CANを理解するうえで欠かせない“フレーム”の知識：車載ネットワーク“CANの仕組み”教えます（3）（1/3 ページ）

安全面を重視する車載ネットワークでは、仮に通信時にエラーが発生したとても正常な動作を維持し続けなければならない

[増田浩史（ベクター・ジャパン），MONOist]

関連記事：次世代の車載ネットワーク「CAN FD」とは

　連載第2回「CAN通信におけるデータ送信の仕組みとは？」では、CAN（Controller Area Network）のデータ送信の仕組みをテーマに、「データフレーム」と「リモートフレーム」について紹介した。

　今回は残る2つのフレーム

• オーバーロードフレーム
• エラーフレーム

について、その構造や使われ方、これらに関連するエラー処理について詳しく解説する。

※注：CANの前提知識については、第1回「CANプロトコルを理解するための基礎知識」を参照のこと。

	関連リンク：
⇒	CAN通信におけるデータ送信の仕組みとは？
⇒	いまさら聞けない 車載ネットワーク入門

⇒連載バックナンバーはこちら

オーバーロードフレーム

　「オーバーロードフレーム」は、CANコントローラが前回のフレームの処理をまだ完了していないときに、次のフレームの開始を遅延させるために用いられる。

　CANプロトコルが開発されたころは、マイコンチップやCANコントローラの処理能力が低かったため、処理が正常に行われないケースがあった。これを防止するために考え出されたのがオーバーロードフレームだ。例えば、あるデータフレームの処理が終了しないうちに、次のデータフレームを受信してしまうと、結果としてデータ受信が正常に行えない可能性がある。オーバーロードフレームはこのような問題を回避するために使用される。

図1　オーバーロードフレーム
※ベクター・ジャパンの資料を基に作成

　最近のCANコントローラでは、オーバーロードフレームを発生させることはまずないが、CANの仕様に基づいてそれらを処理する機能は存在する。オーバーロードフレームは、以下の「オーバーロードフラグ」と「オーバーロードデリミタ」から構成される。

オーバーロードフラグ

　オーバーロードフラグは6ビットのドミナントから構成される。インターミッション（ITM）の最初の2ビット以内から送信が開始される。オーバーロードフラグを受信したノードは、即座にオーバーロードフラグを送り返す。これにより、最初のオーバーロードフラグとそれにより送信されるオーバーロードフラグとが重なり、結果としてオーバーロードフラグのビット長は、7ビットとなる。

　ちなみに、全ノードが同時にオーバーロードフラグを送信した場合には、オーバーロードフラグのビット長は6ビットとなる。

オーバーロードデリミタ

　オーバーロードデリミタは8ビットのリセッシブから構成され、オーバーロードフレームの区切りを示す。オーバーロードフレームが送信されることにより、バスアイドル開始位置を遅らせることができ、その間に処理が間に合わないノードは処理を行うことができる。

　なお、オーバーロードフラグは、エラーカウンタの値に影響を与えない。

エラーフレーム

　次に、「エラーフレーム」について紹介する。

　エラーフレームは、後述する各種エラーが発生すると送信されるフレームのことで、「エラーフラグ」と「エラーデリミタ」から構成される。これらは、ビットスタッフィングルールに違反、または固定フォーム部分を破壊する形で直近の送信を中断させる。

図2　エラーフレーム
※ベクター・ジャパンの資料を基に作成

　エラーフラグとエラーデリミタの概要は以下のとおりだ。

エラーフラグ

　エラーフラグはエラー発生を他ノードに知らせる目的で使用される。エラーフラグは、通常6ビットのドミナントから構成され、ビットスタッフィングルール違反を発生させる。このビットスタッフィングルール違反によって、他ノードもエラーフラグを送信する。結果として、プライマリとセカンダリを合わせて6〜12ビットのドミナントがエラーフラグとしてバスに現れることになる。

　6〜12ビットとドミナント長が変化する理由は、他ノードがどのタイミングでエラーを検出するかによってプライマリとセカンダリが重なる場合があり、それによりセカンダリ部分は0〜6ビットという扱いになる。これについては後述するエラー検出時の動作にて解説を行う。

　すべてのCANコントローラは、エラー発生状態により内部のエラーカウンタの値を増減させる。これにより、現在ノードがどのような状態であるかを知ることができ、例えばハードウェア故障など深刻な状態のノードからエラーフラグが連続して送信され、結果として通信不能になることを防ぐ仕組みを持っている。

エラーデリミタ

　エラーデリミタは8ビットのリセッシブからなり、エラーフレームを終了させる。データ、またはリモートフレームの終端における1ビットのACKデリミタと7ビットのEOFの部分と同じ、8ビットの連続したリセッシブから構成される。

エラー検出

　続いて、ネットワーク上で発生したエラーをどのように検出するのか見てみよう。

図3　エラー検出
※ベクター・ジャパンの資料を基に作成

　まず、送信ノードでの監視について以下に示す。

1．ビットモニタリング

　送信データとバス上をサンプリングしたデータとの相違をチェックする。相違があればビットエラーとして扱う。ただし、調停フィールドとアクナレッジスロットでは、判定を行わない。

2．アクナレッジチェック

　アクナレッジスロットにおいて該当個所のバス状態がリセッシブのままだった場合、アクナレッジエラーとして扱う。これは、全受信ノードがドミナントを返さなかったとき、すなわち全受信ノードが誤ったメッセージを受信したか、あるいはネットワークに他ノードが接続されていない場合に発生する。

　次に、受信ノードでの監視について以下に示す。

3．CRCチェック

　受信ノードが演算したCRCとフレームに含まれるCRCの値が合致しなかったときに、CRCエラーとして扱う。

4．フォームチェック

　CRCデリミタ、アクナレッジデリミタ、またはEOFは通常、リッセシブと決められている。このリセッシブ固定の場所でドミナントが検出されたときはフォームエラーとして扱う。

5．スタッフチェック

　ビットスタッフィングルールが守られているかを監視する。ビットスタッフィングエリア内で同一レベルが6ビット以上継続した場合はスタッフエラーとして扱う。

　以上、5種類のエラー検出機構において、ネットワーク上で発生したエラーを発見できるようになっている。これらのエラーが発見された場合、エラーフラグ（6ビットのドミナント）が即座に送信される。ただし、CRCエラーの場合はEOFの最初のビットまでエラーフラグは送信されない。