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

前のブログ 次のブログ

過去記事に記載のとおり、RAMS 2025は、2025年1月27日から30日まで、米国フロリダ州ミラマービーチのヒルトンサンデスティンホテルで開催されました。弊社代表は2日目に論文発表を行いました。

本論文のタイトルは、"Point Unavailability and its Density Processes with Periodic Inspections in ISO 26262"です。邦題は「ISO 26262における定期検査を伴う点不稼働度とその密度過程」となります。

弊社が2020年のRAMSで提案したPMHFは、不稼働度または不稼働密度関数により定義されます。当時は定期検査の診断率をアーキテクチャ依存の定数と仮定し、不稼働度を導出しました。当時はこれを近似式と認識していましたが、今回診断率を条件付き確率に変更したうえで不稼働度の厳密式を導出しました。さらに誤差評価を行った結果、ASIL-Bの条件において両者にはほとんど差が無いことが分かりました。

また、弊社代表の、昨年2024年の論文がAlfred Stevens/Henry Hartt最優秀論文賞を受賞し、バンケットにおいて賞金として500ドルが授与されました。これは今回新設された賞で、本論文がISO 26262規格の誤りを明らかにしたことが評価されたものです。

プレスリリース

前のブログ 次のブログ

ChatGPTに前稿のRBDを読ませたところ、次のMARDを取得しました。 TEST.BED ～TEST.FTDの3ファイルは同一なので省略します。

TEST.FTL

*Saphire 8.2.9
TEST, TOP =
TOP AND IF_FAIL SM_FAIL
IF_FAIL OR APS_SENSOR TPS_SENSOR FCAN_LINE MAIN_MCU MOTOR_DRV MOTOR THROTTLE
SM_FAIL OR COV_REM SM_PATH
SM_PATH AND COV_90 SM_EXPAND
SM_EXPAND OR DETECT_FAIL CONTROL_FAIL
DETECT_FAIL AND LANE_APS LANE_TPS LANE_DIAG LANE_SUB
LANE_APS OR APS_SENSOR MAIN_MCU
LANE_TPS OR TPS_SENSOR MAIN_MCU
LANE_DIAG OR DRIVER_DIAG MAIN_MCU
LANE_SUB OR SUB_MCU
CONTROL_FAIL OR BLOCK_PAR RELAY_DRV RELAY
BLOCK_PAR AND MAIN_MCU SUB_MCU

TEST.GTD

*Saphire 8.2.9
TEST=
* Name , Description, Project
TOP , TEST , ,TEST
IF_FAIL , IF fail , ,TEST
SM_FAIL , SM fail , ,TEST
SM_PATH , SM coverage path , ,TEST
SM_EXPAND , SM expanded , ,TEST
DETECT_FAIL , detection fail , ,TEST
LANE_APS , lane APS , ,TEST
LANE_TPS , lane TPS , ,TEST
LANE_DIAG , lane DIAG , ,TEST
LANE_SUB , lane SUB , ,TEST
CONTROL_FAIL , control fail , ,TEST
BLOCK_PAR , parallel block , ,TEST

これらをSaphireに取り込んだところ、図943.1のようなFTが自動生成されました。

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

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

前のブログ 次のブログ

さてMCSを取ることにより、このアーキテクチャの欠点が見えてきました。

積項No.1とNo.2の論理和を取れば、 $$ \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} $$

積項No.1とNo.2の割合を加えれば89.04+9.89=99.29。このように、約99%以上のPMHFがメインマイコンとなっており、その理由は先の通りメインマイコンがIFパスとSMパスに存在するため、単一故障で両方のパス共に故障するためです。

これを避けるため、サブマイコンがメインマイコンの故障を検出したらいきなりリレーをオフするようにパスを変更します。

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

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

前のブログ 次のブログ

特に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 の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。

前のブログ 次のブログ