イントロダクション

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.

前のブログ 次のブログ

論文ward2012$\dagger$の続きです。以下は誤りの例として論文中で取り上げているものです。まず、REQ 32の安全要求

REQ 32: Failure of the road-wheel actuation shall not lead to an absence of directional control of the vehicle. [ASILD]

REQ 32: 車輪の作動の故障により、車両の方向制御ができなくなることがあってはならない。 [ASIL D]

を誤って次のように冗長な要求REQ 32.1, REQ 32.2に分解しました。

REQ 32.1: The front road-wheel actuation shall provide directional control of the vehicle according to ECU commands. [ASIL C(D)]

REQ 32.1: 前輪駆動は、ECUの指令に従って車両の方向制御を行うこと。 [ASIL C(D)]

及び

REQ 32.2: The rear road-wheel actuation shall provide directional control of the vehicle according to ECU commands. [ASIL A(D)]

REQ 32.2: 後輪駆動は、ECUの指令に従って車両の方向制御を行うこと。 [ASIL A(D)]

分解された要求(REQ 32.1又は32.2)単独で初期安全要求(REQ 32)を満たしていないので、冗長な要求ではありません。例えば、前輪の方向制御が狂う故障が起きた場合に、後輪の方向制御のみで正常に車両を制御できるとは思えません。論文中にもあるように、例えば前輪が左一杯に舵が切られ固着していた場合等です。このような場合は後輪操舵だけで正常に走行することは困難です。さらに、ECUが共通であるため、独立なエレメント同士にもなっていません。

これはASILデコンポジションをエレメントのデコンポジションと誤って思い込んだ例です。論文でも主張しているように、エレメントを分解するのではなく、安全要求を(冗長、独立に)分解します。

この後に、REQ 49の分解例として、センサが3冗長の時、2段階のASILデコンポジションを実施する例が挙げられていますが、省略します。

最後に、図303.1は良くある誤りです。故障率を2乗すると次元が[$1/H^2$]となってしまい、本来$\lambda_1\lambda_2 T_\text{Lifetime}$としなければ次元が合いません。故障率と故障確率を混同しているようです。

$\dagger$Ward, D. D., & Crozier, S. E. (2012). The uses and abuses of ASIL decomposition in ISO 26262. 7th IET International Conference on System Safety, Incorporating the Cyber Security Conference 2012.

前のブログ 次のブログ

論文ward2012$\dagger$の続きです。 2番目の例としてより複雑なSteer-by-wireを取り上げます。

In this example (which is intended to illustrate principles and not represent a real design) a 4-wheel steer-by-wire system is under development. Here, the hand-wheel input is sensed and processed into commands for control of the front and rear axle actuators. A third actuator provides haptic feedback to the driver at the hand-wheel.

この例では（原理を説明するためのものであり、実際の設計を示すものではありません）4輪ステアバイワイヤシステムが開発されています。ここでは、ステアリングの入力が感知され、フロントアクスルとリアアクスルのアクチュエータを制御するためのコマンドに処理されます。第3のアクチュエーターは、ステアリングでドライバーに触覚フィードバックを提供します。

図302.1はSteer-by-wireのシステムブロック図です。

このシステムには多くの安全目標が設定されており、要求分解をしていった結果、以下の要求がステアリングセンシングと車輪アクチュエーション（項目の他の要素の中で）に課せられています。

REQ 32: Failure of the road-wheel actuation shall not lead to an absence of directional control of the vehicle. [ASILD]

REQ 32: 車輪の作動の故障により、車両の方向制御ができなくなることがあってはならない。 [ASIL D]

REQ 49: Failure of the hand-wheel sensing shall not lead to an incorrect indication of the driver’s intended direction to the ECU [ASIL D]

REQ 49: ステアリングセンシングの故障により、ECUに運転者の意図する方向が正しく表示されないことがあってはならない。 [ASIL D]

$\dagger$Ward, D. D., & Crozier, S. E. (2012). The uses and abuses of ASIL decomposition in ISO 26262. 7th IET International Conference on System Safety, Incorporating the Cyber Security Conference 2012.

前のブログ 次のブログ

論文ward2012$\dagger$の続きです。

Figure 4 illustrates a plausible solution to this problem, where the secondary micro is also equipped with CAN hardware and therefore is able to fulfill REQ 22.2 independently from the primary microcontroller.

図4は、セカンダリマイクロがCANハードウェアを装備しているため、プライマリマイクロコントローラから独立してREQ 22.2を満たすことができるという、この問題の妥当な解決策を示しています。

このように変更することで、ASILデコンポジションが成立しています。2ステップに分解して確かめてみましょう。まず分解された安全要求は初期安全要求を単独で満足する必要があります。

安全要求

REQ 22.1. プライマリ・マイコンは、CANバス上で「ロック」コマンドを受信すると、ブリッジ・ドライブへのドライブ信号をアクティブにしなければならない。

は、初期安全要求

REQ 22: 「ロック」状態がCANバスで受信された場合、マイクロコントローラはブリッジドライブへのドライブ信号をアクティブにしなければならない。

を単独で満足します。また、安全要求

REQ 22.2. セカンダリマイコンは、CANバスを介して受信した車速がロック状態が妥当であることを示した場合（すなわち、車両が静止している場合）に、ブリッジドライブへのイネーブル信号をアクティブにしなければならない。[ASIL B(D)]

は、初期安全要求

REQ 22: 「ロック」状態がCANバスで受信された場合、マイクロコントローラはブリッジドライブへのドライブ信号をアクティブにしなければならない。

を単独で満足します。

次に、REQ 22.1と22.2が割り当てられたエレメントは、互いに独立となっていてASILデコンポジションが成立しそうです。論文中にもありますが、

Finally, as a cautionary note; one often overlooked aspect is that of support circuitry for the microcontrollers. In such architecture, care should be taken to ensure that there is an absence of common cause faults, and that no propagation of faults from one microcontroller to the other can occur via a common power supply or common clock circuit.

最後に、注意事項として、見落とされがちなのがマイクロコントローラのサポート回路です。このようなアーキテクチャでは、共通の原因となる故障が存在しないこと、そして、共通の電源や共通のクロック回路を介して、一方のマイクロコントローラから他方のマイクロコントローラへの故障の伝播が起こらないことを保証するために注意を払う必要があります。

エレメント間で電源やクロックの異常により、同時に異常動作が起きることが無いことの説明が必要ですが、それが成立する場合、ASILデコンポジションが成立します。

実は前稿にも書いたように、この例は無駄なASILデコンポジションの例であり、このような無駄をしないためにはASILデコンポジションを正しく理解することが必要です。

$\dagger$Ward, D. D., & Crozier, S. E. (2012). The uses and abuses of ASIL decomposition in ISO 26262. 7th IET International Conference on System Safety, Incorporating the Cyber Security Conference 2012.

前のブログ 次のブログ

論文ward2012$\dagger$の続きです。具体例が参考になるので、具体的な要求に従って検討していきます。

Below are some examples illustrating common misuse of requirements decomposition.

以下に、要件分解の一般的な誤用を説明するいくつかの例を示します。

最初の例はESL (Electronic Steering Lock)です。ESLとは、盗難防止装置であるステアリングロックを電子的に行うもので、停止状態(=車速がある速度以下)で、一定の条件でステアリングを回転させないようにカンヌキをかけるシステムです。図300.1はESLの初期アーキテクチャです。

この初期アーキテクチャのSGは以下のようです。

SG01: When the vehicle is being driven, the steering lock shall not engage unintentionally [ASIL D].

SG01: 車両の運転中は、ステアリングロックが意図せずに作動してはならない[ASIL D]。

前述のように、走行中にESLが働くと大変なことになります。SG中の意図せずというのは、故障した場合と読み替えることができます。このSGに従い、次の初期TSRを導出しました。

REQ 22: The Microcontroller shall activate the drive signal to the bridge drive when “lock” conditions are received over the CAN bus. [ASIL D]

REQ 22: 「ロック」状態がCANバスで受信された場合、マイクロコントローラはブリッジドライブへのドライブ信号をアクティブにしなければならない。[ASIL D]

が、これではASIL-Dを担保できないでしょう。なぜなら、マイクロコントローラの単一故障で走行中にステアリングロックする可能性が高いためです。そのため本論文では、初期安全要求REQ 22をREQ 22.1とREQ 22.2に分解しています。

次のREQ 22.1と、

REQ 22.1: The primary microcontroller shall activate the drive signal to the bridge drive when a “lock” command is received over the CAN bus. [ASIL B(D)]

REQ 22.1. プライマリ・マイコンは、CANバス上で「ロック」コマンドを受信すると、ブリッジ・ドライブへのドライブ信号をアクティブにしなければならない。[ASIL B(D)]

次のREQ 22.2

REQ 22.2: The secondary microcontroller shall activate the enable signal to the bridge drive when the vehicle speed received over the CAN bus indicates that lock conditions are plausible (i.e. the vehicle is stationary). [ASIL B(D)]

REQ 22.2. セカンダリマイコンは、CANバスを介して受信した車速がロック状態が妥当であることを示した場合（すなわち、車両が静止している場合）に、ブリッジドライブへのイネーブル信号をアクティブにしなければならない。[ASIL B(D)]

ですが、この分解には問題があります。現実にも見られる例ですが、論文中にも、

there is a common-cause failure (the CAN reception; element’s sub-parts and software) which could cause both REQ 22.1 and REQ 22.2 to fail simultaneously.

REQ 22.1 と REQ 22.2 の両方が同時に失敗する原因となる共通の障害（CAN 受信；エレメントのサブパーツとソフトウェア）がある

とあるように、分解されたエレメント同士の独立性に違反しています。すなわち、ASILデコンポジションとして成立していません。

※このように述べると全くダメなようですが、実は成立するやり方があります。初期安全要求をCANをはずすようにすれば、独立性に違反しませんし、ASILデコンポジションはハードウェアに関しては無意味であるため、本来マイコンのみを含むようにするのが良いのです。この辺りはASILデコンポジションのテクニックやノウハウに関するところとなります。

$\dagger$Ward, D. D., & Crozier, S. E. (2012). The uses and abuses of ASIL decomposition in ISO 26262. 7th IET International Conference on System Safety, Incorporating the Cyber Security Conference 2012.

前のブログ 次のブログ

「ASIL」分解の誤解

論文ward2012$\dagger$の続きです。ASIL分解においてしばしば見られる誤解が述べられていていますが、これは日本でも全く同じ状況です。

3 Misinterpretations of “ASIL” decomposition
This incorrect terminology is unfortunately associated with a great deal of misunderstanding about the purpose and application of the technique. In particular, it is often assumed that:

3 「ASIL」分解の誤解
この誤った用語は、残念ながら、技術の目的や応用に関する多くの誤解に関連しています。特に、しばしば次のように想定されています。

2例挙げられていますが、最初の例はあまり重要ではないので、省略します。

• ASIL decomposition is frequently misinterpreted as an objective; in other words, a frequently encountered (and incorrect) question is “There is an ASIL D safety goal; now how can it be decomposed into ASIL B elements?” It is not valid to create an element out of sub-elements with lower ASIL values through such a “building block” approach without considering the independence of the redundant elements and their associated safety requirements (i.e. without considering the suitability of the architecture to support this).

• ASIL分解は、しばしば目的として誤解されます。例えば、頻繁に遭遇する（そして不正確な）質問は、「ASIL Dの安全目標がありますが、それをどのようにASIL Bエレメントに分解できますか？」冗長エレメントの独立性とそれに関連する安全要件を考慮せずに（すなわち、これをサポートするためのアーキテクチャの適合性を考慮せずに）、このような「ビルディングブロック」アプローチによって、より低いASIL値を持つサブエレメントからエレメントを作成することは有効ではありません。

この質問は日本においても典型的なものであり、エレメントのASILを引き下げたいあまり、それが目的となっています。ASILは、安全要求を分解した結果としてであれば、引き下げることが可能ですが、それには上で触れられているように冗長なエレメントの独立性という条件を満たす必要があります。それ無しに、いきなりエレメントに低いASILを割り当てる誤りが、業界ではしばしば見受けられます。

$\dagger$Ward, D. D., & Crozier, S. E. (2012). The uses and abuses of ASIL decomposition in ISO 26262. 7th IET International Conference on System Safety, Incorporating the Cyber Security Conference 2012.

前のブログ 次のブログ

論文の概要

あるASILデコンポジション(またはASIL分解とも言う)論文$\dagger$を読み込みます。これは投稿論文の参照論文ではありませんが、ASILデコンポジションを題材としていて非常に参考になるため、ここで取り上げます。

アブストラクト

アブストラクトは非常に短く、以下の1文だけです。

This paper examines the ISO 26262 approach to ASIL decomposition, more appropriately called “requirements decomposition”, and how it may be applied correctly during the requirements analysis and architectural design of a safety-related automotive control system.

本稿では、ASIL分解（より適切には「要求分解」と呼ばれる）に対するISO 26262のアプローチを検証し、安全関連の自動車制御システムの要求分析やアーキテクチャ設計の際に、どのようにして正しく適用できるかを検討する。

本論文の筆者は一貫してASIL分解は良くない言葉であり、その代わりに要求分解と言うべきであると主張しています。その通りであり、本来は要求を分解するのが主目的で、結果的に要求の属性であるASILも分解されるということです。

しかしながら、本論文の筆者も論文タイトルであえて使用しているように、「ASIL分解」が一般化してしまっているのが現状です。要は、ASILデコンポジションの正しい意味を理解し、要求分解によるASILの低減のことであると認識した上で、ASILデコンポジションの用語を使用すれば良いと思います。

$\dagger$Ward, D. D., & Crozier, S. E. (2012). The uses and abuses of ASIL decomposition in ISO 26262. 7th IET International Conference on System Safety, Incorporating the Cyber Security Conference 2012.

前のブログ 次のブログ

PMHFと基本的な信頼性計算(続き)

論文sae2020$\dagger$のPMHFと基本的な信頼性計算(続き)です。

ISO 26262-2018 designates the average probability of failure per hour over the operational lifetime as the probability that the item will fail before its lifetime $T_\text{Lifetime}$ as $Prob(t ≤ T_\text{Lifetime})/T_\text{Lifetime}$. In order to simplify the notations and improve the understanding, in this paper we will designate the average probability of failure per hour (assuming these faults are independent) as $P_{avg/t}$ and express it as a product of probabilities of failures required for a system to fail over the time of operation:

ISO 26262-2018 では、運用寿命における 1 時間当たりの平均故障確率を、その品目がその寿命$T_\text{Lifetime}$までに故障する確率を$Prob(t ≤ T_\text{Lifetime})/T_\text{Lifetime}$として指定している。表記を簡略化して理解を深めるために、本稿では、1時間あたりの平均故障確率を（以下のように仮定して）指定することにする。 これらの故障は独立している)を$P_{avg/t}$とし、システムが運転中に故障するのに必要な故障確率の積として表現します。

ISO 26262-2018がPMHFを $$\frac{\Pr(t ≤ T_\text{Lifetime})}{T_\text{Lifetime}}$$ のように規定していると書かれているが、これは正しくありません。

たしかに、ISO 26262:2018ではPart10 8.4において、PMHFを次のように書いています。

The following shows the derivation of the average probability of failure per hour over the operational lifetime of the item regarding single point faults.
(略)
Then, average probability of failure per hour (according to ISO 26262-5), over operational life time (Tlifetime) is:
$$\frac{\Pr(t ≤ T_\text{Lifetime})}{T_\text{Lifetime}}$$

つまり、SPFについての式であると限定しています。SPFにおいてはフォールトの発生により直ちにVSGとなるため、修理の時間が全く取れないので、分子はReliabilityで良いのですが、本来は、Reliabilityに加えて修理を考慮したAvailabilityでなければなりません。

確率式で書き直すと、SPFに限れば、PMHFは $$M_\text{PMHF,SPF}=\frac{\Pr(\text{item fail till }T_\text{Lifetime})}{T_\text{Lifetime}}$$ で良いですが、一般には $$M_\text{PMHF}=\frac{\Pr(\text{item down at }T_\text{Lifetime})}{T_\text{Lifetime}}$$ とするべきです。本論文に限らず、多数の論文がPMHF結果式を無視していますが、PMHF結果式を適用すべきです。

この論文の次の段落からは、ISO 26262の精神のひとつである指数分布をワイブル分布に一般化しており、ISO 26262を逸脱するため、検討はここまでとします。

結論として、PMHF式についての信頼性工学的な議論を期待していたのですが、SPFのみに通用する話を一般化した上、ISO 26262非互換な議論に脱線しており、期待はずれに終わりました。

$\dagger$: Kleyner, A. and Knoell, R., “Calculating Probability Metric for Random Hardware Failures (PMHF) in the New Version of ISO 26262 Functional Safety - Methodology and Case Studies,” SAE Technical Paper 2018-01-0793, 2018

前のブログ 次のブログ

PMHFと基本的な信頼性計算(続き)

論文sae2020$\dagger$のPMHFと基本的な信頼性計算(続き)です。

The assumption of a constant failure rate, though often debated by reliability professionals, provides simplified and expedient closed-form calculations which have been utilized to assess the ASIL safety goals throughout the ISO 26262. Table 1 provides the PMHF values expressed as failure rates in units of FIT (Failures In Time) defined as 10^9 times the number of failures divided by the product of the number of components and their operating hours before failure. A convenient metric is 1 FIT = 1 PPM per 1000 hours of operation corresponding to each ASIL safety goal.

一定の故障率の仮定は、信頼性の専門家によってしばしば議論されているが、簡略化された簡便なクローズドフォーム計算を提供し、ISO 26262 の ASIL 安全目標を評価するために利用されている。表1は故障率を、$10^9$倍した故障回数を部品点数と故障前の稼働時間の積で除した値のFIT (Failures In Time)の単位で表したPMHF値を示している。便利な指標は、各ASILの安全目標に対応する運転時間1000時間あたりの1FIT=1PPMである。

1000時間につき1PPM(=$10^{-6}$)とは、誤りではありませんが、中途半端な例示です。PPMを持ち出すなら1時間に1PPB(=$10^{-9}$)とするか、1回/$10^9$時間とするかいずれかでしょう。

Determining the probability of a fault causing a safety-critical failure ISO 26262 Part 5 requires that they are analyzed and classified into six different categories: (a) Safe, (b) Single point, (c) Residual, (d) Detected multi-point, (e) Perceived multi-point and (f) Latent multi-point. Residual is the portion of the fault which is not controlled by a safety mechanism. Latent faults are not detected by safety mechanisms or perceived by the driver. Perceived faults may be detected indirectly through deviating behavior on the vehicle level. Multiple- point faults result in several hardware faults whereas single-point fault requires just one. More detailed explanations of these fault categories and the guidance of calculating PMHF for these types of faults are provided by the ISO 26262 Parts 1 and 5. However, in this paper, we will focus on the two major types of failures: single-point and multi-point faults.

ISO 26262 Part 5では、安全上重要な故障の原因となる故障の確率を決定するために、故障を分析し、6つの異なるカテゴリーに分類することを要求している。(a) 安全、(b) 単一点、(c) 残留、(d) 検出された多点、(e) 知覚された多点、(f) 潜在的多点である。残留は，安全機構によって制御されていない故障の部分である。潜在的な欠陥は、安全機構によって検出されず、運転者によって感知されない。知覚されたフォルトは、車両レベルでの逸脱した動作によって間接的に検出されることがある。多点フォルトは複数のハードウェアフォルトを発生させるのに対し、シングルポイントフォルトは1つのハードウェアフォルトを必要とします。これらの故障カテゴリの詳細な説明や、これらのタイプの故障に対する PMHF の計算方法については、ISO 26262 第 1 部と第 5 部に記載されている。しかし、本稿では、単一点故障と多点故障という 2 つの主要なタイプの故障に焦点を当てる。

多点フォルトが複数のハードウェアフォルトを必要とするという事実と、レイテントフォルトの説明が別に書かれているため、著者は理解しているのかどうかが不明です。レイテントフォルトは1点フォルトであるにも関わらず、マルチポイントフォルトと名付けられているからです。上記の説明ではその説明が無いため、レイテントフォルトがが複数のハードウェアフォルトを発生するともとられかねません。

However, dealing with multi-points faults is more challenging. In reliability engineer’s terminology, this would be similar to modeling (although with some subtle differences) a parallel system. The failure rate of such a system would no longer be constant, but rather a function of time which makes it more difficult to express PMHF in terms of failure rates. For that purpose, the new version of the ISO 26262 standard introduces a new metric, Average Probability of Failure per Hour for the Lifetime. It is important to note that this metric is not commonly used by the reliability and design professionals and, therefore, will require some further explanation.

しかし、多点故障への対応はより困難です。信頼性エンジニアの用語で言えば、これは並列システムのモデリングに似ています（微妙な違いはありますが）。このようなシステムの故障率はもはや一定ではなく、むしろ時間の関数となり、PMHFを故障率で表現することはより困難になる。そのために、ISO 26262の新バージョンでは、新しいメトリック「Average Probability of Failure per Hour for the Lifetime」が導入されている。このメトリックは、信頼性や設計の専門家が一般的に使用しているものではないことに注意が必要であり、そのため、もう少し説明が必要である。

前稿でも説明したとおり、規格の新バージョンで「Average Probability of Failure per Hour for the Lifetime」が導入されたわけではありません。さらに、表現は違いますが、これは信頼性や設計の専門家が一般的に使用しているものです。規格に明確に書かれていないのが原因ですが、Part 10のPMHF式を検証すれば、PFHの定義式と同じことがわかります。

ちなみに、PFHの定義は、ISO 12489で定義されているとおり、不稼働密度を0から車両寿命まで積分して時間平均をとったものです。

$\dagger$: Kleyner, A. and Knoell, R., “Calculating Probability Metric for Random Hardware Failures (PMHF) in the New Version of ISO 26262 Functional Safety - Methodology and Case Studies,” SAE Technical Paper 2018-01-0793, 2018

前のブログ 次のブログ