動き続けることが、危険になる瞬間

架空事例：青葉機材が昇降装置を監視する制御システムの安全性を設計する。検出機構、制御方針、故障事象は架空の教育用条件であり、実在の機械に対する安全認証や操作指示ではない。

止まらないことが良いとは限らない

昇降装置の制御センサから信号が来なくなった。稼働を止めない設計なら、作業を継続できる。しかし、位置が分からないまま動かせば、危険な状態になる可能性がある。

同じ「障害に強い」という言葉でも、安全に停止させることと、サービスを継続することでは目的が異なる。

フェールセーフは、障害が発生したときに危険を避ける状態へ移す考え方である。フェールソフトは機能や性能を落としてでも一部のサービスを継続する考え方である。故障を許容して所定のサービスを保つフォールトトレランス、待機系へ切り替えるフェールオーバーも同じ意味ではない。1

青葉機材は、昇降を止める制御と、事務所へ故障を通知する機能を分ける。通知だけが使えなくなった場合、制御をどうするか。位置センサが使えない場合、何を安全状態とするか。危険な物理動作へ結び付く条件を先に整理する。

一つの「故障」から、別の結果が生まれる

位置センサが壊れるとしても、値が全く来なくなる故障、同じ値で固定される故障、時折大きくずれる故障がある。装置へ現れる影響は同じとは限らない。

FMEA（故障モード影響解析）は、要素や機能に起こり得る故障モードを起点に、それが全体へどう影響するかを調べる考え方である。一方、FTA（故障の木解析）は、避けたい頂上事象から原因を論理的に分解する。

例えば「装置が危険な位置まで進んだ」を頂上事象とすると、危険な移動指示が出ること、位置確認が失敗すること、停止が働かないことなどの関係を調べる。これがFTA的な方向である。センサの値が固定される故障から、検出と停止へどんな影響があるかを調べるのはFMEA的な方向となる。1

二つはどちらが優れているかという関係ではない。原因から影響を調べるのか、望ましくない結果から必要な条件を分解するのか。問いの方向を区別することが試験の選択肢にも役立つ。

ANDとORは、図を難しくするためではない

危険な状態が、A「センサ異常」とB「停止機構の不作動」の両方が同時に起きる場合に成立すると単純化する。AとBが独立で、それぞれ発生確率が0.01、0.02なら、同時発生の確率は 0.01×0.02＝0.0002、すなわち0.02%となる。

一方、AかBのどちらか一方で危険が生じるなら、独立性を仮定した確率は 1−(1−0.01)(1−0.02)＝0.0298、すなわち2.98%となる。

同じ二つの値でも、事象の組合せ方で結果は違う。ただし現実の装置では、共通電源の故障や同じプログラムの欠陥によって事象が独立でないことがある。単純な掛算をそのまま実機の安全確率とみなしてはいけない。

計算より前に、何が起きれば危険なのかをモデル化する。数値を並べてからANDやORを選ぶのでは、原因と結果が逆転する。

冗長化で、同じ間違いを二度行う

センサを二台に増やせば安全だろうか。二台が同じ電源へ依存し、同じソフトウェアで処理され、同じ誤った設定を受け取るなら、両方が同時に誤る可能性がある。

冗長化は、異なる故障原因が独立に起きるという仮定で効果を評価することが多い。共通原因を無視すると、数字だけがよく見える。二台の機材が別々に動くという構成図と、同じ理由で止まらないという安全上の根拠は一致しない。

また、二つのセンサ値が食い違ったとき、どちらを信用するかを決めなければならない。多数決を導入するなら必要な個数、異常検出の条件、危険時にどう扱うかを定義する。値が不明なまま「どちらか一方を採用する」だけでは、安全側への判断とならない場合がある。

ソフトウェアの品質と、危険を避ける設計

MISRA Cのようなコーディングガイドラインは、C言語で危険な記述を抑える助けになる。静的解析は実行せずに到達不能コードや未初期化変数などの問題を調べる。しかし、仕様の中に危険な動作を許す条件が書かれているなら、規約を守った実装でもその危険は残る。

安全性の検証では、正常に制御できることだけでなく、必要な入力が来ない場合、電源が変動する場合、通信が止まる場合などを考える。エミュレータ、HIL（Hardware-in-the-Loop）、実機、故障注入にはそれぞれ検証できる範囲が違う。環境を限定したテストを実機全体の証明にしない。

NIST SP 800-82 Rev.3は、物理環境と相互作用するOT（Operational Technology）のセキュリティを、性能・信頼性・安全性の要求に配慮して扱う。2 装置のセキュリティ対策を導入するときも、制御の期限や停止時の危険へどう影響するかを検討する。

主張と証拠を、間の理由で結ぶ

「この装置は危険な昇降を防ぐ」という主張だけでは保証にならない。どの状態を危険とし、どの故障を想定し、何を検出し、どんな動作へ移すかが必要になる。

アシュアランスケースでは、主張（Claim）、それを支える論証（Argument）、証拠（Evidence）を対応させる考え方を用いる。例えば「センサ異常時に危険な動作を継続しない」という主張を、「異常検出から制御出力の制限へ至る論理」と「想定した故障注入で確認した記録」によって支える。

ただし、実施したテストが、主張したすべての故障を覆っているとは限らない。センサが完全に無応答になる場合だけを試しても、誤った一定値を出し続ける場合まで確認したことにはならない。

NASAのシステム工学の公開文書は、要求を検証方法・証拠と結び付ける考え方を示す。3 本章の安全主張は独自の例であり、特定の認証制度をそのまま満たす証拠として扱わない。

安全に止めたあと、業務はどう戻るのか

センサ異常を検出し、装置を安全な状態へ移した。これで一つの目的は達成した。しかし、故障原因が分からず再起動を繰り返せば、別の危険を生む可能性がある。

復旧する前に必要な点検、承認、試験、再開条件を決める。停止させる設計と、再び動かしてよいと判断する設計は別である。遠隔地に設置された装置なら、通信が不安定な状態で誰が許可できるかも考える。

「装置が動いている」と「安全な状態で運用できる」は一致しない。停止に失敗した場合だけでなく、復旧の途中で何が起きるかを確認する必要がある。

安全は単一の部品名ではなく、故障の想定、検出、制御、運用をまたぐ主張なのである。

知識を答案へ戻す

午前Ⅱ。 FMEAとFTA、フェールセーフとフェールソフト、フォールトトレランスとフェールオーバーを目的・分析方向から区別する。

午後Ⅰ。 故障モード、共通原因、危険な頂上事象、異常検出と復旧条件を本文から取り出す。

午後Ⅱ。 安全上の目標、選択した制御方式、想定する故障、検証方法、残る制約を主張と根拠のつながりで説明する。

立ち止まって考える：同じ型番のセンサを二台付けた。故障に対する独立性を保証できるか

できない。電源、配線、設定、ソフトウェア、環境などの共通原因を評価する必要がある。台数だけでは独立性を証明できない。

出典と照合範囲

[1] コンプリートテキスト第10・11・12・13・26章、IPA SAシラバスVer.5.2：安全性・可用性、FMEA・FTA、アシュアランスケースを出発点とした。確率計算は独自の独立モデル。公式シラバス

[2] NIST SP 800-82 Rev.3（2023年最終版）：OTの性能・信頼性・安全性を考慮したセキュリティの観点を参照した。公式資料

[3] NASA Systems Engineering Handbook, Appendix D/E：要求と検証方法・証拠の対応を考える目的で参照した。NASA固有の認証要件を一般へ転用しない。公開説明