Article #55

既に発行済みのブログであっても適宜修正・追加することがあります。
Even in the already published blog, we may modify and add appropriately.

ASILデコンポジション

posted by sakurai on August 23, 2018

ASILデコンポジションについて、誤解が幅広くみられるため、説明したいと思います。

誤解の例1

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

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

つまり、要求も無しにエレメントのASILを決定することはできません。このティア1では、MCUは従来開発を踏襲したいのでMCUにQMを割り当てました。先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。

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

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

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

まず、1.は規格Part9 5.4.4に

図55.1
図55.2

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

次に2.は規格Part9 5.4.6に

図55.3

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

図55.4

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

図55.5

左矢前のブログ 次のブログ右矢

Leave a Comment

Your email address will not be published.

You may use Markdown syntax.

Please enter the letters as they are shown in the image above.
Letters are not case-sensitive.