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

前のブログ 次のブログ

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

前のブログ 次のブログ

人間にとって、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月頃に開示予定です。

前のブログ 次のブログ

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

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

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

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

前のブログ 次のブログ

弊社コンテンツの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月頃に開示予定です。

前のブログ 次のブログ