この矛盾はどう解釈したらよいですか？

ChatGPT:
ISO 26262初版 Part 5のNote 5に記載された内容について、合理性がないと感じられる理由を深掘りし、その背景や考え方を検討してみます。

1. ISO 26262におけるPMHFの役割

ISO 26262におけるPMHF（平均確率故障時間）は、安全性の評価指標であり、車両が動作中に発生するハードウェア故障のリスクを評価するものです。ここで重要なのは、車両が動作中に発生するリスクに焦点を当てているという点です。

2. Note 5の意図

Note 5では、システムが電源オフ（または低消費電力モード）の場合、その時間はPMHFの計算に含めないとされています。これは、システムが実際に稼働している時間だけを評価対象とし、非稼働時間を含めて平均故障確率が低く見積もられることを防ぐ意図があります。

例えば、あるシステムが1日1時間しか稼働しないとした場合、その1時間の間に発生する故障リスクを正確に評価するためには、残りの23時間（非稼働時間）を計算に含めないことが求められます。これにより、システムが実際に稼働している時間中のリスクを過小評価することを防ぎます。

3. 平均故障率の観点

一方で、あなたが指摘しているように、PMHFは車両寿命間の平均故障率に近似される値であり、稼働時間が少なければ少ないほど、全体の平均故障確率は下がると考えるのが一般的です。したがって、非稼働時間を考慮しないというNote 5のアプローチは、寿命全体でのリスク評価には適さないように見えます。

4. 解釈の可能性

ここで考えられる解釈の一つは、ISO 26262が車両の運行中の安全性を最優先しているため、動作中のリスクのみを厳密に評価しようとしている点です。これは、運行中に発生する故障が直接的な安全リスクにつながるため、これを正確に反映することが重視されているからです。

5. 矛盾の感覚

確かに、寿命全体での平均故障率という観点から見ると、非稼働時間を考慮しないことでPMHFが上昇し、システムの安全性が過剰に評価される可能性があります。この点で、Note 5の規定は、実際の運行条件にそぐわないと感じられるかもしれません。

6. 結論

Note 5のアプローチは、運行中のリスク評価を過剰に行い、安全目標を確実に達成するための保守的な手法と見ることができます。しかし、これが合理的でないと感じる場合、その理由は、車両寿命全体でのリスク評価との間にギャップが生じるためと考えられます。今後の議論や改定において、この点が再検討される可能性はあるかもしれませんが、現在の規定は運行中のリスクを重視する姿勢を示しています。

ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。

前のブログ 次のブログ

ISO 26262において、矛盾のように思える事項がいくつかあります。これは解釈の誤りかもしれませんが、規格自体に詳しい説明が無いため、解釈の誤りかさえ判然としません。

ヒントをもらおうとChatGPTに聞きました。ChatGPTは規格委員会ではないので必ずしも正解を与えてはくれませんが、比較的蓋然性の高い回答をしてくれます。さらには多角的な見方をするので、思考範囲を拡大するのに役に立ちます。

まず、初版ではありますが、

ISO 26262-5:2011 9.4.2.3

NOTE 5 Situations when the item is in power down mode are not included in the calculation of the average probability per hour, thereby preventing the artificial reduction of the average probability per hour. Thus, for an item that is only operational 1 hour each day, the remaining 23 hours are not considered in the calculation of this operational target value.
注5 機器がパワーダウンモードにある状況は、1時間当たりの平均確率の計算には含まれない。これにより、1時間当たりの平均確率の恣意的な低下が防止される。したがって、1日あたり1時間しか稼働しない機器の場合、残りの23時間は、この稼働目標値の計算には考慮されない。

これは合理的ではないように思えます。なぜならPMHFは車両寿命間の平均故障率に近似される値であり、車両寿命間の稼働時間が少なければ少ないほど平均故障確率は下がるためです。これを「不稼働時間を計算に入れた恣意的な平均確率の低下」と言われると、納得がいきません。

さらに、IEC/TR 62380を参照すると、基礎故障率に以下の稼働確率をかけています。 $$ \frac{\tau_{on}}{\tau_{on}+\tau_{off}} $$ ここで$\tau_{on}$は一日の稼働時間割合、$\tau_{off}$は一日の不稼働時間割合です。

これはまさに「不稼働時間を考慮した(恣意的な?)故障確率の低減」であり、Note 5が禁止しているところになります。一方で、OEMから提供されるミッションプロファイルには不稼働時間が含まれており、実際の車両の使用方法に合わせるために、稼働確率をかけて平均故障確率を下げるのは合理的な手段です。

ISO 26262の入力であるIEC/TR 62380の段階で稼働確率をかけ、ISO 26262内でもさらに稼働確率を掛けると2重になるので禁止というなら分かりますが、Note 5ではそのようには言っていません。

前のブログ 次のブログ

締め切りは7/15だったため、初版の論文及びプレゼン資料(名前、所属無し版)を作成し、RAMSサイトに登録しました。初版で査読を受け9/1までに査読結果を受領予定です。

前のブログ 次のブログ

論文及びプレゼン資料の名前、所属無し版を作成し、RAMSサイトに登録しました。締め切りは7/15であるため、ブラッシュアップしたものを再登録する予定です。

前のブログ 次のブログ

弊社コンテンツの5月の検索結果です。

前のブログ 次のブログ

昨日RAMS委員会からアブストラクトの採択の連絡がありました。ほぼ論文は完成してはいるものの、これから論文のブラッシュアップ及びプレゼンテーション原稿の作成を開始します。

前のブログ 次のブログ

弊社コンテンツの4月の検索結果です。

前のブログ 次のブログ

RAMS 2025の締め切りが先週末5/10まで延長され、最終アブストラクトを投稿しました。

• 題名：
  Point Unavailability Processes with Periodic Inspections in ISO 26262
  ISO26262における定期検査を伴う点不稼働度過程

• 抄録概要：
  A study of the derivation and approximation of the exact point availability (PUA) and its derivative, the point unavailability density (PUD) processes, in deriving the probabilistic metric for random hardware failures (PMHF) formula under ISO 26262, aiming to refine automotive system design reliability by simplifying fault-tolerant subsystem development.
  耐故障サブシステム開発の簡素化による自動車システム設計の信頼性向上を目的とする、ISO26262に基づくランダムハードウェア故障の確率的指標(PMHF)式の導出における、厳密な点不稼働度(PUA)とその導関数である点不稼働度密度(PUD)過程の導出と近似に関する研究。

題名は本来「Point Unavailability and its Density Processes with Periodic Inspections in ISO 26262(ISO 26262における定期検査を伴う点不稼働度過程とその点不稼働度密度過程)」ですが、長すぎてシステムに入力できないため短くしました。これは査読により変更の可能性が十分にあります。後は6月初旬の採択通知を待つのみです。

本研究はブログ記事から始まったものですが、2020年の論文から導出し使用してきた不稼働度(PUA)の式が実は近似式であったということ、正確な式の導出及び誤差の評価を行ったものです。

前のブログ 次のブログ

以下の動画を公開しました。第1回はISO 26262の簡単な紹介の後、故障率とは何か、信頼度の導出というISO 26262の数理的な側面について解説します。

前のブログ 次のブログ

再度、重要項目の3項目めです。

ハードウェアメトリクスの目標値は、分解したからといって変わるものではない。多くの人はこのことを理解していない。

同感ですね。規格にはPart 9 5.4.5にこれが記されています(図781.1)。

規格5.4.5のDeepLによる翻訳を示せば、

5.4.5 ISO 26262-5 に従ったハードウェアアーキテクチャメトリクスの評価と、ランダムハードウ ェア故障による安全目標違反の評価に関する要件は、ASIL 分解によって変更されない。

これは弊社でもお伝えしている、ASIL分解に関する重要なノウハウの一つであり、ハードウエアの目標値を変えない理由についての動画の解説は以下のとおりです。

フォールト・ツリー解析の観点で考えてみると、本当に独立した2つの並列パスがある場合、これらはAND接続される。数学的には、それぞれの故障率が少し高くなり、さらに故障率が少し高くなっても、一番上の故障率が低くなるというのは、利点になる。したがって、フォールトツリーの最上位イベントは変わらないが、定量的安全性解析を実行すればメリットが得られる。

「故障率が少し高くなる」とは何を言っているかわかりませんが、端的に言えば、

• 冗長な独立性のあるエレメントの故障確率を(FTAにより)算出すれば、故障確率の掛け算になるため目標値を下げなくても故障確率のほうが下がるため、目標値を下げる必要は無い

し、かつ下げてはならないということです。

具体例として、故障率$\lambda$=100[FIT]の対称な冗長チャネル(両チャネルの故障率が等しい)について車両寿命10万時間で考えます。単体チャネルでは100[FIT]ですが、2重故障(同時故障ではない)を考えると、

$$100[FIT]\cdot100[FIT]\cdot10\times10^4[H]=1.0\times10^{-7}\cdot1.0\times10^{-7}\cdot1.0\times10^5\\ =100\times10^{-9}\cdot\frac{1}{100}=100[FIT]\cdot\frac{1}{100}$$

となり、すなわち、元の100[FIT]の100分の一の1[FIT]となります。つまり、ASILや目標値を下げなくても(ASILデコンポジションの必須条件である)冗長構成によりサブシステムの故障率は1/100にできたと言えます。

前のブログ 次のブログ