リアルタイム・イーサネット（産業用イーサネット）は、ここ数年の間に急速に普及しました。旧来のフィールドバスは現在も広く使われていますが、その全盛期は過ぎ去ったと言えます。イーサネットの規格は、リアルタイム機能の要件に適合するよう拡張されてきました。その結果、策定されたのがリアルタイム・イーサネット向けの各種プロトコルです。また、現在ではリアルタイム・イーサネットを実現するための新たな手段として、IEEE 802.1 TSN（Time Sensitive Networking）という標準規格も策定されました。
リアルタイム性に対するニーズ
FAやモーション制御などの分野では、リアルタイムという言葉は、高い安全性と信頼性を確保しながら数十ミリ秒から数マイクロ秒までのサイクル・タイムを達成するということを意味します（図1）。イーサネットによる通信において、そうしたリアルタイム性に対する要件を満たすには、それに向けたリアルタイム機能を盛り込む必要があります。
フィールドバスよりも高速なイーサネットが抱える課題
FAシステムにおいてリアルタイム性の要件を満たすには、伝送帯域幅と遅延の値について保証する必要があります。ほとんどの状態で帯域幅が明らかに狭い（デバイスあたり数十バイト）といった場合でも、伝送チャンネルは、遅延に関する要件を満たしつつ、I/Oのサイクルごとに利用できる状態になるようにしなければなりません。
しかし、もともとのイーサネット（クラシック・イーサネット）は、遅延と帯域幅については保証していません。それどころか、イーサネットをベースとするネットワークは、適切な動作のために必要であれば、いつでもフレームを破棄する可能性があります。以下、この点について説明しておきます。
イーサネットを使用する場合、いわゆるブリッジ型のネットワークを構成することになります。そして、1つのポイントから別のポイントへとフレーム（イーサネット・フレーム）が送信されます。フレームはエンドポイントからスイッチ（ブリッジ）へ送信された後、恐らくは別の複数のブリッジを経由して最終的に別のエンドポイントに到達します。このアーキテクチャは、ほぼ自己構成の仕組みに基づいています。ブリッジは、フレームを完全に受信してから転送します。ここで、以下に示す複数の問題が生じます。
- ブリッジのバッファ用メモリに格納しきれないほどのフレームが到達するピーク時には、新しく送られてきたフレームは破棄されます。
- フレームによって長さが異なり、フレームの遅延はその長さに依存します。これによって、遅延の値にばらつきが生じます（ジッタ）。
- スイッチがフレームの送信に使おうとしたポートが、フレーム・サイズいっぱいまで他のフレームに既に占有されている場合には、更に遅延が生じます。大きなイーサネット・フレーム（1522バイト）の送信には、伝送レートが100Mbpsの場合で約124マイクロ秒の時間を要します。
イーサネットは、正常時には適切に動作し、ほぼ公平に処理を行うと言えます。しかし、ハード・リアルタイムでの接続においては、それでは意味がありません。正常時だけリアルタイム性が確保されても十分ではないのです。リアルタイム性は常に満たされる必要があります。
化学工場や製油所の隣に住む人であれば、その意味を容易に理解できるはずです。産業用の通信も公平ではありません。制御アプリケーションやクローズドループ制御アプリケーションを最も重要なものだと位置付け、それらを必ず優先するからです。
リアルタイムに対応するための拡張の仕組み：PROFINETとEtherCATの例
イーサネットの標準化を担うIEEEからは、上述した課題に対する解決策は提供されていませんでした。そのため、業界では、それぞれに革新性を主張する独自のソリューションが開発されるようになりました（図3）。各ソリューションは、それぞれ異なる市場をターゲットとしており、それぞれに長所と短所があります。
PROFINET：広く適用可能なプロトコル
PROFINETでは、2つの相補的なソリューションを提供しています。その1つであるPROFINET RTは、サイクル・タイムが1ミリ秒までのFA向けソリューションです。このプロトコルは、標準のイーサネットを直接的な基盤としています。サービス品質（QoS）や優先度など、イーサネットの潜在的な可能性を活用し、リアルタイムのトラフィックを優先します。QoSはある程度有効な手法ですが、リソースと遅延の問題を完全に解決できるわけではありません。そのため、このプロトコルの適用レベルはソフト・リアルタイムに限定されます。ネットワークで使用される他のプロトコル（HTTP、SNMP、TCP/IPなど）との相互運用性に優れていることが、この技術が備える明確な長所です。
ハード・リアルタイム向けに提供されているもう1つのプロトコルが、PROFINET IRT（Isochronous Real-Time：等時性リアルタイム）です（図4）。このプロトコルを介して標準のイーサネットに対応するハードウェアに伝送されるIRTトラフィックに向けては、それ専用にイーサネットの帯域幅の一部があらかじめ確保されます。これは、IRTノード間で正確なクロック同期がとられることによって実現されます。その結果、すべてのサイクルにおいて、1つのチャンネル（赤のフェーズ）から通常のトラフィックを排除することができ、赤のフェーズのIRTフレームだけがネットワークに到達します。加えて、ネットワークの構成要素は、あらかじめ計算された正確な時間にIRTフレームを送信します。そのため、赤のフェーズの効率が最大化されます。IRTフレームは、ほぼ遅延を伴うことなくネットワーク上で伝送されます。このプロトコルの長所の1つは、他の全トラフィックを待機させなければならない赤のフェーズの長さが最小限に抑えられることです。赤のフェーズは、イーサネット・チャンネルの帯域幅のうち、最大50%までしか占有することはありません。
先述したとおり、最大長（ 1552バイト） のイーサネット・フレームの転送には、約124マイクロ秒の時間がかかります。PROFINET IRTにおいて、フレームが上限値である帯域幅の50%を占めているとすると、最速のサイクル・タイムは2 × 124で248マイクロ秒、四捨五入して250マイクロ秒になります。この方法によってのみ、他のプロトコル（HTTPなど）は変更を加えることなく共存できます。
なお、IRT向けに最適されたPROFINET 2.3では、高速のフォワーディング、フレームの動的なパッケージング、フラグメンテーションなどにより、サイクル・タイムを31.25マイクロ秒まで短縮することができます。
EtherCAT：イーサネット・ベースのフィールドバス
EtherCATは、もともとは他の要件を念頭に置いて開発されたものであり、イーサネットの物理層（レイヤ1）をベースとするフィールドバスです。レイヤ2は、フィールドバスのアプリケーションと高いスループットを念頭に置いて最適化されています。EtherCATには、クラシック・イーサネットのブリッジは存在しません。特にデータ伝送の効率を高めるために、サメーション（総和）フレーム・テレグラムが用いられます。通常のイーサネットでは、各デバイスが個々にフレームを送信することによって、デバイス間の通信が行われます。それとは異なり、EtherCATでは、サイクルごとに1つのフレームが送信されます。ただ、そのフレームには、対象となる複数のデバイス向けのすべてのデータが含まれています。EtherCATフレームは、特定のデバイスによって転送されます。同フレームには、そのデバイスに対応するデータが挿入されています。それらのデータがその場でフレームから取り出されます。このような仕組みにより、状況によっては、31.25マイクロ秒よりも更に短いサイクル・タイムを達成できます。
EtherCATでは、時間同期の処理も行われます。必ずしも理想的だとは言えないPCのイーサネット用インターフェースをEtherCATのマスタとして使用できるようにするために、かなりの工夫が加えられています。
ウェブに対するトラフィックやTCP/IPのトラフィックなど、イーサネットのトラフィックは、EtherCAT上では少量ずつピギーバック方式を適用することでしか伝送することはできません。言い換えると、配線上でそのままそれらのプロトコルを共存させることはできません。
その他のプロトコル
基本的な部分でEtherCATと同じアプローチを採用しているプロトコルにPOWERLINKがあります。イーサネットを完全に制御し、ピギーバック方式でIPアプリケーションのデータをノードに伝送します。但し、両者の共通点はそれだけです。POWERLINKはサメーション・フレーム・プロトコルは採用していません。両プロトコルを採用した現実のアプリケーションの性能はほぼ同等です。
Sercosは、IRTと同様に帯域幅をあらかじめ確保しますが、内部ではサメーション・フレーム・プロトコルを使用します。Sercosは、他のプロトコルとの共存が可能です。
TSNの時代へ
IEEEは、AVB（Audio Video Bridging）プロトコルの範囲内で、リアルタイム対応の問題に取り組みました。このプロトコルを改善する中で、より難易度の高い産業用途向けのリアルタイム通信に関する検討も行われました。そうした経緯から、一連の規格の名称が当初のAVB2からTSNに変更されました。現在では、TSNによって、イーサネットをベースとするデタミニスティックな手法が標準技術として利用できるようになりました。
実際、TSNによって多くの問題が緩和されます。例えば、よく知られた産業用ネットワークは、いずれも100Mbpsの伝送レートを前提として定義されています。しかし、現在注目を集めているのは、やや特殊なアプリケーションで使用されるギガビット・イーサネットや10Mbpsのイーサネットです。TSN以外の既存の規格では、ギガビット・イーサネットに対応するためには仕様の再定義を行う必要があり、ハードウェアの開発コストもかさみます。このことは、市場の分断化にもつながります。一方、TSNであればあらゆる伝送レートに対応するので、基盤の部分から構築し直す必要はありません。
TSNがもたらすメリット
TSNでは、イーサネットのレイヤ2を拡張することにより、リアルタイム動作に必要な一連のメカニズムが追加されています。その特徴を以下に示します。
- IEEE 802.1AS/802.1AS-Revにより、ネットワークにおける非常に高精度なクロック同期が実現されます。
- オプションのTAS（Time Aware Shaper）により、イーサネットをハード・スケジューリングで動作させることができます。その結果、QoSモデルの1つ以上のキューを特定の時間に遮断／開放することが可能になります。
- オプションのプリエンプション（IET：Interspersing Express Traffic）により、長いフレームを小さく分割し、優先度の高いフレームの遅延を最小限に抑えることができます。TASのガード・バンドの最適化に使ったり、伝送レートが100Mbpsを超える用途でTASの代わりに利用したりすることが可能です。
- 信頼性の確保を目的として、オプションでフレームの複製／削除が行えます。それにより、リング型ネットワークなどで冗長パスを定義することが可能になります。
- ソフトウェア定義型のネットワークを使用すると、宛先までのフレームの転送には、宛先のノード（ハードウェア）のMACアドレスではなく、特別なMACアドレス（ ローカルで管理されるマルチキャストMAC）とVLAN IDの組み合わせが使用されます。これらのフレームをどのようにしてネットワーク上でルーティングするかは、自動的に決まるのではなく、ソフトウェアによって設定されます。マルチキャストMACとVLAN IDの組み合わせは、ストリームIDと呼ばれます。そして、同じストリームIDを持つすべてのTSNのフレームをTSNストリームと呼びます。TSNストリームの送信ノードは必ず1つですが、受信ノードは複数存在する場合もあります。
TSNストリームは、フレームを破棄しなくても済むように、既存のリソースを考慮して設定できます。ブリッジはそれぞれのリソースを使用し、TSNフレームを損失させることなく転送します。
ベスト・エフォート型のトラフィック（標準のイーサネット、IP、ウェブ）は、残りのリソース（メモリ／帯域幅）を使って通常どおりに処理されます。
レイヤ2よりも上の層に及ぶ影響
イーサネットをベースとするプロトコルは数多く策定されました。各プロトコルについては、その標準化と普及を推進する組織が存在します。各組織は、それぞれの考え方に基づいて、TSNに対応するための戦略を立てています。そのため、TSNが導入されても、既存のプロトコルのほとんどは使用され続けることになるでしょう。本稿で取り上げたプロトコルについては、TSNに対して以下のような対応が図られています。
PROFINETの場合、TSNへの対応は比較的容易です。TASに関する経験が豊富で（IRTで既によく似た機能が実装されています）、産業用プロトコルとIT用プロトコルの共存が既に実現されているからです。ユーザから見れば、従来とほぼ変わりない環境で新たな性能を享受できることになります。
EtherCATとSercosでは、フィールド・レベルよりも上の階層でTSNにアクセスできるようになる予定です。例えば、EAP（EtherCAT Automation Protocol）は、従来のEtherCATのセグメントを、小さいオーバーヘッドでTSNを介してネットワークに接続する上で非常に適しています。
ただ、上記のプロトコル以外にも、全く新たな産業用イーサネット・プロトコルを定義している団体が存在します。
例えば、OPC UAはアプリケーション層として使用されています。TSNは、このプロトコルをリアルタイム対応にするための手段であると見なされています。しかし、これについてはまだ追加の作業が必要です。伝送のためには、OPC UAの新たなトランスポート層（いわゆるOPC UA Pub/Subプロトコル）が必要になります。
高速ネットワークでもリアルタイム規格は必須
現在、産業分野のオートメーション・システムでは、主に100Mbpsのイーサネットが使われています。それらは、間もなくギガビット・イーサネットへと移行することになるでしょう。しかし、高速化が進めば自動的に確実な伝送や小さな遅延が保証されるというわけではありません。ハード・リアルタイムの実現に向けては、そのためのメカニズムが必ず求められます。TSNは、そうしたメカニズムを標準化するために定められた規格です。
