Posts Tagged with "PMHF"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.
posted by sakurai on May 28, 2025 #980

図%%.1
図%%.2
図980.2 RAMS 2026

2026年1月26日から米国ネバダ州ラスベガスのプラネットハリウッドホテルで開催される予定のRAMS 2026(72th Annual Reliability and Maintainability Symposium)に、弊社代表が投稿した論文のアブストラクトが採択されたとの連絡が届きました。まだアブストラクトの採択ですが、正式採択されれば7年連続、IEEEとしては8回目の採択となります。正式採択に向け、7月末の締め切りまでに論文をブラッシュアップしていくことになります。

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

表980.1 RAMS 2026へのマイルストーン
期限 マイルストーン 状態
2025/4/30 AJEにアブストラクトを修正依頼
2025/4/30 アブストラクト(氏名、所属無し版)投稿締め切り(システム入力)
2025/6/2
2025/5/27
アブストラクト採択結果 採択
2025/7/31 初稿論文、プレゼン投稿締め切り(氏名、所属無し版)
2025/9/30 最終論文、プレゼン投稿締め切り(氏名、所属有り版)
2025/10/10 IEEEコピーライトフォーム提出
2025/10/10 学会出席登録締め切り


左矢前のブログ 次のブログ右矢

PMHF式の誤りの論文 (2)

posted by sakurai on May 20, 2025 #976

そして、肝心のPMHFの式部分は以下のとおりです。

図%%.1
図976.1 論文のPMHF方程式

(3)では3つの故障率を単純に加えていますが、これは過去記事(下記)で取り上げた論文と同じく誤りです。

(3)式が誤りである理由はPMHFは確率由来だからであり、安全目標違反確率を求めるにはDPF項には故障率の二乗が必要だからです。具体的にはIFのMPF故障率とSMのレイテント故障率の二乗となります。一方(3)式はレイテント故障率を単純にSPF項と加算しています。

それにしてもPMHF式を引用する人たちはなぜ規格Part 10にPMHF式があるにもかかわらず、その公式を用いずに、論文$\dagger$の誤った式を参照するのでしょうか?参考にするなら規格式を参照すれば良いと思うのですが、今までに規格式を引用した論文を、ほぼ見たことがないことが不思議でなりません。


$\dagger$ Y. Chang, L. Huang, H. Liu, C. Yang and C. Chiu, "Assessing automotive functional safety microprocessor with ISO 26262 hardware requirements," Technical Papers of 2014 International Symposium on VLSI Design, Automation and Test, Hsinchu, 2014, pp. 1-4, doi: 10.1109/VLSI-DAT.2014.6834876.


左矢前のブログ 次のブログ右矢

PMHF式の誤りの論文

posted by sakurai on May 19, 2025 #975

PMHF式が誤っている論文は大変に多く、その元凶は2014年のこの論文$\dagger$のようですが、また発見しました。

K, Lu and Y. Chen, "Safety-Oriented System Hardware Architecture Exploration in Compliance with ISO 26262,", Appl. Sci. 12(11), MDPI, 2022.

アブストラクトの翻訳文を示します。

要約:安全性が重要な自動車用インテリジェントシステムは、動作中に厳しい信頼性が要求されます。そのため、このような安全性が重要なシステムの開発では、安全性と信頼性の問題に対処しなければなりません。しかし、安全/信頼性の要件をシステムに組み込むと、設計の複雑さが大幅に増します。さらに、国際的な安全規格はガイドラインしか提供しておらず、具体的な設計手法やフローは示されていません。そのため、システム設計および検証の複雑さに対処し、国際的な安全規格の要件も満たす、システムエンジニアを支援する効果的な安全プロセスを開発することが、重要かつ価値のある研究課題となっています。本研究では、フォールトツリーに基づく脆弱性分析と安全志向のシステムハードウェアアーキテクチャの探索を統合した、安全志向のシステムハードウェアアーキテクチャ探索フレームワークを提案します。このフレームワークにより、ISO-26262 の安全要件およびハードウェアのオーバーヘッドの制約に準拠した、効率的なソリューションを迅速に発見することができます。探索フレームワークの実行後に、故障モード、影響、および診断分析(FMEDA)レポートが生成されます。提案したフレームワークは、システムエンジニアが、コスト効率の高い方法でシステムの安全性/堅牢性の設計、評価、および強化を行うことを容易にします。

ちなみに弊社の論文も[7]及び[10]の2件が参照されているものの、数式は全く考慮されていません。

図%%.1
図975.1 論文の参照文献[7]

これに対する本文での引用は以下のようです。

[7] の著者は、ISO 26262 に基づいて適用範囲を拡大するため、ミッション機能の故障率、安全機構の故障率、一次安全機構および二次安全機構の診断カバレッジ、二次安全機構の診断期間などの観測可能なパラメータを用いて、非冗長および冗長サブシステムにおける PMHF の計算のための一般化された式を提示しました。

全くこのとおりなので、このPMHF公式を参考にしてもらえば良かったのですが。

図%%.2
図975.2 論文の参照文献[10]

[10] の研究は、規格の重要な前提である定期的な検査と修理を考慮しながら、定量的なFTAのフレームワークを提供することを目的としています。このフレームワークは、マルコフ確率過程のモデルと、そのモデルから導式化したPMHF方程式に基づいています。

全くこのとおりなので、定期的な検査と修理を考慮したPMHF公式を参考にしてもらえば良かったのですが。 論文は批判的に読むものであって、このように自論文の飾りにするだけでは引用としての意味がありません。


$\dagger$ † Y. Chang, L. Huang, H. Liu, C. Yang and C. Chiu, "Assessing automotive functional safety microprocessor with ISO 26262 hardware requirements," Technical Papers of 2014 International Symposium on VLSI Design, Automation and Test, Hsinchu, 2014, pp. 1-4, doi: 10.1109/VLSI-DAT.2014.6834876.


左矢前のブログ 次のブログ右矢

posted by sakurai on March 24, 2025 #964

AJEに依頼したアブストラクトの修正が返ってきたので反映し、システムに登録しました。今回のIDは#17で、採択の発表は6月2日とのことです。

表964.1 RAMS 2026へのマイルストーン
期限 マイルストーン 状態
2025/4/30 AJEにアブストラクトを修正依頼
2025/4/30 アブストラクト(氏名、所属無し版)投稿締め切り(システム入力)
2025/6/2 アブストラクト採択結果
2025/7/31 初稿論文、プレゼン投稿締め切り(氏名、所属無し版)
2025/9/31 最終論文、プレゼン投稿締め切り(氏名、所属有り版)
2025/10/10 学会出席登録締め切り


左矢前のブログ 次のブログ右矢

posted by sakurai on March 13, 2025 #960

AJEに依頼した論文のアブストラクトが返ってきたので、修正し再依頼しました。アブストラクトなのでそれほどやりとりなく、次で完了する予定です。

表960.1 RAMS 2026へのマイルストーン
期限 マイルストーン 状態
2025/4/30 AJEにアブストラクトを修正依頼 修正中
2025/4/30 アブストラクト(氏名、所属無し版)投稿締め切り(システム入力)
2025/6/2 アブストラクト採択結果
2025/7/31 初稿論文、プレゼン投稿締め切り(氏名、所属無し版)
2025/9/31 最終論文、プレゼン投稿締め切り(氏名、所属有り版)
2025/10/10 学会出席登録締め切り


左矢前のブログ 次のブログ右矢

posted by sakurai on March 12, 2025 #959

次回RAMS 2026に投稿する論文「Optimizing Fault Tree Analysis for Probabilistic Metrics Using Large Language Models in ISO 26262」を作成しました。アブストラクトをAJEに投稿中です。

表959.1 RAMS 2026へのマイルストーン
期限 マイルストーン 状態
2025/4/30 AJEにアブストラクトを投稿
2025/4/30 アブストラクト(氏名、所属無し版)投稿締め切り(システム入力)
2025/6/2 アブストラクト採択結果
2025/7/31 初稿論文、プレゼン投稿締め切り(氏名、所属無し版)
2025/9/31 最終論文、プレゼン投稿締め切り(氏名、所属有り版)
2025/10/10 学会出席登録締め切り


左矢前のブログ 次のブログ右矢

posted by sakurai on March 3, 2025 #957

次回RAMS 2026に投稿する論文「Deriving Accurate Probabilistic Metrics (PMHF) with Imperfect Large Language Models in ISO 26262」を作成しました。アブストラクトを修正中で、AJEに出してから3/EまでにRAMSに投稿予定です。

表957.1 RAMS 2026へのマイルストーン
期限 マイルストーン 状態
2025/4/30 アブストラクト(氏名、所属無し版)投稿締め切り(システム入力)
2025/6/2 アブストラクト採択結果
2025/7/31 初稿論文、プレゼン投稿締め切り(氏名、所属無し版)
2025/9/31 最終論文、プレゼン投稿締め切り(氏名、所属有り版)
2025/10/10 学会出席登録締め切り

過去に掲載した論文の実績と予定をアップデートします。

表957.2 PMHF論文の実績と予定表
No. 学会 論文タイトル 内容 採択/未
1 2017 ISPCE Generalized formula for the calculation of a probabilistic metric for random hardware failures in redundant subsystems PMHF式を初めて冗長系に拡張し提案 ISPCE 2017 最優秀論文賞
2 2020 RAMS Generic Equations for a Probabilistic Metric for Random Hardware Failures According to ISO 26262 PMHF式を初めて理論的に導出、提案 採択
3 2021 RAMS A Framework for Performing Quantitative Fault Tree Analyses for Subsystems with Periodic Repairs 理論的に導出したPMHFのFTA構成法 採択
4 2022 RAMS Formulas of the Probabilistic Metric for Random Hardware Failures to Resolve a Dilemma in ISO 26262 LFMと整合するPMHF式の導出及び提案 採択
5 2023 RAMS Stochastic Constituents for the Probabilistic Metric for Hardware Failures 確率構成要素を用いたIFRモデルの証明 採択
6 2024 RAMS Identifying and Rectifying the Potential Faults in Probabilistic Metric (PMHF) Formula in ISO 26262 規格第2版のPMHF式の誤りと正確なPMHF式の提案 RAMS 2025最優秀実用論文賞
7 2025 RAMS Point Unavailability and Its Density Processes of Repairable Element with Periodic Inspections in ISO 26262 定期検査する修理可能エレメントのPUAとPUD 採択
8 2026 RAMS Deriving Accurate Probabilistic Metrics (PMHF) with Imperfect Large Language Models in ISO 26262 低信頼LLMを用いた定量FTAの方法
9 2027 RAMS 未定 定量FTAにおける2次安全機構の効果
10 2028 RAMS 未定 PMHF式導出における不稼働度の近似式
11 2029 RAMS 未定 EOTTIの導出
12 2030 RAMS 未定 未定


左矢前のブログ 次のブログ右矢

posted by sakurai on February 18, 2025 #951

そもそもEGASアーキテクチャはメインマイコンが主機能を担当し、サブマイコンはメインマイコンのモニタ的な扱いです(EGASの2チャンネル構成の意義)。そこから考えると案1と案4では得失はどうでしょうか?

ChatGPT
以下では、EGAS の 2 チャンネル構成において「メインマイコンが主機能 (IF) を担当し、サブマイコンはモニタ的な扱いである」という前提のもと、案1(サブマイコンが幅広く異常検出 & リレー直接制御)案4(サブマイコンはメインマイコン死活を監視し、故障時にリレーを直接制御) について得失を整理します。


案1: サブマイコンが幅広く検出し、リレーを直接制御

  • 誰が検出?

    • サブマイコンが APS, TPS, Driver Diag などメインのセンサ情報も取り込むか、少なくとも同様の情報を並列でもらう。
    • メインマイコンが主機能を担当していても、サブマイコンがセンサを「モニタ的」にフル読みしている場合には、サブマイコンが完全なバックアップルートを形成。
  • 誰がリレーをオフ?

    • サブマイコンが単独で Relay Driver を直接駆動しリレーを切る。

メリット

  1. サブマイコンが主機能と同レベルでセンサを取得 → メインマイコン故障や誤動作のみならず、「APS/TPS故障」自体もサブマイコンが独立に検出し、リレーOFFできる。
  2. 故障検出の並列度が高い (メイン・サブそれぞれが全センサを見ている) → 異常検出カバレッジを拡大しやすい。

デメリット

  1. モニタ的アーキテクチャ以上に大きなソフトウエア負担** → サブマイコン側もAPS/TPS等の取得ロジックや診断フローを実装。
  2. 「メインマイコンが主機能担当」というEGAS設計思想からすると、サブマイコンにセンサ処理を大きく複製するのはオーバースペックになる場合がある。

案4: サブマイコンが主に「メインマイコン故障」を監視し、故障時にリレーを直接制御

  • 誰が検出?

    • サブマイコンはメインマイコン(および一部限られた診断線)をウォッチして「メインマイコンが固まった/故障している」ことを検出。
    • APS/TPSなどの主センサ異常は基本メインマイコンが担当し、サブマイコンはそこまでは見ない(あるいは簡易モニタ程度)。
  • 誰がリレーをオフ?

    • サブマイコンがメインマイコンを経由せずリレーを制御 → メインが死んでもサブマイコンがオフ可能。

メリット

  1. モニタ的なサブマイコンの立ち位置を大きく変えない → 「主機能はメインマイコンが行う」EGASの設計思想を守る。
  2. ソフト負担が比較的軽い → サブマイコンはメインマイコンの死活監視が中心。APS/TPSなどの大きな計算や詳細診断をサブマイコンで実装しなくてよい。
  3. メインマイコンに異常があったときのみ “非常停止” できる → 最低限の安全保証は確保。

デメリット

  1. 「APS/TPSなどセンサ異常」まではサブマイコンが検出せず → メインマイコンが誤検知や故障を起こすと、サブマイコン視点では「メインマイコンが動いているかどうかしかわからない」ため、センサ異常をメインマイコンが見逃したら、サブマイコンがカバーできない
  2. Driver Diagもメインマイコン側で見ている構成だと、サブマイコンはそれを直接見ないため、Driver Diagの異常がメインで見逃されたら危険残る。

得失の比較

項目 案1 案4
サブマイコンの役割 幅広いセンサ検出 (APS/TPS/Driver Diag 等) + リレー制御 主にメインマイコン死活監視+簡易モニタ(故障でリレーOFF)
ソフト負担 大きい(サブマイコンがセンサ処理を重複実装) 比較的軽い(メイン死活監視+リレー制御ルーチン程度)
主機能 vs モニタ サブマイコンが主機能のバックアップとして十分機能できる メインマイコンが主機能、サブマイコンはあくまで死活監視メイン
検出カバレッジ拡大 しやすい(サブマイコンがAPS/TPS等を独立に見られる) メインマイコン故障時だけはカバーするが、APS/TPS異常はメイン依存
EGAS思想への整合 やや大きく変更(サブマイコンがほぼ主機能並みに働く) 従来の「主機能=メイン、モニタ=サブ」の思想を大きく崩さない
コスト面 追加ハードは不要だがソフト大幅改修の可能性あり 追加ハード不要、ソフト改修は監視部とリレー制御のみ

結論

  • 案1案4 はどちらも「メインマイコンが死んでもサブマイコンでリレーをOFF可能」となるが、
    • 案1 はサブマイコンが「APS/TPS/DriverDiag」等もフルカバーし、故障を幅広く検出 → サブマイコンが主機能に近い
    • 案4 は「サブマイコンはメインマイコン故障の監視が中心、センサ大半はメインが担当 → ソフト負担軽」 → EGASの“主=メイン / モニタ=サブ”構造を保ちやすい

EGASアーキテクチャで「メインマイコンが主機能/サブはモニタ」の大枠をあまり崩したくないなら、案4 がより自然。一方、サブマイコンが本格的にAPS/TPS等を独立処理できるなら案1の安全度は高いが、システム変更が大きい。

よって案4はEGASの2チャンネル構成を大きく変えずに「メインマイコン死活監視 → リレー直接制御」を追加するだけで済むため、最もEGAS思想に近く、低コストでメインマイコン故障をカバーできると言えます。

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


ユーザとの会話により、ChatGPTの結論としてユーザ提案回路と同一となったものの、その道のりにはいろいろなポイントが含まれており、なかなか示唆に富む会話だったと思います。

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


左矢前のブログ 次のブログ右矢

posted by sakurai on February 17, 2025 #950

コストがかからない方法が良いというのがユーザ要求です。サブマイコンは既にEGASアーキテクチャ上存在するので追加費用ゼロ、一方ロジックICは数十円でもあまり良くありません。例えば案4と案2は遮断手段のみが違うようですが、案2の案4に対する優位性はありますか?無いなら案1と4に絞られると思います。

ChatGPT
以下では、案2(ロジックICを追加)案4(サブマイコンがメインマイコン故障を監視&直接リレー制御) に対して、コスト面・機能面でどのような優位性があるかを整理しつつ、もしメリットが無いなら案1 or 案4に絞る、という視点で回答します。


案2の特徴

  • ロジックIC(数十円程度)を用い、ハードウェア的に複数の“故障検出線”をまとめ、どれかが“危険”を示せば強制的にリレードライバをOFFする回路を構築する。
  • 検出はメインマイコン+サブマイコン+Driver Diag など、複数の出力信号があり、「いずれかがアクティブになったらリレーを落とす」といったORゲート有線AND/ORなどをロジックICで実装する。
  • 費用:IC数十円+基板配線工数。

案2のメリット

  1. ハードウェア化によりソフト依存を減らす
    • どちらのマイコンがどの異常を検出しようが、ロジックICが最終的にリレーオフをまとめて実行するため、ソフトの変更が少なくて済む(既存MCUのコードを大幅にいじらなくても、一つの故障信号ラインをICに入れるだけ)。
  2. メイン/サブマイコン以外からの直接信号も簡単に統合
    • 例えばDriver Diagが「High」で危険を示すなら、そのままロジックICへ入力 → リレーOFF
    • “多数のOR/AND線”をハードICでまとめ、配線やIC上で一括完結させられる。

案2のデメリット

  1. IC自体のコスト:たとえ数十円でもユーザが「追加費用を避けたい」とするなら、その分不利。
  2. 基板改修:ロジックICを置くスペースや配線追加が必要。
  3. IC故障リスク:新たな部品を1個加えることがシングルポイントになる可能性もある(IC自体が壊れるとリレー動作不能)。

案4の特徴

  • サブマイコンがメインマイコン故障を監視し、もしメインマイコンが固まればサブマイコンが直接リレー制御線を持っており、リレーをOFFできる。
  • 検出の主体:メインマイコン以外の異常(Driver Diagやセンサも)をサブマイコンが見るかどうかは設計次第だが、最低限メインマイコン故障はサブマイコンが独立判定。

案4のメリット

  1. 追加ハードが不要
    • サブマイコンは既にあるため、あとはソフト+数本の配線(既存ピン割り当て変更程度)で構成できる。
    • 物理的なIC追加コストはゼロに近い。
  2. メインマイコンが壊れてもサブマイコン単独でリレーを落とせる
    • シングルポイント故障を回避。

案4のデメリット

  1. サブマイコンが「メインマイコン故障」しか見ていないと、APS/TPS故障など他異常はメインマイコン頼み
    • ただしユーザの運用次第でサブマイコンが他センサも見られるよう拡張可能。

案2 vs 案4 の比較

  1. 追加コスト

    • 案2:ロジックICを数十円~+基板アートワーク → ユーザが「費用避けたい」なら不利。
    • 案4:基本的にサブマイコン追加コスト無し(既存)、ピン配線程度 → コスト的により有利。
  2. ソフト変更

    • 案2:ハードで完結させられるので、各マイコン側ソフトの大きな書き換え不要 → メイン/サブMCUから“故障信号”だけ出力させればロジックICが一括処理。
    • 案4:サブマイコンのコードに「メインマイコンウォッチ」や「リレードライバ制御」などロジックを実装 → ソフト改修量が増える可能性あり。
  3. Flexibility

    • 案2:ロジックICのOR回路にDriver Diag他のラインも簡単に追加しやすい。
    • 案4:サブマイコンが追加するなら、そちらのソフトコードを拡張。
    • いずれでも目的は“どれか故障ならリレーOFF”。
  4. 故障点増

    • 案2:ICが壊れるとリレーOFFが効かなくなるリスク → 新たなSPoF?
    • 案4:ハード追加が不要なので新しいSPoF要素は増えにくい。
  5. ユーザがサブマイコンをすでに持つ

    • なら案4 は「ハード追加ゼロ」で済む → 全体コストを最小化。
    • 案2 は数十円と言えど追加部品がいる → 「コストを掛けたくない」要望とは合わない。

結論

  • 案2 (ロジックIC追加) は「ソフト修正を最小化し、複数故障検出線を一括処理したい」場合に有利。ただしICの追加コストIC故障リスクがある。
  • 案4 (サブマイコンが直接リレーを制御) はハード追加が不要でコスト0に近く、すでにあるサブマイコンで完結。ソフト改変は必要だが、ユーザが「追加費用を極力避けたい」ならこちらが好適。

    したがって、案2案4 に対する大きな優位性はなく、案4 の方がコストを抑えやすい。
    さらにサブマイコンがAPS/TPSも直接監視できるなら案1(サブマイコンが幅広く検出&制御) と実質同様となり、費用ゼロでシングルポイント故障を解消可能です。

ゆえに、コストを極力掛けずにMain MCU依存を除去したいなら、案4 (あるいは案1) が望ましく、案2 のハード追加メリットはほぼないと言えます。

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


ユーザは直感的に案2のメリットが無いと見抜き、ChatGPTに詳細を検討させましたが、その結果、案2はメリットがほぼ無いと言う同意できる結論を出しました。隠れたメリットが有るかもしれないので、このように議論を尽くすことは重要です。

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


左矢前のブログ 次のブログ右矢

posted by sakurai on February 14, 2025 #949

案3はユーザ要望からNGなので除きます。次に案1と案4が同じように見えますが、どこが違うのでしょうか?いずれもサブマイコンがメインマイコンを経由してリレーを制御していたものをメインマイコンを経由せずに制御する案のように見えます。案2もはっきりアーキテクチャが分かりません。メインマイコン監視はロジックICがやるのかそれともサブマイコンか?リレー遮断はロジックICがやるのかそれともサブマイコンか?提案するときは誰が検出して誰がリレー制御するのかをはっきりさせてください。

ChatGPT
以下では、前回の提案1/2/4 が「メインマイコンに依存せずリレーを制御する」点で似ているものの、それぞれ誰が異常を検出し、誰がリレーを実際にオフ(駆動)するかの違いを整理してまとめます。
ユーザ要望に沿い、案3(メインマイコン部品の高信頼化等)はNGとして除外しています。


案1: 「サブマイコンが検出し、サブマイコンが直接リレーを制御」

  • 誰が異常検出?
    • サブマイコン自身が各種異常(例:Driver Diag, APS等)を監視
    • メインマイコンは不要または並列
  • 誰がリレーをOFF?
    • サブマイコンがリレードライバへ直接指示を出してリレーを切る
  • アーキテクチャの例
    • サブマイコンがハード的にリレードライバへ接続し、異常時に“サブマイコン→リレードライバ→リレーOFF”
    • メインマイコン故障時でもサブマイコン単独で電源遮断可能

ポイント

  • サブマイコン自身が異常を見つけ、直接リレーを落とすのでメインマイコンは介在しない
  • メインマイコンが死んでいてもサブマイコンが検出~制御できる

案4: 「サブマイコンがメインマイコンの死活を監視→故障時に直でリレーをOFFする」

  • 誰が異常検出?
    • メインマイコンの故障(“固まって応答しない”など)をサブマイコンが監視(ウォッチドッグ的)
    • さらにDriver Diag等もサブマイコンが見るか、あるいはメインマイコンが見るかは設計次第
  • 誰がリレーをOFF?
    • サブマイコンがメインマイコンを経由せずリレードライバへ出力し、リレーを切る
  • アーキテクチャの例
    • “メインマイコンが正常なら通常制御。サブマイコンは監視役”
    • メインマイコンが固まれば、サブマイコンがウォッチドッグタイマ等で故障検知→直接リレーにオフ指令

ポイント

  • サブマイコンの検出対象が「メインマイコン故障」中心(もちろん他センサをサブマイコンが見る構成も可)
  • “メインマイコンが応答しない”という状態をトリガにサブマイコンが介入→リレーOFF

案1との違い

  • 案1: サブマイコンが幅広く「APS/TPS等の異常」自体も検出
  • 案4: サブマイコンのメイン検出対象は「メインマイコン死活」。他センサ異常はまだメインマイコンが見る場合が多い

案2: 「ロジックICを追加して“メイン or サブ”のどちらかが故障検出すればリレーをOFFできる回路」

  • 誰が異常検出?
    • (a) メインマイコンは従来の検出をする
    • (b) サブマイコン or Driver Diag が独立で検出
    • (c) どちらが検出した信号もハードロジックIC(例: ワイヤードOR/ANDゲート)を通じてリレードライバへ
  • 誰がリレーをOFF?
    • ロジックICがメイン/サブ いずれかの出力をまとめ、最終的にはリレードライバを駆動
  • アーキテクチャの例
    • 小型ゲートICやトランジスタ回路に「Main MCU fault検出線 or Sub MCU fault検出線」を入力
    • IC出力が“Low”になればリレードライバを強制オフ
    • いわばハードウェア冗長の簡易形

ポイント

  • 異常検出の主体: “メイン or サブ or Diag”
  • リレー駆動自体はIC回路が集約→「どの出力線でも異常信号が来ればリレーOFF」
  • コスト: ロジックIC(数十円~)+基板配線
  • 純粋に“サブマイコンがリレーを直に駆動”ではなく、“ハード回路で複数信号を論理合成→リレードライバへ”

整理: 誰が検出? 誰がリレーを駆動?

  • 案1

    • 検出: サブマイコン側でセンサ・故障入力を直接見る
    • 駆動: サブマイコン→リレードライバ→リレー
    • メインマイコンをバイパスする
  • 案4

    • 検出: サブマイコンは主に「メインマイコン死活」(+αでDriver Diag等も可)
    • 駆動: サブマイコン→リレードライバ→リレー
    • (案1とは違い)他のAPS/TPS等の検出をメインマイコンが担当する可能性が大
  • 案2

    • 検出: メインマイコン/サブマイコン/Driver Diag など複数
    • 駆動: ハードロジックICが「複数異常信号」をまとめ、リレードライバを強制OFF
    • メイン/サブ両方の出力を集約し、どちらかが“故障”判定したらリレーOFFする

結論

  • 案1: サブマイコンが幅広く(APS/TPS等)検出し→直接リレー制御。
  • 案4: サブマイコンは主に“メインマイコン故障”を検出→直接リレー制御(他センサはメインマイコンが見る)。
  • 案2: 異常検出は(メイン+サブ+Diag等)複数パターンだが、リレーOFFはロジックICが最終ゲートとなって実行。

どの案も共通点は「最終的にメインマイコン以外でもリレーを落とせる」ですが、誰がセンサを見て、誰が故障検出し、誰がリレーに出力するのかが案ごとに異なります。

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


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


左矢前のブログ 次のブログ右矢


ページ: