企業が製品の設計/テストにおいて標準化された取り組みが行われるようになってから、安全対策は以前より規制が厳しくなりました。ISO 26262は、自動車コンポーネントの重要な電気および電子 (E/E) システムの機能安全規格です。 ISO 26262は、電気/電子システムの汎用機能安全規格であるIEC 61508から派生しました。本文書では、ISO 26262の主要部分とソフトウェアおよびハードウェアの認定について説明しています。さらに、ISO 26262テストプロセスと、ISO 26262の認定ツールについても紹介します。
自動車産業では、複雑化によって安全性に準拠したシステムを提供するのに多くの努力が必要となってきています。たとえば、昨今の自動車ではスロットルバイワイヤなどのバイワイヤシステムが採用されています。ドライバーがアクセルを踏むと、ペダル内のセンサが電子制御装置に信号を送るというものです。この制御装置は、エンジン速度、車両速度、ペダル位置など、複数の要素を解析します。そしてスロットル本体にコマンドを送ります。スロットルバイワイヤのようなシステムのテストと検証は、自動車業界にとって難題となっています。ISO 26262が目指すのは、すべての自動車E/Eシステムの安全規格の統一です。
ISO 26262の国際規格草案 (DIS) は、2009年6月に発表されています。草案の発表以来、自動車業界におけるISO 26262への関心は高まっています。規格草案が公開されているため、法律家はISO 26262を最高水準の技術として扱います。最高水準の技術とは、その時点におけるデバイスまたはプロセス開発の最高レベルを示すものです。ドイツの法律では、製品の誤動作により人体が損傷を受けた場合、一般に責任を負うのは自動車メーカーです。ただし誤動作が最高水準技術でも検出できない場合は、責任が免除されます [製造物責任に関するドイツ法 (§ 823 Abs.1 BGB, § 1 ProdHaftG)]。
ISO 26262を実装することで、一般的な規格を利用してシステムの動作時の安全性を測定することができます。また、当規格では一般的な語彙を使用するため、システムの特定の部分を参照することも可能です。これは安全性を最重要視する他のアプリケーション分野にも言えることです。一般的な基準では、システムの安全性を測定する方法が規定されています。
ISO 26262では、ステップのシステムを使用して、機能安全を管理し、システム、ハードウェア、ソフトウェアのレベルで製品開発を調整します。
ISO 26262規格は、発案から廃車まで製品開発プロセスの全工程における規定や推奨事項を盛り込んでいます。許容できるリスクレベルをシステムやコンポーネントに割り当てて、全体のテストプロセスを文書化する方法が詳しく記載されています。ISO 26262は以下のような内容となっています。
ISO 26262は全10章からなります。連続生産自動車向けに制定されたもので、自動車に特化したセクションが含まれています。たとえば、ISO 26262の第7章では、生産、運用、サービス、廃車に関する特定の安全要求を定義しています。
ISO 26262自動車安全ライフサイクルでは、全生産ライフサイクルについて記述しています。たとえば安全管理者の必要性や安全計画の作成のほか、安全審査、監査、評価といった安全確認策の定義などが記載されています。これらの要求は、E/Eシステムおよび要素の開発に使用する目的で制定されています。
この技術資料では、主としてライフサイクルの開発フェーズに重点を置いています。ISO 26262の開発フェーズでは、システムの定義、システム設計、機能安全評価、安全検証について記述しています。
ASILは、ISO 26262コンプライアンスの主要構成要素です。ASILは、開発プロセスの開始時に決定します。システムの意図する機能を、考えられる危険性に基づいて解析します。ASILは、「不具合が発生した場合にドライバーや他の道路利用者にどのような影響があるか」という問いに答えるものです。
リスクにさらされる確率やドライバーによる制御性、事故発生時の結果の重大性などに基づいてこのリスクを推定することで、ASILを導き出します。ASILはシステムに採用されている技術に対するものではなく、純粋にドライバーと他の道路利用者への危険性のみに基づいています。
各安全要求にA、B、C、DのASILを割り当てます。Dが安全性の重要なプロセスで最も厳しいテスト規定です。ISO 26262規格では、コンポーネントのASILに基づいて最小テスト要求を具体的に特定します。それを基にテストに使用する方法を決めることができます。ASILが決定したら、システムの安全目標を設定します。それにより、安全の確保に必要なシステム動作が定義されます。
たとえば、ワイパーシステムについて考えてみます。安全分析により、ワイパー機能が損なわれた場合ドライバーの視野にどのような影響があるかを特定します。ASILは、製品の整合性がある一定のレベルに達するのに適した方法を選ぶための目安となります。この目安は、現在の安全対策の補助的な意味を持ちます。現在の自動車は高い安全レベルで製造されており、業界全体で特定の対策を標準化するのがISO 26262の狙いです。
ハードウェア認定には、2つの目的があります。部品のシステム全体への適合性確認と、故障モードの評価です。基本のハードウェアコンポーネントは標準の認定基準で認定できますが、より複雑な部品の場合はASIL分解/テストによる評価が必要です。ハードウェアコンポーネントは、通常様々な環境/動作条件で部品をテストすることで認定を行います。そしてテスト結果をさまざまな数値方式によって解析し、テスト手順、仮定、入力基準とともに認定レポートとして生成します。
ソフトウェアコンポーネントの認定には、機能要求の定義やリソースの利用状況、故障時やオーバーロード時におけるソフトウェア動作の予測などを利用します。このプロセスは、アプリケーション開発の際に認定ソフトウェアを使用することで大幅に簡素化できます。認定されたソフトウェアコンポーネントは、一般に他のプロジェクトでの再利用が可能で、ライブラリ、オペレーティングシステム、データベース、ドライバソフトウェアを搭載した完全な製品です。
ソフトウェアコンポーネントを認定するには、通常の動作状態でテストするとともに、システムに障害を挿入して異常入力への反応を確認する必要があります。ランタイムやデータエラーなどのソフトウェアエラーは、設計プロセス全体にわたって解析し対応します。
ソフトウェア/ハードウェアコンポーネントは、「Proven in Use」項によってISO 26262要求に準拠することができます。この条項は、他のアプリケーションで事故なく使用されている場合に適用されます。ISO 26262は、さらに使用実績により証明されている旧システムにも対応しています。多くの場合、数百万台もの車両にすでに実装されているシステムに規格を適用するのは、あまり意味のあることではありません。たとえば、現在生産されている車に搭載された多くのシステムは、ISO 26262が公開される前から高い安全性を備えています。それらのコンポーネントは、実環境での使用を通して、信頼性の高い動作が可能なことを実証しています。 信頼性の高いシステムが旧車両からそのまま使用されている場合は、ISO 26262でも認定可能です。同様のアプリケーションや広く実装されている旧アプリケーションに使用されている認定可能コンポーネントを組み合わせることで、システム全体の複雑性が軽減します。
ISO 26262のような新しい規格を導入する際に課題となるのが、現行プロセスへの適用です。新しい規格の場合、通常パイロットプロジェクトを使用して規格の実装と現行プロセスへの影響を確認します。現時点での結果を見ると、ISO 26262は業界の現行の安全概念によく適合しています。メーカーは、開発プロセスの早い段階でのリスクの評価と危険分析、またプロセス全体でのテストの実行のメリットを認識しています。
ISO 26262の導入を検討している企業が理解しておくべきなのは、開発プロセスの早期にリスクを解析し、適切な安全要求を確立して、開発時にテストを行うことでそれらの要求を満たすことが目的であるという点です。
ISO 26262開発では、テストが極めて重要な構成要素です。安全性が重視されるシステムは、テストシナリオに適切に応答し、人や環境からの様々な入力にさらされても、指定した安全限度を超えないことが必要です。高品質のテストシステムを使用すると、製品の性能が向上し、品質と信頼性が上がってリターン率は低下します。出荷後ではなく生産時にエラーを見つけると、故障のコストは10分の1に低減され、生産時ではなく開発時に見つかればさらに10分の1に減ると推定されています。テストによってそのような欠陥を見つけてデータを集め、設計やプロセスを向上させることは、企業に価値をもたらします。技術挿入と最善策の方法論によってこのプロセスにイノベーションをもたらすことで、大幅に効率化するとともにコストも削減することが可能です。ツールまで気が回らずシステムの設計のことだけを考えがちですが、現実にはツールはエンドユーザの安全を期す上で非常に重要です。
ISO 26262では、広く普及しているソフトウェアツールを使用することで、安全関連機能を持つ電気、電子、ソフトウェア要素の開発に必要なタスクやアクティビティを自動化し、簡素化できることを認識しています。ツールの認定プロセスの詳細を説明する前に、ツール認定の重点部分である「ツールの信頼度」について明確にすることが重要です。
ツールの入力と出力から、一般的な (基準となる) 使用例が導き出されます。それらの使用例を分析することで、ツールの信頼度 (TCL) が決まります。TCLとASILによって、ソフトウェアツールに求められる認定レベルが決定します。信頼度を指定するには、2つの特定分野の評価が必要です。
ツールの信頼度はTCL1、TCL2、TCL3、TCL4の4段階になっています。TCL4が最も高く、TCL1が最低信頼度を示しています。
ISO 26262に基づいてツールを認定するには、多くの要求があります。たとえば、ASILはすでに決定していなければいけません。ツールには、ユーザマニュアル、固有の識別/バージョン番号、機能、インストールプロセス、環境の説明などが必要です。ISO 26262では、以下のツール認定情報が必要です。
ソフトウェアツール認定計画 (STQP) は、安全関連要素の開発ライフサイクルの初期段階で作成します。ソフトウェアツール認定の計画の策定と、求められる信頼度に基づいてツールが分類されていることを示す使用例一覧の作成という2つの部分からなります。
STQPには、ソフトウェアツールの固有の識別/バージョン番号、使用例、環境、説明、ユーザマニュアル、定義済みのASILといった項目が含まれている必要があります。
ソフトウェアツール分類分析 (STCA) は、ツールの信頼度を決定するのが主な目的です。TCLを決定する要素は2つあります。1つ目は、ツールの影響 (TI) です。2つ目は、ツールエラー検出 (TD) です。これらの要素に基づいて、適切なTCLを選択します。
ツールの影響には、TI1とTI2の2つのクラスがあります。TI1は、ソフトウェアツールが誤動作しても安全要求に違反する可能性がない場合に選択します。その他のケースでは、TI2を選択します。
たとえば、ある特定のソフトウェア機能で文書にタイプミスを引き起こすツールがあるとします。不快なミスではありますが、テスト対象の安全要求の違反にはなりません。そのためツールの影響はTI1となります。システムの何らかの動作を変化させるようなエラーが起こる場合、そのツールはTI2となります。
ツールエラー検出は、TD1からTD3に分類されます。TD1は、ツールのエラー検出能力に対する信頼度が高い場合に選択されます。TD3は信頼度が非常に低い場合に選択されます。エラーはランダムにしか検出できないと判断される場合などです。
たとえば、ソフトウェアツールが設計モデルのエラーをチェックするとします。この場合はモデルの静的解析を行います。静的解析は適していますが、可能性のあるモデルの違反をすべてチェックできるわけではありません。ただしそれが必ずしもモデルの欠陥を示すわけではなく、さらに別のテストが必要であることを示すのみです。このシナリオでは、「中間」の信頼度、つまりTD2という結果になります。
|
ツールエラー検出 | |||
TD1 |
TD2 |
TD3 | ||
ツールの影響 |
TI1 |
TCL1 |
TCL1 |
TCL1 |
TI2 |
TCL1 |
TCL2 |
TCL3 |
ツールの影響 (TI) とツールエラー検出 (TD) が決まったら、必要とされる信頼度に従って、TCL 1からTCL 3の値が割り当てられます。場合によっては複数の使用例があるためTCLが複数になることがあります。この場合、最高レベルのTCLが使用されます。ツールの分類は、各ソフトウェアツールについて実施する必要があります。
ソフトウェアツールを正しく使用するためには、いくつかの情報を提供する必要があります。
ソフトウェアツール認定レポートには、テストの結果と、ツール認定が完了し要求が満たされたことを示す証明が記載されています。検証時に誤動作や出力エラーが起こった場合は、そのすべてを解析し記載する必要があります。
ツール認定で重要なのが、使用による信頼度向上という概念です。認定要求があるツールに対して満たされている場合、さらに認定を行う必要はありません。それにより開発プロセスの時間とコストが大幅に削減できます。ただし、安全関連要素の開発で使用する前に、その要素それぞれについて認定要求を満たす必要があります。これを実証するには、以下の条件を満たすことが必要です。
たとえば、テストツールAが自動車XのECU (エンジン制御装置) の要求検証に使用されたとします。テストツールAが安全要求に違反せず変更もされていない場合、自動車YのECUの検証にも使用することができます。ただし自動車YのECUが自動車XのECUと同じ様に使用されていることが条件です。
NIのテストツールを使用して安全関連製品のテストを行う方法については、安全準拠システムをテストするためのNIのベストプラクティスを参照してください。全開発プロセスにおけるMIL (model-in-the-loop) テストやHIL (hardware-in-the-loop) テストといったテクニックについて紹介しています。さらに、コンポーネントの再利用によるメリットや効率性の向上についても解説しています。