CANバス

コントローラエリアネットワーク

CAN-in-Automation による CAN バスの非公式ロゴ。
タイプ	シリアル通信 バス
生産履歴
デザイナー	ボッシュ株式会社
設計	1983年; 41年前 （1983年）
外部の	いいえ
電気
信号	差額
最大電圧	16V DC
データ
データ信号	トランシーバー駆動
幅	1ビット（双方向）
ビットレート	0.05、0.125、0.250、0.500、0.800、または1.0 Mbit/s 、 CAN FDの場合は最大5.0 Mbit/s
最大デバイス数	32、64、または127（規格によって異なります）
プロトコル	シリアル、半二重、非同期
ピン配置
CAN-H	CAN 高（黄）
CAN-L	CAN 低 (緑)

コントローラエリア ネットワーク( CAN ) は、主に電子制御ユニット (ECU) 間の効率的な通信を可能にするために設計された車両バス規格です。CAN バス プロトコルは、もともと多重化によって自動車の電気配線の複雑さとコストを削減するために開発されましたが、その後、さまざまな状況で採用されてきました。このブロードキャスト ベースのメッセージ指向プロトコルは、アービトレーションと呼ばれるプロセスによってデータの整合性と優先順位付けを確保し、複数のデバイスが同時にデータを送信しようとした場合でも、最も優先度の高いデバイスが送信を続行し、他のデバイスが後退できるようにします。その信頼性は、電気ノイズを軽減する差動信号によって強化されています。CAN プロトコルの一般的なバージョンには、CAN 2.0、CAN FD、および CAN XL があり、データ レート機能と最大データ ペイロード サイズが異なります。

• CAN バスの概要:コントローラ エリア ネットワーク (CAN) は、車両内の電子制御ユニット (ECU) 間の効率的な通信を目的として設計された車両バス規格であり、配線の複雑さとコストを削減します。
• 開発と採用: CAN は 1980 年代に Bosch によって開発され、1991 年の Mercedes-Benz W140 で初めて使用されました。それ以来、自動車業界やその他の業界で標準となっています。
• バージョンと標準:バージョンには CAN 2.0、CAN FD、CAN XL があり、それぞれ異なるデータ レートとペイロード サイズを提供します。ISO 11898 などの ISO 標準は、物理層とデータ リンク層を定義します。
• 用途: CAN は、エンジン制御、自動運転、診断など、さまざまな車両サブシステムで使用されます。リアルタイム通信と調停による優先順位付けをサポートします。

CANバスの開発は1983年にロバート・ボッシュ社で始まりました。^[1]このプロトコルは1986年にミシガン州デトロイトで開催された自動車技術者協会（SAE）会議で正式に発表されました。最初のCANコントローラチップは1987年にインテルによって導入され、その後すぐにフィリップスによって導入されました。^[1] 1991年に発売されたメルセデスベンツW140は、 CANベースの多重配線システムを搭載した最初の量産車でした。^{[2] [3]}

Bosch は CAN 仕様のいくつかのバージョンを公開しました。最新のものは 1991 年に公開された CAN 2.0 です。この仕様は 2 つの部分から構成されています。パート A は 11 ビットの識別子を持つ標準形式、パート B は 29 ビットの識別子を持つ拡張形式です。11 ビットの識別子を使用する CAN デバイスは一般に CAN 2.0A と呼ばれ、29 ビットの識別子を使用する CAN デバイスは一般に CAN 2.0B と呼ばれます。これらの標準規格は、他の仕様やホワイト ペーパーとともに Bosch から無料で入手できます。^[4]

1993 年、国際標準化機構(ISO) は CAN 規格 ISO 11898 をリリースしました。これは後に 2 つの部分に再構成されました。データ リンク層をカバーする ISO 11898-1と、高速 CAN の CAN 物理層をカバーする ISO 11898-2 です。その後、低速でフォールト トレラントな CAN の CAN 物理層をカバーする ISO 11898-3 がリリースされました。物理層規格 ISO 11898-2 と ISO 11898-3 は、Bosch CAN 2.0 仕様の一部ではありません。

2012 年、Bosch はCAN FD 1.0、つまり CAN with Flexible Data-Rate をリリースしました。この仕様では、異なるデータ長を許可するだけでなく、調停が決定された後にオプションでより高速なビット レートに切り替えることができる、異なるフレーム形式を使用します。CAN FD は既存の CAN 2.0 ネットワークと互換性があるため、新しい CAN FD デバイスは、同じ CAN 2.0 通信パラメータを使用して、既存の CAN デバイスと同じネットワーク上で共存できます。2018 年現在^{[アップデート]}、Bosch は CAN 標準の拡張に積極的に取り組んでいます。

CANバスは、車載診断（OBD）-II車両診断規格で使用される5つのプロトコルの1つです。OBD-II規格は、 1996年モデル以降、米国で販売されるすべての乗用車と小型トラックに義務付けられています。EOBD規格は、2001年以降、欧州連合で販売されるすべてのガソリン車と2004年以降、すべてのディーゼル車に義務付けられています。^[5]

• 乗用車、トラック、バス（内燃機関車および電気自動車）
• 農業機械
• 航空および航行用電子機器
• 発電機
• 産業オートメーションと機械制御
• エレベーター、エスカレーター
• ビルオートメーション
• 医療機器および装置
• ペデレック
• 鉄道模型
• 船舶およびその他の海事用途
• 照明制御システム
• 3Dプリンター
• ロボット工学/自動化

現代の自動車には、さまざまなサブシステム用に 70 個もの電子制御ユニット(ECU) が搭載されている場合があります。^[6]通常、最大のプロセッサはエンジン制御ユニットです。その他のプロセッサは、自動運転、先進運転支援システム (ADAS)、トランスミッション、エアバッグ、アンチロック ブレーキ/ABS、クルーズ コントロール、電動パワー ステアリング、オーディオ システム、パワー ウィンドウ、ドア、ミラー調整、ハイブリッド車/電気自動車のバッテリーおよび充電システムなどに使用されます。これらの一部は独立したサブシステムを形成しますが、他のサブシステム間の通信は不可欠です。サブシステムは、アクチュエータを制御したり、センサーからフィードバックを受信したりする必要がある場合があります。このニーズを満たすために CAN 標準が考案されました。重要な利点の 1 つは、異なる車両システム間の相互接続により、安全性、経済性、利便性の幅広い機能をソフトウェアのみを使用して実装できることです。このような機能を従来の自動車電気を使用してハード ワイヤードすると、コストと複雑さが増します。例は次のとおりです。

• 自動スタート/ストップ: 車両周囲のさまざまなセンサー入力 (速度センサー、ステアリング角度、エアコンのオン/オフ、エンジン温度) が CAN バスを介して照合され、静止時にエンジンを停止して燃費と排出量を改善できるかどうかが判断されます。
• 電動パーキングブレーキ:ヒルホールド機能は、車両の傾斜センサー (盗難警報装置でも使用) と道路速度センサー (ABS、エンジン制御、トラクション制御でも使用) からの入力を CAN バス経由で受け取り、車両が傾斜で停止しているかどうかを判断します。同様に、シートベルトセンサー (エアバッグ制御の一部) からの入力が CAN バスから送られ、シートベルトが締められているかどうかが判断され、発進時にパーキングブレーキが自動的に解除されます。
• 駐車支援システム: ドライバーがバックギアを入れると、トランスミッション制御ユニットは CAN バス経由で信号を送信し、駐車センサー システムとドア制御モジュールの両方をアクティブにして、助手席側のドアミラーを下向きに傾けて縁石の位置を表示します。また、CAN バスは雨滴センサーからの入力を受け取り、後退時にリア ウィンドスクリーン ワイパーを作動させます。
• 自動車線支援/衝突回避システム: 駐車センサーからの入力は、車線逸脱警告などの運転支援システムに外部の近接データを送るために CAN バスでも使用されます。さらに最近では、これらの信号が CAN バスを経由してアクティブ衝突回避システムのブレーキ バイ ワイヤを作動させることもあります。
• 自動ブレーキワイパー: 入力は、雨滴センサー (主に自動フロントガラスワイパーに使用) から CAN バス経由で ABS モジュールに送られ、走行中にブレーキを感知できない程度に作動させてブレーキローターから水分を除去します。一部の高性能AudiおよびBMWモデルには、この機能が組み込まれています。
• センサーは最適な場所に設置でき、そのデータは複数の ECU で使用できます。たとえば、屋外温度センサー (従来は前面に設置) をドアミラーに設置してエンジンによる加熱を回避し、そのデータをエンジン、空調コントロール、ドライバー ディスプレイで使用できます。

近年、データ伝送速度と信頼性がそれほど重要でない空調やインフォテインメントなどの非クリティカルなサブシステム向けに CAN を補完するために、 LIN バス(Local Interconnect Network) 規格が導入されました。

• CAN バス プロトコルは、 2009 年からロード バイク用のShimano DI2 電子ギア シフト システムで使用されており、Ansmann およびBionXシステムのダイレクト ドライブ モーターでも使用されています。
• CAN バスは、一部の CAN コントローラとプロセッサのコストが低いため、一般的なオートメーション環境ではフィールドバスとしても使用されます。
• NISMOを含むメーカーは、CANバスデータを使用して、ビデオゲーム「グランツーリスモ6」のGPSデータロガー機能を使用して実際のレースラップを再現し、プレイヤーが実際のラップと競争できるようにすることを目指しています。^[7]
• ジョンズ ホプキンス大学応用物理学研究所のモジュラー義肢 (MPL) は、ローカル CAN バスを使用して、義手内のサーボとマイクロコントローラ間の通信を容易にします。
• FIRST ロボット競技会のチームは、roboRIO と他のロボット制御モジュール間の通信に CAN バスを広く使用しています。
• CueScriptテレプロンプターシリーズは、同軸ケーブルを介してCANバスプロトコルを使用し、CSSC（デスクトップスクロールコントロール）をメインユニットに接続します。
• CAN バス プロトコルは、主要な商用デジタル コマンド制御システム メーカーによる鉄道模型のセンサー フィードバック システムや、さまざまなオープン ソースのデジタル鉄道模型制御プロジェクトなど、電気的にノイズの多い環境でのフォールト トレランスを備えているため、広く実装されています。
• Shearwater Researchは、ダイブコンピュータをさまざまなメーカーのダイビングリブリーザーに統合するために、 DiveCAN ^[8]としてプロトコルを実装しました。

CAN 2.0 は、その伝統により、最大ペイロード サイズが 8 バイト、標準的なボー レートが 500 kbit/s の最も広く使用されているプロトコルです。CAN 2.0A (標準 CAN) と CAN 2.0B (拡張 CAN) を含む従来の CAN は、主に識別子フィールドの長さが異なります。CAN 2.0A は 11 ビットの識別子を使用し、CAN 2.0B は 29 ビットの識別子を使用します。CAN 2.0B の長い識別子により、より多くの一意のメッセージ識別子を使用できるようになります。これは、多くのノードとデータ タイプを含む複雑なシステムでは有利です。ただし、一意のメッセージ識別子が増えるとフレーム長も長くなり、最大データ レートが低下します。さらに、拡張識別子では、使用可能な識別子値が増えるため、メッセージの優先順位をより細かく制御できます。ただし、これにより互換性の問題が発生する可能性があります。 CAN 2.0B デバイスは一般に CAN 2.0A デバイスと通信できますが、その逆はできません。これは、長い識別子を処理する際にエラーが発生する可能性があるためです。高速 CAN 2.0 は 40 kbit/s から 1 Mbit/s のビット レートをサポートし、上位層プロトコルの基礎となります。対照的に、低速 CAN 2.0 は 40 kbit/s から 125 kbit/s のビット レートをサポートし、2 本のワイヤのいずれかに障害が発生しても通信を継続できるようにすることでフォールト トレランスを提供し、各ノードは独自の終端を維持します。^{[4] [9] [10] [11]}

ISO 11898-1 として標準化された CAN FD (Flexible Data-Rate) は、ボッシュによって開発され、2012 年にリリースされました。これは、現代の高性能車両におけるデータ転送の増加のニーズを満たすためです。単一フレームの送信中に可変データ レートを提供し、より低いデータ レートで調停フェーズを実行して堅牢な通信を実現すると同時に、データ ペイロードをより高いデータ レートで送信してスループットを向上させることができます。これは、電気的にノイズの多い環境でノイズ耐性を向上させるために特に役立ちます。CAN FD では、柔軟なデータ フィールド サイズも導入され、最大サイズが 8 バイトから 64 バイトに増加しました。この柔軟性により、大容量データ転送に必要なフレーム数が削減され、より効率的なデータ転送が可能になります。これは、高解像度のセンサー データやソフトウェア更新などのアプリケーションに役立ちます。

CAN FDは、CAN 2.0Bと同じフレームフォーマットを使用し、フレームがCAN FDフレームか標準のCAN 2.0フレームかを示す新しい制御フィールドを追加することで、CAN 2.0デバイスとの下位互換性を維持しています。これにより、CAN FDデバイスは同じバス上でCAN 2.0デバイスと共存できますが、より高いデータレートとより大きなデータペイロードは、他のCAN FDデバイスと通信する場合にのみ利用できます。^{[11] [10] [12]}

CAN XLは、CiA 610-1で規定され、ISO11898-1の一部として標準化されており、最大2,048バイトのペイロードと最大20 Mbit/sのデータレートをサポートします。CAN FDとイーサネット（100BASE-T1）のギャップを埋めながら、CANの衝突解決の利点を維持します。CAN XLコントローラは、クラシックCANとCAN FD通信も処理できるため、混合ネットワークでの互換性が確保されます。その大きなデータフィールドにより、IP（インターネットプロトコル）などの上位層プロトコルやイーサネットフレームのトンネリングが可能になります。^{[4] [13] [14]}

CAN は、ノードとも呼ばれる電子制御ユニット (ECU) を接続するためのマルチマスター シリアル バス規格です(自動車用電子機器が主要なアプリケーション ドメインです)。通信するには、CAN バス上で 2 つ以上のノードが必要です。ノードは、FPGAを介して、 PLDなどの単純なデジタル ロジックから、大規模なソフトウェアを実行する組み込みコンピューターまで、さまざまなデバイスとインターフェイスできます。このようなコンピューターは、汎用コンピューター (ラップトップなど) が USB ポートまたはイーサネット ポートを介して CAN バス上のデバイスと通信できるようにするゲートウェイになることもあります。

すべてのノードは、物理的に従来型の2 線式バスを介して相互に接続されます。ワイヤは、特性インピーダンスが 120 Ω (公称) のツイストペアです。

このバスは、差動 ワイヤード AND信号を使用します。2 つの信号、CAN ハイ (CANH) と CAN ロー (CANL) は、CANH > CANL で「優位」状態に駆動されるか、または駆動されずに受動抵抗器によって「劣位」状態にプルされ、CANH ≤ CANL になります。0 データ ビットは優位状態をエンコードし、1 データ ビットは劣位状態をエンコードします。ワイヤード AND 規則をサポートし、バス上で ID 番号の小さいノードに優先順位を与えます。

ISO 11898-2 は、高速 CAN (ビット速度は CAN で最大 1  Mbit/s、 CAN-FD で最大 5 Mbit/s) とも呼ばれ、両端が 120 Ω の抵抗で終端されたリニア バスを使用します。

高速 CAN 信号は、 いずれかのデバイスがドミナント (0) を送信しているときに CANH ワイヤを 3.5 V に向けて駆動し、CANL ワイヤを 1.5 V に向けて駆動します。一方、ドミナントを送信しているデバイスがない場合、終端抵抗器は 2 本のワイヤを公称差動電圧 0  V で受動的にリセッシブ (1) 状態に戻します (受信機は 0.5 V 未満の差動電圧を リセッシブと見なします)。ドミナント差動電圧は公称 2  V です。ドミナントの共通モード電圧 (CANH+CANL)/2 は共通電圧の 1.5 ～ 3.5  V 以内である必要があり、リセッシブの共通モード電圧は 共通電圧の ±12 以内である必要があります。

ISO 11898-3 は、低速またはフォールト トレラント CAN (最大 125  kbit/s) とも呼ばれ、リニア バス、スター バス、またはリニア バスで接続された複数のスター バスを使用し、各ノードで全体の終端抵抗の一部によって終端されます。全体の終端抵抗は 100  Ω に近い値である必要がありますが、100 Ω 未満であってはなりません。

低速フォールト トレラント CAN 信号は高速 CAN と同様に動作しますが、電圧振幅が大きくなります。ドミナント状態は、ドミナント (0) を送信するときに、CANH をデバイス電源電圧 (5  V または 3.3  V) に向かって駆動し、CANL を 0 V に向かって駆動することによって送信されます。一方、終端抵抗は、CANH が 0 V、CANL が 5 V の状態でバスをリセッシブ状態に引き込みます。これにより、CANH − CANL の符号のみを考慮する、よりシンプルな受信機が可能になります。両方のワイヤは、損傷することなく -27 ～ +40 V を処理できる必要があります。    

高速 CAN と低速 CAN の両方において、CAN ワイヤがアクティブに駆動されているため、劣勢から優勢への遷移が発生すると遷移速度が速くなります。優勢から劣勢への遷移速度は、主に CAN ネットワークの長さと、使用されるワイヤの静電容量によって決まります。

高速 CAN は通常、バスが環境の端から端まで走る自動車や産業のアプリケーションで使用されます。フォールト トレラント CAN は、ノードのグループを相互に接続する必要がある場合によく使用されます。

仕様では、バスを最小および最大の共通モード バス電圧内に維持することが要求されていますが、バスをこの範囲内に維持する方法は定義されていません。

CAN バスは終端する必要があります。終端抵抗は反射を抑制するため、またバスをリセッシブ状態またはアイドル状態に戻すために必要です。

高速CANは、リニアバスの両端に120Ωの抵抗器を使用します。低速CANは、各ノードに抵抗器を使用します。ISO11783で定義されている終端バイアス回路など、他のタイプの終端が使用される場合もあります。 [ ^9]

あ終端バイアス回路は、 4 線ケーブル上の CAN 信号に加えて、電源とグランドを提供します。これにより、各バス セグメントの両端で自動的に電気バイアスと終端が行われます。ISO11783 ネットワークは、バス セグメントと ECU のホット プラグインと取り外し用に設計されています。

各ノードには

• 中央処理装置、マイクロプロセッサ、またはホストプロセッサ
  • ホスト プロセッサは、受信したメッセージの意味と送信するメッセージを決定します。
  • センサー、アクチュエーター、制御デバイスをホスト プロセッサに接続できます。
• CANコントローラ - 多くの場合、マイクロコントローラの不可欠な部分
  • 受信: CAN コントローラは、メッセージ全体が利用可能になるまでバスから受信したシリアル ビットを保存し、その後、ホスト プロセッサがそれをフェッチできるようになります (通常は、CAN コントローラが割り込みをトリガーすることによって)。
  • 送信: ホスト プロセッサは送信メッセージを CAN コントローラに送信し、バスが空いているときに CAN コントローラはビ​​ットをバスにシリアルに送信します。
• ISO 11898-2/3 メディアアクセスユニット [MAU] 規格で定義された トランシーバー
  • 受信: データ ストリームを CAN バス レベルから CAN コントローラが使用するレベルに変換します。通常、CAN コントローラを保護するための保護回路が備わっています。
  • 送信: CAN コントローラからのデータ ストリームを CAN バス レベルに変換します。

各ノードはメッセージを送受信できますが、同時にはできません。メッセージまたはフレームは、主にメッセージの優先度を表す ID (識別子) と最大 8 バイトのデータで構成されます。CRC、確認応答スロット [ACK]、およびその他のオーバーヘッドもメッセージの一部です。改良された CAN FD では、データ セクションの長さがフレームあたり最大 64 バイトまで拡張されています。メッセージは、非ゼロ復帰(NRZ) 形式を使用してバスにシリアルに送信され、すべてのノードで受信できます。

CAN ネットワークによって接続されるデバイスは、通常、センサー、アクチュエータ、およびその他の制御デバイスです。これらのデバイスは、ホスト プロセッサ、CAN コントローラ、および CAN トランシーバーを 介してバスに接続されます。

CAN データ送信では、競合解決にロスレス ビット単位のアービトレーション方式を使用します。このアービ​​トレーション方式では、CAN ネットワーク上のすべてのノードを同期させて、CAN ネットワーク上のすべてのビットを同時にサンプリングする必要があります。このため、CAN は同期と呼ばれます。残念ながら、データは非同期形式、つまりクロック信号なしで送信されるため、同期という用語は正確ではありません。

CAN 仕様では、ドミナントビットとリセッシブビットという用語が使用されています。ドミナントは論理 0 (トランスミッターによってアクティブに電圧が駆動される)、リセッシブは論理 1 (抵抗器によってパッシブに電圧が戻される) です。アイドル状態はリセッシブ レベル (論理 1) で表されます。1 つのノードがドミナント ビットを送信し、別のノードがリセッシブ ビットを送信すると、衝突が発生し、ドミナント ビットが優先されます。つまり、優先度の高いメッセージに遅延はなく、優先度の低いメッセージを送信するノードは、ドミナント メッセージの終了後に 6 ビット クロックの再送信を自動的に試行します。このため、CAN はリアルタイムの優先順位付けされた通信システムとして非常に適しています。

論理 0 または 1 の正確な電圧は、使用する物理層によって異なりますが、CAN の基本原理では、送信ノード自体を含む各ノードが CAN ネットワーク上のデータをリッスンする必要があります。すべての送信ノードが同時に論理 1 を送信すると、送信ノードと受信ノードの両方を含むすべてのノードで論理 1 が認識されます。すべての送信ノードが同時に論理 0 を送信すると、すべてのノードで論理 0 が認識されます。1 つ以上のノードが論理 0 を送信し、1 つ以上のノードが論理 1 を送信している場合、論理 1 を送信しているノードを含むすべてのノードで論理 0 が認識されます。ノードが論理 1 を送信して論理 0 を認識すると、競合が発生していると認識し、送信を停止します。このプロセスを使用すると、論理 1 を送信するノードは、別のノードが論理 0 を送信すると、調停に負けてドロップアウトします。調停に負けたノードは、後で送信するためにそのメッセージを再キューに入れ、CAN フレームのビット ストリームは、送信するノードが 1 つだけになるまでエラーなく継続します。つまり、最初の 1 を送信したノードが調停に負けることになります。11 (CAN 2.0B の場合は 29) ビットの識別子は、CAN フレームの開始時にすべてのノードによって送信されるため、最も小さい識別子を持つノードは、フレームの開始時により多くのゼロを送信し、そのノードが調停に勝つか、または最も高い優先順位を持ちます。

たとえば、ID が 15 (バイナリ表現、00000001111) と 16 (バイナリ表現、00000010000) の 2 つのノードがある 11 ビット ID の CAN ネットワークを考えます。これらの 2 つのノードが同時に送信すると、各ノードは最初にスタート ビットを送信し、次に ID の最初の 6 つのゼロを送信しますが、調停決定は行われません。

ID ビット 4 が送信されると、ID 16 のノードは ID として 1 (劣勢) を送信し、ID 15 のノードは ID として 0 (優勢) を送信します。このとき、ID 16 のノードは 1 を送信したことは認識していますが、0 を見て衝突が発生し、調停に負けたことを認識します。ノード 16 は送信を停止し、ID 15 のノードはデータを失うことなく送信を続行できます。ID が最も低いノードが常に調停に勝ち、したがって最も高い優先順位を持ちます。

40 m 未満のネットワーク長では、最大 1 Mbit/s のビット レート が可能です 。ビット レートを下げると、ネットワーク距離を長くすることができます (例:  125 kbit/s で 500 m  )。改良されたCAN FD規格では、調停後にビット レートを上げることができ、データ セクションの速度を調停ビット レートの最大 10 倍以上に上げることができます。

メッセージIDは単一のCANバス上で一意である必要があります^[10]。そうでない場合、2つのノードが仲裁フィールド（ID）の終わりを超えて送信を継続し、エラーが発生します。

1990 年代初頭、メッセージの ID の選択は、単にデータの種類と送信ノードを識別することに基づいて行われていましたが、ID はメッセージの優先度としても使用されるため、リアルタイム パフォーマンスが低下しました。これらのシナリオでは、すべてのメッセージが期限内に間に合うようにするには、通常、CAN バスの使用率を 30% 程度に抑える必要がありました。しかし、ID がメッセージの期限に基づいて決定される場合、数値 ID が低いほど、つまりメッセージの優先度が高くなるため、メッセージの期限に間に合わない前に、バスの使用率を 70 ～ 80% に抑えることができます。^[15]

CANネットワーク上のすべてのノードは同じ公称ビットレートで動作する必要がありますが、ノイズ、位相シフト、発振器の許容誤差、発振器のドリフトにより、実際のビットレートが公称ビットレートと異なる場合があります。^[16]個別のクロック信号が使用されていないため、ノードを同期する手段が必要です。同期は調停中に重要であり、調停中のノードは、送信されたデータと他のノードの送信されたデータの両方を同時に確認できる必要があります。同期は、ノード間の発振器タイミングの変動がエラーを引き起こさないようにするためにも重要です。

同期は、バスアイドル期間 (開始ビット) の後の、最初の劣勢から優勢への遷移でのハード同期から始まります。フレーム中の劣勢から優勢への遷移ごとに再同期が行われます。CAN コントローラは、遷移が公称ビット時間の倍数で発生することを想定しています。遷移がコントローラが想定する正確な時間に発生しない場合は、コントローラはそれに応じて公称ビット時間を調整します。

調整は、各ビットを量子と呼ばれるいくつかの時間スライスに分割し、ビット内の 4 つのセグメント (同期、伝播、位相セグメント 1、位相セグメント 2) のそれぞれにいくつかの量子を割り当てることによって行われます。

ビットが分割される量子の数はコントローラによって異なり、各セグメントに割り当てられる量子の数はビット レートとネットワークの状態に応じて変化します。

予測より前または後に遷移が発生すると、コントローラは時間差を計算し、この時間までにフェーズ セグメント 1 を長くするか、フェーズ セグメント 2 を短くします。これにより、受信機と送信機のタイミングが効果的に調整され、同期されます。この再同期プロセスは、送信機と受信機が同期状態を維持するように、劣勢から優勢への遷移ごとに継続的に実行されます。継続的に再同期すると、ノイズによって引き起こされるエラーが削減され、調停に負けたノードに同期されていた受信ノードが、調停に勝ったノードに再同期できるようになります。

CAN プロトコルは、多くのネットワーク プロトコルと同様に、次の抽象化レイヤーに分解できます。

アプリケーション層

• アプリケーション固有のロジック

オブジェクトレイヤー

• メッセージフィルタリング（メールボックス）
• メッセージとステータスの処理

転送層

CAN 標準のほとんどは転送層に適用されます。転送層は物理層からメッセージを受信し、それらのメッセージをオブジェクト層に送信します。転送層は、ビット タイミングと同期、メッセージ フレーミング、調停、確認、エラー検出とシグナリング、および障害の制限を担当します。次の処理を実行します。

• 断層の限定
• エラー検出
• メッセージの検証
• 了承
• 仲裁
• メッセージのフレーミング
• 転送速度とタイミング
• 情報ルーティング

物理層

CAN バス ( ISO 11898 -1:2003) は、当初、物理層に関する抽象的な要件のみを含むリンク層プロトコルを規定していました。たとえば、ドミナント状態とリセッシブ状態を使用してビット レベルでマルチアクセス可能なメディアの使用を主張していました。物理層の電気的側面 (電圧、電流、導体の数) は、現在広く受け入れられているISO 11898 -2:2003 で規定されています。ただし、物理層の機械的側面 (コネクタの種類と数、色、ラベル、ピン配列) はまだ正式に規定されていません。その結果、自動車用 ECU には通常、さまざまな種類のケーブルを備えた特定の (多くの場合はカスタムの) コネクタがあり、そのうちの 2 つが CAN バス ラインです。それでも、機械的な実装に関する事実上の標準がいくつか登場しており、最も一般的なのは、次のピン配列を持つ 9 ピン D-sub タイプのオス コネクタです。

• ピン2: CAN-Low (CAN−)
• ピン3: GND (グランド)
• ピン 7: CAN-High (CAN+)
• ピン9: CAN V+ (電源)

この事実上のCAN の機械的標準は、ノード内で互いに並列に電気的に接続されたオスとメスの両方の 9 ピン D-sub コネクタを持つノードで実装できます。バス電源はノードのオス コネクタに供給され、バスはノードのメス コネクタから電力を供給されます。これは、電源がメス コネクタで終端されるという電気工学の慣例に従っています。この標準を採用すると、各ノードで 2 セットのバス ワイヤを 1 つの D コネクタに接続するためのカスタム スプリッタを作成する必要がなくなります。ノードの外部で導体を接続するこのような非標準 (カスタム) ワイヤ ハーネス (スプリッタ) は、バスの信頼性を低下させ、ケーブルの互換性をなくし、ワイヤ ハーネスの互換性を低下させ、コストを増加させます。

完全な物理層仕様（電気に加えて機械）が存在しなかったため、CANバス仕様は物理的な実装の制約と複雑さから解放されました。しかし、機械的な非互換性による相互運用性の問題はCANバスの実装に残されていました。相互運用性を改善するために、多くの自動車メーカーは、ラインの寄生容量の要件と組み合わせて、許容されるCANトランシーバーのセットを記述した仕様を作成しました。許容される寄生容量には、コンデンサとESD保護（ISO 7637-3に対するESD ^[17]）の両方が含まれます。寄生容量に加えて、12Vシステムと24Vシステムには、ラインの最大電圧に関する同じ要件がありません。実際、ジャンプスタートイベント中に、軽自動車のラインは24Vまで上昇する可能性がありますが、トラックシステムは36Vまで上昇する可能性があります。同じコンポーネントをCANとCAN FDに使用できるようにする新しいソリューションが登場しています（^[18]を参照）。

ISO 11898 -2:2003のノイズ耐性は、バスの両端に低抵抗 (120 オーム) を配置してバスの差動インピーダンスを低レベルに維持することで実現されます。ただし、休止状態のときは、CAN などの低インピーダンス バスは他の電圧ベースの信号バスよりも多くの電流 (および電力) を消費します。CAN バス システムでは、 1 つの信号ラインの電流が他の信号の反対方向の電流と正確にバランスするバランス ライン動作によって、受信機に独立した安定した 0 V リファレンスが提供されます。ベスト プラクティスでは、CAN バスのバランス ペア信号をシールド ケーブルのツイスト ペア ワイヤで伝送して、RF 放射を最小限に抑え、自動車のノイズの多い RF 環境での干渉感受性を低減することが求められます。

ISO 11898 -2 は、バスに沿って 0  V レールを走らせ、ノード間の電圧の関連性を高度に維持することで、送信機と受信機間のコモン モード電圧に対する耐性をある程度提供します。また、上記の事実上の機械的構成には、各トランシーバー ノードに電力を分配するための電源レールが含まれています。この設計では、すべてのトランシーバーに共通の電源が提供されます。バスによって適用される実際の電圧と、どのノードがそれを適用するかは、アプリケーション固有であり、正式には指定されていません。一般的なノード設計では、各ノードに、ノード ホストから光学的に分離されたトランシーバーが提供され、 バスによって提供されるユニバーサル電源レールから、トランシーバー用の 5 V の線形調整された電源電圧が供給されます。これにより、通常、電源レールの動作マージンが十分に確保され、多くのノード タイプ間で相互運用が可能になります。このようなネットワークの電源電圧の一般的な値は 7 ～ 30 V です。ただし、正式な標準がないため、システム設計者が電源レールの互換性について責任を負うことになります。

ISO 11898 -2 は、バスの両端に抵抗終端を備えたマルチドロップシングルエンドバランスライン構成から形成される電気的実装について説明しています。この構成では、1 つ以上のトランスミッタが CAN− を 0  V に切り替え、(同時に) CAN+ を +5  V バス電圧に切り替えることでドミナント状態がアサートされ、バスを終端する抵抗器を通る電流パスが形成されます。このように、終端抵抗器は信号システムの重要なコンポーネントを形成し、高周波での波の反射を制限するためだけでなく、他の目的でも含まれています。

リセッシブ状態の間、信号線と抵抗器は両方のレールに対して高インピーダンス状態のままです。CAN+ と CAN- の両方の電圧は、レール間の中間の電圧に（弱く）近づく傾向があります。バス上のトランスミッタのいずれもドミナント状態をアサートしていない場合にのみ、バス上でリセッシブ状態が存在します。

ドミナント状態では、信号線と抵抗器はレールに対して低インピーダンス状態に移行し、抵抗器に電流が流れます。CAN+ 電圧は +5  V に、CAN- は 0  V に近づきます。

信号の状態に関係なく、バスの端にある終端抵抗器のおかげで、信号線は互いに常に低インピーダンス状態にあります。

この信号方式は、差動ライン ドライバ/レシーバを採用し、概念上の 0 V と交差する平衡ラインの差動モード電圧に基づく信号方式を使用するRS-422 /3、RS-485などの他の平衡ライン 伝送技術とは大きく異なります。このようなシステムでの多重アクセスは、通常、3 つの状態 (アクティブ ハイ、アクティブ ロー、非アクティブ トライステート) をサポートするメディアに依存し、時間領域で処理されます。CAN バスでの多重アクセスは、概念的には「有線 AND」ネットワークに類似した 2 つの状態のみをサポートするシステムの電気ロジックによって実現されます。

CAN ネットワークは、標準またはベース フレーム形式 (CAN 2.0 A および CAN 2.0 B で説明) と拡張フレーム形式 (CAN 2.0 B でのみ説明) の 2 つの異なるメッセージ (またはフレーム) 形式で動作するように構成できます。2 つの形式の唯一の違いは、 CAN ベース フレームが11 ビットの長さの識別子をサポートし、CAN 拡張フレームが29 ビットの長さの識別子 (11 ビットの識別子 (ベース識別子) と 18 ビットの拡張 (識別子拡張) で構成される) をサポートしていることです。CAN ベース フレーム形式と CAN 拡張フレーム形式の区別は、IDE ビットを使用して行われます。IDE ビットは、11 ビット フレームの場合はドミナントとして送信され、29 ビット フレームの場合はリセッシブとして送信されます。拡張フレーム形式のメッセージをサポートする CAN コントローラは、CAN ベース フレーム形式でメッセージを送受信することもできます。すべてのフレームは、フレーム送信の開始を示すフレーム開始 (SOF) ビットで始まります。

CAN には 4 つのフレーム タイプがあります。

• データフレーム: 送信用のノードデータを含むフレーム
• リモートフレーム: 特定の識別子の送信を要求するフレーム
• エラーフレーム: エラーを検出したノードによって送信されるフレーム
• オーバーロードフレーム: データまたはリモートフレームの間に遅延を挿入するフレーム

データ フレームは、実際のデータ送信のための唯一のフレームです。メッセージ形式には次の 2 つがあります。

• 基本フレームフォーマット: 11 個の識別子ビット付き
• 拡張フレームフォーマット: 29 個の識別子ビット付き

CAN 標準では、実装は基本フレーム形式を受け入れる必要があり、拡張フレーム形式を受け入れる可能性がありますが、拡張フレーム形式を許容する必要があります。

フレーム形式は次のとおりです。CAN-LO 信号のビット値が記述されます。

フレームのフォーマットは以下の表のとおりです。

2 つの識別子フィールド (A と B) が結合して 29 ビットの識別子を形成します。

• 通常、データ送信は、データ ソース ノード (センサーなど) がデータ フレームを送信することで自律的に実行されます。ただし、宛先ノードがリモート フレームを送信してソースにデータを要求することも可能です。
• データ フレームとリモート フレームには 2 つの違いがあります。まず、RTR ビットはデータ フレームの主要ビットとして送信され、次にリモート フレームにはデータ フィールドがありません。DLC フィールドは、要求されたメッセージのデータ長を示します (送信されたメッセージではありません)。
  つまり、

RTR = 0 ; データフレームでは DOMINANT

RTR = 1 ; リモートフレームではRECESSIVE

同じ識別子を持つデータ フレームとリモート フレームが同時に送信された場合、識別子に続く優勢な RTR ビットにより、データ フレームが調停に勝ちます。

エラー フレームは 2 つの異なるフィールドで構成されます。

• 最初のフィールドは、異なるステーションから提供されたエラー フラグ (6 ～ 12 個の優性/劣性ビット) の重ね合わせによって提供されます。
• 次の 2 番目のフィールドは、ERROR DELIMITER (8 つのリセッシブ ビット) です。

エラー フラグには 2 つの種類があります。

アクティブエラーフラグ

6 つのドミナント ビット – エラー状態(エラー アクティブ)にあるネットワーク上のエラーを検出したノードによって送信されます。

パッシブエラーフラグ

6 つのリセッシブ ビット - エラー状態(エラー パッシブ)にあるネットワーク上のアクティブ エラー フレームを検出するノードによって送信されます。

CAN には 2 つのエラー カウンターがあります。

1. 送信エラーカウンタ（TEC）
2. 受信エラーカウンタ（REC）

• TEC または REC が 127 より大きく 255 より小さい場合、パッシブ エラー フレームがバス上で送信されます。
• TEC と REC が 128 未満の場合、アクティブ エラー フレームがバス上で送信されます。
• TEC が 255 より大きい場合、ノードはバス オフ状態になり、フレームは送信されません。

オーバーロード フレームには、オーバーロード フラグとオーバーロード デリミタの 2 つのビット フィールドが含まれています。オーバーロード フラグの送信につながるオーバーロード状態には、次の 2 種類があります。

1. 次のデータ フレームまたはリモート フレームの遅延を必要とする受信機の内部条件。
2. 中断中のドミナントビットの検出。

ケース 1 によるオーバーロード フレームの開始は、予想されるインターミッションの最初のビット時間でのみ開始できますが、ケース 2 によるオーバーロード フレームは、ドミナント ビットを検出してから 1 ビット後に開始されます。オーバーロード フラグは、6 つのドミナント ビットで構成されます。全体的な形式は、アクティブ エラー フラグの形式に対応します。オーバーロード フラグの形式は、インターミッション フィールドの固定形式を破壊します。その結果、他のすべてのステーションもオーバーロード状態を検出し、オーバーロード フラグの送信を開始します。オーバーロード デリミタは、8 つのリセッシブ ビットで構成されます。オーバーロード デリミタは、エラー デリミタと同じ形式です。

確認応答スロットは、有効な CAN フレームの受信を確認するために使用されます。フレームを受信した各ノードは、エラーが見つからなければ、ACK スロットでドミナント レベルを送信し、送信機のリセッシブ レベルを上書きします。送信機が ACK スロットでリセッシブ レベルを検出すると、有効なフレームが見つかった受信機がなかったことが分かります。受信ノードは、有効なフレームを受信しなかったことを示すためにリセッシブを送信することがありますが、有効なフレームを受信した別のノードは、ドミナントでこれを上書きすることがあります。送信ノードは、メッセージが CAN ネットワーク上のすべてのノードによって受信されたことを知ることはできません。

多くの場合、デバイスの動作モードは、確認応答のないフレームを何度も再送信することです。これにより、最終的にエラーパッシブ状態になる可能性があります。

データフレームとリモートフレームは、インターフレームスペースと呼ばれるビットフィールドによって前のフレームから区切られます。インターフレームスペースは、少なくとも3つの連続するリセッシブ（1）ビットで構成されます。その後、ドミナントビットが検出されると、次のフレームのフレーム開始ビットと見なされます。オーバーロードフレームとエラーフレームの前にはインターフレームスペースはなく、複数のオーバーロードフレームはインターフレームスペースで区切られません。インターフレームスペースには、前のメッセージを送信していたエラーパッシブステーションのインターミッションとバスアイドル、および送信一時停止のビットフィールドが含まれます。^[19]

同期を維持するために十分な遷移を保証するために、同じ極性の 5 つの連続ビットの後に反対極性のビットが挿入されます。この方法はビット スタッフィングと呼ばれ、CAN で使用される非ゼロ復帰(NRZ) コーディングのために必要です。スタッフィングされたデータ フレームは、受信機によってデスタッフィングされます。

フレーム内のすべてのフィールドは、CRC デリミタ、ACK フィールド、および固定サイズで詰め込まれないフレームの終了を除いて詰め込まれます。ビット詰め込みが使用されるフィールドでは、同じ極性の連続する 6 つのビット (111111 または 000000) はエラーと見なされます。エラーが検出されると、ノードによってアクティブ エラー フラグが送信されることがあります。アクティブ エラー フラグは、連続する 6 つのドミナント ビットで構成され、ビット詰め込みのルールに違反します。

ビットスタッフィングとは、データフレームが、上記の表に示されているビットを単純に列挙するだけでは予測できないほど大きくなる可能性があることを意味します。ビットスタッフィング後のCANフレーム（基本フォーマット）のサイズの最大増加は、次の場合です。

11111000011110000...

これは次のように詰め込まれます (詰め込み部分は太字で表示)。

11111 0 0000 1 1111 0 0000 1 ...

スタッフィング ビット自体は、連続する 5 つの同一ビットの最初のビットである可能性があるため、最悪の場合、元のビット 4 つにつきスタッフィング ビットが 1 つ存在します。

ベースフレームのサイズは

${\displaystyle 8n+44+\left\lfloor {\frac {34+8n-1}{4}}\right\rfloor }$

ここで、n はデータ バイト数で、最大 8 です。

は詰め込み前のフレームのサイズなので、最悪の場合、最初のビットの後に元の 4 ビットごとに 1 ビットが追加されます (したがって、分子に -1 があります)。また、ヘッダーのビットのレイアウトのため、44 ビットのうち 34 ビットのみがビット詰め込みの対象になります。 ${\displaystyle 8n+44}$

ビット スタッフィング方式の望ましくない副作用は、受信メッセージ内の少数のビット エラーによってデスタッフィング プロセスが破損し、デスタッフィングされたメッセージを通じて多数のエラーが伝播する可能性があることです。これにより、本来は CRC によって元のエラーに対して提供される保護レベルが低下します。このプロトコルの欠陥は、CAN FD フレームで、固定スタッフ ビットと挿入されたスタッフ ビットの数を記録するカウンターの組み合わせを使用することで解決されています。

ISO 11898シリーズは、道路車両内での使用のための分散リアルタイム制御と多重化をサポートするコントローラエリアネットワークと呼ばれるシリアル通信カテゴリの物理層とデータリンク層（ISO / OSIモデルのレベル1と2）を規定しています。^[20]

CAN物理層およびその他の標準 にはいくつかあります。

ISO 11898-1:2015は、コントローラエリアネットワーク（CAN）のデータリンク層（DLL）と物理シグナリングを規定しています。 ^{[13]この文書は}、ISO/IEC 7498-1で確立されたオープンシステム相互接続（OSI）のISO参照モデルに従って、階層層の観点からCANの一般的なアーキテクチャを説明し、論理リンク制御（LLC）サブレイヤーとメディアアクセス制御（MAC）サブレイヤーの詳細な仕様とともに、CAN DLLを実装するモジュール間でデジタル情報の交換を設定するための特性を提供します。

ISO 11898-2:2016 は 、コントローラ エリア ネットワークの物理層を構成する高速 (最大 1 Mbit/s の伝送速度) のメディア アクセス ユニット (MAU) と一部のメディア依存インターフェイス (MDI) 機能 (ISO 8802-3 に準拠) を規定しています。ISO 11898-2 は、2 線式バランス信号方式を使用します。これは、車両のパワートレインアプリケーションや産業用制御ネットワーク で最もよく使用される物理層です。

ISO 11898-3:2006 は、  40 kbit/s 超から 125 kbit/s までの伝送速度で CAN を搭載した道路車両の電子制御ユニット間でデジタル情報の交換を設定するための、低速でフォールト トレラントな媒体依存インターフェイスを規定しています 。

ISO 11898-4:2004 は、 CAN におけるタイム トリガー通信 (TTCAN) を規定しています。これは、CAN を搭載した道路車両の電子制御ユニット (ECU) 間でデジタル情報をタイム トリガーで交換するための設定に適用され、ISO 11898-1 に従って論理リンクとメディア アクセス制御の両方の動作を調整し、タイム トリガー通信スケジュールを提供するフレーム同期エンティティを規定しています。

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:2016 は、 ISO 11898-1 で規定されている CAN のあらゆる CAN 実装の適合性をチェックするために必要な方法論と抽象テスト スイートを提供します。

ISO 16845-2:2018は、選択的ウェイクアップ機能が実装された CAN トランシーバーが指定された機能に準拠しているかどうかを検証するテスト プランを実現するためのテスト ケースとテスト要件を確立します。ISO 16845-2:2018 で定義されているテストの種類は、適合性テストと呼ばれます。

CAN DBC ファイルは、CAN バス経由で送信されるメッセージを定義するために使用される標準化された ASCII ファイルです。メッセージ ID、信号名、スケーリング、オフセット、データ タイプなど、各タイプのメッセージの形式と目的を定義し、CAN バス アプリケーションの開発に相互運用可能な支援を提供します。

CAN 規格には、フロー制御、デバイス アドレス指定、1 つのメッセージより大きいデータ ブロック、特にアプリケーション データの転送などの一般的な通信機能が含まれていないため、上位層プロトコルの実装が多数作成されました。いくつかはビジネス領域用に標準化されていますが、すべて各メーカーによって拡張できます。乗用車の場合、各メーカーが独自の規格を持っています。

CAN in Automation (CiA)は、CANベースの上位層プロトコルとその国際標準化を開発およびサポートする国際的なユーザーおよびメーカーの組織です。^[12]これらの仕様には次のものがあります。

• ARINC 812 または ARINC 825 (航空業界)
• CANopen - CiA 301/302-2 および EN 50325-4 (産業オートメーション)
• IEC 61375 -3-3 (鉄道車両における CANopen の使用)
• DeviceNet (産業オートメーション)
• EnergyBus - CiA 454 およびIEC 61851 -3 (バッテリーと充電器間の通信)
• ISOBUS - ISO 11783 (農業)
• ISO-TP - ISO 15765-2 (自動車診断用のトランスポート プロトコル)
• MilCAN（軍用車両）
• NMEA 2000 - IEC 61162-3 (海洋産業)
• SAE J1939（バスおよびトラック用車載ネットワーク）
• SAE J2284（乗用車用車載ネットワーク）
• 統合診断サービス(UDS) - ISO 14229 (自動車診断)
• LeisureCAN - レジャークラフト/車両業界向けオープンスタンダード

• CANaerospace - 株式（航空業界向け）
• CAN Kingdom - Kvaser（組み込み制御システム）
• CCP/ XCP（自動車ECUキャリブレーション）
• GMLAN - General Motors (ゼネラルモーターズ向け)
• RV-C - RVIA（レクリエーション用車両に使用）
• SafetyBUS p - Pilz（産業オートメーションに使用）
• UAVCAN（航空宇宙およびロボット工学）
• CSP (キューブサット宇宙プロトコル)
• VSCP (Very Simple Control Protocol) は、あらゆる種類の自動化タスクに適した無料の自動化プロトコルです。

2001 年に設立された CANopen Special Interest Group (SIG)「Lift Control」は、エレベーター制御システム用の CANopen アプリケーション プロファイル CiA 417 を開発しています。機能の拡張、技術内容の改善に取り組んでおり、エレベーター制御システムの現在の法的基準が満たされていることを保証します。CiA 417 の最初のバージョンは 2003 年夏に公開され (CiA メンバーが利用可能)、バージョン 2.0 は 2010 年 2 月、バージョン 2.1.0 は 2012 年 7 月、バージョン 2.2.0 は 2015 年 12 月、バージョン 2.3.1 は 2020 年 2 月に公開されました。

Jörg Hellmich (ELFIN GmbH) はこの SIG の議長であり、CANopen リフトに関するコンテンツを含む CANopen リフト コミュニティの wiki を管理しています。

CANは低レベルのプロトコルであり、本質的にセキュリティ機能をサポートしていません。また、標準のCAN実装には暗号化がないため、これらのネットワークは中間者によるフレーム傍受に対して無防備です。ほとんどの実装では、アプリケーションが独自のセキュリティメカニズムを展開することが期待されています。たとえば、着信コマンドの認証やネットワーク上の特定のデバイスの存在などです。適切なセキュリティ対策を実装しないと、相手がバスにメッセージを挿入した場合にさまざまな種類の攻撃が発生する可能性があります。 ^[21]ファームウェアの変更、キーのプログラミング、アンチロックブレーキアクチュエータの制御など、一部の安全性が重要な機能にはパスワードが存在しますが、これらのシステムは普遍的に実装されておらず、シード/キーのペアの数は限られています。

CAN バスの開発やトラブルシューティングを行う際、ハードウェア信号の検査は非常に重要です。ロジック アナライザとバス アナライザは、信号を収集、分析、デコード、保存して、高速波形を自由に表示できるツールです。CAN バス モニターだけでなく、専門ツールもあります。

あCAN バス モニターは、CAN バスを使用するハードウェアの開発中に使用される 分析ツールであり、多くの場合、ハードウェアとソフトウェアの組み合わせです

通常、CAN バス モニターは、CAN バス上のトラフィックを監視して、それをユーザー インターフェイスに表示します。多くの場合、CAN バス モニターは、CAN フレームをバスに送信することで、CAN バスのアクティビティをシミュレートする機能を提供します。したがって、CAN バス モニターは、特定のデバイスからの予想される CAN トラフィックを検証したり、CAN バスに接続された特定のデバイスからの反応を検証するために CAN トラフィックをシミュレートしたりするために使用できます。

ボッシュはこの技術の特許を保有しているが、元のプロトコルに関連する特許は既に期限切れとなっている。CAN互換マイクロプロセッサの製造業者は、CAN商標およびCAN FDに関連する新しい特許の使用に対してボッシュにライセンス料を支払っており、これは通常、チップの価格に含めて顧客に転嫁される。CAN互換モジュールを含むカスタムASICまたはFPGAを搭載した製品のメーカーは、CAN商標またはCAN FD機能を使用する場合、CANプロトコルライセンス料を支払う必要がある。^[22]

• CANopen  – コンピュータネットワークプロトコル
• 自動車用EtherLoop  – 通信ハイブリッド技術Pages displaying short descriptions of redirect targets
• FlexRay  – コンピュータネットワークプロトコル
• ネットワークバスのリスト – 単一衝突ドメイン電子通信バスシステムのリスト
• Modbus  – シリアル通信プロトコル
• MOSTバス – 自動車業界で使用される高速マルチメディアネットワーク技術Pages displaying short descriptions of redirect targets

仕様

• ISO 11898-1 規格 (2015) - CAN および CAN-FD 仕様を含む
• Bosch CAN 仕様バージョン 2.0 (1991、1997) -クラシック CANおよびCAN-Classicとも呼ばれる
•  Bosch CAN-FD仕様バージョン1.0（2012） - データレートを最大8 Mbit/sに向上
• Bosch CAN-FD-Light (将来) - コスト最適化された CAN-FD のサブセット
•  Bosch CAN-XL (将来) - データレートを最大 20 Mbit/sまで向上

他の

• コントローラ エリア ネットワーク (CAN) のスケジュール可能性分析: 反論、再検討、修正
• 一般的なCANバスコネクタのピン配置
• 自動車におけるCANに関するウェブページ
• FIFO キューを使用したコントローラ エリア ネットワーク (CAN) のスケジュール可能性分析
• コントローラ エリア ネットワーク (CAN) 実装ガイド 2012-12-10 にWayback Machineでアーカイブされました
• Windows 用のフリーウェア ビットタイミング計算機。Atmel、STM32、Microchip、Renesas など、多くのマイクロコントローラをサポートしています (ZIP ファイル)
• 無料の e ラーニング モジュール「CAN 入門」
• Excalibur Systems Inc. の ARINC-825 チュートリアル (ビデオ)
• CiAのウェブサイト
• CANニュースレターオンライン
• カリフォルニア大学バークレー校のコントローラ エリア ネットワークの理解と使用
• CAN プロトコル チュートリアル
• CANバスおよびCAN FDのESD保護