Robotics 2026-10-20

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

投稿日: 2026年10月20日更新日: 2026年10月20日読了目安: 約2分

先に結論

ロボット通信を決定論的に設計するには、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側の予約やスケジュールは決まりません。

サーボやI/Oでは、通信の目的がデータ共有よりも周期的な制御交換にあります。要求ジッターが厳しいなら、専用フィールドネットワークを選ぶか、少なくともDDS通信とは独立したTSNクラスとして設計するのが妥当です。専用ネットワークとDDSを連携させる場合は、ゲートウェイ、ブリッジ、または上位アプリケーションを介して必要な状態だけを変換します。

判断では、次の項目を先に定義します。

制御周期、許容ジッター、最大許容遅延
通信量、最大フレーム長、同時に流れるトラフィック
パケット損失、再送、輻輳への許容度
障害時に停止させる範囲とフェイルセーフ動作
スイッチ、NIC、OS、DDS実装のTSN対応範囲
物理分離、VLAN、TSNクラスを運用・検証できる範囲

flowchart TD
  A["通信要求を定義"] --> B["制御周期と許容ジッターを確認"]
  B --> C{"厳しい周期・ジッター制約があるか"}
  C -- "はい" --> D["サーボ・モーション・I/Oの制御ループ"]
  D --> E{"他の通信から分離するか"}
  E -- "物理または専用経路" --> F["専用フィールドネットワーク"]
  E -- "共有Ethernet内で分離" --> G["独立したTSNトラフィッククラス"]
  C -- "いいえ" --> H["状態共有・センサ・監視・計画・診断"]
  H --> I["DDSの通信契約とQoSを定義"]
  I --> J["必要に応じてDDS over TSNを構成"]
  F --> K["ゲートウェイまたはデータ変換を設計"]
  G --> L["周期・帯域・キュー・優先度を予算化"]
  J --> L
  K --> M["エンドツーエンドで検証"]
  L --> M
  M --> N["最悪遅延・最悪ジッター・障害時挙動を確認"]

通信の周期・ジッター要求とデータの用途を起点に、共有通信とハードリアルタイム制御経路を分けて選択する。

制約と検証の進め方

TSN対応機器を並べても、エンドツーエンドの決定性が自動的に得られるわけではありません。DDS実装やROS 2のRMW実装によって、利用できるQoS、トランスポート、共有メモリ、TSN機能、NICオフロードの範囲は異なります。対象製品が802.1AS、802.1Qbv、802.1Qccなどをどこまでサポートするかを仕様書で確認します。

検証では、DDS側の通信契約を周期、帯域、最大フレーム長、優先度、Qbvゲート、キュー、再送条件へ割り当てます。そのうえで、802.1ASの同期誤差、エンドポイント処理時間、制御ループの実行時間を含め、最悪遅延と最悪ジッターを実機で確認します。

ネットワーク内の遅延上限と、制御アプリケーションが観測する周期・ジッターの上限は同じではありません。センサ入力から制御器、アクチュエータまでの経路を測定対象に含め、輻輳、時刻同期喪失、スケジュール不整合などの障害時挙動も確認する必要があります。

flowchart LR
  A["DDSの要求"] --> A1["Deadline・LatencyBudget"]
  A --> A2["Reliability・History"]
  A --> A3["データ周期・損失許容度"]

  A1 --> B["通信パラメータへ割り当て"]
  A2 --> B
  A3 --> B
  B --> B1["周期・帯域・最大フレーム長"]
  B --> B2["優先度・キュー・再送条件"]
  B --> B3["Qbvゲートと送信ウィンドウ"]

  B1 --> C["TSN・エンドポイント構成"]
  B2 --> C
  B3 --> C
  C --> C1["802.1AS同期誤差"]
  C --> C2["スイッチ・NIC・ドライバ"]
  C --> C3["OS・DDS実装・executor"]
  C --> C4["コールバック・メモリ割り当て"]

  C1 --> D["実機でエンドツーエンド測定"]
  C2 --> D
  C3 --> D
  C4 --> D
  D --> E["最悪遅延・最悪ジッター・制御ループ実行時間"]
  E --> F{"要求を満たすか"}
  F -- "はい" --> G["構成と検証結果を記録"]
  F -- "いいえ" --> H["周期・帯域・経路・実装条件を再設計"]
  H --> B

DDS QoSをTSN構成へ機械的に置き換えるのではなく、通信パラメータとエンドポイント処理を含むエンドツーエンドの測定で決定性を確認する。

まとめ

DDSを通信ミドルウェア、TSNをEthernetインフラ、専用制御ネットワークをサーボ・I/O経路の分離手段として考えると、構成を整理しやすくなります。状態共有・監視・計画はDDS over TSN、厳しいサーボ・I/Oは専用ネットワークまたは独立したTSNクラス、という分離が基本候補です。

最終判断は、制御周期、許容ジッター、帯域、障害範囲、機器の対応状況をもとに行います。決定性は単一の製品や設定から得られる性質ではなく、時刻同期、スケジュール、QoS、エンドポイント、OS、アプリケーション処理を通した検証で確認するものです。

参考情報

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。

参考にした一次情報

IEEE 802.1 Time-Sensitive Networking Task Group （paper）
IEEE 802.1AS Timing and Synchronization Task Group （paper）
IEEE 802.1Qbv Enhancements for Scheduled Traffic （paper）
IEEE 802.1Qcc Stream Reservation Protocol Enhancements and Performance Improvements （paper）
Data Distribution Service Version 1.4 （official_documentation）公開: 2022-04-01
The Real-time Publish-Subscribe Wire Protocol DDSI-RTPS Version 2.5 （official_documentation）公開: 2022-04-01
ROS 2 Documentation: About Quality of Service settings （official_documentation）公開: 2024-05-23
EtherCAT Technology （official_documentation）