宇宙航空研究開発機構(JAXA)における

信頼性向上とその対応策信頼性向上とその対応策（SEC特別セミナー）

アーキテクチャ指向エンジニアリングと形式手法

宇宙航空研究開発機構（JAXA）石浜 直樹

目次目次

宇宙航空 究 機構 概1. 宇宙航空研究開発機構(JAXA)の概要

2. システム開発における安全・高信頼性の必要性と背景背景

3 安全 高信頼性システム開発の具体的アプロ チ3. 安全・高信頼性システム開発の具体的アプローチ

SEC特別セミナー＠2011/7/4-5 2

1．宇宙航空研究開発機構(JAXA)の概要宇宙航空研究開発機構(J )の概要

SEC特別セミナー＠2011/7/4-5 3

JAXAの概要

「空へ挑み、宇宙を拓く」

JAXAの概要

これまで培った技術を結集させ

空 挑み、宇宙を拓く」フロンティアに「挑戦」することを通じ、社会・人類の可能性を「開拓」する

これまで培った技術を結集させ、

世界最高の信頼性を持つ宇宙輸送システムを実現させます。1宇宙技術を利用し、地球環境問題に貢献します。2人々が安心して暮らすことができ人々が安心して暮らすことができ、

さらにその暮らしを豊かにする、生活に密着した宇宙技術を育成します。

3世界最高水準の天文衛星観測と、月・惑星探査を推進し、人類の知の資産拡大に貢献します。4国産ジェットエンジン技術の研究・実証を行い、国産航空機開発に貢献します。5

4SEC特別セミナー＠2011/7/4-5

JAXAの開発する主な宇宙機JAXAの開発する主な宇宙機

5SEC特別セミナー＠2011/7/4-5

宇宙分野のソフトウェアの種類と特徴宇宙分野のソフトウェアの種類と特徴

人工衛星姿勢制御系 データ処理系 ミッション系 ス姿勢制御系、データ処理系、ミッション系、スタートラッカー／GPSRなどセンサー系など組込み系が中心

Fail Safe → Fail Operative

FDIR: Failure Detection Isolation and RecoveryFDIR: Failure Detection Isolation and Recovery

最近は書換可能のものもある

アセンブラ、C言語

再利用／シリーズ化

放射線 影響放射線の影響

ロケット宇宙ステーション航法誘導制御系等

高信頼性／多数決

アセンブラ、C言語

宇宙ステ ション管制システム、マニュピュレータ、実験装置など膨大な数のソフトウエア

高い安全要求（２故障でも安全に！）

コマンド データ 処理の独立性ハードリアルタイム

地上管制システム

管制システム等

安全性

コマンド、データ、処理の独立性

複雑で膨大なFDIR

システム構成にクルーが入る

Ada、C言語

6

安全性

SEC特別セミナー＠2011/7/4-5

一般の組込みソフトウエアとの共通点般の組込みソフトウエアとの共通点

宇宙用ソフトウエアの置かれる状況

• 組み込みソフトとの共通課題

– 上流工程の不確定さ（要求元は？決まらない？）

– 機能要求の増加と複雑化による検証の限界機能要求の増加と複雑化による検証の限界

– ハードウエア主体の文化

– 開発の外注化の加速

• 宇宙特有の問題• 宇宙特有の問題

– 容易に修理できない

– 開発期間

製品が単発

高信頼性ソフトウエアのための戦略的開発・検証計画術

各組 各 確 検 責 割– 製品が単発 各組織、各担当に明確な開発・検証責任の割付インプロセスによる検証V&V （検証及び妥当性確認）による検証IV&V（独立検証及び妥当性確認）による検証IV&V（独立検証及び妥当性確認）による検証

開発資源の適切な配分のためのランク付け

ハザード解析に基づく重要度の識別

不具合情報などをもとにした重要部位の識別

SEC特別セミナー＠2011/7/4-5 7

不具合情報などをもとにした重要部位の識別

宇宙機搭載ソフトウエアの特徴と信頼性向上対策信頼性向上対策

宇宙機搭載ソフトウエア 地上ソフトウエア

メンテナンスが困難短時間での対処が必須（高度な安全性・信頼性）環境条件 想定が困難

状況製品実物に対し実際の使用環境で不具合・故障のあぶり出しが可能

環境条件の想定が困難

ソフトウエアで自己診断・自動回復対策 人手による対処が可能自己診断 自動回復自動化・自律化（ソフトウエアの50%以上）

対策

可能な限り故障 不具合を想定して

人手による対処が可能

可能な限り故障・不具合を想定して必要機能を設けるが網羅は不可能

最終試験検証で不具合・ 製品出荷前の徹底的な最終試験検証網羅することは不可能故障の

発見 最終試験段階で不具合・故障のあぶり出しは困難

製品 荷前 徹 最終試験検証で高い網羅率を実現可能

出荷前であれば不具合・故障を修理できる

8

“しっかり作る”ソフトウエアプロセス改善

“しっかりチェックする”ソフトウエアIV&V＊１

宇宙での信頼性向上対策 *1 :IV&V：

独立検証及び有効性確認

信頼性向上と安全性確保の考え方信頼性向上と安全性確保の考え方

• 信頼性向上は、安全性確保に直結するのか信頼性向上は、安全性確保に直結するのか– 例、冗長系設計により信頼度は向上するが。。

• 安全性は、信頼性と異なる視点システム設計が重要

• 機能安全 Computer-based control system

ち んと作 ているだけでは安全なシステムにはならない

が重要

ちゃんと作っているだけでは安全なシステムにはならない

国際規格・認証だけでは安全なシステムにはならない国際規格・認証だけでは安全なシステムにはならない

信頼性信頼性 安全性安全性

SEC特別セミナー＠2011/7/4-5 9

品質保証

2 システム開発における安全 高信頼性の2．システム開発における安全・高信頼性の

必要性と背景必要性 背景

10SEC特別セミナー＠2011/7/4-5

システムの安全・高信頼性の必要性システムの安全 高信頼性の必要性

宇宙 社会 人類 可能性を「開拓• 宇宙への社会・人類の可能性を「開拓」

• 宇宙産業の成長

• 宇宙ステーション

– 人命にかかわる 過去に学ぶ– 国際協力プロジェクト

• 人工衛星

– 重要な資産 リスクを把握– 重要な資産

– 安全・安心な生活

• ロケット

– 重要な資産、ペイロードの喪失

– 射場の安全

SEC特別セミナー＠2011/7/4-5 11

かぐや（SELENE）かぐや（SELENE）

SEC特別セミナー＠2011/7/4-5 12

HTVの宇宙ステーションへのドッキングHTVの宇宙ステ ション のドッキング

宇宙ステーションへの接近軌道は、オフセットタ ゲットされているが 予期しない噴射などでターゲットされているが、予期しない噴射などで衝突軌道に入ることが考えられる。

SEC特別セミナー＠2011/7/4-5 13

背景：過去の事故から学ぶ背景：過去の事故から学ぶ

• 宇宙機のソフトウエア開発に大きい影響を与えた事故宇宙機のソフトウエア開発に大きい影響を与えた事故– NASA スペースシャトルチャレンジャー事故 → IV&Vの強化

– 欧州 アリアンV事故 → ソフトウエア設計・検証方法の見直し

• 事故は直接的な原因だけではない

• 技術者モラル、安全文化の崩壊

• チャレンジャー事故に学ぶべきこと

– 直接原因はソフトウエアではなかったが、その安全文化の崩壊・技術者モラル低下にメスを入れるため、各領域において英知を結集して分析・勧告を実施

– An Assessment of Space Shuttle Flight Software DevelopmentAn Assessment of Space Shuttle Flight Software Development Process, 1993 議長： Nancy G. Leveson

SEC特別セミナー＠2011/7/4-5 14

チャレンジャー事故後の勧告事項チャレンジャ 事故後の勧告事項

勧告１： 開発及びV&Vプロセスの統一的な適用

勧告２： V&Vの想定外のシナリオの追加

勧告３： システムレベルの問題考慮の強化（資金供給）

勧告４： IV&Vの責任を開発及び運用者から独立勧告４： IV&Vの責任を開発及び運用者から独立

勧告５： ソフトウエア安全基準の確立・適用

勧告６： 安全基準の適用を監視するHQの開発・保証組織

勧告 安全確保のための計画立案勧告７： 安全確保のための計画立案

勧告８； ソフトウエアハザード解析の実施

勧告９： ソフトウエア安全の専門家の育成と配置

勧告１０：安全性の報告・管理の強化

勧告１１：安全性認証委員会の設置

勧告１２：ソフトウエア開発プロセスの各組織の責任分担明確化勧告１２：ソフトウエア開発プロセスの各組織の責任分担明確化

・・・ 他、全２２件

安全文化の形骸化防止、モラルの維持 ⇒ 第三者による評価・監視

SEC特別セミナー＠2011/7/4-5 15

ソフトウエア安全の確保 ⇒ 統一プロセス・ハザード解析などの新たな導入

3．安全・高信頼性ソフトウエアシステム開発の具体的アプローチの具体的ア チ

16SEC特別セミナー＠2011/7/4-5

システムレベルからのトップダウンアプローチシ テ ル らのトッ ダウンア チ

17SEC特別セミナー＠2011/7/4-5

事故を回避するために事故を回避するために

安全設計 審査プロセス安全設計・審査プロセス

STEP1 ハザードを見つける

STEP2 原因を突き止めるSTEP2 原因を突き止める

STEP3 対策を考える

対策通り く振舞うか検証する

安全がシステム設計を決める

STEP4 対策通り正しく振舞うか検証する

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

安全技術要求

安全安全

SEC特別セミナー＠2011/7/4-5 18

安全審査プロセス安全審査プロセス

システムレベル

ソフトウエアレベル システム全体

安全審査プロセス

開発プロセス

フェーズ０

レベル レベル

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

による分析）

関連するソフトウエアの識別概念設計

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

システムFTA/

プロセスプロセス

フェーズ１

システムFTAなどによる原因

と制御方法の識別

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

制御方法）箇所の識別基本設計

テム /ソフトウエアFTA

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

ハードソフト

適切な

フェーズ２

フ ズ

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

設計結果 反映／

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

の適用

設計結果 反映／

詳細設計

ソフトウエア動作を識別

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

ソフト人（運用）

な配分

フェーズ３

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

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

試験後

安全性検証方法の設定

検証結果の確認

SEC特別セミナー＠2011/7/4-5 19

事故を回避するためにSTEP1 ザ ドを見 けるSTEP1：ハザードを見つける

• 開発している製品がどうなると事故になるのか？

火災、感電、爆発、衝突、挟み込み….etc

• 製品領域毎のGeneric ハザードを蓄積

• 影響度は？– 死亡、大けが、軽微なけが

– 製品、財産の喪失。金融システム

• 製品の利用者・利用環境は• 製品の利用者・利用環境は、– 教育された特別な人

– 不特定多数

SEC特別セミナー＠2011/7/4-5 20

事故を回避するためにSTEP2 原因を突き止めるSTEP2：原因を突き止める

などを 原 を分析 そ• FTAなどを用いて原因を分析、そして…

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

直接原因となる制御系直接原因となる制御系機能そのものが危険な事象に影響する機能機能そのものが危険な事象に影響する機能ケケ ））機能 動作が人を殺す機能 動作が人を殺す 負傷させ負傷させケース１ケース１））機能不動作が人を殺す機能不動作が人を殺す、、負傷させる負傷させる・・必要なときに動作しない必要なときに動作しない・・動作中に不意に止まる動作中に不意に止まる

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

停止しなければならない時に止まらない停止しなければならない時に止まらない・・停止しなければならない時に止まらない停止しなければならない時に止まらない・・動きだす時に想定外の動きをする動きだす時に想定外の動きをする

安全監視系安全監視系

SEC特別セミナー＠2011/7/4-5 21

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

事故を回避するためにSTEP3：対策を考えるSTEP3：対策を考える

①① ハザードの除去

ハザード源又はハザードを伴う使用を除去する

②② ハザードの最小化設計

ザ ド 発生を防 するため 被害 大きさ ザ ド ベ 応ハザードの発生を防止するために、被害の大きさ（ハザードのレベル）に応

じて、原因となる故障要因に対して以下の制御を行う

①故障許容設計①故障許容設計

②リスク最小化設計

③③ 安全装置

設計上除去できないハザードは、安全装置によりハザードの影響を許容 レ

ベルまで低減する

④④ 警告警報装置④④ 警告警報装置

ハザードの発生をタイムリーに検知して、適切な警告警報を発信する

⑤⑤ 特別な手順⑤⑤ 特別な手順

SEC特別セミナー＠2011/7/4-5 22

事故を回避するためにSTEP4 対策通り正しく振舞うかSTEP4：対策通り正しく振舞うか

如何 検証す 安全性検証• 如何に検証するか（安全性検証）

– 基本は実試験（デモンストレーション）

– 異常故障を模擬できない場合は、解析・Inspection

• 安全性検証エビデンス

SEC特別セミナー＠2011/7/4-5 23

トウ アレベ でのアプ チソフトウエアレベルでのアプローチ～Formal model & Model checkingo a ode & ode c ec g

24SEC特別セミナー＠2011/7/4-5

安全性・信頼性確保のための取組み安全性 信頼性確保のための取組み

宇宙機ソフトウエア開発 健康維持

• 基本的動作(標準等)

– 品質プログラム標準

技術標準• 基礎体力・健康維持

– 技術標準

– 経験則を含めた教育

• プロセス改善プ セス改善

– 各立場での改善サイクル

– メトリクスによる可視化• 自己診断

• 独立検証及び有効性確認

(IV&V)

専 的観点

• 専門家による検査

– 専門的観点のチェック

• 新規技術の研究

SEC特別セミナー＠2011/7/4-5 25

– 高信頼性RTOS検証

– 高信頼性ソフトウエア部品

• 新規装置を使った検査

ソフトウエアIV&Vの概要ソフトウエアIV&Vの概要【IV&V】

• ソフトウエア製品の正しさ及び品質をソフトウエアライフサイクルを通して評価するためのシステムエンジニアリングプロセスステムエンジニアリングプロセス

ソフトウエアIV&Vシステム開発

開発側組織 開発側とは独立した組織

開発中間成果物

• 資金的、組織的、技術的独立性が必須

• IV&V活動は、ソフトウエアの開発工程（要

システム要求

ソフトウエア開発

検証システム仕様書

要求

求設定～試験）のすべての段階で実施

• 開発側が作成するソフトウエア中間成果物（文書、データ）を各開発工程において解析・評価

有効性確認

要求 解析 評価ソフトウエア要求

シフトウエア設計ソフトウエアV&V

要求仕様書

設計書

解析 評価

• 作業は以下の２つの観点からなる。

Verification(検証)

要求仕様書

設計書

解析・評価

解析 評価

解析・評価

解析・評価

コーディング

開発組織の中の独立部門による

コード

手順書・

各段階の開発中間成果物が、前の工程

からの入力情報に照らし、正しく作られていることを確認

Validation(有効性確認)

コード

手順書

解析・評価

解析・評価

解析・評価

解析・評価ソフトウエア試験

システム試験

手順書記録

手順書・記録

Validation(有効性確認)各段階の開発中間成果物が、JAXAが期待する通りに作られていることを確認

JAXAでは現在約１００種のIV&V技術を

手順書・記録 解析・評価

解析 評価

解析・評価

26打ち上げ、運用 運用手順

• JAXAでは現在約１００種のIV&V技術を用いて評価作業を実施中

解析・評価

SEC特別セミナー＠2011/7/4-5

開発プロセスに沿ったIV&V活動開発プロセスに沿ったIV&V活動

事故分析組織的 / 共通原因分析

事故分析

類似問題の検索

テスト結果レビュー

設計根拠の評価と構築

COTS/再利用ソフトウェア評価検証のカバレッジ評価

システム解析

トレーサビリティ・等価性解析

要求分析 デザイン コーディング テスト

運用

構成管理検査

静的解析*2

ツールチェック

テストケース生成

一貫性 / 完全性 解析

SpecTRM model check

静的解析2

*1:等価性チェック

テストケース生成

FDIR / オフノミナルノミナル 妥当性確認

タイミ グ解析

FDIRデザイン評価

リバースエンジニアリング

システムモデル *1 要求モデル *1 詳細設計モデル

*1

リーチャビリティ解析

タイミング解析

ディビエーション解析 *2:コード構造エラーメモリーリークエラーハンドリングフォールトトレランス無限ループコーディング規約違反

運用モデル

インターフェースの一貫性

SEC特別セミナー＠2011/7/4-5 27リスク分析 (システム/ソフトウェア FTA) コード、テスト、運用のトラッキング

耐２故障システム(Safe Mode) ソフトウェア多様性解析他コンポーネント

選択的ソフトウェアIV&V手法選択的ソフトウェアIV&V手法

わずかな作業規模でも効果をあげることができるIV&V

選択（達成度）Full set 開発フェーズ

わずかな作業規模でも効果をあげることができるIV&V

完全性・一貫性

選択（達成度）

Light Weight

インタフェース整合性

設計網羅性・タイミング

検証網羅性

リスク解析・ロバスト性

整合性・トレーサビリティ

開発プロセス・品質

SEC特別セミナー＠2011/7/4-5 28

開発工程とモデル検査の流れ

サブシステム基本設計

サブシステム仕様

システムライフサイクル

サブシステムモデルSpecTRM

モデル検査用モデル入力用 検査・解析

自然言語モデル

直接入力＊１

ソフトウエア要求分析・定義

ソフトウエア要求仕様(#)

ソフトウエアライフサイクル

SpecTRM

要求モデルSpecTRM

自然言語モデル

自然言語モデル

直接入力

活用 等価性検証

＊１

UPPAAL/Times

ソフトウエア要求仕様(#)

ソフトウエア基本設計

SpecTRM

基本設計モデル

フローモデル

自然言語モデル

直接入力

SPIN活用 等価性検証

＊１

#は段階的に実施される場合がある

UPPAAL/Times

ソ ウ ア基本設計

基本設計仕様(#)

ソフトウエア詳細設計

基本設計モデルSpecTRM

自然言語モデル

直接入力

活用 等価性検証SPINフローモデル

詳細設計仕様(#)

製造・単体試験

コ ド(#)

詳細設計モデルSpecTRMフローモデル

直接入力＊１

コード(#)

ソフトウエア試験

試験ケース・試験結果

＊１：一貫性解析完全性解析到達性解析ディビエーション解析インタフェース整合性

フロー

モデルベーステストに基づくテストケース生成

29

サブシステム試験

試験ケース・試験結果

インタフェ ス整合性

モデルベーステストモデルベーステストに基づくテストケース生成SEC特別セミナー＠2011/7/4-5

複数のモデル複数 デル

• SpecTRMモデル有限状態遷移モデル

Component <ABC_Control_Task>//Error Handling– 有限状態遷移モデル

– モード(Mode)や状態変数(State Value)が、どのような条件で遷移するのかを定義する状態遷移マトリクステーブル作成

– モードや状態変数の遷移条件の一貫性の確認（一貫性解析）、および遷移条件 網羅性 確認（完全性解析）が 能

//Error Handling[5.1]

ABC_CSC_task_name is ABC_Control_TaskAnd ABC_Control_Task_step is Error_Handling_AAnd Message_type is STOP_COMMANDOr Message_type is CLEAR_COMMANDThen Return value becomes INVALIDよび遷移条件の網羅性の確認（完全性解析）が可能

• 自然言語モデル– 「自然言語モデル」は、仕様書の記述をそのまま自然言語に近い

形でモデリング可能な中間モデル

Then Return_value becomes INVALIDABC_Control_Task_step becomes End_step

– 自作のコンバータによってSpecTRMモデルを自動生成

– 仕様書の項番通りに作成できるので、状態変数の探索に要する時間を削ると同時に、抜けのないモデリングが可能

– 入力作業を複数の人員によって実施する場合 項目ごとに分担で

Component:ABC

:State Value

_ABC_System_Mode= Standby– 入力作業を複数の人員によって実施する場合、項目ごとに分担で

き、作業効率が向上

• フローチャートモデル– 設計仕様は、フローチャートで記述されている場合が多い

= Standby{

Transit_Allow_flag ==True TABC_System_Mode==Initial TMode_transit_cmd ==Standby T

}= Operation

– 「フローチャートモデル」は、仕様書のフローチャートを市販のツールを用いて図のまま表現した中間モデル

– コンバータによってSpecTRMモデルを自動生成

– モデリングにおいては、フローチャート全体の中から、モード遷移

= Operation{

Transit_Allow_flag ==True T TABC_System_Mode==Standby T FABC_System_Mode==Initial F TMode_transit_cmd ==Operation T TAuto transit flag True F Tリ グ 、 体 中 、 遷移

やフラグ設定等、処理の流れを左右する特に重要な箇所、あるいは重要なグローバル変数等を識別

SEC特別セミナー＠2011/7/4-5 30

Auto_transit_flag ==True F T}

SpecTRMを中心としたJAXAでの導入事例導入事例

モデル化 モデル検査要求仕様モデル

(SpecTRM*1, Uppaal)要求仕様書

モデル化

自然言語入力モデル入力ツール

モデル検査(静的検査)

完全性一貫性到達性

完全性一貫性到達性

設計仕様モデル

インタフェース管理文書ハザード解析結果 フローダイアグラム

入力ツール

到達性到達性

等価性等価性

SPIN SMVSPIN SMVモデル(SpecTRM, Uppaal)

設計仕様書インタフェース管理文書

UppaalSPIN. SMVSPIN. SMV

問題点問題点

ハザード解析結果 実行可能コード

シミュレーション（動的検査）

運用モデル（動的検査）

ロバスト性

動作分析運用手順書運用シナリオ

一貫性タスクモデルツール 試験ケース提案

31

*1:SpecTRM: Specification Tools and Requirements Methodology 問題点

SEC特別セミナー＠2011/7/4-5

JAXA IV&Vにおけるモデル化・モデル検査の例Model Chain例

AA Mode( )

ツールによる解析・変換

人手による入力

一貫性解析完全性解析

静的検査The SYSTEM XYZ shall (REQ‐01001) transfer mode from every mode without Initialization Mode or B Mode to AA Mode by command.

SpecTRMモデル

完全性解析到達性解析開発側からのInput

要求仕様書設計仕様書 自然言語入力モデル

動的検査

簡易C コード設計フロー入力モデル

SPIN モデル

タイミング解析

SPIN モデル

UPPAAL

シミュレーション•実行されないフローをチェック

動的検査

静的検査

32

UPPAALを用いた

モデル検査 UPPALL モデル XML(UPPAAL)モデル

•変数の初期値設定チェック•条件分岐の一貫性•ゼロ除算の可能性 等SEC特別セミナー＠2011/7/4-5

上流工程に有効なモデル検査技術上流工程に有効なモデル検査技術

• レビューの補完技術としての有効レビュ の補完技術としての有効– モデル化作業は、『評価実施者があたかも自身でソフトウエアを作り上げ

る意識で仕様書を読み込む』ため、第三者の観点でチェックをする作業には有効仕様の基本的な問題点 （記述の曖昧さ 内容の不 致 デ タの定義の不明– 仕様の基本的な問題点 （記述の曖昧さ、内容の不一致、データの定義の不明瞭さ）を発見可能

• ツールによる網羅的検査網羅 検– 強力なツールにより人間では不可能な複合的な問題点（非一貫性、非

完全性、ハザード到達性など）の網羅的検査が可能– シミュレーションにより動的問題（デッドロックなど）を発見可能

注意点：• 過剰に頼りすぎないバランスのとれたV&V• 当初はモデル化の作業の誤りが多い当初はモデル化の作業の誤りが多い• 規模が大きい場合、複数人数による作業においては、自然言語モデル、フ

ローチャートモデルともに、状態変数名の統一が必須

SEC特別セミナー＠2011/7/4-5 33

モデル検査技術の実プロジェクト適用に関する問題に関する問題

デ 検 ど 頼 ぎ 全体• モデル検査などに頼りすぎたためにシステム全体の重要な問題を見落とす

領域知識の不足 絞り込み 粒度設定の誤りにより重大な問• 領域知識の不足、絞り込み・粒度設定の誤りにより重大な問題を見逃す

ハ ド（環境） 人（運用手順）の振舞いのモデル化の必要性• ハード（環境）・人（運用手順）の振舞いのモデル化の必要性

• 連続値計算のようなアルゴリズム（制御則など）の検証が困難 (Matlab SCADEなどとの連携）難 (Matlab、SCADEなどとの連携）

• モデル検査の得意とするところ、シミュレーションの得意とするところの観点の区別るところの観点の区別

SEC特別セミナー＠2011/7/4-5 34

理想的な開発に向かってのアプローチ

～モデルベース開発とアーキテクチャデル ス開発とア キテクチャ

SEC特別セミナー＠2011/7/4-5 35

開発の現状と理想開発の現状と理想

現状

自然言語の設計になっていて、曖昧な表現である

理想

フォーマルな記述を用いた開発な表現である。

設計の中で、機能要求と非機能要求を別々に管理している。

機能要求・非機能要求をまとめた管理

ハードウェアとソフトウェアをバラバラで設計している。そのために共通理解が難しい。

理

ハードウェアとソフトウェア込みでの設計

不十分なアーキテクチャ分析

職人的な信頼性・安全性設計

効率の良いアーキテクチャ分析

体系だった信頼性・安全性設計と設計の妥当性確認

ソースコードが出来上がるまで、ハードウェアが出来上がるまで検証をして

計の妥当性確認

早期（要求段階、設計段階）に動くものを用いた検証

いない。

SEC特別セミナー＠2011/7/4-5 36

例：宇宙アーキテクチャ例：宇宙ア キテクチャ

地球の災害データがと地球の災害デ タがとりたいな・・・いつデータを取るか・・・誰が、何を、どのように作るのがいいのか作るのがいいのか・・・

SEC特別セミナー＠2011/7/4-5 37

モデルベースエンジニアリング技術を用いた開発革新用いた開発革新

– 上流設計の検討の充実（運用などの考慮、設計資産の伝承）• 要求定義、アーキテクチャ設計の充実

• 概念設計段階からの検証・妥当性確認、システム妥当性評価の精度を上げる

• Know-Howの明文化、蓄積による設計品質の向上

精度 高 求設定 設計– 精度の高い要求設定・設計• 曖昧性の排除

• 共通理解の確立

– 検証、妥当性評価活動の質・精度の向上• 開発の上流段階での検証強化

• 開発中に識別された要求変更点、設計変更点の検証、および妥当性評価を可能にする。

• 環境変化に対応して要求の継続的見直しを容易にする

暗黙知⇒形式知暗黙知⇒形式知すなわち、しっかり作り、しっかりチェックする

SEC特別セミナー＠2011/7/4-5 38Copyright 2009 JAXA

システム開発における要求の流れ例：コンピュータ周辺機能例：コンピュータ周辺機能

ミッション要求、システム要求

システムとして何が求められていますか？

例：１つの機能がダメになっても、必ずサービスを提供することが出来るシステムであること。

どのような機能要求がありますか？

実装（サブシステム）要求

• 何台のコンピュータが必要ですか？

• どのコンピュータで何の処理をしますか？

ンピ タに必要なリソ ス 性能は？

実装（ ）要求

• コンピュータに必要なリソース、性能は？

実装（ソフトウェア）要求

• ソフトウェアに要求される機能は？

• ソフトウェアの機能に求められている性能は？

• ソフトウェアの機能では どのように処理を行うか？アーキテクチャ

設計を実施

SEC特別セミナー＠2011/7/4-5 39

• ソフトウェアの機能では、どのように処理を行うか？設計を実施

アーキテクチャに着目したアプ チアプローチ

• Q:アーキテクチャ設計を実施する際に、特にコンピュータ周ア キテク ャ設計を実施する際 、特 タ周

辺を設計していく際に、要求を明確化出来、検証が出来るフレームワークはないか？• 各関係者の考えが整理が出来（表現でき）、検証（確認）が出来る環境は？

• A：早い段階からアーキテクチャを意識しモデルを用いた開A：早い段階からア キテクチャを意識しモデルを用いた開発・検証を実施することが出来るAADL技術の試行① ハードウェアとソフトウェアを含めたアーキテクチャのモデリング

② モデルを用いた担当者間の仕様の共通理解度② モデルを用いた担当者間の仕様の共通理解度

③ エラー処理機能・信頼性機能のモデリング

④ モデリング可能範囲

⑤ デ 検証 能性⑤ モデルの検証可能性

SEC特別セミナー＠2011/7/4-5 40

AADLとはAADLとは

AADL A hi A l i D i L• AADL：Architecture Analysis Design Language

• CMUが中心となって進めているプロジェクトCMUが中心となって進めているプロジェクト

• ユーザとしては、航空宇宙業界、自動車業界が主体

• 組込ｼｽﾃﾑのコンピュータ関連アーキテクチャをモデル化するのに最適な言語（ハ ドウェア ソフトウェア込み）言語（ハードウェア、ソフトウェア込み）

• システムの信頼性を表現することが出来るアーキテクチャ言語シ テ 信頼性を表現する 出来る キテク ャ言語

– 例：コンピュータに問題が起きた時のシステムの挙動を表現することが出来る。その情報を使用してシステムが致命的になるようなケースについて解析を行うことが出来る。を行うことが出来る。

SEC特別セミナー＠2011/7/4-5 41

Low fidelity

Adequate confidenceHigh fidelity

Strong confidenceVirtual System Integration

Benefits of Predictive Architecting

Acceptance Test

Top-Level Verification Items

RequirementsEngineering

Virtual System Integration

SoftwareArchitectural

SystemDesign

SystemTest

Integration

High-levelAADL Model

DetailedAADL M d l

早期検証

ArchitecturalDesign

ComponentSoftwareDesign

UnitTest

gTestAADL Model

Specify Model-Code Interfaces

Design

Code

→ generation of test cases← updating models with actual data

SEC特別セミナー＠2011/7/4-5 42

© 2008 by Carnegie Mellon University Development

AADLの例システムの複数階層システムの複数階層

System: (Level 1)Engine, Landing, Cockpit, …

i ht l t i l f l h d li

SubSystem: (Level 2)Hardware platform, software partitions

P MIPS RAM it & b d tweight, electrical, fuel, hydraulics, … Power, MIPS, RAM capacity & budgetsEnd-to-end flow latency

Software subsystem: (Level 3)

SEC特別セミナー＠2011/7/4-5 43

y ( )Tasks, periods, execution timeSoftware allocation, schedulability

AADLの例タスク & アーキテクチャ & 階層モード

System System1

Mode as Alternative ConfigurationThread Dispatch Protocols

Periodic

System Subsystem1

System System1

E1 A

Typed and constrained data

streams

PeriodicAperiodicSporaticBackgroundClient - Server

Immediate and delayed communication

Process Prc1

y y

Initial Mode A: Prc1, Prc2;Mode B: Prc1, Prc3; Process Prc3

Initial Mode A: T1, T2, T3;

E1 A

E1 A

Client Server

Server Thread T2

Data1:Pos

Process Prc2

Thread T3Data1:

Pos

Thread T1Data1

Data1:Pos

E1

E1Shared data

Mode B: T1, T2;

SubprogThread T1

Server Thread T2

SP1

SP2SP3

RSP1Thread T2

E1E1 A

DirectionalData, event, message portsQueued and unqueued xfer

Call/ReturnLocal subprogram

Client/server subprogram

Shared AccessPersistent, shareable data

Access coordination

SEC特別セミナー＠2011/7/4-5 I-44Application Source Internal Mode

Conditional code

Queued and unqueued xfer Client/server subprogram Access coordination

AADLを適用・評価した感想AADLを適用 評価した感想

• 【フォーマルな表現】システムのEnd to Endでフォーマルな標記法によって仕様を記述する とが 能記述することが可能

– 適用フェーズとして、機器の基本設計フェーズ以降

– 適用範囲としては、コンピュータ関連機器

– ハードモデルとソフトモデルを同一モデル表現可能

– モデルの中に性能情報（非機能要求）の記述が可能

– 最新の仕様だと、故障モデルや振り舞いモデルも記述することも可能

– 全てのシステムを記述・設計することは不可能。他の技術で保管する必要がある。

– メタモデルが中心の考え方のために、全てがグラフィカルに記述出来ない

【早期検証】XMLのメタモデルをベ スに他の検証ツ ルとI/Fが可能• 【早期検証】XMLのメタモデルをベースに他の検証ツールとI/Fが可能

– 既存の開発ツール間をAADLのメタモデルでI/Fすることにより、プロセス移行を容易にすることが可能（プロトコルとして使用）

• もちろんモデル検査ツールとの接続も可能• もちろんモデル検査ツ ルとの接続も可能。

– 現状では、モデリングツールとして試行出来るフリーツールはあるが、全ての機能をモデル出来るわけではない。検証ツールとしては、ほとんどない。

• 設計メタモデルDBとして使用が可能設計メタモデルDBとして使用が可能

45SEC特別セミナー＠2011/7/4-5

AADL技術導入により期待できることAADL技術導入により期待できること

『 クを減らす』• 『リスクを減らす』– ライフサイクルを通して早めにシステム解析が出来る

システム全体のインパクトを理解する– システム全体のインパクトを理解する

– 想定問題を評価する

• 『信頼を増す』– 結合試験を完全にするために、モデルの評価を行う

– 忠実度を高くしたシステムモデルによる評価

『費 を減 す』• 『費用を減らす』– システムインテグレーションの問題を少なくする

自動検証環境を使用して工数を少なくする– 自動検証環境を使用して工数を少なくする

SEC特別セミナー＠2011/7/4-5 46

まとめまとめ

安全 高 体 プ• 安全・高信頼性ソフトウエアシステム開発の具体的アプローチの紹介

– 安全設計・審査プロセス

– ソフトウエアIV&V

– モデル検査技術の有効性

キ ク 着 た デ ベ 開発– アーキテクチャに着目したモデルベース開発

SEC特別セミナー＠2011/7/4-5 47

特別セ ナSEC特別セミナー＠2011/7/4-5

48