論文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}$としなければ次元が合いません。故障率と故障確率を混同しているようです。

図303.1 故障率に対する要求分解効果

---

$\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のシステムブロック図です。

図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を満たすことができるという、この問題の妥当な解決策を示しています。

図301.1 ESL初期アーキテクチャ

このように変更することで、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の初期アーキテクチャです。

図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に分解しています。

図300.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.

---

前のブログ 次のブログ

ADASについての言及

続けてADASの具体例を書いた記事が見つかりました。

ブレーキの基本機能は ASIL D だろう。画像解析のエレメントは ASIL D なの？という疑問が生まれる。 プリクラッシュブレーキ システムはシステム全体としては ASIL D だろうから、ブレーキの基本機能は ASIL D のままで、画像解析エレメントは ASIL C(D) にデコンボジションしたとする。 その際にブレーキエレメントと画像解析エレメントは独立しており従属故障は起こらないと言えるのだろうか。

図288.1 図は弊社で作成

ASILデコンポジションの記事を読んで理解された方は指摘できると思いますが、これは1.及び2.の2条件が成立していません。再掲すれば、ASILデコンポジションが成立する条件は、

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

の2条件(AND条件)が必要ですが、両方共成立していません。

そもそも安全目標や安全要求が書かれていないので、ASILアロケーションができないことがまず問題です。通常ADASであれば、例えば「意図しない急ブレーキ無き事」等の安全目標があるはずです。書かれていない安全要求を仮定し、RBDを描くと、ブレーキエレメントと画像解析エレメントは冗長(並列)関係ではなく、直列関係(従属)となります。従って、そもそもASILデコンポジションが成立していません。著者が心配しているとおり、画像解析エレメントの単一故障により従属故障が起き、システム全体が危険な状態に陥いるのは当然です。

この情報だけだとシステムの安全要求がASIL-Dであれば、画像解析エレメントもブレーキエレメントもASIL-Dとなり、それ以上のことは言うことはできません。この例に限らず、センサーとしてのCMOS撮像素子や画像認識サブシステムを(ASIL-Dにしたくないから)ASIL-Ｂとする、等のような、エレメントへの自由なASIL割り当て手法が業界で幅広く蔓延しているため、注意が必要です。

故障率についての言及

さらに幅広く見られる誤解として、前の記事と同様の誤りも見られ、

ハードウェアの故障はランダム故障の場合が多いから、もとのシステムと安全装置の故障が二重に起こる確率は下がる。部品の故障率ならば1万分の１×1万分の1で、10億分の1など。

故障率を確率と混同し、故障率を掛け算することができると誤解しています。故障率の次元は[1/H]なので、掛け算すると$[1/H^2]$というわけのわからない次元になってしまいます。正しくは、故障率([1/H])を故障確率(無次元)に直すために車両寿命([H])をかけた上で乗算する必要があります。

---

前のブログ 次のブログ

ASILデコンポジションについての言及

ASILデコンポジションでひっかかるネット上の文章で以下のようなものがありました。

ユーザーの安全確保を第一に考えれば、まずやるべきことはシステムを安全に関わる大事な部分とそうでない部分に分けて印を付けることだ。それが ASIL であり、コンポーネントも分解すれば危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ。

ASILデコンポジションの記事をご覧頂ければわかるように、これはほとんど誤りです。ほとんどと言うのは、条件を追加すれば正しくもなる、曖昧な表記であるためです。以下に誤りと正しい場合の2通りを検討してみます。

まず第1にASILデコンポジションの記事でも説明しているように、最初に考えるべきことは安全要求です。その目で見ると、この文章では安全要求への言及が抜けていますが、それを補ったとして素直に読むと、

コンポーネントも分解すれば危ない部分(=安全要求の厳しい部分)とそれほどでもない部分(=安全要求の緩い部分)にわけることができる

と読めます。それぞれの安全目標毎にHA&RA(ハザード分析とリスク評価)を実施し、初めてASILが決定されるわけですが、安全目標毎に安全要求及びASILも変わります。それを安全要求の厳しい部分と緩い部分に分けるのは、安全要求のエレメントへの割り当て(=安全コンセプト)であり、通常の設計ですから、ASILデコンポジションとは何の関係もありません。

素直に読むと以上のように誤りですが、なんとか正しくなるように補って読んでみます。すると、

(ひとつの厳しい安全要求を、冗長な要求に分解し、それを互いに独立したエレメントに割り当る。すると)コンポーネントも分解すれば、危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ

となり、かろうじて意味が通じることになりますが、重要な2点の条件を落としているので、ASILデコンポジションの説明になっていません。さらにその後を読んでいくと、

システムの中の大事な部分、安全を担っている部分をできるだけを機能ごとに凝集し、他のコンポーネントとの結合を疎にして、その大事なコンポーネントに関わる設計や検証に工数や費用を投入するのがよい。そのためにはシステム全体の安全に対する分析を最初に進める必要がある。

とあります。上記で重要な2点の条件を説明していないことを考慮すると、ASILデコンポジションと共存の基準を混同しているようです。似たような概念なので混同するのもやむをえませんが、この2つをしっかり区別して理解することが必要です。

---

前のブログ 次のブログ

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. 安全要求の割り当てられたエレメント間の独立性

---

前のブログ 次のブログ

ASILデコンポジションの論文

ASILデコンポジションで検索すると上位に出てくる次の論文について考察します。 https://www.juse.or.jp/sqip/workshop/report/attachs/2006/3_3_report.pdf

第三分科会 機能安全グループ
安全関連システムの分割要件の考察
Consideration of requirement of decomposition for a safety related system

筆者は恐らくソフト屋さんなのでしょうか、誤りが見受けられます。

記事中の文章

図２は一般的な監視機構を表しているが、このシステムでは主機能システムの異常を監視システムが検出し、あらかじめ設定された安全状態(Safety State)にシステムを遷移させ、その状態を維持する。同様に監視システムの異常を主機能システムが検出し、 Safety State に遷移・維持する。これは監視システムの喪失が単一故障で即危険状態に至る潜在故障(Latent failure)を避けるためである。

図283.1 引用文中の"図2"

IFの故障により直ちにVSGとならないようにSMがIFの故障検出を行い、(FTTI中に)SSに遷移するというのは正しいです。また、SMの故障によりLFとならないように、IFが?(正しくは2nd SMだが、IFに2nd SMの機能が有ったとして)(MPFDI中に)故障検出を行うというのも、誤りではないです。

しかしながら、LFとならないようにSSに遷移する、という部分が誤りです。そもそもSMのフォールトは直ちに非安全状態になるものではなく、そのうち(!)に修理すれば良いわけです。そのためにMPFDIはかなり長時間、例えば1 vehicle trip時間(key onからkey offまで)を想定しています。SMはその定義上、故障しても直ちに危険事象を引き起こすことはないので、SSに遷移する必要はありません。

例えば ABS/VSA 等の電子制御のブレーキシステムにおいて故障を検出した時に、警告灯の表示で運転者に異常を知らせると共にシステムを機械式ブレーキシステム相当に戻した時の状態が、安全状態である。

警告灯が故障したからといって、いちいち機械式ブレーキに遷移しては、使い物になりません。この例に限りませんが、警告灯が故障したからといって、直ちに問題にはなりません。主機能である電子制御ブレーキシステムは正常に動作します。

とはいえ、システムはレイテント状態、つまりフォールトの待ち受け状態になっており、準危険状態なのでMPFDI中に検出し、修理する必要があります。MPFDIは「そのうち」と読み替えて良く、あまり危険度合いが高くないシステムであれば、次の車検の時でも良いでしょう。MPFDIの時間間隔は主機能と安全機構の故障率にも依存しており、PMHF式から逆算することが可能です。

---

前のブログ 次のブログ