FlexRay

FlexRay（フレックスレイ）とは、FlexRay Consortiumによって開発された、自動車などの車載ネットワーク（車載LAN）の通信プロトコル（ビークルバス）の1つである。

車載通信ネットワークとしては最も普及しているController Area Network(CAN)とは異なる要求に答えるものとして2000年頃から欧州の自動車メーカーを中心に策定作業が本格化し、2004年には日本の自動車メーカー数社も日本側からの要望を取り入れた規格策定の動きをはじめた。欧州製の高級自動車では最新の2.1a規格に沿った車載LAN製品の採用が始まっている。FlexRayコンソーシアムは2009年に廃止されたが、FlexRay標準は現在、ISO標準 17458-1 - 17458-5となっている。

CANやTime-Triggered Protocol(TTP)よりも性能や機能を大きく上回る規格として、高速で信頼性が高くなるように設計されたため、コストが高い。日本の自動車メーカーではよりCANに近い新たなバージョンである3.0（仮称）の規格制定に動いている。

名称はFlexible Ray（柔軟な光線）転じてFlexRayとなっているが、2009年現在においては電気による通信のみが実用化されている。

特徴

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規格」

CANへの不満

高い特許料

CANはISO化はされているがドイツのボッシュ社が独自に開発した規格であり、特許の大半は同社が保有している。自ら「ライセンス料で大きな利益を得ている」と認めるように、ライセンス条件や料金は1社で独占して決められる。

非相互接続性

ボッシュ社は互換性を保証するための厳密な相互接続性試験の規定を定めなかったため、同社とそれ以外のメーカーのCAN製品同士での接続には問題が生じた。

非リアルタイム性

長年の研究開発

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での新たな主流規格の座を獲得した。

3つの規格の比較

FlexRay 2.1aとFlexRay 3.0, CANとの比較を以下に示す。

.	FlexRay 2.1a	FlexRay 3.0 （正式規格前、仮称）	CAN
トポロジー	バス型 （スター型、複合型も可能）	スター型 （バス型、複合型も可能）	バス型
通信速度	5 Mbps, 2.5 Mbps (10 Mbpsも可能)	10 Mbps	1 Mbps （多くが500 kbpsで使用）
最大ノード数	6個（5 Mbps）、 22個（2.5 Mbps）	スター型：22個 バス型：数個	15個程度 （自動車メーカーにより異なる）
チャンネル数	1チャンネル	2チャンネル	1チャンネル
通信タイミング	タイム・トリガ型	タイム・トリガ型	イベント・ドリブン型

標準化団体

FlexRayコンソーシアム

2000年9月に、ドイツのBMW・ダイムラー、オランダのNXPセミコンダクターズ、アメリカのフリースケール・セミコンダクタによって新たな自動車用通信規格を策定を目指して、FlexRayコンソーシアム(FRC)が設立された。2001年8月にはボッシュも参加した。FRCは以下のコアメンバーで構成されていた。

• フリースケール・セミコンダクタ
• ロバート・ボッシュ
• NXPセミコンダクターズ
• BMW
• フォルクスワーゲン
• ダイムラー
• ゼネラルモーターズ

FlexRayコンソーシアムには、他にのプレミアム・アソシエートおよびアソシエート・メンバーも存在した。2009年9月までに、28社のプレミアム・アソシエートと60社以上のアソシエート・メンバーが加盟していた。2009年末に、コンソーシアムは解散した。

欧州の高級自動車メーカーを中心に設立されたFRCは、CANに比べて機能と性能の両面で上位の規格を求めていた。例えばブレーキ操作などを電気的に伝える"X-by-Wire" (XBW) などを実現できる通信規格である。XBWでは高い信頼性と高速性が求められるため、通信用チャネルは2系統備えて冗長性を持たせ、通信速度も10 MbpsとCANの10倍とされた。

FlexRayの規格策定にあたっては、ボッシュによるCAN特許の独占の轍を踏まないように、特定の1社が主導することを避けながら慎重に進められ、FRC参加企業には特許ライセンス料を支払わなくて済むようにされた。相互接続性の適合性テストの内容も厳密に定められた。

2002年4月に最初の要求仕様1.0を発表し、2004年6月には2.0を、2005年12月には2009年現在最新版となる2.1aを発表した。

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周期が存在することを意味する。クロックを頻繁に再同期することで、問題が発生しないことが保証する。クロックは静的セグメントで送信される。

バス上のビット

0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 エラーがない場合の平均を修正する。 信号は単に2周期だけ遅延される。

0 0 0 0 0 0 1 1 1 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 8周期の中間付近のエラーは解消される。

0 0 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 8周期領域の境界付近の誤差が境界ビットに影響を与える可能性がある。

毎回、1つのECUだけがバスにデータを書き込む。送信される各ビットは8サンプルのクロック周期の間バス上に保持される。受信機は、最後の5つのサンプルのバッファを保持し、最後の5つのサンプルから多数決で入力信号を決定する。

単周期の送信エラーは、ビット境界付近の結果に影響する可能性があるが、8周期領域の中央部には影響しない。

サンプルするビット

ビットの値は、8ビット領域の中央でサンプリングされる。エラーはいちばん端の周期に移動し、ドリフトが小さくなるように頻繁にクロックが同期される（ドリフトは300周期あたり1周期より小さく、送信中は300周期ごとに1回以上同期する）。

フレーム

すべての通信はフレーム形式で送信される。メッセージは、次のようにパックされたバイト $\{x_{0},x_{1},\dots ,x_{m-1}\}$ である。

• Transmission Start Signal (TSS) – bit 0
• Frame Start Signal (FSS) – bit 1
• m 回繰り返し:
  • Byte Start Signal 0 (BSS0) – bit 1
  • Byte Start Signal 1 (BSS1) – bit 0
  • 0th bit of i-th byte
  • 1st bit of i-th byte
  • 2nd bit of i-th byte
  • ...
  • 7th bit of i-th byte
• Frame End Signal (FES) – bit 0
• Transmission End Signal (TES) – bit 1

何も通信されていなければ、バスは状態1（高電圧）に保持されているので、全ての受信機は、電圧が0に低下したときに通信が開始されたことがわかる。

受信機は、BSS0 (1) またはFES (0) が受信されたかどうかをチェックすることで、メッセージがいつ完了したかがわかる。

ビットあたりの8周期はバイトとは無関係である。各バイトは転送に80周期かかる。BSS0とBSS1の場合は16、そのビットの場合は64である。また、BSS0は値 1 を持ち、BSS1は値 0 を持つ。

クロック同期

受信機がアイドル状態にあるかBSS1を予期していたときに、受信した信号が1から0に変化すると、クロックは再同期される。

受信した信号に対して同期が行われるので、境界ビットに影響を及ぼす同期中の小さな送信エラーは、1周期を超えて同期をスキューする可能性がある。同期の間に88周期（BSS1が最後のバイトの8ビット。FESとTESが8周期にそれぞれ11ビット）あり、クロックドリフトは300周期当たり1より多くないので、ドリフトはクロックを歪ませる1周期を超えてはならない。受信中の小さな送信エラーは、境界ビットのみに影響する可能性がある。従って、最悪の場合でも、2つの中間ビットは正しいので、サンプリングされた値は正しい。

ここでは、同期中のエラー、クロックドリフトによるサイクルの喪失、伝送エラーなどの特に悪い場合の例を示す。

この例で発生したエラー

• 同期中のシングルビットエラーのため、同期が1周期遅れた。
• 受信機のクロックが送信側のクロックよりも遅かったので、受信機は1周期を逃した（下図でXとマークされている）。これは、最大許容クロックドリフトの限界のために、次の同期の前に再び起こることはない。
• 送信中のシングルビットエラーのため、結果の近くでビットが誤って受信された。

非常に多くのエラーにもかかわらず、通信は正しく受信される。

緑のセルはサンプリングされたビットである。最初のものを除く全てが、示されている送信フラグメントの1→0のエッジによって同期される。

送信データ	1								0								1								0								1
送信信号	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0	1	1
バス上の信号	1	1	1	1	1	1	1	1	0	1	0	0	0	0	0	0	1	1	1	1	1	1	1	1	0	0	0	0	0	0	1	0	1	1
受信信号	1	1	1	1	1	1	1	1	0	1	0	0	0	0	0	0	1	1	1	1	1	1	X	1	0	0	0	0	0	0	1	0	1	1
5-maj voted			1	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	1	1	1	1	X	1	1	1	0	0	0	0	0	0	0	1

開発ツール

FlexRayの開発やトラブルシューティングを行う際には、ハードウェア信号の検査が非常に重要である。ロジックアナライザとバスアナライザは、信号を収集、分析、デコード、保存して、高速波形を表示できるツールである。

FlexRayの将来

このプロトコルには、動作電圧レベルが低く、エッジが非対称であるなどの欠点があり、ネットワークの長さを長くする際に問題となる。帯域幅が集約的で安全性に欠けるアプリケーションでは、EthernetをFlexRayに置き換えることができる。

参考資料

• トヨタ!? 日産!? どうなるFlexRay普及への道 － ＠IT MONOist（2008年5月28日時点のアーカイブ）

関連項目

• ビークルバス
• エンジンコントロールユニット (ECU)
• エレクトロニックコントロールユニット (ECU)
• Byteflight
• Controller Area Network (CAN)
• Local Interconnect Network (LIN)
• Media Oriented Systems Transport (MOST)

外部リンク

• FlexRay Consortium - ウェイバックマシン（2012年10月25日アーカイブ分）
• JasPar
• FlexRay Overview Technical Overview of FlexRay by National Instruments
• FlexRay Specification (PDF)