Posts Tagged with "ASIL decomposition"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.

ASILデコンポジション

posted by sakurai on August 23, 2018 #55

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

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

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

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

つまり、要求も無しにエレメントのASILを決定することはできません。要求分解よりも先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。

ところで、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に

図55.1
図55.2

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

次に2.は規格Part9 5.4.6に

図55.3

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

図55.4

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

図55.5

それではどうすれば良かったのかといえば、規格に示すとおり、マイコンと冗長な安全要求を担保するエレメントを設け、マイコンと独立に実装すればマイコンはQMとできたはずです。冗長と言っても同じ機能を持つ対称冗長である必要はなく、〇〇の検出時にスイッチをオフする、というようなトランジスタでも構いません。低複雑度を持つ安全機構に高ASILを割り付けてASILデコンポジションする方式は、規格でも推奨しています。


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


ページ: