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

前のブログ 次のブログ

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

前のブログ 次のブログ