Technical Article CANoe オプション DiVa を使用した診断通信機能の自動評価 GM ヨーロッパ (GME) で、量産車開発における診断通信機能の評価に、全自動でテストケースを生成す るツールが初めて導入されました。 テストの生成には、電子データ化された診断仕様書を使用します。 ここではまず、テストの自動化のために、既存のツール環境にベクター・インフォマティック社(以下ベクタ ー)のCANoeオプションDiVa (Diagnostic Integration and Validation Assistant：以下DiVa) というツ ールを取り入れた過程を紹介します。さらに、診断通信機能の評価を自動化した新型オペル 「インシグニ ア」の開発事例をもとに、そこで得られた開発プロセスの改善と、コストおよび工数削減の成果を、現行オ ペル 「コルサ」の開発時に用いた従来の手作業での評価と比較して説明します。 1 はじめに 自動車市場の競争が世界的に激しくなった結果、開発サイクルの短縮が強く求められています。その一方、 ECU 間のネットワークアーキテクチャーの複雑化がますます進んでいます。従来のシステムを電子制御シ ステムに移行することの重要な目的は、コストの削減、高い安全性と信頼性、管理の容易性にあります。こ のような利点の反面、車両の電子部品の増加に伴い、それらが故障する可能性が高くなる恐れがあります。 新しい自動車を購入する際、信頼性はお客様にとって重要な条件の 1 つであるため、複雑化の克服と開 発プロセスの短縮を実現し、組み込まれた ECU が正しく動作することを保証できる新しい手法を導入する CANoe オプション DiVa を使用した診断通信機能の自動評価 1/14 Technical Article ことが非常に重要です。特に ECU が提供する診断機能については、診断サービスが正しく機能することが 重要です。診断サービスは、修理工場で故障の原因を短時間で特定して修理するための情報を提供しま す。この情報は、修理工場で問題の原因となる部品を特定し、完全に動作する状態に修理するために何が 必要なのかを判断できるものでなければなりません。正しい情報が得られない場合、修理によって正常に 動作している ECU [1] を誤って交換してしまう可能性があり、これにより品質保証に関するコストが増加す るばかりか顧客満足度も低下します。 インシグニアの E/E(Electrical/Electronic) アーキテクチャーは、複数の CAN (Controller Area Network) および LIN (Local Interconnect Network) バスシステム [2, 3] で構成されます。すべてのバスシステムに は、単一の診断コネクタ (DLC) を使用してアクセスできます (図 1)。通信は GM 固有のプロトコルで定義さ れています。この GM の診断仕様は、KWP2000 [4] および CAN 2.0A にもとづいており、ECU の診断シ ステムを使用して診断情報を取得するために必要な診断サービスのすべてが規定されています。これらの サービスは診断テスターによって出力され、診断のためのコミュニケーションを確立します。要求が送信さ れるとすぐに、対象の ECU が肯定応答または否定応答を送信します。 • 肯定応答には、診断テスターが要求した診断情報が含まれます。診断情報 が多い場合は、応答を複数のメッセージフレームで構成することができます。 • 否定応答には明示的に定義された否定応答コードが含まれ、否定応答の理 由を示す情報が提供されます。否定応答コードは、GM 診断仕様に対応する ように指定します。 受信した応答により故障の原因を特定できるので、修理工場では正しい作業を行い、問題を解決すること ができます。 そのため、修理工場で正しく故障を修理できるかどうかは、診断システムによって出力されたデータの精度 に大きく依存します。診断の機能を正しく実装することが、迅速に専門的な修理やメンテナンスを実施して お客様を満足させるために非常に重要です。診断は生産ラインでのテストでも役立っており、ここでの ECU の書き換えや製品の品質保証に使用されます。そのため、診断機能の総合的な評価・確認は必要不可欠 です。 CANoe オプション DiVa を使用した診断通信機能の自動評価 2/14 Technical Article 図 1：インシグニアの E/E アーキテクチャーと診断通信 2 GM ヨーロッパでの評価プロセスとツール環境 GM ヨーロッパはインシグニアの開発で初めてベクターの DiVa を導入しました。DiVa は、診断通信機能を 評価するテストの作成と実行を自動化します。図 2 にコルサとインシグニアのツール環境を示します。どち らもテストツールとして CANoe [5] を使用しています。コルサの開発では、評価テストはほとんど手動で行 われましたが、インシグニアの開発では評価テストの大部分が自動で行われています。図 3 は、GM ヨーロ ッパのテストエンジニアが行った典型的な ECU 診断機能の評価の経過を示します。ECU ソフトウェアの開 発は複数のフェーズに細分化されています。ECU 開発の最初のフェーズでは、診断通信機能よりも ECU 本来の機能に重点が置かれます。診断通信機能は、その後のソフトウェアのバージョンで開発されます。 図 3 に示すように、フェーズ 1 (SWR 1) のソフトウェアバージョンではごくわずかしか診断通信機能は実装 されません。GM ヨーロッパでは診断ソフトウェアモジュール (ベクターの CANdesc) を使用することにより、 開発開始の早い段階で診断通信機能の一部を実装することができました。 テストしなければならない診断通信機能の数は開発サイクルごとに増えます。診断通信機能をすべて実装 した後は、回帰テストを実施します (SWR 7)。この段階で診断通信機能に関する不具合が報告されなけれ ば、ECU は診断通信機能については量産可能な状態といえます。 CANoe オプション DiVa を使用した診断通信機能の自動評価 3/14 Technical Article テストエンジニアは通常、数多くの ECU を同時にテストするため、適切なツールによるサポートがなければ、 各ソフトウェアバージョンにおいて実装された診断通信機能をすべて網羅するために必要な膨大なテストを 実施できません。その結果、新しく実装された診断通信機能しか十分にテストされず、以前に実装された機 能については、テストエンジニアが経験から判断した一部のテストを実施するだけになってしまいます。適 切な自動化ツールを使用することにより、評価の際により多くのテストを実施できるだけでなく工数も削減で きます。 図 2：コルサおよびインシグニアの、診断通信機能の評価とツール環境の比較 図 3：GM ヨーロッパでの ECU 開発における各フェーズでの診断機能の範囲 CANoe オプション DiVa を使用した診断通信機能の自動評価 4/14 Technical Article 3 評価テストツールの要件 自動診断評価テストツールは、以下の要件を満たす必要があります。 • 既存のツールチェーンにシームレスに組み入れられること • 透明性および再現性： テストエンジニアが、自動実行したテストの過程を確 認できる。また、テストを再現できること • GM のテスト仕様への準拠：GM の仕様書には、ECU の診断機能を評価す るためのテスト手順が規定されているので、これにもとづいたテストを実施で きること • テストエンジニアによる拡張が可能であること • テストケースの自動生成： このためには、診断通信仕様を、計算機で処理で きる型式で電子データ化しておく 4 仕様からテストの実行、レポートの評価まで 図 2 に示すように DiVa を導入することで、ベクターが提供する「CANdelaStudio (診断通信仕様) 」と実績 のある開発/テストツール 「CANoe」との組み合わせを、さらに有効に活用できるようになります。DiVa は、 既存の確立された GM ヨーロッパのツールチェーンにシームレスに組み入れられます。各機能をチェックす るためのテストケースは、CANdela 診断データベース (CDD ファイル) から自動的に生成されます。生成さ れたコードは CANoe のプログラミング言語 CAPL (Communication Access Programming Language) で記述されているため、いつでもその内容を確認できます。問題が発生した場合、テストエンジニアは自動 テストシーケンスの結果を調べて原因をつきとめ対処します。また、CANoe のログ機能を使用して、CAN 通信における診断データフローのトレースと評価を行うこともできます。 DiVa を使用してテストを実施するには、以下の手順に従います。 1.ECU とそのバリアントを選択します CANoe オプション DiVa を使用した診断通信機能の自動評価 5/14 Technical Article 2.テストの生成仕様を設定します 3.テストを生成します 4.テストモジュールを CANoe テスト環境に追加します 5.テストを実行します 6.テストレポートを評価します DiVa でのテストの生成仕様はいつでも変更できます。特に、「テスト範囲」のパラメータを使用して、「フルテ スト」、「クイックテスト」、「正常なケースのみ」などのテストを作る機能が便利です。また、「対応サービス」 画面でテストからある特定のサービスを除いたり、「データカスタマイズ」画面で診断サービスで用いるデー タを変更したりすることができます (図 4)。 診断通信仕様を変更する際には、それまでの設定を保持したまま新しい仕様に同期させることができます。 技術的には、DiVa は CANoe テストモジュール用の CAPL コードを生成して、ECU がサポートするすべて の診断通信機能をテストします。GM の診断仕様に正しく準拠するために、DiVa の拡張機能によって GM 標準のテスト手順を追加しています。テストを生成する際には、生成されたテストケースの詳細な記述、 CANoe テストモジュールの CAPL ソースコード、関連する CANoe のテスト環境が作成されます。 図 4：DiVa でのテストの生成仕様の設定 (図は「対応サービス」を設定する画面) CANoe オプション DiVa を使用した診断通信機能の自動評価 6/14 Technical Article 5 テストの実行とレポートの評価 テストの生成後、生成したテスト環境を CANoe で開いてテストを開始します。テストを実行するのに必要な 時間は、診断通信仕様の複雑さやテスト生成仕様によって異なり、数分から数時間の幅があります (表 1)。 GM では、CANoe テスト環境をテストの自動化のための共通のプラットフォームとして使用することにより、 GM の既存のテストプログラムの再利用を容易にしています。たとえば、生産ラインでのフラッシュテストも CANoe プログラミング言語の CAPL でプログラミングされています。テストエンジニアによる解析を補助す るために、GM 診断仕様に準拠したテストレポートが作成されます。図 5 に典型的なテストレポートを示しま す。 表 1：インシグニアの ECU のテスト実行時間 図 5：DiVa で自動生成されたテストレポート CANoe オプション DiVa を使用した診断通信機能の自動評価 7/14 Technical Article 6 テストの範囲 (カバレッジ) テストを自動化することにより、テストの範囲を広げながら、同時にテストの実行に必要な時間を短縮するこ とができます。GM の診断仕様書に記述されているテスト手順の中で DiVa が対応可能な範囲を以下に記 述します。生成されるテストケースの数とその品質は、生成に用いる診断仕様データ (CDD ファイル) の完 成度に大きく依存します。テストはすべて、CDD ファイルから生成されます。 合計で約 350 のテスト手順が GM の診断仕様書に定義されています。DiVa は、この中の「正常な場合の テスト」と「異常な場合のテスト」の両方に対応しています。テスト手順の大部分 (約 80%) は、DiVa によっ て完全自動化されたテストで行うことができます。GM の診断仕様書に定義されたテスト手順のうち 45 (15%) の手順に対しては、アプリケーション固有のユーザー入力が必要です。この場合、DiVa はテストの 実行を一時中断し、ユーザーに ECU を必要な状態にするように要求します。テスト手順の残りの 5%は DiVa でサポートされていないため、手動またはその他の手段を用いてテストする必要があります。この中 には、EEPROM エラーを生成して検出するなどの、残りのテストが実施できなくなる危険があるテストや、 ECU の設定を変更してしまうテストなどが含まれます。GM 固有のテストケース以外のテストケースを追加 して実行することにより、テストの範囲をさらに広げることもできます。 GM ヨーロッパで行われたコルサとインシグニアの開発プロセスの比較により、生成されたすべてのテスト ケースの大部分を DiVa を使用して自動的に実行することで、テスト実行時間が大幅に短縮されることが分 かります (図 6)。前記の表 1 は、インシグニアの ECU 用に生成されたテストケースの実行時間と数を示し ています。 また、しばしば時間の制約から、散発的な手動のテストのみを行うことがあります。この場合、評 価結果はテストエンジニアの経験や費やせる時間によって大きく変わります。GM ヨーロッパでは、DiVa を 使用することで、診断通信仕様書に従った ECU の完全なテストと、すべての開発段階でのテスト範囲の拡 大に成功しています。 CANoe オプション DiVa を使用した診断通信機能の自動評価 8/14 Technical Article 7 コストの削減と効率の向上 ツールを導入する場合、それによるコスト面でのメリットが最も期待されます。 現行コルサは自動車市場で 非常に成功しており、診断に関連する電子関連の問題について悪い報告がないため、コルサの開発時に 手動で行われた評価プロセスを比較対象として選びました。一方、新型インシグニアでは、診断通信機能 の評価に DiVa がメインツールとして使用され、初めて評価テストの大部分が自動化されました。比較を行 うために代表的な ECU について、評価フェーズでのテストの実行と結果の確認に必要な時間が測定され ました。これらの測定値は図 3 の SWR 5 の実装レベルにもとづいています。多くの診断サービスはすでに その時点で実装されており、不合格になったテストケースの大部分はすでに把握されています。図 6 は、コ ルサでの手動テストとインシグニアでの自動テストにおける評価の時間数を示します。 DiVa を使用することにより、コルサに比べてインシグニアのほうがはるかに実行時間と確認時間とが短縮 されています。この調査では、3～5 倍の改善が確認されています (図 6)。特に、診断サービスの数が多い ECU の場合に時間が大幅に短縮されています。SWR 6 や SWR 7 などの開発後期を考慮すると、テスト 結果の確認に必要な時間はさらに短縮されます。 これは、ソフトウェアの完成度が上がるにしたがって、不 合格になるテストの数が減るためです。この流れは量産開始に至るまで、全ての開発フェーズで続きます。 量産レベルに達した ECU には一切不具合がないため、評価時間が実行時間と等しくなります。インシグニ アの量産決定段階では、ECU の複雑さによって異なりますが、効率を 20～40 倍に向上できました。DiVa の導入に必要なことはライセンスの購入だけですので、新しいソリューションは低コストです。CANoe に精 通している GM ヨーロッパのユーザーは、特にトレーニングを受けなくても DiVa のテストを行うことができ ました。また、DiVa では CANoe を介して利用可能な CAN のインフラを使用できるため、テストを実行する ために別途ハードウェアを用意する必要もありません。 CANoe オプション DiVa を使用した診断通信機能の自動評価 9/14 Technical Article 図 6：ECU の診断通信機能を手動評価した場合の所要時間(コルサ)と、自動評価した場合の時間(インシグニア)との比較 (テスト実行 と結果確認に要した時間) 8 テストケースの自動生成と自動実行の限界 自動ツールが手動テストよりもテスト範囲と工数の面でどんなに勝っていても、テスト生成の自動化には限 界があります。 • 仕様書の品質：仕様書はテストケース生成のベースですので、完全かつ精度 が高いことが不可欠です。つまり、テストの品質は仕様書の品質によって決 まります。また、GM 診断インフラ仕様 (GGSE-I) [6] の要件にも従う必要が あります。 • 再現性：車両での CAN 通信のふるまいには一定範囲内の不確実性がある ため、不具合が生じたテストを再現するのが非常に困難な場合もあります。 • 二次的な不具合：自動テストツールはテストエンジニアと違い、不具合が生じ た際に、それが一次的な不具合なのか他の不具合により生じた二次的な不 具合なのかを区別できません。 CANoe オプション DiVa を使用した診断通信機能の自動評価 10/14 Technical Article • ユーザーによる入力：アプリケーション固有のテストでは、ECU を追加のハ ードウェアを必要とする状態にしなければならないことがあります。このような 場合、DiVa を使っても、テストの実行を完全に自動化することはできません。 9 まとめ テスト自動化ツールを使用しなければ、現在の車両における診断機能の評価テストに要求される範囲をす べてカバーすることは、もはや不可能です。 ベクターの CANoe オプション DiVa は、GM のテスト仕様に完 全に準拠しており、GM ヨーロッパの既存のツールチェーンにシームレスに組み込めます。新型インシグニ アの開発では、診断通信機能の評価を行うための自動テストツールとして実際に使用されました。 DiVa を使用することにより GM ヨーロッパでは、テストのための工数を削減するだけでなく、回帰テストを 何度も実施することにより、同時に評価の品質も向上させています。さらに GM 固有でないテストケースを 追加で実行することにより、テスト範囲を広げることもできます。 新型インシグニアの開発では、以前の成 功したプロジェクトでの手動評価と比較して、技術的にもコスト的にも飛躍的に効率が上がっています。開 発フェーズと実装の品質によって異なりますが、効率は実際に 4～20 倍に向上しています。 そして同時に、 品質面での顧客の高度な要求にも応えられるようになりました。 参考文献： [1] Thomas, D.; Ayers, K.; Pecht, M.: The “trouble not identified” phenomenon in automotive electronics. In: Microelectronics reliability, Vol. 42, P. 641-651, 2002 [2] LIN Consortium: LIN Specification Package Revision 2.1, OV. 2006 [3] Robert Bosch GmbH: CAN-Spezifikation 2.0, 1991 [4] International Organization for Standardization: Keyword Protocol 2000, ISO 14230, 1999 [5] Krauss, S.: Testing with CANoe, Application Note AN-IND-1-002. Vector Informatik, 2005 [6] General Motors. GGSE ECU Diagnostic Infrastructure Requirements, Version 1.07, 2007 CANoe オプション DiVa を使用した診断通信機能の自動評価 11/14 Technical Article 著者： Philipp Peti 博士は、ウィーン工科大学でコンピューターサイエンスを専攻し、博士号を取得しています。現 在ドイツのリュッセルスハイムにある GM ヨーロッパの「グローバルシステムエンジニアリング」グループで開 発エンジニアとして従事しています。 Armin Timmerberg 氏は University of Applied Sciences at Wiesbaden で電気工学を専攻し、その後 GM ヨーロッパのアフターサービス部門のシステムエンジニアとして採用されました。最初の仕事は、GM の サービステスターTECH2 に ECU を診断する機能を実装することでした。2004 年からは同社の「グローバ ルシステムエンジニアリング」グループで開発エンジニアとして従事し、診断機能の評価を担当しています。 CANoe オプション DiVa を使用した診断通信機能の自動評価 12/14 Technical Article Thomas Pfeffer 氏は Darmstadt University of Technology で電気工学を専攻しました。現在ドイツのリュ ッセルスハイムにある GM ヨーロッパの「グローバルシステムエンジニアリング」グループで、診断とテストの 自動化を担当するグループのグループマネージャを務めています。 Simon Müller はシュトゥットガルト大学でソフトウェアテクノロジーを専攻。シュトゥットガルトの Vector Informatik GmbH の診断システム部において CANoe オプション DiVa のプロダクトマネージャーを務めて います。 Christoph Rätz はシュトゥットガルトの University of Cooperative Education でコンピュータエンジニアリン グを専攻。Vector Informatik GmbH の 診断システム部のグローバルプロダクトラインマネージャーを務め ています。 Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart Germany www.vector-worldwide.com Editorial contact: Holger Heit Tel. +49 711 80670-567, Fax +49 711 80670-58567, E-mail: holger.heit@vector-informatik.de CANoe オプション DiVa を使用した診断通信機能の自動評価 13/14 Technical Article ■ 日本での本件に関するお問い合わせ先 ベクター・ジャパン株式会社 営業部 （東京） TEL: 03-5769-6980 FAX: 03-5769-6975 （名古屋） TEL: 052-957-2471 FAX: 052-957-2469 E-Mail: sales@vector-japan.co.jp CANoe オプション DiVa を使用した診断通信機能の自動評価 14/14
© Copyright 2024 Paperzz
