Loading article…
リアルタイムシステム向けのデータ配信サービス（DDS ）は、オブジェクト管理グループ（OMG）のマシン間（ミドルウェアまたは接続フレームワークと呼ばれることもある）標準であり、パブリッシュ/サブスクライブパターンを使用して、信頼性が高く、高性能で、相互運用可能で、リアルタイムかつスケーラブルなデータ交換を可能にすることを目的としています。
DDSは、航空宇宙、防衛、航空交通管制、自動運転車、医療機器、ロボット工学、発電、シミュレーションおよびテスト、スマートグリッド管理、輸送システム、その他のアプリケーションにおけるリアルタイムデータ交換のニーズに対応します。
DDSは、複雑なネットワークプログラミングを簡素化するネットワークミドルウェアです。ノード間でデータ、イベント、コマンドを送受信するためのパブリッシュ/サブスクライブパターンを実装しています。情報を生成するノード（パブリッシャー）は、「トピック」（温度、位置、圧力など）を作成し、「サンプル」を公開します。DDSは、そのトピックに関心を示すサブスクライバーにサンプルを配信します。
DDSは、メッセージのアドレス指定、データのマーシャリングとデマーシャリング（購読者が発行者とは異なるプラットフォームにいても対応できるようにするため）、配信、フロー制御、再試行など、転送処理を担います。どのノードも、発行者、購読者、またはその両方を同時に担うことができます。
DDSのパブリッシュ/サブスクライブモデルは、分散アプリケーションにおける複雑なネットワークプログラミングを事実上不要にする。
DDSは、基本的なパブリッシュ/サブスクライブモデルを超えるメカニズムをサポートしています。主な利点は、DDSを使用して通信を行うアプリケーションが疎結合になることです。アプリケーション間の相互作用を処理するための設計時間はほとんど必要ありません。特に、アプリケーションは、他の参加アプリケーションの存在や場所などの情報を必要としません。DDSは、ユーザーアプリケーションからの介入を必要とせずに、以下のようなメッセージ配信を透過的に処理します。
DDSでは、ユーザーがサービス品質（QoS）パラメータを指定して、検出メカニズムと動作メカニズムを事前に構成できます。DDSは匿名でメッセージを交換することで、分散アプリケーションを簡素化し、モジュール化された構造の整ったプログラムを促進します。 また、プライマリパブリッシャーが故障した場合、DDSは冗長パブリッシャーのホットスワップを自動的に処理します。サブスクライバーは常に、データが有効な（つまり、パブリッシャーが指定した有効期間が経過していない）最も優先度の高いサンプルを取得します。プライマリが復旧すると、自動的にプライマリに切り替わります。
DDSの実装には、プロプライエタリソフトウェアとオープンソースソフトウェアの両方が利用可能です。これらには、Ada、C、C++、C#、 Java、Python、Scala、Lua、Pharo、Ruby、Rustで実装されたアプリケーションプログラミングインターフェース（API）とライブラリが含まれます。
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相互運用性の実証実験では、以下のようなシナリオが用いられた。
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つのレベルのインターフェースが規定されています。
初期のコア文書に続いて、他の関連規格が策定されました。リアルタイムパブリッシュ/サブスクライブワイヤプロトコルDDS相互運用ワイヤプロトコル仕様は、あるベンダーのDDS実装を使用してトピックに公開された情報が、同じまたは異なるベンダーのDDS実装を使用する1つ以上のサブスクライバーによって利用可能であることを保証しました。この仕様はDDSコミュニティを対象としていますが、その使用は限定されていません。バージョン2.0は2008年4月に、バージョン2.1は2010年11月に、バージョン2.2は2014年9月に、バージョン2.3は2019年5月に公開されました。[ 7 ]
軽量CCM用 DDS (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 ]