この論文でも、ターゲットの目標値はPMHFとなっていますが、算出において規格のPMHF式を尊重していません。サブシステムの不信頼度を $$F(t)=1-e^{-\lambda t}$$ との式で計算しており、これは修理可能性を考慮していないことを表しています。ただし、前論文とは異なり図206.1の赤で示すように、$\lambda_{RF}=(1-DC)\lambda$は計算に入っているのでましです。ただし、RFと書かれていますが、後で説明するように、これはLFです。1点故障は全て冗長相手チャネルによりVSG抑止されるので、100%レイテントとなるためです。

図206.1 故障率

再度整理すると、正しい考え方は、

1. E1及びE2の2つのエレメントにより構成される冗長系は、マルコフ連鎖で表される。
2. E1、E2それぞれのエレメントは修理可能(つまり不信頼度$F(t)$ではなく、不稼働度$Q(t)$となる)
3. PMHF式はこれらを考慮し、系の車両寿命における平均不稼働確率Q(T)を表したものであり、 PMHF式に基づきFault Treeを構成する

でなくてはなりませんが、参照論文はこのうち、2.及び3.が満足されていません。

このように専門家であっても同じような誤りを起こす原因は、規格が理解しやすく書かれていないためだと考えます。ただ、規格屋さんに言わせれば、「規格は論文でもなければ教科書でもない」とのことなので、分かりやすさは追究していないようです。そのためこのような解説ブログの存在意義があります。

---

前のブログ 次のブログ

次は前回紹介した論文も参照している論文$\dagger$です。本稿ではこれを参照論文といいます。 参照論文の対象は冗長構成のEPSですが、まず一般的な完全冗長サブシステムで議論します。

図205.1　完全冗長サブシステム

参照論文もPMHF式を使用していません。その代わりに定量FTAのそれぞれの基事象において確率が時間変化する、つまり確率過程であることをマルコフチェインを組み合わせて解いています。図205.2に参照論文の概念図を示します。これは論文中には無く、弊社が作成したものですが、前述の言葉で説明したものを図化したものです。

図205.2 論文の概念図

マルコフチェインを用いる考え方は概ね正しいものの、実はマルコフチェインを用いてPMHFを求めたものが、規格のPMHF式であり(ブログ記事#102～109を参照)、PMHF式に従えばこの定期検査修理を含む確率過程を織り込んだものとなっているため、再度基事象を確率過程として捉える必要はありません。

上で概ねと書いた部分ですが、本来マルコフチェインは修理を考慮する必要があります。SM1 (1st order SM)が先に故障する場合、SM2 (2nd order SM)により定期検査を受け、故障が検出された場合は直ちにゼロ時間で修理されるのが、ISO 26262の考え方です。ということは'1'の状態から'00'状態に戻る場合が存在します。

---

$\dagger$ https://www.researchgate.net/publication/323450274_A_mixed_model_to_evaluate_random_hardware_failures_of_whole-redundancy_system_in_ISO_26262_based_on_fault_tree_analysis_and_Markov_chain

---

前のブログ 次のブログ

書き換えたFTの評価

図202.1に対して図203.1の書き換えを適用したものが図204.1のFTです。このFTに対してカットセット分析を実施し、TOP事象の確率を求めます。

図204.1 弊社提案のEBDサブシステムのFT(ワーストケース)

同様にツールを用いてMCSを求めると、MC数は42個に増加します。しかし前述のように、これには3個以上のエレメント故障が含まれるためツールで削除します。すると、表204.1のように24個のMCが得られ、TOP事象の確率は$4.35\times 10^{-5}$、PMHFは8.70[FIT]となります。表204.1中のC_DC_OL_MONは、1からオンラインモニタのDCを引いた定数であるため、これはエレメント故障数にカウントされません(青字で定数を表示)

表204.1 図204.1のFTのMCS

このように、PMHF式を尊重せず、LFを見逃しDPFのみとすることで、2.7倍も故障確率を甘く(低く)見る事になります。保守的に(高く)見積もるのであれば安全側なのでOKですが、不稼働確率の過小評価は危険側のため、良くありません。

再度整理すると、正しい考え方は、

1. E1及びE2の2つのエレメントにより構成される冗長系は、マルコフ連鎖で表される。
2. E1、E2それぞれのエレメントは修理可能(つまり不信頼度$F(t)$ではなく、不稼働度$Q(t)$となる)
3. PMHF式はこれらを考慮し、系の車両寿命における平均不稼働確率Q(T)を表したものであり、 PMHF式に基づきFault Treeを構成する

ですが、参照論文はこのうち、2., 3.が満足されていません。1.は当然なので、ほとんどが間違いということになります。

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

---

前のブログ 次のブログ

保守的なPMHF式

さらに、参照論文では不信頼度 $$F(t)=1-e^{-\lambda t}$$ を用いた非修理系として扱っていますが、これはISO 26262の考え方と合いません。規格では主機能と安全機構のDPFまで考慮する必要があり、安全機構は修理可能として扱います。そのため2nd order SMが必要であり、周期的な検出(検出周期=$\tau$)と修理(検出カバレッジ=$K_\text{SM,MPF}$)が前提となります。修理系において不信頼度$F(t)$は不稼働度$Q(t)$となり、

$$Q(t)=(1-K_\text{SM,MPF})F(t)+K_\text{SM,MPF}F(t\bmod\tau)\\ =(1-K_\text{SM,MPF})(1-e^{-\lambda t})+K_\text{SM,MPF}(1-e^{-\lambda(t\bmod\tau)})$$ これからPMHFを求めると、

$$M_\text{PMHF}=(1-K_\text{IF,RF})\lambda_\text{IF}+K_\text{IF,RF}\lambda_\text{IF}\lambda_\text{SM}[(1-K_\text{SM,MPF})T_\text{lifetime}+K_\text{SM,MPF}\tau]$$

ここでワーストケースを考え、2nd order SMが無い(カバレージがゼロ、$K_\text{SM,MPF}=0$として評価します。これは保守的な評価です。すると、上式のPMHFは、

$$M_\text{PMHF}=(1-K_\text{IF,RF})\lambda_\text{IF}+K_\text{IF,RF}\lambda_\text{IF}\lambda_\text{SM}T_\text{lifetime}\\ =\lambda_\text{IF}[(1-K_\text{IF,RF})+K_\text{IF,RF}\lambda_\text{SM}T_\text{lifetime}]$$ 従って、基本的にFTはこの評価式を実装することになります。

FTの書き換え

参照論文ではLFを考慮せずに、単純にDPFとしていましたが、上記のようにLFを考慮したほうが正確です。これを確率式で表せば、

$$(\lambda_\text{IF}T_\text{lifetime})(\lambda_\text{SM}T_\text{lifetime})\to(\lambda_\text{IF}T_\text{lifetime})[(1-K_\text{IF,RF})+K_\text{IF,RF}(\lambda_\text{SM}T_\text{lifetime})]$$

となり、図203.1のFTの書き換えのように構成します。図の左は参照論文のFTであり、右は変更後のFTです。

図203.1 DPFの書き換え(LFを追加)

FTAツールは確率で取り扱い、ミッション時間の計算は自動的に行われるため、明示的に$T_\text{lifetime}$を掛ける必要はありません。

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

---

前のブログ 次のブログ

参照論文の問題点

参照論文では、EBDノードを含めた全体について、定量的にFault Treeを用いたMCS(Minimal Cut Set)分析を行っており、問題は2つあります。

• ISO 26262規格のPMHF式を参照していない
• On-lineモニタのカバレッジが参照されていない。

この2つは関連する問題です。具体的に表202.1のとおり数値を入れてみてみます。On-lineモニタは参照論文に数値が無かったため、SMとして低めの数値を入れました。

表202.1

Subsystem	Component	Failure Rate [1/h]
EBD Node	Brake ECU	$3.3\times 10^{-7}$
	Electronics Brake Module (EBM)	$4.2\times 10^{-7}$
	On-line monitor for EBM	$1.1\times 10^{-7}$

誤ったFTA

この数値に基づき、参照論文のEBDサブシステムのFTをツール(SAPHIRE)により構成すれば、図202.1のようになります。

図202.1 参照論文のEBDサブシステムのFT

誤ったMCS

図202.1は論文のFTですが、このFTに対してカットセット分析を実施し、EBDサブシステムの故障確率を求めます。ツールを用いてMCSを求めると、表202.2のように24個の積項(Minimal Cut)が得られ、EBDサブシステムの故障確率は$1.63\times 10^{-5}$となります。参照論文ではミッション時間を5,000[H]としているため、"PMHF"(本当は車両故障確率の時間平均)は3.26[FIT]となります。

表202.2 EBDサブシステムのFTのMCS

ISO 26262では3つ以上のエレメント故障は安全故障としています。これは(規格には明確に書かれていませんが)確率が非常に低くなるためです。従って、3つ以上の故障を枝刈り(slice)すれば、表202.3のMCSとなります。積項数は6個に減少するものの、故障確率も"PMHF"も変わりません。

表202.3 枝刈りをしたMCS 便宜上、時間平均VSG確率を"PMHF"としましたが、本来PMHFと呼ぶためにはPMHF式を尊重しなければなりません。以上のように、本論文の手法では"PMHF"が非常に低く計算されます。その理由はon-lineモニタのカバレージをほぼ100%としているためです。

---

前のブログ 次のブログ

ISO 26262のFTA関連の2つの論文を紹介します。

最初に紹介するのは"ISO 26262 ASIL-Oriented Hardware Design Framework for Safety-Critical Automotive Systems"という論文$\dagger$で、 PMHFターゲットに対してシステムをFTAを用いて分析し、弱い部分を定量的に抽出し、そこにSMを追加し、最終的にPMHF目標を満たす設計手法を提案するという、大変興味深いものです。ただ、残念ながらこの論文にはランダムハードウェア故障の確率の評価値(いわゆるPMHF)について問題があるため、それを取り上げます。

この論文(以下参照論文と言う)は以下のところから取得できます。

• https://ieeexplore.ieee.org/document/8965235
  
• https://www.researchgate.net/publication/335396971_ISO_26262_ASIL-Oriented_Hardware_Design_Framework_for_Safety-Critical_Automotive_Systems

この論文ではAEB(autonomous emergency braking system)を題材としています。以下にAEBシステムのFT(Fault Tree)を示します。

図201.1 AEBシステム

AEBはかなり大規模なシステムであるため、FTの一部を抜き出します。図201.2がその一部で、これにEBDサブシステムと名付けます。

図201.2 AEBシステムの一部(EBDサブシステム)

EBDサブシステムは図201.2のように、EBDノード4冗長で構成されます。参照論文では図201.3のように、EBDノード1チャネルのEBM(Electronic Brake Module)に対してOn-line Monitorを付加してPMHFを下げたと主張しています。

図201.3 EBDノード1チャネル

---

$\dagger$Chen, Yung-Yuan & Lu, Kuen-Long. (2019). ISO 26262 ASIL-Oriented Hardware Design Framework for Safety-Critical Automotive Systems. 10.1109/ICCVE45908.2019.8965235.

---

前のブログ 次のブログ

共通原因故障(CCF)

前稿では冗長制御方式を取り上げて、メインマイコンとサブマイコンがお互いに主機能とSMの関係になっており、SPFを防止していることを説明しました。共通原因故障(Common Cause Failure, CCF)が無い理想的な場合にはこれが成立します。一方、メインマイコンとサブマイコンにCCFを持つ場合にはどうなるか、MCSを取得してみましょう。

CCFの例

メインマイコンとサブマイコンに共通の発振回路からクロックを供給している場合はどうでしょうか？ メインマイコン発信回路の故障をBE028、サブマイコン発振回路の故障をBE031としていたもとのツリーを変更してBE031をBE028に置き換えてみます。こうすると冗長系の両側に共通の故障原因BE028を持つことになり、MCSを取得すると以下のようにANDの下だったものが上位のORに接続され、SPFの原因となります(図29.1)。

図29.1 CCFのFT図

図29.2 分配則

図29.2はブール代数の分配則であり、これにより上記論理変換が行われます。

これは何を意味するかというと、共通の電源、クロック源、あるいは共通の型番を持つと、単一のランダムハードウェア故障ないしはシステマティック故障により、メインマイコンとサブマイコンのお互いの安全機構の構造が崩れて、単一原因により安全目標が侵害されるとことになり、重要な故障となることを意味します。

ISO26262はこのCCFを定量的に計算する手段を規定していないため、ISO26262のベース規格であるIEC61508に記述されているCCFのβファクタを援用することになります。また、ISO26262の発展規格であるISO19451において、従属故障分析(DFA, Dependent Failure Analysis)として詳述されていますので、ご参照ください。

---

前のブログ 次のブログ

因数分解

前稿のMCSにおいて因数分解を行います。このステップは必須のステップではありません。論理的には前のツリーと等価なツリーなのですが、冗長構成となっていることをひとめで明らかにするために因数分解を行います。上記のMCS論理式を因数分解したものを以下のFTに示します。因数分解はAND-OR形式をOR-AND形式に変換するものですが、残念ながら自動的には困難であるため、人力で行います。

図29.1 FTA例のMCSと等価のFT

論理等価なのでMCSは上記MCSと同じです。メインマイコン各部(8箇所)の故障とサブマイコン各部(8箇所)の故障が互いに主機能・安全機構の関係となりSPFを防止しており、共通部分の回路のみがSPFとなっていることがひとめでわかります。MCの数は前と同じく8×8+1=65項となります。

ISO26262の目的は安全に関する論証なので、このようにアセッサー等の第三者が見てわかりやすいドキュメントを生成することが重要です。マイコンやLSIのように比較的故障率の大な部品を使用する際に、マイコン単体でASIL-Dを達成するのは困難ですが、このような冗長構成をとればSPF/RFが冗長部分で微小となるため、ASIL-D対応が可能となります。

---

前のブログ 次のブログ

実際の例

システムFTAの実例をご紹介します。これはあるECUの安全分析を実施したもので、メインマイコンとサブマイコンによる冗長制御を行っているECUの例です。電源回路は共通で、共通の信号が両マイコンに入力され、両マイコンの出力が揃って初めて動作するという回路構成となっています。主機能としてはマイコンはひとつで成立するのですが、ECUがASIL-D対応をする必要があるため、冗長構成をとり故障率を低減しています。

システムFTAと称する理由は、基事象が部品の故障モードではなく、エレメントの故障モードとなっているためです。

トップ事象を侵害する分析は、このように一般的に非常に複雑になり、マイコンの故障が複数個所に出てくることになります。以下はFTの図です。

図28.1 ECUのFTA例

MCSの導出

この例のMCSを取得したものが以下の図です。SAPHIREにより155個の積項(ミニマルカット=MC)が得られました。カラムは順番に、その事象の「連番」、「ケース」、「確率」、「確率のパーセント表記」、「ミニマルカット」です。

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 図28.2 FTA例のMCS

3次以上の次数項の省略

次にSAPHIREの分析の際に、3次以上の積項を省略したMCSを取得してみます。3次以上の積項を省略する理由は、ISO26262において3点故障はセーフフォルトとして良いとあるためであり、3次以上の積項は一般的に確率的に非常に小さいので省略可能なためです。

これを行うにはSAPHIREにおいて、Fault Treeを選択しSolveコマンドを実行する際に、Sizeに2を設定します。すると155個得られた積項が65個と減少します。以下のMCSの論理式を確認すると1次と2次の積項のみであることがわかります。今回はTOP事象の侵害確率は、155項の積算でも65項の積算でも2.218E-5と変わりませんでした。これからも3次以上の積項を省略することが可能と言えます。

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 図28.3 FTA例のMCS(2次以下)

これを論理式として出力し、FTL(Fault Tree Language)に(手で)変換してからSAPHIREに取り込むと、SAPHIREがツリーを構成してくれます。その図を以下に示します。

図28.4 FTA例のMCSのFT

---

前のブログ 次のブログ

MCSのFault Tree

SAPHIREではMCSの論理式は出力してくれるのですが、残念ながらFault Tree図(FT図)は構成されません。そこで、論理式からのインポートを行います。まず論理式は図26.2のように出力されるので、それをFTL(Fault Tree Language)に変換しますが、変換したものを以下に示します。

WARWICKFTA, TOP-MCS =
TOP-MCS OR TOP0 TOP1
TOP0 AND E1 E3 E4
TOP1 AND E2 E3 E4

その後、SAPHIREのインポート機能により取り込み、FT図を作成したものが、図27.1となります。

図27.1 MCSのFT図

---

前のブログ 次のブログ