さて前回も紹介した通り今回も車載Networkの話。今回は一番広く使われている「CAN（Controller Area Network）」をご紹介したい。

　CANという規格を1986年に最初に作ったのは独Bosch。欧州の自動車メーカーに大きなシェアを持ち、日本でも有名なあのBoschである。

　この時の規格はBosch独自のものであったが、同社はこれをSAE（Society of Automotive Engeneers：自動車技術者協会。現在のSAE International）に提案し、「CAN 1.0」として制定された。

　さらに1991年にはバージョン2.0がリリースされ、最終的にはISO（International Organization for Standardization：国際標準化機構）でISO-11898として1993年に標準化（これをCAN 2.0Aと俗に呼ぶ）、さらに一部プロトコルを拡張したものが1996年にISO-11898：1996として標準化された（こちらがCAN 2.0Bと呼ばれる）。

　CANの場合、原則は図1のように、全ての機器（CANの用語を使えばNode［ノード］）が一対の信号線に直列にぶら下がる形である。

図1

　原則、というのはCANの仕様ではあくまで電気的な特性（信号の電圧や伝達速度、あるNodeからデータを送ったときに、それがどのくらいの遅延時間で他のNodeに伝達されるか、etc.）のみが定められており、なのでこの特性を満足するのであれば、図2のような構成にすることも許される。

図2

　転送速度はいくつかあるが、一番高速なものでも1Mbpsで、他にも83.3Kbps～500Kbpsといった低速なオプションも用意されている。1Mbpsというのは、例えばWi-Fiの一番遅いものがカタログ値で11Mbps、実行転送速度が2～3Mbps程度だから、これと比べても決して高速とは言えない。もっとも最近でこそ速度不足が段々顕在化してきているが、2000年台まではこれでも十分な速度であった。

　CANの特徴は色々あるが、CANの仕様書に設計目標として掲げられているのは

• マルチマスターで、優先順位ベースのアクセスを提供
  
• 非競合ベースの調停機構
  
• 受信フィルタを前提にしたマルチキャスト転送
  
• リモートからのデータ転送処理のサポート
  
• 構成の柔軟性
  
• システム全体でのデータ整合性の保証
  
• エラー検出と通知
  
• 調停で負けた場合や送信エラー時の自動再送信
  
• 一時的エラーと継続的な故障の切り分けと、故障したノードの自動切り離し
  

といった事柄である。

　順に説明してゆくと、まずCANは「Master-Slave式」の通信を行っている。これは、「誰がどう通信をするか管理する管理Node」（Master）と「管理ノードの指示に従ってデータの送受信を行うNode」（Slave）に分かれるという仕組みで、身近なところでは例えばUSBがこれにあたる。USBメモリは、ポートに刺したら自発的に通信を始めるわけではなく、PCなりスマートフォンなりが明示的に通信を行わないと、まったくデータの移動が発生しないことに似ている。

　CANの場合、例えば4つのタイヤについてそれぞれサスペンションの状況やブレーキのかかり具合など、それにジャイロセンサーやステアリング/ペダルの操作量をもとに車体制御を行うとすると、まず「車の状態はどうなっているか」を判断するためのデータ入力系は、図3のように構成されることになる。ここでは車体制御を行う中央のEUC（Body ECU）が、この赤い配線のCANのMasterとなり、4つのタイヤ毎にサスペンションやブレーキなどの情報を収集するECUやジャイロスコープ/加速度センサーなどで車体全体の動きを収集するEUC、ステアリングやペダル、シフトなどの操作状況をモニタリングするECUは全てSlaveとして構成されるのが普通だ。

図3

　では「マルチマスター」とは何か？　というと、図4のようにMasterとなるECUが1本のCANのNetworkの上に複数存在することが可能、という事だ。Body ECUは車体の制御そのものを行うが、それとは別に運転制御（燃料消費を監視したり、オートクルーズの制御をしたり）用にDrive ECUを追加する場合は、図4のような形で並ぶことになる。この場合、1本のCAN NetworkにBody ECUとDrive ECUの2つのMasterが存在できるというわけだ。

図4

　そうなると、今度はどうやって2つのECUがケンカせずに通信できるかという話になるが、これを行うのが「優先順位」である。全てのCAN NodeになっているECUは自身のIDを持っているが、このIDが高いほど優先的に通信を行える仕組みになっている。

　ちなみに全てのNodeは、通信前にまず「CAN Networkが空いているか」を確認してから通信する仕組みになっており、ここで複数のNodeが同時に確認をした場合には、常にIDが一番大きいものが優先される。なので、もしBody ECUが10000、Drive ECUが10001というIDを持っていて同時に通信を始めようとすると、Drive ECUが常に最優先で通信され、Body ECUはDrive ECUが通信をしていないときに通信するという形になる（ちなみに他のNodeが通信中は、それを打ち切って別のNodeが通信することはできない）。

　通信は「マルチキャスト」と呼ばれる「全Nodeに一斉通信を掛ける」仕組みである。これはTVとかラジオと同じ仕組みで、とにかく自分の出したいメッセージを勝手に送信するだけである。受け手は、ちょうどチャンネルとか周波数を合わせるように、「自分の必要とするデータだけを受け取る」という形で対応する。なので、全データを受け取るように設定しておけば、CANに流れる全てのデータを受信することが可能だ。実のところ、例えばステアリング操作の情報とかサスペンションの情報などは、Body ECUでもDrive ECUでも必要とするデータだから、マルチキャストを使うと1回の通信で両方のECUが受け取ることができて便利というわけだ。

　続く「構成の柔軟性」は、例えば図1と図2を見比べていただければ分かるが、さまざまな形での接続がサポートできるよという話。これに続くデータ整合性の保障とかエラー検知/通知、自動再送信、自動切り離しといった話の詳細を語っても退屈なだけになるので割愛するが、概ね字面だけでも機能は想像できるかと思う。

　カーナビならデータ転送に失敗しても、それでいきなりクリティカルな状況になることはまず無いが、車体制御とか運転制御でデータ転送に失敗すると、しばしばクリティカルな状況になりかねない。勿論、通信エラー一発でいきなりクリティカルにならないような工夫はECU側でも当然のように施されているが、CAN側でもこうした工夫をすることでより抗堪性を高めよう、というわけだ。

　実のところ、CANのこうした「確実にデータを転送させるための仕組み」は、自動車以外の用途でも都合がよく、工場における製造装置の制御といった用途でも広く利用されているのが現状である。元々CANは最大40mもの長さで配線を引っ張ることができるし、最高速が125Kbpsでよければ500mもの配線を引っ張ることが可能である。

　また2本の配線を使うことでノイズに強い（差動式、と呼ばれる信号の伝達方式を利用しており、外部からノイズが入っても打ち消すことができる性質を持つ）特徴がある。信号そのものは車載向けらしく＋12Vが基本であるが、－3V～＋16Vという非常に電圧の幅が広い状態に対応しており、このあたりも工場などでの利用に適している。

　ただその一方で、CANのいろいろな問題点も最近になって取り沙汰されるようになってきた。

　まず信号速度が低速なことである。当初はこれで十分と思われた（1986年当時なら楽勝であった）が、昨今のECUが山のように搭載された車では、これはもはや十分とは言えない。

　この対策のひとつが、複数本のCAN Networkの搭載である。例えば先ほどのケースで言えば、車体/運動状態の取得そのものは1本のCAN Networkでできるとしても、そこから車体制御の指示は別のCAN Networkを使う（図5の青線）といった形だ。

図5

　実際、最近のECUは、こうした複数のCAN Networkを並行して利用することを前提に構成されている。例えばPhoto01は、ルネサスエレクトロニクス（日立製作所と三菱電機のマイコン部門が合弁したルネサステクノロジと、NECエレクトロニクスが合弁してできた会社。詳細はこのあたりを参照）が車体制御のハイエンド向けとしてリリースしているV850E2/Fx4（http://japan.renesas.com/products/mpumcu/v850/v850e2fx/v850e2fx4/index.jsp）というマイコンの内部構造である。この中で赤い枠で囲った部分がCANのインターフェースで、2本のCAN Networkを利用できるようにFCN0とFCN1という2つのインターフェースが装備されているのが分かる。

Photo01

　ただ、無条件でCAN Networkを増やしても配線が過剰になるだけで、あまりうれしい話ではない。そこで、CANを上回る性能を持つ、「FlexRay」という新しいNetworkも登場した（Photo01では黄色で囲った部分が、このFlexRay用のインターフェースである）。

　一方、逆にCANは非常に堅牢ながら、それほどクリティカルで無い用途（例えばドアミラーの制御）には過剰である、という声も出てきた。これにあわせてより低価格化したものに「LIN」というNetworkがある。Photo01の場合、5本ものLINインターフェースを持っている（Photo01で緑で囲った部分。LMA 10/11と、LMA 2/3/4の5つ）事が分かる。

　要するに今のところ車載NetworkはCANが中核をなしており、部分的にFlexRayに置き換えが進みつつある状態で、クリティカルで無い部分はLINが担っているという形で、CANの不足部分を補っているわけだ。

　ということで次回はFlexRayをご紹介したい。