30分で分かるCAN、設定とデザインのポイント

　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コントローラを使い分けることで解決できる。

用途に応じてコントローラを使い分ける

　CANコントローラには、ごく基本的な機能しか備えていないものから、マイコンにかかる負荷を下げるさまざまな機能を搭載したものまで、多くの種類がある。ここでは、各ベンダーが製造しているCANコントローラを大まかに3種類に分けて、それぞれの機能の違いを説明する。

　ここでは、3種類のCANコントローラを仮に「Basic」、「Full」、「Extended full」と呼ぶことにする。Basic CANコントローラは、必要なメッセージを受け取り、不要なメッセージを無視するだけの、ごく基本的な機能を備える。単純な機能しか備えていないため、マイコンにかかる負荷は高くなりやすい（図3上）。

 

図3　Basic CANコントローラとFull CANコントローラの違い
Basic CANコントローラはごく単純な機能しか備えていないが、Full CANコントローラはメッセージを蓄積するなどの機能を備える。

　Basic CANコントローラは、メッセージの受信、受信したメッセージの解析など、ことあるごとにマイコンへの割り込み信号を発生させる。マイコン上で動くソフトウエアでは、受信したメッセージのIDを見て、返信が必要かどうか判断し、必要ならば返信しなければならない。このように、Basic CANコントローラは、メッセージ通信が多く発生するとマイコンに高い負荷をかけることになる。データ転送速度を低く設定し、メッセージのやり取りがあまり発生しないところで使うべきだ。そうすることで、マイコンはCAN通信以外の処理に時間をかけられる。

　Full CANコントローラは、必要なメッセージと不要なメッセージを振り分けるだけでなく、返信が必要なメッセージに返信を出す機能も提供する（図3下）。Basic CANコントローラのように、メッセージの返信でマイコンに負荷をかけないようになっている。

　Full CANコントローラは、特定のIDのメッセージを受信したときだけマイコンへの割り込み信号を発生させるようにもできる。さらに、電子メールのメール・ボックスのように、複数のメッセージを保持しておくこともできる。マイコンは、貯まったメッセージをいつでも取り出せるが、同じIDを持つ同種のメッセージを再び受信する前に、メッセージが要求する処理を完了させなければならない。この点は、次に紹介するExtended Full CANコントローラを使うことで処理しやすくなる。

　Extended Full CANコントローラは、Full CANコントローラの機能に加えて、受信したメッセージを貯めておくために、ハードウエアFIFO（First In First Out）キューを備える。こうすることで、マイコンに割り込みをかけることなく、同種の複数のメッセージを貯めておくことが可能になる。その結果、バスの速度が上がってもメッセージを取りこぼすことはなくなり、マイコンにかかる負荷が少なくなる。

　ここで、1つ注意しておかなければならないことがある。DeviceNetでは、メッセージの振り分けに、IDだけでなく、データ領域の先頭2バイトまで使う。このような通信プロトコルを利用するときは、ここで説明したFull CANコントローラか、Extended Full CANコントローラに相当する機能を持つコントローラが必要になる。

　やりとりするメッセージの種類にもよるが、Full CANコントローラとExtended Full CANコントローラを同じ基板に共存させることも可能だ。こうすることで、特定のメッセージの優先度を高くし、マイコンがメッセージを処理する効率を上げることができる。

　例えば、障害に対応するためのメッセージを「0x250」というIDで受け取り、温度センサーの情報を「0x3FF」というIDが付いたメッセージで受け取るようになっている機器なら、障害対応に必要なメッセージをFull CANコントローラで受信し、温度情報のメッセージを4段のFIFOキューを備えるExtended Full CANコントローラで受信するように構成できる。

　障害対応に必要なメッセージをFull CANコントローラに受信させることで、メッセージが届くたびにマイコンに割り込みを発生させて、すぐに処理させる。温度情報のメッセージは4つ貯まったところで処理するという考えだ。

1ビット1ビットを確実に認識する

　CANの伝送速度は最大1Mビット/秒で、バスのケーブルは最大で1000mまで伸ばせ、配線の自由度が高い。ただし、ここまで伸ばすと伝送速度は最大50kビット/秒まで下がる。先ほど説明した機能のほか、このような扱いやすさの点でもCANは高い評価を得た。

　さらに、CANは耐障害性の面でも優れている。電気的雑音が多い環境で、1ビット1ビットを確実に認識するための仕組みを備えている。さらに、メッセージ送信失敗を検知する機能や、送信に失敗したメッセージの再送信機能を用意することで、耐障害性を高めている。

　各ビットを確実に認識し、耐障害性を高めるために、CANでは1ビットの転送にかかる時間を細分化した。細分化することで、CANバスの状態に応じて、信号を認識するポイントを操作できる。

　CAN上で1ビットを伝送する時間は、先頭から「Sync_Seg」、「Prop_Seg」、「Phase_Seg1」、「Phase_Seg2」の4つの期間に分けられる。この4つの期間の長さを操作することで、ビットを検知する時点（サンプル・ポイント）を前後に移動させることができる。

　Sync_Segは、バスとの同期を取るために使う。バスにつながる機器はすべてこの期間内で信号の送受信を始めようとする。言い方を変えると、信号の立ち上がり、立ち下がり（エッジ）がこの点にあることが望ましいということである。

　Prop_Segは、ネットワークの遅延を吸収するための期間だ。ここを伸縮させることで、CANバスで発生する遅延や、バスからノードへの配線の遅延の影響を避けることができる。

　Phase_Seg1とPhase_Seg2は、信号のエッジが早すぎたり、遅すぎたりしたときに、伸縮させる期間だ。信号を拾うサンプル・ポイントはPhase_Seg1の直後にあるので、例えば、エッジがSync_Segよりも遅いタイミングで来たときは、Phase_Seg1を伸ばし、Phase_Seg2を縮めることで、サンプル・ポイントをずらし、正確に信号を捉える。

　CANコントローラによっては、Prop_SegとPhase_Seg1をまとめて、合計3つの領域でビットを認識するものもある（図4）。

 

図4　CANでは、1ビットのデータを転送するのにかかる時間を複数の期間に分割する
図中左端の灰色の部分がSync_Seg。この長さは1TQと決まっており、変更はできない。その右がProp_SegとPhase_Seg1で、さらにその左はサンプル・ポイント。右端はPhase_Seg2。Phase_Seg1とPhase_Seg2の長さを伸縮させることで、サンプル・ポイントを調整できる。Phase_Seg1とPhase_Seg2の調整幅（SJW）の合計を1TQ～4TQとしている。ネットワークを正しく動かすには、それぞれの期間の長さを適切に調整することが必要。

　CANでは、1ビット当たりの時間、つまり先に挙げた4つの期間を8～25に細分化できる。細分化した1つ1つを「Time Quanta（TQ）」と呼ぶ。TQの実際の長さは、CANデータ転送速度から計算できる。

　TQの最小値は1ビットの転送に必要な時間の1/25だ。例えば、データ転送速度が1Mビット/秒の場合、1ビットの転送に1μsかかるので、TQは最小で40nsということになる。

　先に説明した、Sync_Seg、Prop_Seg、Phase_Seg1、Phase_Seg2のそれぞれの長さは規格で決まっている。TQで表現すると、Sync_Segは1TQ、Prop_Segは1TQ～8TQ、Phase_Seg1は1TQ～8TQ、そしてPhase_Seg2は2TQ～8TQとなる。この範囲で、1ビットが合計8TQ～25TQになるように設定する。ちなみに、Phase_Seg1とPhase_Seg2の調整幅の合計をreSynchronization Jump Width（SJW）と呼ぶ。

タイミング調整が要点

　このように、4つの領域の長さは、多様な値を取り得る。ここで適切な値を設定できるかどうかが、耐障害性の高いCANネットワークを構築できるかどうかの分かれ目となる。設計者は、発振器の周波数だけでなく、問題が起こっているノードの送信遅延、そしてほかのノードの遅延まで想定してネットワークを構築する必要がある。

　上記のようなタイミング調整には、機器のクロック周波数や、CANのデータ転送速度、そしてシステムごとに決められたサンプル・ポイントなど、さまざまな要素が関わってくる。このため、多くの設計者はこの仕事を嫌がるようだ。

　CANネットワーク設計が複雑であるため、設計者や開発者は、古いマイコンとソフトウエア・ライブラリを再利用して新しい組み込み機器を開発しようとする。すべての要求を満たす、まったく別のよりよい方法があったとしてもだ。このような事情から、CANは「それはとりあえず動いているから、変に手を出したくない」と言われる類の技術となってしまっている。

　10年以上使われている技術でありながら、CANは組み込み機器の設計では複雑な技術だと見られている。特に、研究開発の領域ではその傾向が強い。研究開発では、CANでいくつもの機器を接続して、機器の配置などの調整を繰り返す。CAN用のデバイス・ドライバの開発は専業ベンダーに外注できるが、仕様や設定の変更をあまり許してくれないベンダーもある。

　最近は、半導体ベンダーがCANコントローラの設定機能を備えた開発ツールの提供を始めている。例えば、米Cypress Semiconductor社のマイコン向けソフトウエア開発ツール「PSoC Creator」では、CANのメッセージに対応した割り込みの設定や、1ビット当たりの時間を簡単に設定できる（図5）。

 

図5　PSoC CreatorでCANコントローラの機能を設定しているところ
1ビットの転送にかかる各期間の長さを設定している。

　このようなツールを使えば、組み込みソフトウエア開発を外注することなく、市場の要求に素早く応えて製品を開発、出荷できるようになるだろう。