備忘のために表題の「2nd SMのASILの引き下げ」について記します。ISO 26262ではセレクトハイ原則やFFI等の原則で、低ASILエレメントが高ASILエレメントに影響を及ぼすことが禁止されています。そのような場合は低ASILエレメントはASILを引き上げるべきです。

一方その原則の例外があり、有名なものは「ASILデコンポジション」です。ところでこの用語は厳密には正しくなく、本来は「要求分割(デコンポジション)により結果的にASILが分割される」ものであり、ASILを任意に分割するものではありません。

この他に表記の場合の例外があります。Part 4 6.4.2はシステム設計における安全機構の要件を示したもので、6.4.2.1及び6.4.2.2が「フォールトを検出及び機能安全要求を侵害するシステムの出力に存在する故障を防止又は緩和する安全機構」、つまり1st SMについての要件です。さらに6.4.2.3～6.4.2.5が「フォールトがレイテント状態になるのを防止する安全機構」、つまり2nd SMについての要件です。

ここで6.4.2.5において、2nd SMとしてのみ働くエレメントのASILは以下のように引き下げることが可能と書かれています。以下は規格に書かれていない文言をカッコ内に補って記述しています。

Part 4 - 6.4.2.5

• (IFまたは1st SMに)割りつけられた安全要求のASILがASIL-Dのとき、その2nd SMはASIL-B
• (IFまたは1st SMに)割りつけられた安全要求のASILがASIL-BまたはASIL-Cのとき、その2nd SMはASIL-A
• (IFまたは1st SMに)割りつけられた安全要求のASILがASIL-Aのとき、その2nd SMはQM

すなわち、ASIL-Bを除きASILを2段階引き下げることが可能です。ASIL-Bの時は1段階となります。

前のブログ 次のブログ

再度、重要項目の3項目めです。

ハードウェアメトリクスの目標値は、分解したからといって変わるものではない。多くの人はこのことを理解していない。

同感ですね。規格にはPart 9 5.4.5にこれが記されています(図781.1)。

規格5.4.5のDeepLによる翻訳を示せば、

5.4.5 ISO 26262-5 に従ったハードウェアアーキテクチャメトリクスの評価と、ランダムハードウ ェア故障による安全目標違反の評価に関する要件は、ASIL 分解によって変更されない。

これは弊社でもお伝えしている、ASIL分解に関する重要なノウハウの一つであり、ハードウエアの目標値を変えない理由についての動画の解説は以下のとおりです。

フォールト・ツリー解析の観点で考えてみると、本当に独立した2つの並列パスがある場合、これらはAND接続される。数学的には、それぞれの故障率が少し高くなり、さらに故障率が少し高くなっても、一番上の故障率が低くなるというのは、利点になる。したがって、フォールトツリーの最上位イベントは変わらないが、定量的安全性解析を実行すればメリットが得られる。

「故障率が少し高くなる」とは何を言っているかわかりませんが、端的に言えば、

• 冗長な独立性のあるエレメントの故障確率を(FTAにより)算出すれば、故障確率の掛け算になるため目標値を下げなくても故障確率のほうが下がるため、目標値を下げる必要は無い

し、かつ下げてはならないということです。

具体例として、故障率$\lambda$=100[FIT]の対称な冗長チャネル(両チャネルの故障率が等しい)について車両寿命10万時間で考えます。単体チャネルでは100[FIT]ですが、2重故障(同時故障ではない)を考えると、

$$100[FIT]\cdot100[FIT]\cdot10\times10^4[H]=1.0\times10^{-7}\cdot1.0\times10^{-7}\cdot1.0\times10^5\\ =100\times10^{-9}\cdot\frac{1}{100}=100[FIT]\cdot\frac{1}{100}$$

となり、すなわち、元の100[FIT]の100分の一の1[FIT]となります。つまり、ASILや目標値を下げなくても(ASILデコンポジションの必須条件である)冗長構成によりサブシステムの故障率は1/100にできたと言えます。

前のブログ 次のブログ

同じ技術者の解説動画です。こちらには基本的に誤りはありません。2分間の動画で重要な事を3項目押さえているのでご紹介します。

英語のトランスクリプトを入手したので、画面と合わせて見てみましょう。以下はDeepLによるその翻訳です。

今回は、分解についてよく見られる誤解について少しお話ししたい。まず第一に、ISO26262で分解について話す場合、安全要件の分解について話している。ハードウェアを分解するわけでもなく、ソフトウェアを分解するわけでもなく、安全目標そのものを分解するわけでもない。分解するのは、ハードウェア安全要求事項、ソフトウェア安全要求事項、技術安全要求事項、FSRである。安全要件を分解することで、ハードウェアの独立した並列パスやソフトウェアの独立した並列パスが生まれる。これがよく見られる誤解のひとつだ。

ややはっきりしないところがありますが、好意的に解釈すれば最初に2つの重要な事項を述べています。

• ASIL分解は本当はASILを分解するのではなく、安全要求を分解し、その結果としてASILが分解「される」
• ASIL分解の原則である冗長性と独立性

引用の最後の部分、

安全要件を分解することで、ハードウェアの独立した並列パスやソフトウェアの独立した並列パスが生まれる。これがよく見られる誤解のひとつだ。

これがどう誤解なのかははっきりしません。ただ、ASIL分解の原則はさらっと述べていますが、以下の2つが重要です。これは規格の必須要求事項です。

• 冗長な安全要求に分解(動画では並列と表現)
• 安全要求が割り当てられたエレメントの独立性(動画では独立と表現)

次に、

もうひとつは命名法についてだ。命名法の重要な側面のひとつは、例えばASIL Dの安全要件まで構築する場合、ASIL Bのハードウエアを2つ使用するのであれば、それらのハードウエアにはASIL B of Dという命名法を使用しなければならないということだ。

いわゆるASIL-B(D)のような記法については、命名法が大事というよりは以下が重要です。これが3項目めです。

ハードウェアメトリクスの目標値は、分解したからといって変わるものではない。多くの人はこのことを理解していない。

前のブログ 次のブログ

不当な仮定1

正しく引用されたことは良かったのですが、本論文$\dagger$では弊社の式に対して新たに以下の(12)という仮定を加えており、残念なことにこれでは一般性を失う不要な仮定です。

$$ \lambda_{m,MPF}=\lambda_{sm,MPF}=\lambda_{MPF}=\lambda_{D}\tag{12} $$

この(12)の意味するところは"m"も"sm"も同じ故障率を持つこと、すなわち対称冗長を意味しており、これは特殊な場合に限られます。

反例を示すと、例えば過去記事の図70.1に示すヘッドライト装置の実例のように、

メカスイッチからのON信号をメインのチャネルではマイコンで点灯し、バックアップチャネルではトランジスタで点灯するような非対称冗長には(12)は当てはまりません。以下のように"m"系の故障率のほうが"sm"系よりも巨大になるためです。 $$ \lambda_{m,MPF}\gg\lambda_{sm,MPF} $$ さらに言えば、このような非対称冗長は、特にASIL分解においては、規格ではむしろ推奨されています。マイコンに低いASILを割り当てておき、複雑なシステムの開発を容易にできる一方、壊れにくい単純なトランジスタで元の安全要求を保証できるためです。

不当な仮定2

さらに別の仮定の問題があります。弊社の式における2nd SMの検査周期である$\tau$について、$\tau=T_{lifetime}$と仮定してしまったことです。これは2nd SMが存在しないか、あるいはDCがゼロであることを意味します。これは誤った仮定です。

なぜそうしたかはその箇所には書かれていませんが、アンリペアラブルという仮定を置いているのが後からわかります。

$\dagger$E. Rogova, C. Nowak, M. Ramold, et al., "Comparison of Analytical Formulas of PFH and PMHF Calculation for M-out-of-N Redundancy Architecture," Europ. Safe. Reliab. Conf.,, pp.1-5, 2019

前のブログ 次のブログ