第8回クリティカルソフトウェアワークショップ
8
thWorkshop of Critical Software (WOCS2011)
Modeling and Hazard Analysis using STPA
～STAMP/STPAを用いた安全解析手法の検討～
2011.1.18
Massachusetts Institute of Technology (MIT)
Takuto Ishimatsu, Nancy Leveson, John Thomas
宇宙航空研究開発機構 情報・計算工学センター 片平真史、宮本裕子
有人宇宙システム(株) 安全開発保証部 中尾春香 （発表者）
目次
• 研究目的
• STAMP/STPA
• JAXA HTV（コウノトリ）での試行
– システム・飛行運用の概要紹介
– キャプチャフェーズへのSTPA適用
– STPAの有効性として確認できたこと
• 今後の取り組み
研究目的
～MITとJAXA及びJAMSS間の共同研究～
•
目的
– STAMP/STPAの宇宙システムへの適用可能性を分析し、適用時の課題に
ついての解決策を検討する。
– STAMP (Systems-Theoretic Accident Model and Processes) – STPA (STAMP-Based Process Analysis)
– STAMP/STPAのハザード解析手法としての有効性を評価する。
• STPAの結果とFTAに基づく安全解析書（*1）との比較
STPA
FTA
(*1) 安全解析書： システムが安全要求に合 致しているか、ハザード が適切に制御できている か否かを示した文書STAMP/STPA
•
特性
– コンポーネント故障に着目するのではなく、コントローラ同士の相
互作用を伴う動作に忍び込む問題に着目する。
– 事故はコンポーネント故障によってのみ起きるのではなく、危険
な状態を導く動作に対して、安全制約が徹底されていないことで
おきると捉える。
– 2故障許容設計などの
”故障対策”
ではなく、
”安全制約”
を識別
し設計に組み込むことに重きを置く。
– 設計の初期フェーズから利用可能。
システム理論に基づく事故モデル:
STAMP (Systems‐Theoretic Accident Model and Processes)
安全解析手法:
STPA (STAMP‐Based Process Analysis)
STAMP/STPA の流れ
ハザードの識別とハイレベ ルの安全要求、安全制約 の識別 Control Structure Diagramの定義 Step1．不適切な制御 アクションによるハ ザードシナリオの識別 ハザードシナリオにつなが る潜在原因の識別 Potential causeへの対策 検討、要すれば 設計見直し （Eliminate or Control）Control Structure Diagram (例)
①Not Provided
②Incorrectly provided
④Stopped too soon ③Provided Too Early,
Too Late, or Out of Sequence
Action is：
出展：
Nancy Leveson著
“Engineering a Safer World ”
事前準備
Step1．不適切な制御アクションによる
ハザードシナリオの識別
～Inadequate Control Action～
不適切な制御アクションは以下の4つの一般的なカテゴリに落としこまれる。
1.
“Not Provided”
A required control action to maintain safety is not provided.
2.
“Incorrectly Provided”
An incorrect or unsafe control action is provided that induces a loss.
3.
“Provided Too Early, Too Late, or Out of Sequence”
A potentially correct or adequate control action is provided too early, too late,
or out of sequence.
4.
“Stopped Too Soon”
Step2．ハザードシナリオにつながる
潜在原因（Causal Factor）の識別
出展：
Nancy Leveson著
“Engineering a Safer World ”
HTV（コウノトリ）のシステム概要
Items Specifications 全長 9.8 m (including thrusters) 直径 4.4 m 質量 10,500 kg 推薬 燃料: MMH 酸化剤: MON3 (Tetroxide) 補給能力 6,000 kg - 与圧区: 4,500 kg - 非与圧区: 1,500 kg 廃棄品搭載能力 Max. 6,000 kg 軌道 高度: 350-460 km 軌道傾斜角: 51.6 degrees 最長ミッション期 間 Solo flight: 100 時間 Stand-by (on-orbit): > 1 週 Berthed with ISS: Max. 30 日間HTVの主要諸元
HTV‐1号機 :
(2009年 9/10打ち上げ – 11/2再突入)
HTV‐2号機 :
(2011年 1/20打ち上げ予定)
宇宙ステーション補給機（H-II Transfer Vehicle: HTV） 愛称：コウノトリ
HTV飛行運用概要
キャプチャフェーズへのSTPA適用
1. 種子島からH-IIBロケットで打ち上げ
2. ISSへのランデブ
3. ロボットアームによる把持（キャプチャ）
4. ISSへのドッキング
5. アンドック／ISSからの離脱
6. 再突入
HTV飛行運用の概要：
事前準備. ハザードの識別とハイレベルの
安全要求・安全制約の識別
ロボットアームによるHTVキャプチャを行うフェーズでのHTVの
ISSへの衝突、及びミッション喪失をハザードとして識別
※安全のための対策
・地上からのコマンドによりHTVのスラスタ制御がオフされた直後にISSクルーがロボットアー
ム操作によってHTVをキャプチャする。
・キャプチャ失敗時など緊急時はISSクルーからのコマンドにより危険を回避する。（図1）
パネルからのクリティカルコマンド:
ABORT
アボート、緊急待避RETREAT
ISSの下30mまたは100m地点まで後退HOLD
その場に停止FRGF SEP
Separate the Flight Releasable Grapple Fixture (FRGF)を分離する
事前準備 Control Structure Diagramの定義
（トップレベル：抽象レベル0）
Step1．不適切な制御アクションによる
ハザードシナリオの識別
表1 キャプチャ時の通常のコマンドシーケンス
短時間•
キャプチャ時の通常のコマンドシーケンスを識別する。
•
コマンドシーケンスで出現するコマンドを対象に、一般的な4つのカテゴリに当て
はめ不適切な制御アクションを識別する。
•
不適切な制御アクションによるハザードシナリオを識別する。
表.ハザードシナリオにつながる不適切な制御アクションの識別
Category 1
“Not
Provided”
Category 2
“Incorrectly
Provided”
Category 3
“Provided
Too Early,
Too Late, or
Out of
Sequence”
Category 4
“Stopped
Too Soon”
クルーからのクリティカルコマ
ンド（Abort, Free Drift,
FRGF Sepなど）が誤って送
出される、というシナリオも考
慮する。
(1a) HTVがロボットアームにミスキャプチャされた危険な状態で、FRGFを分離できず、
HTVが回転し始め、ロボットアームに衝突する。
(1b) HTVがキャプチャ可能領域から徐々に外れていった状態で、HTVをアクティベート
（制御開始）するコマンドが来ない、又は遅れることでHTVが浮遊状態のままISSに衝突
する。
(2a) アクティベート状態のままキャプチャすると、このミスキャプチャがHTVへの外乱と
なり、意図しない姿勢制御、またはアボートとなる。
(2b) ロボットアームによるキャプチャ前にFRGFが意図せず分離され、FRGFの機構部分
が浮遊物となり、ISSへ衝突する。またミッションも喪失する。
(Ca)ロボットアームが、浮遊状態になったHTVを誤って小突くことで、HTVが回転し始め、
ISSに衝突する。
(Cb) キャプチャが中途半端に終わり、HTVがロボットアームに固定されていない状態と
なって、回転し始め、ロボットアームに衝突する。
(3a) FRGF分離がイネーブルの状態で、FRGF分離が実行され、HTVをアクティベートす
るコマンドが来ない、又は遅れることで、HTVが浮遊状態のままISSに衝突する。
識別されたハザードシナリオ
Step2．ハザードシナリオにつながる
潜在原因（Causal Factor）の識別
(1b) HTVがキャプチャ可能領域から徐々に外れていった状態で、HTVをアクティベーション（制
• ISS 機器故障 • クルーによるミスオペ（アクティベーションコマンドを打た ない） • ISSクループロセスモデルの矛盾 • アクティベーションの非実施／不適切 • アクティベーションの遅延 • HTV機器故障 • (マルチパスによる)通信障害 • SSRMSによる外乱 • 実際の状態とは異なる不適切なフィードバック （FreeDrift後 の時間、位置） • フィードバック遅延 (FreeDrift後の時間、位置） • 誤ったフィードバック(FreeDrift後の時間、位置） • 実際の状態とは異なる不適切なフィードバック(Flight Mode) • フィードバック遅延 (Flight Mode) • 誤ったフィードバック (Flight Mode) • 地上システムからの誤った情報
STPAにて識別された潜在原因
• ISS 機器故障 • クルーによるミスオペ（アクティベーションコマンドをうた ない） • ISSクループロセスモデルの矛盾 • アクティベーションの非実施／不適切 • アクティベーションの遅延 • HTV機器故障 • (マルチパスによる)通信障害 • SSRMSによる外乱 • 実際の状態とは異なる不適切なフィードバック （FreeDrift後 の時間、位置） • フィードバック遅延 (FreeDrift後の時間、位置） • 誤ったフィードバック(FreeDrift後の時間、位置） • 実際の状態とは異なる不適切なフィードバック(Flight Mode) • フィードバック遅延 (Flight Mode) • 誤ったフィードバック (Flight Mode) • 地上システムからの誤った情報
赤字： 安全解析書上は識別されなかった原因
安全解析書上の安全制御の識別
•
ISSクルーの制御プロセスモデルの矛盾
– HTVは“無制御状態”だが、HTVが”制御状態
”
だとISSクルーが誤認し、クルーはHTV
制御開始のコマンドを送信しない。
– このままの状況が続き、HTVは安全が確保されたキャプチャ可能範囲から徐々に外れ、
ISSに衝突する。
潜在原因（Causal Factor）の例
実際のHTV設計・運用による安全対策
安全解析書には、STPAで識別した原因の内いくつかが識別されていないが、実
際のHTV設計にはこれら原因に対する
安全対策がある
安全対策がある
ことを確認している。
•
例） Causal factors:
– ISSクループロセスモデルの矛盾
– 不適切なフィードバック（時間、位置、Flight Mode）
9 ISSクループロセスモデルの矛盾
• クルーは、HTVから送られてくるテレメトリの中の”Flight Mode”が”Free Drift”から”Retreat”、”Hold”、 及び”Abort”になったことによりHTVが“無制御状態”から“制御状態”へ変化したことを認識することが ルール化されている。
9 不適切なフィードバック（時間、位置、Flight Mode）
• INCORRECT: パリティエラー、パケットフォーマットエラー⇒Integrity CheckやValidity Check （安全要求への合致） • MISSING: 通信断
