RTI Connext DDS Professionalツールで市場投入を加速

デモまであと2週間しかありません。

私たちには、完全に機能するマイクログリッド制御システムを提供する単一の高リスクな機会がありました。要件は：

• IntelとARMプロセッサで動作
• LinuxとWindowsプラットフォームをターゲット
• C、C++、Java、Scala、Lua、LabVIEWで書かれたアプリケーションを含む
• ModBusとDNP3プロトコルでレガシー機器と通信
• 上記すべてを満たしながらリアルタイム制御を実行

この投稿では、私たちが直面した実世界の課題と、RTI Connext DDS Professionalに含まれるツールが如何にしてわずか数日で統合問題を解決したかを共有します。一般的な問題とそれに対処した具体的なRTIツールをハイライトし、より深く知りたい方向けにサポート動画と記事へのリンクを提供します。目標は、RTIツールを適用してDDS開発を加速するための実践的な出発点を提供することです。

大規模デモ

これは、Smart Grid Interoperability PanelのOpen Field Message Bus（OpenFMB）の最初の動作デモンストレーションでした。DDSのようなIoT技術を用いたエッジグリッドデバイス制御の新しいアプローチです。

以下は、ハードウェアアーキテクチャ、OS、プログラミング言語を示すシステムのブロック図です：

各参加者をオンラインに導くにつれ、いくつかの課題に遭遇しました。以下のセクションでは各問題と解決に使用したツールを説明します。見出しをスキャンして、あなたのDDSシステムで同様の問題に直面したことがあるか確認し、リンクをクリックして新しいトラブルシューティング技術を学んでください。これらのツールなしでどう診断していたか考えてみてください。

問題：ネットワーク設定の問題

ツール：RTI DDS Ping

Oak Ridge National Labsチームが主要ディスプレイとして機能するLabVIEW GUIを構築していました。彼らのラップトップはネットワーク上のクライアントからのデータを一切見ることができませんでした。まず、マシンが同じサブネットにあるか確認─定石の「基本をチェック」ステップです。標準のpingユーティリティは基本的な到達可能性を確認しますが、DDS検出ポートが開いているかは検証しません。rtiddspingユーティリティはまさにそれを行い、数秒で政府支給のラップトップのファイアウォールがDDS検出トラフィックをブロックしていることを明らかにしました。基本診断の詳細ガイドはこのコミュニティ投稿を参照。

問題：アプリケーションがデータを公開しているか？

ツール：Spy、Admin Console

DDS初心者のベンダーによくある質問は、アプリケーションが正しく振る舞っているか：期待される間隔でデータを公開しているか、データは意味をなしているか。RTI DDS Spyを使用しました。これは特定の型とトピックでフィルタリングし、受信した各サンプルを出力する軽量サブスクライバーです。すべてのベンダーがアプリケーション起動直後にSpyでクイックな健全性チェックを実施しました。

同じトピックが複数のパブリッシャーによって更新される場合、「-showSampleIdentity」スイッチで最新サンプルを送信したパブリッシャーを特定できます。

Spyはコンソールアプリで、組み込みターゲットでも基本テスト用に実行可能。その小さなフットプリント、高速起動、シンプルさが迅速な検証に最適です。詳細な使用手順はこちら。

問題：データ型の不一致

ツール：Admin Console、Monitor

あるベンダーが、前回のテストでは別アプリケーションのデータが見えたが、デモ中にデータが消えたと報告。Admin Consoleが即座にデータ型の不一致を特定─同じトピック名だが異なるIDL構造で定義されていた。このような不一致は、大規模で複雑な型では検出が困難です。Admin ConsoleはDDSのデータ中心の性質を活用し、各参加者が理解するデータ型をイントロスペクションし、簡易ビューと「同等IDL」ビューを並べて比較提示。全アプリケーションのソースIDLがない場合に特に貴重です。

この場合、ベンダーは古いGitHubコミットからの古いIDLを使用していました。最新ファイルをプルし、rtiddsgenで更新された型固有コードを生成、クイックリコンパイルで完全な互換性が復活しました。

問題：QoSの不一致

ツール：Admin Console、Monitor

検出を超えて、QoSの不一致はDDSユーザーにとって最も一般的な統合問題です。設定項目が多すぎる中、如何に互換性を確保するか？ OpenFMBプロジェクトでも最初にいくつかのQoS不一致が発生。Admin Consoleがこれらを迅速に検出し、競合設定をハイライト。QoS名をクリックするとドキュメントにジャンプ可能。検出時に交換されるQoS情報により、Admin Consoleが自動的に不一致をフラグします。

問題：システム性能の検証

ツール：Admin Console、Monitor

Spyは生のテキスト出力を提供しますが、時間経過に沿ったデータの可視化はシステム動態をより明確に描きます。Admin Consoleの組み込みデータ可視化で、全体的なシステムパフォーマンスを迅速に評価し、履歴データをスクロールして現在の状態をトレースしました。短い紹介動画はこちら、より深い掘り下げはこちら。

問題：パフォーマンスチューニング

ツール：Monitor、Admin Console

パフォーマンスチューニングにはMonitorが最適です。アプリケーションから定期的にリアルタイムパフォーマンスメトリクスを公開する特別版DDSライブラリと連携。デバッグライブラリは最小限の侵襲性で、Monitorがデータを集計して分析します。

Monitorで検査可能な項目：

• 送受信統計
• デッドラインミス
• キャッシュハイウォーターマーク
• QoS不一致
• データ型競合
• 損失/拒否サンプル
• 生存性喪失

多くのQoS設定は検出時に通知されません（ローカルリソース管理とパフォーマンスチューニングに影響するため）。Monitorならこれらも検査可能。紹介動画でクイックツアーをご覧ください。

問題：飛行中のデータ変換

ツール：Lua付きPrototyper、LabVIEW用DDS Toolkit

マイクログリッド状態をリアルタイム表示する大規模GUIが必要でした。Oak Ridge National LabsがLabVIEWでGUI構築を志願。LabVIEW用DDS ToolkitでDDSデータを取得し、LabVIEW VI内で使用可能。しかし、Toolkitは配列のシーケンスをサポートせず、これはOpenFMBデータモデルの一部。これらの複雑な型を読み取る迅速なソリューションが必要でした。

Connext DDS Pro 5.2の新機能であるLua付きPrototyperは、最小限のコーディングでDDS対応アプリケーションを迅速作成可能：XMLでトピックとドメイン参加者を定義、シンプルなLuaスクリプトを追加、数分でDDSドメイン上で稼働。（GianpieroのPrototyperブログ記事参照。）

その夜、複雑なDDSトピック（配列のシーケンスを含む）を読み取り、LabVIEW GUI用にフラット化したトピックとして再公開するLuaスクリプトを作成。以前記録したライブデータでオフラインテストし、次のセクションへ。

問題：切り離された開発

ツール：Record、Replay、Lua付きPrototyper

OpenFMBデモは地理的に分散したチームで構築。ノックスビルでの数日を除き、誰もすべてのマイクログリッドコンポーネントに同時アクセスできませんでした。各開発者がライブハードウェアなしで自分のピースをどう進めるか？

LabVIEW GUI用のLuaブリッジ作業時、Connext Pro RecordとReplayサービスを使用。ラボで全ユースケースをカバーする約10分間のライブデータを記録。その夜、ホテルでデータを再生しながらLuaスクリプトを改良。Replayはトピックを選択的に再生、ループ再生で継続的シミュレーション、再生速度を加速─数日分のランタイムを数分に短縮可能。

Prototyperの強みの1つは、実行中にLuaスクリプトを自動リロードすること。これにより高速イテレーションが可能：Replayが加速データを連続再生；Luaスクリプトを編集、保存、Prototyperが即座に反映─再起動不要。変換スクリプトはわずか数時間で完了。

Prototyperはシミュレートデータ生成にも不可欠でした。LabVIEW GUIは完全にオフラインで構築され、Replay生成トピックとPrototyperブリッジ/シミュレートデータを使用。シミュレータースクリプトをORNLにメール、彼らがLabVIEWに組み込み、私はローカルで更新VIを実行して統合検証。ORNLのリアルタイムDDSデータとSGIPビジュアル要素の統合により、デモの目玉となる洗練されたGUIが完成。

主な教訓

数週間後ニューオーリンズに到着時、システム全体が約30分で稼働─LabVIEW GUIのように、実ハードウェアとネットワーク上で初めて動作するアプリケーションがあったことを考えると驚異的な成果です。

RTI Connext DDS Professionalの包括的ツールセットにより、ノックスビル週間で統合ハードルを迅速に解決し、その後もリモート開発を継続できました。Admin Console、Monitor、DDS Ping、DDS Spyが初期導入を加速。Record、Replay、Prototyperがライブハードウェア不在下での分散開発を促進。LabVIEW用DDS Toolkitが高度なGUIを迅速に提供。イベント後もこれらのツールは継続的開発とバーチャルデモに利用可能です。

詳細はこちら：

自律走行車両の生産 »

自律システムにおける接続性 »

DDSとは？ »

Connext DDS Professional »

IIoTとは？ »