特にSMのパスの論理が分かりにくいので解説します。図941.1は前稿の図940.1のうちSM部を抜き出した図です。

$$\img[-1.35em]{/images/withinseminar.png}$$

図で見るように、SM部前半の検出手段は次の4つが存在します。

• APSの情報を受けTPSからのズレをメインマイコンが故障検出
• TPSの情報を受けAPSからのズレをメインマイコンが故障検出
• DRIVER_DIAGの故障診断をメインマイコンが故障検出
• サブマイコンによるメインマイコンの故障検出

RBDで書くとこのように、EGASシステムはいずれの故障が検出されてもORされ、リレーによりモータ電源が遮断される安全なシステムであると言えます。

一方FTでは動作ではなく故障を伝えるので、論理が反転となりORはANDになります。 RBDにおいては動作を

「いずれか一つの故障が検出されたら、モータ電源が遮断される」

と書き、FTでは

「全ての故障が起きた場合のみ、モータ電源が遮断されない」

と故障を書くわけです。つまりSMの動作ではなく、SMの故障について考えなければなりません。従って、図941.2のように、全ての故障検出のAND関係となります。

ただしSM部後半の手段のほうはこれと異なり、メインマイコンからリレードライバ経由でリレーが直列になっているため、メインマイコンかリレードライバのいずれかの故障でモータ電源が遮断されないOR関係となります。

結果として、SM部の前半のANDと後半のORを組み合わせると図941.3のようになります。これも手で構成したのではなく、ChatGPT により自動生成されたものです。 $$\img[-1.35em]{/images/withinseminar.png}$$ なお、本稿はRAMS 2026に投稿予定のため一部を秘匿していますが、論文公開後の2026年2月頃に開示予定です。

前のブログ 次のブログ

図940.1にSaphireで取得したMCSを示します。

Saphireで生成したcut setの表に対してPMHFの欄を追加し、かつ故障率の項を黄色で塗っています。#7～10のように黄色行が2段になっている積項はDPFを表します。万一DPF項が大きければ2nd SMの効果も加えなければなりませんが、割合の欄がいずれも0.01%未満なことからわかるように、DPFが全体に占める割合は非常に小さいことが多く、通常は2nd SMの効果は不要です。今後はこのような単項で0.01%未満の積項はMCS表から省略します。

さて、このMCSを分析します。

#1, #2の論理式を加えて見ると、次のようにMAIN_MCUはSMにより全く保護されていないことがわかります。

$$ \mathtt{MAIN\_MCU}\cdot \mathtt{COV\_90}+\mathtt{MAIN\_MCU}\cdot \mathtt{COV\_REM}\\=\mathtt{MAIN\_MCU}\cdot \mathtt{COV\_90}+\mathtt{MAIN\_MCU}\cdot\overline{\mathtt{COV\_90}}\\=\mathtt{MAIN\_MCU} $$

#1はSMが故障しているため保護されない場合であり、#2はSMが動作していても保護されない場合です。いずれにしてもSMにより保護されていません。

#2は通常のSMの動作であるものの、#1はIFとSMの両方のパスが故障しているので、これはいわゆるCCFでSMの効果を無効にします。

ちなみにこれは論理圧縮であるため、Saphireで実施しても良さそうですが、やってくれません。$\mathtt{COV\_90}$と$\mathtt{COV\_REM}$は$\mathtt{DC}$と$\mathtt{1-DC}$の関係にあるのですが、それぞれのイベントが無関係だからかと思い、$\mathtt{COV\_90}$と$\overline{\mathtt{COV\_90}}$にしても同じでした。

図940.2に#1のパストレース図を示します。

$$\img[-1.35em]{/images/withinseminar.png}$$

図940.3に#2のパストレース図を示します。

$$\img[-1.35em]{/images/withinseminar.png}$$

なお、本稿はRAMS 2026に投稿予定のため一部を秘匿していますが、論文公開後の2026年2月頃に開示予定です。

前のブログ 次のブログ

一連のスレッドですがタイトルは以前の記事から引き継いでいます。

それではEGASアーキテクチャのブロック図を図939.1に示すので、MARDを提供して下さい。

$$\img[-1.35em]{/images/withinseminar.png}$$

図939.1を読み取ったChatGPTの生成したMARDファイルを以下に示します。

TEST.BED

*Saphire 8.2.9
TEST =
* Name , Descriptions , Project
APS_SENSOR , APS sensor (1FIT) , TEST
TPS_SENSOR , TPS sensor (1FIT) , TEST
FCAN_LINE , FCAN line (10FIT) , TEST
MAIN_MCU , Main MCU (200FIT) , TEST
MOTOR_DRV , Motor driver (10FIT) , TEST
DRIVER_DIAG , Driver DIAG (1FIT) , TEST
SUB_MCU , Sub MCU (150FIT) , TEST
RELAY_DRV , Relay driver (10FIT) , TEST
COV_REM , SM leftover (1-DC=10%) , TEST
COV_90 , SM coverage (DC=90%) , TEST

TEST.BEI

*Saphire 8.2.9
TEST =
* Name ,FdT,UdC,UdT,UdValue, Prob, Lambda, Tau, Mission, Init,PF,UdValue2,Calc. Prob,Freq,Analysis Type,Phase Type,Project
APS_SENSOR ,3, , , , ,1.0E-009, ,1.0E+004, , , ,1.0E-005, ,RANDOM,CD,TEST
TPS_SENSOR ,3, , , , ,1.0E-009, ,1.0E+004, , , ,1.0E-005, ,RANDOM,CD,TEST
FCAN_LINE ,3, , , , ,1.0E-008, ,1.0E+004, , , ,1.0E-004, ,RANDOM,CD,TEST
MAIN_MCU ,3, , , , ,2.0E-007, ,1.0E+004, , , ,2.0E-003, ,RANDOM,CD,TEST
MOTOR_DRV ,3, , , , ,1.0E-008, ,1.0E+004, , , ,1.0E-004, ,RANDOM,CD,TEST
DRIVER_DIAG ,3, , , , ,1.0E-009, ,1.0E+004, , , ,1.0E-005, ,RANDOM,CD,TEST
SUB_MCU ,3, , , , ,1.5E-007, ,1.0E+004, , , ,1.5E-003, ,RANDOM,CD,TEST
RELAY_DRV ,3, , , , ,1.0E-008, ,1.0E+004, , , ,1.0E-004, ,RANDOM,CD,TEST
COV_REM ,1, , , ,1.0E-001, , , , , , ,1.0E-001, ,RANDOM,CD,TEST
COV_90 ,1, , , ,9.0E-001, , , , , , ,9.0E-001, ,RANDOM,CD,TEST

TEST.FTD

TEST =
* Name , Description, SubTree, Alternate, Project
TOP , TEST , , , TEST

TEST.FTL

TEST, TOP =
TOP AND IF_FAIL SM_FAIL
IF_FAIL OR APS_SENSOR TPS_SENSOR FCAN_LINE MAIN_MCU MOTOR_DRV SM_FAIL OR COV_REM SM_PATH SM_PATH AND COV_90 SM_EXPAND SM_EXPAND OR DETECT_FAIL CTRL_FAIL DETECT_FAIL AND APS_SENSOR TPS_SENSOR DRIVER_DIAG SUB_MCU CTRL_FAIL OR MAIN_MCU RELAY_DRV

TEST.GTD

TEST=
* Name , Description, Project
TOP , TEST , ,TEST
IF_FAIL , IF fail , ,TEST
SM_FAIL , SM fail , ,TEST
SM_PATH , coverage path , ,TEST
SM_EXPAND , SM expand , ,TEST
DETECT_FAIL , detection fail , ,TEST
CTRL_FAIL , control fail , ,TEST

図939.2にこれらのMARDをSpahireにロードし生成したFTを示します。

$$\img[-1.35em]{/images/withinseminar.png}$$

なお、本稿はRAMS 2026に投稿予定のため一部を秘匿していますが、論文公開後の2026年2月頃に開示予定です。

前のブログ 次のブログ

よく見ると、「3層構造(入力-制御-出力)」というChatGPTの回答は誤りです。EGASの3層というのは
Level 1 --> Intended control function with QM(x)
Level 2 --> Function monitoring with ASIL x(x)
Level 3 --> Controller monitoring with ASIL x
というものです。

ChatGPT:
以下では、EGAS(Electronic Gas)における2チャネル・3層安全アーキテクチャを「入力-制御-出力」という一般的な階層分けとは切り離し、EGAS特有の機能層・監視層の構成として整理します。ポイントは、(1) 物理的・論理的に2系統（チャネル）を用意し、(2) それぞれの機能レイヤを3段階に分けて安全を担保する点にあります。

1. 「2チャネル」とは？

EGASの電子スロットル制御では、メイン系(Main)とモニタ系(Monitor)の2つのチャンネル（あるいは2エレメント、2経路）を用意し、それぞれが異なるロジックやハードを持ちながら互いの動作をクロスチェックする構造が一般的です。

1. メイン系 (Main Channel)

   • エンジントルクやスロットル開度を演算し、実際のアクセル操作に応じた制御を行う。
   • いわゆる「意図した機能」(Intended Function)を中心に担当。

2. モニタ系 (Monitor Channel)

   • メイン系の演算結果（目標スロットル開度や出力トルクなど）を常時監視し、妥当かどうかをチェック。
   • メイン系に異常が発生していると判断すれば、リミット制御やアイドル制御など安全側への切り替えを行う。

両チャネルが別々のマイコンや独立したCPUコアを用いることにより、単一点故障や暴走（ソフトウェアのバグ含む）が両系統へ波及しにくくなり、ISO 26262などで求められる高いASIL要求に対応しやすくなります。

2. 「3層(レベル)」とは？

EGASにおける「3層安全アーキテクチャ」は、下記のように機能と監視機能を段階的に分けた3レベルを示します。これは物理的な入出力ではなく、安全機能を階層化している点が重要です。

1. Level 1: Intended control function (QM)

   • スロットル開度やエンジントルクを計算し、通常の走行時に必要な機能を提供する層。
   • ISO 26262の安全目標から外れている(=QM)場合や、ASILが非常に低いレベルとして扱われることが多い。
   • いわば「メイン制御」の本体。

2. Level 2: Function monitoring (ASIL x)

   • 上記「Level 1」が不適切な制御（例：過剰トルク）を行っていないか、機能そのものを監視する層。
   • 異常を検知したら、安全側への制御介入（リミット制御やシャットダウン等）を行う。
   • ここにはISO 26262で定義されるASIL(A～D) が割り当てられ、一定の故障検出率やフェイルセーフを実装。

3. Level 3: Controller monitoring (ASIL x)

   • 「Level 2」の監視機能自体が故障・暴走していないかをさらに上位の視点で監視する層。
   • マイコン全体の健全性（ウォッチドッグやメモリ保護など）も含め、モニタ系が正しく動作しているかを診断。
   • ここでもASIMレベルが課され、万一Level 2が壊れた際に最悪の誤作動へ至らないような仕組みをもつ。

2.1 3層の狙い

• 1段目(メイン機能)が故障した場合、2段目(機能監視) が検知・安全化する。
• 2段目(機能監視)自体が故障した場合、3段目(コントローラ監視) がそれを検知してシステムを安全側に制御する。

こうした「多層（多段）の監視」により、一つの故障（もしくは一つのバグ）だけで過度な加速や危険な出力が発生し続けない構造を狙っています。

3. 2チャネル × 3層アーキテクチャの全体像

まとめると、EGASの安全アーキテクチャは“2チャネル”（メイン系とモニタ系）を物理的に用意しつつ、論理的には“3つの安全機能レベル”（意図した機能 → 機能監視 → コントローラ監視）を実装しています。

1. メイン系
   
   • Level 1 (QM) の意図した制御を実装し、アクセルペダル入力からトルク/スロットルを算出。
   • Level 2の監視を受ける対象。
2. モニタ系
   
   • Level 2 (機能監視, ASIL x) と Level 3 (コントローラ監視, ASIL x) の役割を担い、メイン系や自身の動作を常に監視。
   • モニタ系内でもさらに、機能を監視する部分とモニタ自体を監視する部分が階層化されることもある。

2チャネルは冗長・相互監視を可能にし、3層の安全機構は故障や誤動作を段階的に検知し、最終的に安全側へ制御できるような構成を実現します。

4. 具体的な挙動イメージ

1. 通常動作

   • Level 1（メイン制御）がスロットル開度を演算し、車両走行に必要なトルクを提供する。
   • Level 2（機能監視）はメイン制御の出力値・センサ値等を常時チェック。
   • Level 3（コントローラ監視）はモニタ系が正しく実行されているかをさらに監視。

2. メイン制御が誤った出力を指示 (ソフトバグや故障)

   • Level 2が異常に気付き、スロットルを制限もしくはアイドル付近に固定して安全を確保。
   • これにより、意図しない加速が起き続けない。

3. モニタ系（Level 2）が故障して監視不能

   • Level 3（コントローラ監視）で、モニタ機能自体が応答しない/妥当な検出を行えていないと判断し、フェイルセーフへ移行。
   • たとえ監視機能が壊れても、最終的に安全側へ逃げる設計が可能になる。

5. まとめ

• 2チャネル: メイン制御（Level 1）と、その制御を監視するモニタ系を物理的に分離・冗長化。
• 3層(レベル)構造:
  
  1. Level 1: Intended control function (QM)
  2. Level 2: Function monitoring (ASIL x)
  3. Level 3: Controller monitoring (ASIL x)

この「2チャネル × 3層安全アーキテクチャ」により、EGASの電子スロットル制御では単一点故障やソフトウェア不具合が発生しても危険なトルクが出続ける事態を防止し、ISO 26262のような機能安全規格で要求される高いASIL水準を満たす設計が可能となります。

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

前のブログ 次のブログ

ランダムハードウエアフォールトに関するCCFになりやすいエレメントとして、電源やマイコンが挙げられます。電源はSMが構成しにくい、電源ICやマイコンは自己診断機能があるがCCFに弱い等。このようにCCFに弱いエレメントに対するSMの強化にはどのようなものがありますか？

ChatGPT:
以下では、まずCCF（Common Cause Failure）に弱いエレメント（特に電源やマイコン）に対して、どのようなSafety Mechanism（SM）の強化策が考えられるかを整理します。

1. CCFに弱いエレメントへのSM強化策

1.1 電源まわり

電源（レギュレータや電源IC）はシステム内の複数エレメントへ同一電源を供給していることが多く、故障すると全系統に影響が及ぶため、CCFリスクが高い典型的な箇所です。また、自己診断機能を組込みにくい・故障検出が難しいという問題もあります。

1. 電源の物理的・論理的分割
   
   • メイン系とモニタ系で独立したレギュレータを使用する。
   • 可能であれば異なるメーカーや異なる内部構造の電源ICを採用し、多様化（Diversity）でCCFリスクを低減する。
2. 電源監視IC（スーパーバイザ）の強化
   
   • $V_{\text{core}}, V_{\text{IO}}, V_{\text{analog}} $ など複数電源を同時監視し、閾値を下回ったり異常上昇（過電圧）を検知したら速やかにリセットや出力シャットダウンを行う。
   • ウォッチドッグとは別に、独立監視ICを設けることでマイコンが暴走しても監視機能が維持される。
3. バックアップ電源や冗長電源の導入
   
   • 安全上クリティカルなECUでは、非常用のバッテリやコンデンサを利用し、一時的にでも制御を継続できる仕組みを検討する（ただし車載では大容量バッテリを多重化するのは難しいため、限定的に実装される場合が多い）。
4. 物理的実装面でのノイズ・熱対策
   
   • レギュレータ周辺の放熱設計やEMI/EMC対策が不十分だと、ノイズや熱暴走が同時に全系統へ影響しやすい。
   • コンデンサやインダクタを高信頼部品にして経年変化・故障率を下げる。

1.2 マイコン（MCU, MPU）まわり

マイコンも電源と同様、システム制御の要となるため、マイコン1つが故障するとメイン系＋モニタ系いずれも機能不全に陥る可能性があります。自己診断機能（BIST, ECCなど）はあるものの、同じシリコンや同じアーキテクチャを使う場合にはCCFのリスクが高いです。

1. 多様化（Diversity）の検討
   
   • メイン系とモニタ系で異なるベンダーや異なるCPUコアを使う（例：ARM系＋RH850系など）。
   • 同一ベンダーであってもステッピングやシリコンリビジョンをずらす。
2. 自己診断機能のレイヤ分け
   
   • マイコン内のLockstep構成（2つの演算ユニットが同時に同じ命令を実行し比較）やECC付きメモリ、クロックモニタなどの機能を活用し、単一点故障を高確率で検出する。
   • モニタ系（または外付けの安全IC）が定期的にメイン系マイコンの診断情報を参照し、異常を検知した際にはフェイルセーフへ遷移。
3. 物理的分離によるCCF緩和
   
   • PCB上でメイン系マイコンとモニタ系マイコンを物理的に離し、同一箇所の熱や振動、EMIを受けにくくする（多少の効果ではあるが、ゼロにはできない）。
   • クロック源やリセット回路、電源回路を別々に持ち、1つの共通不具合で両方が巻き込まれないようにする。

2. まとめ

• CCFに弱いエレメント（電源・マイコン等） のSM（Safety Mechanism）強化では、
  
  1. ハードウェア多様化（異なるIC・ベンダー）
  2. 監視回路の充実（電源監視IC・クロック監視等）
  3. 物理的分離・実装上のノイズ対策・熱対策
     などが効果的です。

こうしたアプローチにより、CCFリスクを定量/定性の両面で評価・低減し、ISO 26262の要求する安全目標を満たす設計・分析が可能となります。

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

前のブログ 次のブログ

2エレメントの間のCCF、もしくは3層の間のCCFが起きる可能性は無いか探してください。

ChatGPT:
2エレメント構成や3層構造によって単一点故障への耐性を高めたとしても、CCF (Common Cause Failure: 共通要因故障) の可能性がゼロにはなりません。ISO 26262などの機能安全規格においても、CCFは必ず考慮すべき重要なリスクとして明示されており、メイン系とモニタ系の間、あるいは入力層・制御層・出力層の各層間で同時故障につながる共通要因が潜在していないかどうかを評価・低減するプロセスが必要です。

以下では、(1) 2エレメント間のCCF要因 と (2) 3層間のCCF要因 をそれぞれ整理し、どのように発生しうるかとその対策の考え方を概説します。

1. 2エレメント(メイン系とモニタ系)間のCCF要因

2つの独立した制御経路(エレメント)を用意しても、以下のような“共通要因”が原因で両系統が同時にダウンしたり、誤作動を起こす可能性があります。

1-1. 同一ソフトウェア/ツールチェーンに起因するバグ

• 概要
  メイン系・モニタ系ともに、同一ソースコード(同一アルゴリズム)や同一コンパイラを使っている場合、共通のソフトウェアバグやコンパイラバグにより、両系統が同時に不正な動作を行う可能性があります。
• 対策
  
  • ソフトウェア多様化: 重要な演算ロジックを別言語や別アルゴリズムで実装(同一バグに陥る確率を下げる)。
  • ツールチェーン多様化: 可能な範囲で異なるコンパイラ/リンカを使用し、共通バグを回避する。
  • ソフトウェア検証プロセス(静的解析、MISRA適合、単体/結合テスト)の強化。

1-2. ハードウェア/電源まわりの設計不良やノイズ

• 概要
  メイン系とモニタ系が同一基板や同一電源回路を共有している場合、電源の瞬断、過電圧、過剰ノイズなどが同時に両系統へ悪影響を与え、同時故障につながる可能性があります。
• 対策
  • 電源の物理的/論理的分離(例: メイン系とモニタ系それぞれに独立したレギュレータやフィルタを配置)。
  • グラウンド(アース)のパターン分離やノイズフィルタの追加。
  • システムレベルでのEMC/EMI試験を十分実施し、外来ノイズやサージに対する保護回路を強化。

1-3. 製造不良や同一ICの“シリコンバグ”

• 概要
  メイン系・モニタ系が同一型番/同一シリコンのマイコンを使用している場合、製造段階の欠陥(シリコンバグ)や経年劣化が同じタイミングで顕在化する場合があります。
• 対策
  • 異なるベンダーや型番のマイコンを採用して多様化を図る。
  • メイン系とモニタ系でステッピング(製造ロット)をずらす。
  • シリコンベンダーが公表するエラッタ情報(Errata)を確認し、回避策を適用。

2. 3層(入力・制御・出力)間のCCF要因

3つの階層に分割して冗長化/診断機構を組み込んでも、各層のあいだに生じる共通要因で故障が波及し、同時に多層が機能不全に陥るリスクがあります。

2-1. センサ層(入力層)の共通ハーネス不良や環境要因

• 概要 ペダル位置センサやスロットル位置センサを二重化していても、配線ハーネスの取り回しが同一ルートを経由していると、ショートや断線が同時に起きやすい。また、過酷な環境(高温・高湿・塩害・振動など)が同時に複数のセンサを故障させる可能性もある。
• 対策
  • 配線・コネクタのルーティングを分離し、単一点障害で両チャネルを同時に失わない設計。
  • 異なる物理センサ(ホール素子式 + ポテンショ式 など)を併用し、共通の故障モードを減らす。
  • 防水・防振・防塵などハードウェアの実装クオリティを向上。

2-2. 制御層(マイコン/ソフト)での同時障害

• 概要
  制御層(メイン系・モニタ系)はもともと2エレメントに分かれていますが、OSやハードウェアリソースの一部を共有するなど、内部的に共通する部分(電源、クロック、リセット回路、ウォッチドッグなど)がある場合、そこが1箇所壊れただけで両系統ともダウンするリスクがあります。
• 対策
  
  • 重要なクロック源やリセット回路などを2系統分離、あるいはシステムレベルで安全監視する。
  • ソフトウェアのコモンモジュール(初期化処理など)がバグを含んでいないか、入念なレビューを実施する。

2-3. 出力層(アクチュエータ)の機構的共通故障

• 概要 スロットルアクチュエータや燃料噴射、点火系統などの出力段が、機構的に一つのモータやバルブに依存している場合、仮に電気的な二重化があっても、機械部品(モータ軸、ギア、バルブシャフト)の破断や固着が起きると両系統とも動作不能になり得る。
• 対策
  • 機械的冗長化はコスト/スペース的に難しい場合が多いが、少なくともフェイルセーフ(バルブを閉方向にバネ戻しできる等)を備えて、過度な開度を防ぐ。
  • アクチュエータが致命的に壊れたときでも、車両を安全側へ導けるように“上位の安全コンセプト”を明確化しておく(例: エンジンが止まっても制動/操舵が可能、など)。

3. CCFの評価と対策(ISO 26262でのアプローチ)

ISO 26262では、CCFを考慮するために以下のようなアプローチが推奨されています。

3-1. 安全ゴールの明確化

• 例えば「スロットルが意図せず全開にならないようにする」「ブレーキが効かない状態を回避する」などの安全目標に対して、冗長化だけでなくCCF対策も含めたアーキテクチャが設計されているかを確認。

3-2. FMEDA/FTA (故障モード影響解析 / フォルトツリー解析)

• 個々の要素に対して、どんな故障モードがあるかを洗い出し、共通要因故障が起こりうる経路を特定する。
• その原因や発生頻度を見積もり、対策の導入可否や効果を検討。

3-1. 3. SEooC (Safety Element out of Context) の適切な利用

• 他のプロジェクトやベンダーが提供する「安全認証済み部品」を活用する場合でも、自システム特有の環境(温度、振動、電磁環境など)でCCFリスクが高まらないかを確認する。

3-1. 4. バリエーション解析 (Diversity Analysis)

• ソフトウェアアルゴリズム、ハードウェアアーキテクチャ、製造プロセスなど、多様化をどこまで実施するか。
• コスト・開発期間を考慮しながら、一定の多様化を取り入れてCCFの確率を現実的に低減。

4. まとめ

• 2エレメント(メイン系・モニタ系)間のCCF

  • ソフトウェアバグ、ハードウェアシリコンバグ、電源・ノイズ起因などにより、両系統が同時に誤作動する可能性はゼロではありません。
  • 多様化設計や電源分離・ノイズ対策を行い、共通要因による故障を極力低減します。

• 3層(入力層・制御層・出力層)間のCCF

  • センサ配線の共通断線、制御層共通部品(クロック、リセット回路)の不良、アクチュエータの機構的破損などで複数層が同時に機能不全になるリスクがあります。
  • 層ごとに物理的・論理的分離や診断機能を強化し、単一点障害が多層へ波及するのを防ぎます。

したがって「2エレメント」や「3層構造」によって冗長性は高まりますが、CCFの可能性が完全になくなるわけではありません。ISO 26262の要求に則り、CCFのリスクを洗い出した上で、ソフトウェア多様化・物理的分離・冗長設計・適切な診断(フェイルセーフ)などの対策を適切に組み合わせることが重要です。

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

前のブログ 次のブログ

挙げられたフォールトにはランダムハードウエアフォールトとシステマティックフォールトの2種類が混ざっています。ランダムハードウエアフォールトのみに関して、設計、検証上の注意点を教えてください。

ChatGPT:
ランダムハードウェアフォールト（Random Hardware Fault）は、シリコンや電子部品の経年劣化や物理的要因（放射線、温度、振動など）によって確率的に発生する故障であり、設計上・製造上のミス（いわゆるシステマティックフォールト）とは異なる性質を持ちます。ISO 26262の文脈でも、ランダムハードウェアフォールトに対してはハードウェアアーキテクチャメトリクス（Single Point Fault Metric, Latent Fault Metricなど）や、FMEDA (Failure Mode, Effects and Diagnostic Analysis) を用いて、想定される故障モードを分析し、必要な診断機能や冗長化を実装して要求レベル（ASIL）を満たすことが求められます。

以下では、ランダムハードウェアフォールトに着目したときの設計上・検証上の注意点を整理します。

1. 設計上の注意点

1-1. ハードウェアアーキテクチャメトリクスへの適合

ISO 26262 Part 5 では、Single Point Fault Metric (SPFM) や Latent Fault Metric (LFM)、さらにシステムレベルでは Probabilistic Metric for random Hardware Failures (PMHF) といった指標を達成する必要があります。
- SPFM: 単一点故障（検出されずに安全目標を侵害する恐れのある故障）の確率をいかに低く抑えるか。
- LFM: ある程度時間が経過しないと顕在化しない潜在故障をどれだけ検出できるか。
- PMHF: システムレベルで安全目標が侵害される確率を年間あたりいくつに抑えられるか。

これらを満たすため、以下のようなハードウェア診断・冗長化が設計段階で考慮されます。

1. 冗長化設計
   
   • 二重化(2エレメント)やモニタ系を持つことで故障検知と安全側制御を可能にする。
2. 自己診断機能(オンチップBIST, RAMテスト, ECC/パリティ等)
   
   • CPU/メモリ内部でのビット化け、回路の破損を検出する機構。
3. アナログフロントエンドの診断
   
   • センサ用ADCにリファレンス電圧監視、クロスチェックなどを用意して入力故障を検出する。

1-2. FMEDAによる故障モード・診断カバレッジの分析

部品レベルからECUレベルまで、FMEDA (Failure Mode, Effects and Diagnostic Analysis) を実施し、以下を明確にするのが一般的です。

1. 故障モードの洗い出し
   
   • 例: トランジスタ短絡、抵抗断線、コンデンサリーク、配線ショート、メモリビットフリップ等。
2. 故障の影響(Effect)評価
   
   • その故障が安全機能にどう影響を与えるか（単一点故障なのか、それともシステムは検出可能なのか）。
3. 診断方法(Diagnostic Coverage)の見積もり
   
   • どの診断機能を使ってどれくらいの確率で故障を検出できるのか。
4. 故障率(λ)の妥当性評価
   
   • 部品の信頼性データ（IEC TR 62380, SN29500, FIDESなどの信頼性規格）を参照し、ランダム故障率を定量化。

FMEDAの結果をもとに、冗長化や診断の追加を行いながら、要求されるハードウェアメトリクスを達成するかどうかを評価します。

1-3. 物理的・環境的要因への対策

ランダムハードウェアフォールトの発生率は、温度・振動・湿度などの使用環境によって大きく変化します。
- 温度上昇 → バイポーラトランジスタの熱暴走、電解コンデンサの寿命短縮など。
- 振動/衝撃 → はんだクラック、部品の破断など。
- 湿度/水分 → PCBへの腐食、漏電による誤作動。

設計段階で、ECUの筐体構造、防振設計、放熱設計、封止（ポッティング）などを吟味し、過酷な環境条件下でも故障率が過度に上がらないようにすることが必要です。

1-4. フェイルセーフコンセプト・安全機構の導入

ランダムフォールトが起きても、システム全体の安全を保つためのフェイルセーフコンセプトを策定します。

1. デグレード制御
   
   • 例: スロットルポジションがわからなくなったらリミット制御やアイドル固定。
2. フェイルサイレント化
   
   • 致命的な故障が発生した場合は、出力ドライバを強制的にOFFし、出力をカットする。
3. エスケープパス
   
   • 車両制御機能が部分的に失われても安全に停止できるようブレーキ・ステア系などの冗長設計を検討。

2. 検証上の注意点

2-1. ハードウェア診断機構のテスト

ランダムハードウェアフォールトを想定した診断機構（例: ECC、BIST、ウォッチドッグなど）が、実際に故障を想定した条件下で正しく検出・動作するかを検証します。

1. フォールトインジェクションテスト
   
   • シミュレーションやプロトタイプ基板上で、メモリビットフリップや回路短絡/断線を模擬して、診断が作動するかを確認する。
2. ソフトウェア診断ルーチンのデバッグ
   
   • ランタイムで実行するCPU自己診断、RAMテストなどが意図したタイミング・カバレッジで動作しているかを計測。

2-2. 信頼性試験・加速試験

• 環境試験(熱サイクル、振動、湿度、耐久試験)
  
  • ランダムフォールトの発生メカニズムを早期に引き起こすための加速試験(例: HALT/HASSなど)で、実際にどの程度の故障が発生するかを評価。
• バーンイン試験
  
  • 製造直後の初期故障(Infant Mortality)を除去するために、通電して高温環境下で一定時間運転し、不良素子を早期に検出。

2-3. FMEDA・FTAの整合性確認

• FMEDA結果で見積もった診断カバレッジや故障率をシステム全体のフォルトツリー解析(FTA) と照合し、
  
  • 「単一故障が検出できずに安全目標を侵害する確率が、ASIL要件を満たす範囲内にあるか」
  • 「複合故障の検出・制御がどの程度可能か」
    をシミュレーションや実機試験で確認する。

2-4. 整合性レポートとコンフィギュレーション管理

• 機能安全の開発プロセスでは、文書化と追跡性(Traceability) が重視されます。
• ランダムハードウェアフォールト対策として導入した設計・診断機能が、どの安全要求(SR: Safety Requirement)に対して妥当性を持つのかを明確にレポート化し、ソフトウェアやシステム全体と整合性を取ります。

3. まとめ

ランダムハードウェアフォールトは、システマティックフォールト（設計不良やソフトウェアバグ等）とは異なり、確率的に避けられない側面があります。そのため、ISO 26262のハードウェア開発プロセスでは以下が特に重視されます。

1. ハードウェアアーキテクチャメトリクス(SPFM/LFM/PMHF)の達成
2. FMEDAを中心とした故障モード解析と診断カバレッジ設計
3. 物理的・環境的要因を考慮した信頼性設計(温度、振動、防湿など)
4. 診断機能(オンチップBISTやECC等)とフェイルセーフコンセプトの徹底
5. フォールトインジェクションや加速試験等による検証

こうしたプロセスを通じて、ランダムハードウェアフォールトの発生率を可能な限り低減し、故障が発生しても安全要求を侵害しない(もしくは侵害の確率を必要十分に低く抑える)ようなシステムを実現することが重要となります。

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

前のブログ 次のブログ

2エレメントで3層構造を持つアーキテクチャの特徴を詳述してください。

ChatGPT:
以下では、EGAS(電子スロットル制御)システムに代表される「2エレメントで3層構造を持つアーキテクチャ」を例に、各層・各要素がどのように安全性を確保しているかを詳述します。なお「2エレメント」とは主にメイン系(Main)とモニタ系(Monitor)の2経路をもつことを指し、「3層構造」はセンサ入力層・制御(演算)層・アクチュエータ出力層の3段階にわたって安全を確保する仕組みを指します。

1. 全体像と目的

1. 2エレメント(二重構成)
   メイン系とモニタ系の2経路(あるいは2要素)を用意し、一方の故障を他方が検出して安全な状態に導くことが主眼となります。例えばメイン系がアクセル開度やエンジントルクを計算し、モニタ系が常時メイン系の出力値と自身で計算した値を比較することで、誤作動を即座に検出する構造です。

2. 3層構造(入力-制御-出力)
   典型的には以下の3つの層に分けて、それぞれで冗長性や診断を組み込みます。

   • 入力層: ペダル位置センサ、スロットル位置センサなど
   • 制御層: マイクロコントローラ(メイン系とモニタ系)、ソフトウェア
   • 出力層: スロットルバルブアクチュエータ、あるいは燃料噴射系など

各層ごとに故障診断(監視)やフェイルセーフを組み合わせることで、高いASIL(Automotive Safety Integrity Level)要求にも対応可能なアーキテクチャを構築します。

2. 入力層 (Sensor Layer)

1. 二重化センサ
   • アクセルペダル(APS: Accelerator Pedal Position Sensor)やスロットルバルブ位置(TPS: Throttle Position Sensor)などのセンサを、
     $$ 2 \text{系} \quad (\text{例: } \text{APS}_1, \text{APS}_2) $$ のように二重化(あるいは多重化)して設置します。
   • それぞれのセンサが出力する値を常時比較し、異常(出力の大きな乖離など)を検出した際には、メイン系・モニタ系のソフトウェアが安全状態(リミット制御やフェイルセーフ)に移行するようになっています。
2. 入力信号の妥当性チェック
   • メイン系マイコンとモニタ系マイコンの双方が、二重化センサから取得した信号に対して妥当性チェックを行います。
   • $(\text{APS}_1) $と$ (\text{APS}_2) $の差分が規定値以上なら警報やデグレードモード(パワー制限)へ移行するなど、安全に関する振る舞いをソフトウェア設計上で定義します。

3. 制御層 (Control/Computation Layer)

1. メイン系 (Main) とモニタ系 (Monitor)
   • メイン系:
     通常のエンジントルク演算、アクセル開度演算などを実施するメインのマイクロコントローラ(あるいはCPUコア)。実際にスロットルバルブや燃料噴射量などを決定します。
   • モニタ系:
     メイン系の演算結果が妥当かを常時監視するサブマイクロコントローラや第二のCPUコア。モニタ系は簡易的な演算(例: アクセル開度→トルクのざっくりとした見積もり)を並行して行い、メイン系の出力を比較・検証します。
2. クロスチェックと故障検知
   • 同一センサ情報の独立演算
     モニタ系もメイン系とは独立した方法または簡易モデルで同一センサ情報を演算し、メイン系の出力とのクロスチェックを実施します。
   • ウォッチドッグ(Watchdog)やタイマベースの監視
     メイン系・モニタ系の処理が停止したり暴走した場合に、ウォッチドッグタイマがリセットや出力無効化を指示し、出力層を安全側に移行させる仕組みを備えます。
3. ソフトウェアレイヤの多層防御
   • AUTOSARなどのソフトウェアプラットフォームを使用する場合、BSW(Basic Software) レイヤとASW(Application Software) レイヤでそれぞれ診断機能を実装します。
   • メモリ保護機構やプログラムフロー監視など、ハードウェア機能(例: Lockstep CPU、ECC保護つきメモリ)とも連携してソフトウェアの破損・暴走を検知します。

4. 出力層 (Actuator Layer)

1. スロットルアクチュエータの冗長化・診断
   • 出力段であるスロットルアクチュエータには、ポジションセンサを二重化するなどしてアクチュエータ内部でも故障を検知できるようにします。
   • モニタ系がスロットルアクチュエータの目標値と実際の開度を比較し、大きな差異が生じた場合は出力を制限する(リミット制御)またはアイドル状態に強制移行させるなどのフェイルセーフを実行します。
2. 電源制御やリレーによるフェイルサイレント化
   • 出力ドライバの電源ラインに安全リレーやFETスイッチなどを設け、システムが致命的な異常と判断した場合には強制的に駆動信号を遮断します(フェイルサイレント化)。
   • 遮断後はエンジン出力を絞ったり、アクセル操作が反映されない状態にすることで車両の安全を確保します。

5. アーキテクチャがもたらす安全メリット

1. 単一点故障への耐性
   いずれか1つのセンサやマイコンに故障が生じても、もう一方の正常系(メイン系またはモニタ系)で検知し、安全動作へ移行できる。
2. 潜在的な故障の早期検知
   クロスチェック(メイン系 vs モニタ系)により、たとえソフトウェアバグやメモリエラーなどの故障モードでも異常値を早期発見しやすい。
3. ASIL Dレベルへの適合が容易
   エンジン制御のような安全度要求の高い機能ではASIL Dが割り当てられる場合が多いが、2エレメント3層構造によって冗長性と故障検出率を高めることで、ISO 26262の厳しい要求を満たす設計を行いやすい。

6. まとめ

「2エレメントで3層構造を持つEGASアーキテクチャ」は、入力(センサ)・制御(マイコン)・出力(アクチュエータ)の各層において冗長化と診断機構を備え、かつメイン系とモニタ系という2つの経路で相互監視を行う仕組みです。これにより、単一点故障やソフトウェア異常を検出・隔離し、必要に応じて車両を安全状態に導くことが可能となります。ISO 26262で要求される高いASIL(特にCやD)にも適合するために、多層的な安全策が組み込まれるのが最大の特徴です。

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

前のブログ 次のブログ

EGASアーキテクチャについて、ChatGPTに聞いてみました。

機能安全、特にISO 26262において、EGASアーキテクチャとは何ですか？

ChatGPT:
機能安全（特にISO 26262）でよく言及される「EGASアーキテクチャ」とは、一般的に “Electronic Gas (またはGaspedal) System” の略称であり、いわゆるドライブ・バイ・ワイヤ(Drive-by-Wire)方式の電子スロットル制御システムを指します。従来のアクセルペダルとスロットルバルブをワイヤやリンケージで機械的につないでいた構造に代わって、ペダル位置センサ・電子制御ユニット(ECU)・スロットルアクチュエータといった電子的構成要素でアクセル開度を制御する仕組みです。

EGASアーキテクチャでは、以下のような機能安全上の特徴・考慮事項が存在します。

1. ペダル位置センサの冗長化
   アクセルペダルの踏み込み量を計測するペダル位置センサを二重化や多重化し、それぞれのセンサ信号を相互に監視することで故障検知を行います。ISO 26262では、ASIL（Automotive Safety Integrity Level）の要求に応じて十分な冗長度や故障診断機構を設計し、安全目標を満たす必要があります。

2. ECU内の監視機能（トルクモニタリング等）
   エンジントルクを演算するメインのマイクロコントローラに加え、モニタ用のサブマイクロコントローラやウォッチドッグなどを配置することで、メイン系の異常動作を検出します。必要に応じてフェイルセーフ（エンジンを強制的にアイドルにするといった制御）を実行し、車両の安全を確保します。

3. スロットルアクチュエータの安全機構
   スロットルバルブを動かすアクチュエータにも故障診断やフェイルセーフ動作を盛り込むことが求められます。例えば、スロットルバルブのポジションセンサを二重化して、開度に矛盾がないかをチェックする仕組みを設計します。

4. ASIL割り当てと安全コンセプト
   EGASのように車両の加速・減速に直接関わる機能は、ISO 26262におけるASIL評価で高いレベル（例：ASIL CやD）が割り当てられることが多く、それに応じて高度な故障診断、冗長化、監視機能が求められます。

要するに、EGASアーキテクチャは機械的リンケージを排して電子的にアクセル開度（スロットル開度）を制御するシステムの総称であり、ISO 26262の枠組みにおいては、故障時の安全性（フェイルセーフ）や冗長性を確保するためのさまざまな仕組みを持つことが重要とされています。これにより、アクセル制御の異常が起きても車両挙動が過度に危険にならないようにすることが、機能安全上の大きな目的となります。

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

以下はhttps://nvdungx.github.io/EGAS-concept/に掲載されている図の引用です。

前のブログ 次のブログ

次に、IFやSMを単一エレメントではなく複数エレメントのグループとします。これは実際には基本形のFTに対してIFやSMの部分はBEではなくサブツリーが配置されるため、その処理を行わせるためのAIに対する学習となります。

図932.1を読み取ったChatGPTの生成したMARDファイルを以下に示します。

TEST.BED

*Saphire 8.2.9
TEST =
* Name , Descriptions , Project
A , A fault (20FIT) , TEST
B , B fault (40FIT) , TEST
D , D fault (5FIT) , TEST
E , E fault (10FIT) , TEST
SM_IF_COVREM , SM_IF coverage leftover (1-DC=40%) , TEST
SM_IF_COV , SM_IF coverage (DC=60%) , TEST

TEST.BEI

*Saphire 8.2.9
TEST =
* Name ,FdT,UdC,UdT,UdValue, Prob, Lambda, Tau, Mission, Init,PF,UdValue2,Calc. Prob,Freq,Analysis Type,Phase Type,Project
A ,3, , , , ,2.0E-008, ,1.0E+005, , , ,2.0E-003, ,RANDOM,CD,TEST
B ,3, , , , ,4.0E-008, ,1.0E+005, , , ,4.0E-003, ,RANDOM,CD,TEST
D ,3, , , , ,5.0E-009, ,1.0E+005, , , ,5.0E-004, ,RANDOM,CD,TEST
E ,3, , , , ,1.0E-008, ,1.0E+005, , , ,1.0E-003, ,RANDOM,CD,TEST
SM_IF_COVREM ,1, , , ,4.0E-001, , , , , , ,4.0E-001, ,RANDOM,CD,TEST
SM_IF_COV ,1, , , ,6.0E-001, , , , , , ,6.0E-001, ,RANDOM,CD,TEST

TEST.FTD

TEST =
* Name , Description, SubTree, Alternate, Project
TOP , TEST , , , TEST

TEST.FTL

TEST, TOP =
TOP AND IF SM_IF
IF OR A B
SM_IF OR SM_IF_COVREM DPF
DPF AND SM_IF_COV SM_IF_GROUP
SM_IF_GROUP OR D E

TEST.GTD

TEST=
* Name , Description, Project
TOP , TEST , ,TEST
IF , IF Subtree , ,TEST
SM_IF , SM_IF , ,TEST
DPF , DPF , ,TEST
SM_IF_GROUP , SM_IF Subtree , ,TEST

図932.2にこれらのMARDをSpahireにロードし生成したFTを示します。

$$\img[-1.35em]{/images/withinseminar.png}$$

図932.3にSaphireで取得したMCSを示します。

Saphireで生成したcut setの表に対してPMHFの欄を追加し、かつ故障率の項を黄色で塗っています。これによりSPF/RFかDPFかが容易に理解されます。

なお、本稿はRAMS 2028に投稿予定のため一部を秘匿していますが、論文公開後の2028年2月頃に開示予定です。

前のブログ 次のブログ