キャン【CAN】
読み方：きゃん
《controller area network》車載ネットワークの通信規格の一。ドイツのボッシュ社が開発。自動車のECU・エンジン・ブレーキ・トランスミッションなどの制御に利用されるほか、工作機械や輸送用機械などでも用いられる。最大通信速度は1Mbps。コントローラーエリアネットワーク。
コントローラーエリア‐ネットワーク【controller area network】
読み方：こんとろーらーえりあねっとわーく
⇒キャン（CAN）
Controller Area Network
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/03/22 14:40 UTC 版)
 Unofficial logo of the CAN bus by CAN-in-Automation. | |||
| 種別 | シリアル通信 バス | ||
|---|---|---|---|
| 製品史 | |||
| 開発者 | ボッシュ社 | ||
| 開発年 | 1983年 | ||
| 外部接続 | No | ||
| 電気仕様 | |||
| 電気的特性 | 差動 | ||
| 許容電圧 | 16 V DC | ||
| データ仕様 | |||
| データ信号 | トランシーバー駆動 | ||
| 帯域幅 | 1 bit（双方向） | ||
| バンド域幅 |
| ||
| 許容デバイス | 32, 64 or 127 (depending on standard) | ||
| プロトコル | |||
| ピン配列 | |||
| CAN-H | CAN High (Yellow) | ||
| CAN-L | CAN Low (Green) | ||
Controller Area Network（コントローラー・エリア・ネットワーク、CAN）は、ビークルバス規格の一種で、ホストコンピュータなしでマイクロコントローラやデバイスが相互に通信できるように設計されている。耐ノイズ性の強化が考慮された堅牢な規格である。メッセージベースのプロトコルであり、元々は、自動車内部の多重化電気配線用に設計されたものだが、機器の制御情報の転送用として普及しており、輸送用機械、工場、工作機械などのロボット分野においても利用されている。自動車においては、速度、エンジンの回転数、ブレーキの状態、故障診断の情報などの転送に使用されている。
データ転送速度は、40 mの通信路においては最高で1 Mbps程度、500 mの通信路においては最高で125 kbps程度。実際の運用においては、速いもので500 kbps、遅いもので83.3 kbpsとなっている。通信速度が上がるほど接続できる機器の数が減るので、高級車などでは速度の異なる複数の通信路をもつ。
なお、デジタルコンテンツなど大量データの転送には、MOSTまたはIDB-1394、車載Ethernetを用いる。パワーウィンドウなど転送速度をそれほど要求されないシステムにおいては、Local Interconnect Network（LIN）と呼ばれるネットワーク通信を用いるのが一般的となっている。また、エアバッグやシートベルトなどの乗員保護装置（Supplemental Restraint System）には、低速で信頼性を高めたSafe-by-Wireという規格が策定されている。しかし、CANを使用しているシステムもあり、はっきりとした使い分けは定着していない。
歴史
CANの開発は、1983年にドイツのボッシュ社で開始された[1]。このプロトコルは、1986年にデトロイトで開催されたSociety of Automotive Engineers（SAE）の会議で公式に発表された。インテルとフィリップスが製造した最初のCANコントローラチップは、1987年に発売された
ボッシュ社はCAN仕様のバージョンをいくつか発行し、1991年にCAN 2.0を発行した。この仕様には2つの部分がある。パートAは11ビットの識別子を持つ標準フォーマット用であり、パートBは29ビットの識別子を持つ拡張フォーマット用である。11ビットの識別子を使用するCANデバイスはCAN 2.0Aと呼ばれ、29ビットの識別子を使用するCANデバイスはCAN 2.0Bと呼ばれる。これらの規格は、ボッシュ社から他の仕様やホワイトペーパーとともに自由に入手できる[2]。
1993年、国際標準化機構（ISO）はCAN規格ISO 11898を発表した。この規格は後に、データリンク層を規定するISO 11898-1と、高速CAN用のCAN物理層を規定するISO 11898-2の2部に再構成された。後に、低速フォールトトレラントCAN物理層を規定するISO 11898-3が発表された。物理層規格であるISO 11898-2とISO 11898-3はボッシュ社によるCAN 2.0仕様の一部ではない。これらの規格はISOから購入することができる。
ボッシュ社はCAN規格の拡張に積極的に取り組んでいる。2012年、ボッシュ社はCAN FD（CAN with Flexible Data-Rate） 1.0を発表した。この仕様では、アービトレーションが決定された後、より高速のビットレートに切り替えるだけでなく、異なるデータ長を可能にする異なるフレームフォーマットを使用する。CAN FDは既存のCAN 2.0ネットワークと互換性があり、新しいCAN FDデバイスは既存のCANデバイスと同じネットワーク上に共存できる。ただし、既存CANコントローラに接続するCANトランシーバを全てCAN FDパッシブ用のものに変更する必要がある[3][4]。
CANは、自動車の自己診断機能の標準であるOBD2で使用される5つのプロトコルのうちの1つである。OBD2規格は、1996年以降、米国で販売される全て自動車・軽トラックに必須であり、OBD2と等価のEOBD規格は、2001年以降の欧州連合で販売される全てのガソリン車および2004年以降の全てのディーゼル車に対して義務付けられている[5]。
応用
自動車
現代の自動車には、様々なサブシステム用に約70個もの電子制御ユニット（ECU）が搭載されている[6]。通常、最大のプロセッサはエンジンコントロールユニットである。その他に、トランスミッション、エアバッグ、アンチロック・ブレーキ・システム（ABS）、クルーズコントロール、パワーステアリング、オーディオシステム、パワーウィンドウ、ドア、ミラー調整、ハイブリッドカー・電気自動車用のバッテリーおよび充電システムなどに使用される。これらのうちのいくつかは独立したサブシステムを形成するが、他のサブシステムとの通信は不可欠である。サブシステムは、アクチュエータを制御したり、センサからのフィードバックを受け取ったりする必要がある。この要求を満たすためにCANが考案された。
CANの重要な利点の1つは、異なる車両システム間の相互接続により、ソフトウェアだけで幅広い安全性・経済性・利便性を実現できることである。このような機能を従来の自動車電装によりハードの配線により実現しようとすると、コストと複雑さが増大する。例として、以下の事柄が挙げられる。
- アイドリングストップ : CANバスを介して、車両周辺からの様々なセンサ入力（速度センサ、ステアリング角度、空調オン/オフ、エンジン温度）を照合し、エンジンを停止することで燃費と排気を改善できるかどうかを判断する。
- 電動パーキングブレーキ : ヒルホールド機能は、車の傾斜センサ（盗難警報器でも使用される）と道路速度センサ（ABS、エンジン制御、トラクション制御でも使用される）をCANバス経由で入力し、車が坂道で停止しているかを判断する。同様に、CANバスから供給されるシートベルトセンサからの入力（エアバッグ制御の一部）により、シートベルトが締められているかどうかを判断し、車が動き出すとパーキングブレーキが自動的に解除される。
- 駐車支援システム : 運転者がギアを後退に入れると、トランスミッションコントロールユニットはCANバスを介して信号を送信し、駐車センサシステムとドア制御モジュールを作動させる。ドア制御モジュールは助手席ドアミラーを傾けて、縁石の位置が見えるようにする。また、CANバスは降雨センサからの入力を受けて、後退時にリアガラスのワイパーを動かす。
- 車線逸脱防止支援/衝突回避システム : 駐車センサからの入力はCANバスを通して車線逸脱警報などの運転支援システムに外部近接データを送る。最近では、これらの信号がCANバスを通して能動的衝突回避システムにおけるブレーキ・バイ・ワイヤを作動させる。
- 自動ブレーキ拭き取り：降雨センサ（主に自動フロントガラス用ワイパーで使用 ）からCANバスを介してABSモジュールに入力され、ブレーキロータの水分を取る。いくつかのアウディとBMWの高級モデルにはこの機能が組み込まれている。
近年、空調やインフォテインメントなどのデータ伝送速度や信頼性があまり重要ではないサブシステムに対してCANを補完するために、Local Interconnect Network（LIN）バス規格が導入された。
その他
- 2009年からロードバイク用のシマノDI2電子ギアシフトシステムでCANバスプロトコルが使用されている。また、直接駆動モーターのAnsmannおよびBionXシステムでも使用されている。
- CANバスは、一部のCANコントローラやプロセッサのコストが低いため、一般的な自動化環境でフィールドバスとしても使用される。
- NISMOなどのメーカーは、ゲームのGPSデータロガー機能を使用してビデオゲームグランツーリスモ6で実際のレーシングラップを再現するためにCANバスデータを使用することを目指している[7]。
- ジョンズ・ホプキンズ大学応用物理研究所のModular Prosthetic Limb（MPL）は、ローカルCANバスを使用して、人工腕のサーボとマイクロコントローラ間の通信を容易にしようとしている。
アーキテクチャ
CANは、ノードとも呼ばれる電子制御ユニット（ECU）を接続するためのマルチマスタシリアルバス規格である。通信するには、CANネットワーク上に2つ以上のノードが必要となる。ノードの複雑さは、単純なI/Oデバイスから、CANインターフェースとソフトウェアを備えた組み込みコンピュータまでさまざまである。ノードは、標準的なコンピュータがUSBやイーサネットポートを介してCANネットワーク上のデバイスに通信することを可能にするゲートウェイであっても良い。
全てのノードは、2線式バスを介して互いに接続されている。通信線は、公称120 Ωのツイストペアケーブルである。信号は、2本の通信線の電圧の差動によって送信される（平衡接続）。双方の線にいくらかの電圧が加わっても電圧の差には大きな変化がないので、ノイズに強いという性質がある。また低速CANの場合、仮に通信線2本の内の1本が途切れた場合でも、耐ノイズ性は下がるが通信は可能である。
ISO 11898-2は高速CANとも呼ばれ、両端が120 Ωの抵抗で終端されたリニアバスを使用する。
ドミナント（dominant, 0）を送信するときには、CANハイワイヤを5 Vの方に、ローワイヤを0 Vの方に駆動し、リセッシブ（recessive, 1）を送信するときはどちらの通信線も駆動しない。ドミナントの差動電圧は公称2 Vである。終端抵抗は2本の通信線を受動的に0 Vの公称差動電圧に戻す。ドミナントのコモンモード電圧はコモンの1.5-3.5 Vの間でなければならず、リセッシブのコモンモード電圧はコモンの+/- 12である。
ISO 11898-3は低速CANまたはフォールトトレラントCANとも呼ばれ、リニアバス、スターバス、またはリニアバスで接続された複数のスターバスを使用し、各ノードが全体終端抵抗の一部で終端される。全体終端抵抗は100 Ω程度（ただし100 Ω以上）でなければならない。
ISO 11898-3のシグナリングは、ドミナント（0）を送信するときにCANハイワイヤを5 Vの方に、CANローワイヤを0 Vの方に駆動し、リセッシブ（1）を送信するときはどちらの通信線も駆動しない。ドミナントの差動電圧は2.3 V（5 V Vcc）より大きくなければならず、リセッシブの差動電圧は0.6 V未満でなければならない。終端抵抗は、CANのローワイヤをRTH（最小4.7 V（Vcc - 0.3 V（Vccは公称5 V））に、CANハイワイヤをRTL（最大0.3 V）に受動的に戻す。どちらのワイヤも-27-40 Vを損傷することなく処理できなければならない。
高速・低速両方のCANで、CANワイヤが能動的に駆動されているため、リセッシブからドミナントへの遷移が発生すると、遷移の速度が速くなる。ドミナントからリセッシブへの遷移の速度は、主にCANネットワークの長さと使用する通信線の容量に依存する。
高速CANは、1つのバスが使用環境の端から端まで走る自動車や産業用アプリケーションでよく使用される。低速CANは、ノードのグループを一緒に接続する必要がある場合によく使用される。
ISO仕様では、バスを最小コモンモードバス電圧内に維持する必要があるが、この範囲内でバスを保持する方法は定義していない。
CANバスは終端される必要がある。終端抵抗は、反射を抑制し、バスをレセッシブまたはアイドル状態に戻すために必要である。
高速CANはリニアバスの両端で120 Ωの抵抗を使用する。低速CANは各ノードで抵抗を使用する。ISO 11783[8]に定義されている終端バイアス回路のような他のタイプの終端が使用される場合もある。
終端バイアス回路は、4線式ケーブル上のCANシグナリングに加えて、電力と接地を提供する。これにより、各バスセグメントの両端で自動バイアスと終端が自動的に行われる。ISO 11783ネットワークは、ホットプラグインとバスセグメントとECUの取り外し用に設計されている。
各ノードには以下のものが必要である。
- CPU、マイクロプロセッサ、またはホストプロセッサ
- ホストプロセッサは、受信したメッセージが何を意味し、どのメッセージを送信するかを決定する。
- センサ、アクチュエータ、制御デバイスをホストプロセッサに接続することができる。
- CANコントローラ（通常はマイクロコントローラの一部）
- 受信: CANコントローラは、メッセージ全体が利用可能になるまで、バスから受け取ったシリアルビットを格納する。これは、ホストプロセッサによって（通常は割り込みをトリガするCANコントローラによって）フェッチされる。
- 送信: ホストプロセッサは送信メッセージをCANコントローラに送信し、CANコントローラはバスが空いているときにシリアルにビットを送信する。
- トランシーバー（ISO 11898-2/3 媒体アクセスユニット（MAU）規格で定義される）
各ノードはメッセージを送受信できるが、複数のノードが同時に送信することはできない。メッセージまたはフレームは、主に、メッセージの優先度を表すID（識別子）と最大8バイトのデータセクションで構成される。CRC、確認応答スロット（ACK）その他のオーバーヘッドもメッセージの一部である。改良されたCAN FDでは、データセクションの長さをフレームあたり最大64バイトまで拡張している。このメッセージは、NRZ（non-return-to-zero）フォーマットを使用してシリアルにバスに送信され、すべてのノードによって受信される。
CANネットワークに接続されるデバイスは、センサ、アクチュエータ、その他の制御デバイスである。これらのデバイスは、ホストプロセッサ、CANコントローラ、CANトランシーバを介してバスに接続されている。
データ転送
CANデータ伝送では、競合解消に無損失ビット単位アービトレーション方式が採用されている。この方式では、CANネットワーク上の全てのビットを同時にサンプリングするために、CANネットワーク上の全てのノードを同期させる必要がある。これがCAN同期と呼ばれる理由である。ただし、「同期」という用語は、データが非同期フォーマットによってクロック信号なしで伝送されるため、不正確である。
CAN仕様では、「ドミナント」（優性）ビットと「リセッシブ」（劣性）ビットという用語が使用されている。これは、ドミナントが論理0（トランスミッタによって能動的に駆動される）、リセッシブが論理1（抵抗によって受動的に戻される）であるためである。アイドル状態はリセッシブレベル（論理1）で表される。1つのノードがドミナントビットを送信し、別のノードがリセッシブビットを送信した場合、衝突が起こり、ドミナントビットの方が「勝つ」。これは、より高い優先順位のメッセージに遅延がないことを意味し、より低い優先順位のメッセージを送信するノードは、ドミナントメッセージの終了後のビットクロック後に自動的に再送信しようと試みる。これにより、CANはリアルタイムの優先順位付けされた通信システムとして非常に適している。
論理0と論理1の正確な電圧は使用する物理層に依存するが、CANの基本原理では、各ノードが送信ノード自体を含むCANネットワーク上の全てのデータを受信する必要がある。論理1が全ての送信ノードによって同時に送信される場合、論理1は、送信ノードおよび受信ノードの両方を含む全てのノードによって観測される。論理0が全ての送信ノードによって同時に送信される場合、全てのノードで論理0が観測される。論理0が1つ以上のノードによって送信され、論理1が1つ以上のノードによって送信されている場合、論理1を送信するノードを含む全てのノードで論理0が観測される。論理1を送信したノードは、論理0を観測することで、競合が存在し、自身の送信を終了すべきであることを認識する。このプロセスを使用することによって、別のノードが論理0を送信するときに、論理1を送信するノードは、中断するか、またはアービトレーション（調停）を失う。アービトレーションを失ったノードは、後で送信するためにそのメッセージを再キューに入れ、CANフレームビットストリームは、1つのノードのみが送信されるまでエラーなしで継続する。これは、最初に1を送信したノードがアービトレーションを失うことを意味する。CANフレームの開始時に11ビット（CAN 2.0Bでは29ビット）の識別子が送信されるため、識別子の最も小さいノードがフレームの先頭に0を送信し、それがアービトレーションまたは最優先権を有することになる。
例えば、ノード識別子が11ビットのCANネットワークに、ノード識別子が15（二進数表現 00000001111）、16（二進数表現 00000010000）の2つのノードが接続されているとする。これらの2つのノードが同時に送信した場合、それぞれは最初に開始ビットを送信し、次にアービトレーションの決定が行わないままノード識別子の最初の6つのゼロを送信する。
| 開始 ビット |
識別子ビット | フレームの残り | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |||
| ノード 15 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | |
| ノード 16 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 送信停止 | ||||
| CANデータ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | |
第7ビットでは、識別子が16のノードは1（リセッシブ）を送信し、識別子が15のノードは0（ドミナント）を送信する。これが起こると、識別子が16のノードは、1を送信したのに0が観測されたことから、衝突があり自身がアービトレーションを失ったことを認識する。識別子が16のノードは送信を停止し、識別子が15のノードはデータの損失なしに送信を継続できる。最も小さい識別子を持つノードは、常にアービトレーションに勝つため、最も高い優先度を持つ。
ネットワーク長が40 m未満の場合、最大1 Mbit/sのビットレートが可能である。ビットレートを下げれば、ネットワーク距離を長くすることができる（例えば、125 kbit/sで500 m）。改良されたCAN FD規格では、アービトレーション後のビットレートを増加させることができ、アービトレーションビットレートの最大8倍の倍率でデータセクションの速度を上げることができる。
ID割り当て
メッセージIDは、1つのCANバス上で一意でなければならない。そうしないと、2つのノードがアービトレーションフィールド（ID）の終わりを超えて送信を続け、エラーを引き起こす。
1990年代初めには、メッセージIDの選択は、データのタイプと送信ノードの識別に基づいて単純に行われていた。しかし、IDがメッセージ優先度としても使用されるため、リアルタイムのパフォーマンスが低下する。これらのシナリオでは、全てのメッセージが期限を過ぎないようにするために、CANバス使用率を通常30%と低くする必要があった。しかし、メッセージのデッドラインに基づいてIDが決定され、数値IDが低くメッセージの優先度が高い場合には、通常、メッセージのデッドラインを逃してしまう前に70-80%のバス使用率を達成することができる。
ビットタイミング
CANネットワーク上の全てのノードは、同じ公称ビットレートで動作する必要があるが、ノイズ、位相シフト、オシレータ公差、オシレータドリフトなどにより、実際のビットレートが公称ビットレートと同じでない可能性がある[9]。別のクロック信号が使用されないので、ノードを同期させる手段が必要である。アービトレーション中のノードは、自身の送信データと他のノードの送信データの両方を同時に観測することができなければならないため、アービトレーション中には同期が重要である。同期は、ノード間の発振器タイミングの変動によってエラーが発生しないようにするためにも重要である。
同期は、バスアイドル期間（開始ビット）の後、最初のリセッシブからドミナントへの遷移時のハード同期から開始される。再同期は、フレーム中の全てのリセッシブからドミナントへの遷移時に行われる。CANコントローラは、公称ビット時間の倍数で遷移が発生することを期待している。コントローラが期待する正確な時間に遷移が発生しない場合、コントローラはそれに応じて公称ビット時間を調整する。
調整は、各ビットをクアンタ（quanta、量子）と呼ばれる複数のタイムスライスに分割し、ビット内の4つのセグメント（同期、伝播、位相セグメント1、位相セグメント2）のそれぞれにいくつかのクアンタを割り当てることによって達成される。
ビットによって分けられるクアンタの数は、コントローラによって変えることができ、各セグメントに割り当てられるクアンタの数は、ビットレートおよびネットワーク状態に応じて変えることができる。
コントローラが期待するよりも前後に遷移が起こった場合、コントローラが時間差を計算し、この時間までに位相セグメント1を長くするか、位相セグメント2を短くする。これにより、受信機と送信機のタイミングを効果的に調整して同期させることができる。この再同期プロセスは、送信機と受信機が同期していることを確実にするために、全てのリセッシブからドミナントへの遷移において連続的に行われる。継続的な再同期化は、ノイズによって引き起こされるエラーを低減し、アービトレーションを失ったノードに同期された受信ノードが、アービトレーションを獲得したノードと再同期することを可能にする。
レイヤ
CANプロトコルは、多くのネットワークプロトコルと同様に、以下の抽象化レイヤに分解できる。
- アプリケーション層
- オブジェクト層
-
- メッセージフィルタリング
- メッセージと状態のハンドリング
- トランスファー層
- CAN規格のほとんどはトランスファー層に適用される。トランスファー層は、物理層からメッセージを受信し、それらのメッセージをオブジェクト層に送信する。トランスファー層は、ビットタイミングと同期、メッセージフレーミング、アービトレーション、肯定応答、エラー検出とシグナリング、障害隔離を担当する。
- 障害隔離
- エラー検出
- メッセージの検証
- 肯定応答
- アービトレーション
- メッセージフレーミング
- 転送レートとタイミング
- 情報ルーティング
- 物理層
終端抵抗付きCANバスの電気サンプルトポロジ - ピン2: CAN-Low（CAN−）
- ピン3: GND（Ground）
- ピン7: CAN-High（CAN+）
- ピン9: CAN V+（Power）
この事実上の機械的規格は、オスとメスの両方の9ピンDサブコネクタをノード内で並列に相互に電気的に配線したノードで実施することができる。バス電源はノードのオスコネクタに供給され、バスはノードのメスコネクタから電力を引き出す。これは、電源がメスコネクタで終端されるという電気工学的取り決めに従っている。この規格の採用により、2つのバスワイヤセットを各ノードの1つのDコネクタに接続するカスタムスプリッタを製作する必要がなくなる。ノード外の導体を接合する非標準（カスタム）ワイヤーハーネス（スプリッター）は、バスの信頼性を低下させ、ケーブルの互換性をなくし、配線ハーネスの互換性を低下させ、コストを増加させる。
完全な物理層仕様（電気的・機械的）がないため、CANバス仕様は物理的な実装の制約と複雑さから解放された。しかし、CANバスの実装は、機械的な非互換性のために相互運用性の問題にさらされていた。相互運用性を向上させるために、自動車メーカーの多くは、伝送路上の寄生容量の要件と組み合わせて許容されるCANトランシーバのセットを記述する仕様を作成している。許容される寄生容量には、ESD保護だけでなく、コンデンサも含まれる（ISO 7637-3に対するESD[10]）。寄生容量に加えて、12 Vと24 Vのシステムは、伝送路の最大電圧に関して同じ要件を持っていない。事実、ジャンプスタートイベントの間、小型乗用車の伝送路は24Vまで上昇し、トラックでは36 Vまで上昇する可能性がある。新しい解決法が市場に出ており、CANとCAN FD（[11]を参照）に同じ部品を使用できるようになった。
ISO 11898-2:2003の耐ノイズ性は、バスの両端の低値抵抗（120 Ω）でバスの差動インピーダンスを低レベルに維持することによって達成される。しかし、休止状態になると、CANなどの低インピーダンスバスは、他の電圧ベースの信号バスより多くの電流および電力を消費する。CANバスシステムでは、一方の信号ラインの電流が他方の信号の反対方向の電流によって正確に平衡される平衡接続により、受信機に対して独立した安定した0 Vの参照を提供する。ベストプラクティスでは、自動車内部のノイズの多いRF環境でRF放射を最小限に抑え、干渉感受性を低減するために、CANバスの平衡接続信号をシールドケーブルのツイストペアケーブルで伝送することが決定されている。
ISO 11898-2は、ノード間の高い電圧結合を維持するために、バスに沿って0 Vレールを走らせることにより、送信機と受信機の間のコモンモード電圧に対する耐性を提供する。また、上述の事実上の機械的構成では、各トランシーバノードに電力を分配するための電源レールが設けられている。この設計は、全てのトランシーバに共通の電源を提供する。バスによって印加される実際の電圧およびそれに適用されるノードは、アプリケーション固有であり、正式には指定されていない。一般的な実際のノード設計は、各ノードに、ノードホストから光学的に絶縁されたトランシーバを提供し、バスによって提供されるユニバーサル電源レールからのトランシーバに対して5 Vの線形に調整された電源電圧を導出する。これにより、通常、多くのノードタイプ間の相互運用を可能にするのに十分な電源レールの動作マージンが可能になる。このようなネットワーク上の電源電圧の標準値は7-30 Vである。しかし、正式な規格がないということは、システム設計者が電源レールの互換性の責を負うことを意味する。
ISO 11898-2には、バスの両端に抵抗終端を備えたマルチドロップシングルエンド平衡接続構成で形成された電気的実装が記載されている。この構成では、ドミナント状態にするには、1つ以上の送信機がCAN-に0Vを供給するように切り替え、同時に、CAN+に+5 Vのバス電圧を供給するように切り替えることで、バスを終端する抵抗を通る電流経路を形成する。このように、終端抵抗は、高周波での波反射を制限するためだけでなく、信号システムの必須構成要素を形成する。
リセッシブ状態の間、信号線と抵抗器は両方のレールに対して高インピーダンス状態のままである。CAN +とCAN-の両方の電圧は、レール間の中間電圧に向かう（弱い）傾向がある。リセッシブ状態は、バス上の送信機のどれもドミナント状態をアサートしていないときにのみ、バス上に存在する。
ドミナント状態の間、信号線および抵抗器は、レールに対して低インピーダンス状態に遷移し、電流が抵抗器を通って流れる。CAN+の電圧は+5 Vになり、CAN-は0 Vになる。
信号状態にかかわらず、信号線は、バスの終端にある終端抵抗により、常に互いに低インピーダンス状態にある。
この信号方式は、差動ラインドライバ/レシーバを使用するRS-422/3、RS-485などの他の平衡線伝送技術とは大きく異なり、概念的な0 Vと交差する差動モード電圧に基づく信号方式を使用する。このようなシステム上の多重アクセスは、通常、3つの状態（アクティブハイ、アクティブロー、非アクティブ）をサポートするメディアに依存し、時間領域で処理される。CANバス上の複数のアクセスは、概念的には「有線AND」ネットワークに類似した2つの状態のみをサポートするシステムの電気的論理によって達成される。
フレーム
CANネットワークは、標準フレームフォーマット（CAN 2.0AとCAN 2.0Bで規定）と拡張フレームフォーマット（CAN 2.0Bでのみ規定）の2つの異なるメッセージ（または「フレーム」）フォーマットで動作するように設定できる。2つの形式の唯一の違いは、CAN標準フレームが識別子の長さが11ビットであるのに対し、CAN拡張フレームが識別子の長さが29ビットであり、11ビットの識別子（ベース識別子）と18ビットの拡張（識別子拡張）を含むことである。CAN標準フレームフォーマットとCAN拡張フレームフォーマットとの区別は、IDEビットを使用することによって行われる。これは、11ビットフレームの場合はドミナント、29ビットフレームの場合はリセッシブとして送信される。拡張フレームフォーマットのメッセージに対応するCANコントローラは、CAN標準フレームフォーマットでもメッセージを送受信できる。全てのフレームは、フレーム送信の開始を示すフレーム開始（SOF: start-of-frame）ビットで始まる。
CANには4つのフレームタイプがある。
- データフレーム: 通常のデータを送信するためのフレーム
- リモートフレーム: データフレームの送信先にフレームの送信を要求するフレーム
- エラーフレーム: 各種のエラーを他ノードに通知するためのフレーム
- オーバーロードフレーム: コントローラーが信号の処理が間に合わないときに「バッファの処理が追いつかずデータを受け取れませんでした」などの信号を送信するフレーム
データフレーム
データフレームは、実際のデータを伝送するために使われる唯一のフレームである。これには、2つの形式がある。
標準フレームフォーマット: 識別子が11ビット
拡張フレームフォーマット: 識別子が29ビット
CAN標準では、標準フレームフォーマットは必ず受け入れなければならず、拡張フレームフォーマットは受け入れなくても良いが、それに耐えなければならない。
標準フレームフォーマット
標準フレームフォーマットは以下の通りである。CAN-LO信号のビット値が記述されている。
| フィールド名 | ビット長 | 目的 |
|---|---|---|
| フレーム開始（SOF） | 1 | フレーム送信の開始を示す。 |
| 識別子（緑） | 11 | （一意な）識別子。メッセージ優先度も表す。 |
| リモート送信要求（RTR）（青） | 1 | データフレームの場合はドミナント（0）、リモートフレームの場合はリセッシブ（1）。 |
| 識別子拡張ビット（IDE） | 1 | 11ビットの識別子を持つ標準フレームフォーマットではドミナント（0）。 |
| 予約ビット（r0） | 1 | 予約ビット。ドミナント（0）である必要があるが、ドミナント、リセッシブのどちらであっても許容する。 |
| データ長コード（DLC）（黄） | 4 | データのバイト数（0–8バイト）[注釈 1] |
| データフィールド（赤） | 0–64 | 送信されるデータ（DLCフィールドによってバイト単位で指定された長さ） |
| CRC | 15 | 巡回冗長検査 |
| CRCデリミタ | 1 | リセッシブ（1）でなければならない。 |
| ACKスロット | 1 | 送信機はリセッシブ（1）を送信する。 |
| ACKデリミタ | 1 | リセッシブ（1）でなければならない。 |
| フレーム終了（EOF） | 7 | 全てリセッシブ（1）でなければならない。 |
- ^ 物理的には、データが8バイトに制限されているにもかかわらず、4ビットのDLCでは9から15の間の値が送信され得る。一部のCANコントローラでは、8より大きなDLCの送信/受信が可能であるが、実際のデータ長は常に8バイトに制限されている。
拡張フレームフォーマット
拡張フレームフォーマットは以下の通りである。
| フィールド名 | ビット長 | 目的 |
|---|---|---|
| フレーム開始（SOF） | 1 | フレーム送信の開始を示す。 |
| ベース識別子（緑） | 11 | （一意な）識別子。メッセージ優先度も表す。 |
| 代替リモートリクエスト（SRR） | 1 | リセッシブ（1）でなければならない。 |
| 識別子拡張ビット（IDE） | 1 | 29ビットの識別子を持つ拡張フレームフォーマットではリセッシブ（1）でなければならない。 |
| 識別子拡張（緑） | 18 | （一意な）識別子の第二の部分。メッセージ優先度も表す。 |
| リモート送信要求（RTR）（青） | 1 | データフレームの場合はドミナント（0）、リモートフレームの場合はリセッシブ（1）。 |
| 予約ビット（r1, r0） | 2 | 予約ビット。ドミナント（0）である必要があるが、ドミナント、リセッシブのどちらであっても許容する。 |
| データ長コード（DLC）（黄） | 4 | データのバイト数（0–8バイト）[注釈 1] |
| データフィールド（赤） | 0–64 | 送信されるデータ（DLCフィールドによってバイト単位で指定された長さ） |
| CRC | 15 | 巡回冗長検査 |
| CRCデリミタ | 1 | リセッシブ（1）でなければならない。 |
| ACKスロット | 1 | 送信機はリセッシブ（1）を送信する。 |
| ACKデリミタ | 1 | リセッシブ（1）でなければならない。 |
| フレーム終了（EOF） | 7 | 全てリセッシブ（1）でなければならない。 |
- ^ 物理的には、データが8バイトに制限されているにもかかわらず、4ビットのDLCでは9から15の間の値が送信され得る。一部のCANコントローラでは、8より大きなDLCの送信/受信が可能であるが、実際のデータ長は常に8バイトに制限されている。
2つの識別子フィールドは、結合して29ビットの識別子を形成する。
CAN FD標準フレームフォーマット
CAN標準フレームとの違いは、r0ビットがFDFビットに変更され、その直後にres、BRS、ESIビットが追加されている。また、高ビットレート化やデータ長変更に伴う信頼性確保のため、CRCフィールドの直前にスタッフカウントが追加され、CRCの長さが変更されている。
CAN FD標準フレームフォーマットは以下の通りである。
| フィールド名 | ビット長 | 目的 |
|---|---|---|
| フレーム開始（SOF） | 1 | フレーム送信の開始を示す。 |
| 識別子（緑） | 11 | （一意な）識別子。メッセージ優先度も表す。 |
| リモート要求代替（RRS） | 1 | CANのRTRビットがRRSビットに置き換えられた。CAN FDではリモートフレームがないためドミナント（0）でなければならない。 |
| 識別子拡張ビット（IDE） | 1 | 11ビットの識別子を持つ標準フレームフォーマットではドミナント（0）。 |
| FDフォーマット識別ビット（FDF） | 1 | CAN FDのデータフレームではリセッシブ（1）。 |
| 予約ビット（res） | 1 | 予約ビット。ドミナント（0）である必要がある。 |
| ビットレートスイッチ（BRS） | 1 | データフィールドのビットレートが高速ならリセッシブ（1）、通常速度ならドミナント（0）。BRS=1の場合はESIからCRCデリミタまでが高ビットレートとなる。 |
| エラー状態（ESI） | 1 | 送信ノードのエラー状態。Error Passiveの場合はリセッシブ（1）、Error Activeの場合はドミナント（0）。 |
| データ長コード（DLC）（黄） | 4 | データのバイト数（0–8/12/16/20/24/32/48/64バイト）。CANではDLCの値が8以上の場合は8バイトであったが、CAN FDの場合はDLCの値8～15に対して8/12/16/20/24/32/48/64バイトのデータ長が割り当てられた。 |
| データフィールド（赤） | 0–512 | 送信されるデータ（DLCフィールドによってバイト単位で指定された長さ）。 |
| スタッフカウント | 4 | スタッフビットの数を8で割った余り（3ビット）とパリティビット（1ビット）の合計4ビット。 |
| CRC | 17/21 | 巡回冗長検査。CANでは15ビットであったが、CAN FDではデータ長が16バイト以下なら17ビット、16バイト超なら21ビットに強化された。 |
| CRCデリミタ | 1 | リセッシブ（1）でなければならない。受信側は2ビットまでのCRCデリミタを許容する必要がある。 |
| ACKスロット | 1 | 送信機はリセッシブ（1）を送信する。2ビットまでのACKスロットを許容する必要がある。 |
| ACKデリミタ | 1 | リセッシブ（1）でなければならない。 |
| フレーム終了（EOF） | 7 | 全てリセッシブ（1）でなければならない。 |
CAN FD拡張フレームフォーマット
CAN拡張フレームとの違いは、r1,r0ビットがFDFビットに変更され、その直後にres、BRS、ESIビットが追加されている。また、高ビットレート化やデータ長変更に伴う信頼性確保のため、CRCフィールドの直前にスタッフカウントが追加され、CRCの長さが変更されている。
CAN FD拡張フレームフォーマットは以下の通りである。
| フィールド名 | ビット長 | 目的 |
|---|---|---|
| フレーム開始（SOF） | 1 | フレーム送信の開始を示す。 |
| 識別子（緑） | 11 | （一意な）識別子。メッセージ優先度も表す。 |
| 代替リモートリクエスト（SRR） | 1 | リセッシブ（1）でなければならない。 |
| 識別子拡張ビット（IDE） | 1 | 29ビットの識別子を持つ拡張フレームフォーマットではリセッシブ（1）でなければならない。 |
| 識別子拡張（緑） | 18 | （一意な）識別子の第二の部分。メッセージ優先度も表す。 |
| リモート要求代替（RRS） | 1 | CANのRTRビットがRRSビットに置き換えられた。CAN FDではリモートフレームがないためドミナント（0）でなければならない。 |
| FDフォーマット識別ビット（FDF） | 1 | CAN FDのデータフレームではリセッシブ（1）。 |
| 予約ビット（res） | 1 | 予約ビット。ドミナント（0）である必要がある。 |
| ビットレートスイッチ（BRS） | 1 | データフィールドのビットレートが高速ならリセッシブ（1）、通常速度ならドミナント（0）。BRS=1の場合はESIからCRCデリミタまでが高ビットレートとなる。 |
| エラー状態（ESI） | 1 | 送信ノードのエラー状態。Error Passiveの場合はリセッシブ（1）、Error Activeの場合はドミナント（0）。 |
| データ長コード（DLC）（黄） | 4 | データのバイト数（0–8/12/16/20/24/32/48/64バイト）。CANではDLCの値が8以上の場合は8バイトであったが、CAN FDの場合はDLCの値8～15に対して8/12/16/20/24/32/48/64バイトのデータ長が割り当てられた。 |
| データフィールド（赤） | 0–512 | 送信されるデータ（DLCフィールドによってバイト単位で指定された長さ）。 |
| スタッフカウント | 4 | スタッフビットの数を8で割った余り（3ビット）とパリティビット（1ビット）の合計4ビット。 |
| CRC | 17/21 | 巡回冗長検査。CANでは15ビットであったが、CAN FDではデータ長が16バイト以下なら17ビット、16バイト超なら21ビットに強化された。 |
| CRCデリミタ | 1 | リセッシブ（1）でなければならない。受信側は2ビットまでのCRCデリミタを許容する必要がある。 |
| ACKスロット | 1 | 送信機はリセッシブ（1）を送信する。2ビットまでのACKスロットを許容する必要がある。 |
| ACKデリミタ | 1 | リセッシブ（1）でなければならない。 |
| フレーム終了（EOF） | 7 | 全てリセッシブ（1）でなければならない。 |
リモートフレーム
- 一般に、データ送信は、データフレームを送信するデータ送信元ノード（例えば、センサ）との自律的な基準で実行される。しかし、宛先ノードが遠隔フレームを送信することによってソースからデータを要求することも可能である。
- データフレームとリモートフレームには2つの違いがある。第一に、データフレームではRTRビットがドミナント（0）であったのに対し、リモートフレームではリセッシブ（1）となる。第二に、リモートフレームにはデータフィールドが存在しない。DLCフィールドは、要求されたメッセージ（送信されたものではない）のデータ長を示す。
同じ識別子を持つデータフレームとリモートフレームが同時に送信された場合、識別子に続くRTRビットがドミナント（0）であるデータフレームの方がアービトレーションを獲得する。
エラーフレーム
エラーフレームは、2つのフィールドから構成されている。
- 最初のフィールドは、異なるノードからのエラーフラグ（6-12ビットのドミナント/リセッシブビット）の重ね合わせによって与えられる。
- 第二のフィールドは、エラーデリミタ（8ビットのリセッシブビット）である。
エラーフラグには2種類ある。
- アクティブエラーフラグ: 6ビットのドミナントビット。エラー状態「エラーアクティブ」にあるネットワーク上のエラーを検出したノードによって送信される。
- パッシブエラーフラグ: 6ビットのリセッシブビット。エラー状態「エラーパッシブ」にあるネットワーク上のアクティブなエラーフレームを検出するノードによって送信される。
オーバーロードフレーム
オーバーロードフレームには、2つのビットフィールド・オーバーロードフラグとオーバーロードデリミタが含まれる。オーバーロードフラグには、次の2種類がある。
- 受信機の内部状態。次のデータフレームまたはリモートフレームの遅延を要求する。
- 中断中のドミナントビットの検出。
ケース1によるオーバーロードフレームの開始は、予期される休止の最初のビット時間でのみ開始することが可能であるが、ケース2によるオーバーロードフレームは、ドミナントビットを検出した後に1ビットを開始する。オーバーロードフラグは6ビットのドミナントビットで構成される。全体的なフォームは、アクティブエラーフラグの形式に対応する。オーバーロードフラグの形式は、固定形式の断続フィールドを破棄する。結果として、他のすべてのノードも過負荷状態を検出し、即座にオーバーロードフラグの送信を開始する。オーバーロードデリミタは8ビットのリセッシブビットから構成される。オーバーロードデリミタは、エラーデリミタと同じ形式である。
ACKスロット
肯定応答（ACK）スロットは、有効なCANフレームの受信を確認するために使用される。エラーを検出することなくフレームを受信した各ノードは、ACKスロット内でドミナントビットを送信する。従って、送信機のリセッシブレベルを無効にする。送信機がACKスロット内のリセッシブレベルを検出すると、受信機が有効なフレームを発見しなかったことがわかる。受信ノードは、有効なフレームを受信しなかったことを示すためにリセッシブを送信することができるが、有効なフレームを受信した別のノードは、これをドミナントに置き換えることができる。送信ノードは、メッセージがCANネットワーク上の全てのノードによって受信されたかどうかを知ることができない。
フレーム間スペース
データフレームとリモートフレームは、フレーム間スペースと呼ばれるビットフィールドによって先行するフレームから分離される。フレーム間スペースは、少なくとも3つの連続するレセッシブ（1）ビットからなる。その後、ドミナントビットが検出されると、それは次のフレームのフレーム開始（SOF）ビットと見なされる。オーバーロードフレームとエラーフレームの前はにフレーム間スペースがなく、複数のオーバーロードフレームはフレーム間スペースで区切られていない。フレーム間スペースは、ビットフィールドの休止およびバスアイドルを含み、前のメッセージの送信機であったエラーパッシブステーションのための送信を一時停止する[12]。
ビットスタッフィング
同期を維持するのに十分な遷移を保証するために、同じ極性のビットが5つ連続したら逆の極性のビット（スタッフビット）が挿入される。この方法はビットスタッフィングと呼ばれ、CANで使用されるnon-return-to-zero（NRZ）符号で同期をとるために必要である。データフレームに挿入されたスタッフビットは、受信機によって取り除かれる（デスタッフされる）。
フレーム内の全てのフィールドはビットスタッフィングの対象となる。ただし、CRCデリミタ、ACKフィールド、フレーム終了は固定長であり、ビットスタッフィングの対象外である。ビットスタッフィングが使用されるフィールドでは、同じタイプの6つの連続ビット（111111または000000）はエラーと見なされる。アクティブエラーフラグは、エラーを検出したノードによって送信され、6つの連続するドミナントビットを送信することで、他のノードに強制的にビットスタッフィングエラーを起こさせる。
ビットスタッフィングがあるため、上記の表に示すビットの合計よりも、実際のデータフレームが大きくなる可能性がある。
CAN下位層標準
ISO 11898シリーズは、自動車内で使用する分散リアルタイム制御や多重化をサポートするCANと呼ばれるシリアル通信技術の物理層・データリンク層（OSI参照モデルの第1層・第2層）を規定している[13]。
いくつかのCAN物理層およびその他の標準がある。
ISO 11898-1:2015は、CANのデータリンク層（DLL）と物理的な信号伝達を規定している[14]。この文書は、ISO/IEC 7498-1で確立されているOSI参照モデルに従って、階層の面でCANの一般的なアーキテクチャを記述し、デジタル情報の交換を設定するための特性モジュールは、論理リンク制御（LLC）副層および媒体アクセス制御（MAC）副層の詳細な仕様を有するCAN DLLを実装する。
ISO 11898-2:2003は、高速（1 Mbit/sまでの伝送速度）の（ISO 8802-3に準拠した）媒体アクセスユニット（MAU）といくつかの媒体依存インタフェース（MDI）機能を規定している。すなわち、CANの物理層を構成する。ISO 11898-2は、2線式の平衡信号方式を使用している。これは、自動車のパワートレインアプリケーションおよび産業用制御ネットワークで最も使用される物理層である。
ISO 11898-3:2006は、40 kBit/s以上125 kBit/s以下の伝送速度でCANを装備した自動車の電子制御ユニット間のデジタル情報の交換を設定するための、低速でフォールトトレラントな媒体依存インタフェースを規定している。
ISO 11898-4:2004は、CAN（TTCAN）における時間トリガー通信を規定している。CANを装備した自動車の電子制御ユニット（ECU）間での時間情報に基づくデジタル情報交換の設定に適用可能であり、ISOに準拠した論理リンクおよび媒体アクセス制御の両方の動作を調整するフレーム同期エンティティを指定する時間トリガ通信スケジュールを提供する。
ISO 11898-5:2007は、自動車内で使用するための伝送速度が1 Mbit/sまでのCAN物理層を規定している。これは、ISO 8802-2に準拠したいくつかの媒体依存インタフェース機能だけでなく、媒体アクセスユニット機能についても説明している。これは、アクティブなバス通信が存在しない間に低消費電力機能を必要とするシステムの新しい機能を扱うISO 11898-2の拡張版である。
ISO 11898-6:2013は、自動車内で使用するための伝送速度が1 Mbit/sまでのCAN物理層を規定している。これは、ISO 8802-2に準拠したいくつかの媒体依存インタフェース機能だけでなく、媒体アクセスユニット機能についても説明している。これは、ISO 11898-2とISO 11898-5の拡張であり、構成可能なCANフレームを使用した選択的ウェイクアップメカニズムを指定している。
ISO 16845-1:2004は、ISO 11898-1で規定されているCAN仕様のCAN実装の適合性をチェックするのに必要な方法論と抽象的なテストスイートを提供する。
ISO 16845-2:2014は 、実装された選択的ウェークアップ機能を備えたCANトランシーバが指定された機能に適合しているかどうかを検証するテスト計画を実現するためのテストケースとテスト要件を設定する。ISO 16845-2:2014で定義されているテストの種類は、適合テスト（conformance testing）と呼ばれる。
CANベースの上位層プロトコル
CAN標準には、フロー制御、デバイスアドレッシング、1つのメッセージよりも大きなデータブロックの転送、アプリケーションデータのようなアプリケーション層プロトコルのタスクは含まれていないため、上位層プロトコルの多くの実装が作成された。その内のいくつかはビジネスエリアで標準化されているが、各メーカーがそれを拡張している。乗用車の場合、各メーカーに独自の標準がある。これらの実装には以下のものがある。
標準化されたアプローチ
- ARINC 812, ARINC 825（航空業界向け）
- CANopen - EN 50325-4（産業オートメーションに使用）
- DeviceNet（産業オートメーションに使用）
- EnergyBus - CiA 454（軽電気自動車用）
- ISOBUS - ISO 11783（農業用）
- ISO-TP - ISO 15765-2（自動車診断用トランスポート層プロトコル）
- SAE J1939（バス・トラック用車載ネットワーク）
- MilCAN
- NMEA 2000 - IEC 61162-3（海洋産業用）
- Unified Diagnostic Services（UDS） - ISO 14229（自動車診断用）
その他のアプローチ
- CANaerospace - Stock Flight Systems社（航空業界向け）
- CAN Kingdom - Kvaser社（組み込み制御システム）
- CCP/XCP（車載ECU較正）
- GMLAN - ゼネラルモーターズ（ゼネラルモーターズ向け）
- RV-C - RVIA社（レクリエーショナル・ビークルに使用）
- SafetyBUS p - Pilz社（産業オートメーションに使用）
- UAVCAN（航空宇宙およびロボット工学）
セキュリティ
CANは低レベルのプロトコルであり、本質的にセキュリティ機能をサポートしていない。標準のCAN実装には暗号化もなく、これらのネットワークは中間者攻撃に対してオープンである。ほとんどの実装では、アプリケーションは独自のセキュリティメカニズムを導入することが期待されている。例えば、入ってくるコマンドやネットワーク上の特定のデバイスの存在を認証するなど。十分なセキュリティ対策を講じないと、相手がバスにメッセージを送信した場合、さまざまな種類の攻撃が発生する可能性がある[15]。ファームウェアの変更、キーのプログラミング、アンチロックブレーキアクチュエータの制御など、いくつかの安全上重要な機能のためのパスワードが存在するが、これらのシステムは普遍的に実装されておらず、限られた数のシード/キーペアを持っている。
実際にエンジン始動に特化したCANデバイスを接続し、短時間で自動車を窃盗する事例が発生している[16][17]。
開発ツール
CANバスの開発やトラブルシューティングを行う際には、ハードウェア信号の検査が非常に重要である。ロジックアナライザやプロトコル・アナライザは、信号を収集、分析、デコード、保存するツールで、高速波形を見ることができる。また、CANバスモニターなどの特殊ツールもある。
CANバスモニタは、CANバスを使用するハードウェアの開発中に使用される分析ツールで、多くはハードウェアとソフトウェアの組み合わせである。
通常、CANバスモニタはCANバス上のトラフィックを傍受し、ユーザインターフェイスに表示する。多くの場合、CANバスモニタはCANフレームをバスに送信することによってCANバスの動作をシミュレートすることもできる。そのため、CANバスモニタは、CANバスに接続された特定のデバイスからの反応を検証するために、特定のデバイスから予想されるCANトラフィックを検証したり、CANトラフィックをシミュレートするために使用できる。
ライセンス
ボッシュはこの技術の特許を保有しているが、元のプロトコルに関連する特許は既に期限切れとなっている。CAN互換マイクロプロセッサの製造元はCAN商標およびCAN FDに関連する新しい特許の使用に対してボッシュ社にライセンス料を支払っており、通常、それはチップの価格として顧客に転嫁される。カスタムASICやCAN互換モジュールを搭載したFPGAを使用している製品の製造業者は、CAN商標またはCAN FD機能を使用する場合、CANプロトコルライセンス料を支払う必要がある[18]。
ライセンス料を回避する一つの方策として、CANバスとは別の名前で同じプロトコルを実装することが考えられる。例えば、ESP32が対応するTwo-Wire Automotive Interface(TWAI)は、ISO11898-1に互換性がある、つまりCANバス2.0と互換性を持つ。[19][20][21]同様の例として、PhillipのI2Cの特許が切れた時Atmelが搭載したTWI(Two-Wire-Interface)が挙げられる。[22]
注釈・出典
- ^ “CAN History”. CAN in Automation. 2017年8月1日閲覧。
- ^ Bosch Semiconductor CAN Literature
- ^ CAN FDパッシブ用のCANトランシーバは、CAN FDフレーム受信時に通信を遮断することによりCAN FDの通信を邪魔しない動作をする
- ^ de Andrade, R.; Hodel, K. N.; Justo, J. F.; Laganá, A. M.; Santos, M. M.; Gu, Z. (2018). “Analytical and Experimental Performance Evaluations of CAN-FD Bus”. IEEE Access 6: 21287 - 21295. doi:10.1109/ACCESS.2018.2826522.
- ^ Building Adapter for Vehicle On-board Diagnostic, obddiag.net, accessed 2009-09-09
- ^ Comparison of Event-Triggered and Time-Triggered Concepts with Regard to Distributed Control Systems A. Albert, Robert Bosch GmbH Embedded World, 2004, Nürnberg
- ^ “NISMO Increases GT6 GPS Data Logger Functionality and Track Count”. www.gtplanet.net. 2017年8月1日閲覧。
- ^ ISO11783 a Standardized Tractor – Implement Interface
- ^ Understanding Microchip’s CAN Module Bit Timing
- ^ “ISO7637-3 diodes protection for CAN bus”. 2017年8月1日閲覧。
- ^ “CAN bus ESD protection”. 2017年8月1日閲覧。
- ^ “CAN BUS MESSAGE FRAMES – Overload Frame, Interframe Space”. 2017年8月1日閲覧。
- ^ “Controller Area Network (CAN)”. Vector Group. 2013年9月25日閲覧。
- ^ “ISO 11898-1:2015 - Road vehicles -- Controller area network (CAN) -- Part 1: Data link layer and physical signalling”. ISO. 2017年8月1日閲覧。
- ^ “We Drove a Car While It Was Being Hacked”. motherboard.vice.com. 2017年8月1日閲覧。
- ^ 日本放送協会. “鍵はかけていたのに… なぜ盗まれた？”. NHKニュース. 2021年11月6日閲覧。
- ^ 「ランクル、２日間で９台盗難…「キャンインベーダー」で解錠か」『読売新聞オンライン』2021年11月11日。2021年11月11日閲覧。
- ^ License Conditions CAN Protocol and CAN FD Protocol
- ^ “Two-Wire Automotive Interface TWAI (CAN) - Ineltek Docs” (英語) (2021年10月11日). 2025年3月22日閲覧。
- ^ “Two-Wire Automotive Interface (TWAI) - ESP32 - — ESP-IDF Programming Guide v5.2.5 documentation”. docs.espressif.com. 2025年3月22日閲覧。
- ^ “Why rename CAN to TWAI? (IDFGH-3645) · Issue #5580 · espressif/esp-idf” (英語). GitHub. 2025年3月22日閲覧。
- ^ “CAN Bus Licensing” (英語). Electrical Engineering Stack Exchange. 2025年3月22日閲覧。
関連項目
- バイトフライト
- CANopen - CANをベースにした、組み込みシステム用の通信プロトコル
- CANpie - オープンソースのCANデバイスドライバ
- CAN FD - 高速伝送可能なCANの新しい実装
- can4linux - オープンソースのLinux用のCANデバイスドライバ
- FlexCAN
- FlexRay
- ISO 14230 - 車両故障診断プロトコルの国際規格
- ネットワークバスの一覧
- Local Interconnect Network（LIN）
- Media Oriented Systems Transport（MOST）
- OBD-II PIDs
- OSEK
- SAE J1939 - トラックやバスのための通信プロトコル
- SocketCAN - オープンソースのLinux用のCANドライバとネットワークスタック
外部リンク
- Controller Area Network (CAN), Local Interconnect Network (LIN) and Telematics Courses
- Wiki on CAN technology and products
- Bosch specification (old document — slightly ambiguous/unclear in some points, superseded by the standard [1])
- Bosch CAN FD Specification Version 1.0
- Controller Area Network (CAN) Schedulability Analysis: Refuted, Revisited and Revised
- Pinouts for common CAN bus connectors
- Independent discussion platform CANLIST
- A webpage about CAN in automotive
- Controller Area Network (CAN) Schedulability Analysis with FIFO Queues
- Controller Area Network (CAN) Implementation Guide
- (Controller_Area_Network):_Introduction_and_Fundamentals.htm Free Tutorial: Controller Area Network (CAN) Introduction and Fundamentals
- Freeware Bit-Timing calculator for Windows, supports a lot of microcontrollers, e.g. Atmel, STM32, Microchip, Renesas, ... (ZIPfile)
- CAN and CAN-FD protection in automotive
- Free e-learning module "Introduction to CAN"
- ARINC-825 Tutorial (video) from Excalibur Systems Inc.
- ISO - International Organization for Standardization
- Understanding and Using the Controller Area Network from UC Berkeley
- 連載記事「車載ネットワーク“CANの仕組み”教えます」
- CANプロトコルチュートリアル
| 典拠管理データベース: 国立図書館 |
|---|
「Controller Area Network」の例文・使い方・用例・文例
- controller area networkのページへのリンク
