# 機能安全 ## 定義 機能安全(Functional Safety)とは、人々や財産——機械・プロセス・システム——に物理的な損害をもたらすような、受け入れられないリスクを取り除くことを目的とする、古くからあるエンジニアリングのプラクティスである。業界特有の規格(自動車のISO 26262、航空のDO-178C・DO-254、原子力のIEC 61513など)は多数存在するが、これらはすべてIEC 61508(「電気・電子・プログラマブル電子機能安全に関する国際規格」)という共通のルーツから派生している。これらの規格には特別な魔法や科学が存在するわけではなく、概して何十年ものあいだ蓄積されてきたエンジニアリングのベストプラクティスや、惨事の影響・議論を受けて成文化されたものである。実際に作っているものが規制対象に該当するかどうかにかかわらず、通常のエンジニアリングの過程で実践するとよい活動が多く含まれる。特に重大な環境に配置されるサイバーフィジカルシステム(CPS)の設計者・開発者は、リスクを評価・管理する上で機能安全のプラクティスを頻繁に活用する。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.1, §17.2) 機能安全の中心的な活動の1つに、故障モードと影響分析(FMEA、Failure Mode and Effects Analysis)がある。典型的なFMEAは、(1) 分析対象のスコープ定義、(2) スコープ内の機能部位の特定、(3) 各機能部位で失敗しうるものすべてのブレインストーミング、(4) 各故障モードによる影響の列挙、(5) 深刻度・発生しやすさ・検知可能性の数値ランク付け、(6) ランク付けの値を掛け合わせたリスク優先度数値の算出、(7) スプレッドシートへの書き出しとイテレーションごとの見直し、という7ステップで進む。分析対象スコープの考慮漏れ、機能部位の特定の困難さ、失敗しうる事項の網羅不可能性、ランキングの恣意性など多くの潜在的な落とし穴を抱えるが、経験豊富で分野横断的な専門家を集めて十分な時間をかけて実施すると、不確実性を引き出す上でよい成果が得られる。FMEAが重要な役割を果たしてきた理由は、正確な予測そのものよりも「失敗を前提としたマインドセット」を養う点にあるとされる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.2) FMEAは通常、多点故障(複数の故障モードの同時発生)を分析の考慮に含めない。電気機械システムの観点からは、独立した2つの機械部品・電気機器コンポーネントが同時かつランダムに故障する可能性は極めて低いため、この前提は合理的である。しかし、ソフトウェアの多用はこの前提を破る——同一の機能が無数の箇所から呼び出され、1つの欠陥があらゆる依存箇所で同時に問題を引き起こしうるため、多点故障として知られる同時多発的な故障モードを生成しやすくなる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.3, §17.4) ## 横断的知見 - **FMEAはボトムアップ、[[故障の木解析]](FTA)はトップダウンという逆方向の解析であり、両者は補完関係にある**: 本ページのFMEAは、スコープ内の個々の機能部位を特定し、そこから「何が失敗しうるか」をブレインストーミングで積み上げるボトムアップの手順として定式化される(定義節参照)。[[故障の木解析]]が集約する FTA は逆に、定義済みのトップ事象(システムの故障影響)から出発し、それを引き起こしうる下位事象へAND/OR/INHIBITゲートでトップダウンに遡る「故障指向(failure-oriented)」の技法として整理されている。両者は「何を分析の起点にするか」が逆であるが、目的(システムの故障モードを洗い出しリスクを評価する)は共有しており、FMEAで洗い出した個々の故障モードをFTAのトップ事象の構成要素として使う、あるいはFTAで特定した重要な下位事象をFMEAのスコープ定義に反映させるという形で連携しうる。ただし本ページのソース(ch.17)はFTAへの言及を持たず、この連携の具体的な手順は示されていない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.2, [[@2012__Wiley__Practical Reliability Engineering - Chapter 6 Reliability Prediction and Modelling]] §6.9-§6.10) - **FMEAのランキングの恣意性という限界は、[[信頼性工学]]が指摘する「数学的・統計的手法の役割は限定的である」という一般的な立場の具体例として読める**: ch.17はFMEAの深刻な限界として「たとえガイドラインがあったとしても、ランキングは本質的に恣意的なもので現実を反映しているとは限らない」ことを挙げる。[[信頼性工学]]が集約する『Practical Reliability Engineering』第1章は、信頼性工学における数学的・統計的手法の役割は限定的であり、実務上の工学的判断が優先されるべきだと明言する——高信頼性ゆえに故障データが乏しく、過去データを将来予測にそのまま使えないためである。FMEAの深刻度×発生しやすさ×検知可能性というランク付けの掛け算(リスク優先度数値)は、この「限定的にしか機能しない定量化」を実務で運用可能な形に落とし込んだ具体例であり、その恣意性は信頼性工学が一般論として指摘する限界の顕れと解釈できる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.2, [[@2012__Wiley__Practical Reliability Engineering - Chapter 1 Introduction to Reliability Engineering]] §1.1, §1.4) - **ソフトウェアが多点故障を頻発させるという ch.17 の指摘は、[[ソフトウェア耐障害性]] が既に集約する「複製された欠陥は同時に励起される」という Gray(1985)の観察、および McAllister & Vouk(1996)の `RALL`(全バージョンとdeciderに影響する関連故障)と同じ現象を、機能安全という異なる文脈から独立に確認する**: [[ソフトウェア耐障害性]]は、Jim Grayが「複製されたソフトウェアの欠陥は同時に励起される」と述べたこと、および多版ソフトウェアの実験で関連故障(`RALL`)が単一の基本事象として扱われる必要があることを記録している(横断的知見参照)。ch.17は同じ現象を「1つの物理的な抵抗器が1000種類の方法で呼ばれることはまずないが、ソフトウェアの機能は1000箇所から呼び出され毎回同じ機能でありうる」という比喩で、機能安全・FMEAの実務的な限界として独立に指摘する。フォールトトレランス研究の文脈(ソフトウェア耐障害性)と機能安全の文脈(本ページ)という異なる出自の2つのソースが、「ソフトウェアの同一性による障害の同時多発」という同じ構造的問題に到達している。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.3, [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] §3, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.5.1-§14.5.3) ## 未解決の問い - FMEAとFTAを実務上どう連携させるか(FMEAで洗い出した故障モードをFTAのトップ事象・下位事象にどう反映するか)は、本ページのソース(ch.17)からもFTA側のソース([[故障の木解析]])からも示されていない。 - FMEAのランキング(深刻度×発生しやすさ×検知可能性)の恣意性を緩和するために、[[故障の木解析]]が持つカット集合・タイ集合のような定量的な手法をFMEAへ部分的に導入できるか。 - ソフトウェアの多点故障(同一欠陥の同時多発)に対し、FMEAのプロセス自体をどう改修すれば有効な分析ができるか。ch.17は限界を指摘するにとどまり、具体的な改修案は示さない。 - ISO 26262・DO-178C・DO-254・IEC 61513といった業界別規格が、それぞれどこまでIEC 61508の要求を独自に拡張しているかは、ch.17では名前が挙げられるのみで詳細な比較はされていない。 ## 関連 - 概念: [[カオスエンジニアリング]] / [[故障の木解析]] / [[信頼性工学]] / [[ソフトウェア耐障害性]] / [[プローブ効果]] - 実体: [[Nathan Aschbacher]] / [[Auxon]] - source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] ## 出典 - Nathan Aschbacher, 「サイバーフィジカルで行こう」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 17章(§17.1-§17.4)。