産業用インターネット参照アーキテクチャにおけるデータ接続

本日、インダストリアルインターネットコンソーシアム（IIC）は、インダストリアルインターネットリファレンスアーキテクチャ（IIRA）をリリースしました。 IICは、170を超えるメンバー（iiconsortium.org）を擁するモノのインターネット（IoT）コンソーシアムの中で最大のものです。さらに重要なのは、産業用システムに焦点を当てているのはそれだけです。 IIRAの最初の公開リリースは、高レベルの観点からのシステムアーキテクチャの正式な概要です。ビジネス目標からシステムの相互運用性まで、すべてを網羅しています。アーキテクチャは、多くの重要な技術ガイドラインを確立します。重要なことに、それはまた多くのアプローチを排除します。アーキテクチャとは、できることと同じくらい、できないことのことです。

Real-Time Innovations（RTI）は、IIRA接続アーキテクチャという1つの重要な側面に最も興奮しています。 「接続性」、つまり物事の通信方法は、新興の産業用モノのインターネット（IIoT）にとって最大の課題の1つです。 IIRAは、最高のパフォーマンス、信頼性、およびセキュリティを提供しながら、相互運用性を容易にする革新的な分散型「データバス」アプローチを採用しています。

共通アーキテクチャの力

最終的に、IIoTは分散システムの構築に関するものです。システムが最適に実行、スケーリング、進化、機能できるようにすべてのパーツをインテリジェントに接続することが、IIRAの核心です。

IIoTを有効にするには、共通を開発する必要があります コンピューティング機能にまたがり、ベンダー間で相互運用し、業界を橋渡しできるアーキテクチャ。時間の経過とともに、業界にまたがる一般的なテクノロジーが常に特注のシステムに取って代わります。ただし、段階的な採用と現在のテクノロジーの適応も重要です。したがって、IIoTは多くの標準と接続技術を統合する必要があります。 IICアーキテクチャは、さまざまな接続テクノロジーを相互接続された未来に明示的にブレンドし、非常に接続された新しい世界の抜本的なビジョンを可能にします。

これは「相互運用性」の問題であり、実際にはRTIの専門です。 RTIは、15の異なる標準とコンソーシアムの取り組みに参加しています。それらは、ほんの数例を挙げると、海軍システム、航空電子工学、電力、医療機器、無人機、家庭用電化製品、産業用制御、および放送テレビなど、多くの産業にまたがっています。すべては、システムを連携させる方法に焦点を当てています。 IICは、これらの業界などの経験を活用しています。

統合の課題

多くの異なるシステムを接続する場合、根本的な問題は「Nの2乗」相互接続の問題です。 2つのシステムを接続するには、プロトコル、データモデル、通信パターン、信頼性、データレート、タイミング期限などのサービス品質（QoS）パラメータを含む多くの側面を一致させる必要があります。 2つのシステムを接続することは困難ですが、専用の「ブリッジ」で解決できます。しかし、それは拡張性がありません。 N を接続する システムを一緒にするには N -二乗橋。 N として 大きくなると、これは気が遠くなるようなものになります。

この問題を緩和する1つの方法は、Nを小さく保つことです。これを行うには、相互運用するすべてのシステムにわたってすべての標準とテクノロジーを指示します。多くの業界固有の標準化団体は、この道をうまく進んでいます。たとえば、European Generic Vehicle Architecture（GVA）は、低レベルのコネクタから最上位のデータモデルまで、軍用地上車両の構築方法のあらゆる側面を指定しています。ドイツのインダストリー4.0の取り組みは、製造業でも同様のパスを取り、注文と配送、工場の設計、技術、および製品の計画を選択します。タスクごとに1つの標準のみが許可されます。

このアプローチにより、相互運用が容易になります。残念ながら、厳密に選択された標準がすべての機能と機能を提供できるわけではないため、結果の範囲は限られています。このように業界を効果的に横断するには、特別な要件が多すぎます。標準を口述することは、レガシー統合の問題にも対処しません。これらの2つの制限（範囲とレガシーの制限）により、このアプローチは、幅広い業界を超えた産業用インターネットの構築には適していません。

スペクトルの反対側では、非常に一般的なブリッジポイントを構築できます。エンタープライズWebサービスは、Apache Camelのような「エンタープライズサービスバス」（ESB）を使用してこのように機能します。ただし、その名前に「バス」が含まれているにもかかわらず、ESBは分散型の概念ではありません。すべてのシステムは単一のポイントに接続する必要があります。ここで、各着信標準は共通のオブジェクト形式にマップされます。すべてが1つの形式にマッピングされるため、ESBは「一方向」の変換のみを必要とし、 N を回避します。 -二乗問題。たとえば、Camelは、それぞれが1つのプロトコルまたはデータソースを変換する何百ものアダプタをサポートしています。

残念ながら、これは要求の厳しい産業用システムにはうまく機能しません。単一のESBサービスは、明らかな問題と障害のポイントです。 ESBは大きくて遅いプログラムです。企業では、ESBは、1秒あたりわずか数のトランザクションを実行する大規模なシステムを接続します。産業用アプリケーションには、はるかに高速で信頼性が高く、きめの細かいサービスが必要です。そのため、ESBはほとんどのIIoTの使用には適していません。

IIRA接続コア標準

IIRAは中間的なアプローチを取ります。この設計では、「接続コア標準」の概念が導入されています。 ESBとは異なり、コア標準は非常に分散された概念です。一部のエンドポイントは、コア標準に直接接続できます。他のエンドポイントとサブシステムは「ゲートウェイ」を介して接続します。次に、コア標準がそれらをすべて接続します。これにより、すべての可能なペア間をブリッジすることなく、複数のプロトコルが可能になります。それぞれがコアへのブリッジを1つだけ必要とします。

ESBのように、これは N を解決します -二乗問題。ただし、ESBとは異なり、集中型サービスモデルに代わる、高速な分散型コアを提供します。レガシーで機能の少ない接続テクノロジーは、ゲートウェイを介してコア標準に変換されます。 N のみがあります 変換、ここで N は接続規格の数です。

<図>

明らかに、この設計には非常に機能的なコア接続規格が必要です。一部のシステムは、低速または単純なコアでうまくいく場合があります。しかし、ほとんどの産業用システムは、他のコンテキストでは見られない要求を伴う多くのデータを識別、記述、検索、および通信する必要があります。多くのアプリケーションでは、マイクロ秒単位での配信、または数千または数百万ものデータ値とノードへの拡張機能が必要です。信頼性障害の結果は深刻な場合があります。コア標準は実際にはシステムのコアであるため、実行する必要があります。

IIRAは、接続フレームワークとそのコア標準が提供する必要のある主要な機能、つまりデータ検出、交換パターン、および「サービス品質」（QoS）を指定します。 QoSパラメータには、配信の信頼性、順序付け、耐久性、寿命、およびフォールトトレランス機能が含まれます。これらの機能により、コア接続は、業界全体の要求の厳しいアプリケーションに必要な、信頼性が高く、高速で、安全なトランスポートを実装できます。

<図>

セキュリティも重要です。セキュリティを正しく機能させるには、セキュリティをアーキテクチャと緊密に連携させる必要があります。たとえば、「コア」標準はさまざまなパターンと配信機能をサポートする場合があります。セキュリティ設計はそれらと正確に一致する必要があります。たとえば、接続がパブリッシュ/サブスクライブをサポートしている場合は、セキュリティも必要です。コアがマルチキャストをサポートしている場合は、セキュリティも必要です。コアが動的プラグアンドプレイ検出をサポートしている場合は、セキュリティも必要です。これがアーキテクチャと密接に関連しているセキュリティは、コードを変更せずにいつでも課すことができます。セキュリティは、より複雑に構成されていますが、もう1つの制御されたサービス品質になります。これは非常に強力な概念です。

統合セキュリティは、コアを超えて拡張する必要があります。 IIRAもそれを可能にします。他のすべての接続テクノロジーは、ゲートウェイで保護できます。

コアスタンダードとしてのDDS

IIRAは標準を指定していません。 IICは、次のリリースでそのステップを踏みます。ただし、DDS（Data Distribution Service）標準がIIRAに最適であることは明らかです。 DDSは、自動検出、IIRAで指定された各パターン、すべてのQoS設定、および緊密に統合されたセキュリティを提供します。

これは偶然ではありません。 IIRA接続設計は、DDSに関する業界の経験を大いに利用しています。 DDSは、電力システム（巨大な水力発電ダム、風力発電所、マイクログリッド）、医療（イメージング、患者監視、緊急医療システム）、輸送（航空交通管制、車両制御、自動車試験）、産業用制御（SCADA、マイニングシステム、PLC通信）、および防衛（船、航空電子工学、自律型車両）。これらのアプリケーションで学んだ教訓は、IIRAの設計に役立ちました。

ありがとうございます！

最後に、IIRAを構築したチームに感謝します。これは多くの企業に支えられた大きな努力でした。 RTIは、アーキテクチャ、接続性、分散データおよび相互運用性のチームに最も関与していました。みなさん、ありがとうございました。最初のリリースおめでとうございます。