イントロダクション

PMHF論文das2016$\dagger$の続きです。

FTAの説明とフレームワークの必要性を述べています。

Fault Tree Analysis (FTA) is a method often proposed for calculation of the PMHF in real-world systems. However, FTA is a very general method, subject to a wide range of interpretations and techniques depending on the objectives of a given problem, the type of failures & faults being considered, and the terminology employed by various industries. There is not yet an accurate and well-explained practical guide to the specific techniques appropriate for PMHF calculation in the automotive industry. For example, large and complex systems, such as those that comprise real-world automotive products, are often difficult to capture in an FTA in a systematic and repeatable way. The use of diagnostic coverage (D.C.) (e.g., by an imperfect safety mechanism which may detect some but not all element faults) is often utilized in hardware metric calculations. However, D.C. concepts are not widely clarified in the industry literature, leaving a gap in understanding for many FTA practitioners. At lower levels of the FTA, specific frameworks for calculating the effect of single-point and dual-point faults (including dual-point latent faults) are necessary to obtain a correct PMHF estimation. All these topics will be addressed here along with a worked automotive example.

フォールトツリー解析(FTA)は、実世界のシステムにおけるPMHFの計算のためにしばしば提案される手法です。しかし、FTAは非常に一般的な手法であり、与えられた問題の目的、考慮される故障や故障の種類、そして様々な業界で採用されている用語に応じて、幅広い解釈や技術の対象となっています。自動車産業におけるPMHF計算に適した特定の技術については、正確かつ十分に説明された実用的なガイドはまだ存在しません。例えば、実際の自動車製品を構成するような大規模で複雑なシステムは、体系的で再現性のある方法でFTAに取り込むことが困難な場合が多い。診断カバレッジ（D.C.）（例えば、一部の要素の故障は検出できるが、すべての要素の故障は検出できない不完全な安全機構）の使用は、しばしばハードウェアメトリックの計算に利用されます。しかし、D.C.の概念は業界の文献では広く明確にされておらず、多くのFTA実務者にとっては理解にギャップがあります。FTA の低レベルでは、正しい PMHF 推定を得るためには、単点および二点故障（二点潜伏故障を含む）の影響を計算するための特定のフレームワークが必要となります。ここでは、これらすべてのトピックについて、実際の自動車の例を挙げながら解説します。

---

$\dagger$N. Das and W. Taylor, "Quantified fault tree techniques for calculating hardware fault metrics according to ISO 26262," 2016 IEEE Symposium on Product Compliance Engineering (ISPCE), Anaheim, CA, 2016, pp. 1-8, doi: 10.1109/ISPCE.2016.7492848.

---

前のブログ 次のブログ

イントロダクション

PMHF論文das2016$\dagger$の続きです。

以下の段落はISO 26262の概要です。

The international standard ISO 26262 “Road vehicles - Functional safety” has been released in final form since late 2011 [1]. It provides a standardized set of processes and methods to assure the functional safety of electrical and electronic systems in the automotive domain. The standard is an evolution of the IEC 61508 functional safety standard, applied specifically to the automotive realm [2].

国際規格ISO 26262「道路運送車両-機能安全」は、2011年後半から最終版としてリリースされている[1]。この規格は、自動車分野における電気・電子システムの機能安全を保証するためのプロセスと手法を標準化したものである。この規格は、IEC 61508の機能安全規格を発展させたもので、特に自動車分野に適用されている[2]。

以下の段落はISO 26262の説明です。

ISO 26262 requires a variety of processes and frameworks for safety management, safety concept development, requirements flow-down, and verification & validation activities. The standard also requires quantified metrics to be calculated for safety-related systems.

ISO 26262 は、安全管理、安全コンセプト開発、要求事項のフローダウン、検証・検証活動のためのさまざまなプロセスやフレームワークを要求している。また、安全関連システムの定量化されたメトリクスの計算も要求している。

以下の段落はPMHFの説明です。

Of particular interest is the Probabilistic Metric for Hardware Failure (or PMHF), which represents a calculated estimate of the rate of hazard occurrence due to random hardware failures. This value must be calculated for systems rated at a high Automotive Safety Integrity Level (or ASIL2). Specifically, systems rated at ASIL C or ASIL D must achieve targets such as those proposed by the standard and listed in Table 1.

特に関心が高いのは、ハードウェア故障の確率的指標（PMHF）であり、これは、ランダムなハードウェア故障によるハザード発生率の計算された推定値を表している。 この値は、高いAutomotive Safety Integrity Level（またはASIL2）で評価されたシステムのために計算されなければならない。具体的には、ASIL C または ASIL D に格付けされたシステムは、規格で提案され、表 1 に記載されているような目標を達成しなければならない。

---

$\dagger$N. Das and W. Taylor, "Quantified fault tree techniques for calculating hardware fault metrics according to ISO 26262," 2016 IEEE Symposium on Product Compliance Engineering (ISPCE), Anaheim, CA, 2016, pp. 1-8, doi: 10.1109/ISPCE.2016.7492848.

---

前のブログ 次のブログ

次にPMHF論文das2016$\dagger$です。この論文は弊社の論文を除き、例外的に1st edition Part10に掲載されているPMHF式に準拠しているものです。それだけでなく、FTAによりPMHF式をどのように実装するかが述べられている実践的なものです。残念ながら、2nd edition発行前の論文であるため、1st editionの範囲でしかなく、冗長サブシステムに対応する形式にはなっていません。

アブストラクト

早速アブストラクトを見てみます。

Since its introduction in 2011, the ISO 26262 standard has provided state-of-the-art methodology for achieving the functional safety of automotive electrical and electronic systems. Among other requirements, the standard requires estimation of quantified metrics such as the Probabilistic Metric for Hardware Failure (PMHF) using quantitative failure analysis techniques. While the standard provides some brief guidance, a complete methodology to calculate the PMHF in detail has not been well described in the literature. This paper will draw out several key frameworks for successfully calculating the probabilistic metric for hardware failure using Fault Tree Analysis (FTA). At the top levels of the analysis, methods drawn from previous literature can be used to organize potential failures within a complex multifunctional system. At the lower levels of the FTA, the effects of all fault categories, including dual-point latent and detected faults, can be accounted for using appropriate diagnostic coverage and proof- test interval times. A simple example is developed throughout the paper to demonstrate the methods. Some simplifications are proposed to estimate an upper bound on the PMHF. Conclusions are drawn related to the steps and methods employed, and the nature of PMHF calculation in practical real-world systems.

ISO 26262規格は、2011年に導入されて以来、自動車の電気・電子システムの機能安全性を実現するための最先端の方法論を提供してきた。他の要求事項の中でも、定量的な故障解析技術を用いて、ハードウェア故障の確率的指標（PMHF）のような定量的な指標を推定することが求められている。この規格では、いくつかの簡単なガイダンスを提供しているが、PMHF を詳細に計算する完全な方法論は、文献に十分に記載されていない。この論文では、Fault Tree Analysis（FTA）を使用してハードウェア故障の確率的メトリックを計算するためのいくつかの重要なフレームワークを紹介する。解析の最上位レベルでは、複雑な多機能システム内の潜在的な故障を整理するために、これまでの文献から導き出された手法を使用することができる。FTA の下位レベルでは、デュアルポイントの潜在故障と検出された故障を含むすべての故障カテゴリの影響を、適切な診断カバレッジとプルーフテスト間隔時間を使用して説明することができる。本論文では、この方法を実証するために、全体を通して簡単な例を示している。PMHFの上限値を推定するために、いくつかの単純化を提案した。また、採用されたステップと手法、及び実用的な実世界のシステムにおけるPMHF計算の性質に関連した結論が示されている。

このアブストラクトに書かれているように、ISO 26262 Part 10ではPMHF式の結果しか書かれておらず、導出過程が書かれていません。さらに初版にはあった定量FTAによるPMHFの計算方法が、なぜか第2版では削除されています。従って、定量FTAによる正確なPMHF計算フレームワークは業界で必要とされており、それが今回弊社からRAMS 2021に投稿した論文です。これは現時点では非公開であるため、来年1月のRAMS 2021での発表以降に公開する予定です。

【追記】RAMS 2021において、A Framework for Performing Quantitative Fault Tree Analyses for Subsystems with Periodic Repairsとして発表済みです。

---

$\dagger$N. Das and W. Taylor, "Quantified fault tree techniques for calculating hardware fault metrics according to ISO 26262," 2016 IEEE Symposium on Product Compliance Engineering (ISPCE), Anaheim, CA, 2016, pp. 1-8, doi: 10.1109/ISPCE.2016.7492848.

---

前のブログ 次のブログ

Fault Tree図

次に論文中のFault Tree図を検証します。

図284.1に、論文中でFault Tree図と書かれている図を示します。図の中にあるように、これは故障率を示す図だそうですが、本来Fault Treeは確率図であるため、これは誤りです。

図284.1 論文中のFault Tree図 また、良くある誤りとして、故障率の2乗を計算しています。故障率の2乗の次元は$[1/H^2]$となるため、図284.1のように故障率$[1/H]$と足すことは、次元が合わないためできません。両辺を無次元の確率に直してから計算します。正しくは、 $$ \require{cancel} \lambda_\text{S}\bcancel{T_\text{lifetime}}=\lambda_\text{fD}\bcancel{T_\text{lifetime}}\cdot\lambda_\text{dUD}T_\text{lifetime}+\lambda_\text{fUD}\bcancel{T_\text{lifetime}}\\ \therefore\lambda_\text{S}=\lambda_\text{fD}\lambda_\text{dUD}T_\text{lifetime}+\lambda_\text{fUD} $$ となります。従って、$\lambda_\text{fUD}T_\text{lifetime}$がSPF/RF確率を、$\lambda_\text{fD}T_\text{lifetime}\cdot\lambda_\text{dUD}T_\text{lifetime}$がDPF確率を表すため、論文の式はDPF確率を過剰に低く評価しています。

さらに、次のFault Tree図は故障率も確率も(確立も)まぜこぜになっています。

図284.2 論文中のFault Tree図2

本来PMHFはハードウエア故障確率の目標値であるため、ソフトウエアについては故障確率で評価するのはおかしいのですが、ハードもソフトもまぜこぜになっています。

本論文の目的はASILデコンポジションにおける独立性の検討のようですが、独立性はIEC 61508-6のβファクタとして検討されており、それを適用すれば良いことになっています。もっともIEC 61508は化学プラントが対象のようであり、Part6のβファクタは非常に適用しにくいのですが、車載用電子機器のβファクタ表が無いため、これを援用するしかありません。

元に戻してASILデコンポジションは過去記事で検討していますが、以下の2つの要件が重要なので、再掲します。これに触れられていないデコンポジション議論には意味がありません。

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

---

前のブログ 次のブログ

元に戻って最初の論文を見てみたいと思います。元の論文のFTはLFが考慮されていないものでした。これに対して、前稿において、ワーストケース評価をするため、2nd SMのDC(Diagnostic Coverage)をゼロとして評価しました。

これに対して2nd SMのDCを考慮したらどうなるかを前稿と同様の考え方でやってみます。数式やFTの書き換えルールは基本的に前稿を踏襲しますが、IFUモデルとIFRモデルで数式が異なります。いずれにせよ、$K_\text{SM,MPF}=0$とおいたところに仮に$K_\text{SM,MPF}=0.6$と仮定して計算します。

すると、係数$C_\text{SM,MPF}=0.5368$となり、この係数をEBMとOn-line monitorのDPF項に掛けることになるため、そのFTは図219.1のようになります。

図219.1 Fault Tree

図219.2に図219.1のFTの拡大図を示します。C100として上記係数0.5368をかけています。

図219.2 Fault Treeの拡大

MCS分析を実施すると、42個のMCが得られ、3個以上のエレメント故障をカットすると、24個のMCが残ります。結果として、全く変化はありませんでした。

今回カットされた積項を表219.1に示します。加えた定数(赤字)は全て3点故障以上の積項に掛けられており、全てカットされています。ただし、カットされた積項は18個のはずですが、ツールのバグか17個となっています。

表219.1 図219.1のMCSのカット部分

得られたMCSを表219.2に示します。エレメント故障は2以下のみであり、定数を青字で示しています。

表219.2 図219.1のMCS

元々2 outof 4という変則的な2冗長内部のSMなので、IFとSMのANDはそれだけで4エレメント故障の積項となります。従って、この積項に何を追加しても元々消えるべき項でした。

RAMS 2021において、PMHF式に基づくFTA構築法の論文発表が終了したため、本記事を開示します。

---

前のブログ 次のブログ

参照論文では、前提が誤っている$\dagger$ものの、2nd Edition規格式に近い形でFTを構成しているようです。例えば、AのRFが先に起きて、BのSPF/RFが後から起きる場合と、その逆パターンのORとなっています。一方、規格式ではAのLFが先に起きて、BのSPF/RFが後から起きる場合と、その逆パターンのORとなっています。従って、参照論文のRFをLFと読み替えれば、規格式と結果的に同じになります。

$$ \begin{eqnarray} \Pr\{\text{TOP Failure}\}&=&M_\text{PMHF}T_\text{L} \\ &=&\frac{1}{2}\lambda_\text{E1}\left[(1-K_\text{E1,MPF})T_\text{L}+K_\text{E1,MPF}\tau\right]\cdot \lambda_\text{E2}T_\text{L} \\ &+&\frac{1}{2}\lambda_\text{E2}\left[(1-K_\text{E2,MPF})T_\text{L}+K_\text{E2,MPF}\tau\right]\cdot \lambda_\text{E1}T_\text{L}\\ &=&\frac{1}{2}(\lambda_\text{E1}T_\text{L})(\lambda_\text{E2}T_\text{L})\left(2-K_\text{E1,MPF}-K_\text{E2,MPF}+(K_\text{E1,MPF}+K_\text{E2,MPF})\cdot\frac{\tau}{T_\text{L}}\right)\\ &=&(\lambda_\text{E1}T_\text{L})(\lambda_\text{E2}T_\text{L})C_\text{1, 2}' \end{eqnarray} $$

今回のE1, E2のペアで$C_\text{1, 2}'$を計算したところ、表218.1に示すようにC10からC19の10種類の定数が得られました。

表218.1

定数記号	定数値
C10	0.23572
C11	0.27046
C12	0.30520
C13	0.38626
C14	0.42100
C15	0.53680
C16	0.61786
C17	0.65260
C18	0.76840
C19	1.00000

よって、2AND項にそれぞれこの定数項を加えて3ANDとすれば、図218.1のようなFTとなります。

図218.1 Fault Tree このMCSを取得したところ、表218.2のような結果となりました。 表218.2 図218.1のFTのMCS 頂上事象侵害確率は$1.159\times 10^{-3}$、PMHFは77.3[FIT]となりましたが、これは真値に対して38%もの過大評価となっています。

---

$\dagger$前稿でご説明したように、冗長チャネル内のSMは、2nd order SMなので、冗長チャネル内のエレメントの故障の場合は、RFではなくLFとなります。参照論文ではRF、LFの両方が起きると考えています。

---

前のブログ 次のブログ

この結果はワーストケースの評価であり、2nd order SMを無視しているものです。従って、この結果をより実際に近づけるには、2nd order SMのDCをFTに入れる必要があります。

まず、数式で書けば、 $$ \begin{eqnarray} \Pr\{\text{TOP Failure}\}=M_\text{PMHF}\cdot T_\text{L}&=&(\lambda_\text{E1}T_\text{L})(\lambda_\text{E2}T_\text{L}) \left[ (1-K_\text{MPF})+K_\text{MPF}\cdot \frac{\tau}{T_\text{L}} \right]\\ &=&(\lambda_\text{E1}T_\text{L})(\lambda_\text{E2}T_\text{L})C_\text{1, 2} \end{eqnarray} $$ ただし $$ K_\text{MPF}=1-(1-K_\text{E1,MPF})(1-K_\text{E2,MPF}) $$ $C_\text{1, 2}$はE1, E2に依存する定数で、 $$ C_\text{1, 2}\equiv(1-K_\text{MPF})+K_\text{MPF}\cdot \frac{\tau}{T_\text{L}} $$

車両寿命$T_\text{L}=15,000[H]$、定期検査周期$\tau=3,420[H]$として、今回のE1, E2のペアで$C_\text{1, 2}$を計算したところ、表217.1に示すようにC1からC9の9種類の定数が得られました。

表217.1

定数記号	定数値
C1	0.2280772
C2	0.2287720
C3	0.2310880
C4	0.2357200
C5	0.2588800
C6	0.3052000
C7	0.3515200
C8	0.5368000
C9	1.0000000

よって、2入力AND項にそれぞれこの定数項を加えて3ANDとすれば、図217.1のようなFTとなります。今回はマニュアル作業により付加しましたが、モデルもしくはツールを開発した暁には自動的に計算が行われる見込みです。

図217.1　2nd order SM効果を追加したFault Tree

このMCSを取得したところ、表217.2の表のような結果となりました。

表217.2　図217.1のMCS

頂上事象侵害確率は$8.321\times 10^{-4}$、PMHFは55.5[FIT]となりました。このように2nd order SMの効果を入れると、PMHFは25%まで低減することがわかります。

RAMS 2021において、PMHF式に基づくFTA構築法の論文発表が終了したため、本記事を開示します。

---

前のブログ 次のブログ

前稿で作成したFTLをSAPHIREにインポートすると、図216.1のようなFTが構成されます。MCSの論理式で示されるとおり、2入力ANDの積項が40個、ORで接続されています。

図216.1 MCSのFault Tree

検証としてこのFTのMCSを確認しますが、当然前々稿と同一のMCSになるはずです。MCS前後で論理は変化しません。表216.1に得られたMCSを示します。

表216.1 MCSのFTをさらにMCS

この頂上事象侵害確率は$3.380\times 10^{-3}$、PMHFは、225[FIT]となりましたが、前回の結果と同一です。

---

前のブログ 次のブログ

SAPHIREのFTL(Fault Tree Language)の文法を図215.1に示します。これで見ると分かるように、ゲートの記述がコメントとして書けるようです。

図215.1 FTLのフォーマット ただし、このように記述しインポートしても、モデルは作成されますがゲートの説明等の記述は入りませんでした。さらに、基事象は全てtoolにより作成済みである必要があります。

調べてみると、FTLのインポートではなく、MAR-D(各種データ)の一括インポートにより、完全なFTが構成できるようです。

図215.2 ターゲットのFT 例えば、図215.2のFTをFlat File (ASCII File)で入力しようとすると、

• .BED --- Basic Eventの説明等の記述
• .BEI --- Basic Eventの情報、故障率やミッション時間等
• .FTD --- Fault Treeの説明等の記述
• .FTL --- 木の構造
• .GTD --- Top Event、中間ゲートの説明等の記述

の5種が少なくとも必要なようです。図215.3～215.7の構文ファイルを用意し、そのリストを図215.8のMARDファイルとしてMARDをloadすると、図215.2のFTが生成されました。

図215.3のBEDは基事象の定義で、3種類の基事象の名前と説明を記述します。

TEST =
* Name , Descriptions , Project
BE01 , Failure of 01 , TEST
BE02 , Failure of 02 , TEST
BE03 , Failure of 03 , TEST

図215.3 ターゲットFT用BED

図215.4のBEIは基事象の故障モデル、故障率、ミッション時間を記述します。赤字は故障率、青字はミッション時間です。

TEST =
* Name ,FdT,UdC ,UdT, UdValue, Prob, Lambda, Tau, Mission, Init,PF, UdValue2, Calc. Prob, Freq, Analysis Type , Phase Type , Project
BE01 , 3, , , , , 1.234E-009, , 1.000E+005, , , , , , , ,
BE02 , 3, , , , , 2.345E-009, , 1.000E+005, , , , , , , ,
BE03 , 3, , , , , 3.457E-009, , 1.000E+005, , , , , , , ,

図215.4 ターゲットFT用BEI ここで、図215.4中のFdtは、表215.1(一部のみ)により規定される故障計算タイプです。 表215.1

故障計算タイプ記号	故障計算タイプ説明
V	数値事象
1	確率
3	指数分布($1-e^{^-\lambda t}$)

図215.5にFT全体の定義として、FTDとして名前と説明を記述します。

TEST=
* Name , Description, Project
TOP ,PVSG of top , ,TEST

図215.5 ターゲットFT用FTD

図215.6にFTの木構造であるFTLを記述します。これは図215.1に文法が書かれています。

TEST, TOP =
TOP OR TOP01 BE03
TOP01 AND BE01 BE02

図215.6 ターゲットFT用FTL

図215.7のGTDにゲートの名前と説明を記述します。

TEST=
* Name , Description, Project
TOP ,PVSG of top , ,TEST
TOP01 , DPF of 01 and 02 , ,TEST

図215.7 ターゲットFT用GTD

上述のように、TESTフォルダのSubsフォルダに、各種ファイルをまとめ、一括ロードするためのリストです。

TEST_Subs\TEST.BED
TEST_Subs\TEST.BEI
TEST_Subs\TEST.FTL
TEST_Subs\TEST.FTD
TEST_Subs\TEST.GTD

図215.8 ターゲットFT用MARD

ここで調査している理由は、SAPHIRE等のFTA toolによりPMHFを正しく計算させたいためです。FTA toolによりPMHFを正しく計算させる手法には2種類あります。

• モデルがPMHF計算に対応　------------　モデルがPMHF計算に対応していれば、パラメータを入力するだけで、モデルがPMHF式を正しく計算します。
• モデルがPMHF計算に非対応　------------　しかしながら、一般的にはモデルがPMHF計算に対応していないため、ユーザがPMHF式に沿うようにFTを組み上げる必要があります。プログラムでFTのサブツリーが自動生成できれば、その労力が大幅に軽減されます。

---

前のブログ 次のブログ

次に、MCSの表から逆にFTを構成します。その理由はFTA tool上でMCSのモデルを修正できるようにするためです。

SAPHIREにおいてFTをインポートするにはFTL(Fault Tree Language)が必要です。そのために、MCSをまずExcel形式でエクスポートし、それをテキストエディタで修正し、以下に示すFTLフォーマットに変換します。

TOP2,TOP-MCS2=
TOP-MCS2 OR TMP1 TMP2 TMP3 TMP4 TMP5 TMP6 TMP7 TMP8 TMP9 TMP10 TMP11 TMP12 TMP13 TMP14 TMP15 TMP16 TMP17 TMP18 TMP19 TMP20 TMP21 TMP22 TMP23 TMP24 TMP25 TMP26 TMP27 TMP28 TMP29 TMP30 TMP31 TMP32 TMP33 TMP34 TMP35 TMP36 TMP37 TMP38 TMP39 TMP40
TMP1 AND M1 M2
TMP2 AND M1 SC2
TMP3 AND SC1 SC2
TMP4 AND M2 SC1
TMP5 AND SA1 SA2
TMP6 AND M1 MCU2
TMP7 AND M2 MCU1
TMP8 AND MCU1 SC2
TMP9 AND MCU2 SC1
TMP10 AND MCU1 MCU2
TMP11 AND I2 M1
TMP12 AND I1 M2
TMP13 AND I1 SC2
TMP14 AND I2 SC1
TMP15 AND I1 MCU2
TMP16 AND I2 MCU1
TMP17 AND I1 I2
TMP18 AND M2 P1
TMP19 AND M1 P2
TMP20 AND P1 SC2
TMP21 AND P2 SC1
TMP22 AND MCU2 P1
TMP23 AND MCU1 P2
TMP24 AND I2 P1
TMP25 AND I1 P2
TMP26 AND D2 M1
TMP27 AND D1 M2
TMP28 AND D1 SC2
TMP29 AND D2 SC1
TMP30 AND D1 MCU2
TMP31 AND D2 MCU1
TMP32 AND D2 I1
TMP33 AND D1 I2
TMP34 AND P1 P2
TMP35 AND CA2 SA1
TMP36 AND CA1 SA2
TMP37 AND D2 P1
TMP38 AND D1 P2
TMP39 AND D1 D2
TMP40 AND CA1 CA2

---

前のブログ 次のブログ