Safe Software Development

Challenges of Safety Critical
Software Development
Leslie Alford
A-P-T Research, Inc.
Huntsville, AL USA
1
絶対に安全なソフトウェア開発の課題
Leslie Alford
A-P-T Research, Inc.
Huntsville, AL USA
2
Challenges of Safety Critical Software Development
• Introduction
• What is Safe Software?
• How Safe Software should be Developed
• Contributing Difficulties
• Industry’s Challenge
• Summary
3
絶対に安全なソフトウェア開発の課題
• Introduction
• 安全はソフトウェアとは?
• 安全なソフトウェアをどのように開発するべきか？
• 貢献の難しさ
• 産業界の課題
• Summary
4
What is Safe Software?
5
安全なソフトウェアとは
6
What is Safe Software?
Safe software is software that meets its intended functionality
while assuring there are no deaths, loss of equipment or
substantial damage and cost. It is software with no
unintended functions
7
安全なソフトウェアとは?
安全なソフトウェアとは、意図した機能を満たしながら
も、人命や設備機能、大きな経済損失がないことを保証
するソフトウェアです。意図しない機能がないソフト
ウェアです。
8
Safe Software
• Concerns:
◦ Not known safety issues – as these are mitigated or removed in a planned and
rigorous development due to Safety Engineering and software safety critical
practices
◦ It is the unknown software problems stemming from “corner cases” or those
areas not thought of during the development
9
安全なソフトウェア
• 懸案点:
◦ 未知の安全性の問題 –万全を期して運用される安全なエンジニアリング
とソフトウェアであるため、計画段階、厳格開発段階で緩和または除去
されるため
◦ 「コーナーケース」や開発中に考えられなかった部分から生じる
未知のソフトウェアの問題。
10
How is Safe Software
Developed?
Best Practices
Context
Error Class Analysis
Other Best Practices
11
安全なソフトウェアは
どのようにして開発されるか?
ベストプラクティス
コンテキスト
エラークラスの分析
その他のベストプラクティス
12
How Safe Software Should Be Developed?
• Methods have evolved as software industry has matured
• In the aviation field, best practices have evolved for safety critical
software
◦ Plan what is to happen and how it should be done, including testing and
verification
◦ Follow defined documented practices – (how we do something)
◦ Follow defined documented processes – (what we do)
◦ Follow standards (requirements, design, coding, verification)
◦ Use rigorous configuration management and keep things in configuration
control (we can repeat something)
13
安全なソフトウェアをどのように開発されるべきか？
• ソフトウェア産業の成熟とともに、メソッドは進化してきた
• 航空分野では、セイフティクリティカルソフトウェアにむけてベ
ストプラクティスを展開している
◦ テストと検証を含め、何が起こるべきか、どのようにすべきかを計画する
◦ 定義され文書化された実践方法に従う – (何をどのようにするか)
◦ 定義され文書化されたプロセスに従う – (何をするか)
◦ 標準に従う（要件、デザイン、コーディング、検証)
◦ 厳密な設定管理を用いて、設定を制御する(反復できる)
14
Safe Software Development
• Requirements, design, code and
tests must be bi-directionally
traceable
◦ With the exception of derived
requirements (requirements that
evolve from design and
implementation details)
• Develop a test and verification
plan
◦ Based on an error class analysis
› This systematically identifies the
types of errors possible in a
specific program and then devise
the verification tasks needing to be
done to remove or prevent those
errors
• Perform complete and thorough requirements testing
◦ The need is 100% verification coverage that includes the
analysis of testing of the hardware interfaces
• For conditions and decisions in the logic,
◦ For catastrophic hazards use modified condition/decision
coverage
◦ For severe hazards that are not immediately catastrophic use
condition/decision testing
• Thoroughly document plans, processes, requirements,
design, tests, test results, and analyses
◦ These must reflect what is the final integrated software
product. This supports any accident investigations
15
安全なソフトウェアの開発
• 要件、設計、コードおよびテス
トは双方向に追跡可能でなけれ
ばならない
◦ 派生要件（設計と実装の詳細から
進化する要件）を除く
• テストと検証計画を作成する
◦ エラークラス分析に基づいて
› これにより、特定のプログラムで
起こり得るエラーの種類を体系的
に特定し、それらのエラーを削除
または防止するために実行する必
要がある検証タスクを考案する
• 完全かつ完全な要件テストを実行する
◦ ハードウェアインターフェースのテストの分析を含む
100%の検証カバレッジが必要
• 論理上における条件および判断について、
◦ 致命的なハザードについては、MC/DCカバレッジを使用す
る
◦ 致命的ではない重大な危険については、判定条件/条件網
羅テストを使用する
• 計画、プロセス、要件、設計、テスト、テスト結果、
および分析を徹底的に文書化する
◦ これらは、最終的な統合ソフトウェア製品が何であるかを
反映しなければならない。これはあらゆる事故の調査を
サポートする。
16
Safe Software Development
Functional Hazard Assessment (FHA)
◦ System engineering and
◦ Safety engineering processes
Identify Functions
Identify & describe
system functional
hierarchy via functional
decomposition analysis.
Identify Failure Modes
Identify & describe failure
modes for each function.
Preliminary Hazard List (PHL)
Identify Hazards
(and Severity
Utilize FHA functions, similar
systems, lessons learned, generic
lists, and FHA effects to identify
systems hazards, along with their
worst credible outcome severity.
Identify Effects
Classify Severity
Identify & describe
effects of each
failure mode.
Classify severity of each
effect. If severity differs
by phase, identify effects
& severity by phase
Preliminary Hazard Assessment (PHA)
Preliminary System Safety Assessment (PSSA)
Identify Causes
Identify causes for each
hazard by performing
deductive systems
analysis (e.g. FTA), and
utilizing FHA Failure Mode
and Effects relationships.
Safety-Critical
Functions List
Most important:
• Safe software is developed
in context with rigorous
Is Risk
YES
Acceptable?
Assess Risk
Assess risk (severity ×
likelihood) for each hazard
based on hazard severity,
likelihood of causes, and
causal relationships
(AND/OR gates in FTA).
NO
Additional Safety Test
Robustness, stress, FMET,
& coverage test.
Verify Mitigation
Design/document test cases to verify that
implementation achieves planned/desired
risk reduction.
Implement Mitigation
Derive/document requirements
and/or design constraints to
implement mitigation. Trace/follow
through design and hardware/
software implementation.
Identify Mitigation
(reduce risk)
Identify means of risk
reduction IAW rules of
precedence (design, device,
warning, procedures) and
DAL/LOR for software.
17
安全なソフトウェアの開発
Functional Hazard Assessment (FHA)
◦ システムエンジニアリング
とセイフティエンジニアリ
ングプロセス
機能の特定
機能分解分析による
システム機能階層の
特定と記述.
障害モードの特定
各機能の障害モードを特
定し記述する.
Preliminary Hazard List (PHL)
ハザードの特定
(および重大さ）
FHAの機能、類似のシステム、
教訓、一般的なリスト、およ
びFHAの影響を活用して、シ
ステムのハザードを識別し、
起こりうる最悪の場合の重大
度を特定します。
影響を特定
各障害モードの影
響を特定および記
述する
重大度の分類
影響の重大度を分類し
ます。重大度がフェー
ズごとに異なる場合は、
フェーズ別に影響度と
重大度を特定します
Preliminary Hazard Assessment (PHA)
Preliminary System Safety Assessment (PSSA)
原因の特定
演繹的システム分析
（FTAなど）を実行し、
FHA障害モードと効果の
関係を利用することに
より、各ハザードの原
因を特定する。
Safety-Critical
Functions List
最重要ポイント:
• 安全なソフトウェアは精
密に開発されなければな
らない
リスクは
YES
許容
できるか?
リスクの評価
ハザードの重大度、原因
の可能性、因果関係
（FTAにおけるAND / OR
ゲート）に基づいて、各
ハザードのリスク（重大
度×可能性）を評価する。
NO
追加の安全性テスト
堅牢性、ストレス、FMET,カバ
レッジテスト.
緩和策の検証
実装が計画された/望ましいリスク削
減を達成したことを検証するためのテ
ストケースの設計/文書化。
緩和策の実践
緩和を実施するための要件およ
び/または設計制約を導出/文書化
する。デザインとハードウェア/
ソフトウェアの実装を追跡/追跡
します。
緩和策の特定 (リス
クの低減)
優先順位の手段（設計、
デバイス、警告、手順）
およびソフトウェアの
DAL / LORに基づくリスク
削減の手段を特定する。
18
Safe Software Development
• Error Class Analysis
◦ The method that identifies the sources of error in a software application by
creating a list of possible contributions of error in the software
› Resulting from the processes, people, tools, and environment involved with developing a
software applications
• How it is Used:
◦ To design a thorough verification program (reviews, analysis, test)
◦ To methodically remove or reduce the possibilities of errors
◦ In the aviation industry, the RTCA/DO-178B/C documents the most used
approach using an error class analysis
19
安全なソフトウェアの開発
• エラークラスの分析
◦ ソフトウェアのエラーの可能性のあるリストを作成することにより、ソ
フトウェアアプリケーションのエラーの原因を特定する方法
› ソフトウェアアプリケーションの開発に関わるプロセス、人、ツール、環境の結果
• どのように使用されるか:
◦ 徹底的な検証プログラムの設計（レビュー、解析、テスト）
◦ 誤りの可能性の体系的な除去または低減
◦ 航空業界では、RTCA / DO-178B / Cはエラークラス分析を使用した最もよ
く使用されるアプローチを記録する
20
Safe Software Development
Other Best Practices
Practice
What it does
Rigorous Safety
Engineering
Only Use Static Memory
Allocation
Only use Safe Subsets of
instruction sets,
technologies, etc.
Use of Tools
Identifies hazards
Assures they are removed or mitigated
Ensures isolation/partitioning of memory by ensuring safety critical memory is not
overwritten by less critical tasks
Using a safe subset of a language instruction set or a software technology ensures
safety critical software partitions and memory are not violated – does not allow
overwriting by lesser tasks
Efficiently reduces workload, performs tedious or time consuming tasks,
automates the steps in processes, removes specific kinds of errors, configuration
control and problem reporting, requirements traceability, performs various kinds
of verification like structural coverage analysis, formal methods, etc.
Appropriate Use of Analysis Finds runtime errors, performs stack, dataflow, set-use, control flow, timing and
memory margin, and verification requirement coverage analysis
Engineering Training and
Provides lessons learned and best practices
Experience
Aids in efficiency and problem solving
21
安全なソフトウェア開発
その他のベストプラクティス
プラクティス
精密な安全工学
スタティックメモリの割り
当てのみの使用
命令セット、技術などの
セーフ・サブセットのみの
使用
ツールの使用
分析の適切な利用
エンジニアリングのトレー
ニングと経験
概要
ハザードの特定
それらが取り除かれたか緩和されたかを確かめる
重要度の低いメモリが重要度の低いタスクで上書きされないようにすることで、
メモリの分離/パーティション化を保証
言語命令セットまたはソフトウェア技術の安全なサブセットを使用することにより、
安全性に重大なソフトウェアパーティションおよびメモリが侵害されないことが保
証される。重要度の低いタスクによる上書きは許可されない
効率的に作業負荷を減らし、冗長で時間のかかる作業を実行し、プロセスのステッ
プを自動化し、特定の種類のエラーを排除し、構成の制御と問題の報告、要件のト
レーサビリティを行い、構造カバレッジ分析や正式な方法などを実行する
実行時エラーを検出し、スタック、データフロー、セット使用、制御フロー、タイ
ミングとメモリマージン、検証要件カバレッジ分析を実行する。
学んだ教訓とベストプラクティスの提供
効率化と問題解決の支援
22
Contributing Difficulties
Complex Programmable Logic Devices
Multicore Processors
Real Time Operating Systems for Multicore Processors
Life Cycle Concerns
23
貢献の困難さ
複雑なプログラマブルロジックデバイス
マルチコアプロセッサ
マルチコアプロセッサ用のリアルタイムオペレーティングシステム
ライフサイクルの懸念
24
Contributing Difficulties
• Rapid advances in processor speed and capability pose another
challenge to developing safe software
• Size and complexity of software applications have mushroomed
exponentially
• Complex programmable logic devices (PLD) now have millions of gates
possible and often replace older software functions
◦ Parts obsolescent replacements with PLDs can be difficult dependent on the
design of the original software
◦ PLDs have embedded commercial-off-the-shelf (COTS) that are declared
Intellectual Property (IP)
◦ These also must be safe and may interface with software
25
貢献の難しさ
• プロセッサの速度と能力の急速な進歩により、安全なソフト
ウェアを開発する上で課題が生じる
• ソフトウェアアプリケーションのサイズと複雑さは指数関数的
に急上昇する
• 複雑なプログラマブル・ロジック・デバイス（PLD）は現在、
何百万ものゲートがあり、しばしば古いソフトウェア機能を置
き換える
◦ PLDを使用した部品への代替は、元のソフトウェアの設計によっては困
難な場合がある
◦ PLDには、知的財産権（IP）を含む商用版（COTS）が組み込まれている
◦ これらもまた安全でソフトウェアと接続されうる
26
Contributing Difficulties
Multicore Processors
• These pose the latest challenge to safety critical software applications
• These have been proliferated in our home computers and internet
capabilities for some time
• We are now challenged to add more capability in multicore
processors for speed and capability upgrades, but our issues now
include
◦ Resource contention
◦ Crossed processing threads of varied safety criticality
◦ Issues with prioritization
◦ Proliferation of conflicting states, etc.
◦ Increased test and verification issues
27
Contributing Difficulties
マルチコアプロセッサーズ
• これらは、セイフティクリティカルソフトウェアに最新の課題を
もたらする
• これらは家庭のコンピュータやインターネットの機能の中で近年
に急増している
• マルチコアプロセッサを、速度と機能のアップグレードするため
に使おうとしているが、現在以下のような課題がある
◦ リソースの競合
◦ さまざまな安全レベルにおけるプロセスとスレッド
◦ 優先順位付けの問題
◦ 競合状態の増大など
◦ テストと検証の問題の増加
28
Contributing Difficulties
Real Time Operating Systems (RTOS)
• A multicore processor needs an RTOS that supports safety critical
applications needs for protection for partitioning and separation
• Only 2 commercially available RTOS’ have been approved by
certification authorities for use in airworthiness applications
• These support the time and space partitioning needs of safety critical
software (ARINC 653 compliant)
29
Contributing Difficulties
リアルタイムオペレーティングシステム (RTOS)
• マルチコアプロセッサには、隔離と分離の保護のために、安全
性が重要なアプリケーションニーズをサポートするRTOSが必要
• 航空業界で使用できる、認証機関によって認証された市販の
RTOSが2つある
• 安全性が重要なソフトウェア（ARINC 653準拠）に求められる時
間と空間を分割するというニーズをサポートしている
30
Contributing Difficulties
Life Cycle Concerns
• Other forces contribute to loss of safety, beyond development and
verification
• Safety issues can arise from use and maintenance practices
• Examples:
◦ A pilot needs to know what unsafe conditions are while flying
◦ A software engineer needs to be able to determine whether changes made will
impact functions that are currently “safe”
31
Contributing Difficulties
ライフサイクルの懸念
• 他に要素も、開発と検証を超えて、安全性の喪失を引き起こす
• 使用および保守を実践する過程で安全性の問題が生じる可能性がある
• 事例:
◦ パイロットは、飛行中に危険な状態が何であるかを知る必要がある
◦ ソフトウェアエンジニアは、行われた変更が現在の「安全」な機能に影響を与
えるかどうかを判断できなければならない。
32
Industry’s Challenge
Cost Mitigations
Technical Mitigations
33
産業界の課題
コスト削減
技術的緩和
34
Industry’s Challenge
• Safety critical software is time intensive and costly
• In aviation, it also requires customer and certification authorities to
approve their use
• Our challenge is to develop the software and also meet schedule and
cost through various mitigation strategies
◦ Cost
◦ Technical
35
産業界の課題
• 安全なソフトウェア開発には、時間がかかり、コストがかかる
• 航空システムでは、顧客および認証機関がソフトウェアを使用
することを承認する必要もある
• 我々の課題は、さまざまな緩和戦略によってスケジュールとコ
ストの要件を満たしつつ開発すること
◦ コスト
◦ 技術面
36
Industry’s Challenge
Cost Mitigations
• Use Risk Management
◦ This is a proactive method for identifying and managing risks to a program
◦ It includes the development of a plan for each risk identified that removes or
reduces the risk to a manageable level during the program
• Software related risks include assessing existing software capabilities
to determine what software and/or documentation can be reused
and determining how much requires modification
◦ This analysis is referred to as a Change Impact Analysis
◦ Benefit: Provides the confidence of starting with a known safe and working
product with the possible impact of reducing the overall effort
37
Industry’s Challenge
コスト削減
• リスクマネジメントの利用
◦ プログラムのリスクを特定し管理するための積極的な方法
◦ プログラム中に管理可能なレベルのリスクを除去または低減すること、も
しくは、特定されたリスクごとの計画の策定が含まれる
• ソフトウェアに関連するリスクには、既存のソフトウェア機能を
評価して、どのソフトウェアおよび/またはドキュメンテーション
を再利用できるかを判断し、どれだけ修正が必要かを判断するこ
とが含まれる
◦ この分析は、チェンジ・インパクト・アナリシスと呼ばれる
◦ メリット：既知の安全な現行製品から始めることで、全体的な労力の削減
38
Industry’s Challenge
Cost Mitigations
• Use Risk Management, continued
◦ Less complex areas of code development may be determined to require less rigor and savings are
identified.
◦ Some documentation may be assessed to determine if it can be streamlined (deleted or combined)
◦ Automating testing, or using manual testing versus automated may be assessed for cost cutting
• When used properly, risk management is a powerful tool for managing a successful program by
planning for reduction or early resolution of issues and proactively addressing them
◦ Risk management can sound bad in the aviation industry, as its often stated in terms of deaths, cost, and
equipment damage
• The overall goal for risk management is determining what level of risk can be acceptable for cost
and schedule savings
A WORD OF CAUTION – the danger is accepting too much risk
39
Industry’s Challenge
コスト削減
• リスクマネジメントの利用（続き）
◦ あまり複雑でないコード開発の領域は、さほど精密に開発する必要がないと判断され、コスト削減
の対象となる。
◦ 合理化できるかどうかを判断するために、一部の文書を評価することがある（削減あるいは統合）
◦ コスト削減のために、自動化テスト、または手動テストか自動化のどちらを使うかが評価される
• リスクマネジメントは、適切に使われれば、問題の削減や早期解決を計画し、積極的に取り
組むことで、プログラム成功裏に管理するための強力なツールとなる
◦ リスク管理は、死亡、コスト、および機器の損傷の点で言及されることから、航空業界では
悪いイメージをもたれることがある
• リスク管理の最終的な目標は、コストとスケジュールの節約に対してどのレベルまでのリス
クを許容できるかを判断すること
A WORD OF CAUTION – 危険とは過剰なリスクを受け入れること
40
Industry’s Challenge
Cost Mitigation Concerns
• In today’s world, good management must keep costs to a minimum
• Due to the intense economic pressures, it is very easy to accept too much risk in minimizing costs
and inadvertently cause safety issues
• A few lessons learned over the years include the following:
◦ Documentation is an upfront cost that is tempting to reduce. This can seem like an impressive cost
savings up front, but by program end, it can turn out to be more costly and impede the management and
maintenance of software safety
◦ Configuration control is unfortunately an easy target for reducing costs. But without configuration
control, any repeatable success is accidental.
› (A summarized point of the Software Engineering Institute (SEI) Capability Maturity Model (CMM) tenets)
◦ Software Quality Assurance is also a target for cost cutting, but this is what assures the plans, processes,
and standards and best practices are followed
› Again, the absence of software quality assurance can mean success is unreachable
41
Industry’s Challenge
コスト削減の懸念
• 今日、良い経営といわれるためにはコストを最小限に抑えることを求められる
• 厳しい経営的圧力にさらされると、コストを最小限に抑えすぎるあまり、安全性に問題
を引き起こすリスクをかかえがちである。
• 長年にわたる経験から下記のような教訓が得られた:
◦ 文書化は初期費用であり、削減されがちである。これは、効果的なコスト削減のように見える
が、最終的には、かえってより高くつき、ソフトウェアの安全性の管理と保守を妨げる元凶と
なりうる。
◦ 残念なことに、構成管理（コンフィギュレーションコントロール）はコスト削減のためのター
ゲットとなりやすい。しかし、構成の制御がなければ、反復可能な成功は偶然にしか起こりえ
ない。
› （ソフトウェアエンジニアリング研究所（SEI）能力成熟度モデル（CMM）の教義の要約）
◦ ソフトウェア品質保証もコスト削減のターゲットとなりがちだが、ソフトウェア品質保証こそ
が計画、プロセス、スタンダードを保障しベストプラクティスへ導く
› ソフトウェアの品質保証がないと、成功に達することができない可能性がある
42
Industry’s Challenge
Technical Mitigations
• We know we must plan for a safety approach to safety critical
software
• We develop the requirements and design with safety mitigation
strategies.
◦ Strategies include architectural mitigations, use of previously approved and
certified software systems, and advanced verification methods
◦ Architectural mitigations include redundancy, isolation, use of monitors,
partitioning, dissimilarity, and command/authority limits.
43
Industry’s Challenge
技術的緩和
• 私たちは、セイフティクリティカルソフトウェアに向けて安全
なアプローチを計画しなければならない
• 安全対策戦略を用いて要件と設計を開発する。
◦ 戦略には、アーキテクチャの緩和、以前に承認され認定されたソフト
ウェアシステムの使用、高度な検証方法が含まれる
◦ アーキテクチャの緩和には、冗長性、隔離、モニターの使用、パーティ
ション化、相違性、およびコマンド/権限の制限が含まれる。
44
Industry’s Challenge
Technical Mitigations
Most are defined in RTCA/DO-178B, as follows:
• Redundancy
◦ Used to duplicate a function or system to ensure a backup system is available
• Isolation
◦ Used to contain and/or isolate faults and potentially reduce the effort of the software verification process
• Monitors
◦ These are a means of protecting against specific failure conditions by directly monitoring a function for failures which would contribute to the failure condition.
Monitoring functions may be implemented in hardware, software, or a combination of hardware and software.
• Partitioning
◦ This is the time and space separation / isolation between functionally independent software functions and components to contain and/or isolate faults and
potentially reduce the effort of the software verification process
• Dissimilarity
◦ Dissimilar software versions are usually used as a means of providing additional protection after the software verification process has been satisfied.
Dissimilar software verification methods may be reduced from those used to verify single version software if it can be shown that the resulting potential loss of
system function is acceptable as determined by the system safety assessment process.
• Command/authority limits
◦ Used in monitors that command and limit maneuvering of an object forcing certain motion to stay within defined limits. This is used for limiting the pitch, roll,
and yaw of a flying aircraft, for example.
45
Industry’s Challenge
技術的緩和
RTCA / DO-178Bで次のように定義されている。
• 冗長性
◦ バックアップシステムが利用できることを保証するため、ファンクションまたはシステムを複数持つ
• 分離
◦ 障害を抑止および/または分離し、ソフトウェア検証プロセスの労力を削減することもできる
• モニター
◦ 障害状態に寄与する障害の機能を直接監視することによって、特定の障害状態から保護する手段。監視機能は、ハー
ドウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせによって実施される。
• 分割
◦ 機能的に独立したソフトウェア機能とコンポーネントとの間の時間と空間の分離である。フォールトを包含および/ま
たは分離し、ソフトウェア検証プロセスの労力を潜在的に削減する。
•
相違点
◦ 異なるソフトウェアバージョンとは、通常、ソフトウェア検証プロセスが満たされた後に、何らかの追加の補償を必
要とする。システムの安全アセスメントプロセスによって決定されるように、システム機能の潜在的損失が許容可能
であることが示され得る場合、異なるソフトウェアへの検証方法は、単一バージョンソフトウェアを検証するために
使用した方法を活用することにより減らせる。
• コマンド/権限の制限
◦ 特定の動作が定義された制限内にとどまるように、オブジェクトの操作を命令し、モニターする。これは、例えば飛
行機のピッチ、ロール、ヨーの動きを制限するために使用される。
46
Industry’s Challenge
Advanced Verification Methods
• These are used for the more severe levels
of safety critical software
• Used at the software integration level to
further assure the safety critical
application and include at the software
architecture and code level:
• Path coverage
• Condition/decision coverage
• Modified condition/decision coverage
47
Industry’s Challenge
高度な検証方法
• より厳しいレベルの安全に欠かせない
ソフトウェアに使用される
• 安全性に重大な影響を与えるアプリ
ケーションをさらに確実にするために
ソフトウェア統合レベルで使用される。
ソフトウェアアーキテクチャとコード
レベル
• パスカバレッジ
• 条件/デシジョンカバレッジ
• MC/DC
48
Summary
Conclusion
49
概要
結論
50
Summary
• It would seem that if we know what best practices are for safety critical software,
they should be widely used and accepted in industry
◦ But this is not the case, if only due to the time and cost of using them
◦ Several examples from my recent experience include:
› A company whose program management dictated to the software development team what they could
and could not do.
• This program has slid more than 3 years and is still in progress
› One site of a company did not provide for software tools for configuration management, verification,
or requirements traceability for the software development team.
• This program also slid close to one year while errors were being corrected
› A recent program has used a textbook example of the Agile software development concept, without
modification for safety critical applications
• This system is now being redesigned to meet safety requirements
› A supplier of a software intensive safety critical system did not assure that a software quality
assurance function was occurring rigorously and consistently throughout the program
• This program has suffered program delays as the errors were found and further changes were deemed
necessary
51
概要
• セイフティクリティカルソフトウェアのベストプラクティスが何であるか
を知っていれば、それは広く使用され、業界で受け入れられるであろう
◦ しかし、それを使用する時間とコストのためだけであれば、その限りではない。
◦ 私の最近の経験上いくつかの例がある：
› プログラムマネジメントがソフトウェア開発チームに対していちいち指示を出していた会社。
• このプログラムの開発は3年以上ずれこんで、まだ進行中。
› ある企業のあるサイトは、ソフトウェア開発チームの構成管理、検証、または要件のトレー
サビリティのためのソフトウェアツールを提供していなかった。
• このプログラムもまた、エラーが訂正されている間に1年近くまでずれこんだ。
› 最近のプログラムでは、アジャイルソフトウェア開発コンセプトの教科書の例を使用した。
• このシステムは安全要件を満たすように再設計されている。
› ソフトウェアインテンシブセイフティクリティカルシステムのサプライヤが、ソフトウェア
品質保証機能をプログラム全体にわたって精密かつ一貫してきちんと機能させていなかった
• このプログラムは、エラーが発見され、変更が必要となり、遅延が発生した。
52
Summary
• Conclusion
◦ Our first challenge is to use properly what we know
◦ Our second challenge for the future of safety critical software is to continue to
grow in innovation and creativity with new technologies. We must stay
abreast of technology development and continue to seek new and novel
methods for assuring safety.
◦ Our caution is that we must know a technology well enough to seek a safe
application of a technology to understand and successfully use its safe-subset
53
概要
• 結論
◦ まずは、私たちが知っていることを正しく使う。
◦ セイフティクリティカルソフトウェアの将来の課題は、新しい技術で革
新と創造性を成長させ続けること。技術開発に遅れずに、安全を保証
するための新しく斬新な方法を模索し続けなければならない
◦ 安全なサブセットを理解し、上手に利用するためには、技術を安全に適
用できるように、技術を理解しなければならない。
54
Questions?
55
56

Download Report