次に、これまで紹介してきたスロットで送信されるフレームの具体的な構造や主な種類を紹介します。
フレームは「ヘッダー(Header)」「ペイロード(Payload)」「トレーラー(Trailer)」の3つのセグメントから構成されており、この構造はスタティックセグメントで送信されるフレーム(=スタティックフレーム)とダイナミックセグメントにて送信されるフレーム(=ダイナミックフレーム)で共通です。
それぞれのセグメントに格納されるデータは以下になります。
ペイロードの一部を特別な目的に使用するかどうかを示すビットとなり、その用途はスタティックフレームとダイナミックフレームで異なります。
スタティックフレームではペイロードセグメントの最初の0〜12バイトにネットワークマネジメントの情報を、ダイナミックフレームではペイロードセグメントの最初の2バイトにメッセージIDを定義できます。
ペイロードに使用できるデータを載せていないフレーム、つまり“データが使われない”フレームです。フレームのヘッダーセグメントのNullフレームインジケーターが「0」のとき、そのフレームはNullフレームとなり、ペイロードデータはすべて「0」となります。このフレームは、例えばサイクルマルチプレキシングの未使用スロットでの送信など、送るべきデータがないとき、またはコントローラでのフィルター条件に合致した場合、スタティックセグメントでのみ送信されます。
同期補正を実行する際に使用されるフレームです。
クラスタ全体の通信開始時に、同期を図るために使用するフレームです。
連載第1回で紹介したように、FlexRayノードにはホスト、通信コントローラ、バスドライバーといった複数の機能体が搭載されており、その中の通信コントローラにはプロトコルを制御する「プロトコルオペレーションコントロール(POC)」というメカニズムが備わっています。ここでは、このPOCの状態がどのように遷移するのかを簡単に説明します。
各プロセスとPOCとの関係は次の図で表せます(POCとアプリケーションの一部であるホストとの通信を行うインターフェイスをコントローラホストインターフェイス(CHI)といいます)。
このPOCが取り得る状態や遷移条件などの関連性を示した図が以下になります。通常、これらの状態はホストからCHIを経由して変更されますが、下図の(*)部分はPOC自身によって、(**)部分はPOCまたはCHIによって変更されます。
ここで懸案となるのが、“致命的なエラーが発生した状態”であるホールト(halt)に遷移する条件です。FlexRayではプロトコルの判断により通信を中止することはなく、エラーの種類やノーマルアクティブからノーマルパッシブに遷移する条件、ホールトに遷移する条件などはあくまでもアプリケーションで行われます。POCは実際のエラー処理を行います。
以上、今回はFlexRayの通信構造やタイミングなど、基本的な部分を簡単に説明しました。次回はエンコーディング/デコーディングや同期方法など、プロトコルの他項目を紹介します。ご期待ください。(次回に続く)
【 筆者紹介 】 ベクター・ジャパン株式会社 開発ツール部 チームリーダー 丹野 清嗣(たんの きよつぐ) ベクター・ジャパン 開発ツール部のチームリーダーとして、CAN、LIN、FlexRayなどの車載ネットワークに対応した開発ツールやハードウェア・インターフェイスの提供、サポート業務に従事している。 ▼ベクター・ジャパン http://www.vector-japan.co.jp/ ▼ベクターFlexRayソリューション http://www.vector.com/vj_flexray_solutions_jp.html |
Copyright © ITmedia, Inc. All Rights Reserved.