トップ セミナー情報 バックナンバー 媒体概要 無料読者登録 お問い合わせ 技術調査会
トップ > バックナンバー > アジレントの車載ネットワーク測定ソリューション

特別寄稿１　カーエレクトロニクス計測技術

アジレントの車載ネットワーク測定ソリューション


アジレント・テクノロジー株式会社

　電子計測本部マーケット・ディベロップメント・マネージャ　佐藤　利宏

近年、車載用システムの電子化に伴い、電気信号を取り扱う機会が増えている。さらに加えてシステム通信の効率の向上、コストの削減を実現するために、車載用システムには、さまざまなシリアル・バス通信プロトコルが採用されている。
　I2CやSPIプロトコルは、電子制御装置（ECU）内でのチップ間通信によく用いられている。アンチロック・ブレーキ、エアバック、エンジン制御、GPSナビゲーションなどのさまざまな車載用サブシステム間のシリアル通信用として、CAN、LIN、MOSTプロトコルが今日最も一般的になっている。長時間の通信では、イグニション・システムによる信号干渉やランダム・ノイズなどの自動車によく見られる過酷な環境が原因で、シグナル・インテグリティの問題が生じることがよく見られる。このため、クリティカルな通信サイクル中にエラーが生じることもある。
　さらに加えて、車載エレクトロニクスの複雑化や、ネットワークの帯域幅の効率化を求められているものの、現在の多くのデザイン・プロセスには、バスの負荷による遅延を測定／制御できる信頼性の高い手法がない。このために、CANではシステム動作の信頼性を十分に確保するために、帯域幅利用率を例えば50%以下に制限してシステムを設計・構築しているケースもある。
　最初にエンジニアが直面するケースが多いシグナル・インテグリティの問題としてCANベースの車載用システムのシグナル・インテグリティの代表的なデバッグ方法を紹介する。
　今回の事例では、プロトタイプのオートワイパ・システムの回路／プロトコルの動作確認を行っている。回路内のCAN差動信号はアナログ・センサからのデータをECUにデジタル伝送するために使用しており、CAN信号とリモート・アナログ入力センサの出力振幅を繰り返し捕捉／測定している。同時に、ECU内の複数のSPI制御信号も捕捉している。
　まず、プロトタイプのオートワイパ・システムの回路／プロトコルが正常に動作するか検証した。図1は、MSO6104Aで捕捉したプロトタイプ・システムのアナログ信号とデジタル信号を時間相関表示したものである。チャネル1の波形（上側の黄色のトレース）は、ワイパ・システムなどのさまざまなリモート・サブシステムと通信している差動CANバス信号である。チャネル2の波形（中央の緑色のトレース）は、フロントガラスにあたっている雨や雪の量を光で検出するリモート・レイン・センサのアナログ出力信号レベルを示している。CLOCK、DATA、CS、INTERRUPT信号などの、ECU内のSPI 制御信号（オシロスコープのディスプレイの下部近くに示されている青色のトレース）も時間相関表示している。これらはすべて、MSOの16個のロジック・タイミング・チャネルの一部を使って捕捉されたものである。このオシロスコープのディスプレイの一番下に示されている多色のバス・トレースは、CANデータ・チャネル（この場合は、チャネル1）のデコードされた情報を時間相関表示したものである。
　この回路では、リモート・アナログ・センサの瞬時出力振幅が、A/Dコンバータ（ADC）を使ってデジタル値に変換され、特定のデータ・フレーム（ID=07Fh）の単一データ・バイトとしてECU にシリアル転送される。このセンサの出力の繰り返し転送を捕捉して、プロトタイプの正常動作を検証するために、CANデータ・フレームID=07FhでトリガをかけてCANの通信内容とセンサの出力電圧をモニタすることとした。

実験室では問題がなかったはずなのに、実際の自動車に組み込むとオートワイパーの動作に不具合がみられるようになった。その波形が図1である。CANのデータ・フレームID=07Fhの通信をしばらくモニタすることで、入力されたアナログ・センサの出力値とECUが受け取るはずのデータの値とが異なる不具合があることが特定できた。

 

 

 

 

 

図1　入力されたアナログ・センサの出力値とECUが受け取るはずのデータの値とが異なる不具合があることを特定

 

 


　このように書いてしまうと、読者の方には非常に簡単に問題点（センサの出力値とCANへの通信内容が異なっていたこと）が特定できたように見えるが、実際には使用する機器によってはここまでの工数がまるで異なることに注意が必要である。
　今回、CANの通信の特定個所（データ・フレームID=07Fh）でトリガを掛けながら、CANの通信内容とセンサの出力電圧をリアルタイムでモニタしつづけたわけだが、オシロスコープの処理速度により、不具合を発見するまでの時間が大きく異なる。
　通常、シリアル通信のデコード機能をもつオシロスコープはソフトウエアによるデコード処理を行っているため、トリガ条件発生後も一定の処理時間を掛けてようやく波形・デコード結果を表示する。めったに発生しない不具合の場合、処理時間（デッドタイム）の中に埋もれてしまう確率が高く、不具合の発見・特定までに相応の時間がかかってしまう。これに対してアジレントでは、デバッグ時のリアルタイム性を優先するためシリアル通信のデコード機能をハードウエアで実装している。このことにより、当社のInfiniiVisionシリーズではシリアル・デコードを使用している時でも波形の更新速度が高い水準で保たれ、トリガの発生条件よりも十分に早い波形・デコード表示速度を実現していた。
　不具合の発生に必要な測定器に求められる機能としてはいくつかあるが、信号の波形品質評価においては、波形の再現性もさることながら、波形の更新速度（リアルタイム性）は重要な項目となる。

また、不具合を発見した次にエンジニアが行うことは不具合の発生原因や他の問題点との相関性の特定である。先ほどは特定の通信に対するトリガをオシロスコープで設定し、CANの通信内容とセンサ出力とをモニタして不具合を発見した。次のステップとして不具合に対するトリガを設定し、前後の事象・信号との相関を探すこととなる。当社のオシロスコープの場合、特定のデータ・フレームのIDへのトリガが掛けられることは前述したが、他にも「SOF（Start of Frame）」「Remote Frame ID」「Remote or Data Frame ID」「Error Frame」「All Errors」「Acknowledge Error」「Overload Frame」にもトリガを掛けることも可能である。不具合（Error）が発生する条件でトリガを掛けることで、より迅速に不具合の発生原因や他の問題点との相関が可能になる。
　また、CANだけではなく、次世代車載ネットワークとして仕様が検討されているFlexRayに関しても、FlexRayコンソーシアムのメンバでもあるアジレントはオシロスコープでのトリガおよびデコード機能を提供している。FlexRayでもCANと同様にハードウエアによるFlexRay通信のリアルタイム・デコードを実現している他、プロトコル・アナライザ（Agilent VPT1000シリーズ）を併用することで、当社のみが様々なトリガ機能を唯一オシロスコープで実現している。
　具体的にFlexRayでは、従来のCANやLINのようなイベントトリガ方式だけではなく、タイムトリガ方式が採用されているため、従来のオシロスコープで実現していたようなトリガでは不十分なケースがある。たとえば、特定のスロットの無通信状態の検出や、全く通信が発生して特定のスロット（時間）へのトリガなどは、オシロスコープだけで実現することはできない。さらに加えて、ソフトウエアによるデコードを実現しているオシロスコープでは、パケットのデコード処理が重たくなるために、トリガをリアルタイムに実行させることが難しくなる。その結果トリガ条件の捕捉ですら膨大な時間がかかってしまう。当社のオシロスコープではプロトコル・アナライザとのシームレスな連動により、リアルタイムに迫る高速なハードウエア・ベース・デコードを実現し、『問題を発見する』というデバッグの中でも最も重要な作業にその真価を発揮する（写真1）。

 

 

 

写真1　プロトコル・アナライザとのシームレスな連動により、リアルタイムに迫る高速なハードウェア・ベース・デコードを実現

 

 


※FlexRayに設定可能なトリガは下記の通りです。（2008年4月現在）
　Flame Trigger: Flame Type（SUP, ~SUP, SYNC, ~SYNC, NULL, ~NULL, NORM, All), Frame ID(0-2047, all), Cycle(0-63),  Cycle　reputation(1,2,4,8,16,32,64)
　Time Trigger: Segment type(SS, DS, Symbol, NIT)
　Error Trigger: All, Code error, TSSV, Header CRC error, Frame CRC error, Frame end Sequence Error, Boundary violation, Network idle time violation, Slot overbooked error, Null frame error, Sync or startup error, Frame ID error, Cycle count error, Staticpayload length error


　また、車載ネットワークの設計・検証を行うにあたり、物理層による測定はもちろん重要であるが、さらに上位のレイヤによるネットワークの検証作業には、オシロスコープだけではなく、プロトコル・アナライザなどの専用モニタ・ツールが用意されている（写真2）。

 

 

 

写真2　オシロスコープだけでなく、プロトコル・アナライザ等の専用モニタ・ツールが必要

 

 

当社ではCANやLIN、FlexRay用の各測定器を提供しているが、特に『測定器』として時間情報、つまり各被測定物（ゲートウェイや各ノード、サブスクライバ、パブリッシャ）の遅延時間・応答時間をより高い精度で測定することが可能である。併せてエクセサイザ機能（エミュレーション機能）を同時に提供し、いち早く実ネットワークにおける試験環境を提供することが可能である。いずれも物理層からプロトコル層、さらにはアプリケーション層までの様々なテストケースを想定した製品・ソフトウエアで、ネットワークに関連する問題を効率的に特定するために必要なノウハウが含まれている。
　エンジニアの『デバッグ作業』において工数が膨大にかかる可能性がある『問題点・不具合の発見』という一番の難関を、いかに速く解決するのかが現在エンジニアに課せられている一番の難題である。被測定物である車載ネットワーク・システムの複雑さが高まる中、十分なシステムの信頼性を検証するためには、ネットワーク・システムのテスト手段、プロセスの重要性を把握し、事前に充分な準備を行うことと、それを手助けできるツール（測定器）を選択・採用することが重要である。