業界ではASILデコンポジションについての誤解が幅広くみられるため(経験では99%)、説明します。

ASILをいきなりエレメントに与えるのは誤り

あるティア1では、ECUを設計する際にOEMから安全目標を頂いたところ、ASIL-Cでした。走る曲がる止まるに関連し、もし故障した場合のリスク度合が高いため安全目標がASIL-Cとなっています。流用開発のためブロック図はだいたい固まっています。このティア1はASILデコンポジションを前提として、MCUは従来開発をキャリー(オーバー)したいので、MCUにQMを割り当てました。しかし、これは誤りです。

本来、安全目標があり、それをシステムレベルの初期安全要求に分解しますが、安全要求がASILの属性を持つことに注意してください。エレメントは安全要求を割り当てられてはじめてASIL値を持つことになります。

つまり、要求も無しにエレメントのASILを決定することはできません。要求分解よりも先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。この誤りは前述のように経験上99%の顧客に当てはまります。

ところで、ASIL-CのSPFMの目標値は97%以上と非常に高く、ほぼすべてのエレメントが故障検出されるといっても良いくらいです。また最高難度であるASIL-Dの99%以上と比べてほとんど違いが無いため、欧州ではASIL-CとASIL-Dは同様なプロセスやアーキテクチャを適用することが多いようです。

一方、この誤りの原因は理解でき、ソフトウェアは安全機構でバックアップした上で、なるべくQMで開発したいところです。そのためにISO 26262規格ではASILデコンポジション(ASIL分解)というテーラリング手段が用意されています。

ただし、ASILデコンポジションが可能なのは以下の2つの要件が満足されるときに限られます。

1. 安全要求の冗長性
2. 安全要求の割り当てられたエレメント間の独立性

まず、1.は規格Part9 5.4.4に

とあります。普通の場合、初期安全要求は複数の安全要求に分解され、分解された安全要求を合わせて初期安全要求を満足します。ASILデコンポジションは例外で、分解された安全要求は単独で初期安全要求を満足しなければなりません。備考にもあるようにこれは冗長性を意味します。これは、エレメントの機能失陥により一方の安全要求が達成されなくても、他方の安全要求が割り当てられたエレメントにより初期安全要求が担保されることを意味します。

次に2.は規格Part9 5.4.6に

とあるように、分解された安全要求が割り当てられたエレメントはお互いに独立でなければなりません。独立とは、Part9 5.4.11 b)にあるように、従属故障分析を行った上で、その故障原因を発見できない場合、あるいはコントロールされる場合という意味です。この従属故障とは、カスケード故障と共通原因故障の両者を意味します。

これら2つの要件をまとめて表すと次の規格要求となります。

それではどうすれば良かったのかといえば、$\img[-0.9em]{/images/withinseminar.png}$ このような方式は、規格でも推奨しています。

前のブログ 次のブログ