車載Networkの3回目は、「CAN」の後継規格として開発された「FlexRay」をご紹介する。

　1990年代に入り、広くCANは車載機器に利用されるようになってきたが、実際に搭載しはじめると色々と問題が生じるのは、どんな規格でも同じではある。CANの場合、仕様は定まったものの、厳密な相互接続性試験の手順を定めておらず、このため実際に接続したら「動かない」というケースが当初頻繁に発生した。また、90年代の車両であればCANの500kbps程度の性能で十分間に合うと判断されたが、これは逆に言えば今後に向けての伸び代が殆ど無いという意味でもある。

　このため、CANを利用して様々なECUを開発するのと並行して、CANの次にあたる規格の策定が2000年前後から始まった。当初は様々な既存の規格の延長線にあるものが検討されたが、どれも将来の車載バスには十分ではない、ということで、新しく車載バスの規格を定めることになった。最終的にこれはFlexRayという名称で、2002年にVersion 1.0がリリースされる。

　FlexRayの構成は、さまざまな要求が反映されている。転送速度は10Mbps（現在は最大20Mbps) となったほか、CANに欠けていたリアルタイム転送性、CANを上回るネットワーク構成の柔軟性や、堅牢性（冗長性、と言い換えることもできるが) の確保などが求められ、これを全部カバーするような構成となった。

　まずスピードに関して言えば、「X-By-Wire」の採用が当初から念頭にあった。X-By-Wire、最近ではもう少し具体的にSteering-By-WireとかBreak-By-Wireといった名称になっているが、元々はアメリカ空軍の要求に応じてジェネラル・ダイナミクスが開発・製造したF-16戦闘機に搭載された「FBW（Fly-By-Wire）」が、量産製品に採用された最初のものとなる。

　当時の軍用機を含む高性能機や大型機は、操縦に必要な舵面の操作を油圧制御で行っていた。ただ油圧だから（特に戦闘機に求められる）急激な操作は難しいし、応答性をあげるために配管の油圧を高くすると、この油圧システム一式の重量や体積が馬鹿にならなかった。これを解決するためにF-16で採用されたのがFBWで、舵面の操作は電動アクチュエータで行い、これと操縦システムを電線で繋ぐ（これがFly-By-Wireの語源）というものである。ただ、このままだと反応が敏感すぎる事もあり、操縦桿とアクチュエータを直接繋ぐのではなく、間に操縦用のデジタルコンピュータを挟みこみ、舵面の直接的な操作はこのコンピュータが行う形となった。

　この方式は大成功を収めた。元々F-16という戦闘機は軽量戦闘機（LWF：Light Weight Fighter）という開発コンセプトに基づくもので、装置重量をなるべく抑えることが求められていたが、FBWはこれを実現したのみならず、思わぬ副産物ももたらした。

　もともと航空機は正の安定性（外乱が無ければそのままの姿勢を維持して飛行を続ける）を持たないとパイロットによる操縦が極端に難しくなるが、戦闘機というのは格闘戦をするのが主眼だから、あまり安定性が高いと運動性能が落ちてしまう。ところがFBWを使うと、機体が負の安定性（外乱が何も無くても飛行姿勢に乱れが出てしまう）の機体であっても、コンピュータが常時状況を監視して舵面の操作を自動的に行うことで、パイロットから見るとまるで正の安定性を持つように振舞うことが可能になる。これにより、格闘戦時の運動性能は高まるし、安定性を高めるための諸々の機体構造を省くことが可能になるのでよりいっそう軽量、小型化できるというわけだ。

　この「正の安定性を後付けで獲得できる」という点や、操縦系統に関わる配管などを省ける（＝重量と体積の節約になる）ということは当然自動車にとってもメリットは大きく、そんなわけでFlexRayの検討を始めた当初から、将来的にはこうした方向に進むことは十分考慮されていた。

　ただ、X-By-Wireの欠点は、何しろ猛烈な量のデータが流れることだ。航空機ほどではないとはいえ、常に車体の状況（前後タイヤの回転数、サスペンションの状態やトー角、フロントタイヤのステア状況、車の姿勢や進行方向、速度/加速度、etc……）をセンサーで取り込み、その状況に応じて細かく制御を行わなければ安定性は保てない。F-16の場合、「MIL-STD-1553」という1Mbpsのバスをそれぞれの舵面に配して対応したが、これは軍用機だから可能なことで、コスト面で制約がある自動車向けには、できればバスは1本でまとめたい。そうなると、とにかく転送速度を上げることが必須となる。

　2番目の話も、実はこのXrive-By-Wireに関係する。X-By-Wireでは、原則として現在の車体なりアクセルなりブレーキなりといった状況を定期的にセンサーなどから取得して、制御ECUの内部で仮想的な「現在の状況」をモデリングし、そこにユーザーの操作を加味して制御を行うわけだ。

　たとえばBrake-By-Wireであれば、4つのタイヤの回転数を常時監視している。で、左コーナーにブレーキをかけながら進入、なんてシーンでは相対的に左後輪の荷重が抜けやすくなるから、最初に空転しやすくなるわけだ。そこでユーザーがブレーキペダルを踏んでも、左後輪向けのブレーキのアクチュエータは圧力を弱めるなどして、空転しないように工夫することになる（逆に右前輪はブレーキアクチュエータの圧力を高めることも可能になるが、そこまでやるかどうかは車体制御の味付けの話になるのでここでは割愛）。こうしたことを行うためには、常時タイヤの回転数をECUは取り込んで監視する必要がある。

　ところがこれをCANでやろうとすると、なかなかに難しい。というのは、4つのタイヤ回転数センサーは場所が分散しているだけに、どうしても4つのECUに分散されるわけで、これを1つのCANで接続してしまうと、IDの振り方一つで「よくデータを取れるセンサーのEUC」と「時々データが取れなくなるセンサーのECU」が発生することになる。CANの原理上これは避けられないのだが、だからといってこのままではよろしくない。

　FlexRayではこれを避けるため、ちょっとした工夫をしている。FlexRayは、「Frame」という単位で通信を行う。このFrameの長さは、最終的にはECUを含むFlexRayを利用して構成するシステムの設計者が決めるものだが、仮に1msとする。つまり1秒間に1000回、Frameの伝送が行われるわけだ。この1つのFrameは、STDMA（Static Time Division Multiple Access）とFTDMA（Flexible Time Division Multiple Access）、それと制御コードで構成される。仮にSTDMAを600μs、FTDMAを300μs、制御コードを100μsと仮定する。

　各タイヤ回転数センサーによるデータ伝送は、STDMAの方で行う。こちらは設計者があらかじめ定めるもので、たとえばまず右前輪、ついで左前輪、右後輪、左後輪の順でそれぞれの回転数センサーから回転数を受け取ると決めた場合、こちらは毎Frameごとに必ずその転送時間が予約される。つまり1秒間に1000回、それぞれのタイヤの回転数を取り込めることがFlexRay全体で保証される。一定期間ごとに必ず発生するデータ転送は、このSTDMAを使って行うことになる。

　一方、不定期に発生するイベント、たとえばドライバーのブレーキ操作に応じてそれぞれのアクチュエータに指示を行うといったものは、FTDMAを使って転送する。こちらも基本的には、全てのECU（正確に書けば、FlexRayに繋がっている「FlexRayのノード」という）が均等に利用できる様になっている。重要なのは、バスの転送時間をどのECUにどう割り振るか、を事前に設計者が定め、それにあわせて通信できるようになっている点が、CANとの大きな違いである。先ほどリアルタイム性という書き方をしたが、FlexRayを使うと「一定時間以内（今回の例なら1ms以内）に必ずデータ転送を行えることが保証される」というのがこのリアルタイム性の意味するところである。

　堅牢性に関しては、たとえば冗長構成（FlexRayの配線を2組使って冗長化させる）とか、Bus Guardian（もしECUが壊れたり暴走したりしても、FlexRayに変なデータが送り出されないようにガードする）のサポートなど、いろいろ工夫されている。また柔軟性にも富んでおり、CANを上回る柔軟な構成が可能となっている。

　ということで、ここまではいいことづくめな書き方をしてきたが、大問題だったのが価格の高騰である。FlexRayは元々BMW、ダイムラー、NXPセミコンダクターズ、フリースケールセミコンダクターズの4社で開発を始め、途中でボッシュ、フォルクスワーゲン、PSA、ルノーなどが参画して策定された規格である。現在はこれにGMも加わって「FlexRay Consortium」を形成、ここで仕様が決められており、要するに欧米の自動車メーカーと半導体メーカーが主体になって開発された規格である。で、X-By-Wireは当然ながら高級車向けのシステムであり、ある程度価格が高くても許容されるという話であった。ところが日本の自動車メーカーもFlexRayを検討することになり、こうした高価格は許容できないという話が出てきた。

　実はCANでもう1つ問題だったのは、CANの規格そのものはISOによる標準化が行われたものであるにも関わらず、ボッシュががっちり特許を握っており、使うためにはボッシュに特許料を支払う必要があった。FlexRayはこうした問題を回避すべく気をつけて仕様が策定されており、なので日本メーカーは「特許料を支払う必要の無いCANの代替規格」としてFlexRayを捉えていた節が大きい。

　このため、10Mbpsとかの高性能な帯域は不要で、むしろ1Mbpsでもいいからもっと安くといった要求を出すに至る。結局FlexRayとして最初に広く普及したVersion 2.1 Revision A（2005年12月）では2.5Mbps/5Mbps/10Mbpsといった複数の速度をサポートし、しかもFlexRayが1本の非冗長構成で策定されることになる。ただ今度は、このスペックでは欧米メーカーでは不満足ということで、Version 2.1 Revision Aと互換性を保ちつつより拡張したVersion 3.0が2009年12月に登場した。

2007年6月にフリースケールが米国で開催したFTF（Freescale Technology Forum）における一般展示。BMW X5の実車の脇にこの看板が掲げられていた

　実車への搭載、という意味でもやはり欧米が先行している。最初に搭載したのはBMWで、2006年末に発売されたBMW X5のリアサスペンションにFlexRayが採用された（写真）。2007年にはBMW 7シリーズ（F01）でFlexRayを全面採用するに至り、現在ではBMWのほかアウディ、ベントレー、ロールスロイスなどで採用されている（なぜかメルセデス・ベンツに関しては今のところアナウンスが無いのだが、こっそり採用しているのかもしれない）。

　一方日本のメーカーは？というと、上で述べたとおり価格の高さから採用に二の足を踏んでいる状態である。実はトヨタや日産が中心になって2004年にJasPar（Japan Automotive Software Platform and Architecture）という団体（https://www.jaspar.jp/）が設立され、ここでFlexRayのサブセットを制定し、FlexRay Consortiumに提案するという話だった筈なのだが、今もって具体的な成果は出ていない（念のために書いておけば、JasperはFlexRayのサブセットの規格を策定することだけが目的の団体ではなく、他の活動もやっている。成果が出ていないのは、FlexRayのサブセットに関する部分のみである）。

　そんなわけで、今のところはまだCANが主体ではあるのだが、日本車も昨今は電子制御化が著しく、特に最近のActive Saferyに向けた車体制御などはどうしてもFlexRayを持ち込まないと間に合わないというところに来つつある。個人的にはもう数年すると、高級車あたりから次第にFlexRayをベースとした設計が始まるのではないかと想像している。