他の論文を読む意味

論文を執筆するにあたって、既存の論文の調査は必須です。論文には必ず新規な発見や理論を記述する必要がありますが、既存の論文で書かれていることを再度書いても意味が無いためです。特許と同様、論文にも新規性が最も重要です。

IEEE XploreにおいてキーワードをPMHFとして検索すると、以下の4つの論文が検索されました。そのうち2つは弊社の論文ですので、他の2つの論文を検討します。

sakurai2017:

A. Sakurai, "Generalized formula for the calculation of a probabilistic metric for random hardware failures in redundant subsystems," 2017 IEEE Symposium on Product Compliance Engineering (ISPCE), San Jose, CA, 2017, pp. 1-5, doi: 10.1109/ISPCE.2017.7935021.

　 sae2020:

Calculating Probability Metric for Random Hardware Failures (PMHF) in the New Version of ISO 26262 Functional Safety - Methodology and Case Studies," in The Safety of Controllers, Sensors, and Actuators , SAE, 2020, pp.85-94.

　 das2016:

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.

　 sakurai2020:

S. Atsushi, "Generic Equations for a Probabilistic Metric for Random Hardware Failures According to ISO 26262," 2020 Annual Reliability and Maintainability Symposium (RAMS), Palm Springs, CA, USA, 2020, pp. 1-6, doi: 10.1109/RAMS48030.2020.9153704.

RAMS 2020論文の参照論文

RAMS 2020で論文を発表しましたが、その参照論文を読んで行きます。論文中に他の論文を参照する場合は、紙面が限られているため、大まかに一言でまとめるしかないのですが、ブログではもう少し細かく見ていくことが可能です。

早速sae2020,「Calculating Probability Metric for Random Hardware Failures (PMHF) in the New Version of ISO 26262 Functional Safety - Methodology and Case Studies(ISO 26262 機能安全新版におけるランダムハードウェア故障の確率メトリック(PMHF)の算出方法とケーススタディ)」$\dagger$を取り上げます。

アブストラクト

以降翻訳はDeepLによるものです。

The Automotive Functional Safety standard ISO 26262 introduced a PMHF (Probabilistic Metric for Random Hardware Failures) in Part 5 and Part 10 by calculating the system failure rates and assessing the ASIL (Automotive Safety and Integrity Level) for functional safety.

自動車機能安全規格ISO26262では、第5部と第10部で、システムの故障率を計算し、機能安全のためのASIL(Automotive Safety and Integrity Level)を評価することでPMHF(Probabilistic Metric for Random Hardware Failures)を導入している。

ここまでは特に問題ありません。PMHFはPart 5で概念が提供され、Part 10で結果方程式が示されています。規格の問題は定義式が規格中に無いことです。

---

$\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

---

前のブログ 次のブログ

機能安全について非常に良いご質問を受けたので、その解答を示します(順不同)。

1. 機能安全の設計作業、安全分析
   Q. ISO 26262機能安全対応が加わることで、設計作業はどのように変化しますか？
   A. 機能安全の考えが広まる前からでも、設計者は安全機構を設けていましたが、ISO 26262が発効してから以降は、作業のエビデンスが重要となります。その理由は、万一法廷で、どのように安全設計を実施したかを説明してくださいと問われた時、従来は設計仕様書や検証結果がきちんと残っていないことがあったためです。これでは実際には実施していても第3者への証明になりません。安全設計そのものの作業としては危険事象から原因を遡るFTAと、部品故障等の原因から危険事象を辿るFMEAの両方を実施し、安全分析を行います。このような安全分析手法を実施し、証拠書類を保管することがISO 26262規格により推奨されています。

2. 製品ライフサイクルとは
   Q. ISO 26262のカバー範囲は設計作業なのでしょうか?
   A. いいえ、製品ライフサイクル、具体的には製品企画から廃棄までの全ての工程で、安全を担保する必要があります。例えばエアバッグ等は火薬が仕込まれているので、廃棄段階でも安全な廃棄方策をとる必要があります。あるいは保守工程において、ROMの誤書き込みを防止するなどの注意をする必要があります。安全要求を文書化し、製品の設計、製造、保守、廃棄工程において遵守する必要があります。

3. 階層の上から下のどこまで遵守するのか
   Q. 自動車産業はピラミッド階層構造ですが、OEM/1st tier/2nd tier等の階層のどこまでがISO 26262の対象となりますか？
   A. 全ての階層で遵守する必要があります。ISO 26262は車載電気電子システムの機能安全規格であり、通常車載電気電子機器は分散開発されます。この各層のそれぞれのプレイヤーが作業を分担し、トータルの車載システムとして安全を担保するのが規格の目的であるため、半導体ベンダーと言えども責任を免れることはできません。

4. 中国、韓国の状況
   Q. ISO 26262に対する中国、韓国の状況はいかがでしょうか？
   A. 新型コロナショックで一時的にスローダウンしていますが、一昨年あたりから対応の必要性がより強く認識されるようになってきました。2011年にISO 26262規格初版が発効されましたが、日本においては、大手OEMやサプライヤーはそれ以前のドラフト段階からISO 26262の活動に参加し、社内体制を整備してきました。それに比べると中国、韓国のOEM、サプライヤーの認識には数年の遅れがあり、数年前は安全に対しての意識は高くありませんでした。しかし、2018年の第2版の発効以降、急速に盛り上がってきています。

---

前のブログ 次のブログ

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つをしっかり区別して理解することが必要です。

---

前のブログ 次のブログ

表286.1はRAMS 2021正式採択までのマイルストーンであり、今後適宜更新します。

表286.1　RAMS 2021へのマイルストーン

年月日	マイルストーン	状態
2020/7/3	学会出席確認	済
2020/8/5	論文、プレゼン投稿締め切り(名前、所属無し版)	済
2020/9/7	第1回査読コメント受領
2020/10/2	改訂版論文、プレゼン投稿締め切り(名前、所属無し版)
2020/10/6	学会出席登録締め切り
2020/10/13	最終査読コメント受領
2020/10/27	最終論文、プレゼン投稿締め切り(名前、所属有り版)

---

前のブログ 次のブログ

表記の論文について、本年2020年1月にU.S.カリフォルニア州パームスプリングスで開催された、RAMS 2020において発表した論文は以下のところで公開中です。
https://www.xcdsystem.com/rams/proceedings2020/

著者リンクです。 以下が論文(魚拓)のURLです。
https://www.xcdsystem.com/rams/proceedings2020/pdfs/13E1-006.pdf

しかしながら、正規の発行場所であるIEEE Xploreにおいて半年たっても公開されないため、問い合わせを行いました。RAMS 2020の論文は、RAMS事務局からIEEE Xploreに7/22に到着したため、公開まで3、4週間待ってほしいとのこと。従って、IEEE Xploreで公開されるのは8/12～8/19あたりになると予想されます。こちらは有料になりますが、公開された後にこの記事に追記します。

[8/3追記]
以下でようやく公開されました。
https://ieeexplore.ieee.org/document/9153704

---

前のブログ 次のブログ

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式から逆算することが可能です。

---

前のブログ 次のブログ

表282.1はRAMS 2021正式採択までのマイルストーンであり、今後適宜更新します。

表282.1　RAMS 2021へのマイルストーン

年月日	マイルストーン	状態
2020/7/3	学会出席確認	済
2020/8/5	論文、プレゼン投稿締め切り(名前、所属無し版)
2020/9/7	第1回査読コメント受領
2020/10/2	改訂版論文、プレゼン投稿締め切り(名前、所属無し版)
2020/10/6	学会出席登録締め切り
2020/10/13	最終査読コメント受領
2020/10/27	最終論文、プレゼン投稿締め切り(名前、所属有り版)

---

前のブログ 次のブログ

表記のとおり、2021年1月25日からフロリダ州オーランドのローズンプラザホテルで開催される予定のRAMS 2021(67th Annual Reliability and Maintainability Symposium)に、弊社代表が投稿した論文のアブストラクトが採択されました。論文の内容は、今年1月に開催されたRAMS 2020で発表したPMHF式をFTAにどのように実装するかを明らかにするものです。まだ正式採択ではないため、これから論文をブラッシュアップしていくことになります。

---

前のブログ 次のブログ