目次背景説明 ( 業務説明前提知識等 ) 提案手法の概要提案手法の有効性確認結果まとめ 2

(1)

GSN 及びESD モデルを用いたソフトウェア

FMEA の提案

Failure mode and effect analysis using Goal Structuring Notation

and Event Sequence Diagram for Software

国立研究開発法人宇宙航空研究開発機構

研究開発部門第三研究ユニット

○梅田浩貴波平晃佑祖川和弘植田泰士片平真史

e-mail：umeda.hiroki@jaxa.jp

(2)



背景説明（業務説明、前提知識等）



提案手法の概要



提案手法の有効性確認結果

(3)

宇宙機搭載ソフトウェアの種類と特徴



システムの動作環境が過酷で、ソフトウェアの誤動作は損失大。



想定外が発生しやすい。（放射線によるメモリ化けが発生等）



ロケットや衛星の損失は、環境や人命の喪失につながる。



故障の対応や復帰も難易度が高い。（地球との通信は、特定期間のみ）



部品交換はできず、実際の利用環境の試験もできない。



ハードウェアは、基本的に予備（冗長系）を搭載している。



ソフトウェアは、安全解析を含めた設計検証や網羅的な試験が重要である。



開発数や機会が少なく、研究実証向けの製品。



5年以上の長い開発期間、少量多品種である。

3 

宇宙ステーション



人工衛星



ロケット



地上管制システム

(4)

本発表の概要

課題①： FMEAの分析は、

エキスパート依存性が高い。

※例：ソフトウェア製品の修正につながる「故障」が発想が難しい等。

課題②：

FMEA結果をレビュー

することが困難。

※例：SW故障後にどのような時系列で影響を判定したのか読み取れない等。

課題③：失敗経験に関する情報が少なく、非熟練者への支援が困難。

※例：繰り返し適用によって特化した誘導語の整備ができない等

（１）提案手法は、FMEA未経験者の故障発想を支援している。

（２）提案手法は、熟練者に取って既存のコストと同等で分析できる。

（３）提案手法は、熟練者からの技術継承を促進する可能性がある。

研究実証を目的とし、開発期間が長く、実際の環境で試験できない「宇宙機」の

ソフトウェア開発で、

FMEA（故障モードと影響解析）を適用した場合、下記の課題があった。

結論

(5)

前提説明（故障の概念）

5 ・ソフトウェアは、経年劣化しない。

・ソフトウェアは、見えない。

・ソフトウェアは、属人的に作られる。

故障

原因

ストレス

システムが

故障状態

システムが

動作状態

故障

メカニズム

故障

_事象

人・機器が「故障

※

1 」を認知

※

1：アイテムが要求機能達成能力を失う

時間

利用運用時

ソフトウェアの製品としての特徴

ソフトウェアFMEA適用時の課題

・抽象概念や論理に対し

アイテム（解析単位）

の設定が属人的。

・ソフトウェアで対応できる故障の発想が困難。

・事例が少ないと、故障モードや誘導語の整備が困難。

コンポー

ネント

サブシステム

システム

パーツ

サブシステム

コンポー

ネント

コンポー

ネント

パーツ

※

FTA

：フォルトツリー解析

FMEA ：故障モードとその影響の解析

ソフトウェア品質シンポジウム2018

(6)

アイテム名

故障モード

故障原因

検出機能

誤った入力

画像センサーの故障

画像データ

遅過ぎるタイミング

ネットワークの遅延

故障モードとは、故障を適度の抽象度でまとめた様式のこと。

業務説明（FMEAの一般的な適用例）

FMEAの工程

解析体制や方針を決め

アイテムを決める。

故障モードを

作成する

影響を解析する

対策を検討する。

故障の影響

対策内容

対策効果

○○が検知できず、

システムが誤認識する。

・冗長系で対応する。

・入力の誤りを検出する。

1つのセンサーが故障し

ても誤検知しない。

検知処理の実行が遅くなり、

システムの認識が遅れる。

検知機能が有効でないこ

とを通知する。

システムではなく、人の

判断で検知する。

アイテムに故障モード

発生頻度をランク付け

致命度の算定

重要度から対策の

優先順位を決める

対象

故障モードの例

ポイント

ソフトウェア

誤入力

早過ぎ/遅過ぎる入力

タイミング

抽象概念で、「論理」はアイテム

単体で故障しない。

※設計ミスやバグは対象外

ハードウェア

断線、摩耗、腐食

物理事象のため、アイテムで

パターン化しやすい

SWで対策を行う場合、

(7)

前提説明（故障とソフトウェアFMEAの概念）

7 故障

原因

ストレス

システムが

故障状態

システムが

動作状態

故障

メカニズム

故障

_発生

人・機器が「故障

※

1 」を認知

※

1：アイテムが要求機能達成能力を失う

時間

利用運用時

・製品だけでなく、環境や利用者なども分析対象とすること。

・複合的な要因による障害を分析できること。

・障害発生（影響判定）するその過程（シナリオ）が分析できること。

①物理要素

②制御要素

③入力

情報

SW搭載機器

④処理

⑥出力

情報

⑦機器故障

⑧情報損失

利用状況

外部環境

SWで対策できる故障

影響判断

発生可能性

に活用

アイテムの設定や故障モードの発想は

この範囲に誘導していく必要がある。

ソフトウェアFMEAへの要件

ソフトウェア品質シンポジウム2018

(8)

前提説明（故障モードの発想方法）

故障モードの作成方法： ①失敗経験の利用、②アイテムの詳細化、③誘導語の活用

アイテム名

質

量

時間

逆

他

類

無

大

小

部分

早

遅

前

後

検出機能

検出

不可

誤

検知

未

検知

部分

検知

早く

検知

遅く

検知

画像データ

デー

タなし

ノイズ

が大

部分

ノイズ

画像補正処理

不完全

補正

判定アルゴリズム

アイテムの種類（入力、処理等）や抽象度、技術者の力量を

考慮し、誘導語自体の選択もレビューできる仕組みが必要。

適用しやすいよう誘導語を増やすと

アイテムと誘導語の組合せを検討する工数が増加

③誘導語の活用

（例：

HAZOP）

②アイテムの詳細化

【過去の不具合より】

○○状態で、画像と赤外線で

異なる判定結果が入力されたため、誤判定した。

①失敗経験の利用

アイテムによって有効な誘導語が限られる。

論理（処理）の故障は

前提（状況、入力）との

関係性が破綻

(9)

ドメインにおける開発特性

業務説明（宇宙ドメインのFMEA適用例）

9 SW開発工程上のFMEA適用目的

・

SWの

役割や特徴に応じた

より固有の故障モード

・開発工程に合わせた段階的な適用

・非熟練者の参加および能力強化

SW要求分析

SW設計

SW実装

SW結合試験

SW統合試験

SW単体試験

・属人性の高い開発

（研究開発目的の製品）

・実際の環境で試験不可

運用開始後は修理不可

・開発期間が

5年以上

目的

1：

・故障シナリオの提示

・故障時に必要な

機能の抽出

目的

3：

・故障シナリオの

試験ケースの作成

目的

2：

・

SW設計のレビュー観点導出

・

SW設計から運用制約の抽出

開発業務上の

SW-FMEAへの要件

(10)

■解決策のアプローチ

・熟練者の思考経緯を可視化する。

・非熟練者の思考誘導と能力強化をする。

提案手法の概要

課題①： FMEAの分析は、

エキスパート依存性

が高い。

※例：論理の「故障」の発想は、ガイドワードでは困難等。

課題②：

FMEA結果の妥当性

をレビューすることが困難

※例：SW故障後にどのような時系列で影響を判定したのか読み取れない等。

課題③：失敗経験に関する情報が少なく、

非熟練者

への支援が困難。

※例：繰り返し適用によって特化した誘導語の整備ができない等

設計

情報

故障発想

試行錯誤

失敗経験

類似点の探索

因果推定の

論理を構築

仮説の設定

裏付けの確定

熟練者の思考プロセス

(11)

■解決策のアプローチ

・熟練者の思考経緯を可視化する。

＋

複数のビューを組合せ、自己の気づきを促進する。

・非熟練者の思考誘導と能力強化をする。

提案手法の概要

11 対策①：

特徴点の抽出を誘導

対策②：

故障モード導出経緯を

可視化（GSN）

対策③：

故障発生から影響判定を

シナリオ（ESD）で可視化

構造ビューで

特徴点の表出化

ツリービューで同時に表現

①失敗経験の利用

②アイテムの分割

③誘導語の適用

時系列ビューで

故障モードの自己検証

設計

情報

故障発想

試行錯誤

失敗経験

類似点の探索

因果推定の

論理を構築

仮説の設定

裏付けの確定

熟練者の思考プロセス

何度も繰り返す

ソフトウェア品質シンポジウム2018

(12)

提案手法の概要

ウェアラブル端末に搭載するソフトウェア外側との依存部か独立部か処理 AAA データ転送処理【特徴情報】ウェアラブル端末はスマートフォンに対してリアルタイムでデータを転送するといった特徴がある目標達成通知処理【特徴情報】目標運動量を達成したら画面に表示するといった特徴がある時刻補正処理【特徴情報】ウェアラブル端末は GPSからの情報で時刻情報を自動修正するといった特徴があるインターフェースソフトウェアへの入力かソフトウェアからの出力かソフトウェアへ入力される情報入力タイミングが一定か不定かユーザからの入力情報設定する目標運動量【特徴情報】目標運動量は何時でもユーザが変更できるといった特徴がある機器からの入力情報入力されるセンサー情報入力される心拍数情報【特徴情報】センサーから取得した心拍数は特定の範囲に収まっていない場合は破棄されるといった特徴がある【特徴情報】ウェアラブル端末は腕に巻きつけて使用するといった特徴があるソフトウェアが出力する情報単発か連続定期的に出力する情報内部で扱う情報表示する移動距離情報【懸念情報】時刻が補正され時刻が飛んだ場合、移動距離のリセットを行わない懸念がある【特徴情報】ウェアラブル端末は日付毎の移動距離を記録するため、0時になったら移動距離を内部に保存し、リセットするといった特徴がある表示する心拍情報【懸念情報】腕への巻きつけが不十分の場合、ウェアラブル端末に心拍情報が表示されない懸念がある外部に転送するデータ【懸念情報】ウェアラブル端末のデータが更新する度にスマートフォンに対してデータを転送する場合、負荷が高くなりバッテリー消費が早くなる懸念がある単発で出力する情報表示する目標達成情報【懸念情報】現在の運動量以下の目標運動量を設定した場合、目標が達成できない懸念がある

②故障モード導出

（ツリービュー）

熟練者

非熟練者

①特徴点の表出化

（構造ビュー）

③影響判定までの故障シナリオ

（時系列ビュー）

・特徴点の理解を深める仕掛け。

（特徴周辺の因果関係による気づき）

・

誘導語の設定を訓練する仕掛け。

（質・量・時間の

2軸マトリックス分析）

設計情報

不具合情報

(13)

提案手法の概説1（特徴抽出部）

13 概説：特徴抽出図によって、熟練者が捉える特徴点を抽出する。

IN：・仕様情報（設計書等）

・不具合情報

OUT：・特徴点

①物理

要素

②制御

要素

③入力

情報

⑫SW搭載機器

プラットフォーム

④処理

_⑥出力

情報

⑦機器

故障

⑧情報

損失

⑤参照情報

⑪参照情報

の阻害要因

⑨入力

阻害要因

⑩出力

阻害要因

アイテム名

特徴点の記入

＋

特徴から発生する懸念

①物理要素

概説：特徴抽出図の各位置づけにアイテム＋特徴点を記入する。

狙い：特徴点に作業要因（例：変更反映漏れ、実装ミス）や

抽象的な要因（例：

IF仕様の不整合）の除外するため。

特徴抽出図

記入イメージ

特徴抽出図

※特徴点とは、他アイテムと違い

SWの複雑さがある仕様等

実装ミスが要因ではない不具合は、通常、

複数

の特徴点がある。

例：特定状態で、誤った入力があり、想定外に処理が実行。

(14)

提案手法の詳細1（特徴抽出部）

特徴抽出図の使い方

・熟練者向け

・・・「懸念」がある「特徴点」を自由に記述する。

・非熟練者向け・・・設計情報の捉え方、特徴点抽出の偏り、

SWで対策ができる特徴点か確認。

①物理

要素

②制御

要素

③入力

情報

⑫SW搭載機器

プラットフォーム

④処理

_⑥出力

情報

⑦機器

故障

⑧情報

損失

⑤参照情報

⑪参照情報

の阻害要因

⑨入力

阻害要因

⑩出力

阻害要因

画像センサー

【特徴】

常にリアルタイムで更新

【懸念】

誤検知の懸念が高まる。

①物理要素

人

【特徴】

検知の閾値は、手動入力

【懸念】

誤入力の懸念がある。

②制御要素

④処理・振る舞い

検知処理

【特徴】複数の値域が異なるセンサーから

同じ意味のデータを収集している。

【懸念】センサー間の境界値が重複又は

行き来した場合、検知できるのか。

⑧情報損失

検知結果情報

【特徴】リアルタイム表示

【懸念】誤った表示で、人の

判断が誤り、××となる

(15)

15 提案手法の詳細2（特徴抽出部：非熟練者向け）

課題：非熟練者は、仕様

/設計情報の解釈が不足してしまう。

対策：特徴点に因果関係のある情報の収集と理解を促進する。

どんな状況で

何が

どうして

どうなる

結果こうなる

SW搭載機器

④振る舞い・処理

⑤参照情報

①物理要素

③入力情報

②制御要素

システム

運用

利用

の状況

機器や制御操作

が特定の状況で

入力情報

入力の発生原や

伝達経路等の異常

誤った

入力状態

処理が実行状況

や結果

①～⑤の位置づけのアイテムは、

SWで対応できる。

フレームワークA＋Bの例（③入力情報の場合）

フレームワークA：特徴抽出図

フレームワークB：因果関係の誘導

記入例

人を検知してい

る状況下で

画像データ

センサーに

ノイズが発生し

ノイズがある

画像データ

検知処理が遅

れる。

位置づけ毎のガイド

ソフトウェア品質シンポジウム2018

(16)

提案手法の詳細3（特徴抽出部：非熟練者向け）

課題：非熟練者は、誘導語があると、アイテム×誘導語の範囲のみに集中。

対策：単なる言葉の組合せではなく、「意味」の組合せで考えるよう誘導する。

アイテム名

【特徴】 ×××

【懸念】 ○○○

時間変化

質の変化

量の変化

アイテムが

早過ぎ

アイテムが

遅すぎ

質×時間

量×時間

早過ぎ

遅過ぎ

アイテムなし

アイテム逆

早過ぎ

遅過ぎ

過少

過剰

2軸マトリックス分析

発想した

SW故障

発想した

SW故障

質×量

過少

過剰

なし

逆

発想した

SW故障

視点を変えて誤り状態を

発想する訓練をする。

視点毎の誤り状態の組合せ

で新たな故障モードが

発想できないか訓練する。

特徴点を参照し

各「質、量、時間」の視点

アイテムの誤り状態を

「対立概念」で定義する

SW故障の発想ポイント

・複合条件

・論理（処理）の前提破綻

・時間変化による想定外

誤り状態A

対立概念

で定義

参照

誘

導

(17)

提案手法の概要

17 ②故障モード導出

（ツリービュー）

熟練者

非熟練者

①特徴点の表出化

（構造ビュー）

③影響判定までの故障シナリオ

（時系列ビュー）

設計情報

不具合情報

・特徴点の理解を深める仕掛け。

（特徴周辺の因果関係による気づき）

・誘導語の設定を訓練する仕掛け。

（質・量・時間の

2軸マトリックス分析）

ソフトウェア品質シンポジウム2018

(18)

提案手法の概説2（故障発想部）

概説：アイテムの具体化、特徴点、誘導語等を用いて故障モードを作成する。

IN：・設計情報、特徴点

・誘導語

OUT：

・故障モード

概説：故障モードの導出方法①～③を

GSNで

ツリービューとして同時に表現

アイテム

分割視点

SWアイテム

【特徴】

XXXXの

特徴がある

アイテム

【懸念】

YYYY

が懸念ある

①失敗経験の利用

②アイテムの

具体化・詳細化

誘導語

③誘導語の適用

GSNで可視化

参考：

GSNとは、ゴール構造化記法

ゴール

ストラテジー

エビデンス

コンテキスト

サブゴール

コンテキスト

エビデンス

※ロジックツリーの拡張記法

(19)

19 提案手法の概説2（故障発想部）

【特徴】

機能の利用シーン

検知機能

未検知/誤検知

に分ける。

アクチュエータが動作し

ていないにも関わらず、

誤って検知する

アクチュエータの

動作を検知できない

【特徴】

機能の仕様するセンサー情報

信号誤りを継続、瞬間、

過渡状態（判定中）に分ける

【懸念】

安全状態と誤認識して、

緊急停止しない懸念がある。

××利用シーンで

信号の継続的な異常で

アクチュエータの

危険状態を未検知する。

信号の瞬間的な異常で

アクチュエータの

危険状態を未検知する。

判定中に信号の異常で

アクチュエータの

危険状態を未検知する。

【懸念】

未検知の原因候補や誤検知の影響

【特徴】

検知処理のポイント

①上位アイテムの

特徴点を下位へ継承

＝論理の前提破綻

を誘導できる。

②アイテムの分割視点

や誘導語で網羅を確保

③アイテムを具体化した

根拠を明記できる。

④特徴点が追加された場合

ツリー展開することで

アイテムを具体化していく

故障モードの導出経緯をツリービューとして同時に表現するメリット

・熟練者向け

･･･立場が異なる人がレビューすることでさらに特徴点を収集できる。

・非熟練者向け･･･故障モードが発想できていない原因とその改善点が明確になる。

例：特徴点の不足、アイテムの詳細化不足、誘導語の選択ミス等の改善点

(20)

提案手法の概説2（故障発想部）

・製品だけでなく、環境や利用者なども分析対象とすること。

→

特徴抽出部で論理の前提（状況、物理、制御）を不具合やエキスパートから収集済

・複合的な要因による障害を分析できること。

→ 下記の方法で誘導

ソフトウェアFMEAへの要件

②アイテムのツリー構造を決める。

①特徴点からアイテム候補を決める。

No. 特徴情報

懸念情報

アイテム名

1 SW製品は、○○と

いう特徴がある。

システムが、××と

いう懸念がある。

修飾語句＋名

詞

最上位の

要素名

1層目

視点

1層目の

アイテム名

2層目

視点

2層目の

アイテム名

アイテムA

分割視点1

アイテムB

誘導語

具体アイテム1

具体アイテム2

故障モード導出経緯（GSN）

上位アイテム（例：システム）

アイテム

A

アイテム

B

同位・包含関係

の確保

ツールで（GSN）に変換する。

→ 複数の特徴点が上位下位で継承される。

→ 論理の前提破綻がレビュー可能となる。

(21)

提案手法の概要

21 ②故障モード導出

（ツリービュー）

熟練者

非熟練者

①特徴点の表出化

（構造ビュー）

③影響判定までの故障シナリオ

（時系列ビュー）

設計情報

不具合情報

・特徴点の理解を深める仕掛け。

（特徴周辺の因果関係による気づき）

・誘導語の設定を訓練する仕掛け。

（質・量・時間の

2軸マトリックス分析）

ソフトウェア品質シンポジウム2018

(22)

提案手法の概説3（故障モード検証部）

概説：発想した故障モードが

SWの開発に効果的か確認する。

IN：設計情報、故障モード

ESDで可視化

OUT：故障シナリオ

＜

ESDの適用イメージ＞

特定状況下で故障発生後、

利用者やシステムへの影響を

ESDで時系列ビューで表現する

。

開始

分岐

イベント1

分岐

イベント2

終了

イベントB

イベントA

影響小

影響大

Yes

No

参考：

ESDとは、イベントシーケンス図のこと。

Yes

開始

正常イベントA

正常イベントB

正常終了

異常イベント

SW異常対処

システム対処

運用対処

影響度小

故障モードと原因

直接影響や対策

影響判定

(23)

23 提案手法の概説3（故障モード検証部）

・熟練者向け

･･･故障発生時の状況やそのメカニズムをシステムや運用担当者へ提示

→

SW対策の限界や運用制約、FMEA効果を合意形成できる。

・非熟練者向け･･･故障モードが

抽象的過ぎる

と、シナリオが描けない。

故障モードによっては、そもそも

SWで対策できない。

例：××入力の誤り、機能の停止、パラメータ設定誤り

→ アイテムの分割不足、特徴点の不足等の故障モードが修正可。

開始

正常イベントA

正常イベントB

正常終了

異常イベントX

対処なし

システム対処

影響度大

影響度小

SW異常対処

システム対処

運用対処AY

運用対処AX

FMEA実施前

FMEA実施後

①故障モードをさらに具体化し、

分岐イベントとする。

②：影響判定までの時系列推移を表現

→システムや利用者へどのような影響がある

と判断したのかトレースが可能。

③：FMEAの効果を明示

（修正されたシナリオ）

④：故障発生後の後続のシステム

や運用への対応を表現

故障の原因・対策を、時系列ビューで表現するメリット

ソフトウェア品質シンポジウム2018

(24)

提案手法の概説3（故障モード検証部）

＜提案手法＞

開始

正常イベントA

正常イベントB

正常終了

ネットワーク遅延により

画像データの入力タイ

ミングが遅れる

影響度小

検知機能が有効で

ないことを通知する

システムではなく、

人の目視で検知する

アイテム名

故障モード

故障原因

故障の影響

対策内容

対策効果

画像データ

遅過ぎるタイミング

ネットワークの

遅延

検知処理の実行が

遅くなり、システム

の認識が遅れる。

検知機能が有効

でないことを通知

する。

システムではなく、

人の目視で検知

できる。

検知処理の実行が遅くなり、

システムの認識が遅れる。

影響度大

FMEA実施前

FMEA実施後

＜従来手法＞

SW対処

SW故障

運用対処

影響度大

複合要因も表現可

(25)

提案手法の実装概要

25 FMEAの適用工程

提案手法の適用工程

No. 特徴情報

懸念情報

アイテム名

1 SW製品は、○○とい

う特徴がある。

システムが、××とい

う懸念がある。

具体アイテム名

最上位の

要素名

1層目

視点

1層目の

要素名

2層目

視点

2層目の

要素名

3層目

視点

抽象名詞

視点1

名詞3

視点11

具体名詞1

具体名詞2

特徴情報

懸念情報

特徴抽出図の位置づけ

故障発生

SW対処

運用対処

影響判定

ツールによる

自動変換

正常イベント

アイテム

影響の定義

特徴点の記入

シナリオと影響の定義

特徴点からアイテムの展開をツリー構造化

故障発生前後のシナリオの記入

特徴点のレビュー

故障モード導出の確認

影響判定を時系列で確認

方針やアイテム

を決める。

故障モードを

作成する

影響を解析する

対策を検討する。

分析やモデリングコストを削減するツールを用意

※特許出願中（特願

2018-121252）

ライセンス提供の問い合わせ先：

umeda.hiroki@jaxa.jp

EXCELの

アドイン

(26)

提案手法の有効性確認の方法

■有効性確認方法：

技術者のプロファイル

・エキスパート（製品開発が

10年以上）

・

FMEA適用経験の有無

・評価指標

1：故障モード数

・評価指標

2：故障シナリオ数

（効率、効果）

■確認条件：

3つの異なる開発組織で、実際の開発と並行して実施。

エキスパート

開発経験10年以上

FMEA

習熟

①：熟練者

③：FMEA

エキスパート

②：製品

エキスパート

④：非熟練者

FMEA

未経験

No

手法実施者

比較対象（評価指標1）

比較対象（評価指標2）

1 ④非熟練者

製品エキスパートA

（不具合分析と経験から）

故障モードに対する

故障シナリオの作成効率

2 ②製品

エキスパート

誘導語による発想

（効果）

影響度別の故障シナリオ数

3 ①熟練者

従来から実施している方法

（不具合分析と経験から）

1故障モード当たりのFMEA適用効率

（仕様修正件数）

(27)

有効性確認の結果（No1：製品エキスパートと非熟練者）

27

0

10

20

30

40

50

60

70

80 企業A

非熟練者

企業B

製品エキスパートB

企業C

熟練者

従来手法

提案手法

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0 製品エキスパートA

非熟練者

％

理由

評価指標

1：故障モードの発想数

（製品エキスパート

A）

（非熟練者）

・故障モード数は、非熟練者（提案手法）が

2 倍

・故障シナリオの作成効率は、

製品エキスパートが

10％以上高い。

故障モードから故障シナリオを作成ができた割合

非熟練者は、特徴点の抜けがないか、

GSN上で論理網羅を重視したため、

対象システムであり得ない

SW故障を発想

(28)

提案手法の妥当性確認の結果（No2：製品エキスパート）

0

10

20

30

40

50

60

70

80 非熟練者

製品エキスパートB

熟練者

従来手法

提案手法

考察

影響度大のシナリオ数が

提案手法で

60％増加

0

20

40

60

80

100

120

140

160 影響度大

影響度中

影響度小

従来手法

提案手法

（誘導語）

影響度別故障シナリオ数

_{従来手法（誘導語）で}

「アルゴリズム」に対する

故障の発想ができない。

評価指標

1：故障モードの発想数

(29)

提案手法の妥当性確認の結果（No3：熟練者）

29

0

10

20

30

40

50

60

70

80 非熟練者

製品エキスパートB

熟練者

従来手法

提案手法

考察

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7 従来手法

提案手法

1 故障モードあたりのFEMA 適用時間

評価指標

1：故障モードの発想数

熟練者の考えていた故障モードが

従来より

4倍以上

、可視化

・FMEA適用時間は、ツール効果により

従来と同等。

・仕様修正や制約抽出は、約50％追加

(30)

発展①：開発工程に合わせて

GSNやESD モデルを

繰り返し更新する仕組み

→ 新たにアイテムや特徴点が追加された時の効率的な分析。

発展②：エキスパートの思考経緯を含めた故障モードの再利用方法

→ エキスパートが整理するのではく、非熟練者の能力向上の一環。

発展③：故障の発生後や非定常状態の故障シナリオを分析する「複合異常」

→ 影響度が小や中と判定した故障シナリオ時に、軽微な故障で

影響度が大となる故障シナリオが存在していないか。

本発表のまとめ

（１）提案手法は、

FMEA未経験者の故障発想を支援している。

（２）提案手法は、熟練者に取って既存のコストと同等で分析できる。

（３）提案手法は、熟練者からの技術継承を促進する可能性がある。

目次 背景説明 ( 業務説明 前提知識等 ) 提案手法の概要 提案手法の有効性確認結果 まとめ 2

GSN 及びESD モデルを用いたソフトウェア

FMEA の提案

Failure mode and effect analysis using Goal Structuring Notation

and Event Sequence Diagram for Software

国立研究開発法人 宇宙航空研究開発機構

研究開発部門 第三研究ユニット

○梅田浩貴 波平晃佑 祖川和弘 植田泰士 片平真史

e-mail：umeda.hiroki@jaxa.jp

目次



背景説明（業務説明、前提知識等）



提案手法の概要



提案手法の有効性確認結果

宇宙機搭載ソフトウェアの種類と特徴



システムの動作環境が過酷で、ソフトウェアの誤動作は損失大。



想定外が発生しやすい。 （放射線によるメモリ化けが発生等）



ロケットや衛星の損失は、環境や人命の喪失につながる。



故障の対応や復帰も難易度が高い。（地球との通信は、特定期間のみ）



部品交換はできず、実際の利用環境の試験もできない。



ハードウェアは、基本的に予備（冗長系）を搭載している。



ソフトウェアは、安全解析を含めた設計検証や網羅的な試験が重要である。



開発数や機会が少なく、研究実証向けの製品。



5年以上の長い開発期間、少量多品種である。

3



宇宙ステーション



人工衛星



ロケット



地上管制システム

本発表の概要

課題①： FMEAの分析は、

エキスパート依存性が高い。

※例：ソフトウェア製品の修正につながる「故障」が発想が難しい等。

課題②：

FMEA結果をレビュー

することが困難。

※例：SW故障後にどのような時系列で影響を判定したのか読み取れない等。

課題③： 失敗経験に関する情報が少なく、非熟練者への支援が困難。

※例：繰り返し適用によって特化した誘導語の整備ができない等

（１） 提案手法は、FMEA未経験者の故障発想を支援している。

（２） 提案手法は、熟練者に取って既存のコストと同等で分析できる。

（３） 提案手法は、熟練者からの技術継承を促進する可能性がある。

研究実証を目的とし、開発期間が長く、実際の環境で試験できない「宇宙機」の

ソフトウェア開発で、

FMEA（故障モードと影響解析）を適用した場合、下記の課題があった。

結論

前提説明（故障の概念）

5

・ソフトウェアは、経年劣化しない。

・ソフトウェアは、見えない。

・ソフトウェアは、属人的に作られる。

故障

原因

ストレス

システムが

故障状態

システムが

動作状態

故障

メカニズム

故障

事象

人・機器が「故障

※

1

目次背景説明 ( 業務説明前提知識等 ) 提案手法の概要提案手法の有効性確認結果まとめ 2

国立研究開発法人宇宙航空研究開発機構

研究開発部門第三研究ユニット

○梅田浩貴波平晃佑祖川和弘植田泰士片平真史

想定外が発生しやすい。（放射線によるメモリ化けが発生等）

課題③：失敗経験に関する情報が少なく、非熟練者への支援が困難。

（１）提案手法は、FMEA未経験者の故障発想を支援している。

（２）提案手法は、熟練者に取って既存のコストと同等で分析できる。

（３）提案手法は、熟練者からの技術継承を促進する可能性がある。

_事象