Posts Tagged with "failure rate"

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

VSG は到達後の復帰は規格上仮定しないので、それは吸収状態です。したがって VSG への到達は高々一度しか起きません。

VSG 到達時刻を $$ \tau:=\inf\{t\ge0:\eta_i\in\mathcal{P}\} $$ と定義します。

$N(T)$を区間 $[0,T]$におけるVSG 到達回数として、

$$ N(T):=\mathbf 1_{{\tau\le T}} \tag{1058.0} $$ と定義すれば、 $$ N(T)\in\{0, 1\} $$

前頁の式 (1057.7) より、微小時間区間におけるダウン確率は $$ \Pr\{\eta_t\in\mathcal{M},\ \eta_{t+dt}\in\mathcal{P}\} =h(t)\,dt+o(dt)\tag{1058.1} $$ で、ダウン回数を$dN(t)$と書けば、 $$ \begin{eqnarray} dN(t)= \begin{cases} 1 & (ダウンが起きるとき) \ 0 & (それ以外) \end{cases} \end{eqnarray} $$ であるので、期待ダウン回数は $$ E[dN(t)]=\Pr\{\eta_t\in\mathcal{M},\ \eta_{t+dt}\in\mathcal{P}\} $$ これに(1058.1)を適用して両辺を積分すれば、 $$ E[N(t)]=\int_0^T h(t)dt\tag{1058.2} $$ となります。$N(T)\in\{0,1\}$であるので、 $$ E[N(T)]=\Pr\{N(T)=1\}=\Pr\{\tau\le T\}\tag{1058.2} $$

したがって $$ \mathrm{PoF}(T)=\Pr\{\tau\le T\}=\int_0^T h(t)\,dt\tag{1058.4} $$ であり、

$$ \mathrm{PMHF}=\frac{\mathrm{PoF}(T_\text{lifetime})}{T_\text{lifetime}}=\frac{1}{T_\text{lifetime}} \int_0^{T_\text{lifetime}}h(t)\,dt\tag{1058.5} $$

となります。

この記事の改訂版です。


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

posted by sakurai on February 13, 2026 #1057

確率空間 $(\Omega,\mathcal F,\Pr)$ 上で定義された確率過程 $\{\eta_t\}_{t\ge0}$ を考えます。 米国ロチェスター大学の資料(そのキャッシュ)によれば、 $\eta_t$ が状態空間 $\mathcal E=\{0,1,2,\ldots\}$ を値に取るとき、 任意の $t\ge0$, $s>0$, および任意の状態 $i,j\in\mathcal E$ に対して

$$\Pr\{\eta_{t+s}\in j\mid\eta_t\in i,\ \eta_u=x_u,\ u<t\} =\Pr\{\eta_{t+s}\in j\mid\eta_t\in i\}\tag{1057.1}$$

が成り立つ場合、${\eta_t}$ は連続時間マルコフ連鎖(CTMC)です。これは遷移する確率が、過去の時刻$u$での状態に依存せず、現在時刻$t$での状態にのみ依存することを表します。

斉時CTMCである$\eta_t$において、ステート$i$から$j$への微小時間$dt$における状態遷移確率 (Instantanous Transition Probability Function)$P_{ij}$は次式で与えられます。

$$ P_{ij}(t):=\Pr\{\eta_{t+dt}\in\mathcal{j}\mid\eta_{t}\in\mathcal{i}\} =q_{ij}dt+o(dt)\tag{1057.2} $$ ここで$q_{ij}$はCTMC の生成行列の成分として定義される遷移率(Transition Rate)です。

次に、$\mathcal{M}$を稼働状態の集合、$\mathcal{P}$を不稼働状態の集合とします。稼働状態$\mathcal{M}$から不稼働状態$\mathcal{P}$への遷移をダウンと定義し、その微小時間$dt$における条件付き確率を考えると(1057.2)は次の形で表されます。

$$P_\mathcal{MP}(t) =\Pr\{\eta_{t+dt}\in\mathcal{P}\mid\eta_{t}\in\mathcal{M}\} =q_\mathcal{MP}dt+o(dt)\tag{1057.3}$$

ここで、ダウンに対応するVesely故障率$\lambda_v(t)$を次式で定義します。 ​ $$ \lambda_v(t):=\lim_{dt\to0}\frac{\Pr\{\eta_{t+dt}\in\mathcal{P}\mid \eta_t\in\mathcal{M}\}}{dt}\tag{1057.4} $$

CTMC を仮定する場合、式 (1057.3) より$\lambda_v(t)$は生成行列の成分$q_\mathcal{MP}$と一致します。

このVesely 故障率$\lambda_v(t)$を用いると、微小時間$dt$においてダウンする同時遷移確率は、

$$\Pr\{\eta_t\in\mathcal{M},\eta_{t+dt}\in\mathcal{P}\}\\ =\Pr\{\eta_t\in\mathcal{M}\}\Pr\{\eta_{t+dt}\in\mathcal{P}\mid\eta_t\in\mathcal{M}\}\\ =\Pr\{\eta_t\in\mathcal{M}\}\lambda_v(t)dt+o(dt)\tag{1057.5}$$

で与えられます。このとき、ダウンの無条件の瞬間遷移強度$h(t)$を $$ h(t):=\Pr\{\eta_t\in\mathcal{M}\}\,\lambda_v(t) \tag{1057.6} $$ と定義すれば、 $$ \Pr\{\eta_t\in\mathcal{M},\ \eta_{t+dt}\in\mathcal{P}\} = h(t)\,dt +o(dt) \tag{1057.7} $$ となります。

以後、この $h(t)$を用いて VSG 発生確率を評価します。

この記事の改訂版です。


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

posted by sakurai on February 12, 2026 #1056

upやdownを数式で書いてみます。

非修理系

ランダムプロセス$\eta_s$において、確率変数$X$を無故障稼働時間とします。$\mathcal{M}$を稼働状態のサブセットとし、$\mathcal{P}$を不稼働状態のサブセットとすれば、$X=\inf\lbrace s:\eta_{s}\in\mathcal{P}\rbrace$と示すことができます。

non-repairable elementの瞬間故障率$\lambda(t)$の定義式は、

$$ \lambda(t)\stackrel{\mathrm{def}}{=}\lim_{dt\downarrow 0}\frac{\Pr\lbrace X\le t+dt\ |\ t\lt X\rbrace}{dt}\tag{1056.1} $$

であり、(1056.1)を一次展開すれば、

$$ \Pr\lbrace X\le t+dt\ |\ t\lt X\rbrace=\lambda(t)dt+o(dt)\tag{1056.2} $$

となります。ここで(1056.2)に条件付き確率の公式を用いれば、

$$ \Pr\lbrace X\le t+dt\ |\ t\lt X\rbrace=\frac{\Pr\lbrace t\lt X\le t+dt\rbrace}{\Pr\lbrace t\lt X\rbrace}=\frac{f(t)}{R(t)}dt+o(dt)\tag{1056.3} $$

であることから、(1056.2)、(1056.3)の右辺の比較により、

$$ \lambda(t)=\frac{f(t)}{R(t)}\tag{1056.4} $$

修理系

repairable elementのVesely故障率$\lambda_V(t)$は、Christiane Cocozza-Thivent他の論文"The Failure Rate in Reliability. Numerical Treatment"の(1.2)式によれば、

$$\lambda_V(t)\stackrel{\mathrm{def}}{=}\lim_{dt\downarrow 0}\frac{\Pr\{\eta_{t+dt}\in\mathcal{P}\mid \eta_t\in\mathcal{M}\}}{dt} \tag{1056.5}$$

であり、(1056.5)を一次展開すれば、 $$ \Pr\{\eta_{t+dt}\in\mathcal{P}\mid\eta_t\in\mathcal{M}\}=\lambda_V(t)dt+o(dt)\tag{1056.6} $$

となります。次に無条件瞬間ダウン強度$h(t)$の定義式は、

$$ h(t)\stackrel{\mathrm{def}}{=} \lim_{dt\downarrow 0} \frac{\Pr\{\eta_t\in\mathcal{M},\ \eta_{t+dt}\in\mathcal{P}\}}{dt} \tag{1056.7} $$

であり、(1056.7)を一次展開すれば、 $$ \Pr\{\eta_t\in\mathcal{M},\ \eta_{t+dt}\in\mathcal{P}\}=h(t)dt+o(dt)\tag{1056.8} $$

となります。また、point availability$A(t)$は、

$$A(t)\stackrel{\mathrm{def}}{=}\Pr\{\eta_t\in\mathcal{M}\}\tag{1056.9}$$

で表されます。ここで(1056.6)に条件付き確率の公式を用いれば、(1056.8)及び(1056.9)より、

$$ \Pr\{\eta_{t+dt}\in\mathcal{P}\mid \eta_t\in\mathcal{M}\} =\frac{\Pr\{\eta_t\in\mathcal{M},\ \eta_{t+dt}\in\mathcal{P}\}}{\Pr\{\eta_t\in\mathcal{M}\}} =\frac{h(t)}{A(t)}dt+o(dt) \tag{1056.10} $$

であることから、(1056.6)、(1056.10)の右辺の比較により、

$$ \lambda_V(t)=\frac{h(t)}{A(t)}\tag{1056.11} $$

この記事の改訂版です。


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

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月頃に開示予定です。


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

posted by sakurai on February 13, 2025 #948

DCの相補関係を理解していないようなので、ヒントを与えることにします。

実はMCSを良く見ると、COV_90=DC、COV_REM=1-DCで加えると1になります。従って、1位と2位を加えると、MAIN_MCUの故障確率となります。ということはDCの低減対策は無意味です。さらに変更案は可能な限り費用が掛からないものとします。ユーザからのフィードバックを元に、改善案を提案してください。

ChatGPT
MCSを分析すると、DC=90%(COV_90)と1−DC=10%(COV_REM)のいずれも最終的にMain MCU故障と組み合わさり、合計でMain MCUの故障確率に等しい形になっています。
すなわち、カバレッジを上げても下げても、結局Main MCU一台の故障が全体を支配しているため、DCの改善策((1-DC)を低減する等)は効果がほぼ無いと判断できます。


改善案の考え方: 低コストでMain MCUのシングルポイント故障を解消する

1. Sub MCUを直接リレーをドライブできる構造へ(配線変更)

  • 提案理由: 現在は“Main MCUが必須”になっているため、その故障でSM全体が停止してしまう。
  • 対策: Sub MCUが異常を検出した場合、Main MCUを経由せずリレーをドライブできるよう、配線やゲートを追加する。
  • 費用: 基板上の配線変更やソフトロジック追加程度であれば、部品追加が最小限で済む。
  • 効果: Main MCUが壊れても、Sub MCU単独でリレーをOFFしてモータを止められる → 1台のMCU故障に対する依存度が低減し、MCSにおける「MAIN_MCU」支配が解消される。

2. Hardwareロジックや小型ゲートを使った“バックアップ回路”

  • 提案理由: 「Sub MCUがMain MCUを監視」していても、結局リレー制御がMain MCU頼みなら効果が薄い。
  • 対策: Sub MCUに加え、簡易ロジックIC(例: オープンコレクタの有線OR回路など)を導入し、「Main MCU or Sub MCUのどちらか生存していればリレードライバをオフにできる」回路へ。
  • 費用: 小型ロジックIC(数十円程度)+基板アートワーク修正だけで済む可能性が高い。
  • 効果: 冗長MCUを追加購入するような大規模コスト無しに、“Main MCUがNGでもSub MCUがオフ可能”を実現。

3. Main MCU自体の故障確率低減は優先度低

  • ユーザ所望: コストを抑えたい → 高信頼部品に切り替えは高価。
  • MCSから: Coverageをいくら改善してもMain MCU故障単独が支配 → カバレッジ改善での効果小。
  • 結論: 部品自体を変更するよりも、回路・配線面でシングルポイントをなくす方が得策。

4. リレー/リレードライバに対するサブマイコンウォッチドッグ

  • 提案理由: ハードウェア的な“死活監視”をSub MCUが行い、Main MCU故障でサブマイコンが自動的にリレーを遮断。
  • 費用: Sub MCUファーム更新+線1本追加程度なら大規模投資は不要。
  • 効果: “Main MCUが固まったらリレーOFF”というシンプルな安全策を作れる。

まとめ

Main MCU故障がシステム全体をダウンさせる」のが最大課題で、DC改善は効果が無いというMCS分析結果です。
低コスト案としては、

  1. Sub MCUが直接リレーを遮断できるようにする(配線や小さなゲート追加)。
  2. 有線OR回路リレー駆動の追加トランジスタ等を実装し、Main MCU以外でもリレー制御線を落とせるバックアップ機構を付ける。

これらが最も費用対効果の高い対策となります。大掛かりな冗長MCU追加やDC向上策を行わず、シングルポイントのMain MCUに頼らない手段を確保するのがベストです。

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


以上がChatGPTの回答ですが、まとめの1案を実施するなら、2案は余分なコストがかかるため不要な案と言えます。しかしながら、このようにChatGPTは最適案だけではなく様々な案を出してくれるため、視野が広がる効果も有るかもしれません。

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


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

posted by sakurai on February 12, 2025 #947

人間にとって、MCSを見ればメインマイコンの安全機構が無効であることが即座に分かり、アーキテクチャ上の問題を発見することはそれほど難しくありません。一方でAIはどうでしょうか?そこでChatGPTにMCSのTop 1, 2を見せて改善提案をしてもらいました。

添付の図が以前のEGASアーキテクチャでしたが、4つの検出ルートが全てメインマイコン、リレードライバに接続されています。一方でメインマイコンはIFのパスにも入っています。従って、MCSを取得すると、

1  1.80E-03 89.04 179.8
  9.00E-01  COV_90  SM coverage (DC=90%)
  2.00E-03  MAIN_MCU  Main MCU (200FIT)
2  2.00E-04 9.89 20.0
  1.00E-01  COV_REM  SM leftover (1-DC=10%)
  2.00E-03  MAIN_MCU  Main MCU (200FIT)

となりました。この見方は、
積項の大きい順の順位、積項確率、全体の割合、PMHF
  単項確率、項目、説明
 :
です。このMCSを分析してアーキテクチャの改善を提案してください。

ChatGPT
下記のMCS(Minimal Cut Set)を見ると、上位2つの積項がいずれも「Main MCUの故障×SM側の定数(Coverage 90%またはLeftover 10%)」によって支配されている点がわかります。具体的には、

  1. $1.80\times10^{-3}$ (約89%)
    • カバレッジ 90% ($0.9$) と Main MCU ($2.0\times10^{-3}$) の積
  2. $2.00\times10^{-4}$ (約10%)
    • レフトオーバー 10% ($0.1$) と Main MCU ($2.0\times10^{-3}$) の積

両方ともMain MCUが故障するとSM(安全機能)を失ってしまう構造、かつ全体の約99%を占めています。
この結果から読み取れるのは、

  • Main MCU がシングルポイント故障になっている
    • どの検出経路を通っても最終的に Main MCU が要(かなめ)となっており、そこで一度でも故障するとSMが機能しない。
  • SM本来のカバレッジ(0.9)やレフトオーバー(0.1)の影響以前に、Main MCU故障が最優先で TOP イベントを引き起こす状態です。

改善提案の方向性

  1. Main MCU の冗長化

    • 例えば、SMを作動させるための経路で「Main MCU」を1つだけに頼らず、複数のMCUを並列化(ハード冗長)するなり、あるいは別の独立したマイクロコントローラ(Sub MCU)を真に並列ルートとして挿入する。
    • これにより「Main MCUが故障しても、もう1つの健康なコントローラがリレーを遮断できる」構造にすれば、このシングルポイント故障を除去できる。
  2. SM経路から Main MCU を外す/縮小する

    • 安全機能(モータ電源遮断)に必須なのがMain MCUだけになっている点を再検討し、「サブマイコン(Sub MCU)が単独でリレードライバを制御できる」といった構造を更に強化する。
    • 現状、サブマイコンがDriver Diagを監視してはいるが、最終的にリレーを駆動する際にMain MCUが絶対必須になっていないかを再確認する。
  3. レフトオーバー(1-DC=10%)の低減

    • Main MCUのFIT値を下げる(設計・選定を高信頼品にする)と同時に、SMの診断カバレッジを上げて(1-DCを5%以下などにできれば)、残余故障による寄与を減らす。
    • MCSを見ると2番目のカットセットにおいても(COV_REM=0.1) と Main MCU故障が組み合わさっているので、低カバレッジによるSM失敗を抑えるメリットがある。
  4. サブマイコン(150FIT)をもっと活用する

    • 図上ではサブマイコンがDriver Diagと直接配線されているが、実際にはAPS/TPSなどもサブマイコン側で検出できればMain MCU故障時のバックアップになる。
    • そうすれば、検出フェーズの並列度が向上して「Main MCUが壊れてもサブマイコンがAPS/TPS異常を捉えてリレーを遮断する」ルートが確立し、Main MCU依存を下げられる。

結論

MCS結果からはMain MCUがどの経路でもシングルポイントになっているため、ほぼ全ての失敗モードが「Main MCU故障 ×(Coverage or leftover)」で占められています。
最も効果的な対策は、
(1) Main MCUを冗長化または
(2) SM制御における依存度を下げる(Sub MCUを独立経路にする)ことで、Main MCU一台の故障がSM全体を止めないようにする構造改善です。さらに
(3) レフトオーバー10%の低減も併せて行えば、PMHFを大幅に削減可能と考えられます。

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


回答文の表現は微妙で、DCと1-DCの相補関係が分かっているのか分かっていないのかが微妙です。

Main MCU がシングルポイント故障になっている

これが狭義のSPFであればまさにそのとおりです。狭義のSPFとはSMを持たないIFのフォールトであり、DCと1-DCを加えて1となるということは、SMが全くカバーしていないことを意味します。

ちなみに、広義のSPFは狭義のSPFとRFを会わせたものを指します

SM本来のカバレッジ(0.9)やレフトオーバー(0.1)の影響以前に、Main MCU故障が最優先で TOP イベントを引き起こす状態

ところが、影響以前もなにも、DCと1-DCなので加えれば影響はありません。影響があることを前提としているようなので、理解が間違っているようにも思われます。

改善提案の方向性

案1. Main MCU の冗長化

Main MCUが故障確率の1位なので当然ともいえる提案ですが、コストがかかるのが難点です。

案2. SM経路から Main MCU を外す/縮小する

これが人間の考えた方式と一致する案であり、正解といえます。

案3. レフトオーバー(1-DC=10%)の低減

この提案は誤りです。COV_90とCOV_REMは相補関係にあり、1-DCであるCOV_REMが減少すればDCであるCOV_90が増加します。さらに仮に独立だとしてもCOV_90のほうが9倍も大きいので減少させるならtop1のほうでしょう。

案4. サブマイコン(150FIT)をもっと活用する

サブマイコンよりもメインマイコンの故障確率が支配的なので、的を射た提案とは言えません。

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


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

posted by sakurai on February 11, 2025 #946

前稿の続きです。このFTについて、Solve⇒Cut setを実施し、MCSを図946.1のように取得しました。

図%%.1
図946.1 改善アーキテクチャのFT

前のアーキテクチャから比べてちょうどTop 1が抜けた形となっています。これにより最も大きな残余故障はメインマイコンであり、サブマイコンによる故障検出だけでなく、ECCやクロックモニタ等の別の故障検出手段を追加して全体のPMHFを下げることが可能です。

このようにMCSはどこが弱いかが一目瞭然であるため、弱い部分から手当することにより効率的なアーキテクチャの改善やSMの追加が可能です。

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


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

posted by sakurai on February 6, 2025 #943

ChatGPTに前稿のRBDを読ませたところ、次のMARDを取得しました。 TEST.BEDTEST.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月頃に開示予定です。


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


ページ: