無知の知 OSIモデルで EtherCAT を考察する（前編）

この記事は EtherCATについて語る Advent Calendar 2019の23日目です。
昨日はtakuzirraさんの EtherCATを使うと何がうれしいのか でした。

今日は OSI Reference Model から考える EtherCAT の今後を書いてみます。思ったより量が増えたので今日は「前編」にします。

はじめに

上で「EtherCAT の今後を書いてみます。」と書きました。この「今後」というのは自分が知らないことを勉強するときの方針であったり、ひょっとするとまだEtherCATに存在してないのでその拡張の仕方だったり、EtherCATの利点と弱点を見つける方法だったりします。というのもまだ私が理解不足なもので、「これってどうなってるんだろう」と思ったときに、それが定義されてるのかされてないのかすらわからないからです。なので何かの機能がわからない場合でも、単に知らないだけかもしれませんし、あるいは EtherCAT の規格では定義されていないのかもしれないからです。もし、書いてることですでに決まってる・わかってることがあれば是非教えて下さい。大して知らない中であれこれ考えてみたので「無知の知」をタイトルに入れました。

おことわり

最初、この advent calendar に登録したときは「Elixir で EtherCAT を使ってみる」を書くつもりでした。Elixir とは私の注目している 制御向きのプログラミング言語 です。Elixir に注目した経緯については Elixir を使うようになった経緯 〜電力システム制御の現場から〜を御覧ください。あと、IoT 的な応用については #NervesJP Advent Calendar 2019 なども参照してください。

EtherCAT は気になりつつも気軽に触れる感じを持っていなかったところ手頃なスレーブボードが発売され、これをちょっと触ってみるかという気分になったのです。Elixir でどう EtherCAT Master を構築するかは2通り考えてて

• Elixir から OS のシステムコールを呼んで Ethernet フレームを直接扱うプログラムを作る
• すでにあるライブラリやフレームワークを使う

という両面作戦でした。で、今回これを披露しようと思ってたのですが、なんと期日に間に合わず… です。前者については Elixir で raw socket を扱う（準備編） としてまとめました。要は Ruby や Python にある PF_PACKET も利用可能な raw socket インタフェースが Elixir ではまだ用意されてないというところです。

後者についてはギリギリまでやってて まだ仕込み中でどうも間に合いそうにありません。

ということで、非常に残念ながらこの宿題は来年ということでネタをこちらに変更しました。

OSI モデル

OSIモデル(Open Systems Interconnection model)は、ネットワーク全体の概念を機能別に分類してネットワークアーキテクチャを構築・理解するために使うモデルです。第1層の物理層から第7層のアプリケーション層までに別れており、番号の小さい層が具象的で番号の大きな層が抽象的な概念を表すようになっています。

• 第7層：アプリケーション層
• 第6層：プレゼンテーション層
• 第5層：セッション層
• 第4層：トランスポート層
• 第3層：ネットワーク層
• 第2層：データリンク層
• 第1層：物理層

アプリケーション層は人間が触ったりプログラムがアクセスしたりするための層で、最も抽象的・論理的な層です。物理層は、電気信号や光信号などをどのように扱って通信させるかを決める最も具象的・物理的な層です。これらの7層全体でネットワークの機能を表現するモデルがOSIモデルです。

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

EtherCAT は工業制御用のプロトコルであり、PLCや様々な入出力装置がこれを使います。PLCや入出力装置が出会うところはOSIモデルに従うならアプリケーション層のはずです。また、Ethernetケーブル上の電気信号で通信を行いますので、OSIモデルの言うところの物理層もあるはずです。では EtherCAT を OSI モデルで下の層から見てみます。

物理層 (Layer 1, Physical Layer)

これは EtherCAT は Ethernet (IEEE 802.3 シリーズ) を使うので「いじょ！」なのです。ただし、今後の展開を考える上でどんな物理メディアがあり得るのかを考えるのは楽しいです。

光伝送

電気信号に代えて光信号を使うというのは簡単に思いつきます。もう規格として存在するのかなとは思いますし、実際に規格にないとしても使っちゃってる現場も結構あるのではと思います。

Ethernet の規格 IEEE802.3 には導線による UTP ケーブルだけでなく、100BASE-FXや1000BASE-SX, 1000BASE-LX等の光を媒体とする通信規格が随分前からあります。直接扱う製品も多いですし、100BASE-TXや1000BASE-Tとの変換をするMC (Media Converter) も多く出回っています。EtherCAT を直接使うことも可能です。やったことはないですが、おそらく何の問題もなく MC で変換することで光ファイバ通信ができるでしょう。

これのメリットで一番大きいのは EtherCAT のケーブルを這わせる箇所の近傍に大きな誘導電圧が発生するような機器がある場合です。典型的には一旦屋外を経由するようなときに使うと誘導雷の被害を防げます。

また、UTP だと100mに長さが制限されますが、光で運べばもっと延ばすことができます。100BASE-TX における UTP の長さの制限は、一つは電気信号の減衰による S/N の限界によるものです。これを光デバイスに置き換えることでより長距離にすることが可能です。

私の知ってる限りにおいては 100BASE で一番到達距離のあるデバイスは Smart Optics 社の SFP でリンクバジェット（減衰許容）が47dBもある化け物です。これは200km程度という名目になっていますが、途中にコネクタを挟まないきれいな光ファイバなら本当に200kmは届きます。つまりEtherCATのマスタとスレーブが200km離れてても動かすことができます。

もう一つの理由としてCSMA/CD¹の動作をする上で、他のノードが送信を始めたのを一定時間内に知ってできるだけ同時送信の衝突を防ぐために長さを抑えたとういうのもあります。光速が有限なためです。これは、EtherCAT では1本のUTPメディア上では1対1接続するので直接は関係ありません。ただし、光の速度によってノード間での通信遅延は避けられません。

光ファイバは光が通過するコアが$SiO_2$ガラスであり、そこでの光速は真空中の速度の2/3程度、すなわち$2.0×10^8 m/s$ 程度です。上の例に倣ってマスタとスレーブが200km離れてるとすると、往路に1ms、帰路に1msかかるので、スレーブが処理する時間を0msと仮定してもマスタのもとにフレームが帰ってくるまでに2msかかることに注意してください。

無線伝送

UTP も光ファイバも固体の媒体を必要とします。これを引き回さなくて良くなると大変便利です。例えば工場のラインを再構成するような場合です。普段の実験や試作の際も便利ですね。Ethernetフレームを運べるような無線通信で実現も可能でしょう。

例えば直接使えそうなメディアで言うと IEEE802.11系列で規定されているいわゆるWiFiがそうです。この場合はシェアードメディアで EtherCAT を使うことになるのでトークンバス的な応用になります²。

また、Bluetooth 3.0 から IEEE802.3 のフレームを扱えるようになったようなので、Bluetooth に乗せるのもあまり難しくなさそうです。

さらに可能性だけで言うと、携帯電話、とくに Local 5G と呼ばれる自営網で使う第5世代の携帯電話規格に乗せられそうに思います。

無線通信の場合、特に高い周波数を使う場合は直進性が強くなりますので、電波を使ってるとは言え機材のレイアウト・配置には一定の制約がでるでしょう。また、一旦つながってても、何かの拍子に切れてしまう可能性もあります。無線通信同士が互いに干渉する可能性も常にあります。有線に慣れてしまっているとそのあたりが不安で利用に二の足を踏む気分になります。

これに対しては、例えば Flexible Factory Partner Alliance という組織で工場場内の無線通信についての実験・検証や規格化が進められています ³。また、有線での EtherCAT が広まるにつれてなし崩し的に無線区間が増えていくことが予想されます。積極的に使いたいと思うかどうかは別として、そういう波が来るものとして考えておくのが良いでしょう。

データリンク層 (Layer 2, Data link Layer)

物理層同様に、EtherCAT は Ethernet を使ってますのでデータリンク層についても「いじょ！」でおしまいです。

おしまいのはずですが、ちょっと気になるのが MTU (Maximum Transfer Unit) 問題です。Ethernet は 100BASE-TX では MTU が 1500 octet と固定で決まっています。ここまでは不安はないです。ところが 1000BASE になるとジャンボフレームと言って 10000 octet 近いペイロードのフレームも使えます。速度がざっくり10倍になりますからフレームが長くなるのはフレーム自体の送受信時間にはあまり影響がありません。しかし問題は隣接するマスタ・スレーブでのフレーム長の違いをどう検出するのか、どう吸収するのか、です。

IP での MTU の扱い

これは当然 TCP/IP でも問題になります。L2 の Ethernet のすぐ上にくる L3 プロトコルは IP です。IP は version に v4 と v6 があって、上位互換ではありません。

IPv4 では MTU より大きな IP データグラムが来た場合はフラグメンテーションと言って、IP データグラムを Ethernet の MTU に収まるように一旦バラバラにします。ルータからルータへと伝搬するときには、異なる MTU の区間が出てきたりしますが、それまでの MTU より小さな MTU になると、途中のルータでもフラグメントをします。一旦バラされたら途中では組み立て直しません。最後のルータで全部を組み立て直して元の IP データグラムを構成するということをやります。途中でどれか一つでも Ethernet フレームがなくなると IP データグラムがまるごとなくなります。

IPv6 ではフラグメンテーションをしません。ですので、ルータを伝搬する途中でそれまでより小さな MTU が出てきてもどうすることも出来ません。IPv6 の場合は送信元と受信先との間の全ての区間の MTU で最も小さな MTU でも通るような小ささの IP データグラムで送り出すようにすることで、区間ごとの MTU の変化を吸収しています。

これをやるために IPv6 では PMTUD (P-MTU-D: Path MTU Discovery) というプロトコルでエンド・エンドの区間での最小の MTU を検出します。これは ICMP の v6 版である ICMPv6 のプロトコルで実現されています。が、ICMP は、セキュリティ上の過剰な配慮でフィルタされていることがよくあります。ping しても活きているはずの相手ホストが見えないとか、traceroute の結果が * * * だらけという経験をしたことはみなさんあると思いますが、これが ICMP を遮断することによる弊害です。

これを ICMPv6 でやられると PMTUD が動かなくなります。なので、発信元から送出した IPv6 データグラムが途中のルータで MTU が小さい区間に遭遇して送れなくなって捨てられるという事態が起こります。これトラブルとしては厄介で、小さな IPv6 データグラムは通るのに、でかいデータグラムになると通らないという状況になり、通ったり通らなかったりで大変分かりにくいトラブルを引き起こします⁴。

1Gbps 以上での EtherCAT はどうなのか

上のような問題は EtherCAT でも起こりえます。マスタ・スレーブ間、スレーブ・スレーブ間で MTU が違う可能性がありえます。寡聞にして… というとかっこよいですが、勉強不足につき EtherCAT がどのようにこれを回避するのか私は知りません。EtherCAT の場合は IPv4 の様なフラグメンテーションは使うべきではないですから IPv6 の様に全区間の MTU を検出して、どの区間も絶対に通る大きさのフレームのみ送出すべきです。

そうなるとその MTU はどうやって検出するかの問題が IPv6 同様に出てきます。そのようなメカニズムを作らないとならないですし、その後付のメカニズムがきちんと動くように全ての製品に強制しないとなりません。

あるいは MTU は 1500 octet と決め打ちにしてジャンボフレームは使わないという選択肢もありえます。ただし、今後の展開を考えると、今 1500 octet で済んでてもそのうちもっと大きな EtherCAT データグラムを載せたくなってくるでしょう。そのときに MTU 問題が出てきます。これをできるだけ綺麗に解決しておくと、将来細々とした面倒が発生するのを防ぐことができるはずです。

まとめ

OSIモデルの物理層とデータリンク層で EtherCAT を考察してみました。

さて、明日のEtherCATについて語る Advent Calendar 2019 の記事は今日の続き 無知の知 OSIモデルで EtherCAT を考察する（後編） です。こちらもお楽しみに！

#参考文献（脚注の参照先です）

1. CSMA/CD については別記事 「温故知新 IEEE802シリーズで EtherCAT を眺め直す」の「媒体共有型のイーサネット (Ethernet)」の章」 を御覧ください。 ↩

2. トークンバスについては「温故知新 IEEE802シリーズで EtherCAT を眺め直す」の「IEEE802.4 トークンバス (Token Bus)の章」 を参照してください。 ↩

3. 活動内容については 板谷聡子、狭空間ワイヤレスプロジェクトの推進が分かりやすいと思います。 ↩

4. PMTUDのトラブルについては例えばPath MTU Blackhole で阿部寛様のご尊顔が表示されない！を御覧ください。 ↩