Flex RayのFAQ
FlexRayマイコンに関してのFAQとして、ネットワーク設計時におけるFAQを掲載しております。
- FlexRay ASSP FAQ
- FlexRayスターターキット(MB2005-01) FAQ
ネットワーク設計時
- ネットワークマネージメントベクタ（NMVector)について
- 送信完了ビットについて
- CCの断線検知について
- 受信バッファと受信データについて
- DTSの整合チェックについて
- Sync Frame Overflow発生時のふるまい
- Wakeupノードについて
- 同時WUP信号送信について
- ヘッダCRCについて
- Cold Start Up失敗について
- CASについて
- gListenNoiseのパラメータ単位について
1. ネットワークマネージメントベクタ（NMVector)について
Q1ネットワークマネージメントベクタは、サイクルの最後で“0”にリセットされますが、この時にホストがこのレジスタをロックしていた場合はどのような動作になりますか?
回答
ネットワークマネージメントベクタのステータスレジスタは、ホストによるロックは行いません。
動作は、更新用のレジスタと、ホスト表示用のレジスタの2種（ダブルバッファ）を有しています。更新用レジスタは、サイクル最後に“0”リセットされ、次のサイクルでネットワークベクトルを受信すると更新用レジスタにOR条件でライトしていきます。次のサイクルの最後にホスト表示用レジスタに更新用レジスタの内容をコピーします。
よって、ホスト表示用レジスタには、1つ前のサイクルのネットワークマネージメントベクタ情報が表示されており、必要であるならばサイクル内で処理（リードなど）を終わらせる必要があります。
Q2 ネットワークマネージメントベクタは、ORで書き込まれる仕様になっていますが、これはどのような使用を想定していますか？
回答
各ノードに対して、このネットワークマネージメントベクタのそれぞれ異なったビット位置に割り当てを行います。各ノードは、この割り当てられたビット位置にステータス情報（エラーなど）を添加しStatic Frameを送信します。
受信ノードでは、それぞれ受信したネットワークマネージメントベクタ情報をORすることにより全ノードの状態を容易に識別することができます。
また、1サイクル分のネットワークマネージメントベクタ情報のみで足らない場合は、サイクル単位に通知内容を分ければ取得可能となります。
2. 送信完了ビットについて
Q1 CCが送信完了ビットを立て、送信の完了を Hostに通知するが、その条件は何ですか?
回答
メッセージ毎に制御するMBIフラグ（メッセージバッファの割込みイネーブル）がイネーブル、且つ送信が完了したときに設定されます。
送信完了のイベントは、CC-BD間の送信イネーブルTxENがイネーブルからディセーブル（0→1）になったときです。
MBIフラグは、メッセージ毎に、ヘッダ・セクション情報をライトするときに設定可能です。
3. CCの断線検知について
Q1 CC-BD間のTxDが断線している場合など、送信できなかったことをCCは検知できますか? 同様に、BusがショートしていたときはCCはそれを検知できますか?
回答
TxDが断線している際、BUSに“L”レベルが出力された場合は、受信側ノードでシンタックスエラー（プロトコルエラー）を検出します。BUSに“H”レベルが出力された場合は、IDLEと同等なので受信側でエラー検出することができません。このような場合、BGが搭載されていなければサイクルに対して各ノードを割り当てSymbolWindowにMTSを送信し受信ノードで受信できたかチェックを行うなどの処理を行います。または、BUSを2重化（冗長構成）にしAch、Bchデータの比較を行いチェックを行います。
BUSショート（断線）が発生した場合は、受信ノードにおいてシンタックスエラー（プロトコルエラー）を検出します。
これらエラー検出状況をネットワークマネージメントを用いてどのノードが故障しているのか確認しネットワークを制御する事が可能です。
4. 受信バッファと受信データについて
Q1 1つのスロットで複数フレームを受信した場合、受信バッファにどの受信データが格納されていますか?
回答
有効なフレームと、無効なフレームとが混在する場合があります。
- 受信データ表（ PDF PDF 64KB）
5. DTSの整合チェックについて
Q1 DTSの整合性チェック（有無や最小値を上回っているか）は行っていますか？
回答
DTSの整合性チェック（有無や最小値を上回っているか）は、行っています。
6. Sync Frame Overflow発生時のふるまい
Q1 Sync Frame Overflowが発生するとHostはその情報を取得できますが、通信は継続されます。これはどのような使用を想定していますか？
回答
同期フレームのSync Frame Overflowイベントは、以下の理由により、深刻なエラーとは考えて処理されておりませんので、通信は継続されます。
[理由]
基本的に、FlexRayは決められた同期ノード数以下で運用しなければなりません。しかしながら、この決められた同期ノード数以上の同期フレームを受信したとしてもフォルト・トレラント・ミッドポイント・アリゴリズム（FTA/FTM）に基づき同期処理が行われます。もし、異常な同期フレームが入力されたとしてもFTA/FTMによって排除されますので同期に関して深刻なエラーと考えてないと考えます。
次のような使用方法が想定されます。
ネットワーク設定時に、同期ノードの最大数はレジスタによって設定可能なパラメータです。最大数を不正な値（同期ノード数以下の値）にした場合、Sync Frame Overflowを検出します。このとき、適正な同期ノード最大数を設定すればよい事になります。
また、ネットワーク設定後（システムイン後）の場合、（後付などの）予期しない同期ノードが統合（参加）した時、検出が可能です。この時のクロック同期は設定された同期ノード最大数において同期アルゴリズムに基づき維持されます。
このようにしてネットワーク設定の異常を検出するのに用いる事が想定され、適正なパラメータへの修正を導く事ができます。
また、BUS異常による間違った同期フレームの受信は、ヘッダCRCにより保護されていますので発生しないと考えられます。
7.Wakeupノードについて
Q1.Wakeupノードは必ずColdstartupノードである必要がありますか。また、Coldstartupノードは必ずWUP(WakeUp Patten)を送信しなければならないのですか？
回答
Coldstartrpノード自体が、WUPの受信にて起動する場合もあり得るので、Coldstart upノードがWUPを必ず送信しなければならないということはありません。また、WakeupノードとColdstartupノードが一致していなければならないということはありません。（一致しても構いません）
8. 同時WUP信号送信について
Q1. 複数のWake upノードから同時にWUP(Wake Up Patten)が送信された場合、どうなりますか？ 例えば、Wake Up Signal送信成功を検出できずに、Wakeup Listen -> Wakeup Send -> Wakeup Detect -> Wakeup Readyのステートで永久にループしてしまいませんか？
回答
クラスタ構成を考慮した場合、Wakeupノード自身がWUP送信成功を検出できないことが起こる可能性はあります。ただし、他のWUP受信ノードは正常にWUPを受信し、通信を開始することが出来ます。 その際、もしWakeUpノードがWake upステータス内のサブステートの遷移を繰り返していたとしても、Wakerp Listen ステートにてクラスタ内の通信開始を認識して、Wake upステートから抜けることが出来ます。
9.ヘッダCRCについて
Q1. ヘッダCRCはソフトウェアにより処理することになっていますが、毎回起動時にソフトウェア処理にて計算するのですか？
回答
ヘッダCRCは、Slot毎に決まる固定値であり、通常ツールなどを用いて予め計算されています。ソフトウェアは、初期化時にヘッダCRCのテーブルなどから固定データであるヘッダCRCをメッセージヘッダ情報の1つとしてMessage RAMへ設定するのみとなります。
10. Cold Start Up失敗について
Q1. Cold Start Upノードが、gColdStartAttemptsの分だけ、ColdstartをリトライしてもColdstartupに失敗した場合どうなるのですか？
回答
失敗したColdstartupノードは、フォローイングスタートアップノードとして待機し、他のリーディングスタートアップノードが現れると一緒にスタートアップに参加します。
11.CASについて
Q1. CAS（Collision Avoidance Symbol）関連のパラメータgListenNoiseにて定義される期間を超えてもCASが正常受信できない場合はどうなりますか？
回答
gColdStartAttemptsの定義によるColdstartup失敗時と同様の動作となります。
12.gListenNoiseのパラメータ単位について
Q1. gListenNoiseのパラメータの単位は何ですか？
回答
gListenNoiseは、単位が無く、パラメータpdListenTimeoutの乗数として使用されます。
Flex RayのFAQ
FlexRayマイコンに関してのFAQとして、FlexRayパラメータ設定時におけるFAQを掲載しております。
- FlexRay ASSP FAQ
- FlexRayスターターキット (MB2005-01) FAQ
パラメータ設定時
- プロトコルパラメータ “pClusterDriftDamping”，“pdMaxDrift”などで使用されている“Drift”について
- プロトコルパラメータ“gdNIT”値の算出について
- Primary TRPとSecondary TRPの計算式について
1. プロトコルパラメータ “pClusterDriftDamping”，“pdMaxDrift”などで使用されている"Drift"について
Q1 プロトコルパラメータ “pClusterDriftDamping”，“pdMaxDrift”などで使用されている“Drift”とはどのようなものですか?
また、“pClusterDriftDamping”とは何をするための値ですか?
回答
Driftとは、異なるノード間の非同期クロックによる“ずれ（横滑り）”です。例えば、あるノードの周波数偏差は0ppmで、もう一方のノードの周波数偏差が1500ppmである場合に、位相がずれていきます。“pdMaxDrift”は、この位相のずれで発生する最大値です。
“pClusterDriftDamping”は、クロック同期のレート補正に用いられるパラメータで、ドリフトによってダンピングした値を補正するローカルなパラメータです。
2. プロトコルパラメータ“gdNIT”値の算出について
Q1 プロトコルでは“gdNIT”は2～767の範囲で使用することになっていますが、実際は同期の補正値の計算のための時間、オフセット補正のための時間が必要となり、プロトコルで規定されている計算式ではなく、CC独自の計算式が存在すると考えていますが、そういった計算式は存在しますか?
回答
以下の式で求めることができます。
gdNIT ≧ オフセット演算期間 + オフセット補正のための時間
オフセット演算期間 ： 半導体メーカー（マクロ）依存
オフセット補正の時間 ： オフセット補正最大値÷1MT当りの補正限界量
オフセット補正の時間は、ネットワーク設計の際に計算で求めることができます。オフセット演算期間は、オフセット補正値を演算する期間として1MT （1MT≧30SCLK）とします。
3. Primary TRPとSecondary TRPの計算式について
Q1 Primary TRPとSecondary TRPは、次の図の様に表せると認識しています。
これより、次の計算式を使用することが可能ですか?
pDecodingCorrection = gMacroInitialOffset - pMicroInitialOffset[A] - gActionPointOffset - pDelayCompensation[A]
もし、可能とするとなぜ自動計算をせずにレジスタを持っているのですか？
回答
ハードウェアの処理は、実行中に値の更新が必要とされるパラメータのみを演算します。逆に固定値で実行中に値の更新の必要がない（ハードウェア処理における効果が少ない）パラメータは、レジスタ設定となります。
また、上に示す計算式における、gMacroInitialOffsetおよびpMicroInitialOffsetのパラメータは、FlexRayプロトコル仕様Ver2.1よりA、B ch個別のパラメータとなっています。スタートアップ処理はいずれか一方のchで行う為、ch毎のネットワーク条件（バス長、スタブ数など）によって
Offset値は異なります。
一方、同期後は、A、B chの測定値を合わせて同期処理される為、ch毎のネットワーク条件ではなくなります。
つまり、スタートアップ時と同期後では異なる為、上に示す計算式を使用せず別のパラメータとして扱います。