　FlexRayに対応したECUを開発する場合、もちろん半導体チップや電子部品などのハードウエアは、FlexRayに準拠した製品にする必要がある（別掲記事『FlexRay対応のノイズ対策部品』を参照）。しかし、CANと比べた場合に、最も大きな変更を要求されるのは車載ソフトウエアである。また、ソフトウエアの開発ツールに加え、実機レベルでソフトウエアの機能を検証するための環境の整備も課題の1つとなる。

■パラメータ数はCANの10倍以上

　FlexRayの通信サイクルは、スタティックセグメント、ダイナミックセグメント、シンボルウィンドウ、ネットワークアイドルタイム（NIT）の4つのセグメントから構成されている。スタティックセグメントでは、FlexRayの特徴である同期とりを行うデータを送信し、ダイナミックセグメントでは、 CANと同じ非同期のデータを送信する。シンボルウインドウでは、同期データの送信を保証するBGの動作を確認し、NITではクロック補正を行う。

　これに対して、ほぼダイナミックセグメントだけで構成されているのがCANの通信であると考えてよい。

　CANは、非同期のプロトコルであるため、ソフトウエア開発に必要なパラメータは通信速度（ボーレート）をはじめ数個に限られる。しかし、同期プロトコルであるFlexRayでは、CANの10倍以上となる60以上のパラメータを設定する必要がある（FR2.1aの場合）。

図2　Vector社のFlexRay対応ツール群（提供：ベクター・ジャパン）　Vector社は、車載LAN開発のV字プロセスをこの図のように定義している。そして、このV字プロセスの全般にわたり、FlexRayに対応するツール群を供給している。その中核となるデータベースのフォーマットがFIBEXである。なお、「FRstress」は妨害信号の発生ツール、「CANape/XCP on FlexRay」はキャリブレーションツールである。

　ドイツVector Informatik社は、「CANoe」をはじめとした車載LAN向けソフトウエア開発ツールで高い実績を持つ。FlexRayに対しては、2004年に発表したCANoeのバージョン4.1でFlexRayを扱えるオプション「CANoe.FlexRay」を投入。現在までに、車載ソフトウエア開発の各プロセス向けのFlexRay対応ツール群を供給している（図2）。日本法人ベクター･ジャパンの開発ツール部でチームリーダーを務める丹野清嗣氏は、「FlexRayのような複雑なプロトコルを扱う場合には、CANよりもさらに開発ツールを活用する場面が増えてくる。当社は、CAN用の開発ツールとして1996年にCANoeを発表し、それ以来ユーザーからのさまざまな要望を組み込んでCANoeを進化させてきた。CANoe.FlexRayにも、このノウハウを組み込んでおり、CANベースの開発を行ってきた技術者が違和感を持つことなく、FlexRayベースの開発に移行できるようなツールに仕上げた」と語る。

　Vector社が2007年に発表したCANoeのバージョン6.1では、ユーザーからの要望に応えて「非同期モード」を搭載した。前述したように、FlexRayの車載ソフトウエアには、同期通信を行うための大量のパラメータを設定する必要がある。つまり、スタンドアロンの車載ソフトウエアの動作を確認する場合でさえも、この大量のパラメータを設定しなければデータ送信が行えないのである。それに対し、非同期モードを使えば、ボーレートを設定するだけで、車載ソフトウエアの動作をモニタリングできる。また、CANoeの最新バージョンである7.1では、FlexRayのシステム記述に必要なデータベースファイル「FIBEX」を編集/新規作成できる「FIBEX Explorer pro」を新機能として追加した。「当社は、自動車メーカーの技術者が車載ネットワークの設計を行うためのツールとして『DaVinci Network Designer』を提供している。このツールを使えばFIBEXファイルを扱うことができる。しかし、同ファイルに少し手を加えたいだけのティア1以下のサプライヤからすれば、ネットワーク設計までできるような大規模なツールは必要ない。そこで、FlexRay開発でティア1以下のサプライヤが最も利用することになるCANoeに、FIBEXの編集機能を追加することにした」（丹野氏）という。

　なお、FIBEX Explorer proは、単体販売も行う予定である。

■異なる物理層への対応

　車載ソフトウエアを開発する上では、その動作を確認するための検証プロセスも重要である。FlexRayとCANは、物理層の仕様が異なるため、その検証プロセスにも異なるツールが必要になる。

図3　YDCの検証ツールの利用例（提供：YDC）　

　横河ディジタルコンピュータ（以下、YDC）は、FlexRay対応の検証ツールを提供している。FlexRay対応のマイコンを搭載した評価ボードや、プロトコルバスアナライザ「GT300」、擬似データ送信ツール「GT350」、妨害信号発生ツール「GT360-S02」などで、これらはJasPar の活動にも利用されている（図3）。

　YDCの自動車機器事業部開発センタでセンタ長を務める金田浩氏は、JasParの設立当初からツール開発に携わるワーキンググループに参加しており、 FlexRayネットワーク上に流れるデータをロギングする際のフォーマットの共通化を担当した。「GT360-S02は、FlexRay通信における最小単位である『gdBit』に対して、1gdBitの1/8という分解能でビット破壊（妨害信号の発生）を行えることから、コンフォーマンステストの仕様策定に貢献した」（同氏）という。

　また、同社は、ECUのモニタリング/ロギング用に、マイコンの内蔵RAMのデータをリアルタイムに抽出する計測ユニット「RAMScope」を展開している。ECUとの接続プローブを変更するだけで異なるマイコンに対応できることから、FlexRay対応のマイコンを採用したECUについても、CANの場合と同じように利用できるとしている。

　金田氏は、「今後、FlexRay開発は、これまでに行われてきた机上での検討の段階から、実車へ搭載する段階に移る」と見ている。YDCが現在提供している検証ツールは、机上での運用を前提としたパソコンベースの製品だが、今後はパソコンなしでも利用できるスタンドアロンタイプの製品を投入する予定である。

FlexRay対応のノイズ対策部品

　FlexRayに準拠した半導体の開発が急速に進んでいる。FlexRay対応の通信コントローラを内蔵したマイコンについては、国内外の有力車載半導体メーカーが販売を開始している。

　一方、トランシーバについては、オランダNXP Semicoductors社、オーストリアaustriamicrosystems社、NECエレクトロニクスの3社だけが、現時点で提供を行っているメーカーである。また、ルネサステクノロジも開発を進めており、自社で半導体生産ラインを持つティア1サプライヤのドイツRobert Bosch社も、開発を検討しているという。

　半導体のみならず、FlexRayに対応した電子部品も必要になる。その代表となるのがコモンモードチョークコイルである。CANやFlexRayなどの車載LAN規格では、耐ノイズ性を向上するために、2本の信号線を使った差動信号により通信を行う。しかし、同相成分（コモンモード）のノイズに対しては、コモンモードチョークコイルを回路に組み込むなどの対応が必要になる。

写真A　村田製作所の「DLW435H101」　

　村田製作所は、CANとFlexRayに対応するコモンモードチョークコイルを製品化している。同社がベースとしているのは、USB、LVDS（Low Voltage Differential Signaling）、HDMI（High-Definition Multimedia Interface）など民生品の差動伝送インターフェース向けコモンモードチョークコイルの技術だ。同社EMI事業部商品開発部開発2課の課長を務める東貴博氏は、「民生品向けのコモンモードチョークコイルは、外部回路へのノイズの伝播を防ぐことを目的として利用されている。 CANやFlexRayなどの車載向けでは、ノイズ環境が厳しいことを考慮して、外部回路から伝播してくるノイズを遮断する役割も必要になる」と語る。

　CAN対応のコモンモードチョークコイルの場合、コモンモードインダクタンスは51μHである。これに対してFlexRay対応の製品には、さらに厳しい100μHを要求される。村田製作所が開発した「DLW435H101」（写真A）は、この要求を満たすとともに、ほかの信号線から伝播してくるノイズである、1MHz～5MHz程度の低い周波数のイミュニティに対する耐性を向上している。

前のページへ 1|2|3|4 　　　　　　