シミュレーション検証の後は、ハードウェアとソフトウェアの結合テストやシステムテストを実施します。ここでのテストの目的は「システム要件が正しく実現されていること」の検証です。

テスト仕様の作成では、まず初めにシステム要件から基本となるテストシナリオを抽出します。このテストシナリオに対し、ISO9126で定義される品質特性や過去不具合事例などから導かれるテスト条件を付加することで、要定義段階では定義しきれない部分まで網羅的にテストを実施することが可能になります。また、このような観点を用いてテスト仕様の設計を行うことは、ISO26262で要求されるテストフェーズでの作業を実現することにもつながります。

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

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

『HILS』の活用には次に説明する「運用プロセス」「自動テスト環境」がポイントになります。

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

このような開発製品との不整合を引き起こさないようにするには、『HILS』も製品機能の変更に合わせ、改修を重ねていく必要があります。そのためには、プロセスをつくり、そのプロセスに沿って『HILS』を運用していける環境を整えなければなりません。

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

『HILS』においても、先に述べた単体検証と同様に自動テスト環境が有用ですが、その構築には工夫が必要になります。

例えば基本のテスト仕様に対してさまざまな車両状態を掛け合わせたテストを実施したい場合、単体検証のようなテスト仕様書ではなく、マトリクス形式でのテスト仕様書が効率的です。また検証結果についても自動での結果判定が適するものとそうでないものがあ ります。このように、テストの目的や特性に応じたフォーマットに対応できる環境を構築する必要があります。

さらに、プロジェクトごとに自動テスト環境を一から構築することは、コストや運用性の面でデメリットがあり、環境の移植容易性も考慮する必要があります。

このように、『HILS』の自動テスト環境については、実施したいテストの特性や将来的な展開を考慮して、設計、構築を行うことが肝心です。