Embed Size (px)
Citation preview
1
Challenges of Safety Critical Software Development
Leslie Alford
A-P-T Research, Inc.
Huntsville, AL USA
2
絶対に安全なソフトウェア開発の課題
Leslie Alford
A-P-T Research, Inc.
Huntsville, AL USA
3
Challenges of Safety Critical Software Development
• Introduction
• What is Safe Software?
• How Safe Software should be Developed
• Contributing Difficulties
• Industry’s Challenge
• Summary
4
絶対に安全なソフトウェア開発の課題
• Introduction
•安全はソフトウェアとは?
•安全なソフトウェアをどのように開発するべきか？
•貢献の難しさ
•産業界の課題
• Summary
5
What is Safe Software?
6
安全なソフトウェアとは
7
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
8
安全なソフトウェアとは?
安全なソフトウェアとは、意図した機能を満たしながらも、人命や設備機能、大きな経済損失がないことを保証するソフトウェアです。意図しない機能がないソフトウェアです。
9
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
10
安全なソフトウェア
•懸案点:◦未知の安全性の問題 –万全を期して運用される安全なエンジニアリングとソフトウェアであるため、計画段階、厳格開発段階で緩和または除去されるため
◦「コーナーケース」や開発中に考えられなかった部分から生じる
未知のソフトウェアの問題。
11
How is Safe Software Developed?Best Practices
Context
Error Class Analysis
Other Best Practices
12
安全なソフトウェアはどのようにして開発されるか?
ベストプラクティス
コンテキスト
エラークラスの分析
その他のベストプラクティス
13
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)
14
安全なソフトウェアをどのように開発されるべきか？
•ソフトウェア産業の成熟とともに、メソッドは進化してきた
•航空分野では、セイフティクリティカルソフトウェアにむけてベストプラクティスを展開している◦テストと検証を含め、何が起こるべきか、どのようにすべきかを計画する
◦定義され文書化された実践方法に従う – (何をどのようにするか)
◦定義され文書化されたプロセスに従う – (何をするか)
◦標準に従う（要件、デザイン、コーディング、検証)
◦厳密な設定管理を用いて、設定を制御する(反復できる)
15
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
16
安全なソフトウェアの開発
• 要件、設計、コードおよびテストは双方向に追跡可能でなければならない
◦ 派生要件（設計と実装の詳細から進化する要件）を除く
• テストと検証計画を作成する
◦ エラークラス分析に基づいて› これにより、特定のプログラムで起こり得るエラーの種類を体系的に特定し、それらのエラーを削除または防止するために実行する必要がある検証タスクを考案する
• 完全かつ完全な要件テストを実行する◦ ハードウェアインターフェースのテストの分析を含む
100%の検証カバレッジが必要
• 論理上における条件および判断について、
◦ 致命的なハザードについては、MC/DCカバレッジを使用する
◦ 致命的ではない重大な危険については、判定条件/条件網羅テストを使用する
• 計画、プロセス、要件、設計、テスト、テスト結果、および分析を徹底的に文書化する
◦ これらは、最終的な統合ソフトウェア製品が何であるかを反映しなければならない。これはあらゆる事故の調査をサポートする。
17
Safe Software Development
Most important:
• Safe software is developed in context with rigorous◦ System engineering and
◦ Safety engineering processes
Functional Hazard Assessment (FHA)
Identify Functions Identify Failure Modes Identify Effects Classify Severity
Identify & describe system functional hierarchy via functional decomposition analysis.
Identify & describe failure modes for each function.
Identify & describe effects of each failure mode.
Classify severity of each effect. If severity differs by phase, identify effects & severity by phase
Safety-C
ritical Fu
nctio
ns List
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.
Preliminary Hazard Assessment (PHA)Preliminary System Safety Assessment (PSSA)
Identify Causes Assess RiskIs Risk
Acceptable?
Verify Mitigation
Implement MitigationIdentify Mitigation
(reduce risk)
Identify causes for each hazard by performing deductive systems analysis (e.g. FTA), and utilizing FHA Failure Mode and Effects relationships.
Assess risk (severity ×likelihood) for each hazard based on hazard severity, likelihood of causes, and causal relationships (AND/OR gates in FTA).
Additional Safety TestRobustness, stress, FMET, & coverage test.
Design/document test cases to verify that implementation achieves planned/desired risk reduction.
Derive/document requirements and/or design constraints to implement mitigation. Trace/follow through design and hardware/ software implementation.
Identify means of risk reduction IAW rules of precedence (design, device, warning, procedures) and DAL/LOR for software.
YES
NO
18
安全なソフトウェアの開発
最重要ポイント:
•安全なソフトウェアは精密に開発されなければならない◦システムエンジニアリングとセイフティエンジニアリングプロセス
Functional Hazard Assessment (FHA)
機能の特定 障害モードの特定 影響を特定 重大度の分類
機能分解分析によるシステム機能階層の特定と記述.
各機能の障害モードを特定し記述する.
各障害モードの影響を特定および記述する
影響の重大度を分類します。重大度がフェーズごとに異なる場合は、フェーズ別に影響度と重大度を特定します
Safety-C
ritical Fu
nctio
ns List
Preliminary Hazard List (PHL)
ハザードの特定(および重大さ）
FHAの機能、類似のシステム、教訓、一般的なリスト、およびFHAの影響を活用して、システムのハザードを識別し、起こりうる最悪の場合の重大度を特定します。
Preliminary Hazard Assessment (PHA)Preliminary System Safety Assessment (PSSA)
原因の特定 リスクの評価
リスクは許容
できるか?
緩和策の検証
緩和策の実践緩和策の特定 (リス
クの低減)
演繹的システム分析（FTAなど）を実行し、FHA障害モードと効果の関係を利用することにより、各ハザードの原因を特定する。
ハザードの重大度、原因の可能性、因果関係（FTAにおけるAND / ORゲート）に基づいて、各ハザードのリスク（重大度×可能性）を評価する。
追加の安全性テスト堅牢性、ストレス、FMET,カバレッジテスト.
実装が計画された/望ましいリスク削減を達成したことを検証するためのテストケースの設計/文書化。
緩和を実施するための要件および/または設計制約を導出/文書化する。デザインとハードウェア/ソフトウェアの実装を追跡/追跡します。
優先順位の手段（設計、デバイス、警告、手順）およびソフトウェアのDAL / LORに基づくリスク削減の手段を特定する。
YES
NO
19
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
20
安全なソフトウェアの開発
•エラークラスの分析◦ソフトウェアのエラーの可能性のあるリストを作成することにより、ソフトウェアアプリケーションのエラーの原因を特定する方法
› ソフトウェアアプリケーションの開発に関わるプロセス、人、ツール、環境の結果
•どのように使用されるか:◦徹底的な検証プログラムの設計（レビュー、解析、テスト）
◦誤りの可能性の体系的な除去または低減
◦航空業界では、RTCA / DO-178B / Cはエラークラス分析を使用した最もよく使用されるアプローチを記録する
21
Safe Software Development
Other Best PracticesPractice What it does
Rigorous Safety
Engineering
Identifies hazards
Assures they are removed or mitigated
Only Use Static Memory
Allocation
Ensures isolation/partitioning of memory by ensuring safety critical memory is not
overwritten by less critical tasks
Only use Safe Subsets of
instruction sets,
technologies, etc.
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
Use of Tools 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
Experience
Provides lessons learned and best practices
Aids in efficiency and problem solving
22
安全なソフトウェア開発
その他のベストプラクティスプラクティス 概 要
精密な安全工学 ハザードの特定
それらが取り除かれたか緩和されたかを確かめる
スタティックメモリの割り
当てのみの使用
重要度の低いメモリが重要度の低いタスクで上書きされないようにすることで、
メモリの分離/パーティション化を保証
命令セット、技術などの
セーフ・サブセットのみの
使用
言語命令セットまたはソフトウェア技術の安全なサブセットを使用することにより、
安全性に重大なソフトウェアパーティションおよびメモリが侵害されないことが保
証される。重要度の低いタスクによる上書きは許可されない
ツールの使用 効率的に作業負荷を減らし、冗長で時間のかかる作業を実行し、プロセスのステッ
プを自動化し、特定の種類のエラーを排除し、構成の制御と問題の報告、要件のト
レーサビリティを行い、構造カバレッジ分析や正式な方法などを実行する
分析の適切な利用 実行時エラーを検出し、スタック、データフロー、セット使用、制御フロー、タイ
ミングとメモリマージン、検証要件カバレッジ分析を実行する。
エンジニアリングのトレー
ニングと経験
学んだ教訓とベストプラクティスの提供
効率化と問題解決の支援
23
Contributing DifficultiesComplex Programmable Logic Devices
Multicore Processors
Real Time Operating Systems for Multicore Processors
Life Cycle Concerns
24
貢献の困難さ複雑なプログラマブルロジックデバイス
マルチコアプロセッサ
マルチコアプロセッサ用のリアルタイムオペレーティングシステム
ライフサイクルの懸念
25
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
26
貢献の難しさ
•プロセッサの速度と能力の急速な進歩により、安全なソフトウェアを開発する上で課題が生じる
•ソフトウェアアプリケーションのサイズと複雑さは指数関数的に急上昇する
•複雑なプログラマブル・ロジック・デバイス（PLD）は現在、何百万ものゲートがあり、しばしば古いソフトウェア機能を置き換える◦ PLDを使用した部品への代替は、元のソフトウェアの設計によっては困難な場合がある
◦ PLDには、知的財産権（IP）を含む商用版（COTS）が組み込まれている◦これらもまた安全でソフトウェアと接続されうる
27
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
Contributing Difficulties
28
マルチコアプロセッサーズ
•これらは、セイフティクリティカルソフトウェアに最新の課題をもたらする
•これらは家庭のコンピュータやインターネットの機能の中で近年に急増している
•マルチコアプロセッサを、速度と機能のアップグレードするために使おうとしているが、現在以下のような課題がある◦リソースの競合◦さまざまな安全レベルにおけるプロセスとスレッド◦優先順位付けの問題◦競合状態の増大など◦テストと検証の問題の増加
Contributing Difficulties
29
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)
Contributing Difficulties
30
リアルタイムオペレーティングシステム (RTOS)
•マルチコアプロセッサには、隔離と分離の保護のために、安全性が重要なアプリケーションニーズをサポートするRTOSが必要
•航空業界で使用できる、認証機関によって認証された市販のRTOSが2つある
•安全性が重要なソフトウェア（ARINC 653準拠）に求められる時間と空間を分割するというニーズをサポートしている
Contributing Difficulties
31
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”
Contributing Difficulties
32
ライフサイクルの懸念
•他に要素も、開発と検証を超えて、安全性の喪失を引き起こす
•使用および保守を実践する過程で安全性の問題が生じる可能性がある
•事例:◦パイロットは、飛行中に危険な状態が何であるかを知る必要がある
◦ソフトウェアエンジニアは、行われた変更が現在の「安全」な機能に影響を与えるかどうかを判断できなければならない。
Contributing Difficulties
33
Industry’s ChallengeCost Mitigations
Technical Mitigations
34
産業界の課題コスト削減
技術的緩和
35
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
36
産業界の課題
•安全なソフトウェア開発には、時間がかかり、コストがかかる
•航空システムでは、顧客および認証機関がソフトウェアを使用することを承認する必要もある
•我々の課題は、さまざまな緩和戦略によってスケジュールとコストの要件を満たしつつ開発すること◦コスト
◦技術面
37
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
Industry’s Challenge
38
コスト削減
•リスクマネジメントの利用◦プログラムのリスクを特定し管理するための積極的な方法
◦プログラム中に管理可能なレベルのリスクを除去または低減すること、もしくは、特定されたリスクごとの計画の策定が含まれる
•ソフトウェアに関連するリスクには、既存のソフトウェア機能を評価して、どのソフトウェアおよび/またはドキュメンテーションを再利用できるかを判断し、どれだけ修正が必要かを判断することが含まれる◦この分析は、チェンジ・インパクト・アナリシスと呼ばれる
◦メリット：既知の安全な現行製品から始めることで、全体的な労力の削減
Industry’s Challenge
39
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
Industry’s Challenge
A WORD OF CAUTION – the danger is accepting too much risk
40
コスト削減
• リスクマネジメントの利用（続き）◦ あまり複雑でないコード開発の領域は、さほど精密に開発する必要がないと判断され、コスト削減の対象となる。
◦ 合理化できるかどうかを判断するために、一部の文書を評価することがある（削減あるいは統合）
◦ コスト削減のために、自動化テスト、または手動テストか自動化のどちらを使うかが評価される
• リスクマネジメントは、適切に使われれば、問題の削減や早期解決を計画し、積極的に取り組むことで、プログラム成功裏に管理するための強力なツールとなる
◦ リスク管理は、死亡、コスト、および機器の損傷の点で言及されることから、航空業界では
悪いイメージをもたれることがある
• リスク管理の最終的な目標は、コストとスケジュールの節約に対してどのレベルまでのリスクを許容できるかを判断すること
Industry’s Challenge
A WORD OF CAUTION –危険とは過剰なリスクを受け入れること
41
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
Industry’s Challenge
42
コスト削減の懸念
• 今日、良い経営といわれるためにはコストを最小限に抑えることを求められる
• 厳しい経営的圧力にさらされると、コストを最小限に抑えすぎるあまり、安全性に問題を引き起こすリスクをかかえがちである。
• 長年にわたる経験から下記のような教訓が得られた:
◦ 文書化は初期費用であり、削減されがちである。 これは、効果的なコスト削減のように見えるが、最終的には、かえってより高くつき、ソフトウェアの安全性の管理と保守を妨げる元凶となりうる。
◦ 残念なことに、構成管理（コンフィギュレーションコントロール）はコスト削減のためのターゲットとなりやすい。しかし、構成の制御がなければ、反復可能な成功は偶然にしか起こりえない。
› （ソフトウェアエンジニアリング研究所（SEI）能力成熟度モデル（CMM）の教義の要約）
◦ ソフトウェア品質保証もコスト削減のターゲットとなりがちだが、ソフトウェア品質保証こそが計画、プロセス、スタンダードを保障しベストプラクティスへ導く
› ソフトウェアの品質保証がないと、成功に達することができない可能性がある
Industry’s Challenge
43
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.
Industry’s Challenge
44
技術的緩和
•私たちは、セイフティクリティカルソフトウェアに向けて安全なアプローチを計画しなければならない
•安全対策戦略を用いて要件と設計を開発する。◦戦略には、アーキテクチャの緩和、以前に承認され認定されたソフトウェアシステムの使用、高度な検証方法が含まれる
◦アーキテクチャの緩和には、冗長性、隔離、モニターの使用、パーティション化、相違性、およびコマンド/権限の制限が含まれる。
Industry’s Challenge
45
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.
Industry’s Challenge
46
技術的緩和RTCA / DO-178Bで次のように定義されている。
• 冗長性
◦ バックアップシステムが利用できることを保証するため、ファンクションまたはシステムを複数持つ
• 分離
◦ 障害を抑止および/または分離し、ソフトウェア検証プロセスの労力を削減することもできる
• モニター
◦ 障害状態に寄与する障害の機能を直接監視することによって、特定の障害状態から保護する手段。監視機能は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせによって実施される。
• 分割
◦ 機能的に独立したソフトウェア機能とコンポーネントとの間の時間と空間の分離である。フォールトを包含および/または分離し、ソフトウェア検証プロセスの労力を潜在的に削減する。
• 相違点
◦ 異なるソフトウェアバージョンとは、通常、ソフトウェア検証プロセスが満たされた後に、何らかの追加の補償を必要とする。システムの安全アセスメントプロセスによって決定されるように、システム機能の潜在的損失が許容可能であることが示され得る場合、異なるソフトウェアへの検証方法は、単一バージョンソフトウェアを検証するために使用した方法を活用することにより減らせる。
• コマンド/権限の制限
◦ 特定の動作が定義された制限内にとどまるように、オブジェクトの操作を命令し、モニターする。これは、例えば飛行機のピッチ、ロール、ヨーの動きを制限するために使用される。
Industry’s Challenge
47
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
Industry’s Challenge
48
高度な検証方法
•より厳しいレベルの安全に欠かせないソフトウェアに使用される
•安全性に重大な影響を与えるアプリケーションをさらに確実にするためにソフトウェア統合レベルで使用される。ソフトウェアアーキテクチャとコードレベル• パスカバレッジ
• 条件/デシジョンカバレッジ
• MC/DC
Industry’s Challenge
49
SummaryConclusion
50
概要結論
51
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
52
概要• セイフティクリティカルソフトウェアのベストプラクティスが何であるかを知っていれば、それは広く使用され、業界で受け入れられるであろう◦ しかし、それを使用する時間とコストのためだけであれば、その限りではない。
◦ 私の最近の経験上いくつかの例がある：› プログラムマネジメントがソフトウェア開発チームに対していちいち指示を出していた会社。
• このプログラムの開発は3年以上ずれこんで、まだ進行中。
› ある企業のあるサイトは、ソフトウェア開発チームの構成管理、検証、または要件のトレーサビリティのためのソフトウェアツールを提供していなかった。
• このプログラムもまた、エラーが訂正されている間に1年近くまでずれこんだ。
› 最近のプログラムでは、アジャイルソフトウェア開発コンセプトの教科書の例を使用した。
• このシステムは安全要件を満たすように再設計されている。
› ソフトウェアインテンシブセイフティクリティカルシステムのサプライヤが、ソフトウェア品質保証機能をプログラム全体にわたって精密かつ一貫してきちんと機能させていなかった
• このプログラムは、エラーが発見され、変更が必要となり、遅延が発生した。
53
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
54
概要
•結論◦まずは、私たちが知っていることを正しく使う。
◦セイフティクリティカルソフトウェアの将来の課題は、新しい技術で革新と創造性を成長させ続けること。技術開発に遅れずに、安全を保証するための新しく斬新な方法を模索し続けなければならない
◦安全なサブセットを理解し、上手に利用するためには、技術を安全に適用できるように、技術を理解しなければならない。
55
Questions?
56
