製品・技術情報
KVASER CANプロトコルとは？（CANプロトコルチュートリアル）
- 2022.02.22
PART 8：CANエラー処理
CANのエラー処理方法
エラー処理は、CANプロトコルに組み込まれており、CANシステムのパフォーマンスにとって非常に重要です。エラー処理は、CAN bus上に表示されるメッセージのエラーを検出することを目的としており、トランスミッタが誤りメッセージ（erroneous message）を再送信できるようにします。バスに沿ったすべてのCANコントローラは、メッセージ内のエラーを検出しようとします。エラーが見つかった場合、検出ノードは、エラーフラグを送信し、bus trafficを破棄します。他のノードは、エラーフラグによって引き起こされたエラーを検出し(オリジナルのエラーがまだ検出されていない場合)、適切なアクションを実行します。即ち、現在のメッセージを破棄します。
各ノードは、送信エラーカウンタと受信エラーカウンタの2つのエラーカウンタを保持しています。これらのカウンタのインクリメントおよび/またはデクリメントの方法を制御するルールがいくつかあります。本質的に障害を検出したトランスミッタは、リスニングノードが受信エラーカウンタをインクリメントするよりも速く送信エラーカウンタをインクリメントします。というのも、落ち度があるのは発信者側だ！という可能性が高いからです。というのは、トランスミッタが故障している可能性が高いためです！エラーカウンタが特定の値を超えるとノードは、最初に"error passive"となり、エラーを検出してもバス・トラフィックを積極的に破壊しません。その後"bus off"になり、これは、ノードがbus trafficにまったく参加しないことを意味します。
エラーカウンタを使用することでCANノードは、障害を検出するだけでなく、エラー閉じ込めを行うことができます。
エラー検出メカニズム
CANプロトコルは、エラーを検出する少なくとも5つ以上の異なる方法を定義します。これらのうちの2つは、ビットレベルで動作し、残りの3つは、メッセージレベルで動作します。
- ビット監視
- Bit Stuffing
- フレームチェック（Frame check）
- Acknowledgementチェック
- サイクリック冗長チェック
- 1.ビット監視
- CAN bus上の各トランスミッタは、送信された信号レベルを監視します(つまり、読み返す)。実際に読み取られたビットレベルが送信されたビットレベルと異なる場合は、Bit Errorが通知されます。(調停処理中はBit Errorは発生しません)。
- 2.Bit Stuffing
- 同じレベルの5つの連続するビットがノードによって送信されると、反対のレベルの6番目のビットが送信ビットストリームに追加されます。レシーバは、この余分なビットを削除します。これは、バス上の過剰なDCコンポーネントを避けるために行われますが、受信機がエラーを検出する機会を増やすためにも行われます。バス上で同じレベルのビットが5つ以上連続して発生した場合、Stuff Errorが通知されます。
- 3.フレームチェック（Frame check）
- CANメッセージの一部は、固定フォーマットをもっています。つまり、規格では、どのレベルがいつ発生するかを正確に定義されています。(いくつかの部分とは、CRCデリミタ、ACKデリミタ、End of Frame、およびIntermissionですが、そのために特別なエラーチェックルールがいくつかあります)。CANコントローラがこれらの固定フィールドの1つで無効な値を検出するとフォームエラーが通知されます
- 4.Acknowledgementチェック
- メッセージを正しく受信するバス上のすべてのノード(その内容に"interested"であるかどうかに関わらず)は、メッセージ内のいわゆるAcknowledgementスロットでドミナントレベルを送信することが期待されます。トランスミッタは、ここでレセッシブレベルを送信します。トランスミッタがACKスロット内のドミナントレベルを検出できない場合、Acknowledgementエラーが通知されます。
- 5.Cyclic Redundancy Check（サイクリック冗長チェック）
- 各メッセージは、15ビットのCyclic Redundancy Checksum(CRC)を備え、メッセージ内でそれ自身が計算されたものとは異なるCRCを検出したノードはCRCエラーを通知します。
エラー抑制メカニズム
バスに沿ったすべてのCANコントローラは、各メッセージ内で上記のエラーを検出しようとします。エラーが見つかった場合、検出ノードは、エラーフラグを送信し、bus trafficを破棄します。他のノードは、エラーフラグによって引き起こされたエラーを検出し（オリジナルのエラーをまだ検出していない場合）、適切なアクションを実行します。つまり、現在のメッセージを破棄します。
各ノードは、送信エラーカウンタと受信エラーカウンタの2つのエラーカウンタを保持します。これらのカウンタのインクリメントおよび/またはデクリメントの方法を制御するルールがいくつかあります。本質的にエラーを検出するトランスミッタは、listeningノードが受信エラーカウンタをインクリメントするよりも速く送信エラーカウンタをインクリメントさせます。これは、トランスミッタが故障している可能性が高いためです！
ノードは、Error Active modeを起動します。2つのエラーカウンタのいずれかが127を超える場合、ノードは、Error Passiveと知られる状態に入り、送信エラーカウンタが255を超えた場合、ノードは、Bus Off状態に入ります。
- Error Activeノードは、エラーを検出するとActive Errorフラグを送信します。
- Error Passiveノードは、エラーを検出するとPassive Errorフラグを送信します。
- Bus Offのノードは、バス上に何も送信しません。
エラーカウンタの増加と減少のルールは、やや複雑ですが原則は単純です。即ち、送信エラーは、8エラーポイントを与え、受信エラーは、1エラーポイントが与えられます。正しく送信されたメッセージおよび/または受信メッセージによりカウンタが減少します。
例（少し簡略化したもの）：バスのノードAが何をやってもうまくいかない日があると仮定しましょう。Aがメッセージを送信しようとすると、(どんな理由であれ)失敗します。これが起こるたびにノードは、送信エラーカウンタを8増加させ、Active Errorフラグを送信します。その後、メッセージの再送信を試みますが同じことが起こります。
送信エラーカウンタが127を超える(つまり16回試行した後)場合、ノードAは、Error Passiveになります。違いは、バス上でPassive Errorフラグを送信するようになったことです。Passive Errorフラグは、6レセッシブビットで構成され、他のバス・トラフィックを破壊しません。従って、他のノードは、バスエラーについてのAの不平を聞くことはありません。しかしながら、Aは、送信エラーカウンタを増やし続けます。255を超えるとノードAは最終的に屈服し、Bus Offになります。
他のノードは、ノードAについて何を考えているのでしょうか？ Aが送信したactive errorフラグごとに他のノードは、受信エラーカウンタを1つ増加させます。AがBus Offになるまでに他のノードの受信エラーカウンタのカウントは、Error Passiveの制限値（127）を大きく下回ります。このカウントは、正しく受信されたメッセージごとに1ずつ減少します。しかしながら、ノードAは、bus offのままです。
ほとんどのCANコントローラは、2つの状態に対応するステータスビット（および対応する割り込み）を提供します：
- "Error Warning" - 一方または両方のエラーカウンタが96を超えている状態
- 上記のようにBus Off
いくつかのコントローラは、すべてではありませんがError Passive状態のビットを提供します。また、いくつかのコントローラは、エラーカウンタへの直接アクセスを提供します。
エラーを発生したときにメッセージを自動的に再送信するCANコントローラは、時に煩わしい場合があります。市販されているコントローラの中には、エラー処理を完全に手動で制御できるものが少なくとも1つあります（PhilipsのSJA1000）。
バス障害モード
ISO 11898規格は、CAN busケーブルのいくつかの障害モードを列挙します：
- CAN_H が切断
- CAN_L が切断
- CAN_H がバッテリ電圧に短絡
- CAN_L がグランドに短絡
- CAN_H がグランドに短絡
- CAN_L がバッテリ電圧に短絡
- CAN_L がCAN_Hワイヤに短絡
- CAN_HおよびCAN_L が同じ場所で中断
- 終端ネットワークへのコネクションの喪失
障害1〜6および9の場合、バスは、S/N比を下げて生き残ることが「推奨」され、障害8の場合は、結果として得られるサブシステムが生き残ることになります。障害7の場合、S/N比を下げて生き残ることは"optional"です。
実際には、82C250タイプのトランシーバを使用したCANシステムは、障害1〜7には耐えられず、障害8〜9は耐えられる場合と耐えられない場合があります。
TJA1053のようなすべての障害を処理できる"fault-tolerant"ドライバがあります。通常、TJA1053の場合、このfault toleranceに対する最大スピードは125 kbit/sと制限されています。