安全解析⼿法STAMP／STPA
の概要と事例紹介
平成26年 1⽉ 21⽇ 有⼈宇宙システム株式会社
Japan Manned Space Systems Corporation (JAMSS) 安全開発保証部
ソフトウェアグループ
Contents
1.
会社紹介（10分）
2.
STAMP/STPAの概要（20分）
設⽴
有⼈宇宙システム(株)
⽇本が初めて有⼈宇宙システム：国際宇宙ステーション計画を実施 するにあたり、平成２年５⽉にNASDA／宇宙開発事業団(現JAXA／ 宇宙航空研究開発機構)を⽀援する組織として発⾜。 日本 JAXA 筑波宇宙センター アメリカ NASA宇宙センター 日本 JAXA 筑波宇宙センター アメリカ NASA宇宙センター • ⽇本のモジュールの運⽤管制 • 宇宙実験の準備／実験 • 宇宙⾶⾏⼠／管制要員の訓練 • 運⽤／実験装置の技術⽀援 • 安全開発保証 国際宇宙ステーション44
ソフトウェアIV&V
独⽴検証および有効性確認
（Independent Verification and Validation）
開発組織から独⽴した組織が⾏う ソフトウェアの⾼信頼化・安全性確保のための 評価活動
IV&Vによる効果（メリット）
開発コストの削減 早期に問題点を検出することで開発の⼿戻りを防⽌ システム全体としての視点で問題点を検出 ソフトウェアに偏らず、システムの安全性や信頼性に関わる問題点を識 別 開発者から独⽴的な視点をとることで開発者が⾒逃した 問題点を検出 ユーザの期待する動作を実現していることの確実性を向上 インタフェース、特に開発チームが複数あるときのチーム間のインタフ ェースにおける問題を識別 ソフトウェア 開発 ソフトウェアIV&VIV&Vの実績（⼀部）
組込みシステム 情報システム 無⼈システム 有⼈システム GCOM-W1 GCOM-C1 H-2A かぐや きずな EPSILONE きぼう こうのとり ⼈⼯重⼒発⽣装置 ｢きぼう｣地上官制システム ロケット⾶⾏安全システム ⽣物実験装置 ロケット⾶⾏安全システム © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA © JAXA6
ソフトウェアIV&Vのプロセス
ソフトウェアの開発⼯程 （要求分析〜統合試験）の すべての段階で実施 各開発⼯程において 開発組織が作成する 開発成果物を評価 検証（Verification） 前⼯程での決定事項に 対して正しく 作られていることを確認 有効性確認（Validation） 正しいものが 作られていることを確認 統合 試験仕様統合 試験仕様 結合 試験仕様結合 試験仕様 単体 試験仕様単体 試験仕様 ソース コード ソース コード ソフトウェア 設計 仕様書 ソフトウェア 設計 仕様書 ソフトウェア 要求 仕様書 ソフトウェア 要求 仕様書 システム 仕様書 システム 仕様書 システム 要求分析 システム 要求分析 ソフトウェア 要求分析 ソフトウェア 要求分析 ソフトウェア 設計 ソフトウェア 設計 コーディング コーディング 単体試験単体試験 検証 有効性確認 ソフトウェアIV&V 結合試験 結合試験 統合試験 統合試験 ソフトウェア開発JAMSS IV&Vの特徴
上流⼯程のIV&V
ソフトウェアの要求分析、設計フェーズから検証を実施する
ことで早期に問題点を検出
統合セミフォーマル検証
ハザード解析技術（STAMP/STPA等）により、システム全体
の視点で評価
セミフォーマル検証技術により、開発者から独⽴的な視点で
評価
当社独⾃8
JAMSS IV&Vの特徴
上流⼯程のIV&V
統合 試験仕様統合 試験仕様 結合 試験仕様結合 試験仕様 単体 試験仕様単体 試験仕様 ソース コード ソース コード ソフトウェア 設計 仕様書 ソフトウェア 設計 仕様書 ソフトウェア 要求 仕様書 ソフトウェア 要求 仕様書 システム 仕様書 システム 仕様書 システム 要求分析 システム 要求分析 ソフトウェア 要求分析 ソフトウェア 要求分析 ソフトウェア 設計 ソフトウェア 設計 コーディング コーディング 単体試験単体試験 結合試験 結合試験 統合試験 統合試験 ソフトウェア開発 with 統合セミフォーマル検証 上流⼯程 ※1独⽴テストの実施含む IV&Vを実施する他社 （国内数⼗社※1） 下流⼯程 不具合の 改修コスト※2 1 〜20 〜100 ソフトウェア開発･ 組込み以降 IV&V：9⼈⽉ 改修：1⼈⽉ 改修： 100⼈⽉ IV&V 実施 IV&V 未実施 100⼈⽉ 10⼈⽉ ケーススタディ 不具合混⼊… 不具合検出!! 不具合検出!!※2 McConnell, S（著），クイープ（訳）：Code Complete第2版<上>－完全なプログラミングを⽬指して，
JAMSS IV&Vの特徴
統合セミフォーマル検証
検証対象を絞る技術、フォーマルメソッドなどを基にした
セミフォーマル検証技術を組み合わせ、⼤規模システムに適⽤
【検証対象を絞る技術】 ・階層型事故モデル （NTSBモデル） ・CAST※3 ・階層型事故モデル （NTSBモデル） ・CAST※3 モデル検査技術・BLAST ・PAT Pro ・SPIN
モデル検査技術
・BLAST ・PAT Pro ・SPIN
【セミフォーマル検証技術】 シミュレーション技術 ・UltraC シミュレーション技術 ・UltraC ・FTA ・STAMP/STPA※1 ・CBCS※2安全要求を 参考にしたハザード解析 ・FTA ・STAMP/STPA※1 ・CBCS※2安全要求を 参考にしたハザード解析 検証対象を過去の 同種のソフトウェアの 不具合分析から 得られたソフトウェア の弱点に絞る 検証対象を過去の 同種のソフトウェアの 不具合分析から 得られたソフトウェア の弱点に絞る モデル解析技術 ⾃然⾔語モデリング技術 ・⾃動モデル変換ツール ⾃然⾔語モデリング技術 ・⾃動モデル変換ツール トレーサビリティ 確認技術 ・TRAD トレーサビリティ 確認技術 ・TRAD リーチャビリティ 確認技術 ・RAE リーチャビリティ 確認技術 ・RAE 状態遷移の完全性･⼀貫性 確認技術 ・SpecTRM 状態遷移の完全性･⼀貫性 確認技術 ・SpecTRM ⾃然⾔語に近い⾔語でモデリングすることで 仕様書から効率的に、漏れなく情報を抽出 ⾃然⾔語に近い⾔語でモデリングすることで 仕様書から効率的に、漏れなく情報を抽出 ハザード解析技術 不具合分析技術 フォーマルメソッド 検証対象を安全上重要 な箇所に絞る 検証対象を安全上重要 な箇所に絞る 【統合セミフォーマル検証】
※1 Systems-Theoretic Accident Model and Process /
STAMP based Process Analysis （MITと共同研究中）
※2 Computer-Based Control System
※3 Causal Analysis based on STAMP （MITと共同研究中）
STAMP/STPAの概要
STAMP
（Systems-Theoretic Accident Model and
Process）： システム理論に基づく事故モデル
STPA
（STAMP based Process Analysis）：STAMPに基づく
安全解析⼿法
マサチューセッツ⼯科⼤学(MIT)のNancy.G.Leveson教授が、
最新⽂献“Engineering a Safer World”の中で提唱
複数のコントローラが介在する複雑なシステムに対する安全解
析の⽅法論
システムを構成するサブシステムやコンポーネントに不具合が
なくとも，サブシステムやコンポーネントの組み合わせによっ
て全体のシステムにおける不具合が発⽣する
12
STAMP/STPAの概要
分析⼿法
特徴
従来⼿法
（FTA,
FMEA）
フォールトツリー図や影響分 析表を⽤いて分析する 機器や組織の単⼀故障をハザード要因として識別する 分岐条件を論理的に組むことで 網羅的に分析できる 深く分析できる反⾯、全体的な 視野での分析が難しいSTAMP
/STPA
コントロールストラクチャ図 とコントロールループ図に ガイドワードを適⽤する 複数の機器や組織（⼈間）が、 相互作⽤を⾏う複雑なシステム において、相互作⽤のハザード 要因を識別する 過去の事故事例データに基づく ガイドワードにより網羅的に分 析できる システム全体の振る舞いを確認 しながら分析ができる従来の安全解析⼿法とSTPAの違い
STAMP/STPAの概要
Step.0 ハザード制御に 関わるControl Structureの作成
Step.2 Control Loopの 作成によるハザード要因 の分析 Step.1 ⾮安全なControl Action の識別によるハ ザードシナリオの分析 Step.3 安全制約の識別 分析の流れ 特徴 従来のハザード解析⼿法のよう な、個々のコンポーネント故障 に着⽬するのではなく、複雑に 連携するコンポーネント間の相 互作⽤に関連するシステムレベ ルの問題に着⽬する ４つのガイドワードを⽤いて、 危険な状態を導くコントローラ の動作（⾮安全なコントロール アクション：UCA）を識別する Control Loop上のガイドワード を⽤いて、UCAの要因を識別す る。特に、ソフトウェアやヒュ ーマンに起因する要因として， コントローラの想定するプロセ スモデルが，実際のプロセスの 状態と⽭盾することで起きる要 因を識別する ハザード要因を制御／除去する ための安全制約を識別する
14
STAMP/STPAの概要
Step.0 ハザード制御に関わるControl Structureの作成
システムのハザード制御に関係するコンポーネント（システム、機器、
計算機、組織、⼈など）、及び、コンポーネント間のデータの授受を 識別し、 Control Structure Diagramを作成する
コンポーネント B コンポーネント A コンポーネント C ⾚字：Control Action （指⽰コマンド） ⻘字：フィードバックデータ コマンド1 データ1 コマンド2 データ2 コマンド3
STAMP/STPAの概要
Step.1 ⾮安全なControl Action の識別によるハザード
シナリオの分析
•
Control Structureからハザード制御に必要なControl Action を
抽出し，それらに対して4つのガイドワードを適⽤して，ハザー
ドにつながるUnsafe Control Actionsを分析する
1. “Not Provided”
必要なコントロールアクションが供給されない
2. “Incorrectly Provided”
誤った⾮安全なコントロールアクションが供給される
3. “Provided Too Early, Too Late, or Out of Sequence”
意図しないタイミングで供給される
4. “Stopped Too Soon”
16
STAMP/STPAの概要
Step.2 Control Loopの作成によるハザード要因の分析
• STPA Step1で識別したUnsafe Control Actions毎に，関係するControllerとControlled Processを識別してControl Loop Diagramを 作成し，ガイドワードを適⽤して，詳細なハザード要因を分析する 上位からの指⽰や外部情報の 誤り・⽋落 不⼗分な制御 アルゴリズム （作成上の不具合、 プロセス変更、 不正確な修正・適応） 不⼗分な動作 不⼗分な動作 部品故障 経時変化 プロセスモデルが 不⼀致、不完全 Control Actionが 不適切・無効・⽋落 アクチュエータ センサー コントローラ 制御対象プロセス フィードバックの 不⼗分・⽋落・遅延 動作の遅れ プロセスへの⼊⼒の 誤り・⽋落 意図しない、または 範囲外の外乱 プロセスからの出⼒の 誤り 不正確な情報 情報がない 測定の不正確さ フィードバックの遅延
Step.3 安全制約の識別
Step.2で識別したハザード要因毎に、ハザード要因を制御／除去す
るための安全制約を識別する
3.
宇宙機における
STAMP/STPAの事例
宇宙機におけるSTAMP/STPAの事例
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の主要諸元
宇宙ステーション補給機（H-II Transfer Vehicle: HTV） 愛称：コウノトリ
20
宇宙機におけるSTAMP/STPAの事例
キャプチャフェーズへのSTPA適⽤
1. 種⼦島からH-IIBロケットで打ち上げ2. ISSへのランデブ
3. ロボットアームによる把持（キャプチャ）4. ISSへのドッキング
5. アンドック／ISSからの離脱
6. 再突⼊
HTV⾶⾏運⽤の概要：
宇宙機におけるSTAMP/STPAの事例
Step.0 ハザード制御に関わるControl Structure
の作成
HTV：こうのとり（輸送船） ISS：国際宇宙ステーション TDRS：データ中継衛星 NASA GS：NASA地上局 JAXA GS：JAXA地上局 システムのハザード制御に関係するコンポーネント、及び、コンポーネント間のデータの授受を識別し、 Control Structure Diagramを作 成する
22
宇宙機におけるSTAMP/STPAの事例
Step.1 ⾮安全なControl Action の識別による
ハザードシナリオの分析
キャプチャ時の通常のコマンドシーケンス
短時間
• Control Structureからハザード制御に必要なControl Action を抽出する。 ここでは、キャプチャ時の通常のコマンドシーケンスをControl Actionと する。
• Control Actionに対して4つのガイドワードを適⽤して，ハザードにつなが るUnsafe Control Actionsを分析する （次ページ）
23 Category 1 “Not Provided” Category 2 “Incorrectly Provided” Category 3 “Provided Too Early, Too Late, or Out of Sequence” Category 4 “Stopped Too Soon”
宇宙機におけるSTAMP/STPAの事例
Step.1 ⾮安全なControl Action の識別による
ハザードシナリオの分析
4つのガイドワードを基に、想定しうる システムの状態を、開発者も交えてディ スカッションした結果、各セルの⽂中で 下線が引かれている部分が、ハザードに ⾄る可能性のあるシナリオとして識別さ れた。 （次ページに⼀覧表）24 (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に衝突する。 (3b) HTVがロボットアームに把持された状態で、HTVがアクティベートされ、ロボット アームからの張⼒がHTVへの外乱となり、意図しない姿勢制御、またはアボートとなる。
宇宙機におけるSTAMP/STPAの事例
Step.1 ⾮安全なControl Action の識別による
ハザードシナリオの分析
→各ハザードシナリオに対して、次ページのSTPA Step.2の分析を⾏ったが、 ここでは、(1b)のシナリオのみについて例として採り上げる
• ISS 機器故障 • クルーによるミスオペ（アクティベーションコマンドをうた ない） • ISSクループロセスモデルの⽭盾 • アクティベーションの⾮実施／不適切 • アクティベーションの遅延 • HTV機器故障 • (マルチパスによる)通信障害 • SSRMSによる外乱 • 実際の状態とは異なる不適切なフィードバック （FreeDrift後 の時間、位置） • フィードバック遅延 (FreeDrift後の時間、位置） • 誤ったフィードバック(FreeDrift後の時間、位置） • 実際の状態とは異なる不適切なフィードバック(Flight Mode) • フィードバック遅延 (Flight Mode) • 誤ったフィードバック (Flight Mode) • 地上システムからの誤った情報 分析の結果、従来のハザード解析(FTA)では識別されなかった原因（⾚字）を識別
宇宙機におけるSTAMP/STPAの事例
Step.2 Control Loopの作成による
ハザード要因の分析
• STPA Step1で識別したハザードシナリオ（1b）について、Controller とControlled Processを識別してControl Loop Diagramを作成し，ガ イドワードを適⽤して，詳細なハザード要因を分析する
26 ISSクルーの制御プロセスモデルの⽭盾 HTVは“無制御状態”だが、HTVが”制御状態”だとISSクルーが誤認し、クルーはHTV 制御開始のコマンドを送信しない。 このままの状況が続き、HTVは安全が確保されたキャプチャ可能範囲から徐々に外れ、 ISSに衝突する。
宇宙機におけるSTAMP/STPAの事例
Step.2 Control Loopの作成による
ハザード要因の分析
宇宙機におけるSTAMP/STPAの事例
Step.3 安全制約の識別
ISSクループロセスモデルの⽭盾
• クルーは、HTVから送られてくるテレメトリの中の”Flight Mode”が”Free Drift”か
ら”Retreat”、”Hold”、及び”Abort”になったことによりHTVが“無制御状態”から“制御状態”へ変 化したことを認識することがルール化する。
不適切なフィードバック（時間、位置、Flight Mode）
• INCORRECT: パリティエラー、パケットフォーマットエラー ⇒Integrity CheckやValidity Check （安全要求への合致） • MISSING: 通信断
⇒ISSとHTV間の“ハートビート”信号の状態を監視。通信断の場合は系切替。クルーへ警告
HTVの安全解析書には、STPAで識別した原因の内いくつかが識別されていな いが、実際のHTV設計にはこれら原因に対する安全対策がある安全対策があることを確認した。
