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

『パッシブ』状態ノードにおける送信待機とエラーフラグ送信

　エラーカウンタが『パッシブ』になるということは、何らかの問題がノードに発生したことを意味する。もし、この状態のノードからエラーフラグが繰り返し送信され、バスの占有が行われてしまうと、他ノードの通信が正常に行えなくなってしまう。

　そこで、これを防止するため、『パッシブ』状態のノードでは送信待機が行われる（図8）。

図8　パッシブ状態ノードにおける送信待機
※ベクター・ジャパンの資料を基に作成

　これは以下のメカニズムにより実現されている。

　通常では、ITM終了後にバスアイドル扱いとなり、ノードは送信を開始できるが、『パッシブ』状態のノードは、ITM終了後に8ビットのリセッシブを受信した後でないとバスアイドルとならない。これにより、正常な他ノードは『パッシブ』状態のノードからの送信に妨害されず、バスへのアクセスを行える。

『パッシブ』状態ノードにおけるエラーフラグ送信

　送信待機と同様に『パッシブ』状態のノードからのエラーフラグにより、通信が妨害されてしまうことを防ぐために、以下のメカニズムが用意されている。

　『パッシブ』状態のノードからのエラーフラグは、6ビットのドミナントではなく、6ビットのリセッシブを送信する。これにより、『パッシブ』ノードが受信時にエラーを検出しても、エラーフラグとして送信されるのは6ビットのリセッシブであり、これは現在行われている通信に対して影響を与えない。

図9　パッシブ状態ノードにおけるエラーフラグ送信（受信時）
※ベクター・ジャパンの資料を基に作成

　ただし、『パッシブ』ノードが送信中にエラーを検出した場合、同時に送信を行うノードはないので、6ビットのリセッシブの送信でも他ノードは6ビットのリセッシブが連続したと判断することが可能であり、異常なデータを受信したと認識できるようになっている。

図10　パッシブ状態ノードにおけるエラーフラグ送信（送信時）
※ベクター・ジャパンの資料を基に作成

　最後に、エラー発生時のCANコントローラの動作についてまとめる。

1．ノードがエラーを検出する。

↓

2．エラーフラグが送信される（プライマリ）。ただし、CRCエラーの場合は実質3ビット遅れ、EOF開始時より送信。また、このエラーフラグは、ノードが『アクティブ』の場合は6ビットのドミナント。ノードが『パッシブ』の場合は6ビットのリセッシブとなる。

↓

3．正常に送信、または受信動作を行っていた他ノードは、このエラーフラグ（プライマリ）をスタッフエラー、もしくはフォームエラーと認識してエラーフラグ（セカンダリ）を送信する。

↓

4．エラーフレームが送信されることにより、データフレーム（またはリモートフレーム）はEOFまで正常に送信できず、中断されてしまう。また、全ノードはエラーとなるので、受信情報は破棄される。

↓

5．エラーカウンタの値が規定どおり加算される。

↓

6．送信ノードが再送信を行う。

　これまで3回にわたり、CANプロトコルの概要を解説してきたが、通常これらの内容についてはCANプロトコルコントローラが実際に制御を行う。場合によっては、ここで解説した内容を理解していなくてもCANを扱うことはできる。しかし、通信時にどのような動作をしているかをきちんと理解しておけば、開発時はもちろんのことトラブルが発生した際の助けになるはずだ。

　さて次回は、CANコントローラの“分類”や“動作”などについて解説する予定だ。（次回に続く）

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