メッセージの調停(2つ以上のCANコントローラにおいて誰がバスを使用するかについて合意するプロセス)は、データ転送に実際に利用可能な帯域幅のため非常に重要です。
CANコントローラは、アイドルバスを検出したときに送信を開始します。この結果、複数のコントローラは、ほぼ同時にメッセージを開始します。衝突は、次の方法で解決されます。送信ノードは、送信中にバスを監視します。ノードがレセシブレベル自体を送信しているときにドミナントレベルを検出した場合、そのノードはすぐに調停プロセスを終了し、代わりにレシーバになります。調停は、調停フィールド全体に対して実行され、そのフィールドが送信されると、バス上に1つのトランスミッタが残ります。このノードは、何も起こらなかったかのように送信を継続します。他の潜在的なトランスミッタは、バスが次回利用可能になったときにメッセージの再送信を試みます。調停プロセスで時間が失われることはありません。
このビット単位(bit-wise)の調停が成功するための重要な条件は、2つのノードが同じ調停フィールドを送信できないことです。
このルールには1つの例外があります。メッセージにデータが含まれていない場合、どのノードもそのメッセージを送信できます。
バスは接続されており、ドミナントビットは、論理的に0であるため、数値的に最も低い調停フィールドを持つメッセージが調停に勝つことになります。
CANメッセージには明示的なアドレスがないことは、改めて注目に値します。各CANコントローラは、バス上のすべてのトラフィックをピックアップし、ハードウェアフィルタとソフトウェアの組み合わせを使用して、メッセージが"interesting"か、どうかを判断します。
実際、CANにはメッセージアドレスという概念はありません。その代わりに、メッセージの内容は、メッセージのどこかに存在する識別子によって識別されます。CANメッセージは"コンテンツアドレス"("contents-addressed")と呼ばれています。
従来のメッセージアドレスは、"ここにノードXのメッセージがあります"("Here's a message for node X ")のように使用されます。コンテンツアドレス付メッセージは、"ここにXというラベルのついたデータを含むメッセージがあります"("Here's a message containing data labeled X")のようなものです。この2つの概念の違いは小さいですが重要です。
調停フィールドの内容は、標準規格では、バス上でのメッセージの優先度を決定するために使用される。すべてのCANコントローラは、ハードウェアフィルタリング(filtration)プロセスのキーとして、調停フィールドの全体(一部だけを使用する場合もあります)を使用します。
規格は、調停フィールドをメッセージ識別子として使用しなければならないとは言っていません。それにもかかわらず、それは非常に一般的な使用法です。
"Basic CAN"および"Full CAN"という用語は、CANの幼少期に由来します。昔、プログラマにDPRAMスタイルインターフェースを提供するIntel 82526 CANコントローラがありました。その後、Philipsは、FIFO(queue-)指向のプログラミングモデルと制限されたフィルタリング機能を使用した82C200を発表しました。2つのプログラミングモデルを区別するために、何らかの理由で人々はIntelの方法を"Full CAN"と呼び、Philipsの方法を"Basic CAN"と呼びました。現在、ほとんどのCANコントローラでは両方のプログラミングモデルが可能なため"Full CAN"と"Basic CAN"という用語を使用する理由はありません。実際、これらの用語は混乱を引き起こす可能性があり避けるべきです。
勿論、"Full CAN""コントローラは、"Basic CAN"コントローラと通信することができ、その逆も同様です。互換性の問題はありません。
識別子には11(CAN 2.0A)または29(CAN 2.0B)のビットがあると述べました。これは完全に正しいわけではありません。ある古いCANコントローラ(どれだと思いますか?)との互換性のために識別子は、最上位7ビットをすべて1に設定してはいけないので、11ビットの識別子には0..2031だけが残され、29ビットの識別子のユーザは、532676608の異なる値を使用することができます。
他のすべてのCANコントローラは"違法"("illegal")識別子を受け入れているので、最新のCANシステムの識別子2032..2047は、制限なく使用できます。