第三回：アーキテクチャ設計、構想設計（葛城ミサトの場合）
2017年10月25日「マウナケア観測所で捕捉。第3監視衛星が光学で捉えました。最大望遠でモニタに出します。」
青葉シゲルが正面のプロジェクションを衛星画像に切り替えた。
「光を歪めるほどのA.T.フィールドとは、恐れ入るわね。」
続けてデータが読み上げられる。
「MAGIの軌道計算。ZERV本部への命中確率、99.9999％。10-6です。」
「直撃時の爆砕推定規模は、第3新東京市は蒸発、セントラルドグマも丸裸の規模です。」
葛城ミサトがリスクの定義を思い出す。
「危害のひどさと、起こりやすさ、これがリスクの定義。最高レベルね。
当然許容できるリスクレベルではないわ。特別非常事態宣言D-17を発令！半径120キロ圏内の全市民は退避を開始させて。」
衛星軌道上の使徒を狙撃するわけにもいかず、対策は限られていた。
「飛来する使徒を、エヴァのA.T.フィールドで受け止めるしかないわ。」
ミサトの提案する作戦に対して、赤木リツコがMAGIの計算結果を提示して否定した。
「MAGIの検証でも失敗確率は99%。たとえ成功してもエヴァ3体を損失。技術部として到底受け入れられません。防御システムや作戦にもリスクアセスメントを適用するルールになったでしょう！」
「なにも対策をしなければ、失敗確率は高いかもしれない。奇跡を起こすのよ。人の意思で。」
機能安全の導入をゼーレに指示されたZERVのメンバーは、少しずつ勉強を始めていた。いわゆる最初の災害リスクの評価からのスタートである。その特定のリスクを低減するための対策を、Safety Function（安全機能）と彼女たちは呼んでいる。その安全機能を実施するための仕組みやシステムを安全関連システムと呼んでいる。安全関連システムが失敗せずに安全機能を実現すれば、リスクは最小限に抑えられる。
「安全機能やら機能安全やら、似た用語で面倒くさいわね。」
とミサトは毒づいた。
「今回は、エヴァ本体を対象とするのではなくて、『作戦』を安全関連システムとして考えればいいのよ。その場合、安全関連システムの内部にトラブルが発生しても、危険な状態にならないためのさらなる仕掛けをSafety MechanismとかSafety Measureと呼んでいるわ。コンピュータシステムの設計で一番多用されるのが、電子部品に対する自己診断。ランダムに発生するトラブルに対処するための方策（機能安全 連載 第５回：構想設計とSafety Measure）。けれど今回一番大切なのは・・・『作戦のアーキテクチャ』よっ！」
落下のエネルギーに対抗するには、3体のA.T.フィールドが必要。しかし、今回最も不確定なのは落下地点の座標である。軌道をずらすことができる使徒のため、エヴァ3体が予想地点に集結していては、使徒に容易にかわされてしまう。またMAGIの予想が現実と異なってしまった場合、同じく作戦の失敗確率は極めて大きくなる。
いざというときに失敗するかもしれない確率。機能安全ではPFD（Probability of a dangerous Failure on Demand of the safety function）と呼んでいたわ（機能安全 連載 第3回：設計指標が示す構想設計の重要性）。
多重化した場合の考え方も、確かIEC-61508にあった。単純な多重化は共通要因故障の存在のため、それほどPFDが改善されない。共通要因故障割合（βファクタ）を小さくすることが、多重化の際の重要なポイントだったはずだ。これを何と言ったか。そうだ。多様化だ。多様化を実現するためには、アーキテクチャデザインが重要だ。作戦成功のために、多様化すればいいのだ（機能安全 連載 第3回：設計指標が示す構想設計の重要性）。
大気圏外の軌道計算と異なり、地表周辺の大気の状態の軌道への影響は非線形であり、計算そのものに誤差を含まざるを得ない。このようなことから、MAGIは失敗確率99%と算出した。計算地点でエヴァ3体が待ち受けるという仮定に基づいている。
これに対して、3重化および多様性を駆使した作戦アーキテクチャをミサトは考案した。
基地から離れた周辺の3地点から、落下地点に3体が集結する方式である。この方式であれば、MAGIの計算に誤差があっても、3体のどれかが先に到着し2体合流までの時間を稼ぐことができるかもしれない。また移動しながら集結する方式のため、使徒に回避される恐れが少ない。MAGIは優秀なAIだが、この作戦を条件としての計算はさせていない。なぜなら変化する状況への対処には、3体の配置だけではなく、その時のパイロットのプラグ深度など、膨大なパラメータがあり条件設定が困難だからだ。
そこに勝算があるとミサトは考えた。
エヴァを配置のために移動させる作業が続いていた。その光景を背にしながら、ミサトの作戦を聞いていたアスカが質問した。
「この配置の根拠は？MAGIでも計算できなかったのでしょう？最適な多様性配置。」
ミサトは自信たっぷりに宣言した。
「女の勘よ！」
訴えるようにミサトは続けた。
「あなたたち3人の力が必要なのよ。奇跡を起こすために。」
使徒殲滅後、通信が復活し作戦を伝え聞いた碇ゲンドウは語った。
「ああ、よくやってくれた葛城一佐。この程度の被害はむしろ幸運といえる。」
その夜ミサトは、居酒屋で加持に、酔いながらドヤ顔で語っていた。もう３回目だ。
「今回こそ、作戦アーキテクチャの勝利なのよ。なにごとも構想設計からなのよ。詳細段階のトラブル対策だけがすべてではないの！」
「確かに今まで俺たちは、機能安全とは部品故障率の低減のことだと考えて、電子部品の自己診断機能の追加で済ますことに終始していたな。システムの構想設計段階でのリスク分析が重要だとミサトのおかげで気づいたという訳だ。」
ゲンドウの依頼で入手したIEC-61508の原書では、詳細設計段階の細かい故障の対策以前に、構造が安全関連システムの安全完全性を左右すると考えているようだった。また、IEC-61508の改定で追加された制御セキュリティへのリスクアセスメントは、IEC-62443に基づくとある。この規格の中でも、ネットワークアーキテクチャ（構造）での対処が重視されていた。確かDefense in depthと言っていたな。
コップ酒を振り回しながら、ミサトの語りはまだ続いていた。
「構想設計段階での検討が重要なのよ。今回の作戦、3体ともが予想地点で最初から集結していたら、たぶんMAGIの計算通り失敗していたわ。そのアーキテクチャのままで、いくら仔細を煮詰めてトラブルに対処できるように準備をしても、構造の脆弱性は完全にはカバーできないわ。アーキテクチャを適切な図で表現し、その中で、想定される障害リスクをどのように取り扱うのか、構想をよくしてゆく作業、それがリスクベースデザインなのよ。」
ミサトは急に真顔になって、声を潜めて加持に質問した。
「ところで、人類補完計画･･････ZERVは裏で何をしようとしているの？」
「それは･････俺も知りたいところさ。」
ミサトがすでに人類補完計画の真実に近づきつつあるのではないか、そう加持は感じたが黙っていた。
＜次回予告＞※しばらくお休みします。
大気圏外から眺めるセカンドインパクト後の地球。
碇と冬月は、死海文書の外典に気づく。
月面で製造されているエヴァ。
ゼーレの思惑とZERVの計画に違いが明らかになった時、
少年が碇に声をかける。
次回、「機能安全のセクター規格」
この次も、サービスサービスっ！。
