IIoTソリューション| 6産業用IoT通信ソリューション
産業用IoTを選択するタスクは（ IIoT ）通信インフラストラクチャは非常に複雑な作業であり、控えめな表現になります。無数の市販のソリューションの評価は、時間と費用の両方がかかります。各タイプのインフラストラクチャの複数のソリューションをダウンロードして評価してみてください。そうすれば、数人のエンジニアが完了するのに6か月かかるプロジェクトの真っ只中にいることにすぐに気付くでしょう。私たちは皆そこにいました、そして私はあなたがあなた自身に貴重な時間を節約するのを手伝いたいです！
この投稿の目的は、市販されている人気のあるIIoTインフラストラクチャソリューション（AMQP、CoAP、DDS、RTI Connext DDS、MQTT、ZeroMQ）を紹介することです。各ソリューションの機能を強調します。次の6つの評価領域が適用されます：アーキテクチャ、通信パターン、トランスポート、データタイプとフィルタリング、サービス品質とセキュリティ。
-
- 印刷可能なPDFバージョンをダウンロードするには、ここをクリックしてください。
1。アーキテクチャ
特定の通信インフラストラクチャのアーキテクチャパターンに応じて、アプリケーションがインフラストラクチャ全体で他のアプリケーションと通信するために使用する論理接続（下の図1に示す）は異なります。今日のミドルウェアソリューションで使用されている2つの最も基本的なアーキテクチャは、（1）ピアツーピアと（2）ブローカーベースのスターアーキテクチャです。
- ピアツーピアアーキテクチャ 中間要素にデータを送信することなく、アプリケーションが相互に直接通信できるようにします。これらのアーキテクチャは、送信および受信アプリケーションのみが転送を完了するためにCPUリソースを消費しているため、データ配信において本質的により効率的です。したがって、データを持つアプリケーションとデータを必要とするアプリケーションのみがCPUサイクルを消費します。したがって、アプリケーションの要件に基づいて処理を効率的に分散できます。ピアツーピアアーキテクチャのもう1つの利点は、プロデューサーアプリケーションとコンシューマーアプリケーションの間でデータを処理する「仲介者」がいないため、データの確定的な配信がはるかに実現可能になることです。
-
- 2。 ブローカーベースのソリューション データを送信しているすべてのアプリケーションに、データをブローカーサーバーに直接転送するように要求します。その後、ブローカーサーバーは、このデータを受信側のアプリケーションに再送信します。このアーキテクチャの利点は、ブローカーがデータの送受信に関連するすべての複雑さを管理することです。通常、これらのソリューションには、アクティブなデータパス、データの送信者、およびデータの受信者を正確に確認するためのツールが組み込まれています。ブローカーベースのソリューションは、データ配信に遅延をもたらし、ブローカーに障害が発生した場合にすべての通信にも障害が発生するような単一障害点を提示します。単一障害点の問題を解決するために、これらの実装のほとんどは、冗長で可用性の高いブローカーサーバーを提供します。
2。コミュニケーションパターン
通信パターンのサポートは、プロジェクトまたは製品ラインのライフサイクル全体で使用できるインフラストラクチャに不可欠です。最初のプロジェクトではパブリッシュ/サブスクライブのみが必要な場合がありますが、後続のプロジェクトまたは製品では、要求/応答やキューイングなどの追加のパターンが必要になる場合があります。この点で、現在利用可能なすべての既存のIoTソリューションが、プロジェクトに必要なすべての必要なパターンをサポートできるわけではありません。比較表では、現在使用されている最も一般的なパターンと、各インフラストラクチャソリューションがそのパターンを提供しているかどうかを特定しました。これらは、今日使用されている最も一般的なパターンです：
- パブリッシュ/サブスクライブ ：アプリケーション（サブスクライバー）がデータを1回要求すると、その後のデータの更新はすべてサブスクライバーに「プッシュ」されます。継続的にデータの更新を要求する必要はありません。
- リクエスト/リプライ/ RPC （リモートプロシージャコール ）：リクエスターアプリケーションがリクエストを送信し、リプライアーアプリケーションがリクエストに応答します。
- キューイング （またはポイントツーポイント ）：データは、情報をキューに保持するサーバーにプッシュされます。次に、データをキューからプルするか、コンシューマーにプッシュすることができます。パブリッシュ/サブスクライブとは異なり、各データは1つの受信アプリケーションにのみ配布されます。
- 1対多 ：多数の受信アプリケーションに単一のソースから同じデータを取得させる機能。
- 多対多 ：多くのソースから単一の消費アプリケーションにデータを受信する機能。
3。トランスポートとルーティング/ブリッジング
ほとんどの通信ミドルウェアソリューションは、主要な通信プロトコルとしてTCPをサポートしています。 TCPを使用すると、TCPに固有の組み込みの信頼性メカニズムを使用して、データの信頼性の高い配信が可能になります。これは、信頼性を必要とする特定のデータフローに理想的ですが、過剰であり、信頼性の高い配信を必要としない単純なセンサーデータに不要なオーバーヘッドを追加します。 ZeroMQやDDSなどの一部のIoTソリューションは、共有メモリなどの他のトランスポートもサポートしています。注目すべきトランスポートの1つは、DDSにUDPトランスポートを使用することです。信頼性の実装はDDSに組み込まれているため、信頼性の高いトランスポートは必要ありません。これにより、アプリケーションは、信頼性の高い配信であるデータフローと、ベストエフォートであるフローを選択できます。
トランスポート間およびWANを介したデータのルーティングは、これらすべてのソリューションが何らかの形で提供するものです。 ESBとWebテクノロジーを活用するエンタープライズシステムもリアルタイムデータの一部にアクセスする必要がある今日の世界では、通信ミドルウェアがこれらのテクノロジーへの接続をサポートすることも不可欠です。このため、分散システムミドルウェアのコアコンポーネントとしてルーティングとブリッジングが表示されます。
4。データ型とフィルタリング
データがどのようにカプセル化され、ネットワーク上で表現されるかも、特定のインフラストラクチャに固有です。一部のソリューションは、生のデータバイトを介してのみ送信し、データをシリアル化および逆シリアル化するのはアプリケーション次第です。情報をXMLまたはJSON形式で表現できるように、テキスト/文字列データのみを送信するものもあります。このシナリオは、今日のWebテクノロジーでは非常に一般的ですが、データを送信するたびにパケットにデータの説明が含まれ、パケットサイズが元のサイズの3倍を超えることがあるため、非常に非効率的です。パケットサイズを大きくすると、転送の送信側と受信側の両方で帯域幅の使用量が増えるだけでなく、CPUの使用量も増えます。その真ん中にブローカーを置くと、ネットワーク上のパケット数も2倍になります。
DDSなどの他のソリューションでは、ミドルウェアによって一意にシリアル化および逆シリアル化される強い型のデータを使用できます。スキーマは個別に送信されますが、XMLやJSONの場合はそうではないため、メッセージ（またはサンプル）ごとにペナルティを支払う必要はありません。これは、アスペクトのフィルタリングにも非常に重要になります。多数のサブスクライバーを持つ単一のパブリッシャーを設定しているとします。一部のサブスクライバーはすべてのデータを必要としますが、一部のサブスクライバーはデータの一部のみを必要とします。強く型付けされたデータソリューションがなければ、アプリケーションはこのフィルタリング機能をすべて管理する必要があります。これは、さらに多くのコードを作成する必要があります。タイプ情報が厳密に定義されているDDSのようなソリューションを使用すると、ミドルウェアがすべてのフィルタリングを管理できます。より少ないコード=より幸せな開発者:)。実際、RTI Connext DDSには、データ転送のライター側でこのフィルタリングを提供するための追加機能があります。その結果、ネットワークでの帯域幅の使用量が減り、データをフィルターで除外する必要のないアプリケーションでのCPU処理が減ります。
>5。サービス品質
すべてのデータが同じように作成されるわけではありません。これは何を意味するのでしょうか？さて、リアルタイム分散アプリケーションの一部のデータは、ストリーミングセンサーデータです。ほとんどの場合、この種のデータは配信されたデータを保証する必要はありません。特定のセンサーについて、データ配信の特定の期限が守られているか、さらに重要なことに、守られていないことに気を配ることができます。その他のデータは、アラーム/イベントデータである可能性があります。このデータには、可用性の頻度に対する周期性はありません。ただし、配信を保証することは非常に重要です。アラーム/イベントデータにとっても重要なのは、そのデータソースが生きているかどうかの知識です。アラームプロデューサーが稼働していない場合、リアルタイムシステム内で壊滅的なイベントが発生する可能性があります。これらは、アプリケーションのさまざまなデータフローを管理するサービス品質（QoS）の側面のほんの一部です。サービス品質は、現在存在する他のすべてのIIoTソリューションと比較してDDSがユニークな領域の1つです。標準であるDDSは、QoSがトピックごとに適用可能であるという概念に対処するために、初日から構築されました。
プロデューサーベース、コンシューマーベース、またはその両方で定義できるすべてのQoS（DDSとMQTT）は次のとおりです。
DDSQoSポリシー
- 信頼性/ベストエフォート
- 歴史
- 締め切り
- 活気
- 寿命
- 時間ベースのフィルター
- 耐久性
- リーダー/ライターのライフサイクル
- レイテンシ予算
- 輸送の優先順位
- 所有権
- リソースの制限
- パーティション
- 宛先注文
- ユーザーデータ、グループデータ、トピックデータ
DDSから利用できるこれらのQoSの説明については、このリソースを参照してください。 DDSは、提供するQoSポリシーが独自のものですが、他のインフラストラクチャソリューションもいくつかの制限されたQoS機能を提供します。これらのQoS機能は、ブローカーを冗長性と高可用性をサポートするソリューションの基盤にすることを中心に構成されています。 MQTTを使用する場合、3つの基本的なQoS設定があります。
MQTTQoSポリシー
- QoS 0：最大1回の配信
- QoS 1：少なくとも1回の配信
- QoS 2：1回限りの配信
MQTT QoSの説明については、このリソースを参照してください。
6。セキュリティ
システム内のデータが危険にさらされることを心配していますか？そうでない場合は、非常に厳格な物理的セキュリティソリューションを導入する必要があります。または、外部の脅威によってデータにアクセスしたり操作したりする場合、データはそれほど重要ではありません。これに対抗するために、ほとんどのIoT通信ソリューションはSSL / TLSトランスポートを使用して、プロデューサーとコンシューマー間のデータ転送を保護します。 ZeroMQは、SASLを使用した認証ソリューションも提供します。 DDSは、認証、アクセス制御、暗号化/復号化、データのタグ付け、およびロギングをデータフロー（トピック）ごとに指定できるようにする唯一のソリューションです。このセキュリティの実装は、OMG DDSセキュリティ仕様で定義されているように、基本的に認証とアクセス制御の概念を検出と結び付けます。 DDS Secureの詳細については、このリソースを参照してください。
これですべての情報が得られたので、評価フェーズを、提供しようとしているアプリケーションのタイプに関連するいくつかのソリューションに絞り込むことができます。頑張ってください！
印刷可能なPDFバージョンをダウンロードするには、ここをクリックしてください。
モノのインターネットテクノロジー