データ配信サービス

リアルタイム システムのデータ配布サービス( DDS )は、パブリッシュ/サブスクライブパターンを使用して、信頼性が高く、高性能で、相互運用可能で、リアルタイムで、スケーラブルなデータ交換を可能にすることを目的とした、オブジェクト管理グループ (OMG )のマシン間(ミドルウェアまたは接続フレームワークと呼ばれることもある) 標準です。

DDS は、航空宇宙、防衛、航空交通管制、自律走行車、医療機器、ロボット工学、発電、シミュレーションとテスト、スマートグリッド管理、輸送システム、その他のアプリケーション におけるリアルタイムのデータ交換のニーズに対応します。

DDS は、複雑なネットワーク プログラミングを簡素化するネットワークミドルウェアです。ノード間でデータ、イベント、コマンドを送受信するためのパブリッシュ/サブスクライブ パターンを実装します。情報を生成するノード (パブリッシャー) は、「トピック」(温度、場所、圧力など) を作成し、「サンプル」をパブリッシュします。DDS は、そのトピックに関心があると宣言したサブスクライバーにサンプルを配信します。

DDS は、メッセージのアドレス指定、データのマーシャリングとデマーシャリング(サブスクライバーがパブリッシャーとは異なるプラットフォーム上に存在できるようにする)、配信、フロー制御、再試行などの転送作業を処理します。どのノードも、パブリッシャー、サブスクライバー、または同時に両方になることができます。

DDS パブリッシュ/サブスクライブ モデルにより、分散アプリケーションの複雑なネットワーク プログラミングが事実上不要になります。^{[引用が必要]}

DDS は、基本的なパブリッシュ/サブスクライブ モデルを超えるメカニズムをサポートします。^[要出典]主な利点は、通信に DDS を使用するアプリケーションが分離されることです。相互のやり取りを処理するために設計に費やす時間はほとんどありません。特に、アプリケーションは、参加している他のアプリケーションの存在や場所などの情報を必要としません。DDS は、ユーザー アプリケーションからの介入を必要とせずに、次のようなメッセージ配信を透過的に処理します。

• メッセージを誰が受け取るかを決定する
• 受信者の所在地
• メッセージが配信できない場合はどうなるか

DDS では、ユーザーがサービス品質(QoS) パラメータを指定して、事前に検出および動作メカニズムを構成できます。匿名でメッセージを交換することで、DDS は分散アプリケーションを簡素化し、モジュール式の適切に構造化されたプログラムを促進します。^{[引用が必要]} また、プライマリに障害が発生した場合、DDS は冗長パブリッシャーのホットスワップを自動的に処理します。^{[引用が必要]}サブスクライバーは常に、データがまだ有効な (つまり、パブリッシャーが指定した有効期間が経過していない) 最も優先度の高いサンプルを取得します^{[引用が必要]}。プライマリが回復すると、自動的にプライマリに切り替わります^{[引用が必要]}。

DDS の独自ソフトウェア実装とオープンソース ソフトウェア実装の両方が利用可能です。これらには、アプリケーション プログラミング インターフェイス(API) と、Ada、C、C++、C#、 Java、Python、Scala、Lua、Pharo、Ruby、Rustでの実装ライブラリが含まれます。

DDSベンダーは、2009年から2013年にかけてOMG春季技術会議で相互運用性のデモンストレーションに参加した。^{[1] [2] [3] [4] [5] [6]}

デモ中、各ベンダーは、シェイプ デモと呼ばれるテスト スイートを使用して、互いのトピックを公開およびサブスクライブしました。たとえば、あるベンダーがシェイプに関する情報を公開し、他のベンダーがそのトピックをサブスクライブして、結果を各自のシェイプ ディスプレイに表示できます。各ベンダーが順番に情報を公開し、他のベンダーがサブスクライブします。デモを可能にしたのは、DDS-I またはリアルタイム パブリッシュ サブスクライブ (RTPS) プロトコル^[7]と、共通モデルを使用するという合意の 2 つです。

2009 年 3 月、3 つのベンダーが、2009 年 1 月から OMG リアルタイム パブリッシュ サブスクライブ プロトコル バージョン 2.1 を実装した個別の独立した製品間の相互運用性をデモンストレーションしました。デモンストレーションでは、異なる OS プラットフォーム ( Microsoft WindowsとLinux ) 上の互いのパブリッシャーとサブスクライバーの検出が含まれ、マルチキャストとユニキャストのネットワーク通信がサポートされました。^[1]

DDS 相互運用性のデモンストレーションでは、次のようなシナリオが使用されました。

• インターネット プロトコル(IP)を使用したネットワークへの基本的な接続
• 発行者と購読者の発見
• サービス品質 (QoS) 要求者と提供者間の互換性
• 遅延耐性ネットワーク
• 複数のトピックとトピックのインスタンス
• トピックの独占所有権
• 時間や地理情報を含むトピックデータのコンテンツフィルタリング

DDS仕様の開発は2001年に始まりました。2004年にオブジェクト管理グループ（OMG）はDDSバージョン1.0を公開しました。^[8]バージョン1.1は2005年12月に公開され、^[9]バージョン1.2は2007年1月に、^[10] バージョン1.4は2015年4月に公開されました。 ^[11] DDSはいくつかの米国特許で保護されており、^{[12] [13] [14] [15]}などもあります。

DDS 仕様では、次の 2 つのレベルのインターフェースが説明されています。

• 適切な情報を適切な受信者に効率的に配信することを目的とした、より低いデータ中心のパブリッシュ/サブスクライブ (DCPS) レベル。
• オプションの上位データ ローカル再構築レイヤー (DLRL) により、DDS をアプリケーション レイヤーに簡単に統合できます。

その他の関連規格も、最初のコアドキュメントに倣ったものです。リアルタイム パブリッシュ サブスクライブ ワイヤ プロトコル DDS 相互運用性ワイヤ プロトコル仕様は、あるベンダーの DDS 実装を使用してトピックに公開された情報が、同じまたは異なるベンダーの DDS 実装を使用する 1 人以上のサブスクライバーによって利用可能であることを保証しました。この仕様は DDS コミュニティを対象としていますが、その使用は限定されていません。バージョン 2.0 は 2008 年 4 月に、バージョン 2.1 は 2010 年 11 月に、バージョン 2.2 は 2014 年 9 月に、バージョン 2.3 は 2019 年 5 月に公開されました。^[7]

DDS for Lightweight CCM (dds4ccm) は、ビジネス ロジックを非機能プロパティから分離するアーキテクチャ パターンを提供します。2012 年の拡張機能では、ストリームのサポートが追加されました。^[16] DDS 用の Java 5 言語 PSM は、DDS 用のプラットフォーム固有モデル (PSM) と呼ばれる Java 5 言語バインディングを定義しました。これは、DDS 仕様のデータ中心のパブリッシュ/サブスクライブ (DCPS) 部分のみを指定しました。さらに、DDS-XTypes と DDS-CCM によって導入された DDS API を網羅しています。DDS-PSM-Cxx は、DDS 用のプラットフォーム固有モデル (PSM) と呼ばれるISO/IEC C++ ^{[17] PSM 言語バインディングを定義します。これは、C++ プログラマにとってより自然な、DDS をプログラミングするための新しい C++ API を提供します。 [18]この仕様は、DDS-XTypes で指定された}アプリケーション プログラミング インターフェイス(API) と、 DDS-CCM で指定されたサービス品質(QoS) プロファイル へのアクセスのマッピングを提供します。

DDS の拡張可能で動的なトピック タイプ (DDS-XTypes) は、トピックが特定のデータ構造で定義されるデータ中心のパブリッシュ/サブスクライブ通信のサポートを提供しました。拡張可能にするために、DDS トピックはコンパイル前に定義され、DDS グローバル データ スペース全体で使用されるデータ型を使用します。このモデルは、静的な型チェックが有用な場合に適しています。^[19] 統一モデリング言語(UML) プロファイルは、分析および設計モデリングの一部となる DDS ドメインとトピックを指定しました。^[20]この仕様では、XML や OMG IDL などの別の言語で最初に型を記述せずにオブジェクトをパブリッシュおよびサブスクライブする方法も定義しました。^[21] インターフェイス定義言語(IDL) は、Common Object Request Broker Architecture (CORBA) 仕様の第 3 章とは独立して 2014 年に指定されました。この IDL 3.5 は CORBA 3 仕様と互換性がありましたが、独自の仕様として抽出されたため、CORBA とは独立して進化できました。^[22]

他に言及すべきプロトコルとしては、DDS-XRCE (DDS for eXtremely Resource Constrained Environments) があります。この仕様プロトコルは、マイクロコントローラなどのリソースが限られたデバイスと DDS ネットワーク間の通信を可能にします。これにより、DDS ドメイン内の中間サービスを介してトピックの公開と購読が可能になります^[23]。また、リモート プロシージャ コールを定義する DDS-RPC (RPC Over DDS) もあります。これらは双方向の要求/応答通信を提供し、分散サービスを決定し、サービス インターフェイスを使用して詳細化されます。また、同期メソッド呼び出しと非同期メソッド呼び出しの両方をサポートします。 ^[24]

2015年のDDSバージョン1.4以降、オプションのDLRLレイヤーは別の仕様に移行されました。^[25]

• ミドルウェア
• オープンアーキテクチャコンピューティング環境
• 仕様を開発した標準化団体、オブジェクト管理グループ（OMG）