FlexRay
特徴
FlexRayは、最大10 Mbit/sの高速データレートに対応し、スター型とパーティライン型の両方のバストポロジに対応し、フォールトトレランスのために2つの独立したデータチャネルを持つことができる（1つのチャネルが動作しない場合は、帯域幅を減らして通信を続けることができる）。バスは、静的セグメントと動的セグメントの2つの部分に分割された時間周期で動作する。静的セグメントは、個々の通信種別のスライスに事前に割り当てられ、CANよりも強力なリアルタイム性の保証を提供する。動的セグメントは、CANのように動作し、ノードがバスを使用可能に制御して、イベント・トリガの動作を可能にする。
規格変遷
本規格仕様は、主に物理形状と通信プロトコルから構成され、以下のバージョンによって違いがある。
1.0
2002年4月仕様発表
2.0
2004年6月仕様発表
2.1a
2005年12月仕様発表。2009年現在最新版の「欧州版FlexRay規格」
3.0（仮称）
順調にいけば2009年末に規定予定の「日本版FlexRay規格」
長年の研究開発
FlexRayは突然生み出された技術規格ではない。欧州では1979年から現在のFlexRayに繋がるいくつもの研究開発の蓄積の上で登場した技術である。1979年にMARSプロジェクトとして航空機、鉄道、自動車用の通信機規格の研究開発が始められた。その後、PDCSプロジェクト、X-by-Wireプロジェクト、TTAプロジェクトなどがほぼ1989年から1998年までの間に進められ、EU委員会はこれらに数百億円規模の研究費助成を与えた。
これらの研究はやがてTTP/CとFlexRayという2つのグループに分かれたが、アウディ・PSA・プジョーシトロエン・ルノー・フォルクスワーゲンを中心としてTTP/Cを推進していたTTAグループからフォルクスワーゲン、PSAとルノーがFlexRay陣営に移動するなどしたため、"FlexRay Consortium"が欧州における車載LANでの新たな主流規格の座を獲得した。
JasPar
日本の自動車メーカーも、CAN通信がロバート・ボッシュ社による特許独占を受けていた状況を変えるものとして欧州でのFlexRay規格の登場を基本的には歓迎した。特に、XBWのようなブレーキやステアリングの操作を電気的に伝える用途にイベント・ドリブン型のCANを使おうとしてもリアルタイム性が欠けるために不適であり、タイム・トリガ型で冗長性にも配慮したFlexRayは魅力的だった。
日本側から見た欧州版FlexRay規格の問題点は、高コストになる点であった。FlexRayを策定し導入を進めていた欧州の自動車メーカーは主に高級車を作っておりコストはそれほど障害とならなかったが、日本側では一般大衆車を主眼にしていたので低コストは必須だった。また、欧州での新たな自動車技術の適応は、新車種などから順次切り替えてゆく手法が採られていたが、日本の自動車メーカーでは車内LANのような基盤技術は全車種統一して開発と生産が行なわれていたので、一部の高級車だけに導入するという手法が採りがたかったという事情もあった。
2004年9月にトヨタ自動車や日産自動車が中心となって日本の自動車産業各社が集まり、CANを代替する用途としてのFlexRayの新たな下位規格を作ることを最初の主な目的にして、"Japan Automotive Software Platform and Architecture" (JASPAR) が設立された。
JasParに参加した日本のメーカーでは高コストになる要因の1つであるスター型トポロジの接続形態をバス型トポロジにすることでコスト高となるワイヤーハーネス分岐点のカプラを省くことを検討した。欧州版FlexRayでもバス型トポロジをサポートはしていたが、バス配線で高速通信を実現すると不要電磁放射による環境条件が厳しい車内では数個のノードしか接続できなくなるので不都合だった。このため通信速度を10 Mbpsから5 Mbpsと2.5 Mbpsの2種を加えることでバス型によってカプラを省きながらノード数も6個や22個と十分確保する新たな規格を求めた。
日本の足踏み
JasPar（日本のメーカーを主体とした規格団体）が日本のメーカーが希望する新たなFlexRay規格を2009年末にも規格制定する見込みであるが、この制定が手間取っているだけでなく、基幹部品となるマイコン内部に組み込まれるFlexRay通信用IPコア及びトランシーバICの開発も進んでいない。ロバート・ボッシュ (企業) とフリースケール・セミコンダクタは共同でJasPar版FlexRay対応のIPコアを1種類だけ開発すると表明している。日本の半導体メーカー側の積極性が問われそうだが、JasPar版FlexRayの策定を主導している日本の大手自動車メーカーのいずれもがJasPar版FlexRayの実車への搭載に躊躇していることがその原因となっている。
トヨタ自動車ではプリウスにJasPar版FlexRayの採用を検討したようだが、見送った。CANの利用においてはボッシュ社の特許独占問題や今後の機能拡張・性能向上の余地がなく代替技術に移行したいが、日本の自動車メーカーからすればFlexRayはCANに比べるとトランシーバICで2-3倍にコスト上昇が見込まれ、ソフトウェア開発もCANより工数が増え、ハーネスも同等レベルのコストを維持できるか疑問とされ、総体としてはかなりのコスト高が予想されるので簡単にはCANから移行できない。こういった事情は鶏と卵の関係にも似て、実車に採用されないと電子部品の価格は下がらず、電子部品の価格が下がらないと実車に採用できないというジレンマに陥っている。
日本のメーカー側ではJasPar版FlexRayを策定し、その実績を持って車載ソフトウェアの標準化団体であるAUTOSAR内に日本の自動車産業界の立場を確立する構想であったが、日本版FlexRayの先行きすらも危ぶまれる状況になっている。AUTOSARでは自動車用MCUの内蔵ソフトウェアをモジュール化/汎用化することで再利用を容易にする規格を策定中であるが、開発工数削減が期待出来る反面、マイコン(MCU)に要求される能力が高くなるため高価となり、トータルではコスト高となることを危惧して日本側ではモジュール化に反対の立場である。
クロック
FlexRayシステムは、バスとプロセッサ（電子制御ユニット、ECU）で構成されている。各ECUには独立したクロックがある。クロックドリフトは基準クロックから0.15%以下でなければならないため、システムの最速クロックと最速クロックの差は0.3%以下である。
これは、ECU-sを送信機、ECU-rを受信機とするとき、送信機での300周期の間に受信機側では299〜301周期が存在することを意味する。クロックを頻繁に再同期することで、問題が発生しないことが保証する。クロックは静的セグメントで送信される。
サンプルするビット
ビットの値は、8ビット領域の中央でサンプリングされる。エラーはいちばん端の周期に移動し、ドリフトが小さくなるように頻繁にクロックが同期される（ドリフトは300周期あたり1周期より小さく、送信中は300周期ごとに1回以上同期する）。
開発ツール
FlexRayの開発やトラブルシューティングを行う際には、ハードウェア信号の検査が非常に重要である。ロジックアナライザとバスアナライザは、信号を収集、分析、デコード、保存して、高速波形を表示できるツールである。
FlexRayの将来
このプロトコルには、動作電圧レベルが低く、エッジが非対称であるなどの欠点があり、ネットワークの長さを長くする際に問題となる。帯域幅が集約的で安全性に欠けるアプリケーションでは、EthernetをFlexRayに置き換えることができる。