フレームワークとトランスポート：最適なIIoT接続ソリューションの選択
今日の新たな産業用モノのインターネット（IIoT）ランドスケープで分散システムインフラストラクチャを構築することは、控えめに言っても困難な作業になる可能性があります。開発者またはシステムアーキテクトの場合、分散アプリケーション内でデータを移動するために使用できるツールやプロトコルが多数あることをご存知でしょう。 TCPまたはUDPソケット上に直接独自のカスタムソリューションを構築する可能性は言うまでもありません。次のインフラストラクチャを決定する前に実行する必要のある多くの作業がすでに完了しているとしたら、すばらしいと思いませんか？
あのね？作業は完了し、その決定を支援するために利用できるようになりました。 「この調査をすべて行ったのは誰で、独自のソリューションを販売しようとしている企業によってバイアスがかかっているのでしょうか」と質問する必要があります。幸いなことに、この調査は独立したコンソーシアムであるインダストリアルインターネットコンソーシアム（IIC）によって完了されました。これはベンダーに中立で偏りのない方法で実施され、結果の情報を利用できるようになりました。
完全な免責事項：はい、私はインダストリアルインターネットのインフラストラクチャを提供する会社で働いていますが、私たちのソリューションが最良のソリューションであると言っているわけではありません。 「最善の解決策は何ですか？」という質問に対する本当の答え。は、「状況によります」です。
答えは、インフラストラクチャソリューションに必要なものによって異なります。
- ポイントAからポイントBにデータのバイトを送信する必要がありますか？
- データを確実に配信する必要がありますか？
- インフラストラクチャがよりインテリジェントなソリューションのための効率的な配信決定を提供できるように、データ中心の認識が必要ですか？
- どのくらいのデータ処理をインフラストラクチャに渡したいですか？
これらの重要な質問への回答、およびその他多くのことは、この投稿で調査するものです。この投稿の終わりまでに、独自のアプリケーションに最適なソリューションを十分な情報に基づいて決定するために必要な情報が得られることを願っています。
インダストリアルインターネットコンソーシアム（IIC）について
IICは、インダストリアルインターネット業界の非常に大きなプレーヤーによって2014年に設立されました。創設企業（Cisco、Intel、AT＆T、IBM、GE）は、産業用インターネットアプリケーションのニーズのみに焦点を当てた組織の設立に着手しました。現在、コンソーシアムは大小を問わず250社を超える企業で構成されています。このコンソーシアムの結果には、これらのタイプの産業用インターネットアプリケーションのニーズと潜在的なソリューションの概要を説明する一連のドキュメントが含まれています。ガイダンスドキュメントであるIIC産業用インターネット接続フレームワーク（IICF）ドキュメントは、市場ベースの例に最適なソリューションを決定するのに最適です。さまざまなドキュメントに加えて、さまざまなテクノロジーがさまざまな実際の市場の例に対応できることを証明するために使用されるテストベッドも確立されています。入手可能なドキュメントと市場ベースのテストベッドに関する情報は、IICのWebサイトにあります。
データの配信：トランスポートとフレームワーク
アプリケーション間でデータを取得するために、今日利用できるソリューションはたくさんあります。 IICFドキュメントでは、これらのソリューションは、トランスポートとフレームワークの2つのカテゴリに分類されています。これら2種類のデータ転送ソリューションを見て、接続レイヤーのスタック全体のどこに適合するかを見てみましょう。下の図1は、この接続スタックを示しています。
このドキュメントを読んでいるほとんどの人は、このような接続スタックを見たことがあるでしょうが、IICのスタックには、トランスポート層とフレームワーク層という1つの明確な違いがあります。
通常、トランスポートとフレームワークのカテゴリに表示されるすべてのソリューションをグループ化する傾向がありますが、トランスポートとフレームワークには非常に大きな違いが1つあります。トランスポートは、ポイントAからポイントBにデータを配信するために使用されますが、フレームワークは基本的にトランスポートの機能を活用しながら、相互運用性のためのデータ型システムを提供します。簡単に言うと、トランスポートのみを使用する場合、アプリケーションは、トランスポートに渡すためにデータを汎用バッファーに定式化する必要があります。ただし、フレームワークを使用すると、アプリケーションはデータをフレームワークに渡すだけで済み、フレームワークは、基盤となるトランスポートが先に進んでデータを送信するためのバッファーの構築を処理します。アプリケーションのデータレベルでの作業は、コンテンツフィルタリングや検出などの機能を提供するアプリケーションに多くの利点がありますが、アプリケーションがトランスポート層で何かを使用するだけの場合、必要に応じて検出とフィルタリングを実装するのはアプリケーション次第です。表1に、トランスポートまたはフレームワークの各レイヤーで使用できるすべての機能を示します。
トランスポートを使用して分散型産業用インターネットアプリケーションを構築できますか？はい。フレームワークを使用して分散型産業用インターネットアプリケーションを構築できますか？はい。一方はもう一方よりも優れていますか？本当の答えは、「状況によって異なります」です。インフラストラクチャに最適なソリューションは、アプリケーションの要件によって異なります。この投稿の残りの部分では、これらのフレームワークとトランスポートのいくつかについて説明し、アプリケーションに適したテクノロジーを決定できるようにします。
トランスポート
アプリケーション間でデータを取得するために、今日利用できるソリューションはたくさんあります。 IICFには、UDPまたはTCPのいずれかの標準IPソケットインターフェイスを利用するトランスポートが呼び出されます。アプリケーションで信頼性の高いデータ転送が必要な場合、開発者はコネクション型の機能と信頼性の高いメカニズムのためにTCPを選択します。より単純な接続と信頼性の低いデータ転送のために、UDPはその使いやすさとマルチキャスト配信のために選択されます。何年もの間、ほとんどのネットワークアプリケーションは、データの送受信にこれらの基本的なインターフェイスを使用していました。上位層のトランスポート（表1にリストされている）によって提供されるすべての機能は、アプリケーション内で直接構築する必要があります。 DDS-RTPS、CoAP、MQTT、HTTP、およびOPC-UAビンの上位層のトランスポートを確認する場合、実際にはCoAPとMQTTの詳細のみを確認します。 DDS-RTPS、HTTP、およびOPC-UAのビントランスポートは、基本的に、それぞれDDS、Webサービス、およびOPC-UAの上位のフレームワークに直接関連付けられています。これらのトランスポートの機能については、以下のフレームワークの説明の一部として説明します。
MQTT
メッセージキューテレメトリトランスポート（MQTT）を見てみましょう。繰り返しになりますが、MQTTはアプリケーションのデータモデルを強制または実装しないため、ここではトランスポートとしてリストされています。これは、アプリケーションが送受信するデータを作成するためのバッファーを提供するだけです。それが作成された主な目的は、その名前に正しく記載されています：テレメトリ。デバイスまたはアプリケーションを現場に出すことで、バックエンドクラウドまたはオフサイトの処理場所に接続し、データを報告します。このトランスポートは、ホームIoTゲートウェイや展開された一連のデバイスのマネージャーなどに最適です。 MQTTの主要なアーキテクチャは、図2に示すように、ブローカーベースです。
図2.MQTTブローカーアーキテクチャ このアーキテクチャでは、すべてのリモートクライアントがデータをMQTTブローカーに送信し、ブローカーはそのデータを要求したすべてのクライアントにデータを送信する責任があります。このブローカーベースのアーキテクチャにより、疎結合方式でのデータの送受信が容易になりますが、低遅延で決定論的な産業用アプリケーションのサポートには適していません。トランスポートとして、MQTTは分散型産業用アプリケーションの全体的なランドスケープの中で位置を占めています。以下は、MQTTが次のプロジェクトまたは現在のプロジェクトに使用する必要があるものであるかどうかを判断するために使用できるツールです。ここに5つの「はい」または「いいえ」の質問があります。これらの質問の3つ以上に対する答えが「はい」の場合、MQTTが正しい選択です。
MQTTに関する質問
- アプリケーションをデータ収集と見なしますか？
- デバイス間の通信はほとんどありませんか？
- 相互運用性は考慮事項ではありませんか？
- 小さなデバイスはたくさんありますか？
- ソフトウェアは小さな課題ですか？
MQTTは、IICFドキュメントにリストされている唯一のトランスポートであり、実際には上位層のフレームワークに関連付けられていません。これが、トランスポートとして個別に分割した理由です。それでは、IICドキュメントにリストされているフレームワークを見てみましょう。
フレームワーク
前述のように、フレームワークとトランスポートの際立った違いは、フレームワークに、フレームワークに参加しているアプリケーションによって使用されるデータモデルを維持および実施する機能が含まれているという事実です。呼び出された4つのフレームワーク、OPC-UA、OneM2M、DDS、およびWebサービスのうち、最初の3つのみを取り上げます。 Webサービスは非常によく知られたフレームワークであり、調査用に見つけることができるオンライン参照がたくさんあります。そのため、この投稿ではレビューしません。選択したフレームワーク（OPC-UA、OneM2M、およびDDS）のそれぞれについて、そのフレームワークの基本の概要と、そのフレームワークが分散IIoTアプリケーションの正しいソリューションであるかどうかを判断するために回答する必要のある重要な質問について説明します。
OPC-UA
最初のフレームワークとしてOPC-UAを見てみましょう。 Open Platform Communications Unified Architecture（OPC-UA）は、IICFドキュメントで次のように説明されています。「プラットフォームに依存しない、高性能、安全、信頼性、およびセマンティックな相互運用性のための産業用通信アーキテクチャ。リアルタイムの製造現場レベル、および製造現場とエンタープライズITクラウドの間。」
MQTTと同様に、OPC-UAもブローカーベースのアーキテクチャです。 OPC-UAクライアントはサーバーにデータオブジェクトを提供し、サーバーは他のOPC-UAクライアントからの要求に応答します。通常、これらのデータオブジェクトは非常にデバイス中心のオブジェクトであり、基本的にはさまざまなデバイスの入力変数と出力変数のコレクションです。クライアントは目的のオブジェクトのグラフを作成でき、サーバーは収集されたすべてのオブジェクトをマップして、要求元のクライアントに一貫した応答を提示します。図3は、特定のシステムで使用可能な既存のオブジェクトのグラフを示す典型的なアーキテクチャ図です。
図3.OPC-UAの一般的なデバイスデータオブジェクトグラフ
OPC-UAインフラストラクチャは、主に産業用自動化および製造環境で使用されます。 OPC-UAがアプリケーションの正しいソリューションであるかどうかを判断するために回答する必要がある4つの質問を次に示します。
OPC-UAに関する質問
- ディスクリート製造を行っていますか？
- ドイツのPlattformIndustrie 4.0プログラムに関連していますか？
- ソフトウェアエンジニアではなく、制御エンジニアまたはプロセスエンジニアまたは技術者によって統合されるデバイスを構築していますか？
- アーキテクチャを制御する1つの（タイプの）システムとは対照的に、製品はさまざまなシステムのさまざまなアプリケーションで使用されますか？
- 「ワークセル」用の機器を構築していますか？
これらの質問の3つに「はい」と答えることができる場合は、OPC-UAがアプリケーションに適しています。
OneM2M
IICドキュメントで呼び出される2番目のフレームワークはoneM2Mです。 IICFドキュメントからの1つのM2Mの説明は、「oneM2Mは、アプリケーションと接続トランスポートの間に位置する共通のサービスレイヤーを提供します。これは、さまざまな業界セグメントにわたるIoTアプリケーションが一般的に必要とする機能を提供します。これらの機能はRESTfulAPIを介してアプリケーションに公開されます。OneM2M標準は、アプリケーション、ミドルウェアサービス、ネットワークで構成される3層モデルに適合する水平プラットフォームアーキテクチャで構成されます。OneM2Mの接続標準により、接続されたマシンとデバイス、エンタープライズシステム、およびモバイルデバイスでホストされるアプリケーションが効率的に相互に通信できるようになります。 、安全な方法。OneM2M水平プラットフォームは、Common Service Elementsをホスト、近位ネットワークエッジ、またはエンタープライズクラウド内に展開できるため、スケーラブルです。」現在oneM2Mを使用している主なアプリケーションは、ホームオートメーションと、モバイルシステムを活用する大規模アプリケーションです。 Common Service Layerで利用可能なサービスは、大規模な電気通信会社によって提供されます。図4は、oneM2Mで呼び出される3つのレイヤーのアーキテクチャを示しています。
以下は、oneM2Mがアプリケーションにとって正しい選択であるかどうかを判断するために答える必要がある5つの特定の質問です。これらの質問の3つに「はい」と答えると、oneM2Mが正しい選択であることがわかります。
OneM2Mに関する質問
- 「ICT」の意味を知っていますか？それはあなたですか？ （情報通信技術）
- セルラーネットワークは主要な接続テクノロジーですか？
- ターゲットアプリケーションは主に可動部品で構成されていますか？
- システムのコンポーネントは、断続的な接続と緩く制御された遅延に耐えることができますか？
- システムは、電話会社などの通信プロバイダーが提供するサービスを活用しますか？
データ配布サービス（DDS）
最後に検討するフレームワークはDDSです。この投稿の著者であり、RTIの従業員である私は、DDSを14年以上使用しているため、DDSに偏っていることを認めなければなりません。 IIC IICFで呼び出される4つのフレームワークのうち、DDSは、ピアツーピアのパブリッシュ/サブスクライブアーキテクチャを提供する唯一のフレームワークです。 DDSを使用すると、各アプリケーションは、共有グローバルデータスペースを作成する「データバス」に参加します。これは、データバスが一連のデータトピックで構成され、それぞれが固有のデータモデルで定義され、データバスの参加者が検出できることを意味します。ピアアプリケーションがトピックに関するデータを公開するか、トピックに関するデータをサブスクライブする意図を宣言すると、DDSは検出メカニズムを介して、適切なすべてのパブリッシャーをサブスクライバーに接続します。図5は、水平レイヤー間に配置されたゲートウェイを介して接続する3つのデータバスをインスタンス化するレイヤードデータバスアーキテクチャの図です。
図5.DDSを使用したレイヤードデータバスアーキテクチャ この図の例は、病院で見られる医療患者監視アプリケーションに基づいています。ただし、これは、現在DDSが使用されている多くの種類のリアルタイム自律アプリケーションのほんの一例です。その他のアプリケーション分野には、スマートグリッド、石油およびガス、自動運転車、輸送および防衛システムが含まれます。 DDSが適切な選択であるかどうかを確認するために、アプリケーションについて自分自身に尋ねる必要がある5つの質問を次に示します。
DDSに関する質問
- 数分/秒/秒のオフラインの場合、深刻な影響はありますか？
- 過去2週間に「ミリ秒」または「マイクロ秒」と言ったことはありますか？
- 10人以上のプログラマーがいますか？
- データには多くの宛先がありますか？
- 次世代のIIoTデザインを構築していますか？
まとめ
前に述べたように、私はDDSの会社で働いているので、DDSインフラストラクチャとそれがリアルタイム自律システムで解決する問題に部分的に取り組んでいます。そうは言っても、この投稿が、あなたのにとって正しい解決策を決定するために使用できるいくつかのツールを提供してくれることを願っています。 次または現在の分散インフラストラクチャプロジェクト。なぜなら、実際には、これらのトランスポートとフレームワークはすべて、非常に異なる問題を解決するのに優れているからです。重要なのは、アプリケーション要件が利用可能なソリューションのランドスケープ内のどこに適合するかを把握することです。ここで推奨されるツールには、IIC産業用インターネット接続フレームワーク（IICF）と、各ソリューションの重要な質問のリストが含まれています。足りないものがございましたら、コメント欄でお気軽にご連絡ください。議論を続け、開発者やアーキテクトがカスタムのプロプライエタリソリューションで車輪を再作成することなく接続の問題を解決するのに役立つ他のソリューションについて学びたいと思います。
追加のリソース：
- RTIブログ>>産業用インターネット接続ドキュメントはコア標準を評価します：DDS、OPC-UA、Webサービス
- 無料のオンデマンドウェビナー：IICの接続フレームワークがIIoT接続の選択をどのようにガイドするか
モノのインターネットテクノロジー