30分で分かるCAN、設定とデザインのポイント：有線通信技術 CAN（1/2 ページ）

　1980年代に登場したCAN（Controller Area Network）は、ISOによる国際標準化を経て、非常に大きな進歩を遂げた。機能が拡張されていったことにより、CANの応用領域は広がり、今では自動車から、産業機器、工場のライン制御などにも使えるようになった。しかし、機能の拡張に伴い実装も複雑になっていった。

　CANのコントローラは初期のものから発展した結果、多くの機能を備えるようになった。今では、さらに多くの機能を持つコントローラを使うこともある。そして、CANを制御するソフトウェア・ライブラリは、多様である。車載機器間の通信に使うだけでなく、産業機器の制御などに使う「CANopen」や「DeviceNet」といった通信プロトコルに対応するものもある。

　自動車の中で、CANは「部品」の1つにすぎない。開発者はなるべく少ない手間でCANを実装する必要があり、自動車システム全体を見渡すようにしなければならない。周辺機器の設定に手間取るようではいけない。本稿では、CANインタフェースの概要を見渡し、幾つかの異なる実装方法、設定方法について議論する。そして、設計を最適化し、インタフェースの性能を上げる方法にも触れる。

CAN小史

　CANは、ドイツRobert Boschが開発したものだ。車載機器をつなぐ配線がどんどん複雑になっていたことから、これを解決することを目的にしていた。初期の車載組み込み機器開発では、単一のマイコンを内蔵した機器は単一の機能しか持たなかった。複数の機能を備えていたとしても、それぞれは単純なものだった。例えば図1左のようにA-D変換器経由でセンサーの値を読み取り、直流モーターを動かす程度のものだった。

　それぞれの機能が複雑になるにつれ、2つ以上のマイコンを搭載した機器に機能を実装するようになった。そして、図1右のように「I²C（Inter-Integrated Circuit）」や「SPI（Serial Peripheral Interface）」といった通信プロトコルで機能間の連携を取るようにした。

図1　車載組み込み機器の初期の構成　単一のマイコンでごく単純な機能を実現するところから始まり、複数のチップをI²CやSPIで接続して連携させるという段階まで進んだ。

　先に挙げた直流モーターを例に取ると、より複雑になった機器では、2つあるマイコンのうち、一方が状態を診断する機能や、非常時にモーターを停止させる機能など、ほとんどの機能を受け持つ。もう一方は直流モーターの制御に専念する。このような設計は、汎用のマイコンが安価で手に入るようになったために可能になった。

　最近の自動車では、単一の機器に全ての機能を実装するのではなく、複数の機器に機能を分散させ、機器を車内のあちこちに配置するようになっている。このように分散配置した機器の間をつなぐ、耐障害性（フォールト・トレランス）を備えた通信プロトコルが必要になったことから、自動車市場向けにCANが開発された（図2）。

図2　CANを使った組み込み機器の構成例　共有バスに複数の機器がつながる形を採る。

　そして、1990年代半ばまでにCANは自動車市場を越えて発展していった。CANopenやDeviceNetといったプロトコルが開発され、産業機器の制御にも使われるようになった。

基本は共有バス構造

　CANの用途の広さが魅力となり、多くのマイコン・ベンダーはCANコントローラの機能を自社のマイコンに統合した。CANの機能はI²CやSPIのように2つの機器や部品（ノード）の間で通信する技術に似ているように見えるかもしれない。しかし、CANの通信方式はそれらとは基本的に異なる。

　CANのネットワーク構成は共有バスである。ただし、バスにつながるノードはアドレスを持たず、ノードが流すメッセージが持つIDによって、通信の優先度を決める方式を採っている。そして、CRC（Cyclic Redundancy Code）の一種である「CRC-15」による誤り検知機能を備える。

　CANのバスには、それぞれのノードから同時に複数のメッセージが流れる可能性がある。例えば、ブレーキはホイールに取り付けたセンサーからの速度情報メッセージを流そうとし、同時に機器が正常に動いているかどうかを知らせる診断情報メッセージを流そうとするノードがあるとする。この場合は後者が優先される。

　メッセージを受信したノードが、メッセージのIDを見て優先度を判断するような構造では、マイコンに高い負荷がかかり、マイコンに他の機能を統合することが難しくなるように見えるかもしれない。この問題は、必要に応じて異なる種類のCANコントローラを使い分けることで解決できる。