まず冒頭でちょっと訂正を。147回目で、FlexRay consortiumのPremium Associate membersに国内4社が加盟していると書いたが、実際はデンソー、ホンダ、マツダ、日産、トヨタの5社の間違いであった。お詫びして訂正したい。

フィールドバスの色々(その11)FlexRay(その3)

さて、前回5層階層のプロトコルと書いたが、これは厳密には「5層の階層構造と間を繋ぐプロトコル」というべきだろう。FlexRayの場合も、ネットワークに接続する各ユニットをNodeと呼ぶが、このNoedは、

• Host
• Host-Controller I/F
• Communication Controller(CC)
• Bus Driver(BD)

の4つから構成される。図1には他にBus GuardianとかPower Supplyといったものも含まれているが、これはおいおい説明することにしたい。またNodeの外側の領域をTopologyとしており、Topologyまで含めた5つで階層を構成する形だ。この中で通常あまり考えられないのは、Topologyが別扱いになっていることだ。CANを含め、普通バスの接続はあまり自由度はない。ディジーチェーンならディジーチェーンのみ、シェアードバスのスタブ方式ならそれだけ、といったやり方が普通である。多少なりとも自由度があるのは、途中にスイッチを噛ませられるPCI-Expressと、いわゆるEthernetであるが、実のところFlexRayはこのEthernetにかなり近いTopologyの自由度がある。

例えば、Specification(FlexRay Communications System Protocol Specification Version 2.1 Revision A)にはいくつかのサンプルが出ている。まず最初はPassive bus(図2)やActive star(図3)の形式だ。冗長性を確保するという目的で、各Nodeから2本づつ接続が出せる(1本でも構わない)わけだが、これを接続するのにShared Bus式のTopologyと、Star型のTopologyの両方をサポートしているのがまず面白いところだ。更にStar型では、Hub同士を接続する事も出来る。Ethernetで言えばスタッカブルHubというか、Hubのカスケード接続というか、そうした構図であるが(図4)、更にStarの二重化も可能である(図5)。これだけでも結構柔軟性がありそうだが、更に面白いのは両者の混在が可能な事だ。

図6のケースでは、性能面でのボトルネックの心配が無いノード(Node E～G)はShared Busで、その他のノードはStarでそれぞれ接続するという構図だ。あるいはDual Channelにして、通常はStarを使うが、Starに障害が発生したらShared Busに切り替える(図7)なんて接続も可能である。

Ethernetの場合でも、こうした構成を取る事は不可能ではないが、そもそも今時Shared Busを使うケースは非常に稀になってきているし、自分の送り出したパケットがループバックしないような設定が必要になってくる(これをEthernetのレベルではできないのが、TCP/IP系の問題とはいえる)。一方FlexRayでは積極的にこうしたTopologyを薦めているとも言えるわけで、このあたりに両者の違いを見て取る事ができる。ちなみに冗長性に関し、FlexRayのRequirement Specificationでは各NodeからN本のChannelが出せる事を想定している。図2～6は1ないし2本のチャネルを前提に記述したが、3本とか4本の可能性もありうるわけだ。とはいえ、無尽蔵に増やせば抗堪性が上がるというものではない(部品点数が増えて、MTBF自体はむしろ短くなる)し、そもそもチャネル当りの故障率はかなり低めに目標を設定されるものだから、Six-Nine(99.9999%:NASAが安全基準として設けている稼働率の目標。例えばアクセルとかブレーキ、ハンドル操作といった重要な制御系にはこれを使われることが多い)であっても(構成や部品によるが)2重であれば十分、というのが一般的な考え方の様だ。

ちなみにPassive型では、チャネルの最大長は24m、ノード数は22、ノード最小間隔は150mmと設定されている。一方Active Star型の場合、チャネル最大長は24mと変わらないが、ノード数とか最小間隔は明確に定義されていない。こちらはむしろその他の電気的特性が支配的だから、というのが理由である(続く)。