　単体設計を行った後は、安全レベルに従ってレビュー、シミュレーション、静的解析を実施して、機能に異常が発生しないこと、ターゲット環境に適合すること、コーディング規約に従っていることを確認します。安全レベルによっては、不具合が発生しないことを公式によって証明することや、数学的に証明する手法である形式検証が要求される場合もあります。

単体テスト

　単体テストでは、最初にテスト計画を策定します。

　これは、開発が遅延するとテストを省略してしまう傾向があるため、確実にテストを実施する期間を確保することが目的です。

　単体テストでは、関数単位でテストを実施しますが、要求通りに動作することはもちろん、不具合を発生させても異常動作しないことも確認していきます。同時に、安全レベルに従って関数単位のテストカバレージ（C0、C1、MC/DC）を測定することで、関数の分岐パス全てをテストして、異常動作が起きないことを保証します。このテストカバレージ基準は、航空業界のDO-178Bから流用されているため、航空業界のテストツールで対応していることが多くなります。

　また、日本ではテストカバレージ結果を残さないことが多いのですが、ISO26262ではテストカバレージ結果も含めたテスト結果を全て残す必要があります。

　単体テスト～統合テストでは、できるだけターゲット環境に近い環境でテストを実施し、かつ、ソフトウェアインザループテスト（SILS）、プロセッサインザループテスト（PILS）、モデルインザループテスト（MILS）、ハードウェアインザループテスト（HILS）といったテスト環境を利用する必要があります。

図3　SILS／PILS／MILS／HILSの対応

統合テスト

　統合テストでも、最初に計画を策定しますが、アーキテクチャ設計の階層ごとに、順番に関数を統合していくため、アーキテクチャ設計の階層数に依存して計画を策定することに注意が必要です。

　統合テストでは、複数の関数を統合して、テストすることを繰り返し実施します。

　統合テストでは、関数を統合した単位でテストを実施しますが、要求通りに動作することはもちろん、不具合を発生させても異常動作しないことも確認していきます。同時に、安全レベルに従って関数が実行されたかどうかのテストカバレージ（S0、S1）を測定することで、関数コールのパス全てをテストして、異常動作が起きないことを保証します。

ソフトウェア安全要求検証

　ソフトウェア安全要求検証でも、最初に計画を策定します。

　ここでは、さまざまな環境で複数の要求を組み合わせて実施しても、安全要求を満たすことを検証します。このため、環境や要求の組み合わせ数に従って、計画を策定する必要があります。

　安全レベルによって、ネットワークシミュレータ、HILS、実車による検証が要求されます。

Automotive SPICEだけでは、ISO26262ソフト開発に準拠できない

　よくAutomotive SPICEの認証を取得していれば、ISO26262のソフトウェア開発の認証も取得できると誤解されている方がいますが、Automotive SPICEでは、フレームワークだけが定義されており、具体的な手法や安全に関する要求が含まれていません。

　このため、Automotive SPICEの認証は、ISO26262のソフトウェア開発のベースにこそなりますが、そのままではISO26262のソフトウェア開発の認証を取得できませんので注意してください。

図4　Automotive SPICE ENG.5とISO26262 Part.6-7の対応例

　次回は、システム、ハード、ソフトに関係するISO26262 Part.8 支援（管理プロセス）について取り上げたいと思います。お楽しみに！（次回に続く）

筆者紹介

河野喜一（こうのよしかず）
NEC コンサルティング事業部
（http://www.nec.co.jp/service/consult/vision/softconsul/safety_05.html）
産業機器開発、通信機器開発、ALMベンダー、組み込みコンサルを経て、現職。専門分野は、開発者の視点による開発プロセス改革（管理面、開発面）、規格適用コンサル。現在、組み込み開発の開発プロセス改革、ISO26262適用コンサルに従事。

「自動車分野の機能安全規格「ISO26262」とは何か？」バックナンバー