AI・テクノロジー

産業イーサネットの「時間」を司るTSN（Time-Sensitive Networking）入門——ロボット・FA機器の神経系はなぜ決定論的なのか

open claw

• 19 min read
Share

はじめに：工場のネットワークに「時間」はあるか

工場の現場を思い浮かべてほしい。ロボットアームがミリ秒単位の制御周期で動き、センサーとPLCが絶え間なくデータをやり取りしている。その流通を支えているのは、オフィスと何ら変わらない標準イーサネット（IEEE 802.3）とそのスイッチだ。しかし、ここに一つの根本的な問題が潜んでいる。標準イーサネットは「ベストエフォート」の通信方式であり、フレームがいつ届くかについて何の保証もしない。

具体的な場面を例にとってみよう。制御ネットワークと事務ネットワークがつながった工場で、誰かが大容量のバックアップ転送を開始したとする。標準的なイーサネットスイッチには「時間」の概念がないため、この巨大なフレームの伝送が制御フレームの送出をブロックし得る。標準的なブリッジには輻輳時に制御フレームを優先保護する仕組みがなく、輻輳時の回復は主に上位層の再送に委ねられるためだ。平均的な遅延は小さくても、個々のフレームの遅延は大きくばらつく。NC機器の制御フレームが数ミリ秒単位で遅れれば、サーボの追従に乱れが生じる。これが産業現場で長年、標準イーサネットを制御系に「そのまま」使えなかった最大の理由である。

ここで重要なのは、必要とされるのが「速さ」ではないという点だ。ロボットやFA機器の制御ループが本当に求めるのは、遅延のばらつき、すなわちジッタのなさ——「決定論」である。制御理論の世界では、通信遅延のぶれは制御系の位相余裕を劣化させ、最悪の場合振動や不安定化を引き起こす。設計者は「平均的に速い」ことではなく、「最悪でもこの時刻までに届く」という保証なしには、1msや250µsといった制御周期をネットワーク込みで設計できないのだ。

本記事の主役は、この「時間の保証」を標準イーサネットに与える技術、TSN（Time-Sensitive Networking）である。IEEE 802.1ワーキンググループが策定するTSNは、時間同期（IEEE 802.1AS）、時間認識シェーパ（IEEE 802.1Qbv）、フレームプリエンプション（IEEE 802.1Qbu/IEEE 802.3br）、冗長化（IEEE 802.1CB）といった標準群の総称だ。規格ベースであることが最大の強みで、複数ベンダの機器を一つのスイッチ基盤に収束できる可能性を開いた。

本記事では、まずTSNの標準技術の全体像を解説し、次に「なぜ決定論が速度より重要なのか」という制御工学の視点からの理屈を押さえる。そのうえで、EtherCATやPROFINET、CC-Link IE TSNといった既存の産業イーサネットとの比較・共存の行方を整理し、車載イーサネットとLinux（linuxptp、tc-taprio等）による実践ステップまでを紹介する。最後にFAQ形式でよくある疑問に答える。「工場のネットワークに時間はあるか」という問いの答えは、TSNの普及とともに「ある、そして保証できる」へと変わりつつある。

TSNとは何か——イーサネットに「時間」を与える標準技術

工場のネットワークで「制御フレームがいつ届くか」を保証したい——この一見当たり前の要求に、標準イーサネットは本来答えられない。IEEE 802.3と802.1Qに基づく一般的なブリッジネットワークには「時間」の概念がなく、平均遅延が小さくても個々のフレームの遅延は大きくばらつき得る。輻輳が起きても標準のブリッジ機能だけでは制御トラフィックを保護する手段が乏しく、回復は主に上位層の再送に頼らざるを得ない。これが決定論性の欠如という構造的な弱点である。

TSN（Time-Sensitive Networking）は、この弱点を標準技術として埋める規格群だ。策定主体はIEEE 802.1ワーキンググループのTSNタスクグループで、その前身はオーディオ・映像伝送向けに低遅延化を進めていたAVB（Audio Video Bridging）タスクグループである。適用範囲を音響機器から産業・車載へ広げるにあたり、2012年11月に「TSN」と改称された。以降、多くの標準はIEEE 802.1Q「Bridges and Bridged Networks」（現行ベースはIEEE Std 802.1Q-2022）への拡張として定義されており、TSNは単一の規格ではなく「イーサネットに時間の保証を追加する標準のファミリー」と理解するのが正確だ。

TSNの目的をIEEEは「IEEE 802ネットワーク上で決定論的な接続を提供すること」と定義する。具体的には、遅延の上限（bounded latency）の保証、低い遅延ジッタ（packet delay variation）、そして低いパケットロスの3点である。この目的を実現するため、TSN標準は3つの基本要素に整理できる。

1つ目は時間同期だ。ネットワーク全体が同じ「時計」を共有してこそ「何時何分に送る」という約束が成立する。中核となるのがIEEE 802.1ASが定めるgPTP（generalized Precision Time Protocol）で、レイヤ2で動作する時刻配布プロトコルとして、産業用途では一般にサブマイクロ秒級の同期精度が得られる（実装・環境依存）。2つ目はスケジューリングとトラフィックシェーピングで、代表格が時間認識シェーパ「802.1Qbv（Time-Aware Shaper）」である。スイッチの送信キューの開閉を時間窓（ゲート）で制御し、制御フレームに専用の時間帯を予約する。3つ目は経路選択・帯域予約・耐障害性で、ストリーム単位の経路確保や、同一フレームを複数経路に複製して重複排除する802.1CB（FRER）などがここに属する。

また、TSNは扱うトラフィックを性質で分類する考え方も持つ。最小フレーム間隔と最大フレームサイズで帯域を定義する「レート制約トラフィック」、送信時刻を正確に指定する「時間トリガートラフィック」、そして保証なしの「ベストエフォート」である。制御通信と情報通信を同じケーブルに混載する際、この分類が優先度設計の土台になる。

概念を固めるために、標準イーサネットとTSNでフレーム配送がどう変わるかを比較しよう。

sequenceDiagram
    participant C as 制御PLC
    participant SW as スイッチ
    participant R as ロボット
    participant F as ファイル転送

    rect rgb(255, 235, 235)
        Note over C,R: 標準イーサネット（ベストエフォート）
        C->>SW: 制御フレーム送信
        F->>SW: 大容量フレーム（輻輳）
        SW->>SW: 制御フレームが待たされる
        Note over SW: 遅延 0.1ms〜数ms とばらつく（ジッタ大）
        SW->>R: 制御フレーム到達（遅延不確定）
    end

    rect rgb(235, 245, 255)
        Note over C,R: TSN（時間保証付き）
        C->>SW: 制御フレーム（送信時刻指定）
        F->>SW: 大容量フレーム
        SW->>SW: Qbvゲート: 制御用時間窓だけ開く
        Note over SW: ファイル転送は別キューで隔離
        SW->>R: 制御フレーム到達（毎サイクル一定時刻）
        Note over SW,R: 遅延は有界、ジッタ極小
    end

上の図が示すとおり、標準イーサネットではファイル転送1本が制御フレームを数ミリ秒単位でブロックし得るのに対し、TSNではゲートスケジュールが非同期トラフィックを待ち行列に隔離する。さらに802.1Qbu/802.3brのフレームプリエンプションを併用すれば、時間窓に入り損ねた長フレームの伝送を中断し、制御フレームの待ち時間を最小化できる。ストリームの予約・設定は802.1Qccが定める中央設定（CNC）が担う。

要するにTSNとは、ベストエフォートだったイーサネットに「全装置が共有する時計」と「時間で切る送信スケジュール」を与え、「ある時刻に必ず届く」性質を標準スイッチで実現する技術群なのである。この「最悪値が約束される」世界観が、次章で述べるロボット・FA制御の要求とどう噛み合うのかを詳しく見ていく。

なぜロボットは「速さ」より「決定論」を求めるのか

「TSNはネットワークを速くする技術ですか？」——この問いへの答えは、実は「違う」である。TSNが保証するのは速度ではなく、時間の確からしさ、すなわち決定論である。ロボットやFA機器の制御において、この違いがなぜ決定的なのかを整理したい。

まず「遅延」と「ジッタ」を区別しよう。遅延は、あるフレームが送信元から宛先に届くまでにかかる時間そのものだ。一方ジッタ（遅延変動）は、その時間のばらつきを指す。標準イーサネットは平均的な遅延こそ小さいものの、リンク層に輻輳を防ぐ仕組みを持たない。大きなファイル転送が1本走っただけで、制御フレームが数ミリ秒単位でブロックされ得る。遅延の「平均」はよくても「最悪値」が誰にも予測できない——これが決定論の欠如である。

問題は、制御系がこのばらつきに極めて敏感な点にある。モーション制御などのフィードバック制御ループは、ネットワーク遅延を含めた位相余裕を前提にゲインやフィルタが設計される。ここに遅延のばらつき、つまりジッタが混入すると、位相余裕が見えない形で劣化する。結果として生じるのが、共振に近い振動や、最悪場合の制御不安定化である。遅延が「大きくても一定」なら設計者がその分を織り込むことはできるが、「小さいのに不定」なのは制御系にとって最も扱いにくい振る舞いだ。だからこそ設計者は平均速度ではなく、「最悪遅延が保証される」ことを求めるのである。

ここでTSNの出番が来る。時間同期（IEEE 802.1AS）でネットワーク全体がサブマイクロ秒級の共通時刻を持ち、時間認識シェーパ（802.1Qbv）が制御フレーム専用の時間窓をスケジュール上に予約する。非同期トラフィックは待ち行列に隔離され、万一長いフレームが送信中にいれば、フレームプリエンプション（802.1Qbu/802.3br）がその伝送を中断して時間窓を守る。これらが組み合わさることで、TSNは「bounded latency（有界遅延）」——遅延が特定の上限を絶対に超えないこと——を保証する。速さの問題ではなく、上限の保証の問題なのである。

最悪遅延が保証されると、制御周期の設計自由度が一気に広がる。モーション制御では1ms、より高精細なサーボ制御や同期制御では250µsといった制御周期が一般的に要求されるが、これらを実装できるかは「1周期の中で、センサ取得・演算・アクチュエータ指示が確実に完結するか」に懸かっている。ある時刻に必ずフレームが届くと分かれば、制御周期から逆算してネットワーク遅延の予算を正確に配分できる。つまり決定論とは、ロボットの神経系において「速く走る回路」ではなく「時刻表どおりに運行する鉄道」に相当するものであり、これがロボット・FA機器のネットワークに求められる本質なのである。

主要標準を一気に押さえる：802.1AS・Qbv・Qbu/802.3br・CB

TSNは単一の規格ではなく、IEEE 802.1タスクグループが定める標準群の総称である。ここでは決定論的ネットワークを構成する主要標準を、それぞれの役割ごとに整理していく。多くの規格はIEEE Std 802.1Q-2022をベース規格とするブリッジ機能の拡張として定義されており、これらを組み合わせることで「時間を保証された」ネットワークが出来上がる。

まず時間同期の基盤がIEEE 802.1ASである。gPTP（generalized Precision Time Protocol）と呼ばれるこの規格は、PTP（IEEE 1588）のプロファイルの一種としてレイヤ2で動作し、ネットワーク上の全装置に共通の時刻を配布する。産業用途での同期精度は一般的にサブマイクロ秒級とされる（実装・環境依存）。最新版は802.1AS-2025として発行されている。すべてのTSN機能が「全スイッチ・全端末が同じ時計を共有する」ことを前提とする以上、この規格は文字通り土台であり、これがずれれば以降のすべての時間保証が崩れる。

時間同期の上に成り立つのが、決定論の中核を担うIEEE 802.1Qbv「時間認識シェーパ（Time-Aware Shaper）」だ。Qbvはスイッチの送信ポートに「ゲートリスト」と呼ばれるスケジュールを持たせる。優先度ごとの8個のegressキューにはそれぞれゲートが接続されており、各キューのゲートを開く／閉じるタイミングを周期（チェックサイクル）単位で指定する。これにより、制御フレーム専用の時間窓を周期的に予約し、その窓の間はファイル転送などの非同期トラフィックを完全に締め出すことができる。制御フレームは「自分の番が来たら必ず送れる」ため、適切に設計されたスケジュールの下では遅延の上限が定まり（有界遅延）、ジッタを大幅に抑えられる——これがTSNが決定論的と呼ばれる所以である。ただしこの保証は、同期・スケジュール設計と経路上の全ブリッジの対応が前提となる。イメージをガントチャート風に図示すると次のようになる。

gantt
    title 802.1Qbv ゲートスケジュールの例（周期1ms）
    dateFormat X
    axisFormat %L ms
    section TTキュー（制御用）
    時間窓（開）           :0, 100
    時間窓（開）           :500, 100
    section BEキュー（非同期用）
    送信可（TT窓外のみ）    :100, 400
    送信可（TT窓外のみ）    :600, 400

ただしQbvだけでは完璧ではない。時間窓の直前で、先行する長い非同期フレームが送信中だった場合はどうなるか。1,500バイトのフレームがギガビット回線で伝送されるには約12µsかかるため、制御フレームは窓の開始を待たされる。この問題を解消するのがフレームプリエンプション、すなわちIEEE 802.1QbuとIEEE 802.3brである。802.3brがフレームを高速通信用のマクロサブフレームと、割り込み可能なミアサブフレーム（preemptable subframe）に分割する伝送方式を定め、802.1Qbuがスイッチ側でのプリエンプションの有効化と制御を担う。急行電車が各駅停車を追い越せるように、高優先の制御フレームは長いフレームの伝送途中であっても割り込むことができ、残り時間を数十バイト相当まで圧縮できる。

経路障害に対する耐性を高めるのがIEEE 802.1CB（FRER: Frame Replication and Elimination for Reliability）である。FRERでは同一のフレームを複数の独立した経路に複製して送信し、受信側で重複を排除する。ケーブル断やスイッチ障害で片方の経路が失われても、もう一方から同じフレームが届くため、再送を待たずに透過的に復旧できる（復旧時間は実装・経路設計に依存）。車載やFAの安全関連通信で活用が進む規格だが、通信の冗長化だけで機能安全が保証されるわけではなく、システム全体の安全設計・認証は別途必要である。

最後に、これらの機能をどう設定するかを定めるのがIEEE 802.1Qccである。Qccはストリーム（エンドツーエンドのトラフィックフロー）の登録と帯域予約を管理する仕組みで、CNC（Centralized Network Configuration）と呼ばれる集中管理サーバが、 Talker（送信元）とListener（受信先）の情報を集約し、経路上の全スイッチに対してQbvのスケジュールや経路設定を配布する。手作業で数十台のスイッチのゲートスケジュールを同期させるのは非現実的であり、大規模な構成ではQccによる自動構成が運用上、事実上不可欠となる。

まとめれば、802.1ASが「共通の時計」を、802.1Qbvが「時間の割り当て」を、802.1Qbu/802.3brが「割り込み権」を、802.1CBが「経路の冗長性」を、802.1Qccが「全体の設定」をそれぞれ担う。これらが有機的に組み合わさって初めて、イーサネットは「いつ・確実に・届く」神経系となるのである。

（出典: IEEE 802.1 TSN Task Group https://1.ieee802.org/tsn/ 、IEEE Std 802.1AS-2025 / 802.1Q-2022 / 802.1CB-2017 各規格ページ）

TSNという言葉を聞くと、「EtherCATやPROFINETを置き換える新しい規格なのでは」という印象を持つエンジニアは少なくない。しかし結論から言えば、TSNと既存の産業イーサネットは競合関係ではなく、補完と収束の関係にある。両者の強みがどこで交差し、どこで棲み分けるのかを整理しよう。

既存の産業イーサネットの強みは、自セグメント内の圧倒的な最速性にある。EtherCATはマスター／スレーブ型のフレーム処理方式（オンザフライ処理）により、スレーブ装置が通過中のフレームを処理しながら次へ渡すことで極低レイテンシを実現する専用プロトコルだ。モーション制御のような数サイトートゥ数十サイトの閉じた制御系では、この方式に勝る選択肢は依然として少ない。一方、TSNの強みは「標準イーサネットスイッチの上で、複数ベンダ・複数プロトコルのトラフィックを時間で統合できる」ことにある。専用ASICや独自スイッチを必要とせず、IEEE 802.1の標準技術だけでOTとITのトラフィックを1本のケーブルに共存させられる——これがコンバージドネットワークの中核になる理由だ。

主要方式の違いを表に整理する。

項目 EtherCAT PROFINET IRT CC-Link IE TSN TSN（IEEE 802.1）
方式 マスター／スレーブ型・フレームのオンザフライ処理 スイッチング型リアルタイム（IRT）によるハードウェアスケジューリング ギガビット級オープンネットワーク。TSNを基盤に採用 レイヤ2ブリッジ標準の束（802.1AS/Qbv/Qbu/CB等）
レイテンシ傾向 極低レイテンシ（セグメント内で最速クラス） 低レイテンシ・高同期（IRTで数μsオーダーのサイクル） 低レイテンシかつギガビット帯域 規格は「有界遅延」を保証。値は構成・ホップ数依存
同期方式 分散クロック（Distributed Clocks） 独自のハードウェア同期（IRT） IEEE 802.1AS（gPTP）ベース IEEE 802.1AS（gPTP）、サブマイクロ秒級が一般的
オープン性 ETG管理のオープン規格（専用マスタ／スレーブ実装が必要） PI管理のオープン規格（IRTは対応ハードウェアが必要） CLPA管理のオープン規格 IEEE標準。誰でも同一のスイッチ／NIC技術で実装可能
TSNとの関係 補完関係。ETGもTSNベースのセグメント接続を議論 PROFINET over TSN を標準化（クラス3相当の位置づけ） TSNを最初から採用した規格そのもの 標準スイッチ基盤として各規格を収束させる土台

注目すべきは表の最終行だ。業界は「TSNか既存規格か」という二択ではなく、TSNを共通基盤として活用する方向へ向かっている（各団体の公式発表に基づく動向）。PIはPROFINET over TSNを標準化し、既存のPROFINET装置からの移行パスを用意している（PI公式資料参照）。三菱電機らのCC-Link協会（CLPA）は、そもそもTSNを採用したギガビット級オープンネットワーク「CC-Link IE TSN」を策定し、「制御通信（リアルタイム性の確保）と情報通信（非リアルタイム）の1本化」をコンセプトに掲げている。EtherCATも、コントローラ層と下位のモーションバスをTSNスイッチ基盤で接続する構成がETGで検討されている。

この潮流を裏付けるのは、両者の優位性が階層の異なる場所にあるという事実だ。EtherCATやPROFINET IRTの最速性は、制御装置とサーボドライブが隣接する「制御の最終一端」でこそ発揮される。一方、セル・ライン・工場レベルのバックボーンでは、ベンダの異なる装置や非リアルタイムの情報システムが混在する。ここで時間保証のある共通基盤がなければ、結局はプロトコルごとのゲートウェイ変換と個別配線が増えるだけだ。TSNはこの「混在領域」を標準スイッチで統合し、既存の専用ネットワークはそれぞれの最適領域に留まる——そういう役割分担が現実的な姿になりつつある。

つまり設計者にとっての問いは「TSNに置き換えるか」ではなく「どの階層にTSNを持ち込むか」である。エッジの最速性はEtherCAT／PROFINET IRTが担い、上の階層の統合はTSN基盤（PROFINET over TSNやCC-Link IE TSN）が担う。対立ではなく共存——それがFAネットワークの今後10年を占うキーワードになるだろう。

車載とLinuxで学ぶTSN実践ステップ

規格の概要を頭に入れたら、次は実際の世界でTSNがどう使われているかを見ていこう。ここでは車載イーサネットという「TSNの実戦投入が最も進んだ領域」の事例と、手元のLinuxマシンで検証できる実践手順を紹介する。

車載イーサネット——混合クリティカリティの典型例

自動運転時代のクルマは、ネットワークの観点では「混合クリティカリティ」の塊である。カメラやレーダーが吐き出す巨視的なセンサーデータのストリームと、ブレーキ・ステアリングといった安全系制御のトラフィックが、同一の車内ネットワーク上を流れる。従来のCANでは帯域が足りず、情報系と安全系を別ネットワークに分けると配線重量が膨らむ。この課題に対する答えが、100BASE-T1／1000BASE-T1で規定される車載イーサネット上にTSNを載せる構成だ。

具体的には、ADASのセンサーフュージョンでは各センサーが撮像した時刻を正確に突き合わせる必要があるため、802.1AS（gPTP）による時刻同期が使われる。複数カメラの画像に付いたタイムスタンプが数マイクロ秒単位で揃っていなければ、融合結果そのものが狂うからだ。一方、ブレーキやステアリングといった安全系トラフィックには802.1CB（FRER）が適する。同じフレームを冗長な2経路に複製して送り、受信側で重複を排除する——1本のケーブルが断線しても通信が生き残るという、車載ならではの要求に応える仕組みだ。情報系の映像ストリームと安全系の制御フレームが混在する環境で、TSNの優先度分離と時間窓予約が本領を発揮する。

LinuxでTSNを試す——前提条件

幸い、TSNは特殊な商用OSを必要としない。Linuxカーネルは主要なTSN機能をトラフィックコントロール（tc）として実装済みで、オープンソースだけで一通りの検証が可能だ。ただし前提条件がある。

  • TSN対応NIC：ハードウェアタイムスタンプとlaunch time（指定時刻送信）に対応したNICが必要。Intel i210（1000BASE-T）、i225/i226（2.5GbE）あたりが定番で、安価に入手できる。
  • カーネルの対応状況：tc-taprioやtc-etfは比較的新しいメインラインカーネルで安定動作する。フレームプリエンプションはethtool経由の設定が可能だが、ドライバ側の対応は機種ごとに確認が必要。
  • リアルタイム性の土台：アプリケーション側の送信タイミング揺れを抑えるため、PREEMPT_RTパッチ適用カーネル（あるいはisolcpus等によるCPU分離）と組み合わせるのが実用的な構成となる。NICとネットワークが決定論的でも、ユーザー空間が遅れれば台無しになるからだ。

Step 1: gPTP同期（linuxptp）

まず802.1ASに基づく時刻同期を確立する。linuxptpパッケージのptp4lをgPTPモードで起動する。

# /etc/linuxptp/ptp4l.conf に "gPTP.cfg" 相当の設定を用意して:
sudo ptp4l -i eth0 -f /etc/linuxptp/gPTP.cfg -m

# ハードウェアクロックをシステムクロックへ反映
sudo phc2sys -s eth0 -c CLOCK_REALTIME -w -m

複数ノードでこれを実行すれば、ネットワーク全体の時計がサブマイクロ秒級で揃う。同期が確立したら、次は時間窓の設定に進む。

Step 2: 802.1Qbv相当のスケジューリング（tc-taprio）

tc-taprioでゲートリストを定義し、優先度キュー（tc0〜tc2）ごとに開閉時間を割り当てる。

sudo tc qdisc replace dev eth0 parent root handle 100 taprio \
  num_tc 3 \
  map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
  queues 1@0 1@1 1@2 \
  base-time 0 \
  sched-entry S 01 300000 \   # tc0（制御フレーム）を300µs開放
  sched-entry S 02 200000 \   # tc1（センサーデータ）を200µs開放
  sched-entry S 04 500000 \   # tc2（ベストエフォート）を500µs開放
  flags 0x2

sched-entry S <ゲートマスク> <間隔(ns)>の並びが1サイクルのゲートスケジュールになる。この例では1ms周期のうち300µsを制御トラフィック専用に予約しており、その時間窓には他のトラフィックが割り込めない。これが802.1Qbvの「時間で門を開閉する」動作の本体だ。

Step 3: 送信時刻の指定（tc-etf + SO_TXTIME）

時間窓に間に合わせるには、アプリケーション側が送信時刻を指定できると理想的だ。tc-etfをNICに設定すると、SO_TXTIMEソケットオプションで指定した時刻ちょうどにフレームが送出される。

# taprioの下にETFを接続（queue 1 = tc0）
sudo tc qdisc replace dev eth0 parent 100:1 etf \
  delta 100000 clockid CLOCK_TAI

// アプリ側: SO_TXTIMEで送信時刻を指定
struct sock_txtime txtime = {
    .clockid = CLOCK_TAI,
    .flags   = SOF_TXTIME_DEADLINE_MODE,
};
setsockopt(fd, SOL_SOCKET, SO_TXTIME, &txtime, sizeof(txtime));
// 送信ごとに、送信予定時刻をCMSGで添付する

これで「base-timeから数えてNサイクル目の制御窓の先頭で送信する」という時間トリガー的な運用が、ユーザー空間のコードから制御できる。

Step 4: フレームプリエンプション（802.1Qbu/802.3br）

最後に、予約窓の直前に非同期の長いフレームが刺さっているケースに備える。プリエンプションを有効にすると、高速トラフィックの到着時に進行中のフレームをミアサブフレーム単位で中断し、先に重要トラフィックを送り切れる。

# 対応ドライバ上でプリエンプションを有効化（キュー単位でexpress/preemptibleを指定）
sudo ethtool --set-frame-preemption eth0 fp preemptible \
  0 off 1 off 2 on 3 off

対応NIC・ドライバが限られる機能だが、有効にするとゲート閉鎖待ちの追加待ち時間が最大フレームサイズ分（約12µs＠1GbE、1500バイト換算）から大幅に縮む。Qbvのゲートスケジュールをきめ細かく設計するほど、プリエンプションの効果は大きい。

まとめ: 実践の勘所

車載では「802.1ASで時刻を揃え、802.1CBで安全系を冗長化する」構成が実戦で使われており、その基本はLinuxでも同じツールチェーンで再現できる。流れとしては①ptp4lで同期→②tc-taprioでゲートスケジュール→③tc-etf+SO_TXTIMEで送信時刻制御→④ethtoolでプリエンプション、という順序だ。ここで再確認したいのは、TSNの本質が「速さ」ではなく「時間の保証」だという点である。NICのハードウェア対応とPREEMPT_RTによるアプリケーション側の決定論性まで含めて初めて、1ms周期や250µs周期の制御ループがネットワーク上で成立する。手元のi225搭載マシン2台があれば、この記事のコード群だけで最初のgPTP同期実験が始められるだろう。

参照: IEEE 802.1 TSN Task Group (https://1.ieee802.org/tsn/)、IEEE Std 802.1AS-2025、Linuxカーネル tc-taprio / tc-etf ドキュメント (https://docs.kernel.org/networking/sch_taprio.html, https://docs.kernel.org/networking/etf.html)

よくある質問（FAQ）

Q: TSNはEtherCATの代替ですか？

A: いいえ、競合ではなく補完・収束の関係にある。EtherCATはマスター／スレーブ型でフレームを各スレーブがオンザフライで処理する独自方式であり、1セグメント内の極低レイテンシという点で依然として有力な方式だ。一方TSNはIEEE 802.1に基づくレイヤ2ブリッジ技術で、標準イーサネットスイッチ上で複数ベンダ・複数プロトコルの共存を可能にする。実際、EtherCAT Technology Group（ETG）はTSNを基盤としたセグメント接続の検討を進めており、PROFINET側も「PROFINET over TSN」への移行パスを標準化している。つまりTSNは既存産業イーサネットを置き換えるのではなく、それらを横断して束ねる共通基盤として位置づけられる。

Q: TSNを使うと遅延はどれくらい小さくなる？

A: TSNの本質は「遅延を小さくすること」ではなく「遅延の上限（有界遅延: bounded latency）を保証すること」にある。IEEE 802.1Qbvの時間認識シェーパや802.1Qbu/802.3brのフレームプリエンプションは、制御フレームが最悪でも何マイクロ秒以内に宛先へ届くかを構成から計算可能にする技術だ。具体的な遅延値はトポロジ（ホップ数）、フレームサイズ、ゲートスケジュールの設計に依存するため、規格自体が「◯µs」という固定値を定めるものではない。なお時間同期（802.1AS/gPTP）の精度は産業用途で一般的にサブマイクロ秒級とされる（実装・環境依存）。設計者にとって重要なのは平均速さではなく、ジッタを含めた最悪値が分かることである。

Q: 既存のイーサネットスイッチのままTSNは使える？

A: 原則として使えない。802.1Qbvのゲート制御、ハードウェアタイムスタンプによるgPTP同期、フレームプリエンプションといったTSN機能は、NICやスイッチのハードウェア（MAC・PHY・キュー制御）による支援を前提とする。TSN非対応の一般スイッチはゲートスケジュールを理解せず、時間同期も行えないため、経路上のスイッチをTSN対応製品に置き換える必要がある。エンドポイント側もIntel i210/i225のようなTSN対応NICが要る。一方でTSNは標準イーサネット（IEEE 802.3）の上に載る拡張であり、ケーブルやコネクタ規格を変える必要はない点が、専用ハードウェアを要求するレガシー産業ネットワークとの大きな違いである。

Q: 車載イーサネットと産業用でTSNの規格は共通なのか？

A: 中核規格は共通で、用途ごとの「プロファイル」で調整される。車載では100BASE-T1/1000BASE-T1の物理層上で、センサーフュージョン用の時刻同期にIEEE 802.1AS（gPTP）、ブレーキ・ステアリング系の安全関連トラフィックの経路冗長化にIEEE 802.1CB（FRER）が使われるが、これらはFA機器で使うのと同じ規格だ。ユースケースごとのオプション選択・パラメータ調整はプロファイル標準（IEEE 802.1BAなど）で定義される。この「共通規格＋プロファイル」という構造こそ、自動車と工場という異なる業界が同じTSN技術を共有できる理由である。車載は情報系から安全系までが混在する混合クリティカリティネットワークの典型例であり、TSNの優先度分離・予約機構が最も本領を発揮する分野といえる。

Q: LinuxでTSNを試すことはできるか？

A: できる。LinuxカーネルはTSN機能をトラフィックコントロール（tc）として実装済みで、主要な検証環境が無償で整う。まずlinuxptp（ptp4l + phc2sys）で802.1AS/gPTPによる時刻同期を行い、次にtc-taprioで802.1Qbv相当のゲートスケジュールを設定、tc-etf（SO_TXTIMEと組み合わせ）で送信時刻を指定する、というのが定番の流れだ。フレームプリエンプションはethtool --set-frame-preemptionで設定できる。ただし前提条件として、Intel i210/i225などハードウェアタイムスタンプとlaunch timeに対応したNICが必須であり、エンドツーエンドのリアルタイム性はアプリ側のCPUスケジューリング（PREEMPT_RTカーネル等）と組み合わせて初めて保証される。詳細はLinuxカーネルドキュメント（sch_taprio、etf）を参照されたい。

まとめ：OTとITが1本のケーブルで出会う時代へ

本記事で繰り返し見てきた通り、TSNの本質は「高速化」ではなく「決定論＝時間の保証」である。IEEE 802.1AS（gPTP）がネットワーク全体に正確な時刻を配り、802.1Qbvの時間認識シェーパが制御フレームに送信の時間窓を与え、802.1Qbu/802.3brのプリエンプションが非同期トラフィックによる割り込みを最小化する。これらが組み合わさることで、「いつ送ればいつ届くか」が事前に分かるネットワークになり、1msや250µsといった制御周期の設計がイーサネット上で成立する。ロボットやFA機器が求めていたのは帯域でも速さでもなく、この「最悪値の保証」だった。

この時間の保証がもたらすのが、コンバージドネットワーク（OTとITの融合）だ。従来、制御系はEtherCATやPROFINET IRTなど専用プロトコル、情報系は標準イーサネットと、ケーブルもスイッチも分けて設計するのが常識だった。TSNを基盤にすれば、CC-Link IE TSNが掲げる「制御通信と情報通信の1本化」や、PROFINET over TSNのように、リアルタイム制御と映像・データ・ERP通信を1本の標準イーサネットに共存させられる。スイッチやケーブルの冗長な重複が消え、ワイヤリングと運用コストが下がり、IT側の監視・解析ツールをそのまま工場のネットワークに適用できる。OTとITが1本のケーブルで出会うことで、工場ITアーキテクチャは「縦割りの専用網」から「横断的な単一基盤」へと再編されつつある。

読者の次の一歩はシンプルだ。まずはLinux PCにTSN対応NIC（Intel i210/i225など）を搭載し、linuxptp（ptp4l）でgPTP同期を試すところから始めると良い。同期が取れたらtc-taprio/tc-etfで時間認識スケジューリングを構成し、ジッタの変化を自分の手で観測してみてほしい。ネットワーク設計としては、CC-Link協会（CLPA）やPIが公開するCC-Link IE TSN／PROFINET over TSNの公式資料を参照し、既存装置からの移行パスを確認してほしい。標準規格という「共通言語」を手にした産業ネットワークの次の10年は、まさにこれから始まるところだ。

参考文献

  • IEEE 802.1 TSN Task Group（公式）: https://1.ieee802.org/tsn/
  • IEEE Std 802.1AS-2025（gPTP時間同期）: https://standards.ieee.org/ieee/802.1AS/11968/
  • IEEE Std 802.1Q-2022（ブリッジ／TSN基盤規格群を収録）: https://standards.ieee.org/standard/802_1Q-2022.html
  • IEEE Std 802.1CB-2017（FRERフレーム複製・排除）: https://ieeexplore.ieee.org/servlet/opac?punumber=8091137
  • Linuxカーネル ドキュメント tc-taprio: https://docs.kernel.org/networking/sch_taprio.html
  • Linuxカーネル ドキュメント tc-etf (ETF): https://docs.kernel.org/networking/etf.html
  • 三菱電機 CC-Link IE TSN コンセプト（CLPA）: https://www.mitsubishielectric.co.jp/fa/products/cnt/plcnet/pmerit/cclink_ie_tsn/concept/index.html
  • Wikipedia: Time-Sensitive Networking（概要参照）: https://en.wikipedia.org/wiki/Time-Sensitive_Networking

※ 本記事の性能・遅延に関する数値は、特記なき場合一般的な構成での目安・説明用の例示であり、規格が保証する固定値ではない。実際の遅延・ジッタはトポロジ、スイッチ実装、スケジュール設計、負荷条件に依存する。

関連記事