FlexRay
すべての通信はフレーム形式で送信される。メッセージは、次のようにパックされたバイト { x 0 , x 1 , ... , x m − 1 } {\displaystyle \{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 を持つ。
CANの利用においてはボッシュ社の特許独占問題や今後の機能拡張・性能向上の余地がなく代替技術に移行したいが、日本の自動車メーカーからすればFlexRayはCANに比べるとトランシーバICで2-3倍にコスト上昇が見込まれ、ソフトウェア開発もCANより工数が増え、ハーネスも同等レベルのコストを維持できるか疑問とされ、総体としてはかなりのコスト高が予想されるので簡単にはCANから移行できない。こういった事情は鶏と卵の関係にも似て、実車に採用されないと電子部品の価格は下がらず、電子部品の価格が下がらないと実車に採用できないというジレンマに陥っている。
日本のメーカー側ではJasPar版FlexRayを策定し、その実績を持って車載ソフトウェアの標準化団体であるAUTOSAR内に日本の自動車産業界の立場を確立する構想であったが、日本版FlexRayの先行きすらも危ぶまれる状況になっている。AUTOSARでは自動車用MCUの内蔵ソフトウェアをモジュール化/汎用化することで再利用を容易にする規格を策定中であるが、開発工数削減が期待出来る反面、マイコン(MCU)に要求される能力が高くなるため高価となり、トータルではコスト高となることを危惧して日本側ではモジュール化に反対の立場である。