宇宙機ソフトウェアにおける 安全要求と設計事例 宇宙航空研究開発機構 (JAXA) 情報 計算工学センター (JEDI) 梅田浩貴 (Hiroki Umeda)
目次 1: 安全性とソフトウェア 2: 宇宙機ソフトウェアにおける 安全 とは 3:CBCS 安全要求とは 4: 宇宙機ソフトウェアの実装例 5: 安全設計から得た新たな知見 6: 今後 2
1.1 安全性とは 安全性と信頼性の違いの例開かない踏切りは 安全であるが信頼性はない < 安全性 > 外部環境におけるシステムが人 / モノに損害を与える可能性 ( リスク ) システムに対する要件 人 / モノ システムを使用する環境 ソフトウェア ハードウェア システム ソフトウェアだけではなく ハードウェアと環境を含めて 安全性 を検討する必要がある < 信頼性 > 外部環境下で各部品がどの程度の時間 要求された機能が実現できるか ( 故障率 ) 各部品で定義できる 3
1.2 ソフトウエアが関係する安全機能 分類 1: 直接原因となる制御系 機能そのものが危険な事象に影響する機能 分類 2: 安全監視系 ケース 1) 機能不動作が人を殺す 負傷させる 必要なときに動作しない 動作中に不意に止まる 停止時に想定外の止まり方をする. ケース 2) 機能動作が人を殺す 負傷させる 動いてはいけない時に動き出す 停止しなければならない時に止まらない 動きだす時に想定外の動きをする 危険な事象を監視 検知し 抑制する機能 4
2.1 宇宙機開発における安全解析の概要 1 対象システムの分析安全要求の定義 対象システムのミッション 使用環境 システム特性等を考慮して そのシステムが存在するための前提条件である安全要求を定義する 2 ハザードの識別ハザード原因の識別 対象システムによって発生しうるハザード ( 危険事象 ) と その発生する原因を識別する 3 リスク評価と低減ハザード原因の除去 / 制御 ハザード原因に対して その対策であるハザード除去 ( 本質安全 ) やハザード制御 ( 機能安全 ) を検討し 対象となるシステムの機能を識別する 4 システム要求への反映 ハザード制御を実現するためにシステムに対して求められる要求を 安全技術要求 定義する 5 各機器とソフトウェアの設計 実装 検証 システム要求を各機器やソフトウェアに対する要求に詳細化していく これ以降 信頼性の話となる 5
2.2 宇宙機開発における安全要求 安全プロセス要求 1 安全確保の体制 2 安全解析手法 3 安全審査プロセス 安全技術要求 1 2 共通の要求 ( 基本的な考え方や共通事項など ) 個々のシステムに特有の要求 等を定め 組織的且つ系統的なアプローチによる 安全確保の進め方 を規定している 等が全体システムの仕様の一部として要求 安全プロセス ( 管理 ) 要求 安全技術要求 安全 6
2.3 宇宙機開発における安全設計 ) 開発プロセス 概念設計 基本設計 詳細設計 試験後 安全審査プロセス フェーズ 0 フェーズ 1 フェーズ 2 フェーズ 3 システムレベル トップ事象 ( ハザード ) の識別 ( システム FTA による分析 ) システム FTA などによる原因と制御方法の識別 制御方法の詳細 / 検証方法の検討 設計結果の反映 / 検証結果 ソフトウエアレベル 関連するソフトウエアの識別 ソフトウエア FTA による関連 ( 原因 制御方法 ) 箇所の識別 該当箇所に対するソフトウエア安全要求の適用 設計結果の反映 / 検証結果 ソフトウエアがハザードに関連するのは 原因となる場合制御方法となる場合 ソフトウエア動作としては 動作すべき機能が動作しないものと動作すべきでない機能が動作するというケース ソフトウエア FTA の基本的な考え方としてソフトウエアは故障しない システム全体のハザード識別 システム FTA/ ソフトウエア FTA ハザードに関連するソフトウエア動作を識別 制御方法 安全要求の設定 安全性検証方法の設定 検証結果の確認 7
3.1: CBCS 安全要求とは CBCS(Computer Based Control System) とは コンピュータ( ハードウェア+ソフトウェア ) によるハザード制御を行っているシステム 具体的な対象範囲は システム毎に決めていくことになる 国際宇宙ステーション きぼう の例では CBCSの範囲としてセンサーは含まないが コンピュータ制御されているアクチュエータは含めている CBCS 安全要求とは 国際宇宙ステーションを建造するにあたり NASA が規定した安全要求の 1 つ コンピュータによってハザードを制御するシステムを構築するにあたり どのようなアーキテクチャで実現するのか 安全設計を行うための要求である 前提条件は 適切なハザード解析が行われていること となっている 適用対象は ハザードに関係する 1 つの部品やソフトウェアに適用するものではなく ハザードを制御するシステムやサブシステムとなる 8
3.2 CBCS 安全要求の基本思想 基本思想 (1) ソフトウェアは故障しない ソフトウェアは経年劣化による故障は発生しない ハードウェアの 故障 と異なる概念が必要 ソフトウェアの設計 製造時に混入された不具合 条件が整えば必ず再現する決定論的な原因による故障である 注 : ソフトウェアが仕様通り動作するか ( バグがないか ) は 安全性ではなく信頼性 基本思想 (2) MWF と MNWF 安全解析の対象を二部分岐法を用いて高い網羅性を実現している MWF(Must Work Function: 作動要求機能 ) 安全を確保するため その機能が動作し続けなければならない機能 MNWF(Must Not Work Function: 不作動要求機能 ) 安全を確保するため その機能が動作してはいけない機能 基本思想 (3) MWF/MNWF に対するアーキテクチャ要求 MWF は 同等の機能をなす複数の手段をもつシステムアーキテクチャ MNWF は 簡単に起動しないよう複数のインヒビットを設置するシステムアーキテクチャ 9
3.3 CBCS 安全要求の概要 各要求の概要 ハードウェアに関する要求 意図しない停止がハザードを生じる機能を制御する場合の要求 一般要求 ソフトウェアに関する要求 開発管理に関する要求 CBCS 安全要求 MWF 要求 ( 故障許容設計 ) 冗長構成された機能の停止は 2 コマンド 各冗長化機能を制御する経路は分離 意図しない起動がハザードを生じる機能を制御する場合の要求 MNWF(FCA) 要求 ( 故障伝播抑制設計 ) MNWF(CPS) 要求 ( 制御経路分離設計 ) 複数のインヒビットを全ての計算機で制御複数の計算機を使用複数のインヒビットを1 台の計算機で制御各インヒビットを制御する経路を論理的に分離 10
4.1 宇宙機ソフトウェアの実装例 1(MWF の停止 ) Must Work Function( 作動要求 ) の実装方式は 冗長系の構成となる 2Fault Tolerant(2 故障許容 ) の場合 MWF の停止には下記の構成となる 機能 1 停止準備コマンド 機能 1 停止実行コマンド 機能 1 機能 1 停止準備コマンド 機能 1 停止実行コマンド 計 算 機 機能 2 機能 1 停止準備コマンド 機能 1 停止実行コマンド 機能 3 MWF 11
4.2 宇宙機ソフトウェアの実装例 2(MNWF) Must Not Work Function( 非作動要求 ) の実装方式は 2 種類ある Control Path Separation( 制御経路分離方式 ) Fault Containment Approach( 故障伝播抑制方式 ) コマンド 3 コマンド 2 制御パス 2 制御パス 2 CPS 制御経路分離方式 コマンド 1 制御パス 1 モジュール 1 モジュール 2 モジュール 3 電源 インヒビット 1 インヒビット 2 インヒビット 3 モータ FCA 故障伝播抑制方式 計算機 1 計算機 2 計算機 3 コマンド 1 コマンド 2 コマンド 3 12
5. 安全設計から得た知見の例 (1) CBCS 安全要求を満たす安全設計から導出された新たな知見 ISS から遠い地点の飛行 ISS に近い地点の飛行 HTV HTV ISS ISS HTV のスラスタ噴射機能は MWF と識別された 喪失すると航行不可となるため HTV のスラスタ噴射機能は MNWF と識別された ISS と衝突するため スラスタ噴射機能の MWF から MNWF への切り替えは一瞬で行うこと 仮に MNWF へ切り替わらなかった場合 即座に MWF へ自動復帰させること ISS/HTV は 2 故障許容のため 3 つのインヒビット解除コマンドは一斉発行する 13
CBCS 安全要求 5. 安全設計から得た知見の例 (2) 1 つインヒビットを解除するためのコマンドは 1 回の操作を必要とすること 3 つのインヒビットがある場合 最低 3 コマンドと 3 つの操作が必要 アクションコマンド解除されるインヒビット (1) ARM ボタンのカバーを外す (2) ARM ボタンを押す コマンド 1 インヒビット 1 (3) FIRE ボタンのカバーを外す コマンド 2 インヒビット 2 (4) FIRE ボタンを押す コマンド 3 インヒビット 3 安全設計から得た知見 従来からあるユーザインタフェースは ARM/FIRE の 2 段コマンドであるため安全設計としては ボタンにカバーをつけ操作を増やして対応した 14
5. 安全設計から得た知見の例 (3) 同等機能を実現できる 異なるソフトウェアの計算結果を照合する ソフトウェア冗長 を採用するかどうか 誘導計算に最適化された計算機 計算機 A 計算結果照合 外部入出力の計算機誘導計算も可 計算機 B 計算結果が同じでない場合 計算機 A と B のどちらが正しいか判断することはできない 計算機 A 単独の結果の方が信頼性が高くなる ロジックの変更があった際に 2 つのソフトウェアへ反映が必要 仕様変更漏れのリスクが高くなる 安全設計から得た知見 計算機毎にロジックが最適化された宇宙機のソフトウェアでは 似た機能をもつ計算機が2 台あったとしても お互いに機能を補完するソフトウェア冗長を採用することができない 15
6. 今後 現在の課題 CBCS 安全要求を満たす安全設計の結果 改善すべき点を分析する必要がある 2FT(2 故障許容 ) 且つ CBCS] 安全要求を満たせさえすれば 安全 と言えるのかさらなる検討が必要である 今後 宇宙機の安全設計事例をさらに分析し 宇宙機ソフトウェアの安全要求を洗練させていく CBCS 安全要求を満たすだけでなく 他業界の安全設計事例を分析し宇宙分野に応用できる考え方や安全要求を検討する ソフトウェアの安全性は 要求定義以前から検討をする必要があるので要求定義の手法やその検証手法も確立していく
ご静聴ありがとうございました 17