自動車部品の検査設備で ECU と CAN 通信をしようとしたときに、「フレームを送っているのに ECU が反応しない」という壁にぶつかることがあります。
多くの場合、原因はビットレートや ID ではなく、フレームに載せるべき保護情報が入っていないことです。カウンタ、チェックサム、メッセージ認証コードといった仕組みが、実車では当たり前に載っています。
この記事では、それぞれが何を守っている仕組みなのかと、検査設備側でどう実装するかを整理します。
なぜ検査設備にも車載の作法が要求されるのか
ECU は受信したフレームの中身をそのまま信用しません。使う前に、少なくとも次を検証します。
- 途中で壊れていないか
- 順番どおりに届いているか、同じものが二度来ていないか
- 正規の相手が送ったものか
検証に通らなかったフレームは無視されるか、エラーとして扱われます。フェイルセーフ状態に遷移したり、DTC（故障コード）が記録されたりすることもあります。
つまり、検査設備が実車と同じ形式のフレームを出せなければ、ECU はそもそも応答してくれません。ラインの設備であっても、車載の作法をそのまま実装する必要があるということです。
「検査だから簡略化した通信でいい」とはならない、というのがここでのポイントです。
3つの仕組みが守っているもの
| 仕組み | 検出できること | 典型的なサイズ |
|---|---|---|
| カウンタ | 取りこぼし、順序の入れ替わり、同じフレームの再送（リプレイ） | 4 ビット / 8 ビット |
| チェックサム・CRC | データの破損、別メッセージの紛れ込み | 1 バイト / 2 バイト |
| メッセージ認証コード（MAC） | 改ざん、なりすまし | 数バイト（切り詰めて使う） |
役割が重なっていないことに注目してください。3つとも必要だから3つ載っているのであって、どれかで代用できるものではありません。
カウンタ（Alive Counter / Sequence Counter）
送信のたびに 1 ずつ増やし、上限に達したら 0 に戻る値です。受信側は「前回の値 + 1」が来ることを期待します。
- 値が飛んでいれば、その間のフレームを取りこぼしている
- 値が進んでいなければ、同じフレームを二度受け取っている（あるいは送信が止まっている）
4 ビットなら 0〜15 の巡回です。案件によっては特定の値を欠番にしたり、8 ビットで運用したりと、細部は仕様書によって変わります。
なお、カウンタが正しく連続していることが前提になっているため、通信経路のどこかでフレームを落とすと即座にエラーとして表面化します。この点は PLCのUDP受信性能とCANフレームの取りこぼし とも関係します。
チェックサム・CRC（AUTOSAR E2E Profile 5）
E2E は End-to-End Protection、つまり「送信元から受信先まで、途中の経路で何が起きても検出できるようにする」という考え方です。AUTOSAR で複数のプロファイルが規定されており、CAN でよく使われるもののひとつが Profile 5 です。
Profile 5 が使う要素は3つです。
- 2 バイトの CRC — CRC-16 で計算します。単純な総和（SUM）よりビット化けの検出力が高く、複数ビットが同時に化けても検出できます
- 1 バイトのカウンタ — 上で説明した役割を担います
- Data ID（16 ビット） — メッセージごとに割り当てる固有の値です
3 つ目の Data ID が Profile 5 の要点です。この値はフレームには載せず、CRC の計算にだけ混ぜます。こうしておくと、正しい CRC を持った別のメッセージが紛れ込んでも、受信側が期待する Data ID とは一致しないため CRC 検証に失敗します。メッセージの取り違えを検出できる、というわけです。
単なるチェックサムとの違いはここにあります。チェックサムは「データが壊れていないか」しか見ませんが、Profile 5 は「壊れていないか」「順番は正しいか」「そもそも期待しているメッセージか」を同時に見ています。
メッセージ認証コード（AES-128 CMAC）
CRC は偶発的な破損を検出する仕組みであって、悪意のある改ざんには無力です。値を書き換えたうえで CRC を計算し直せば、そのまま通ってしまいます。
そこで使われるのが MAC（Message Authentication Code）です。CMAC は共通鍵ブロック暗号を使った MAC の方式で、AES を使うものが AES-CMAC、鍵長 128 ビットなら AES-128 CMAC となります。NIST SP 800-38B で標準化されています。
- 送信側と受信側が同じ鍵を持つ
- 送信側はデータから MAC を計算してフレームに載せる
- 受信側は同じ計算をして一致を確認する
- 鍵を知らない第三者は正しい MAC を作れないため、改ざんもなりすましも検出できる
CAN のデータ長は限られているため、128 ビットの計算結果をそのまま載せることはできません。先頭の数バイトに切り詰めて載せるのが一般的です（truncated MAC）。また、同じデータなら同じ MAC になってしまうため、カウンタなどのフレッシュネス値と組み合わせてリプレイを防ぎます。AUTOSAR ではこの枠組みが SecOC（Secure Onboard Communication） として規定されています。
PLC のラダーで実装するのは現実的か
ここまでの処理を、PLC 側のラダープログラムで実装することを考えてみます。
CRC-16 の計算は、テーブル参照かビットシフトのループで書けます。ラダーで組めないことはありません。ただし、これを送信するフレームごとに、送信のたびに回す必要があります。
AES-128 CMAC はさらに重くなります。サブキーの生成に加えて AES のブロック暗号処理そのものが必要で、ラダーでの実装は工数も、検証コストも、レビューの負担も大きくなります。
そして定期送信は 1ms 周期から要求されます。周期が来るたびに、カウンタを更新し、CRC を計算し、MAC を計算することになり、これがスキャンタイムを直撃します。スキャンタイムが延びれば受信処理にも影響が出ます。
加えて、仕様変更のたびにラダーの改修と再検証が発生します。Data ID が変わった、周期が変わった、鍵が変わった、といった変更は珍しくありません。
これらを考えると、送信の直前に通信機器側で計算して埋めるほうが素直な設計になります。PLC は「このデータを、この ID で、この周期で送る」とだけ指示すればよく、保護情報の付加は機器に任せられます。
CANNEX での扱い
CANNEX では、定期送信・単発送信を登録する際に送信補助タイプを番号で指定するだけです。カウンタの更新も CRC の計算も CMAC の計算も、CANNEX が送信のたびに行います。
| タイプ | 内容 | 必要な DLC |
|---|---|---|
| 0 | 補助なし | 制約なし |
| 1 | 4 bit カウンタ + チェックサム | 8 以上 |
| 2 | D7 下位 4 bit カウンタ | 8 以上 |
| 3 | 7 byte カウンタ | 8 以上 |
| 4 | E2E Profile 5 / CRC | 8 以上（推奨） |
| 5 | AES-128 CMAC | 8 以上 |
| 6 | E2E Profile 5 + AES-128 CMAC | 14 以上 |
| 7 | Counter(D6) + SUM(D7) | 8 以上 |
定期送信は CANNEX 内部のタイマで動くため、カウンタの更新も暗号計算も PLC のスキャン周期から完全に独立します。PLC 側のラダーには、ビット演算も暗号処理も一切現れません。
実際に検討されるときの注意点
鍵や Data ID は案件ごとに異なります。 標準規格に沿っていても、実際に使う値、フレームのどこに何を配置するか、カウンタの巡回範囲といった細部は仕様書で決まります。対応可否の判断には仕様の確認が必要です。
仕様書（または DBC / ARXML）をご提示いただければ、対応できるかどうかを確認します。 既存の送信補助タイプで対応できる場合もあれば、ファームウェアの追加対応が必要な場合もあります。実際、既存タイプで足りないケースでは追加対応を行っています。
評価はデモ機で行ってください。 ECU が実際に受信を受け付けるかどうかは、実機で確認するのが確実です。
まとめ
- ECU は保護情報を検証してからデータを使うため、検査設備も実車と同じ形式のフレームを出す必要がある
- カウンタは順序と重複、CRC は破損と取り違え、MAC は改ざんとなりすましを検出する。役割は重ならない
- AUTOSAR E2E Profile 5 は「2 バイト CRC + 1 バイトカウンタ + 送信しない Data ID」で構成される
- AES-128 CMAC は共通鍵で計算する MAC で、鍵を持たない相手は正しい値を作れない
- これらを PLC のラダーで実装するとスキャンタイムと検証コストを圧迫する。通信機器側で付加するほうが素直
- CANNEX は送信補助タイプを番号で指定するだけで、計算を自動で行う
対応可否のご相談は お問い合わせ から承ります。仕様書をご提示いただければ確認いたします。