CAN 通信を PLC（シーケンサ）で扱う設備で、いちばん厄介なトラブルが 受信フレームの取りこぼし です。
立ち上げのときは問題なく動き、量産が始まってしばらくしてから「たまに検査が NG になる」という形で表面化します。再現性が低く、原因の切り分けに時間がかかります。
この記事では、取りこぼしがどういう仕組みで起きるのかを流量の計算から追い、設計段階で何を決めておけばよいかを整理します。
CAN バスは受信側の都合を待たない
まず前提として、CAN には「受信側が準備できるまで待つ」という仕組みがありません。
ECU や実機は自分の周期でフレームを送り続けます。受信側が処理しきれていても、いなくても、バスにはフレームが流れ続けます。TCP のようなフロー制御はなく、受け取れなかったフレームは単に失われます。
そして取りこぼしが起きる場所は、多くの場合 CAN バス上ではありません。変換機器から PLC へ渡すところです。CAN 側は専用のコントローラが取りこぼしなく受けているのに、その先の PLC が処理しきれない、という構図になります。
なお、PLC で CAN を扱うための方式そのものについては PLC（シーケンサ）でCAN / CAN FD通信を行う方法 で整理しています。この記事は、そのうち Ethernet（UDP）変換方式を選んだ場合の設計上の勘所にあたります。
どれくらいの流量になるのか
感覚ではなく数字で見ておくと、必要な性能の当たりがつきます。
標準 CAN の場合
11 ビット ID・データ 8 バイトの CAN フレームは、フレーム間スペースまで含めて 111 ビットです。これに CAN 特有のビットスタッフィング（同じ値が 5 ビット続くと反対の値を 1 ビット挿入する）が加わるため、最悪の場合は 135 ビット程度になります。
ボーレート 500kbps では 1 ビットが 2µs なので、1 フレームあたり 222〜270µs。バスを 100% 占有したとして毎秒 3,700〜4,500 フレームです。
実際の設備でバス占有率 100% はあり得ないので、仮に 40% で見積もると：
| ボーレート | バス占有率 40% のときのフレーム数 |
|---|---|
| 500 kbps | 毎秒 約 1,500〜1,800 フレーム |
| 1 Mbps | 毎秒 約 3,000〜3,600 フレーム |
毎秒 1,500 フレームということは、平均 0.67ms に 1 フレームです。PLC のスキャン周期と比べてみてください。
CAN FD の場合
CAN FD ではアービトレーションフェーズは従来どおりの速度で、データフェーズだけが高速（2Mbps、5Mbps など）になります。フレーム数そのものは劇的に増えませんが、1 フレームで最大 64 バイトを運べる点が効いてきます。
同じフレーム数でも、PLC へ渡るデータ量は最大で 8 倍です。取りこぼしの検討では「毎秒何フレームか」だけでなく「毎秒何バイトか」でも見積もる必要があります。
PLC 側で何が起きているか
受信バッファとスキャン周期
PLC の Ethernet ユニットは、受信した UDP パケットをいったん内部のバッファに積みます。ラダープログラムがそれを取り出すのは、スキャンのタイミングです。
ここで単純な計算をします。毎秒 1,600 フレーム、スキャン周期 10ms とすると、1 スキャンのあいだに 16 フレームが積まれる計算になります。バッファの段数がこれを下回っていれば、その時点で溢れます。
さらに重要なのは、この 16 という数字は平均値でしかないということです。実際の設備では、複数の ECU が同期して送出する瞬間や、イベント送信が重なる瞬間があります。取りこぼしはバーストで決まるので、最悪値で見積もらなければ意味がありません。「平均では足りている」は根拠になりません。
1 スキャンあたりに取り出せる件数
バッファに積まれていても、ラダーが取り出さなければ意味がありません。受信命令を 1 スキャンで何回回せるかが、そのまま処理能力の上限になります。
やっかいなのは、受信処理を厚くするとスキャンタイムが延びることです。スキャンが延びれば 1 スキャンあたりに積まれるフレーム数も増えるので、対策が対策になっていない、という状態になりやすいところです。
製品によって差が大きい
そしてここが本題ですが、UDP の受信処理をどう実装しているかは PLC の Ethernet ユニットによって大きく異なります。
- 受信をスキャンに同期して取り込むのか、割り込みで取り込むのか
- 内部バッファを何段持っているか
- 1 スキャンで処理できるパケット数に上限があるか
これらはカタログの「対応プロトコル：UDP」という一行からは読み取れません。同じ「UDP 対応」でも、実際に毎秒どれだけのパケットを取りこぼさず処理できるかは、実測しないと分かりません。
取りこぼすと何が起きるか
取りこぼしそのものより、その後に起きることのほうが問題です。
- カウンタの不連続 — 車載向けのフレームにはカウンタやチェックサムが載っていることが多く、値が飛べば受信側はシーケンスエラーと判定します。ECU が受信を拒否したり、DTC を記録したりします
- 検査の誤判定 — ワークは正常なのに設備側の都合で NG になります。再検査が発生し、歩留まりの数字も汚れます
- ログの欠落 — トレーサビリティのために全フレームを保存している場合、記録の信頼性そのものが失われます
- 再現しない不具合 — 負荷が高いときだけ出るため、調査のために設備を止めても再現しません。原因が特定できないまま「たまに出る現象」として残り続けます
とくに最後の性質が厄介です。立ち上げ時の確認では通ってしまい、量産開始後に出てくるため、対策の手戻りが大きくなります。
設計段階で取れる対策
1. 受信フィルタで必要な ID だけに絞る
最も効果が大きい対策です。バス上の全フレームを PLC へ上げる必要があるケースはあまりありません。検査で判定に使う ID だけに絞れば、PLC へ渡る流量を一桁減らせることもあります。
CANNEX には受信フィルタを設定する FILT コマンドがあり、CANNEX 側でフィルタしてから PLC へ転送します。PLC 側で受信してから捨てるのでは意味がないので、変換機器の側でフィルタできるかを確認してください。
2. ログ取得は PLC から分離する
「判定に使うデータ」と「記録として残すデータ」を分けます。記録が目的なら、PLC ではなく同じネットワーク上の PC で受ければ、PLC の負荷とは無関係になります。
CANNEX の場合、無償の Windows アプリ CANNEX Control Ex が受信モニタと CSV 保存を行えます。設備を止めずに CAN の流れを確認できるので、立ち上げ時の切り分けにも使えます。
3. 最悪値で見積もる
平均のバス占有率ではなく、同期送出やイベント集中が重なった瞬間を想定して必要な受信性能を出します。そのうえで、バッファ段数と 1 スキャンあたりの取り出し件数が足りるかを確認します。
4. 実機で確認する
最終的にはこれに尽きます。カタログのスペックからは、実際に取りこぼすかどうかは判断できません。想定に近い流量を流して、フレームの抜けが出ないことを確認するのが確実です。
当社が推奨 PLC 構成を明記している理由
CANNEX のサイトでは、推奨構成として KEYENCE KV-8000 + KV-XLE02 を明記しています。「どの PLC でも使えます」と書いたほうが売りやすいのは分かっていますが、あえてそうしていません。
理由はここまで説明したとおりで、PLC の Ethernet ユニットによって UDP の受信性能に大きな差があり、それが取りこぼしの有無を左右するからです。当社ではこの構成で実測評価を行い、動作を確認しています。
推奨構成以外の PLC でも、通信量が少ない場合や、多少の取りこぼしを許容できる用途であれば使えることがあります。ただしその判断は案件ごとの条件によって変わるため、事前にご相談いただくようお願いしています。
後から「やはり取りこぼしは許容できない」となったときに困るのは設備をつくった側です。曖昧なまま話を進めないほうが、結果的に双方にとって良いと考えています。
まとめ
- CAN バスにフロー制御はなく、受け取れなかったフレームは失われる
- 500kbps・バス占有率 40% で毎秒 1,500〜1,800 フレーム。スキャン 10ms なら 1 スキャンに 16 フレームが積まれる
- 取りこぼしはバーストで決まるので、平均ではなく最悪値で見積もる
- UDP の受信性能は PLC の Ethernet ユニットによって差が大きく、カタログからは読み取れない
- 対策として最も効くのは、変換機器の側で受信フィルタをかけて PLC へ渡す量を減らすこと
- 最終確認は実機で行う
実際の流量で成立するかどうかは、デモ機でご確認いただけます。想定される ID 数・周期・ボーレートをお知らせいただければ、構成のご相談も承ります。