Embed Size (px)
Citation preview
内容
1. 本研究の背景1. 日本の宇宙機開発における不具合事故分析の現状
2. 事故・不具合分析手法 STAMP／CAST概要
2. 本研究の目的
3. 事故モデルSTAMP
4. 不具合分析手法CAST
5. CAST適用事例
6. 今後
• 参考文献
2
１．本研究の背景
• 日本の宇宙機開発における不具合分析／事故分析の現状
3
Hazard
なぜ？
運用手順
コンポーネントの高信頼化
冗長設計によるコスト増大 局所最適なコンポ設計（様々な動作ケースやコンポ間の関係を考慮した設計ではない）
典型的な対策典型的な分析 課題
手順遵守の強化手順の詳細化（人の高信頼化）
運用・訓練の負担大 高度な技術を持った運用者への依存
手順ミスの予測の難しさ（人の振る舞いは、置かれた状況で変わる）
（様々な対策） 分析者に対策の有効性が依存
事故不具合
Controller
Controlled Process
Process Model
Control Feedback
Perturbation
１．本研究の背景
• STAMP/CAST：システム理論に基づく新しい事故・不具合分析手法– ソフトウェアの導入などにより大規模化・複雑化した現代のシステムを前提とした手法
• FTA、FMEAは、1950 – 60年代の比較的シンプルなシステムを前提に考案されている。
• 一般にFTA、FMEAはコンポーネントの関係性を静的に描く。一方で、ソフトウェアの登場により、１つのコンポーネントが多様な振る舞いを担う様になっている（動的に関係性が変わる）。
– 「事故は、システムを構成する要素間のインタラクションで発生するシステムのダイナミクスの結果」と考える。
• システムを構成する１要素の故障または不備（製造ミスなど）だけが事故のトリガ（原因）ではない！（故障が無くても事故は起こる）
– 信頼性理論 vs. システム理論
4
Hazard
信頼性理論 システム理論
• 要素の故障に焦点
• 一方向にイベントが進行（線形的）
• ハードウェア中心のシステム
• 設計されたコンポーネントを分析（例 故障モード）
• 要素間の関係性に焦点• Feedbackを含むループ構
造でダイナミクスを表現（非線形的）
• ソフトウェア、人間も含めたシステム
• コンポーネント間の安全な関係性（制約など）を分析
２．本研究の目的
• STAMP/CASTにより、人を含むシステムを構成するコンポーネントのダイナミックな関係性やシステムが置かれるコンテキストを考慮した、全体システムとしての不具合・事故分析が、宇宙機システムで実現可能であるか／有効な結果を産み出せるかを検討する。
– 具体的には、既に開発・運用が終了した宇宙機システムの不具合・インシデントに対して、STAMP/CASTを適用し、有効性を評価する。
– 対象とする宇宙機システムは、JAXAの宇宙機の中でも高い安全性と人の介在が求められるものである。
5
３．事故モデルSTAMP
• STAMP（Systems-Theoretic Accident Model and Process）： システム理論に基づく事故モデル
• マサチューセッツ工科大学(MIT)のNancy.G.Leveson教授が、最新文献“Engineering a Safer World”の中で提唱
• 複数のコントローラが介在する複雑なシステムに対する事故モデル
– システムを構成するサブシステムやコンポーネントに不具合がなくとも，サブシステムやコンポーネントの組み合わせによって全体のシステムにおける不具合が発生する
6
３．事故モデルSTAMP
• 「事故」は、従来「故障イベントの連鎖によって起こる」と定義されていたが、近年システムの複雑さが増し、ハードウェアのように「故障」することのないソフトウェアが多く用いられ、事故発生の仕組みが変わった
• STAMPでは、システムを相互に干渉するコントロールループの集合体と定義する
• 事故は、単純なコンポーネント故障のみを原因とせず、コンポーネントの振る舞い、又はコンポーネント間の相互干渉が、システムの安全制約（コンポーネントの振る舞いに関わる物理的、人、又は社会に関わる制約）を違反した場合に起こると考える
7
３．事故モデルSTAMP
• スペースシャトルチャレンジャー事故（1986）
– Chain of Events1. 気温低下
2. ロケットのOリング弾性低下
3. ロケットの燃料漏れ
4. 爆発
– STAMP• 安全制約をコントロールできていない状態
– Oリングの機能維持をコントロールできない
– 燃料漏れの防止をコントロールできない
– 技術者と管理者の意思疎通がコントロールできない
8
何が／誰が悪い？
なぜ／どのように？
４．不具合分析手法CAST
• Causal Analysis using System Theory (CAST)
– STAMP事故モデルの考えに基づいた不具合分析手法
– 実施ステップStep1: 不具合、事故情報の内容把握
Proximal event chainを作成する。
Step 2: 対象のシステム分析
system safety constraintおよびハザードに関連するsystem requirementを識別する。
Step 3: Safety Control Structure作成
事故に関わる範囲のSafety Control Structureを作成する。
Step 4: physical system levelの分析
事故要因をphysical system levelで分析する。
Step 5: Higher levelの分析
step4での分析結果を踏まえて、上位の要因を含めて関わりを分析する（人によるdecision makeの分析を含む）。
Step 6: 提言（例）の作成
CASTによる分析結果をもとにした提言（例）の作成。
9
５．CAST適用事例
• 宇宙機に関する３つのシステム／組織（システム１、システム２、組織１）の間で発生した不具合事例
• Step.1 不具合シナリオ– システム１の機器Aの異常に対して、システム１内で対処できず、物理的に離れた組織１で対処せざるを得ない事象が発生
• Step.2 不具合事象と安全制約– 不具合事象：システム１内の機器異常にシステム１自ら対処できない
– 安全制約： システム１内の機器異常にシステム１が自動で対処すること
10
５．CAST適用事例
• Step.3 安全制約を実現するコントロールストラクチャ
11
機器A
計算機B
計算機C
切替コマンド 異常ステータス
停止コマンド 異常ステータス
システム１
システム２
組織１
切替コマンド
異常ステータス
切替コマンド異常ステータス
５．CAST適用事例
• Step.4,5 不具合要因の分析
– 各機器や組織が持つ安全上の責任、不適切な指示、背景、プロセス／メンタルモデルの欠陥、について注目し、不具合要因を分析
12
コンポーネント SafetyResponsibilities
Inadequate control action
Context in which decision made
Process or Mental model flaws
システム１
機器A 入力情報の異常を検知し計算機Bへ伝える
異常検知できない。誤って異常を検知する
機器の入力がインヒビットされている
入力情報の異常を正常ととらえる。
計算機B
計算機C 切替コマンドを発行する
切替コマンドを発行できない
コマンドがインヒビットされている
この期間は切替の必要はないととらえる
システム２
組織１分析中
６．今後
• CASTの適用を継続（Step.4以降）
• コントロールストラクチャに示される、システム１内の計算機、機器と、システム２、組織１との関係において、それぞれが授受する指示やデータ、役割や責任に注目して分析することで、単純なオペレーションミスや機器故障によらない、協調動作の乱れによるシステム要因を識別したい
• 宇宙機に限らず、様々なシステム、機器、組織、人が関係する複雑なシステム及びソフトウェアについても適用を試みる
13
参考文献
• Nancy G. Leveson, Engineering a Safer World - Systems Thinking Applied to Safety, MIT Press, 2011
• 中尾春香, Modeling and Hazard Analysis using SPTA(STAMP/STPAを用いた安全解析手法の検討), 8th WOCS
• 星野伸行, 統合セミフォーマル検証によるソフトウェアIV&V, 9th WOCS
• STAMP/STPA Symposium web-site, http://psas.scripts.mit.edu/home/stampstpa-conference/
14
