IBS Japan

PART 2：CANメッセージ, Part 1

日本語字幕設定方法はこちら

CANメッセージ

CAN busは、同報タイプのバスです。これは、すべてのノードがすべての送信を"hear"することを意味します。特定のノードだけにメッセージを送信する方法はありません。すべてのノードは、常にすべてのトラフィックをピックアップします。ただし、CAN ハードウェアはローカルフィルタリングを提供するため各ノードは、対象メッセージに対してのみ反応できます。

CANは、最大ユーティリティ負荷が94ビットのショートメッセージを使用します。メッセージには明示的なアドレスがありません。
代わりにメッセージは、内容アドレス指定されていると言うことができます。つまり、メッセージの内容によって暗黙的にアドレスが決定されます。

メッセージのタイプ

CAN busには、次の4つの異なるメッセージタイプ（または"frames"）があります：

1. データフレーム（Data Frame）
2. リモートフレーム（Remote Frame）
3. エラーフレーム（Remote Frame）
4. オーバーロードフレーム（Overload Frame）

1. データフレーム

Summary: "Hello everyone, here's some data labeled X, hope you like it!"
概要："みなさん、こんにちは。Xというラベルの付いたデータがあります。気に入っていただければ幸いです！"

データフレームは、最も一般的なメッセージタイプです。以下の主要な部分から構成されています（簡潔さのため、いくつかの詳細は省略しています）。

• 調停フィールド（Arbitration Field）は、2つ以上のノードがバスをめぐって競合している場合のメッセージの優先度を決定します。調停フィールドには以下が含まれます：
  • CAN 2.0Aの場合、11ビットの識別子と1ビットのRTRビット。これはデータフレームで"ドミナント"です。
  • CAN 2.0Bの場合、29ビット識別子(これはSRRとIDEの2つの"レセッシブ"ビットが含まれています)。
• データフィールドには、0～8バイトのデータが含まれています。
• CRCフィールドには、メッセージのほとんどの部分で計算された15ビットチェックサムを含んでいます。このチェックサムは、エラー検出に使用されます。
• Acknowledgementスロット：メッセージを正しく受信できたCANコントローラは、各メッセージの最後にAcknowledgementビットを送信します。トランスミッタは、Acknowledgementビットの有無をチェックし、Acknowledgementが検出されなかった場合は、メッセージを再送信します。

• （注1）バス上にアクノレッジビットが存在しても、意図した宛先のいずれかがメッセージを受信したことを意味しないことは、注目に値します。私たちが知っているのは、バス上の1つまたは複数のノードがそれを正しく受信したということだけです。
• （注2）調停フィールドの識別子は、その名前にもかかわらず、必ずしもメッセージの内容を識別していません。

CAN 2.0B ("拡張CAN")データフレーム

2. リモートフレーム

Summary: "Hello everyone, can somebody please produce the data labeled X?"
概要："みなさん、こんにちは。誰かXというラベルの付いたデータを作成してくれませんか？"

リモートフレームは、データフレームと同じですが、2つの重要な違いがあります：

• リモートフレームとして明示的にマークされ（調停フィールドのRTRビットは、レセッシブです
• データフィールドはありません

リモートフレームの意図された目的は、対応するデータフレームの送信を要求することです。例えば、ノードAが調停フィールドで234に設定されたリモートフレームを送信する場合、ノードBは、適切に初期化されていれば、調停フィールドも234に設定されたデータフレームで応答する可能性があります。

リモートフレームは、request-responseタイプのバストラフィックマネージメントを実装するために使用することができます。しかし、実際には、リモートフレームはほとんど使用されていません。また、CAN規格では、ここで概説されている動作は規定されていません。ほとんどのCANコントローラは、リモートフレームに自動的に応答するようにプログラムするか、ローカルCPUに通知するようにプログラムすることができます。

リモートフレーム(2.0A type)

リモートフレームには1つの問題があります：データ長コードは、期待される応答メッセージの長さに設定する必要があります。そうしないと、調停は機能しません。

リモートフレームに応答するノードは、識別子が認識されるとすぐに送信を開始し、これにより空のリモートフレームを"filling up"と主張されることがあります。これは、そうではありません。

3. エラーフレーム

Summary: (everyone, aloud) "OH DEAR, LET'S TRY AGAIN"
概要: (みんな声を出して）"もう一度やってみよう"

簡単に言えば、エラーフレームは、CANメッセージのフレームルールに違反する特別なメッセージです。ノードがフォルトを検出したときに送信され、他のすべてのノードにフォルトを検出させます。その後、トランスミッタは、自動的にメッセージの再送信を試みます。エラーカウンタの精巧なスキームがありノードがエラーフレームを繰り返し送信することでバス・トラフィックを破壊できないことを保証します。

エラーフレームは、同じ値の6ビットのエラーフラグ（従って、bit-stuffingルールに違反します）と8ビットのレセシブビットであるエラーデリミタ（Error Delimiter）から構成されます。エラーデリミタは、バス上の他のノードが最初のエラーフラグを検出したときに、そのエラーフラグを送信できるスペースを提供します。

エラーフレーム

4. オーバーロードフレーム

Summary: "I'm a very busy little 82526, could you please wait for a moment?"
概要："私は非常に忙しい小さな82526ですが、ちょっと待っていてもらえますか?"

ここでは、完全を期すためにオーバーロードフレームについて説明します。フォーマットに関してはエラーフレームと非常によく似ており、ビジー状態になりすぎたノードによって送信されます。今日のCANコントローラは、それを使用しないほど賢いので、オーバーロードフレームはあまり使用されません。実際、オーバーロードフレームを生成する唯一のコントローラは、現在、廃止されている82526です。

標準 vs. 拡張CAN

もともと、CAN規格は、調停フィールドでの識別子の長さを11(11)ビットに定義しました。その後、カストマの要求により規格の拡張が余儀なくされました。新しいフォーマットは、拡張CAN（Extended CAN）と呼ばれることが多く、識別子で少なくとも29ビットを許可します。2つのフレームタイプを区別するためにコントロールフィールドの予約ビットが使用されました。

規格は、正式に次のように呼ばれています：

• 2.0A、11ビット識別子のみ、
• 2.0B、フル29ビット識別子による拡張バージョン(または11ビット、それらを混在可能)。2.0Bノードは、
  • "2.0B active"つまり拡張フレームを送受信できる、または
  • "2.0B passive"つまり受信した拡張フレームを黙って破棄(ただ、以下を参照)
• 1.xは、オリジナルの仕様とその改訂版を参照します。

今日の新しいCANコントローラは、通常2.0Bタイプです。1.xまたは2.0Aタイプのコントローラは、29の調停ビットによるメッセージを受信すると非常に動揺します。2.0B passive typeコントローラは、それらのメッセージを許容し、それらが正しい場合は、それらをacknowledgeしてから破棄しますが2.0B activeタイプコントローラは、それらを送信することも受信することができます。

2.0Bおよび2.0A(および1.x)を実装するコントローラは、互換性があり、2.0Bを実装するコントローラが拡張フレームの送信を控えている限り、同じバスで使用できます！

拡張CANメッセージのオーバーヘッドが大きいため標準CANが拡張CANよりも"優れている"という主張があります。これは必ずしも真実ではありません。データの送信に調停フィールドを使用する場合、拡張CANは、実際には標準CANよりも低いオーバーヘッドである可能性があります。

PART 3：CANメッセージ Part 2