(前NTTデータ フェロー システム科学研究所長)山本 修一郎
システム理論を用いた新しい安全性分析手法の研究が進んでいる。本稿では、このシステム理論に基づく新しい事故モデル手法STAMP(Systems Theoretic Accident Modeling and Processes)/システム理論に基づくハザード分析手法STPA(Systems Theoretic Process Analysis)を説明する。
STAMP(Systems-Theoretic Accident Modeling and Processes)
STAMPは、マサチューセッツ工科大学のNancy. G. Leveson教授が、提唱したシステム理論に基づく事故の発生過程についてのモデルである[1]。
「事故」は、従来「故障イベントの連鎖によって起こる」と定義されていたが、近年システムの複雑さが増し、ハードウェアのように「故障」することのないソフトウェアが多く用いられ、事故発生の仕組みが変わったのである。このためSTAMPでは、事故は単純なコンポーネント故障のみを原因とせず、コンポーネントの振る舞いやコンポーネント間の相互干渉が、システムの安全性制約(コンポーネントの振る舞いに関わる物理的、人、又は社会に関わる制約)を違反した場合に起こると考える。
スペースシャトルのチャレンジャー号事故(1986)に対して、この2つの事故モデルを比較した結果を表1に示す。
STAMPは、複数のコントローラが介在する複雑なシステムに対する事故をモデル化できる。このような複雑なシステムでは、システムを構成するサブシステムやコンポーネントに不具合がなくても、サブシステムやコンポーネントの組み合わせによって全体のシステムで不具合が発生することがある。
表1 事故モデルの比較
安全性制約
STAMPの基本概念は安全性制約である。システム理論では階層構造を考える。各階層では、階層内の活動間に制約があると考える。上位階層の制約が下位階層の活動を制御する。システムの安全状態を構成するシステム変数間の安全関連制約が指定される。原因イベントが、イベント系列に従って事故という結果をもたらすと考えるのではなく、コンポーネント間の相互作用が、システム安全性制約を逸脱した結果によって事故が発生すると考える。安全性制約を強制する制御プロセスによって、システムの挙動が安全に変更かつ適応できるようになる。もちろん、基本的なコンポーネント障害もこの事故モデルの中で考慮されている。障害イベントを識別するだけでは、類似事故を予防する十分な情報を提供することはできない。コンポーネント障害が発生する原因は、製造過程の不適切な制約、設計ミスや不適切な耐障害性の実装などの不適切な開発、コンポーネント容量とタスク要求の対応の欠落、環境外乱の対応漏れ、予防保守や物理的デグレードなどへの不適切な対応などである。
制御は物理的な装置だけで実現されるのではなく、システム設計や製造プロセスで実現される。システム論的事故モデルでは、コンポーネント故障だけではなく、なぜその故障が発生して事故に帰結したかという理由を識別する必要がある。
安全性制約をシステムに強制するには、コンポーネント故障の扱いだけでなく、不注意と注意すべき要因の制御が必要である。システム動作についての制約は、階層的制御構造によって強制される。構造水準ごとに、下位のコンポーネントの動作に必要な制約を強制する。このような制御ループの一般形を図1が示している。この図では、下向きの制御線と上向きのフィードバック線によって、制御ループが各水準の制御構造を操作する。
システム論では、制御装置は制御対象プロセスのモデルを持つ必要がある。このモデルは、制御活動が必要かどうかを判断するために使用される。図1では、制御担当者や制御ソフトの内部に、このようなモデルが組込まれる。人間の場合には、このモデルをメンタルモデルと呼んでいる。
ソフトウェアや人間のオペレータに関連する多くの事故の原因は、ソフトウェアや人間の故障ではない。そうではなく、制御対象プロセスの実際の状態と制御モデルの矛盾にある。フィードバック漏れなどの不注意でも、不正確な制御装置が味方の航空機を敵機だと誤認させることでも、類似する意図しない事故が発生することになる。
図1 制御主体と制御対象
制御条件
システム理論ではシステムを制御するために、次の4条件が必要であるとされる。
【ゴール条件】
制御主体が、目標値や満たすべき制約条件などのゴールを持つ必要がある。
【活動条件】
外乱に際して既定義の限界または安全制約内にプロセスが操作されることを保証するようにシステム状態に影響を与えることができる必要がある。
複数の制御主体に対して、活動が協調してゴール条件を達成できるようにする必要がある。活動が協調できない場合や複数の制御主体間で制御責任の重複があると、制御されたプロセスの境界領域で事故につながる。
【モデル条件】
制御主体が制御対象システムのモデルを持つ必要がある。制御装置が持つプロセスのモデルと、実際のプロセス状態との不整合によって事故が発生することが多い。
【観測条件】
プロセス状態についてのフィードバック情報から、制御主体がシステム状態を確認する必要がある。フィードバックはプロセスモデルを維持更新するために制御主体によって利用される。
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要