皆さん、こんにちは！
上越市を拠点にし、「FA設備・装置開発」と「画像処理」に強い会社、NSIです！
私達は豊富な経験と専門知識で、各種業界の自動化・システム化のお手伝いをしています。
さて、FAネタ2本立ての2本目です。
1本目では「EtherCATとEtherNet/IPの違い」を比較しましたが、今回は「EtherCATが100Mbpsでも速い理由」について解説します！
はじめに
EtherCATについて調べていると、一つ疑問が出てきます。
一般的なEtherCATの通信速度は100Mbpsですが、Ethernetには1Gbpsや10Gbpsに対応した機器もあります。
それなのにEtherCATは、以下のようなリアルタイム性が要求されるFA設備で広く使われています。
- 高速I/O
- サーボ制御
- モーション制御
- 半導体製造装置
- ロボット
- 高速計測
そこで、「100Mbpsしかないのに、なぜEtherCATは速いのか？」という疑問が出てきます。
帯域だけ見れば、1Gbpsの方が有利そうだけど…？
結論から言うと、
EtherCATは100Mbpsなのに速いのではなく、100Mbpsという帯域をリアルタイム制御のために非常に効率よく使っています。
今回はその仕組みを、以下の観点から見ていきます。
- IPを使わない通信
- On-the-Flyと通信効率
- EtherCAT SubDevice Controller
- 時刻同期とMainDevice側の処理
- セキュリティ
EtherCATは100Mbps
まず基本から確認します。
一般的なEtherCATでは、物理層として100BASE-TXが使われ、通信速度は100Mbpsの全二重（Full Duplex）です。100BASE-TXの銅線接続では、ノード間を最大100mまで接続できます。光ファイバーによる100BASE-FXなども利用できます。
つまり、「EtherCATは100Mbps」という説明は、一般的な100BASE-TXのEtherCATを指すなら正しい説明です。Gigabit対応の拡張については後半で触れます。
ではなぜ高速なのでしょうか？
Mbpsとリアルタイム性能は違う
例えば、100Mbps、1Gbps、10Gbpsという数字は、主に1秒間にどれだけ大量のデータを転送できるかを表します。大量の画像やファイルを送る場合には非常に重要な数字です。
しかしFA制御では、それだけではありません。
例えば、以下のような要素も重要です。
- Latency（通信遅延）
- Jitter（遅延のばらつき）
- Cycle Time（制御周期）
- Synchronization（同期精度）
- Determinism（時間確定性）
例えば1Gbpsで通信できても、以下のように到着時間が大きく変動したら、高精度な制御は難しくなります。
今回は300μs
次は800μs
その次は400μs
FAでは、大量に送れることだけでなく、決められた時間内に、予測可能な形で通信できることが重要です。
EtherCATの通常の周期通信はIPを使わない
EtherCATを理解するうえで重要なのが、EtherCATの通常の周期プロセスデータ通信（制御に使う入出力データを一定周期でやり取りする通信）はIPを使わないという点です。一般的なEthernet通信では、以下のような構造がよく使われます。
EtherCATは違います。基本的には、以下のような構造です。
標準EthernetフレームのEtherTypeには、0x88A4というEtherCAT専用の識別子を使用します。EtherCATは短周期のプロセスデータに最適化されているため、TCP/IPやUDP/IPなどのプロトコルスタックを省略できます。
つまり、Ethernetを使っているからといって、必ずIPを使う必要はないということです。
Layer 2で直接やり取りする
OSI参照モデルで考えると分かりやすいでしょう。一般的なTCP/IP通信なら、以下のようになります。
EtherCATのリアルタイムプロセスデータ通信では、以下のような非常にシンプルな構造を取れます。
もちろん、Layer 2だから自動的に速いというわけではありません。
EtherCATの本当のポイントは、さらにその先にあります。
最大の特徴はOn-the-Fly
EtherCATの仕組みで最も面白いのが、On-the-Fly Processingです。
EtherCATでは、各SubDeviceがフレーム全体を受信してからアプリケーションで応答を作るのではなく、フレームが通過している間に担当するプロセスデータを読み書きします。
MainDeviceから送られたEtherCATフレームは、以下のように各機器を通過し、折り返して戻ります。
ライン構成では、末端のSubDeviceが未接続ポートを検出すると、フレームを折り返します。図の上下の矢印は、同じ機器間ケーブル内の別々の送受信経路を表します。100BASE-TXの全二重通信を使い、フレームは各SubDeviceを逆順に通って同じMainDeviceへ戻ります。そのため、末端からMainDeviceへ別の戻りケーブルを引く必要はありません。
各SubDeviceは、フレームが通過している途中で、自分に必要なデータだけを読み取り、自分のデータを書き込みます。イメージすると、以下のとおりです。
この読み書きは、EtherCAT SubDevice Controller（ESC）がハードウェアで行います。
一般のEthernetスイッチにもハードウェア転送やカットスルー方式があり、すべての機器がフレームをCPUで処理してから転送するわけではありません。EtherCATの特徴は、複数機器のプロセスデータ交換を、フレーム通過中の読み書きとして実現する点にあります。
これが、On-the-Flyです。
フレームを止めずに、通り過ぎる間にデータをやり取りしているんだね！
4バイトのデータを送ると、なぜ効率が悪いのか？
On-the-Flyに加えて、EtherCATの通信効率を理解するために、少量のデータを個別に送る場合を考えてみます。
ETGの資料には、機器ごとに個別のEthernetフレームを使う場合の計算例があります。最小フレームの送信には、プリアンブルなどとフレーム間隔（IFG）を含めて84バイト相当の時間が必要です。ここで運ぶ有効なプロセスデータが4バイトなら、割合は次のようになります。
4 ÷ 84 × 100 ≒ 4.8％
これは、「1フレームの送信時間」＋「フレーム間隔（IFG）」に対して、有効な4バイトのデータを送る時間が占める割合です。
この計算では、規定のフレーム間隔以外に待ち時間がないと仮定しています。84バイトすべてがフレーム本体という意味ではなく、プリアンブルなどとIFGも含めた時間をバイト数に換算しています。機器の応答待ちなどがあれば効率はさらに変わります。
機器ごとに小さなデータを個別のフレームで送ると、その都度、フレームの付加情報やフレーム間隔が必要になります。運びたいデータが少ないほど、これらのオーバーヘッドが占める割合は大きくなります。
だからEtherCATは一つのフレームにまとめる
そこでEtherCATでは、複数機器のプロセスデータを一つのEthernetフレームにまとめます。
例えば、複数のSubDeviceのデータを、次のように1フレーム内に配置できます。
各SubDeviceはフレームが通過している間に、自分に割り当てられた領域だけをRead / Writeします。Dev.1はDev.1の領域、Dev.2はDev.2の領域を読み書きする、というイメージです。
一つのフレームを流しながら、複数機器のI/Oデータをまとめて交換できます。
データをまとめることで、フレームごとの付加情報やフレーム間隔の負担を複数機器で分担できます。そして、各SubDeviceが通過中に読み書きする仕組みが、前の章で説明したOn-the-Flyです。
ただし、すべてのデータが必ず1フレームに収まるわけではありません。データ量や周期構成によっては、複数のフレームを使用します。
ETGによれば、十分なデータを効率よくまとめた場合、フレーム利用効率を90％超にできるとされています。ただし、データ量や構成によって変わり、常にこの値になるわけではありません。
ここで分かるのは、少量のデータを個別に送るより、まとめて運ぶことで通信容量を有効に使えるという仕組みです。これが100Mbpsという帯域を効率的に利用できる大きな理由です。
通信フレームの処理を担うのはESC
On-the-Fly処理を実現する重要な存在が、ESC（EtherCAT SubDevice Controller）です。
EtherCAT SubDeviceでは、この専用コントローラがEtherCATフレームをハードウェアで処理します。
つまり、以下のようなソフトウェアスタックの処理を、フレーム通過中の読み書きのたびに行う必要はありません。
フレーム処理を専用ハードウェアで行うことで、以下のようなメリットが得られます。
- 処理時間を短くする
- ノードごとの性能差を小さくする
- 通信時間を予測しやすくする
ESCによる完全なハードウェア処理によってネットワーク性能を予測可能にし、SubDevice側のソフトウェア実装への依存を小さくできます。
ここでいうハードウェア処理は、EtherCATフレームの処理を指します。機器内部の制御演算やアプリケーション処理にはCPUやマイコンが使われる場合があり、その処理時間は別途考慮する必要があります。ESCとアプリケーション側は、PDI（Process Data Interface）などを介してデータを交換します。
「100Mbpsだから遅い」が成立しない理由
ここまで来ると答えが見えてきます。
EtherCATは「100Mbps × 効率の高い通信方式」であり、単純な通信帯域だけではありません。
EtherCATでは、以下のような仕組みでオーバーヘッドを抑えています。
- TCP/IP処理を周期通信で必要としない
- 1フレームに多数のデータをまとめられる
- 各SubDeviceがOn-the-Flyで処理する
- ESCでハードウェア処理する
したがって、「1Gbpsなら100Mbpsの10倍リアルタイム制御が速い」という計算にはなりません。ここが、EtherCATと一般的なEthernet通信をMbpsだけで比較してはいけない理由です。
帯域が10倍になっても、制御がそのまま10倍速くなるわけじゃないんだね。
EtherNet/IPとの違いについては、以下の記事で詳しく紹介しています。
Distributed Clocksも重要
EtherCATがモーション制御で使われるもう一つの大きな理由が、Distributed Clocks（DC）です。
例えば8軸のサーボを同時に動かすとします。
各軸の内部時計がバラバラだと、以下のように微妙な時間差が発生します。
そこでEtherCATでは、各SubDeviceが持つクロックを同期します。さらに、各SubDeviceまでの伝送遅延も測定して補正します。ETGによれば、Distributed Clocksによるシステム内のジッタは1μsを大きく下回ります。
ここでいう同期精度やジッタは、通信周期そのものやフレーム到着時刻のばらつきと同じ指標ではありません。実際の精度は、対応機器、ネットワーク構成、設定によって変わります。
フレームが同時に届く必要はない
Distributed Clocksの考え方で面白いのは、全デバイスへEtherCATフレームを完全に同時に届ける必要がないという点です。各SubDeviceの時計が同期していれば、「10:00:00.000000になったら出力ON」というように、それぞれのデバイス自身が同じ時刻を基準に動作できます。
つまりMainDeviceは、機器側の処理時間も見込み、同期したI/O動作に必要な期限までにデータを届けることになります。通信フレームそのものの到着タイミングと、実際のI/O動作タイミングを分離できるわけです。これはモーション制御を考えると非常に合理的な仕組みです。
みんなで時計を合わせておけば、データの届くタイミングが少しずれても、同じ時刻に動けるんだね！
MainDeviceも必要な期限を守る
DCで機器の時計がそろっていても、制御に使う新しいデータが遅れて届けば、予定した動作には間に合いません。時刻同期の精度と、必要なデータを期限までに届けることは別の要件です。
例えばDC同期出力では、MainDevice側の制御演算とフレーム送信を終え、通信時間と機器内部の処理時間も見込んで、出力タイミングに間に合うようデータを届けます。DCは到着時刻の揺らぎがそのままI/O動作時刻に現れることを抑えますが、期限を過ぎたデータを間に合わせる機能ではありません。
そのため、PCベースのMainDeviceでは、周期タスクの起動のばらつき、制御演算にかかる最大時間、NIC・ドライバの送信処理なども含めて余裕を確認します。要求に応じてRTOSやリアルタイム拡張を選ぶこともありますが、必要な実装は制御周期や機器構成によって変わります。
EtherCATの通信方式だけで、装置全体のリアルタイム性が決まるわけではありません。通信と制御アプリケーションを合わせて、必要な期限を守れるように設計することが重要です。
個人的には非常に「美しい」仕組み
EtherCATの構造を見ていると、「通信速度を上げれば速くなる」という力技だけではありません。むしろ、「今ある100Mbpsを、どうすれば最大限リアルタイム制御に使えるか？」をかなり突き詰めています。
ここまでの工夫を並べると、以下のとおりです。
- 不要なプロトコルを通さない
- フレームを止めない
- 1フレームを複数機器で使う
- ハードウェアで処理する
- 各機器の時計を同期する
個人的には、非常に美しい設計だと思います。
IPを使わないこととセキュリティ
ここでもEtherCATの構造が効いてきます。
通常のEtherCAT周期通信ではIPを使用しません。さらにSubDeviceではESCによるハードウェア処理を中心とするため、一般的なPCやIP機器のようなソフトウェアスタックを必ずしも必要としません。
ETGはEtherCATのセキュリティ上の特徴として、以下などを挙げています。
- ハードウェアベースのフレーム処理
- 非IP通信
- MainDeviceだけがEtherCATフレームを生成する明確な通信階層
- Attack Surface（攻撃を受け得る範囲）の縮小
一般的なTCP/IP機器とはAttack Surfaceの構造が違うわけです。
ただし「IPではない＝安全」ではない
ここは非常に重要です。EtherCATが非IPだからといって、設備全体が安全になるわけではありません。
実際の設備では、以下のような構成になることがあります。
すると、以下のようなものもセキュリティ対象になります。
- Windows IPC
- PLC
- MainDevice
- Engineering PC
- 上位Ethernet
- VPN
- リモートメンテナンス
- USBメモリ
- ファームウェア
例えばMainDeviceそのものが侵害されれば、「EtherCATが非IPだから大丈夫」とは言えません。したがって、EtherCATネットワーク自体のAttack Surfaceが小さいことと、EtherCATを使った設備全体が安全であることは別問題として考える必要があります。
EtherCATの外側にも入り口はたくさんあるから、設備全体で対策を考えてね！
EtherCATとIEC 62443
この点については、2026年に興味深い発表がありました。
2026年4月20日、ETGは、3種類の典型的なEtherCATシステムについて、UL SolutionsによるIEC 62443-3-3の評価結果を発表しました。ETGの発表によると、評価対象のシステムでは、プロトコルを変更することなくSecurity Level 2（SL2）に相当する要求を満たすことが確認されたとしています。
これは評価対象の構成・条件に関する結果であり、任意のEtherCAT機器や設備が無条件でSL2認証を持つことを意味しません。プロトコル変更が不要であることと、対策や設定が不要であることは別です。 実際の設備では、用途に応じたMainDeviceなどの要求と、システム全体の対策・設定・評価を確認する必要があります。
ただしこれも、EtherCATを使えば何もしなくてもIEC 62443対応になるという意味ではありません。実際の装置ではMainDevice、上位ネットワーク、ユーザー管理、リモートアクセスなどを含めたシステム全体として設計する必要があります。
EtherCATでもIP通信はできる
もう一つ補足です。
EtherCATではIP通信が一切できないわけではありません。EoE（Ethernet over EtherCAT）という仕組みがあります。
EoEを利用すると、Mailbox通信を使って通常のEthernetフレームをEtherCAT上でトンネリングできます。そのためEtherCAT SubDevice上でTCP/IPベースのサービスを利用することもできます。ETGもEtherCATのリアルタイムデータ転送に影響を与えずTCP/IP通信をMailbox経由でトンネリングできると説明しています。
利用にはMainDeviceや対象機器のEoE対応と適切な設定が必要です。すべてのSubDeviceがEoEやHTTPなどのサービスを実装しているわけではなく、IP通信に無制限の帯域が確保されるという意味でもありません。また、EoEでIP機能を使う部分については、IPネットワークとしてのセキュリティも考える必要があります。
EtherCATは本当に100Mbpsだけ？
最後にもう一つ。
ここまで「EtherCAT＝100Mbps」として説明してきましたが、Gigabit対応の拡張も存在します。それぞれ、以下の名称で区別されます。
- EtherCAT G：1Gbps
- EtherCAT G10：10Gbps
Machine Vision、高性能計測、大容量プロセスデータなど、100Mbpsでは帯域そのものが不足する用途を想定した技術です。重要なのは、EtherCAT G／G10でも、On-the-Fly、Distributed Clocks、EtherCATの通信モデルという基本思想は維持されていることです。
つまりEtherCAT自身も、「リアルタイム制御では100Mbpsで十分」と言っているわけではありません。データ量そのものが増えれば、当然帯域も必要になります。
まとめ
今回は、「EtherCATは100Mbpsなのになぜ速いのか？」について見てきました。
理由をまとめると、以下のような仕組みがあります。
- 周期通信でTCP/IPを必要としない
- Ethernet Layer 2でEtherCATフレームを直接扱える
- 一つのフレームに複数機器のデータをまとめられる
- 各SubDeviceがOn-the-Flyで読み書きする
- ESCによってハードウェア処理する
- Distributed Clocksで各機器を高精度同期する
これらを装置の性能につなげるには、MainDeviceの制御演算や送信処理も含め、必要な期限を守る設計が重要です。つまり、「EtherCATは100Mbpsなのに速い」のではなく、「100Mbpsをリアルタイム制御のために極めて効率よく使っている」という方が正確です。
PCネットワークでは、以下のように帯域が大きくなることに目が行きがちです。
100Mbps
↓
1Gbps
↓
10Gbps
しかしFA制御では、BandwidthだけではなくLatency、Jitter、Synchronization、Determinismを見る必要があります。EtherCATは、それを非常に分かりやすく体現しているネットワークだと思います。
EtherNet/IPと比較すると、この設計思想の違いがさらに分かりやすくなります。
参考資料
本文の説明に対応する公式資料を、テーマ別にまとめています。
- EtherCATの基本構造・折り返し・EoE
- EtherCAT Technology Group（ETG）：EtherCAT — Layer 2、On-the-Fly、折り返し、Distributed Clocks、EoE
- 通信効率：4.8％の計算例・90％超の利用効率
- ETG：EtherCAT Overview & ETG Introduction (Brochure) — 「The technology in detail」の節：4.8％の計算例と通信効率
- ESC・複数フレーム・Ethernetスイッチとの違い
- Beckhoff：General — EtherCATのESCと「Process Data Interface」の節
- ETG：ETG.1500 EtherCAT Master Classes — 周期フレームと複数タスク：§5.4、V1.0.2
- Cisco：Configuring Switching Modes — カットスルーとストアアンドフォワード：pp.1–2
- Distributed ClocksとMainDevice側の制御
- Beckhoff：EtherCAT Distributed Clocks — 「Application of distributed clocks and synchronicity with the control system in the PC」の節
- 非IP通信とサイバーセキュリティ
- ETG：EtherCAT & Cybersecurity — 非IP通信・ハードウェア処理と攻撃対象領域
- IEC 62443の評価結果と適用条件
- ETG：UL Solutions certifies EtherCAT’s Cyber Resilience — 2026年4月20日の評価結果発表
- ETG：Cyber Security Requirements on EtherCAT Systems — 評価対象・シナリオ・適用条件を示す説明資料、2026年4月20日
- EtherCAT G／G10
- ETG：EtherCAT Technology Group officially supports EtherCAT G — EtherCAT G／G10の公式採用発表、2019年
- ETG：EtherCAT G — Gigabit対応の拡張と用途
商標について
- EtherCAT®、EtherCAT G®、EtherCAT G10®は、Beckhoff Automation GmbHの登録商標です。
- EtherNet/IP™は、ODVA, Inc.の商標です。
- その他、記載されている会社名・製品名は、各社の商標または登録商標です。
最後に
今回は「EtherCATが100Mbpsでも速い理由」について解説しました。
帯域を増やすのではなく、今ある100Mbpsを無駄なく使い切る。この発想がEtherCATの面白いところだと思います。とはいえ、装置全体のリアルタイム性は通信方式だけで決まるわけではなく、MainDevice側の作り込みも関わってきます。
EtherCATに触れる機会があれば、ぜひ思い出してみてください！
ここまで読んでいただき、ありがとうございました。
ご質問・ご要望・ご相談などは、下記お問い合わせフォームからお気軽にご連絡ください。
https://www.net-nsi.co.jp/toiawase.html
この記事が役に立ったらGoodボタンを押してね～
