この記事は EtherCATについて語る Advent Calendar 2019の24日目です。
昨日は無知の知 OSIモデルで EtherCAT を考察する（前編）でした。今日はその後編です。

EtherCAT は物理層とデータリンク層に Ethernet を準用しています。EtherCAT の規格が定める様々な機能はOSIのより上の層での概念で語られるものが多いと思います。OSI で考えるとどんな機能が欲しくなるのか、考察してみます。

なお、前回同様、大して EtherCAT を知っているとは言えない状態であれこれ推察するので、実は規格に入っていたというようなこともあろうかと思います。それを見つけたときはそっと教えて下さいませ。

EtherCAT の機能を OSI モデルで見てみる

では EtherCAT をネットワーク層から見ていくことにします。

ネットワーク層 (Layer 3, Network Layer)

データリンク層は「直接繋がって通信できる相手」での通信を定めます。ネットワーク層は直接繋がっておらず間接的に接続されているノード間での通信を可能にする機能を提供する層です。

Ethernetはデータリンク層のプロトコルを定義しておりLAN (Local Area Network) の概念を提供します。一方、IPはネットワーク層のプロトコルで、IPアドレスの概念と経路制御の概念を提供します。これによりIPを使うと異なるLAN同士での通信が可能になります。

EtherCAT の場合、IPで言うようなネットワークの広がりというのを期待されているのではないと思います。Ethernet の上にシンプルな構造を加えることで優れた産業用の制御用プロトコルを提供するのが目的でしょうから、あまり複雑にすると元も子もなくしてしまいそうに思います。なのでネットワーク層としての機能がそう強く求められてるとは思えません。

ただし、ネットワーク層で大事な概念には論理的なアドレス空間を提供するという機能があります。Ethernet アドレスは48bitのうち上位24bitがベンダアドレスで下位24bitがベンダごとに製品に定められるアドレスで、いわば物理的な個体を表します。IPアドレスは、ネットワークを人まとまりにすることで、論理的なアドレスを提供します。

この論理的なアドレスを提供するというのが大事で、ごく小規模なネットワークなら個体番号や線形に接続されている順番でノードを識別するのでも困りませんが、ちょっと大きくなるとあっという間に破綻します。設計も保守も構成変更もままならなくなるでしょう。さらに、Ethernet アドレスを個体識別番号として使うと EtherCAT の場合は2つ存在するどちらを使うのかという問題も出てしまいます。

論理アドレスを持つには、どこかに論理アドレスと物理アドレスを紐付ける機能が必要になります。これをどの様に実現していくかは EtherCAT の利便性の一つの鍵になるのかなと思っています。わたしの知る限りでは素朴な機構しか提供されていないようで、一工夫ですごく使いやすくなるのではないかと考えています。

さらに DNS (Domain Name System) のような仕組みが持てれば便利この上ないでしょう。IP アドレスの様な L3 の論理アドレスは経路制御に使うための数値なので、論理的と言ってもまだ人間には扱いにくいです。IPv4 の32bitぐらいなら良いですが、IPv6みたいに128bitもあるととても覚えきれないのと同様です。名前 ⇔ 論理アドレス ⇔ Ethernet アドレス×2 というマッピングを持つことができると EtherCAT による制御システムがスケールするようになるでしょう。

トランスポート層 (Layer 4, Transport Layer)

ネットワーク層では一度に運べる情報の大きさに限界があります。パケットとかデータグラムと呼ばれる単位で情報を運ぶのが前提です。また、ネットワーク層ではパケットがお行儀良く振る舞うことを保証しません。パケットが消失したり重複したり、発信の順序とは異なる順序で受信されたりすることもありえます。これはいわば信頼性の低い状態です。

トランスポート層はパケット長より長いデータを扱うことや、信頼性の高い通信を実現する機能を定めます。信頼性が高いとは、発信した情報がそのままの状態で受信されることです。

TCP はこの機能を持っており、送受信する際にIPのパケット長を意識しなくても好きな長さの情報を送ることが出来ます。また、信頼性の低いパケットの伝送を補償する機能を持っていますので、パケロスなども基本的には気にしないでプログラムすることができます。

EtherCAT では、EtherCAT で言うところのデータグラムの単位で情報を運ぶことになっており、任意長の情報を運ぶような構造にはなっていません。いわばデータグラムでの情報伝送上にどのように全体の情報を乗せていくのかは設計者に任されています。現状で想定している EtherCAT の使い方なら、このデータグラム内に1回に伝送が必要なデータを埋め込むように設計するでしょう。

また、EtherCAT は基本的には Ethernet フレームの消失や重複や順序逆転を意識しなくて良いですから、信頼性をさらに確保するような機能も必要ないです。

もし、トランスポート層としての役割が必要になるとすると、EtherCAT が普及して、従来の制御の情報だけでなく、より多彩な情報を運ばせようという状況になったときかと思います。その場合、固定長データグラムでは賄いきれない部分は設計者と言うかプログラマに任されることになります。その場合でも広く安定的に EtherCAT を利用してもらい続けるとなると、EtherCAT 側でトランスポート層の機能を提供する必要がでてくるでしょう。

セッション層 (Layer 5, Session Layer)

トランスポート層までは、ネットワーク上のあるノードとノードとの通信の概念しかありませんでいた。ノードの中にいくつもの機能が準備されてて、それのどれと通信するのかという概念はセッション層で定義します。UNIX でいうとどのプロセスと通信するのか、どのサービスにコネクションするのか、という概念に相当します。

これは TCP や UDP ではポート番号という概念で提供します。TCP はトランスポート層の機能もありますので L4 と L5 の機能を同時に持っています。UDP はトランスポート層の機能はほとんどないので（例えばUDPデータ長はIPデータグラムに依存しますし、IPでの消失に対しては何もしません）L4 と言われますが実態としてはほぼ L5 のみの機能を提供します。

これは EtherCAT でいうと、マスタからスレーブ#nへの情報をどの位置のデータグラムに収めるか、の概念に相当します。ここも EtherCAT の場合、大変素朴に感じるので、規模が大きくなった場合にどのように扱うのかが課題になってくると思います。

プレゼンテーション層 (Layer 6, Presentation Layer)

プレゼンテーション層では「データをどのようなビット列にするか」を定義します。例えば温度の情報を運ぶときに「0.01度単位の温度を100倍した整数値を4octetの2の補数表現でLittle Endian で表現する」という風に定義するのがプレゼンテーション層の役割です。

これは Little/Big Endian の他、文字コードに何を使うか、どのような画像圧縮フォーマットを使うか、なども広くプレゼンテーション層の概念に相当します。制御装置で言うと「電文フォーマット」などと言われる部分がプレゼンテーション層に該当します。

これはTCP/IPの世界では最も有名なのが管理プロトコルの SNMP で用いる MIB です。通信機器の状態を示すたくさんの値をどのように表現するかを定めています¹。そしてそれは ASN.1 (Abstract Syntax Notation 1) と呼ばれる記述言語で形式的に記述されています。

例えば前回の話で出てきた MTU は ifMtu という名称の MIB が定義されています。MTUを知りたいインタフェースの番号を ifIndex と仮定して、データの分類をする木構造を示す OID が 1.3.6.1.2.1.2.2.1.4.(ifIndex) の位置に MTU の値が来ることが決められています。ネットワーク機器を管理・監視するソフトウェアでは、機器のインタフェースの MTU を知りたければ、どこのメーカの機器であってもこれを用いて MTU を取り出すことが出来ます。

EtherCAT ではデータグラムの中身をどのようなデータ表現で用いるかはエンドユーザと言うかベンダごとに決定することになるのだと思います。これが SNMP MIB の様に、ある程度標準的なデータ交換については EtherCAT の枠組みで定義するようになれば、設計や試験のコストを下げたり信頼性を上げたりするのに大きな寄与をするのではないかと想像してます。

アプリケーション層 (Layer 7, Application Layer)

アプリケーション層はプロトコルスタック全体を提供する窓口になる部分です。これは人間であったり、あるいはソフトウェアに対するAPIであったりします。今ではアプリケーション層の機能を直接ユーザが触ることはあまりないかと思いますが、いにしえの telnet や ftp はアプリケーション層を直接人間が触るような例です。

EtherCAT は特にアプリケーション層の概念を持ち得ないようにも思えます。ただ、どのような統一したコンセプトで設計者を含むエンドユーザが必要する機能を提供できるかを、アプリケーション層があるものとして考えるという捉え方はあるかなと思います。

EtherCAT はネットワーク全体としては低いレイヤの定義ですし、制御用という用途もあって、生の構造をどう扱うかをユーザに委ねてしまうことになります。ところが他の制御用のプロトコルと異なって、割と大きな規模でのネットワークも構成できてしまいます。その場合に、ネットワーク全体で構成するかなりの部分を設計者に委ねることになります。そうなるとスケールしない、混乱を起こしがちな技術基盤ということになりかねません。

スケールする、すなわち規模が大きくなっていくときにどう全体を構成していくか、OSIモデルで考えるならネットワーク層からアプリケーション層までをどのように提供していこうと考えるのか、これが EtherCAT の将来に関わる重要な考察ポイントだと考えています。

OSIモデル以外での EtherCAT のネットワーク技術的考察

以上、OSI モデルで EtherCAT を見てきました。ここでは OSI に限らないネットワークの概念で EtherCAT を眺めてみます。

オーバレイネットワーク

一つのネットワークの技術は他のネットワークの技術の上に重ねて使うことが出来ませす。これをオーバレイネットワークといいます。EtherCAT も好むと好まざるとに関わらずオーバレイが可能です。EtherCAT 自体にはデータグラムとして IP を乗せるという考え方がすでに存在します。これもオーバレイネットワークの一種です。ここでは、オーバレイネットワークの上の層に EtherCAT が乗っかる場合を考えてみます。

EtherCAT は Ethernet フレームを使います。Ethernet フレームは何も本物の物理 Ethernet でないとならないということはありません。遅延を許容するなら Ethernet フレームを運べる他のネットワークプロトコルであっても構わないです、というか動作します。

例えば広域のネットワークサービスでは Ethernet フレームを交換するサービスは普通にあります。また様々なネットワークプロトコルを運べるようにするための通信キャリア向けの技術として MPLS (Multi Protocol Label Switching) があって、それも Ethernet フレームを運ぶことが出来ます。

このようなオーバレイネットワークを考えると、EtherCAT 側が要求する情報をアンダーレイ側のネットワークに伝搬する機構が必要になってくるでしょう。例えば乗っかるネットワークに対して伝送が一定時間以内の遅延に収まるような要求を EtherCAT 側からシグナリングするという機能があれば長距離 EtherCAT も実用的に使えるでしょう。逆に下側のネットワークの状態を EtherCAT 側に知らせることも必要になるでしょう。例えば長距離ネットワークの障害情報を EtherCAT のデータグラムに乗せて EtherCAT マスタ側に伝達するなどです。

データプレーンとコントロールプレーン、インバウンドとアウトバウンド

OSI モデルでの考察で EtherCAT に機能を追加したいと考えるシーンがたくさんありました。機能を追加しようとすると EtherCAT には大きな負担になります。Ethernet 上にシンプルに乗っているのが EtherCAT の良いところです。いろんな機能を追加しようとすると、シンプルさが犠牲になる他、低遅延や最大遅延が見積可能であるというような利点を失いかねません。

ネットワーク層からプレゼンテーション層まで、追加したい機能を大雑把に言うと物理的な機能をできるだけ人間が扱いやすい記号的な論理的な形で扱えるようにしようというものです。さらにそれらがなるべく自動的に行われると嬉しいわけです。これを実現するには、制御自体の通信の他に多くの管理用の通信が必要になります。それぞれデータプレーンとコントロールプレーンと言いますが、これらをどう棲み分けるように構築するかは EtherCAT の場合はかなり難しい課題になると予想します。

EtherCAT 自体は現状ではこれだけで完結するように考えられています。少々の機能追加であるなら EtherCAT 自体のメカニズムで吸収可能です。例えば一部のデータグラムに拡張機能の情報を乗せるというような方法が考えられます。このように一つの媒体に管理機構を入れ込んでしまう手法をインバウンドと言います。インバウンドの場合は物理的な通信媒体が一通りで済むという利点があります。

ただしいろんな機能を入れようとしてコントロールプレーンが肥大化するとこれらの管理用の機能を EtherCAT とは別の物理媒体の通信で実現したくなるでしょう。これをアウトバウンドと言います。アウトバウンドになると EtherCAT 自体の通信の品質には影響を及ぼさなくなりますが、通信媒体が複数必要になるという煩雑さが発生します。

まとめ

ネットワーク層以上のOSI層で EtherCAT を考えてみました。多くの追加機能が考えられますが、それらを実現しつつ EtherCAT の利点を減じないためには結構厳しい技術的な山があるように感じました。

さて、明日のEtherCATについて語る Advent Calendar 2019 の記事は@nonNoise さんの2019年のまとめと2020年の話です。こちらもお楽しみに！

参考文献

Open Systems Interconnection Model

例えばネットワーク機器のSNMP MIB/OIDまとめを参照してください。 ↩