ヒュンダイケフィコ、NI PXIハードウェアでECU製造テストを標準化
ユーザ事例のハイライト
ヒュンダイKeficoは、複数のECUタイプ間で再利用可能なスクリプトベースのPXIプラットフォームを導入することで、製品固有のテスターへの開発依存度を低減しました。
共通のテストプラットフォームにより、テスト仕様の変更に迅速に対応し、テストロジックの再利用性を向上させることで、新製品の導入を迅速化できました。
「統一されたNI PXIアーキテクチャに移行すると、ハードウェアとソフトウェアがプロジェクト全体で一貫性を持つようになり、多くの不確定要素がなくなりました。システム間の差異に対処する必要がなく、テスト要件に集中できるようになりました」
―Hyundai Kefico製造技術チーム1、Ph.D. Won-Kyung HAM氏
課題
複雑な車載エレクトロニクスでは、幅広いECUでハードウェア、ソフトウェア、通信インタフェースの相互作用が増加します。コンポーネントを個別にテストするだけでは不十分です。システムが多くのエッジケースで一貫して動作することを確認する必要があります。課題は、単に技術的な複雑さだけではなく、製品が急速に進化しながらテストアーキテクチャの安定性を維持することです。
ソリューション
共通のテストシステムにより、単一のプラットフォームでスクリプトベースの柔軟性により多くの製品をテストできます。汎用的で拡張性のある機能テストシステムを構築することで、Hyundai Keficoはテスト手順の定義、実行、保守方法を標準化し、製品固有のテスターへの依存を減らし、開発効率と生産拡張性を改善しました。
テスト装置を標準化する理由
ヒュンダイ・ケフィコは、さまざまな車載電子部品の研究、開発、検証、および生産を担当しています。
自動車の複雑化に伴い、当社が開発したテスト装置では、大量のデータ、より多くの通信プロトコル、および厳しい信頼性要件を処理する必要があります。この要件は、製造テストチームがハードウェアレベルの検証だけでなく、テストシステムがますます統合されたソフトウェア中心のECUをサポートできるかどうかの確認にも重点を置くことを意味します。開発や生産に関わる人々のより深い技術理解とより強い連携を結びつけるという私の役割を押し進めてきました。
さらに、自動車のパワートレインの進化に伴い、充電インフラやボディ制御モジュールはもちろん、電気自動車、ハイブリッド自動車、燃料電池自動車、燃焼自動車をサポートするために必要なコンポーネントの範囲も劇的に拡大しています。各製品タイプで要求される機能テスト手順が異なるため、この複雑さがテストチームにとっての課題となっていますが、専用の製品固有のテスト装置の開発には拡張性がありません。
これを考慮して、ヒュンダイケフィコのチームは、以下の要件を満たす標準化されたテストアーキテクチャを設計する必要がありました。
柔軟なテストシステムで複数の製品タイプをサポート
エンジニアがテスト手順を一度作成できる
これらの手順を生産テスト装置に直接適用
目的は、実行の標準化、ハードウェア依存項目の分離、およびテストロジックの製品固有かつ機器に依存しない状態に維持することでした。
アーキテクチャ要件
適応可能で再利用可能なテストシステムアーキテクチャの主な目標には以下が含まれます。
製品タイプの柔軟性―車両制御システム、バッテリ管理システム、電力制御、水素供給システム、エンジン制御ユニット、トランスミッション制御など、さまざまなテスト手順を持つ複数の車載電子部品をサポート
懸念事項の分離―テスト装置ハードウェアからテスト手順開発を分離
直接適用可能―エンジニアが開発したテスト手順は、そのまま本番テスト装置で実行する必要がある
再利用性―テスト手順は製品および製造ライン全体で再利用できる必要があります。
アプローチ
図1に示すように、3つの柱の周りに共通のプラットフォーム（CP）を設計しました。
スクリプト開発―エンジニアはテスト方法、シーケンス、仕様を標準化されたテストスクリプトとして定義
一元管理―テストスクリプトは一元管理および配布される
ハードウェア抽象化―本番テスト装置が標準化されたテストプラットフォーム上でスクリプトを実行
図1.共通プラットフォームワークフローの概念
テストスクリプトレイヤは、製品固有のテストロジック (テストメソッド、実行シーケンス、仕様、および基準) を定義するための標準化されたテストスクリプトを提供します。図2に示すように、このテストロジックはテスト装置の構成とハードウェアから分離されています。
テスト実行フレームワークは、すべての製品で共有される共通の実行エンジンとして機能します。このフレームワークは、テストスクリプトの解釈、テスト実行フローの制御、測定と結果評価の処理、エラー処理とロギングの管理をすべて製品タイプに依存しません。
図2.テスト実行フレームワークアーキテクチャ
最後に、ハードウェア抽象化レイヤは、デバイスのタイプやベンダに関係なく、テスト実行フレームワークと物理ハードウェア間の標準化された制御インタフェースを提供し、図3に示すように、同じテストスクリプトと実行フレームワークを異なるハードウェア構成で実行できるようにします。
図3.ハードウェア抽象化
ハードウェア抽象化により、テストの標準化を損なうことなくハードウェアの柔軟性を確保できます。
コアアーキテクチャを標準化し、PXIのモジュール式ハードウェア構造を使用してPXIベースのCP-Testerを導入したため、構成変更が非常に簡単になりました。また、PXIプラットフォームはクリーンなソフトウェアインタフェース層を提供し、新しい関数やプロトコルの統合には最小限の再設計で済みます。その結果、同じアーキテクチャを再利用し、必要なモジュールのみを更新することで、主要なEVプロジェクトに対応できるようになりました。
現在、CP-Testerは、この標準化されたプラットフォームのいくつかのバリアントを通じて、Hyundai Keficoの生産施設全体でさまざまな電子制御ユニットのテストに使用されています。200ピン未満のさまざまなECUタイプのテストを標準化するために、複数のNI PXIマトリクスモジュールが広く使用されています。通常の構成では、2つのPXIシャーシがデイジーチェーントポロジで接続されています。マトリクス以外のモジュールは、PXIモジュール式計測器およびPXI再構成可能マルチファンクションI/Oモジュールで構成されています。以下のリストには、テスタ構成の例が記載されています。
CP: General Control Unit（一般制御ユニット）
DUT: メインインバータ制御ユニット（ECU、TCU、PCU）およびEV制御ユニット（VCU、SCU、CVMSなど）
NI PXIハードウェア: マトリクススイッチ、DMM、DAQ、SMU、CAN、可変抵抗
追加ハードウェア: 電源、ダミー負荷、関数発生器
CP: ワイヤレスRF能力テスト
DUT: ワイヤレスBMUおよびCMU
ハードウェア: ワイヤレステストシステム、電源、UARTモジュール付きF/Qデバッガ
CP: モータ制御ユニット
NI PXIハードウェア: マトリクススイッチ、DMM、DAQ、CAN、可変抵抗
価値と効果
標準化されたPXIベースのハードウェアを使用する前は、すべてがブラックボックスのように感じられました。各システムインテグレータはテスターを別々に作成しており、基本的な機能の標準化さえ難しく、すべてのプロジェクトはゼロから開始されました。良い例はマトリクススイッチです。以前は、各ベンダーによってマトリクスの作成方法が異なるため、経路設定に一貫性がありません。単純な関数でさえ標準化が困難でした。PXIマトリクススイッチに移行後、経路設定とチャンネル動作はすべてのテスタで同じになり、機能の標準化がようやく容易になりました。
CP-Testerでの標準化には、以下の利点があります。
新製品の迅速な導入
テスト仕様の変更に迅速に対応
製品特有のテスト装置への依存度を低減
テストロジックの再利用性の向上
テストロジック、実行、ハードウェアを明確に分離
標準化されたハードウェアとソフトウェアが複数のプロジェクトで信頼性が高いことが実証されると、開発がはるかに容易になり、毎回新しいシステムを構築する必要がなく、実際のテストに集中できるようになりました。やがて、標準化は1つのオブジェクトではなく、文化であることがわかりました。更新し続けないと壊れる生きたシステムです。そのため、すべてのプロジェクトで実行し、改善するために、チーム全体が関与しています。
拡張性のあるハードウェアと明確なテスト方法があれば、既存のシステムを拡張できると確信しています。セットアップの置き換えから、制御されたスケーラブルなアップグレード方法を探すことに切り替えました。