🧟 はじめに：猛獣を飼う覚悟
Day 3では、システムの中で「Fault（ウイルス）」が「Failure（ゾンビ化）」に至るプロセスを学びました。
今日は、そのゾンビ化を食い止めるための 「システムの構造（アーキテクチャ）」 のお話をします。
私たちが作っている自動車というシステムは、動物園の檻のようなものを用意すれば安全という訳ではありません。
「虎（強力な機能）」を飼いながら、同時にその虎が暴れたら即座に制圧する「要塞」 でなければなりません。
現場のゾンビたちは、よくこう言います。
🧟♂️「機能と監視なんて、一緒のメモリに入れておけばいいよ。安上がりだから」
これは機能安全における 「全滅フラグ」 です。
今日は、なぜ「一緒にしてはいけない」のか。その恐怖のシナリオ 「カスケード故障」 について解説します。
1. 基本構造：虎と飼育員
安全なシステムを作るための基本ユニットは、以下の2つに分かれます。
① 虎（本来機能 / Intended Function）
- 役割: 車を走らせる、曲げる、止める。強大なエネルギー（トルク、電圧）を持っている
- 特徴: 普段はショーなどで役に立ちますが、機嫌が悪くなると人間を襲う凶器に変わる
- サバイバル視点: こいつを野放しにはできない
② 飼育員（安全機構 / Safety Mechanism）
- 役割: 檻の外から常に虎を監視する係
- 装備: 虎の目が血走っていないか（機嫌が悪くないか）を見る「飼育員としての知恵と経験」と、暴れたら眠らせる「麻酔銃（安全策）」を持っています。
- サバイバル視点: 教育された飼育員こそが、動物園を安全にする命綱になる
⚠️ 絶対ルール：部屋を分けましょう
ここで最も重要なルールがあります。
「虎と飼育員を、同じ部屋に入れてはいけません」
もし同じ部屋にいて、虎が暴れ出したらどうなるでしょうか？ 飼育員が隣にいたら、最初に噛まれて怪我して、虎を止められなくなります。
だから、機能安全（ISO 26262）では、機能（虎）と監視（飼育員）の分離・独立を徹底的に求めます。
2. 悪夢のシナリオ：「カスケード故障」
なぜそこまで「分けろ」とうるさいのでしょうか？
それは、「共倒れ（Dependent Failure）」 が一番怖いからです。
想像してみてください。動物園でこんなことが起きたらどうなりますか？
🎬 シナリオ：灼熱の動物園
虎と飼育員は、同じ建物の中にいます。 ある真夏の日、建物の エアコン（共通リソース） が故障し、室温が40度を超えました。
虎（機能） は、暑さで錯乱し、暴れ出しました（Fault → Failure）。
本来なら飼育員が止めるはずですが、飼育員（監視）も熱中症で気絶していました。
結果： 誰も暴走を止められません。 これが**「共通原因故障（Common Cause Failure）」**です。結果： 誰も暴走を止められません。もしかしたら、錯乱した虎が檻から出て、動物園が危険な場所になるかもしれません。
これが 「カスケード故障（従属故障）」 です。
自動車システムで言うと、以下のような状況を指します。
- 共通電源の喪失: 5V電源が壊れて過電圧になり、制御マイコン（虎）と監視マイコン（飼育員）が同時に焼けてしまった。
- 共通メモリの破壊: 制御ソフトが暴走して、監視ソフトが使うメモリ領域を上書きして破壊してしまった。
「原因は一つなのに、機能と安全装置が同時に死ぬ」。
これがサバイバルにおいて最も避けなければならない 「全滅ルート」 なのです。
3. シェルター構築術：独立性（Independence）
この悪夢を防ぐために、私たちアーキテクトは 「壁」 を作ります。
これを専門用語で 「独立性（Independence）」 や 「相互干渉の回避（FFI: Freedom from Interference）」 と呼びます。
① 物理的な壁（Hardware Partitioning）
- 動物園: 虎と飼育員の部屋を分け、電源も別系統にします。
-
実装:
- 制御用マイコンと監視用マイコンを分ける（2チップ構成）。
- 電源IC（PMIC）を分けて、片方が死んでも監視側は生き残るようにする。
② 論理的な壁（Software Partitioning）
- 動物園: 同じ建物にいますが、頑丈なガラスで仕切ります。
-
実装:
- メモリ保護ユニット（MPU） を使い、虎（機能）が飼育員（SM）のメモリ領域に書き込めないようにブロックする。
- タスク監視（Program Flow Monitoring） で、虎が飼育員の時間を奪わない（処理落ちさせない）ようにする。
4. プロが使う「3層の守り」
この「虎と飼育員」の構成を、さらに洗練させた業界標準の型があります。
それがドイツの自動車メーカーたちが決めた 「EGAS（イーガス）コンセプト」 です。
- Level 1 (虎): 本来の機能
- Level 2 (飼育員): 機能が間違っていないか計算で見張る監視
- Level 3 (医者/警察): 飼育員（マイコン自体）が健康か動物園が安全かを見張る、独立した監視装置（WdgMなど）
この「3段構え」については、次回 Day 5 で詳しく解説します。
ここでは 「とにかく役割を分けて、共倒れを防ぐ」 という思想だけ持ち帰ってください。
【現場の闇】安全機構があるから、問題ないよね？・・・
🧟♂️ ゾンビの囁き： 「安全機構あるから、ヨシッ！」
「機能安全対応しているから、本来機能はちょっとテストできていないけどリリースしてもいいよね！」
「今時間ないから、機能安全側で検知できるからOKだよ！」
ゾンビ化したエンジニアは、安全機構（Safety Mechanism）を 「手抜きの免罪符」 だと勘違いしている可能性があります。安全機構の保険があるから、本来機能側は本気で対応しなくてもいい、時間や品質をトレードオフにかけがちになります。
🧑🔧 サバイバーの反論： 本来機能がポンコツだと、安全機構も大変だ・・・
「安全機構は保護装置ではあるが、本来機能が意図通りに動作できないことまでは保証できない」
「本来機能がまともに動かない（制御値がノイジーだったり）ことで、安全機構が何度も介入すると使い勝手が悪くなってしまう・・・、本来機能もしっかり設計して、テストする必要がある」
真のサバイバーは、本来機能だとか、安全機構だとか分けて考えていないです。システム的に検討した時に、安全側に倒すべきだと思ったなら、EGASコンセプトの階層を特別意識しないです。Levelで、作りの信頼性を下げてしまうと、システム全体で信頼性を下げることになってしまうからです。
📝 今日のサバイバル・ルール（まとめ）
- 基本構造: システムは「虎（機能）」と「飼育員（SM）」のペアで作りましょう。
- カスケード故障: 「同じ弁当（共通リソース）」を食べると、いざという時に共倒れします。
- 独立性（Independence）: 電源、メモリ、時間を分離して「壁」を作りましょう。
次回予告
檻の構造は分かりました。ですが、虎が暴れ出した時、すぐに「麻酔銃で眠らせること（システム停止）」をしていいのでしょうか？
高速道路で急にエンジンが止まったら、逆に追突されてしまいますよね。
次回Day 5は、「腕を切り落としてでも生き残る技術」。
EGASコンセプトの実装と、プロの撤退戦術である 「縮退運転（Degradation）」 について伝授します。