技術情報

概要

CANは、"Controller Area Network"の略です。Controller Area Networkは、ISO 11898規格で定義される電子通信バスです。これらの規格は、通信のしくみ、配線の構成方法、メッセージの構築方法などを定義します。総称して、このシステムはCAN busと呼ばれます。
このCANプロトコルチュートリアルでは、ISO 11898-1およびISO 11898-2コントローラエリアネットワーク規格の概要を説明します。このチュートリアルでは、自動車設計、産業オートメーションコントロール、およびより多くのアプリケーションで使用されるCAN(controller area network)の基礎について解説します。

PART 1：概要 CAN Bus

CAN busは、ブロードキャストタイプのバスです。これは、すべてのノードがすべての送信を"hear"することができることを意味します。特定のノードだけにメッセージを送信する方法ではありません。従って、すべてのノードは必ずすべてのトラフィックをピックアップます。しかしながら、CANハードウェアはローカルフィルタリングを提供することで各ノードは interestingであるメッセージだけに反応するようにします。

バスは、bit-stuffing（ビット挿入）によるNon-Return To Zero (NRZ)を使用します。このシステムにおいてモジュールは、有線方式でバスに接続されます。1つのノードだけがバスを論理0に駆動している場合、論理1を送信しているノードの数に関係なく、バス全体がその状態になります。

CAN規格では、4つの異なるメッセージタイプが定義されています。メッセージは、ビットごとの調停のクレバーなスキームを使用してバスへのアクセスを制御し、各メッセージには優先度のタグが付けられます。

また、CAN規格はエラー処理と閉じ込めのための精巧なスキームを定義しており、これはPART 8：CANエラー処理で詳しく説明されています。

ビットタイミングとクロック同期は、このチュートリアルのPART 7：CANビットタイミングで説明しています。これはCAN busパラメータおよびレジスタセッティングをするために使用できるビットタイミングカルキュレータ（bit timing calculator）です。

CANは様々な物理層を使って実装することができます（PART 4:CAN物理層を参照）、その一部はここに記載され、また、いくつかのCAN busコネクタタイプは、PART 6のCANコネクタが使用されています。また、メッセージの詳細に興味のある方のためにオシロスコープの写真(PART 5)を提供します。

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）調停フィールドの識別子は、その名前にもかかわらず、必ずしもメッセージの内容を識別していません。

2. リモートフレーム

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

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

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

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

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

リモートフレームには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

アドレス指定、調停、および識別：メッセージがコントローラに到達する方法

バスの調停とメッセージの優先順位

メッセージの調停(2つ以上のCANコントローラにおいて誰がバスを使用するかについて合意するプロセス)は、データ転送に実際に利用可能な帯域幅のため非常に重要です。

CANコントローラは、アイドルバスを検出したときに送信を開始します。この結果、複数のコントローラは、ほぼ同時にメッセージを開始します。衝突は、次の方法で解決されます。送信ノードは、送信中にバスを監視します。ノードがレセシブレベル自体を送信しているときにドミナントレベルを検出した場合、そのノードはすぐに調停プロセスを終了し、代わりにレシーバになります。調停は、調停フィールド全体に対して実行され、そのフィールドが送信されると、バス上に1つのトランスミッタが残ります。このノードは、何も起こらなかったかのように送信を継続します。他の潜在的なトランスミッタは、バスが次回利用可能になったときにメッセージの再送信を試みます。調停プロセスで時間が失われることはありません。

このビット単位（bit-wise）の調停が成功するための重要な条件は、2つのノードが同じ調停フィールドを送信できないことです。
このルールには1つの例外があります。メッセージにデータが含まれていない場合、どのノードもそのメッセージを送信できます。

バスは接続されており、ドミナントビットは、論理的に0であるため、数値的に最も低い調停フィールドを持つメッセージが調停に勝つことになります。

Q: ノードがバス上に単独で存在する場合、送信しようとするとどうなりますか？

A: 勿論、ノードは、調停に勝ち、喜んでメッセージ送信を進めます。しかし、確認の時が来たら...どのノードもACKスロットの間にドミナントビットを送信しないのでトランスミッタは、ACKエラーを検知し、エラーフラグを送信し、送信エラーカウンタを8増加させ、再送信を開始します。これを16回繰り返すとトランスミッタは、error passiveになります。エラー封じ込めアルゴリズム（error confinement algorithm）の特別なルールにより、ノードがerror passiveでエラーがACKエラーの場合、送信エラーカウンタはさらに増加しません。従って、ノードは、少なくとも誰かがメッセージを承認するまで、永遠に送信し続けます。

メッセージのアドレス指定と識別

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

"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は、制限なく使用できます。

PART 4：CAN物理層

CAN bus

CAN busは、bit-stuffingを使用したNon-Return To Zero(NRZ)を使用しています。ドミナント(論理的に0)とレセッシブ(論理的に1)がある2つの異なるシグナル状態があります。これらは、使用される物理層（いくつかあります）に依存する特定の電気レベルに対応しています。モジュールは、有線でバスに接続されています。1つのノードがバスをドミナント状態に駆動している場合、リセッシブ状態を送信するノードの数に関係なくバス全体がその状態になります。

異なる物理層

物理層は、バス上の電気レベルと信号方式、ケーブルインピーダンスおよび類似の情報を定義します。
いくつかの異なる物理層があります：

• 最も一般的なタイプは、CAN規格、part ISO 11898-2、および2線式平衡型信号方式で定義されたタイプです。これは、"high-speed CAN"とも呼ばれます。
• 同じISO規格の別のパートであるISO 11898-3は、低スピードバスのための別の2線式平衡信号方式を定義します。これはフォールトトレラントなので1本のバスラインが切断、グランドまたはVbatに短絡しても信号が継続できます。これは、"low-speed CAN"と呼ばれます。
• J2411は、シングルワイヤ(勿論、接地を含む)物理層を定義します。例えば、主に自動車で使用されているGM-LANがあります。
• いくつかの独自（proprietary）の物理層が存在します。
• RS485の改造は、CANドライバが存在しない古い時代に使用されていました。
• メッセージの詳細に興味のある方は、Page 6のオシロスコープの写真をいくつかご覧ください。

異なる物理層は、原則として相互運用ができません。いくつかの組み合わせは、優れた条件の下で動作するかもしれませんし、動作するように見える場合があります。例えば、同じバス上で"low-speed"および"low-speed"の両方のトランシーバを使用すると、うまく動作することがあります。

非常に多くのCANトランシーバチップは、NXPによって製造されています。代替ベンダとしては、Bosch, Infineon, Texas Instruments ,Vishay Siliconixが含まれます。

非常に一般的なタイプは、ISO 11898で定義された物理層を実装する82C250トランシーバです。82C251は、改良版です。
"low-speed CAN"の一般的なトランシーバは、NXPのTJA1054があります。

最大Busスピード

規格に従ってCAN busの最大Busスピードは、1 Mbit/sです。一部のCANコントローラは、1Mbit/sよりも高速に対応し、特別なアプリケーションのために考慮されています。

Low-speed CAN(ISO 11898-3、上記参照)は、最大125 kbit/sが可能です。

シングルワイヤCANは、標準モードで最大約50 kbit/s、ECUプログラミングなどに使用される特別な高速モードを使用すると最大約100 kbit/sになります。

最小Busスピード

バストランシーバの中には、特定のビットレート以下にはできないものがあることに注意してください。例えば、82C250や82C251を使用しても問題なく10kbit/sまで下げることができますが、代わりにTJA1050を使用した場合は50kbit/sを下回ることができません。データシートを確認してください。

最大ケーブル長

1Mbit/sのスピードで最大で約40mのケーブル長を使用することができます。これは、調停スキームでは、ビットがサンプリングされる前に信号の波面（wave front of the signal）が最も離れたノードまで伝搬し再び戻ってくる必要があるためです。言い換えれば、ケーブル長は光速によって制限されます。
その他の最大ケーブル長は次のとおりです(これらの値は近似値です)：

• 500 kbit/s：(330 ft)100 m
• 250 kbit/s：(650 ft)200 m
• 125 kbit/s：(1600 ft)500 m
• 110 kbit/s: (20000 ft)6 km

ガルバニ絶縁を提供するためにオプトカプラを使用する場合は、それに応じて最大バス長が減少します。ヒント：高速のオプトカプラを使用し、指定された最大ビットレートではなく、デバイスを介した遅延を見てください。

Busターミネーション（終端）

ISO 11898 CAN busは、ターミネーションする必要があります。これは、バスのそれぞれの端に120Ωの抵抗を使用して終端します。このターミネーションは、次の2つの目的があります：

1. バスの終端での信号の反射を除去
2. バスが正しいDCレベルであることを保証

ISO 11898 CAN busは、スピードに関係なく常にターミネーションする必要があります。繰り返しになりますがISO 11898 CAN busは、そのスピードに関係なく常にターミネーションする必要があります。実験室の作業レベルでは、ターミネータが1つあれば十分であるかもしれません。ターミネータを接続しなくてもCAN busが動作する場合は、運が良いだけです。

"low-speed CAN"、シングルワイヤCAN、その他の物理層は、ターミネータを必要とする場合としない場合があります。しかし、vanilla high-speed ISO 11898 CAN busは、常に少なくとも1つのターミネータを必要とします。
詳細については、CAN busターミネーションをご覧ください：

Kvaserの高度なCANソリューション - レセッシブビット伝送を確実に実行するために必要な終端処理(ターミネーション)

ケーブル

ISO 11898では、ケーブルのインピーダンスは公称120Ωと規定されていますが、[108～132]Ω間のインピーダンスが許可されています。今日の市場において、この要件を満たすケーブルは多くはありませんが存在します。将来的には、許容インピーダンス間隔が拡大される可能性が高くなります。
ISO 11898 は、シールド付きまたはシールドなしのツイストペアケーブルについて定義されています。シングルワイヤ規格SAE J2411の作業が進行中です。

CANコネクタ

CAN busコネクタの規格は、特に定められていません! 通常、各上位層プロトコル(!)では、1つまたはいくつかのCAN busコネクタのタイプを定義しています。一般的なタイプとしては下記のがあります：

• 9-pin DSUB、CiAが提案。
• 5-pin Mini-Cおよび/または Micro-C、DeviceNetおよびSDSで使用されています。
• 6-pin Deutchコネクタ、モバイル油圧機器用にCANHUGにより提案されたもの。Page 7では、いくつかの異なるコネクタレイアウトを表示します。

PART 5：オシロスコープの写真

これは、完全に正常なISO 11898のCANバスを1Mビット/秒で動作させたものです。トランシーバは82C251で、物理層はISO 11898で指定されたものを使用しています。

測定は、CAN_HとGND間で行いました。静止状態のバス電圧とリセッシブバス状態のバス電圧は2.5V前後であることに注意してください。ドミナントビットが送信されると電圧は約3.5Vまで上昇します。

これは同じバスですが代わりに測定は、CAN_LとGNDの間で行いました。

これは125 kbit/sで送信された別のメッセージです。
メッセージの(11ビット)識別子は300、つまり16進数で12cです。よく見るとメッセージの最初のビットを識別できるはずです

ここにトリッキーな写真があります。これは上と同じメッセージを示しており(11ビット)識別子300、125 kbit/sと変わりませんがCAN bus上でターミネーションをしていません。CANケーブルは、短いフラットリボンケーブルを使用しています。

それで何が起きているのでしょうか？これは125kbit/sなので1ビットが8μsになります。

1. 最初にトランスミッタがスタートビットを送信します。これは論理'0'、すなわちドミナントレベルです。
2. 次に、識別子が送信されます。10進数300、16進数で12c、または2進数で001 0010 1100です。最初の2つのゼロは、問題なく送信されたように見えます。これは、画像に見られるような24μsのドミナントレベルを説明しています。
3. 次に'1'が送信されるはずですが、バスが終端していないので立ち上がりスロープ(rising slope)は、本来あるべきものではありません。送信ノードは、バス上の'0'を見たと考えるでしょう。
4. これは調停フェーズ中で起こるのでトランスミッタは、送信を停止します。即ち、それは他のノードが送信していると、考えます。実際には誰も送信していないので、バスは、レセッシブのままになります。
5. 6つのレシビティビットの後、トランスミッタとレシーバの両方がstuff errorを検出し、エラー処理が開始されます。この時点で、80μsが経過しています(1スタートビット、2つの'0'、1つの誤解釈ビット、6レセッシブビット、合計10 bits= 80μs)。
6. stuff errorを検出したノードは、エラーフレームの送信を開始します。この場合、上記の画像がキャプチャされる前に多数のエラーが発生しているためエラーフレームはpassiveであるのでトランスミッタはerror passiveです。passive errorフレームは、activeエラーフレームと同じですが、レセッシブレベルで送信されるのでバス上では見えません。
7. passiveフレームは、6ビットを6回続けます。
8. 次にすべてのノードは、error delimiterと呼ばれる8レセッシブビットを待ちます。
9. 次にすべてのノードは、intermissionと呼ばれる3レセッシブビットを待ちます。
10. 上記の数値を合計すると、1+6+6+8+3= 24 レセッシブビット = 192μsに達します(画像を参照してください！)。

モラル：常にCAN busをターミネートさせましょう! 反射は必ずしも傷つけるわけではありませんが、エッジのシェープが悪いと通信障害が発生します。

同じCANバスを別の時間軸で見てみましょう。

CAN busの長さは、約2デシメータ(8 in.)です。アンダーシュートおよびリンギングが見えますが、この場合、さほど重要ではありません。今回は、遅い立ち上がりのエッジが問題の原因です。

これは同じ設定ですが、今回はトランスミッタとレシーバの両方がerror activeになっています。

何が起こっているのでしょうか？

1. 上記の写真のように、3つの'0'が送信され(24μsかかります)、次のビットは、誤って解釈されるため、トランスミッタは、調停を失ったと考えます。
2. ランスミッタは、6ビットを待ってからstuff errorを検出します。誤解釈されたビットと6 ビットは、56μsを要します。
3. トランスミッタとレシーバがエラーフレームの送信を開始します。それは6ドミナントビット(48μs)です。
4. エラーフレームを送信したノードは、8レセッシブビットを待ちますが、立ち上がりのスロープが悪いため、最初のビットが誤解釈されます。ノードは、これはエラーフレームを送信している別のノードであると考え、それを無視します。
5. バスがレセッシブレベルに戻ると、すべてのノードは、8ビットを待ちます。
6. 次に3レセッシブビットのintermissionがきます。
7. 3+9=12ビット=96μs (写真に示されています)。
8. その後、トランスミッタは、同じ結果で再試行します。しばらくすると、トランスミッタは、error passiveになり、前述のように動作します。

ここにさらに別の写真があります。この設定では、適切に終端されたCAN bus上のシングルノードしかありません。メッセージを送信しようとしていますが、誰も聞いていません。

では、何が起きているのでしょうか?

1. まずトランスミッタは、メッセージ全体を送信します。
2. トランスミッタは、ACKスロットにドミナントレベルを期待しますが誰もlisteningしていないのでACKがきていないことからトランスミッタは、Acknowledgementエラーを検出します。
3. その後、トランスミッタは、passive errorフラグを送信します（上の画像では数秒間送信しようとしているためpassiveであり、もはやError activeではなくなりました）。
4. passive errorフラグの後にはエラーデリミタintermissionが続きます。
5. このノードは、メッセージを送信しようとしたが失敗したので新しい送信を開始する前に別の8ビットを待つ必要があります。これはCAN仕様では'suspend transmission'（送信の中断）と呼ばれます。
6. 送信ノードもまた、txエラーカウンタを8増やさなければなりませんが、CAN仕様の特殊なケースではトランスミッタがerror activeな場合のみ発生します。トランスミッタがエラーになると、トランスミッタは（この場合は）txエラーカウンタを増やすことができず結果的に送信は永遠に再試行されます。

従って、画像に表示されているのは、メッセージが送信され、その後、エラーフラグ、エラーデリミタ、中断、送信の中断の合計である小さな一時停止が続きます。メッセージは、その後が再送信され、そして再送信され、そして・・・

PART 6：CANコネクタ

9-pin DSUB

このコネクタレイアウトはCiAによって推奨され、工業規格に完全にマッチしています。

KVASERユーザへ： KVASER DRVcanドライバケーブルのこれらのピンの具体的な使用方法は、
ダウンロードできるドキュメント"Kvaser LAPcan/LAPcan II Hardware Guide" に記載されています。

電源が供給される場合は、+7～+13 V、100 mAの範囲でなければなりません。モジュールにはオスコネクターがあり、ピン3と6を内部で接続する必要があります。

ピン番号は、コネクタ側から見てMコネクタ、はんだ付け側から見てメスFコネクタの場合に有効です。ピン番号を覚えるためにCAN_LOWはLOW、CAN_HIGHはHIGHのピン番号であることに注意してください。

5-pin Mini-C

PIN	FUNCTION	DEVICENET COLOR
1	Drain	Bare
2	V+	Red
3	V-	Black
4	CAN_H	White
5	CAN_L	Blue

DeviceNetとSDS の両方で使用されます。これら2つのプロトコル間で互換性があります。
モジュールには、Mコネクタを使用しています。供給電源は、24V ±1%です。
Note: DeviceNet仕様version 1.xでは、figure 9.13のF(コネクタの番号が間違っています。仕様2.0以降のバージョンは、それが正しくなっています。

6-pin Deutsch DT04-6P

モバイル油圧アプリケーションでの使用のためにCANHUGによって推奨されています。モジュール側はM、バス側F。現在、供給された電源に関しては推奨事項がありません。

PART 7：CANビットタイミング

ビットレイアウト

CAN busの各ビットは、タイミング目的のために少なくとも4 quantaに分割されます。quantaは、論理的に4つのグループまたはセグメントに分割されます。

• 同期セグメント
• 伝播セグメント
• フェーズセグメント 1
• フェーズセグメント 2

これはCANデータビットの画像です:

同期セグメントは、常に1 quantum長でクロックの同期に使用されます。バス上でデータが変化したとき、ここでビットエッジが発生することが予想されます。
フェーズセグメントは、クロックを同期させるために必要に応じて短縮（フェーズセグメント1）または延長（フェーズセグメント2）することができます。
バスレベルは、フェーズセグメント1とフェーズセグメント2の間の境界でサンプリングされます。

ほとんどのCANコントローラは、1ビットの間に3回サンプリングするオプションを提供しています。この場合、サンプリングは、 サンプリングポイントの前の2つのquantaの境界で行われ、結果は多数決デコードの対象となります(少なくとも82527の場合は、これが当てはまります)。

クロック同期

on-chipバスクロックを調整するためにCANコントローラは、quantaの整数によってビットの長さを短縮または延長することがあります。これらのビットタイム調整の最大値は、SJW（Synchronization Jump Width）と呼ばれます。

ハード同期は、スタートビットのレセッシブ-to-ドミナント（recessive-to-dominant）の移行で発生します。ビットタイムは、そのエッジから再スタートされます。

再同期は、メッセージ内の同期セグメント内でビットエッジが発生しない場合に発生します。フェーズセグメントの1つは、信号の位相誤差に依存する量で短縮または延長されます。使用できる最大量は、Synchronization Jump Widthパラメータによって決まります。

ビットタイミングレジスタ計算

ほとんどのCANコントローラでは、プログラマが以下のパラメータを使用してビットタイミングを設定することができます：

• クロックプリスケーラ値
• サンプリングポイントの前のquantaの数
• サンプリングポイントの後のquantaの数
• SJW(Synchronization Jump Width)のquantaの数

通常、この目的のために2つのレジスタが用意されています：btr0とbtr1です。ただし、コントローラによって若干の違いがありますのでデータシートをよく読んでください。

NXP（旧Philips）の82c200とSJA1000では、レジスタのレイアウトは次のようになっています。

• BRP0～BRP5は、クロックプリスケーラ値を設定します。
• SJW0～SJW1は、SJWの長さを設定します。
• TSEG10～TSEG13は、サンプリングポイントの前のquantaの数を設定します(スタートビットは含まれません)。
• TSEG20～TSEG22は、サンプリングポイントの後のquantaの数を設定します。
• SAMは、3つのサンプルを取得する場合は1、1つのサンプルで十分な場合は0に設定されます。

Note：これらのパラメータの実際の値は、レジスタに書き込まれた値より1つ多くなります。

例: SJA1000に送られるオシレータ信号が16 MHzでビットレートが250 kbit/sの場合、サンプリングポイントは、ビット全体の62%に近い値、SJWは2 quantaで、次の値を設定できます：

BRP = 4、これは2 * 4/16000000 s = 500 nsのquantum長を与え、そして
TSEG1 = 5、これはサンプリングポイントの前に 5 quantumを与え、そして
TSEG2 = 3、これはサンプリングポイントの後に3 quantumを与えます。

各ビットは、5 + 3 = 8 quantaで構成され、1/(8 * 500 ns) = 250 kbit/sの所望のビットレートになります。レジスタ値は、ここの例に示すようにします。

サンプリングポイントは、ビットの5/8 = 62.5%です

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つは、メッセージレベルで動作します。

1. ビット監視
2. Bit Stuffing
3. フレームチェック（Frame check）
4. Acknowledgementチェック
5. サイクリック冗長チェック

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ケーブルのいくつかの障害モードを列挙します：

1. CAN_H が切断
2. CAN_L が切断
3. CAN_H がバッテリ電圧に短絡
4. CAN_L がグランドに短絡
5. CAN_H がグランドに短絡
6. CAN_L がバッテリ電圧に短絡
7. CAN_L がCAN_Hワイヤに短絡
8. CAN_HおよびCAN_L が同じ場所で中断
9. 終端ネットワークへのコネクションの喪失

障害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と制限されています。

PART 9：CAN FDと上位層プロトコル

CAN FD

2011年、Boschは、CANの新しいイテレーションである"CAN FD"の開発を開始しました。"FD"は、"flexible data rate"の略です。2011年以降、CAN FDは、次世代のCANとして採用され、SAE仕様会議で改良やチップおよびツールメーカによる実行が続けられています。

Controller Area Network(CAN)およびFlexible Data-Rate(CAN FD)

Boschが開発したCAN FD（CAN with Flexible Data-Rate）は、ISO 11898-1で規定されているオリジナルのCANプロトコルを拡張したものでautomotive networks（自動車ネットワーク）における帯域幅要件の増加に対応しています。CAN FDは、Infineon、NXP、Daimler、GMなどの、この新しい規格の背後にある半導体企業およびエンドユーザからのサポートを受けています。

CAN FD準拠製品の検索：ハードウェア | ソフトウェア

CAN FD : 概要

標準的なCANネットワークは、スピードが1MBit/sに制限され、最大ペイロードは、フレームあたり8バイトです。CAN FDは、CAN物理層を変更することなく、より長いデータフィールド（フレームあたり最大64バイト）を可能にすることで、実効データレートを向上させます。また、CAN FDは、通常のCANバス調停を維持し、調停プロセスの終了時にのみ短いビット時間に切り替え、またレシーバがacknowledgeビットを送信する前のCRCデリミタで長いビット時間に戻すことでビットレートを向上させます。CANで可能な3～8倍の現実的な帯域幅利得は、フラッシングアプリケーションに特に有効です。

CAN FDシステムおよびサブシステムを構築する場合、最大ビットレートを実現するためには物理層の品質に大きく依存するため、より高いビットレートであるほど物理層についてより多くの情報を知る必要があります。また、CAN FDメッセージは、共通のTime Quantaとサンプリングポイントの位置が分かっていることを要求します。これらの理由からCAN FDシステムでは、より高度なトラブルシューティングツールが必要になります。

Kvaser とCAN FD

Kvaserは、早期にCAN FDを開始し、それ以来、CAN FDコントローラロジックに追加機能を実装してきました。これを使用してCANビットを構成して既存のCANバスレイアウトのビットタイミング設定を最適化し、特定のハーネスでのCAN FD実装の最大ビットレートを特定する方法に関する情報を提供できます。

革新的でコスト効率に優れたCANソリューションのリーディングプロバイダとなることを使命とするKvaserは、CAN FD規格のサポートに全力で取り組み、マイクロコントローラと新規格のコンフォーマンステストソリューションが利用可能になり次第、CAN FDに準拠したインターフェースとデータロガーをリリースすることを目指しています。

Kvaser社のCAN FD実装は、 Bosch spec test に合格しました。このテストでは、バス上で大量のエラーフレームやその他の