講演資料（和訳）

Assuring NASA’s Safety and
Mission Critical Software
Wesley Deadrick
IV&V Office Lead
NASA’s Independent Verification and Validation Program
Fairmont, WV
NASA IV&V誕生の経緯
• NASA IV&V プログラム： 1993年設立
• スペースシャトル「チャレンジャー号」事故の調査委員会の結
果、 NASA Office of Safety and Mission Assurance (NASA
安全保証部)のもとで発足.
2
IV&Vの必要性
高い安全性が求められるミッションクリティカルなソフトウェアの開発は、
リスクが大きくなり、難易度が高い
3
IV&Vの概要
Independent Verification and
Validation (IV&V) とは、
ソフトウェアの開発プロセスおよび成果物
に対する客観的な評価である
３つの独立:
• 技術的独立
• 組織的独立
• 資金的独立
システムズエンジニアリング:
正しく製品を作っているか？正しい製
品を開発しているか？
NASA IV&V 3つの問い:
IV&V 技術指針:
• ソフトウェアは.・・・
• 意図通りに正しく振舞うか？
• 意図しない振る舞いをしないか?
• 不都合な事態に期待通り振舞うか?
• IEEE 1012に準拠
• 「Catalog of Methods」で技術管理
• 開発ライフサイクルに合わせて実施
可能
IV&V “Assurance Strategy”
“Assurance Strategy”とは、宇宙機ミッションを保証するためのIV&V戦略であり、戦略は
1. 各開発プロジェクトやミッションの要望に合わせて立案
2. “Assurance Design”によって具体化
3. “Assurance Statement”によって説明責任が果たされる
4
IV&Vの特徴（1/2)
• “Assurance Strategy”は、IV&Vにおいて検証および妥当性確認のため
の最適な評価手法を示す
– IV&Vの評価手法は、開発プロジェクトのリスク分析結果とミッションの特性分析に
よって選択される
– “Assurance Strategy”は個々のプロジェクトで最適化される
• 「妥当性確認」では以下の「根拠」を客観的に示す:
– システムの要求がソフトウェアに落とし込まれているか
– 正しい製品を開発しているか
– 想定される運用環境において、期待通りの振る舞いをするか
• 「検証」では以下の「根拠」を客観的に示す:
– ソフトウェアの開発成果物が、前の工程からの入力情報と照らして正しく作られてい
るか
– 開発基準や開発のベストプラクティスに準拠しているか
– 開発フェーズを次の段階に進めることが可能か
5
IV&Vの特徴（2/2)
• IV&Vでは、開発組織で作成される全ての成果物（アセスメント、分
析、評価、レビュー、検査、試験の結果も含む）が評価対象であり、
評価結果に対して「根拠」を作成する。
– 「根拠」はソフトウェアの品質や信頼性がどうであったかを結論づける際に利用
– 「根拠」は技術レベルを確認する際に利用
– 「根拠」はどの程度厳密に評価を実施したのかを示す際に利用
• 「根拠」はどこまで示せば良いか？  システムから見た時の重要度に応
じて「根拠」作成の強弱をトレードオフする
– システムとして非常に重要なサブシステムにおいては、ソフトウェアが安全に
動く（または動かない）ことを示す「根拠」を、厳密に作成する必要がある。
– 上記と比較し、例えばデータマネージメントのみをするサブシステムにおいて
は、作成する「根拠」の優先度は低くなる場合が多い
• 評価対象にどの程度の「根拠」をつける必要があるのかによって、評価を
どこまで実施するべきかが決まる
– 「評価の厳密さ」によって、IV&Vで用いる評価手法や評価量が異なる
6
“Assurance Strategy”の立案 (1/2)
• IV&Vプログラムでは、以下を識別するためにシステムを評価
– システムの特性に応じたリスク、懸念点
– システムにおけるソフトウェアの役割
– IV&Vで評価すべきソフトウェアの範囲はどこであるか
– IV&V評価の中心はソフトウェアに関する成果物であるが、他の成果物（例：
概念設計、システム方式設計など）も参照情報として利用する。
• システム評価手法： “Portfolio Based Risk Assessment” (PBRA)
– 各々のシステム特性やソフトウェアの役割に関して、影響度(問題が発生した時
の影響の大きさ)と発生確率(エラーが発生する頻度）を用いて評価
– 評価結果は以下を決定するために利用
– IV&Vを適用すべきシステムの範囲
– IV&Vが適用すべき評価手法の「厳格さレベル」 (例: コミュニケーション等の
協調動作が行われる箇所では、動的解析を行う必要がある等）
7
“Assurance Strategy” の立案 (2/2)
Subsystem Criticality Profile
1
2
3
5
4
Likelihood
3
3
1
2
2
1
1
2
3
4
5
Impact
Subsystem 1 – IV&Vの必要はない
Subsystem 2 – IV&Vにおいて静的解析を推奨
Subsystem 3 – IV&Vにおいて動的解析を推奨
Subsystem n …
「厳格さレベル」及び「根拠」の量
小
大
手動評価
静的解析
動的解析
形式手法
SMEs conduct formal
or informal inspections &
evidence is recorded simply
as issues
SMEs evaluate structure
& content using various
perspectives supported
by CASE tools. Evidence is
recorded as issues &
supplemented with coverage
SMEs execute system &
evaluate results. Evidence is
recorded more thoroughly as
to make the case for what
works and what are limitations
SMEs apply formalisms
& mathematical rigor
to prove existence or
absence of critical
properties
“Assurance Strategy”の具体化
• “Assurance Strategy”は “Assurance Design”によって具体化される
•
•
“Assurance Design”はIV&Vプロジェクトの目的を達成するために必要なものを明
確にする。（例：Technical Reference、入力情報、評価手法、評価結果から作成
される「根拠」）
“Assurance Strategy”と同様に、”Assurance Design”は個々のプロジェクトのニーズ
に応じて最適化される
• IV&Vプロジェクトがクリティカル時の動作を保証し、システムのリスクを低減
できるような、「根拠」を確実に作成するように示す
• PBRAの分析でリスクが識別された箇所は、”Assurance Design”を作成する
上での重要なインプットとなる
• “Assurance Statements” は“Assurance Strategy”で何を保証する
のかを伝えるために利用される
•
•
“Assurance Statements” はIV&Vのステークホルダやシステム/サブシステム
のステークホルダーに対して、何を保証したのかを伝える
“Assurance statements”はIV&Vプロジェクト開始時に作成され、評価を進め
るにつれて洗練させる
9
“Assurance Strategy”実行のためのツール
• “Assurance Strategy”の戦略実行のため、NASAでは新しい評価手
法の開発を継続的に進めている
• IV&V評価手法はCatalog of Methods (CoM)でまとめられている
• 評価手法はプロジェクトのニーズに応じて、絶えず洗練やテーラリングがされ
ている
• NASAの高安全性、ミッションクリティカルなソフトウェアを評価し続
けるため、IV&Vプログラムでは新規技術の開発に取り組んでいる
• NASA IV&Vプログラムでは、セキュリティ保証手法や独立試験手法の開発に
力を入れている
• 新規技術の開発は、新規技術の開発現在の開発トレンドや、リスクとして
認識されていることに対応するために実施
• セキュリティ保証や独立試験は、各IV&Vプロジェクトの品質保証戦略を
実現するための重要な要素となっている
10
セキュリティ保証
システムやソフトウェアが高い信頼性、安全性、セキュリティがあることを評価する
リスクアセスメント
•
•
•
FISMA コンプライアンス
システムのライフサイクルを通じて、
• 設計、実装、運用、保守、廃棄についてセキュ
リティが確保されているのか保証する
• Assessment and Authorization (A&A)
Authority to Operate (ATO)
脆弱性評価 /侵入テスト
• セキュリティコントロールの実装
• セキュリティコントロールの監視
• 静的コード解析 (SCA)
CyberLab
IV&V評価によるサポート
•
•
•
セキュリティを “from the ground up”で構築
セキュリティーアーキテクチャの検証
IV&V 評価手法
•
•
•
•
•
•
ITC JSTAR Lab（IV&Vの研究部隊）の一部
バーチャルサーバ
侵入テストツール
サイバーセキュリティのナレッジベース
サイバーセキュリティのトレーニングプログラム
運用システムのバーチャル化とテスト
11
独立試験手法
NASAプロジェクト横断的に適用可能な、動的テスト環境の開発、維持、運用
シミュレーション
•
•
•
•
•
ソフトウェアのみのシミュレーション
NASA Operational Middleware (NOS)
o 共通のエミュレータ
o ミドルウェア
Spacecraft Simulators
o 地上システム、機器、機体のダイナミクス
Small Sat
ソリューション創出のため、種々の技術を統合する
自動化
• 検証のシミュレーション化
• Increase Testing
o 単体試験
o システム試験
• 自動設定とシミュレータの導入
バーチャル化
試験
•
•
•
エビデンスベースの保証を試験結果を持って顧客に
提供
リスクに特化した独立試験
想定外に特化した試験
o 故障模擬、back-to-back シナリオ, etc.
•
バーチャル化技術の検討
o バーチャル技術の開発
o シミュレータのリリース
o Rapid Deployment
o 検証環境
12
まとめ
~IV&Vによる効果~
• 開発成果物のエラーが少なく、ユーザの要求を満たしていることを確信できる
• 開発の初期の段階でリスクが高い箇所、不具合になり得る箇所の識別確率を
上げる
– 開発組織に対して、納入期限を守るためのその場しのぎの対応策ではなく、根本的な解決策
を模索する時間を与えることができる
• IV&Vの進捗状況やパフォーマンスは常に意思決定者（例：プログラムマネージ
ャなど）に伝えられる
– IV&Vの顧客は、システムの開発に関するパフォーマンスを確認することができるので、早い時
期に開発プロジェクトの調整をすることができる
• 開発の手戻りが少なくなるため、開発プロジェクトの総コストを抑えることができ
る。
• IV&Vはソフトウェアやシステムのベストプラクティスに関する技術伝承を促進す
る
IV&V実施の効果として、高品質な製品の作成、リスクの減少、
プロジェクト状況の把握、コスト削減、技術伝承が上げられる
13
QUESTIONS?
14
IV&V Services
IV&V plays a key role in a number of high-profile NASA and nonNASA missions.
15
IV&Vの全体像
Requirements
Specification
Concept Analysis
{validate selected solution, validate s/w reuse strategy, verify sys. architecture is complete, ensure security
threats & risks are known}
Requirements Analysis
{ensure the requirements are high quality (correct, consistent, complete, accurate, unambiguous , and
verifiable) and adequately meet the needs of the system and user}
Design Analysis
Design
{ensure the design is a correct, accurate, and complete transformation of the requirements that will meet the
operational need under nominal and off-nominal conditions and that no unintended features are introduced}
Code Analysis
Implementation
Integration &
Test
Ops &
Maintenance
{ensure the implementation is correct, accurate, and complete, relative to requirements, operational need
under nominal and off-nominal conditions, and introduces no unintended features }
Test Analysis
{ensure testing will serve as a sufficient means to verify and validate that the implementation meets the
requirements and operational need under nominal and off-nominal conditions}
Operational & Maintenance Analysis
Criticality Analysis {identify most critical areas of the system}
Needs Analysis &
Concept Phase
{ensure operating procedures are correct and usable, new constraints & changes are understood and
appropriately addressed, and ensure anomalies are understood and appropriately addressed}
16

Download Report