「プロセス実装」のポイント（その2）：システム設計：中小サプライヤのための実践的ISO26262導入（5）（2/3 ページ）

設計アプローチ

　機能安全プロセスの大きな特徴でもあるのですが、規格には安全設計を行うために、HW／SWそれぞれの特徴に合わせた方策の実施要求があります。システマチック故障への対策とランダムハードウェア故障への回避と抑制の対策です。

　前者は「設計ミスを回避する対策を取っているか」であり、主にSW開発に課せられた要求です。一方後者は、部品の劣化などにより「一定の確率で発生してしまう故障への対策」であり、定量的な目標値が定義されています。これは主にHW開発に課せられた要求です（HWにおいても設計ミスは起こり得ますので、常識的なシステマチック故障対策はもちろん必要です）。システムは、HW的な特徴もSW的な特徴も含むので、これら両方の要求が課せられています。それが、次に示した規格要求です。

• Part4：7.4.3　システマチック故障回避のための方策
• Part4：7.4.4　動作中のランダムハードウェア故障の抑制に対する方策

　それぞれの対策に対する解説は、次回解説するHW／SWのところであらためて触れたいと思います。ここでは、ISO 26262が、上記2つのアプローチによって機能安全を達成するという基本的な考え方の上にあることを理解しておいてください。そして、それぞれ特徴の違うHWとSWが、安全であることを主張する場合のアプローチもそれぞれ異なるという点にも注意してください。

　安全であることを主張するのを「安全論証」と言います。これについても少し触れておきましょう。

安全論証

　安全論証とは、簡単に言えば「このシステムはなぜ安全なのですか？」という問いに対する回答のことです。例えば、「機能安全規格に従って開発しました」というのも論証手段の1つですが、膨大な機能安全規格の要求に対していちいち説明するのは非常に困難な作業です。このため、ポイントを絞って安全であることの説明をする必要があります。

　システム設計の段階で非常に重要になるのが、前述した「システマチック故障への対策」や「ランダムハードウェア故障への対策」といった設計アプローチを使って設計の正しさを主張することです。

　例えば、規格の要求は、システマチック故障への対策として、システム設計に対する安全分析を強く推奨しています（表1）。

表1　システム設計の分析（Part4：7.4.3.1より）

　通常の設計では、幾度かのレビューや議論を経て最終的な設計書が残されていると思います。しかし、安全論証という観点から見ると、最終的な設計結果だけを示したのでは十分とはいえません。表1で要求している安全分析と、最終的な設計結果の関連を示すところまでを求められると考えるべきです。

　つまり、「なぜこのような設計になったのか？」といった設計根拠までを示せなければなりません。具体的には、安全分析を実施した結果とそこで識別された問題、それを解決するために考慮した設計箇所などが明確に関連していることを説明できるようにします（図3）。

図3　設計根拠の説明（安全分析と設計の関係）

　つまり、これだけの作業を実施した結果導き出したのが「最終的な設計」であり、これを基に「正しい設計である」ことを主張するのがこの段階での安全論証となります。従って、明確な戦略をもって設計作業を実施していなければ説明のつじつまが合わなくなります。設計者自身がこれまでの作業に不備はないかを確認する意味でも有効な作業ですから、今後ぜひ検討して頂きたいポイントです。

　以上がシステム設計のポイントになります。この後は、HW、SWに要求を割り付け、Part5のHW開発とPart6のSW開発へと作業が進みます。とはいえ、通常はこうした作業が上から下に順調に流れる訳ではなく、システムからHW、HWからシステム、HWからSW、SWからシステムといったように上下左右に行ったり来たりしながら進むことになるのが現実でしょう。ちなみに、ISO 26262はこの段階での完璧なシステム設計を要求しているわけではありませんので、こうした行ったり来たりの記録自体を安全論証のために使うという考え方もあるかもしれません。