ネットワーク設計時 | パラメータ設定時 |
Flex RayのFAQ
FlexRayマイコンに関してのFAQとして、ネットワーク設計時における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の乗数として使用されます。
