Controller Area Network
Controller Area Network (CAN) は、ビークルバス規格の一種で、ホストコンピュータなしでマイクロコントローラやデバイスが相互に通信できるように設計されている。耐ノイズ性の強化が考慮された堅牢な規格である。メッセージベースのプロトコルであり、元々は、自動車内部の多重化電気配線用に設計されたものだが、機器の制御情報の転送用として普及しており、輸送用機械、工場、工作機械などのロボット分野においても利用されている。自動車においては、速度、エンジンの回転数、ブレーキの状態、故障診断の情報などの転送に使用されている。
データ転送速度は、40mの通信路においては最高で1Mbps程度、500mの通信路においては最高で125kbps程度。実際の運用においては、速いもので500kbps、遅いもので83.3kbpsとなっている。通信速度が上がるほど接続できる機器の数が減るので、高級車などでは速度の異なる複数の通信路をもつのが一般的である。
なお、デジタルコンテンツなど大量データの転送には、MOSTまたはIDB-1394が用いられることが多い。パワーウィンドウなど転送速度をそれほど要求されないシステムにおいては、Local Interconnect Network (LIN) と呼ばれるネットワーク通信を用いるのが一般的となっている。また、エアバッグやシートベルトなどの乗員保護装置には、低速で信頼性を高めたSafe-by-Wireという規格が策定されている。しかし、CANを使用しているシステムもあり、現時点ではまだはっきりとした使い分けはない。
歴史
CANの開発は、1983年にドイツのボッシュ社で開始された。このプロトコルは、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と呼ばれる。これらの規格は、ボッシュ社から他の仕様やホワイトペーパーとともに自由に入手できる。
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パッシブ用のものに変更する必要がある。
CANは、自動車の自己診断機能の標準であるOBD2で使用される5つのプロトコルのうちの1つである。OBD2規格は、1996年以降、米国で販売される全て自動車・軽トラックに必須であり、OBD2と等価のEOBD規格は、2001年以降の欧州連合で販売される全てのガソリン車および2004年以降の全てのディーゼル車に対して義務付けられている。
ID割り当て
メッセージIDは、1つのCANバス上で一意でなければならない。そうしないと、2つのノードがアービトレーションフィールド（ID）の終わりを超えて送信を続け、エラーを引き起こす。
1990年代初めには、メッセージIDの選択は、データのタイプと送信ノードの識別に基づいて単純に行われていた。しかし、IDがメッセージ優先度としても使用されるため、リアルタイムのパフォーマンスが低下する。これらのシナリオでは、全てのメッセージが期限を過ぎないようにするために、CANバス使用率を通常30%と低くする必要があった。しかし、メッセージのデッドラインに基づいてIDが決定され、数値IDが低くメッセージの優先度が高い場合には、通常、メッセージのデッドラインを逃してしまう前に70〜80%のバス使用率を達成することができる。
ビットタイミング
CANネットワーク上の全てのノードは、同じ公称ビットレートで動作する必要があるが、ノイズ、位相シフト、オシレータ公差、オシレータドリフトなどにより、実際のビットレートが公称ビットレートと同じでない可能性がある。別のクロック信号が使用されないので、ノードを同期させる手段が必要である。アービトレーション中のノードは、自身の送信データと他のノードの送信データの両方を同時に観測することができなければならないため、アービトレーション中には同期が重要である。同期は、ノード間の発振器タイミングの変動によってエラーが発生しないようにするためにも重要である。
同期は、バスアイドル期間（開始ビット）の後、最初のリセッシブからドミナントへの遷移時のハード同期から開始される。再同期は、フレーム中の全てのリセッシブからドミナントへの遷移時に行われる。CANコントローラは、公称ビット時間の倍数で遷移が発生することを期待している。コントローラが期待する正確な時間に遷移が発生しない場合、コントローラはそれに応じて公称ビット時間を調整する。
調整は、各ビットをクアンタ（quanta、量子）と呼ばれる複数のタイムスライスに分割し、ビット内の4つのセグメント（同期、伝播、位相セグメント1、位相セグメント2）のそれぞれにいくつかのクアンタを割り当てることによって達成される。
ビットによって分けられるクアンタの数は、コントローラによって変えることができ、各セグメントに割り当てられるクアンタの数は、ビットレートおよびネットワーク状態に応じて変えることができる。
コントローラが期待するよりも前後に遷移が起こった場合、コントローラが時間差を計算し、この時間までに位相セグメント1を長くするか、位相セグメント2を短くする。これにより、受信機と送信機のタイミングを効果的に調整して同期させることができる。この再同期プロセスは、送信機と受信機が同期していることを確実にするために、全てのリセッシブからドミナントへの遷移において連続的に行われる。継続的な再同期化は、ノイズによって引き起こされるエラーを低減し、アービトレーションを失ったノードに同期された受信ノードが、アービトレーションを獲得したノードと再同期することを可能にする。
データフレーム
データフレームは、実際のデータを伝送するために使われる唯一のフレームである。これには、2つの形式がある。
標準フレームフォーマット: 識別子が11ビット
拡張フレームフォーマット: 識別子が29ビット
CAN標準では、標準フレームフォーマットは必ず受け入れなければならず、拡張フレームフォーマットは受け入れなくても良いが、それに耐えなければならない。
ACKスロット
肯定応答(ACK)スロットは、有効なCANフレームの受信を確認するために使用される。エラーを検出することなくフレームを受信した各ノードは、ACKスロット内でドミナントビットを送信する。従って、送信機のリセッシブレベルを無効にする。送信機がACKスロット内のリセッシブレベルを検出すると、受信機が有効なフレームを発見しなかったことがわかる。受信ノードは、有効なフレームを受信しなかったことを示すためにリセッシブを送信することができるが、有効なフレームを受信した別のノードは、これをドミナントに置き換えることができる。送信ノードは、メッセージがCANネットワーク上の全てのノードによって受信されたかどうかを知ることができない。
フレーム間スペース
データフレームとリモートフレームは、フレーム間スペースと呼ばれるビットフィールドによって先行するフレームから分離される。フレーム間スペースは、少なくとも3つの連続するレセッシブ(1)ビットからなる。その後、ドミナントビットが検出されると、それは次のフレームのフレーム開始(SOF)ビットと見なされる。オーバーロードフレームとエラーフレームの前はにフレーム間スペースがなく、複数のオーバーロードフレームはフレーム間スペースで区切られていない。フレーム間スペースは、ビットフィールドの休止およびバスアイドルを含み、前のメッセージの送信機であったエラーパッシブステーションのための送信を一時停止する。
ビットスタッフィング
同期を維持するのに十分な遷移を保証するために、同じ極性のビットが5つ連続したら逆の極性のビット（スタッフビット）が挿入される。この方法はビットスタッフィングと呼ばれ、CANで使用されるnon-return-to-zero(NRZ)符号で同期をとるために必要である。データフレームに挿入されたスタッフビットは、受信機によって取り除かれる（デスタッフされる）。
フレーム内の全てのフィールドはビットスタッフィングの対象となる。ただし、CRCデリミタ、ACKフィールド、フレーム終了は固定長であり、ビットスタッフィングの対象外である。ビットスタッフィングが使用されるフィールドでは、同じタイプの6つの連続ビット（111111または000000）はエラーと見なされる。アクティブエラーフラグは、エラーを検出したノードによって送信され、6つの連続するドミナントビットを送信することで、他のノードに強制的にビットスタッフィングエラーを起こさせる。
ビットスタッフィングがあるため、上記の表に示すビットの合計よりも、実際のデータフレームが大きくなる可能性がある。
CAN下位層標準
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ベースの上位層プロトコル
CAN標準には、フロー制御、デバイスアドレッシング、1つのメッセージよりも大きなデータブロックの転送、アプリケーションデータのようなアプリケーション層プロトコルのタスクは含まれていないため、上位層プロトコルの多くの実装が作成された。その内のいくつかはビジネスエリアで標準化されているが、各メーカーがそれを拡張している。乗用車の場合、各メーカーに独自の標準がある。これらの実装には以下のものがある。
セキュリティ
CANは低レベルのプロトコルであり、本質的にセキュリティ機能をサポートしていない。標準のCAN実装には暗号化もなく、これらのネットワークは中間者攻撃に対してオープンである。ほとんどの実装では、アプリケーションは独自のセキュリティメカニズムを導入することが期待されている。例えば、入ってくるコマンドやネットワーク上の特定のデバイスの存在を認証するなど。十分なセキュリティ対策を講じないと、相手がバスにメッセージを送信した場合、さまざまな種類の攻撃が発生する可能性がある。ファームウェアの変更、キーのプログラミング、アンチロックブレーキアクチュエータの制御など、いくつかの安全上重要な機能のためのパスワードが存在するが、これらのシステムは普遍的に実装されておらず、限られた数のシード/キーペアを持っている。
開発ツール
CANバスの開発やトラブルシューティングを行う際には、ハードウェア信号の検査が非常に重要である。ロジックアナライザやプロトコル・アナライザは、信号を収集、分析、デコード、保存するツールで、高速波形を見ることができる。また、CANバスモニターなどの特殊ツールもある。
CANバスモニタは、CANバスを使用するハードウェアの開発中に使用される分析ツールで、多くはハードウェアとソフトウェアの組み合わせである。
通常、CANバスモニタはCANバス上のトラフィックを傍受し、ユーザインターフェイスに表示する。多くの場合、CANバスモニタはCANフレームをバスに送信することによってCANバスの動作をシミュレートすることもできる。そのため、CANバスモニタは、CANバスに接続された特定のデバイスからの反応を検証するために、特定のデバイスから予想されるCANトラフィックを検証したり、CANトラフィックをシミュレートするために使用できる。
ライセンス
ボッシュ社はこの技術に関する特許を保有している。CAN互換マイクロプロセッサの製造元はボッシュ社にライセンス料を支払っており、通常、それはチップの価格として顧客に転嫁される。カスタムASICやCAN互換モジュールを搭載したFPGAを使用している製品の製造業者は、CANプロトコルライセンス料を支払う必要がある。