FlexRayは主に安全性を非常に重視しタイムクリティカルな車載アプリケーションに使用されている。FlexRayクラスターの編成された通信をStatic通信サイクルに、FlexRayノードにtime slotを連結する事で、スムーズな決定論的通信フローを実現している。ペースから外れたFlexRayノードは本来割り当てられていないtime slotで不正送信する事により調和を乱す可能性がある。これを防止するのがいわゆるBus Guardianのタスクになる。

ローカルなBus Guardianのコンセプトでは、Bus Guardian(BG)は各FlexRayトランシーバーに割り当てられる。通信スケジュールに準拠している場合のみFlexRayトランシーバーがバス上にFlexRayコントローラーから受け取ったデータを配置する事が出来る。

データはStatic Segmentの予約済みスロットに配置される。Dynamic Segment内ではイベントが発生した場合にのみFlexRayノードが送信するために保護が出来ない。FlexRayノードがDynamic Segmentで完全に送信許可される、または完全に送信を禁止する事が可能になる。

その機能を実装するには、Bus Guardianが通信スケジュールとFlexRayクラスターの時刻を知る必要がある。理想的にはBus GuardianはFlexRayコントローラーによって生成されたローカルなtime baseに依存せず、代わりにFlexRayコントローラーから独立したtime baseを生成する。これは、time slot自体のチェックに加えてFlexRayコントローラーのクロックの全エラーが検出されるため、Bus GuardianによりFlexRayノードがそのtime slotだけで送信出来る事を保証出来る唯一の方法となる。

しかし、これはBus GuardianはFlexRayコントローラーとほぼ同じ機能を備えなければならない事を意味し、Bus Guardianはコントローラーと同様の複雑さになり結果としてFlexRay通信のコストを増加させる結果になる。Bus Guardianはどのように時間を決定するかにも関わらず、これまでローカルなBus Guardianは実装されていない。関連仕様のノードのローカルなBus Guardianの仕様はバージョン2.0.9で、暫定的なものになる。

中央Bus Guardian仕様のバージョン2.0.9にも同様に適用される。状態は暫定的なものであり、中央Bus Guardianの実装は未だ存在しない。ここのコンセプトにはアクティブスターカプラーに配置されるBus Guardianが含まれる。通信サイクル内で中央Bus Guardianは通信スケジュールで指定され送信する権限を持つFlexRayノードに接続された終端の通信ブランチを常にアクティブにする。これで信号の衝突を防ぐための方法を提供している。


最終更新日時: 2018年 11月 29日(木曜日) 09:55