ISO26262 Part.8 支援（検定プロセスなど）：自動車分野の機能安全規格「ISO26262」とは何か？（4）（1/2 ページ）
自動車分野向けの機能安全規格「ISO26262」。今回は、システム、ハードウェア／ソフトウェアに関係する「ISO26262 Part.8 支援」の続きとして、主に“検定プロセス”について取り上げる。
自動車機能安全規格「ISO26262」の支援（検定プロセスなど）概要
前回は、機能安全規格の「支援（管理プロセス）」について概要を説明しました。
今回は、ISO26262 Part.8 支援の続きとして「支援（検定プロセスなど）」について説明します。
注目されているが、実施が難しい流用・再利用プロセス
組み込みソフトウェア開発では、既存製品のソースコードの流用による製品開発が多くなりますが、流用するために必要となる情報がきちんとまとめられていないことが多く見受けられます。また、先行開発や試作開発では流用を前提とした開発をしていないため、実際に流用する際、その都度、ソースコードから仕様を読み取ったり、設計書を書き起こしたりすることが多くなります。
ISO26262では、ソフトウェア部品やハードウェア部品がISO26262に準拠して開発されていることはもちろん、流用・再利用に必要な情報を文書として残すことなどが要求されます。つまり、ソースコードの流用や再利用時の誤解による不具合の発生を防止するための「コンポーネント検定プロセス」が定義されています。
ISO26262の支援（検定プロセス）
ISO26262の支援（検定プロセス）では、検定対象とする部品をあらかじめ想定しておき、プロジェクト計画として検定計画を策定することが要求されます。これは、要求定義（アイテム定義）が終わった後に実施されるため、車種ごとの共通する要求や、グレードなどによって変更される箇所を最初にきちんと分析しておく必要があります。このため、どちらかというと商品企画段階でどのようなグレードを想定しているか、車種間における共通要求は何か、ということを明確にすることが前提として挙げられます。
例）エンジンを共通化するなど
ISO26262の検証
ISO26262の検証プロセスは、開発プロセスにおける設計書の検証と実装後のテストの両方に適用されます。この検証プロセスでは、「検証計画の立案」「検証仕様書の作成」「検証結果レポート」の3つがセットで要求されます。
ISO26262では、設計書の検証としてシミュレーションが要求されることがあります。そのため、実装後のテストだけでなく、設計書の検証においてもシミュレーション計画を立案し、設計書を検証することが求められます。
また、単純にシミュレーションするだけではなく、要求を網羅しているかを確認する要求ベーステストや、機能間の状態不整合による異常制御のような内容もテストする必要があります。
「設計書のレビューなら数時間で終わるのに、何でわざわざシミュレーションまでするのか？」という話もありますが、不具合に対する修正工数は、初期の設計段階の方が以降の工程よりも大幅に少なくて済みます（10分の1から100分の1も少なくなるといわれている）。特に、ソフトウェアには不具合が潜在していることが多いため、“より上流で不具合を検出しておいた方が効率が良い”といえるでしょう。
文書化
検定プロセスとは少し異なりますが、ISO26262 Part.8 支援では、文書化の要求も定義されています。
設計書はもちろんのこと、テストを実施するためのテスト仕様書、テスト結果などの全ての成果物を文書にすることが要求されています。この“文書に残す”という行為は、第三者によるレビューをするために必要なだけではなく、開発したソフトウェアやハードウェアを再利用する場合にも必要になってきます。
また、全ての文書には、「作成者」「承認者」「バージョン」「変更履歴」などのフォーマットを採用することが要求されています。
ソフトウェアツール検定
ISO26262のソフトウェアツール検定では、開発に使用するソフトウェアツールを事前に検定するためのプロセスが定義されています。
対象は、“安全性に関わる全てのソフトウェアツール”となりますので、設計書や仕様書を記述するためのエディタやモデリングツール、CADツール、コーディング支援ツール、コンパイラ＆リンカ、テストツールなどが対象となります。また、特殊なツールとして、HILS（Hardware-In-the-Loop Simulation）もソフトウェアツール検定の対象として含まれます。
ソフトウェアツールの中でも、コード自動生成やテストに使用するソフトウェアツールの検定は、他のツールと比べて特に厳しくなります。
最初に、ソフトウェアツール検定の計画を策定するのですが、計画を策定するためには、さまざまなドキュメントや情報が必要となります。このためフリーウェアのツールの場合は、ドキュメントや情報を集め切れないといったリスクもあり得ます。
次に、ソフトウェアツールが安全性に関わるものかどうか、そして、安全性に関わる場合は、故障や不具合発生時にそれを検出できるかどうかを確認して、ツールを分類します。この結果、ソフトウェアツールが安全性に関係ない、あるいは故障や不具合発生時に検出できるといった場合は、検定の対象外として扱われます。
実際の検定では、「使用過程による保証」「ツール開発会社のプロセス認証」「ツールの妥当性確認」を実施することが要求されています。
ここで特に注意が必要なのは、ツール開発会社のプロセス認証も要求される点です。そのため、CMMIやAutomotive SPICE（内製ツールに有効）といった一般的な認証、さらにはIEC61508やISO26262といった厳しい認証に準拠する必要があるということです。
これもフリーウェアの場合、開発した企業がどこか？ 誰か？ プロセスはあるか？ などを把握できないというリスクが発生しやすいといえます。さらに、フリーウェアのため、どのような検証をしたか、妥当性確認をしたかも明確に把握することは困難なので、ツール検定を実施するためには、“フリーウェアをテストするためのテスト環境一式”を準備する必要もでてきてしまいます。
これに対して、ISO26262認証済みの“商用ツール”を利用した場合は、ソフトウェアツール検定を省略でき、さらに信頼性を認証機関が保証しているという大きなメリットがあります。なお、CMMIなどのプロセス認証を取得していない商用ツールベンダーは、今後プロセス認証を取得する必要に迫られる可能性が出てきます。
また、ソフトウェアツール検定は、ソフトウェアツールのバージョンが変わるたびに実施する必要があるため、内部工数を最低限に抑えるには、ソフトウェアツールの種類を必要最低限に抑えることと、ISO26262認証済みの商用ツールを利用することが重要です。また、同様にソフトウェアツールの妥当性確認の工数を最低限に抑えるためにも、妥当性確認を自動化することが求められます。これによって、ソフトウェアツールのバージョンが変わった場合でも、再確認の工数を最低限に抑えることができます。
Copyright © ITmedia, Inc. All Rights Reserved.