　フレームは「ヘッダー（Header）」「ペイロード（Payload）」「トレーラー（Trailer）」の3つのセグメントから構成されており、この構造はスタティックセグメントで送信されるフレーム（＝スタティックフレーム）とダイナミックセグメントにて送信されるフレーム（＝ダイナミックフレーム）で共通です。

図8　フレーム構造
（※ベクター・ジャパンの資料を基に作成）

　それぞれのセグメントに格納されるデータは以下になります。

ヘッダー（40ビット）

リザーブ（Reserved）（1ビット）：今後の拡張のための予約ビットです。通常「0」が設定されます。
ペイロードプリアンブルインジケーター（Payload Preamble Indicator）（1ビット）：ペイロードの一部を特別な目的に使用するかどうかを示します。
Nullフレームインジケーター（Null Frame Indicator）（1ビット）：フレームがNullフレームかどうかを示します。
同期フレームインジケーター（Sync Frame Indicator）（1ビット）：フレームが同期フレームかどうかを示します。
スタートアップフレームインジケーター（Startup Frame Indicator）（1ビット）：フレームがスタートアップフレームかどうかを示します。
フレームID（Identifier）（11ビット）：フレームIDを定義します。取り得る値は1～2047。0は無効です。
ペイロード長（Payload Length）（7ビット）：ペイロード部分の長さを単位「Word」で示します（※1Word＝バイト）。
ヘッダーCRC（Header CRC）（11ビット）：ヘッダー中の同期フレームインジケーター、スタートアップフレームインジケーター、フレームID、ペイロード長部分を保護するCRC（Cyclic Redundancy Check／巡回冗長検査）コードです。
サイクルカウント（Cycle Count）（6ビット）：サイクルカウンタ数を示します。取り得る値は0～63です。

ペイロード（0～2032ビット）

データが格納される部分です。最大127Words（＝254バイト）のデータを定義できます。

トレーラー（24ビット）

フレームCRC（Frame CRC）：ヘッダー全体とペイロードを保護するCRCです。

図9　ヘッダー 5ビット部分の詳細
（※ベクター・ジャパンの資料を基に作成）

ペイロードプリアンブルインジケーター

　ペイロードの一部を特別な目的に使用するかどうかを示すビットとなり、その用途はスタティックフレームとダイナミックフレームで異なります。

　スタティックフレームではペイロードセグメントの最初の0～12バイトにネットワークマネジメントの情報を、ダイナミックフレームではペイロードセグメントの最初の2バイトにメッセージIDを定義できます。

図10　ペイロードプリアンブルインジケーター
（※ベクター・ジャパンの資料を基に作成）

Nullフレーム

　ペイロードに使用できるデータを載せていないフレーム、つまり“データが使われない”フレームです。フレームのヘッダーセグメントのNullフレームインジケーターが「0」のとき、そのフレームはNullフレームとなり、ペイロードデータはすべて「0」となります。このフレームは、例えばサイクルマルチプレキシングの未使用スロットでの送信など、送るべきデータがないとき、またはコントローラでのフィルター条件に合致した場合、スタティックセグメントでのみ送信されます。

同期フレーム

　同期補正を実行する際に使用されるフレームです。

スタートアップフレーム

　クラスタ全体の通信開始時に、同期を図るために使用するフレームです。

4．通信コントローラの状態遷移（POC：Protocol Operation Control）

　連載第1回で紹介したように、FlexRayノードにはホスト、通信コントローラ、バスドライバーといった複数の機能体が搭載されており、その中の通信コントローラにはプロトコルを制御する「プロトコルオペレーションコントロール（POC）」というメカニズムが備わっています。ここでは、このPOCの状態がどのように遷移するのかを簡単に説明します。

　各プロセスとPOCとの関係は次の図で表せます（POCとアプリケーションの一部であるホストとの通信を行うインターフェイスをコントローラホストインターフェイス（CHI）といいます）。

図11　プロトコル制御の流れ
（※ベクター・ジャパンの資料を基に作成）

　このPOCが取り得る状態や遷移条件などの関連性を示した図が以下になります。通常、これらの状態はホストからCHIを経由して変更されますが、下図の（*）部分はPOC自身によって、（**）部分はPOCまたはCHIによって変更されます。

図12　POCの状態遷移
（※ベクター・ジャパンの資料を基に作成）

［1］初期コンフィグ（Default Config）：通信コントローラの初期状態です。

［2］コンフィグ（Config）：ホストによって通信に必要なすべてのパラメータが設定された状態です。

［3］レディ（Ready）：通信開始に向けた待機状態です。

［4］スタートアップ（Startup）：通信の準備を行う状態です。

［5］ノーマルアクティブ（Normal Active）：通常の通信を実行する状態です。

［6］ノーマルパッシブ（Normal Passive）：何らかのエラーが発生したときの一時的なエラー状態です。その後、問題がなければノーマルアクティブに戻ります。

［7］ホールト（Halt）：致命的なエラーが発生した場合に遷移する状態です。

［8］ウェイクアップ（Wakeup）：ウェイクアップ状態です。

　ここで懸案となるのが、“致命的なエラーが発生した状態”であるホールト（halt）に遷移する条件です。FlexRayではプロトコルの判断により通信を中止することはなく、エラーの種類やノーマルアクティブからノーマルパッシブに遷移する条件、ホールトに遷移する条件などはあくまでもアプリケーションで行われます。POCは実際のエラー処理を行います。

　以上、今回はFlexRayの通信構造やタイミングなど、基本的な部分を簡単に説明しました。次回はエンコーディング／デコーディングや同期方法など、プロトコルの他項目を紹介します。ご期待ください。（次回に続く）

【筆者紹介】
ベクター・ジャパン株式会社開発ツール部チームリーダー
丹野清嗣（たんのきよつぐ）
ベクター・ジャパン開発ツール部のチームリーダーとして、CAN、LIN、FlexRayなどの車載ネットワークに対応した開発ツールやハードウェア・インターフェイスの提供、サポート業務に従事している。
▼ベクター・ジャパン
http://www.vector-japan.co.jp/
▼ベクターFlexRayソリューション
http://www.vector.com/vj_flexray_solutions_jp.html