ジッター on Physical AI Hub

ロボット通信の決定論設計：TSN・DDS・制御ネットワークの役割分担

Tue, 20 Oct 2026 13:36:07 +0900

先に結論

ロボット通信を決定論的に設計するには、TSN、DDS、専用制御ネットワークを同じ機能として扱わず、層と責任範囲を分けます。DDSはデータモデルと通信契約、TSNはEthernet上の時刻同期・送信スケジュール・帯域制御、専用制御ネットワークはサーボやI/Oなど厳しい制御経路の分離を担当させます。

センサ、状態共有、計画、監視、診断はDDS over TSNの候補です。一方、周期やジッターの制約が厳しいサーボ・モーション通信は、EtherCATなどの専用フィールドネットワーク、またはDDS通信から独立したTSNトラフィッククラスに分けます。ただし、TSNやDDS QoSを設定しただけで、アプリケーションから見たエンドツーエンドの決定性が保証されるわけではありません。

なぜ層の分担が必要なのか

ロボットでは、センサから処理器、制御器、アクチュエータへデータが届くまでの遅延とジッターが動作に影響します。ネットワーク内の送信が予定どおりでも、NIC、ドライバ、OSスケジューラ、DDS実装、executor、コールバック処理、メモリ割り当てなどが遅延要因になり得ます。

したがって、「DDSを使えばリアルタイムになる」「TSNを導入すれば制御周期が保証される」と単純化するのは危険です。先に制御周期、許容ジッター、最大遅延、損失への許容度を定め、その要求を各層の設定と実機検証へ割り当てます。

前提となる用語

TSN

TSNは単一のプロトコルではなく、IEEE 802.1を中心とする標準群です。802.1ASはブリッジドネットワーク内の時刻同期、802.1Qbvは時間に基づくゲート制御によるスケジュール通信、802.1Qccはストリームの予約や構成を扱います。必要に応じてキュー制御やフレームプリエンプションも組み合わせます。

TSNは主にEthernetのスイッチ、ブリッジ、NICなどのインフラ側で、共通時刻を使い、通信をどのタイミングでどのキューから送るかを制御します。

DDS

DDSはデータ中心のpublish/subscribe型ミドルウェアです。Reliability、History、Deadline、LatencyBudget、LivelinessなどをQoSポリシーとして表現し、データの更新契約やミドルウェアの振る舞いを定義します。ROS 2のDDSベース通信でも、PublisherとSubscriberのQoS互換性が通信可否に影響します。

一方、DDSのDeadlineやLatencyBudgetは、単独で物理ネットワークの帯域予約や802.1Qbvのゲート制御リストを設定するものではありません。DDSI-RTPSなどの転送はIP/Ethernet上で動作し、TSNはその下位のネットワークインフラとして位置づけます。

専用制御ネットワーク

専用制御ネットワークはOSIの特定の一層ではなく、サーボ、モーション、I/Oの通信を他のトラフィックから分離するアーキテクチャ上の選択です。物理的に別ネットワークへ分ける方法、VLANやTSNトラフィッククラスで論理分離する方法、EtherCATのような専用フィールドネットワークを使う方法があります。

内部の仕組みと構成

基本構成では、アプリケーションが扱うデータ型と通信契約をDDSに置き、DDSI-RTPSなどの転送をIP/Ethernet上で動かします。その下でTSNが共通時刻、送信スケジュール、ストリーム、キューを管理します。

まず802.1ASなどでネットワーク内の共通時刻を整え、通信周期や送信ウィンドウに合わせてQbvのゲート制御を構成します。必要に応じてストリームの予約や構成も行います。スケジュールはスイッチだけで完結せず、TSNブリッジやエンドポイントの設定にも依存します。

サーボ経路をDDSと同じ共有ネットワークへ載せる場合は、周期、帯域、最大フレーム長、キュー、優先度、再送や輻輳時の挙動を個別に予算化します。要求が厳しい場合は、専用フィールドネットワークか独立したTSNトラフィッククラスとして、DDSの輻輳や構成不整合の影響範囲を抑えます。

flowchart TB
  subgraph APP["ロボットアプリケーション"]
    S["センサ・状態共有・監視・計画・診断"]
    C["サーボ・モーション・I/O制御"]
  end

  subgraph DDSL["DDS通信層"]
    DM["データモデルと通信契約"]
    Q["QoS: Deadline・Reliability・History・LatencyBudget"]
    RTPS["DDSI-RTPS"]
  end

  subgraph TSNL["TSN対応Ethernet層"]
    TIME["802.1AS 共通時刻"]
    SCHED["802.1Qbv スケジュール・ゲート"]
    RES["ストリーム予約・キュー制御"]
    NET["TSNブリッジ・スイッチ・NIC"]
  end

  subgraph FIELD["専用制御経路"]
    FC["専用フィールドネットワーク"]
    IO["サーボ・アクチュエータ・I/O"]
  end

  S --> DM
  DM --> Q
  Q --> RTPS
  RTPS --> NET
  TIME --> NET
  SCHED --> NET
  RES --> NET
  NET --> S

  C --> FC
  FC --> IO
  FC -. "状態・監視データを必要に応じて変換" .-> DM

  NOTE["DDSのQoS設定だけでは、TSNの帯域予約やQbvゲート制御は自動的に決まらない"]
  Q -.-> NOTE
  NET -.-> NOTE

DDSはデータモデルと通信契約、TSNはEthernet上の時刻同期と送信制御、専用制御ネットワークは厳しい周期・ジッター制約の制御経路を担当する。

選択肢の比較

対象	主な役割	向いている通信	主な確認事項
DDS	データモデル、publish/subscribe、通信契約	状態共有、センサ、監視、計画、診断	QoS互換性、実装、再送や輻輳の挙動
DDSI-RTPS／IP/Ethernet	DDSデータのネットワーク転送	DDSトピックの配送	経路、最大フレーム長、下位ネットワークとの整合
TSN	時刻同期、送信スケジュール、帯域・キュー制御	周期性が必要な共有通信、独立した制御クラス	スイッチ・NIC対応、同期誤差、スケジュール
専用フィールドネットワーク	サーボ、モーション、I/Oの分離	厳しい周期・ジッター制約の制御ループ	ゲートウェイ、障害範囲、DDSとのデータ変換

使いどころと判断基準

状態共有、監視、計画、診断のように、データ中心の接続性と柔軟な購読関係が重要な通信ではDDSが適しています。DDS over TSNを採用する場合は、Deadline、LatencyBudget、Reliabilityなどを、TSNの周期、ゲート、帯域、キュー、最大フレーム長へ具体的に割り当てます。QoS名を設定するだけでは、TSN側の予約やスケジュールは決まりません。

リアルタイムなロボットAI基盤：推論・制御・通信の実行予算を設計する

Sun, 14 Jun 2026 01:15:54 +0900

AI推論のベンチマーク値だけで、ロボット全体のリアルタイム性を判断できるのかが気になるテーマです。

先に結論

ロボットのAI処理に、制御30%、推論50%といった普遍的な固定比率はありません。先に制御ループの期限を予約し、センサー入力、アクチュエータ出力、ROS 2通信、スケジューリング干渉、安全余裕を見積もります。その残りをAIに割り当てるのではなく、AIにも独立した周期と期限を設定し、制御が推論の完了を同期的に待たない構成にするのが基本です。

判断には平均推論時間ではなく、前処理、メモリ転送、GPU実行、同期、後処理、ROS 2メッセージ処理まで含むエンドツーエンドのp99.9、最大値、ジッター、期限超過率を使います。AIが期限に間に合わない場合は、直近の有効な結果を使うか、安全なフォールバックへ切り替えます。

なぜ実行予算が必要か

ロボットでは、平均的に速い処理より、まれな期限超過をどう扱うかが重要です。AIが通常は短時間で完了しても、CPUやGPU、メモリ帯域、ドライバ、ログ処理などの競合で一部の周期が遅れれば、制御の決定性は崩れます。実行予算は、周期や締切の中で各処理が使える時間を明示するための枠組みです。

ハードリアルタイム経路では、処理時間の上限を見積もり、動的メモリ割り当て、ページフォールト、無制限に待つロック、非リアルタイムなシステムコールを避けます。これらは平均値には表れにくい遅延要因です。

前提となる仕組み

ROS 2のExecutorは、待機集合から実行可能なサブスクリプション、タイマー、サービス、アクションなどを取り出してコールバックを実行します。SingleThreadedExecutorは単一スレッド、MultiThreadedExecutorは複数スレッドを使います。ただし、一般的なExecutorはハードな優先度順やFIFO実行を保証しません。

Callback Groupには、同時実行を制限するMutually Exclusiveと、同時実行を許すReentrantがあります。これはコールバック間の関係を制御しますが、設定だけで締切やリアルタイム性が保証されるわけではありません。

QoSにはReliability、History、Deadline、Lifespan、Livelinessなどがあります。通信の信頼性、キュー保持、更新期限、データ鮮度を設計できますが、QoSのDeadlineはデータ更新を監視する機能であり、Executorのコールバック開始時刻や処理完了時刻を保証するものではありません。

予算の分け方

まず制御周期を定め、次の順で予算を予約します。

制御計算、センサー入力、アクチュエータ出力
リアルタイム通信処理
スケジューリングや共有資源による干渉
安全・ジッター余裕
AIの前処理、推論、後処理

AIを制御周期の「残り時間」に詰め込むと、推論遅延が制御期限を直接圧迫します。制御スレッドまたはリアルタイム向けExecutorはAIの結果を待たず、利用可能な結果の鮮度を確認して使う構成にします。AIの前処理やROS 2通信は別の実行資源に分け、GPU推論は可能な範囲で非同期に投入します。

設計上の仮置きとして、100 Hz、10 ms周期なら、制御とI/Oを2 ms、ROS 2通信処理を1 ms、AIのエンドツーエンド処理を6 ms、安全・ジッター余裕を1 msと置けます。ただし、これは標準値でも推奨値でもありません。対象のCPU、GPU、モデル、I/O、ROS 2構成を測定して再設定する必要があります。

flowchart LR
  subgraph CYCLE["100 Hz・10 ms周期の仮置き例"]
    CTRL["制御・I/O\n2 ms"] --> COMM["ROS 2通信処理\n1 ms"]
    COMM --> AI["AIエンドツーエンド処理\n6 ms"]
    AI --> MARGIN["安全・ジッター余裕\n1 ms"]
  end
  SENSOR["センサー入力"] --> CTRL
  AI -->|"期限内に取得"| FRESH["鮮度を確認して\n制御で利用"]
  AI -->|"期限超過"| FALLBACK["直近の有効値\nまたは安全なフォールバック"]
  FRESH --> ACT["アクチュエータ出力"]
  FALLBACK --> ACT
  CTRL -.->|"AIの完了を同期的に待たない"| FRESH

制御とI/O、通信、安全余裕を先に確保し、AIを独立した期限で実行する予算設計の仮置き例。2・1・6・1 msは推奨標準値ではなく、対象ハードウェアでの計測後に再設定する。

何を測るべきか

AIの計測点は、センサー取得、ROS 2受信、前処理開始、ホストからデバイスへの転送、GPUカーネルの開始・終了、同期、デバイスからホストへの転送、後処理、制御入力、アクチュエータ出力です。GPU処理は非同期に実行できるため、推論APIの呼び出し時間だけでは実際の完了時間を表しません。