シミュレーション検証をした後は、ハードウェアとソフトウェアの結合テストやシステムテストを実施します。

しかし、車載ソフトの開発規模が増大している昨今、実車両ですべてのテストを実施することは困難です。

そこで、実車両の振る舞いをシミュレーションできるHILSを利用します。HILSでは、さまざまなテスト条件をパラメータとして与えられるため、任意のテストパターンを容易に、かつ網羅的に実施することができます。

また、自動テスト環境を構築することで、効率化も図れます。

正しく運用すれば多くのメリットが期待できるHILSですが、適切な運用ができている開発現場は多くありません。製品開発の過程では、要求や仕様が随時見直されます。HILSが、その変化に追従できなければ、プロジェクト開始当初は機能を果たしていたとしても、いつしか使えないものになってしまいます。

このような開発製品との不整合を引き起こさないようにするには、HILSもプロジェクトの進行(製品機能の変更)に合わせ、改修を重ねていく必要があります。継続的に一定の品質を保った改修を行っていくには、プロセスをつくり、そのプロセスに沿ってHILSを運用していける環境を整えなければなりません。

改修が必要となったときには、改修に掛かる工数を見積もり、リソースを割り当て、システムの設計を行い、改修を加えていきます。運用プロセスはこれらの作業を管理できるように構築されなければなりません。このような体制を整えることにより、初めて、製品の開発プロジェクトと歩調を合わせた「使える」HILSが利用できるようになります。

HILSの利用による利益を最大限享受しようと考えたときに、必要不可欠になるのはテストの自動化です。例えば法規対応の確認テストは法規が変わらない限りその内容は変わりません。作成したテスト仕様は繰り返し利用可能であり、そのテストを自動化することによって実施にかかる工数を大幅に削減することができます。

しかしながら、自動化のためのシステム構築・メンテナンスに工数が取られてしまっては本末転倒です。開発現場で見られるケースとして、テスト対象のコントローラやHILS環境(プラントモデル等)が変わるたびに改修を加えたり、別のHILSの導入にあたってシステムやテスト仕様を作成し直していることがあります。これは将来の拡張性を考慮しないままシステムを構築していることが大きな理由です。

拡張性の高い自動テストシステムの構築のためには、製品開発と同様に、将来の展開を見据え、再利用しやすい構造を築くことが必要です。

例えば、上図のAとBのような、異なる構造のプラントモデルを持つHILS向けのテストシステムを考えます。プラントモデルは、HILSや車載コントローラの特徴を反映しているため、同じ機能を達成するのであっても、構造が大きく異なることがあります。そのため、同じテスト内容を実施するのであっても、自動テストツールを個別に用意しがちです。それでは、テストを自働化したとしても、一過的な効果にすぎません。

そこでHILS側に操作を共通にするためのインタフェースをそれぞれに設け、その内部でプラントモデルにアクセスするようにします。その際、テンプレートを用意するなど、より柔軟な仕組みにしておくことで、インタフェース部分についても、再利用性や保守性を高くすることができます。

これで、HILSやプラントモデルに依らず、自動テストツールを共通化することが可能となり、また将来改修が必要になったとしても、改修範囲を限定することができます。

 システム要件に基づくシステムテスト