Controller Area Network
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信号のビット値が記述されている。
拡張フレームフォーマットは以下の通りである。
2つの識別子フィールドは、結合して29ビットの識別子を形成する。
CAN標準フレームとの違いは、r0ビットがFDFビットに変更され、その直後にres、BRS、ESIビットが追加されている。また、高ビットレート化やデータ長変更に伴う信頼性確保のため、CRCフィールドの直前にスタッフカウントが追加され、CRCの長さが変更されている。
CAN FD標準フレームフォーマットは以下の通りである。
CAN拡張フレームとの違いは、r1,r0ビットがFDFビットに変更され、その直後にres、BRS、ESIビットが追加されている。また、高ビットレート化やデータ長変更に伴う信頼性確保のため、CRCフィールドの直前にスタッフカウントが追加され、CRCの長さが変更されている。
CAN FD拡張フレームフォーマットは以下の通りである。
一般に、データ送信は、データフレームを送信するデータ送信元ノード(例えば、センサ)との自律的な基準で実行される。しかし、宛先ノードが遠隔フレームを送信することによってソースからデータを要求することも可能である。
データフレームとリモートフレームには2つの違いがある。第一に、データフレームではRTRビットがドミナント(0)であったのに対し、リモートフレームではリセッシブ(1)となる。第二に、リモートフレームにはデータフィールドが存在しない。DLCフィールドは、要求されたメッセージ(送信されたものではない)のデータ長を示す。
同じ識別子を持つデータフレームとリモートフレームが同時に送信された場合、識別子に続くRTRビットがドミナント(0)であるデータフレームの方がアービトレーションを獲得する。
エラーフレームは、2つのフィールドから構成されている。
最初のフィールドは、異なるノードからのエラーフラグ(6-12ビットのドミナント/リセッシブビット)の重ね合わせによって与えられる。
第二のフィールドは、エラーデリミタ(8ビットのリセッシブビット)である。
エラーフラグには2種類ある。
アクティブエラーフラグ:  6ビットのドミナントビット。エラー状態「エラーアクティブ」にあるネットワーク上のエラーを検出したノードによって送信される。
パッシブエラーフラグ:  6ビットのリセッシブビット。エラー状態「エラーパッシブ」にあるネットワーク上のアクティブなエラーフレームを検出するノードによって送信される。
オーバーロードフレームには、2つのビットフィールド・オーバーロードフラグとオーバーロードデリミタが含まれる。オーバーロードフラグには、次の2種類がある。
受信機の内部状態。次のデータフレームまたはリモートフレームの遅延を要求する。
中断中のドミナントビットの検出。
ケース1によるオーバーロードフレームの開始は、予期される休止の最初のビット時間でのみ開始することが可能であるが、ケース2によるオーバーロードフレームは、ドミナントビットを検出した後に1ビットを開始する。オーバーロードフラグは6ビットのドミナントビットで構成される。全体的なフォームは、アクティブエラーフラグの形式に対応する。オーバーロードフラグの形式は、固定形式の断続フィールドを破棄する。結果として、他のすべてのノードも過負荷状態を検出し、即座にオーバーロードフラグの送信を開始する。オーバーロードデリミタは8ビットのリセッシブビットから構成される。オーバーロードデリミタは、エラーデリミタと同じ形式である。
肯定応答(ACK)スロットは、有効なCANフレームの受信を確認するために使用される。エラーを検出することなくフレームを受信した各ノードは、ACKスロット内でドミナントビットを送信する。従って、送信機のリセッシブレベルを無効にする。送信機がACKスロット内のリセッシブレベルを検出すると、受信機が有効なフレームを発見しなかったことがわかる。受信ノードは、有効なフレームを受信しなかったことを示すためにリセッシブを送信することができるが、有効なフレームを受信した別のノードは、これをドミナントに置き換えることができる。送信ノードは、メッセージがCANネットワーク上の全てのノードによって受信されたかどうかを知ることができない。
データフレームとリモートフレームは、フレーム間スペースと呼ばれるビットフィールドによって先行するフレームから分離される。フレーム間スペースは、少なくとも3つの連続するレセッシブ(1)ビットからなる。その後、ドミナントビットが検出されると、それは次のフレームのフレーム開始(SOF)ビットと見なされる。オーバーロードフレームとエラーフレームの前はにフレーム間スペースがなく、複数のオーバーロードフレームはフレーム間スペースで区切られていない。フレーム間スペースは、ビットフィールドの休止およびバスアイドルを含み、前のメッセージの送信機であったエラーパッシブステーションのための送信を一時停止する。
同期を維持するのに十分な遷移を保証するために、同じ極性のビットが5つ連続したら逆の極性のビット(スタッフビット)が挿入される。この方法はビットスタッフィングと呼ばれ、CANで使用されるnon-return-to-zero(NRZ)符号で同期をとるために必要である。データフレームに挿入されたスタッフビットは、受信機によって取り除かれる(デスタッフされる)。
フレーム内の全てのフィールドはビットスタッフィングの対象となる。ただし、CRCデリミタ、ACKフィールド、フレーム終了は固定長であり、ビットスタッフィングの対象外である。ビットスタッフィングが使用されるフィールドでは、同じタイプの6つの連続ビット(111111または000000)はエラーと見なされる。アクティブエラーフラグは、エラーを検出したノードによって送信され、6つの連続するドミナントビットを送信することで、他のノードに強制的にビットスタッフィングエラーを起こさせる。
ビットスタッフィングがあるため、上記の表に示すビットの合計よりも、実際のデータフレームが大きくなる可能性がある。
ISO 11898シリーズは、自動車内で使用する分散リアルタイム制御や多重化をサポートするCANと呼ばれるシリアル通信技術の物理層・データリンク層(OSI参照モデルの第1層・第2層)を規定している。
いくつかのCAN物理層およびその他の標準がある。
ISO 11898-1:2015は、CANのデータリンク層(DLL)と物理的な信号伝達を規定している。この文書は、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標準には、フロー制御、デバイスアドレッシング、1つのメッセージよりも大きなデータブロックの転送、アプリケーションデータのようなアプリケーション層プロトコルのタスクは含まれていないため、上位層プロトコルの多くの実装が作成された。その内のいくつかはビジネスエリアで標準化されているが、各メーカーがそれを拡張している。乗用車の場合、各メーカーに独自の標準がある。これらの実装には以下のものがある。
ARINC 812, ARINC 825(航空業界向け)
CANopen - EN 50325-4(産業オートメーションに使用)
DeviceNet(産業オートメーションに使用)
EnergyBus - CiA 454(軽電気自動車用)
ISOBUS - ISO 11783(農業用)
ISO-TP - ISO 15765-2(自動車診断用トランスポート層プロトコル)
SAE J1939(バス・トラック用車載ネットワーク)
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実装には暗号化もなく、これらのネットワークは中間者攻撃に対してオープンである。ほとんどの実装では、アプリケーションは独自のセキュリティメカニズムを導入することが期待されている。例えば、入ってくるコマンドやネットワーク上の特定のデバイスの存在を認証するなど。十分なセキュリティ対策を講じないと、相手がバスにメッセージを送信した場合、さまざまな種類の攻撃が発生する可能性がある。ファームウェアの変更、キーのプログラミング、アンチロックブレーキアクチュエータの制御など、いくつかの安全上重要な機能のためのパスワードが存在するが、これらのシステムは普遍的に実装されておらず、限られた数のシード/キーペアを持っている。
実際にエンジン始動に特化したCANデバイスを接続し、短時間で自動車を窃盗する事例が発生している。
CANバスの開発やトラブルシューティングを行う際には、ハードウェア信号の検査が非常に重要である。ロジックアナライザやプロトコル・アナライザは、信号を収集、分析、デコード、保存するツールで、高速波形を見ることができる。また、CANバスモニターなどの特殊ツールもある。
CANバスモニタは、CANバスを使用するハードウェアの開発中に使用される分析ツールで、多くはハードウェアとソフトウェアの組み合わせである。
通常、CANバスモニタはCANバス上のトラフィックを傍受し、ユーザインターフェイスに表示する。多くの場合、CANバスモニタはCANフレームをバスに送信することによってCANバスの動作をシミュレートすることもできる。そのため、CANバスモニタは、CANバスに接続された特定のデバイスからの反応を検証するために、特定のデバイスから予想されるCANトラフィックを検証したり、CANトラフィックをシミュレートするために使用できる。
ボッシュ社はこの技術に関する特許を保有している。CAN互換マイクロプロセッサの製造元はボッシュ社にライセンス料を支払っており、通常、それはチップの価格として顧客に転嫁される。カスタムASICやCAN互換モジュールを搭載したFPGAを使用している製品の製造業者は、CANプロトコルライセンス料を支払う必要がある。