宇宙機ソフトウェアにおける

安全要求と設計事例

宇宙航空研究開発機構 (JAXA)

情報・計算工学センター (JEDI)

梅田 浩貴 (Hiroki Umeda)

目次

１：安全性とソフトウェア

２：宇宙機ソフトウェアにおける「安全」とは

３：CBCS安全要求とは

４：宇宙機ソフトウェアの実装例

５：安全設計から得た新たな知見

６：今後

2

1.1 安全性とは

3

ハード ウェア

ソフトウェア

システムを

使用する環境

システム

＜信頼性＞

外部環境下で各部品がどの程度の時間、要求された機能が実現できるか。（故障率） 各部品で定義できる。

＜安全性＞ 外部環境におけるシステムが人/モノに損害を与える可能性（リスク）。システムに対する要件。

人/モノ

安全性と信頼性の違いの例 開かない踏切りは、安全であるが 信頼性はない。

ソフトウェアだけではなく、ハードウェアと

環境を含めて「安全性」を検討する必要がある。

1.2 ソフトウエアが関係する安全機能

4

分類1： 直接原因となる制御系

機能そのものが危険な事象に影響する機能

分類2：安全監視系

危険な事象を監視・検知し、抑制する機能

ケース１）機能不動作が人を殺す、負傷させる ・必要なときに動作しない ・動作中に不意に止まる ・停止時に想定外の止まり方をする．

ケース２）機能動作が人を殺す、負傷させる ・動いてはいけない時に動き出す ・停止しなければならない時に止まらない ・動きだす時に想定外の動きをする

リスク評価と低減 ハザード原因の除去/制御

対象システムの分析 安全要求の定義

ハザードの識別 ハザード原因の識別

システム要求への反映

各機器とソフトウェアの 設計、実装、検証

1

2

3

5

4

システム要求を各機器やソフトウェアに対する要求に詳細化していく。 これ以降、信頼性の話となる。

ハザード制御を実現するためにシステムに対して求められる要求を「安全技術要求」定義する。

ハザード原因に対して、その対策であるハザード除去（本質安全）やハザード制御（機能安全）を検討し、対象となるシステムの機能を識別する。

対象システムによって発生しうるハザード（危険事象）と、その発生する原因を識別する。

対象システムのミッション、使用環境、システム特性等

を考慮して、そのシステムが存在するための前提条件である安全要求を定義する。

2.1 宇宙機開発における安全解析の概要

5

2.2 宇宙機開発における安全要求

安全プロセス要求

① 安全確保の体制

② 安全解析手法

③ 安全審査プロセス

等を定め、組織的且つ系統的なアプローチによる「安全確保の進め方」を規定している。

6

安全技術要求

① 共通の要求（基本的な考え方や共通事項など）

② 個々のシステムに特有の要求

等が全体システムの仕様の一部として要求

安全

安全プロセス（管理）要求 安全技術要求

2.3 宇宙機開発における安全設計）

7

フェーズ０

システム レベル

ソフトウエア レベル

フェーズ１

フェーズ２

フェーズ３

トップ事象（ハザード） の識別（システムFTA

による分析）

システムFTA などによる原因 と制御方法の識別

制御方法の詳細／ 検証方法の検討

設計結果の反映／ 検証結果

関連する ソフトウエアの識別

ソフトウエアFTA による関連（原因、

制御方法）箇所の識別

該当箇所に対する ソフトウエア安全要求

の適用

設計結果の反映／ 検証結果

基本設計

試験後

詳細設計

概念設計

システム全体 のハザード識別

システムFTA/ ソフトウエアFTA

ハザードに関連する ソフトウエア動作を識別

制御方法、安全要求 の設定

安全性検証方法の 設定

検証結果の確認

・ソフトウエアがハザードに関連するのは、 原因となる場合 制御方法となる場合 ・ソフトウエア動作としては、動作すべき機能が動作しないものと動作すべきでない機能が動作するというケース

・ソフトウエアFTAの基本的な考え方としてソフトウエアは故障しない

安全審査 プロセス

開発 プロセス

3.1： CBCS安全要求とは

8

・コンピュータ（ハードウェア＋ソフトウェア）によるハザード制御を行っているシステム。

・具体的な対象範囲は、システム毎に決めていくことになる。

・国際宇宙ステーション「きぼう」の例では、CBCSの範囲として

センサーは含まないが、コンピュータ制御されている

アクチュエータは含めている。

CBCS（Computer Based Control System）とは

・国際宇宙ステーションを建造するにあたり、NASAが規定した安全要求の1つ。

・コンピュータによってハザードを制御するシステムを構築するにあたり、

どのようなアーキテクチャで実現するのか、安全設計を行うための要求である。

・前提条件は、適切なハザード解析が行われていること、となっている。

適用対象は、ハザードに関係する1つの部品やソフトウェアに適用するものではなく、

ハザードを制御するシステムやサブシステムとなる。

CBCS安全要求とは

安全解析の対象を二部分岐法を用いて高い網羅性を実現している。

・MWF（Must Work Function：作動要求機能）

→ 安全を確保するため、その機能が動作し続けなければならない機能

・MNWF（Must Not Work Function：不作動要求機能）

→ 安全を確保するため、その機能が動作してはいけない機能

・ソフトウェアは経年劣化による故障は発生しない

→ハードウェアの「故障」と異なる概念が必要。

・ソフトウェアの設計・製造時に混入された不具合

→ 条件が整えば必ず再現する決定論的な原因による故障である

※注：ソフトウェアが仕様通り動作するか（バグがないか）は、安全性ではなく信頼性。

3.2 CBCS安全要求の基本思想

9

基本思想（１） ソフトウェアは故障しない

基本思想（２） MWFとMNWF

・MWFは、 同等の機能をなす複数の手段をもつシステムアーキテクチャ。

・MNWFは、簡単に起動しないよう複数のインヒビットを設置するシステムアーキテクチャ。

基本思想（３） MWF/MNWFに対するアーキテクチャ要求

3.3 CBCS安全要求の概要

10

CBCS安全要求

一般要求

ハードウェアに関する要求

ソフトウェアに関する要求

開発管理に関する要求

MWF要求

（故障許容設計）

冗長構成された機能の停止は2コマンド

各冗長化機能を制御する経路は分離

MNWF（FCA）要求

（故障伝播抑制設計）

複数のインヒビットを全ての計算機で制御

複数の計算機を使用

MNWF（CPS)要求

（制御経路分離設計）

複数のインヒビットを1台の計算機で制御

各インヒビットを制御する経路を論理的に分離

意図しない起動がハザードを生じる機能を制御する場合の要求

意図しない停止がハザードを生じる機能を制御する場合の要求

各要求の概要

4.1 宇宙機ソフトウェアの実装例1（MWFの停止）

11

機能1

機能2

機能3

機能1停止準備コマンド

計 算

機

機能1停止実行コマンド

機能1停止準備コマンド

機能1停止実行コマンド

機能1停止準備コマンド

機能1停止実行コマンド

Must Work Function（作動要求）の実装方式は、冗長系の構成となる。

2Fault Tolerant（2故障許容）の場合、MWFの停止には下記の構成となる。

MWF

4.2 宇宙機ソフトウェアの実装例2（MNWF）

12

インヒビット3

コマンド3

コマンド2

コマンド1

モジュール1 モジュール2 モジュール3

CPS

制御経路分離方式

FCA

故障伝播抑制方式

電源 モータ

計算機1 計算機2 計算機3

コマンド3 コマンド2 コマンド1

インヒビット1 インヒビット2

制御パス1

制御パス2

制御パス2

Must Not Work Function（非作動要求）の実装方式は、2種類ある。

・Control Path Separation（制御経路分離方式） ・Fault Containment Approach（故障伝播抑制方式）

5．安全設計から得た知見の例（1）

CBCS安全要求を満たす安全設計から導出された新たな知見

13

HTV ISS

ISSから遠い地点の飛行 ISSに近い地点の飛行

HTV

ISS

HTVのスラスタ噴射機能は、 MWFと識別された。

→喪失すると航行不可となるため

HTVのスラスタ噴射機能は、 MNWFと識別された。 →ISSと衝突するため

・スラスタ噴射機能のMWFからMNWFへの切り替えは一瞬で行うこと。

・仮にMNWFへ切り替わらなかった場合、即座にMWFへ自動復帰させること。

・ISS/HTVは2故障許容のため、3つのインヒビット解除コマンドは一斉発行する。

5．安全設計から得た知見の例（2）

14

（１） ARMボタンのカバーを外す

アクション コマンド 解除されるインヒビット

（2） ARMボタンを押す

（3） FIREボタンのカバーを外す

（4） FIREボタンを押す

CBCS安全要求

1つインヒビットを解除するためのコマンドは、1回の操作を必要とすること

→ 3つのインヒビットがある場合、最低3コマンドと3つの操作が必要

コマンド1

コマンド2

コマンド3

インヒビット1

インヒビット2

インヒビット3

従来からあるユーザインタフェースは、ARM/FIREの2段コマンドであるため 安全設計としては、ボタンにカバーをつけ操作を増やして対応した。

安全設計から得た知見

5．安全設計から得た知見の例（3）

15

同等機能を実現できる、異なるソフトウェアの計算結果を照合する

「ソフトウェア冗長」を採用するかどうか

計算機毎にロジックが最適化された宇宙機のソフトウェアでは、似た機能をもつ計算機が2台あったとしても、お互いに機能を補完するソフトウェア冗長を採用することができない。

計算機A 計算機B

外部入出力の計算機

誘導計算も可

誘導計算に最適化

された計算機

計算結果が同じでない場合、計算機AとBのどちらが正しいか判断することはできない。

・計算機A単独の結果の方が信頼性が高くなる。

・ロジックの変更があった際に、2つのソフトウェアへ反映が必要。

仕様変更漏れのリスクが高くなる。

計算結果

照合

安全設計から得た知見

6．今後

・CBCS安全要求を満たす安全設計の結果、改善すべき点を分析する 必要がある。 ・2FT（2故障許容）且つCBCS]安全要求を満たせさえすれば 「安全」と言えるのかさらなる検討が必要である。

現在の課題

・宇宙機の安全設計事例をさらに分析し、宇宙機ソフトウェアの安全要求 を洗練させていく。 →CBCS安全要求を満たすだけでなく、他業界の安全設計事例を分析し 宇宙分野に応用できる考え方や安全要求を検討する。 ・ソフトウェアの安全性は、要求定義以前から検討をする必要があるので 要求定義の手法やその検証手法も確立していく。

今後

ご静聴 ありがとうございました

17