下記の博士のノートからのスピンオフです。

CANは車でよく使われる通信方式です。

ボッシュが規格を策定しました。

車内LANといった場合、十中八九CANのこと指します。
（LANと言ってもLANケーブルや無線LANが使えるわけではありません）

現代の車には欠かせない通信規格です。

【通信が何故必要なのか？】

自動車のECUはどんどん数を増やし、多い車では100個以上にもなります。

ECUに繋がるセンサー類をそれぞれのECUで個別に繋ぐとワイヤーハーネスやそれらを繋ぐコネクター類は膨大になり、ECUのサイズの増加ワイヤーハーネスの重量増に繋がります。
ワイヤーハーネスは銅線で出来ているため、全て直線（じかせん）だと100kgにも及びます。

個別に繋ぐと、それぞれのECUで同じような処理を実装しなくてはならず、CPUパワーの浪費に繋がりますが、役割分担をすることが出来るようになります。

例えば、車速センサーは最近だと車輪ごとにセンサーが付いていて、車速は車輪ごとのセンサーから算出されます。

シャシダイに載せられて駆動輪しか回っていない時や一輪だけスペアタイヤを履いていて車輪ごとの車速が違う時、カーブを曲がっている時やグリップを失って滑っている時など車速を扱うには複雑な条件を演算しなければなりません。

このような計算は車輪ごとに速度を計算するABS（もしくはVSC）-ECUが行い、ブレーキの制御に利用しますが、一方エンジンでも車速リミッターなど車速を扱う必要があります。

こういった場合、ABS-ECUで車速を計算してエンジンECUはABS-ECUから車速の数値だけ貰えばよくなります。

【どんな規格なのか？】

〈信号〉

2線式差動方式です。

これは2つの線だけでやり取りします。

差動方式では2線間の電位差（=電圧）があるかないかをビットに見立てて通信を行います。

この方式はノイズに強いことが特徴です。

車の制御で使う通信には耐ノイズ性は必須です。

〈ボーレート〉

125kbps〜1Mbps
有線無線問わず、最近の基準からすると比較的遅いです。

車用途とはいえ情報量が大きくなって来ているので、さらにスピードを上げた規格も出来ています。

〈ネットワークトロポジ〉

バス型で繋がれます。
この方式は複数の装置が同じ線で繋がれます。

バス接続の弱点として線に問題があれば全ての通信がうまくいかなくなります。

車の場合、ネットワーク上にある装置はシステムでほぼ固定されるためあまり問題にはなりません。

〈マルチマスター方式〉

例えば古くからあるシリアル通信RS-232Cでは、1対1の通信しか想定しておらず、通信線も送信用の線と受信用の線を備えていました。

CANではバス接続により、送信と受信の分け隔てなく信号はバス上に乗せられます。

2本のCANラインをバスに接続し、送信したい装置は送信したいタイミングで送信し、受信する側はバスを常に監視して必要だと思ったデータを受信します。

【レセッシブビット・ドミナントビット】

通信は基本的に送受信する電圧を通信相手同士で共有化することで情報をやり取りしています。

情報を乗せるタイミングが複数の装置で被った場合には違う電圧を乗せることになります。

電気的にどちらかが勝つようになっていて、弱い方をレセッシブ（劣勢）ビット、強い方をドミナント（優勢）ビットと言います。
このビットの優先順位があることにより通信がかち合っても成立するように出来ています。

自分が送信した内容を1ビット毎に受信し、自分の送信した内容と違った場合、送信を諦めることで混信を防いでいます。

【パケット構成】

CAN通信は数10ビットのパケットで情報をやり取りします。

パケットの中身は主に以下で構成されています。
・CAN-ID
・データレングス
・データ（最大8バイト）
・ACK
・CRC

〈CAN-ID〉

標準フォーマットでは11ビットのIDがあり、パケットの先頭の方に配置されています。

前述のように通信がかち合うとレセッシブビットを送出したマスターは送信を諦めます。

なので頭の方がレセッシブビットのIDは優先度が低く、反対に頭の方がドミナントビットのIDは優先度が高いIDになります。

優先度の高い通信でバスが占められていると、優先度の低いCAN-IDの通信は毎回諦めなくてはならずいつまでたっても送信できないという事態になります。

このIDは誰が決めるかというと、車の通信システム設計者です。

バス上にどんなデータが流れるかを把握し、優先度の高い通信を優先度の高いIDに割り振り、優先度の低い通信を優先度の低いIDに割り振ります。

どのIDがどこのECUで何を示すのかはシステム設計者に委ねられているので、メーカーや車種ごとにバラバラです。
（OBD関係を除く）

OBD関係で使われるIDは互換性を保つために共通化が図られています。

ただし、通常の制御に使う通信を妨げないように優先度の低いIDが割り振られています。

〈データレングス〉

後述するデータの長さが入っています。

1〜8を指定します。

CANバスは通信需要の高まりからIDが枯渇気味になっており、基本的には8ビット全て使い切るケースが多いです。

よってこのレングスはほとんどの場合8が入ります。

〈データ〉

通信の内容の本体が収められています。
どのIDのどのバイトのどのビットが何を意味するのかは公開されていません。

公開されていませんが、システムを構成する装置の設計者間で割り当てをやり取りする事で通信が行えます。

〈ACK〉

パケット中のACKビットはそのパケットを送出するマスターからはレセッシブビットで送出されます。

バス上に出たCAN-IDを受信する装置はこのビットのみをドミナントビットで送出します。

このことにより、送出したマスターは「誰かが受け取った」ことがわかります。

〈CRC〉

車分野でCRCというとKUREの浸透潤滑剤CRC556の方を思い浮かべる人の方が多いと思いますが、全く違います。

CRCは通信やデータ構造の正当性を確認するための一般的な方法です。

送信側でデータから演算して求められた値を埋め込んでおき、受信した側では同じ方法でデータから演算し埋め込まれているCRCのコードと一致するか確認します。

一般的なチェックサムと違って除算を使うのでビットの順序が入れ替わった場合でもチェックが出来ます。

【OBDとの関係】

ECUが自己診断機能を持った時、故障の内容が分かるように診断結果を人間に知らせる機能が必要になりました。

当初はヒューズボックスのTEST端子ショートすることによりMILランプの点滅回数でどの異常が発生しているのかを知らせていました。

しかしこの方式では人が読み取れる速度でランプを点滅す必要があり、事細かな情報の伝達は出来ません。

OBDが始まった時にはまだCANはありませんでした。

PWMやKWP2000などのプロトコルで通信を行なっていました。

CANが普及してくると、2008年にOBDに組み込まれ標準化されました。

【CANの弱点】

〈リアルタイム性〉

CAN-IDによって優先順位付けを行うことが出来ますが、通信がバス上に乗るタイミングが保証できません。

これでは単に情報をやり取りするには良いですが、数ms以内に情報を伝える必要のあるリアルタイム制御には使えません。

例えば電動パワーステアリングを想定すると、舵角センサーと駆動用モーターをバス上に繋いで制御するとして舵角センサーの値がいつまでたっても来なかったりしたらどうでしょう？

現在値が目標とずれているからといってモーターをずれのぶんだけ回そうと思っても、次に舵角が来るまでどれだけ回せば良いのか分かりません。

いざ舵角が来ても、どれだけ時間ぶん値が遅れて来たものなのか分からなければ、どれだけの速度で舵角が変化しているか分かりません。

〈セキュリティ〉

CANは車のシステムとしての成立性と耐久性、対ノイズ性に重きが置かれた設計がされたプロトコルのため、外部からの攻撃に関するセキュリティには甘いです。

車のOBDコネクタにあるCAN端子からバス上に繋がれたECUのフリをする装置を繋いで、操作要求に値する信号を流すことで車両を操作することが出来てしまいます。

自分の車は自分が管理するため問題になりにくいですが、近年レーダー探知機などOBDコネクタに繋ぐサードパーティ製品が増えてきていることを考えると、安全性の確保されていない製品をそれと知らずに繋いでしまい、事故の原因になる可能性があります。

【次世代CAN】

前述の弱点を回避すべく作られたFlexRayという通信規格があります。

しかし普及は進んでいません。

X-by-Wireの普及とともに普及すると見込まれましたが、価格の高さとソフトウェアの組み込みにくさが原因です。

CAN-FDという今までのCANと同様の使い方が出来る拡張型のCANが使われ始めているようです。