SOME/IPは、制御メッセージに使用できる自動車用ミドルウェアソリューションです。 DDSは、通信用の自動車用ミドルウェアでもあります。それらの違いは何ですか?そして、なぜそしていつ私はそれらの1つを選ぶべきですか?
SOME/IPとDDSはどちらも、分散アプリケーションがパブリッシュ/サブスクライブパターンとサービスリクエスト/リプライパターン(RPC)の両方を使用して通信できるようにします。しかし、大きな違いもあります。
SOME/IPは、自動車業界向けに特別に設計されています。 SOME/IPは、AUTOSARの一部として開発された仕様のコレクションであり、シリアル化プロトコル、サービスディスカバリ、およびtransformerクラシックAUTOSARとの統合用。
DDS(データ配布サービス)は、より広範な産業用IoTドメインを対象としています。これは、Object Management Group(OMG)によって公開されたオープンスタンダードのファミリです。分散型リアルタイムシステム用に特別に設計されており、輸送、エネルギー、医療システム、産業オートメーション、航空宇宙および防衛などを含む 多くの産業 で使用されています。商業およびオープンの両方で多くの独立した実装がありますソース。 DDSファミリの最初の仕様は2004年にリリースされ、それ以降、標準wire-protocolを含む 12 DDS標準 のセットに成長しました。 (DDS-RTPS)、API(DDS-PSM-CXX、DDS-PSM-JavaおよびIDLからC、Adaなどへのマッピング)atype system(DDS- XTYPES)、データ配信パターン(データ中心のパブリッシュサブスクライブのDDSおよびリクエスト/リプライのDDS-RPC)、security (DDS-SECURITY)、システムの説明(DDS-XML)、データモデリング(IDL)、および他の通信フレームワーク(DDS-WEB、DDS-OPCUAおよびDDS-XRCE)へのゲートウェイ。
技術的および概念的には多くの違いがあるため、それらを別々のカテゴリに整理しました。
SOME/IPは、オブジェクトベースのサービス指向アーキテクチャと見なすことができます。情報は、サービスオブジェクトをインスタンス化することによってシステムに提供されます。これらは、アクセスする各サービスインスタンスの対応する「プロキシ」オブジェクトをインスタンス化するクライアントアプリケーションによってアクセスされます。クライアントアプリケーションは、サービスオブジェクトにプロキシオブジェクトをアタッチし、それを使用してイベントとフィールドの変更を監視することにより、情報をサブスクライブします。また、サービスオブジェクトの操作を呼び出して、リモートプロシージャコールを実行したり、特定のフィールドを読み書きしたりすることもできます。
DDSは基本的に、分離されたデータ中心のパブリッシュサブスクライブモデルを提供します。阿蘇は「データバス」パターンと呼ばれていました。アプリケーションはDataBusピアに参加し、任意のデータ(DDS-Topic名で識別)をパブリッシュ/サブスクライブしたり、任意のサービス操作(DDS-Service名で識別)を呼び出したり実装したりできます。 DDSは完全にピアツーピアです-途中にブローカーは必要ありません。同じトピック名を参照する互換性のあるパブリッシャーアプリケーションとサブスクライバーアプリケーションを検出するために継続的に実行される検出メカニズムがあります。それらが検出されるとすぐに、直接情報の交換を開始します。サブスクライバーアプリケーションは、フィルター(コンテンツまたは時間ベース)を指定して、受信する情報を示すことができます。パブリッシャー側でいじりが発生して、送信される情報を減らすことができます。
DDSとSOME/IPの大きな違いは、DDSではアプリケーションがサービスの特定の実装にバインドする必要がないことです。トピックとサービスを単純に参照し、アプリケーションコードを変更することなく、1対1または1対多で完全に透過的に通信します。ピアの参加または離脱に応じて、個別のピアの存在を追跡するか、新しいオブジェクトを管理する必要があります。すべて自動的に処理されます。この意味で、SOME/IPよりもはるかに動的です。
SOME/IPは標準APIを定義していません。実装は通常C++ APIを提供しますが、実装間での移植性はありません。ただし、通常、SOME/IPはAUTOSARの一部として使用され、いくつかの標準APIを定義しています。
DDSには複数の言語用の標準APIがあります。 C++およびJavaの場合、これらはDDS-PSM-JavaおよびDDS-PSM-CXX仕様に含まれています。標準のCおよびADA APIは、IDL to CおよびADA仕様から派生しています。その上、C#およびその他の言語用のベンダー固有のAPIがあります。したがって、DDSアプリケーションを移植し、DDS実装間で切り替えることが一般的に可能です。
SOME/IPは、UDPとTCPの両方でデータ転送をサポートします。AUTOSAR4.3は、UDPを介した1400バイトを超えるペイロードのセグメンテーションのサポートを導入しました。信頼できる通信のために、SOME/IPはTCPにフォールバックします。
DDSは、RTPS(リアルタイムパブリッシュサブスクライブ)と呼ばれるワイヤープロトコルを使用しました。これは、プラットフォームに依存しないモデルで定義され、さまざまなネットワークトランスポートプロトコルにマッピングできます。ほとんどのDDS(DDS-RTPS)実装は、少なくともUDP、TCP、および共有メモリをサポートしています。 RTPSは、トランスポートにとらわれない信頼性とフラグメンテーションプロトコルを実装します。これは、UDPとマルチキャストを含む、あらゆるトランスポート上で実行されます。そのため、DDSを使用すると、マルチキャストUDPを介して大きなデータと信頼性の高いデータを送信できます。 SOME/IPはそれを行うことができません。
多くのDDS実装は「カスタムトランスポート」SDKを提供しているため、機能やQoSを犠牲にすることなく、独自のカスタムトランスポートを介してDDSを実行できます。特定の機能(信頼性や断片化など)をトランスポートで実装する必要があるため、これはSOME/IPでは不可能です。
一般的に言えば、SOME/IPもセキュリティをトランスポートに依存しています。安全に使用するには、TLSまたはDTLSで実行する必要があります。
DDS over TLSまたはDTLSをトランスポートとして実行することも可能ですが、これは推奨されるソリューションではありません。むしろ、DDSでは、トランスポートに依存しない、DDSセキュリティ仕様で定義されたメカニズムを使用するのが最善です。また、DDSセキュリティは、セキュリティとアクセス制御を行う言語をはるかにきめ細かく制御できるため、DDSドメインとトピックを個別に保護し、トピックに対する読み取り権限と書き込み権限を区別することが可能になります。また、DDSセキュリティはトランスポートに依存しないため、共有メモリ、マルチキャスト、またはカスタムアプリケーション定義のトランスポートを含む任意のトランスポートで使用できます。
SOME/IPは、UDPとTCPの選択に使用される「信頼性」Qos設定を1つだけ提供します。それ以外のものは、QoSポリシーによっては非常に困難なカスタムアプリケーションロジックで実装する必要があります。また、アプリケーション層コードは移植性が低く、すべてのアプリケーションに同じコードを含めるか、少なくとも一般的な非標準ライブラリをリンクする必要があります。
DDSは、ユーザーがパブリッシャーとサブスクライバー間で情報を交換する方法を宣言的に指定できるようにする多数のQoSポリシーを提供します。 DDS標準では、20を超える個別のポリシーが定義されています。これらのポリシーは、信頼性だけでなく、リソースの使用状況、データの優先順位付け、データの可用性、フェイルオーバーなどの他の側面も制御します。たとえば、QoS設定は、パブリッシャーまたはサブスクライバーアプリケーションが特定のレートで情報を送信または配信できない場合に通知を提供するデッドラインを確立する機能を提供します。データのセットアップ耐久性情報が生成および送信された後に参加する加入者アプリケーションに再送信できるようにします。パブリッシャーアプリケーションとサブスクライバーアプリケーションの履歴の深さを構成します。 所有権の強度に基づいて多数の中から1つのソースを自動的に選択する冗長システムを展開し、自動livelinessメッセージを構成して、リモートアプリケーションがまだあるかどうかを判断しますアプリケーションが応答しない場合は、稼働して自動フェイルオーバーを実行します。 DDS仕様 のセクション2.2.3から、またはさまざまな実装のドキュメントから、より多くの詳細を取得できます(たとえば、これを参照してください RTI Connext DDSからのQoS Cheat-Sheet =)。
SOME/IPは、主に自動車アプリケーションのAUTOSARで使用されます。
DDSはより水平に使用されます。多くの場合、接続フレームワークとして直接使用されます。実際、Industrial Internet Consortium(IIC)によって、IIoTの「コア接続フレームワーク」の1つとして識別されました( Industrial Internet of Things Connectivity Framework ドキュメントを参照)。 OpenFMB 、 ROS2 、 MD PnP 、 [〜#〜]などの他の標準およびフレームワークの一部としても使用されますface [〜#〜] 、そしてそれも AUTOSAR Adaptive(バージョン18.03以降) に含まれています。