DO-178B

DO-178B「航空機システムおよび機器認証におけるソフトウェアの考慮事項」は、特定の航空機システムで使用されるセーフティクリティカルソフトウェアの安全性を扱うガイドラインです。これは、航空無線技術委員会(RTCA) のセーフティクリティカルワーキンググループ RTCA SC-167 と、欧州民間航空機器機構(EUROCAE)の WG-12によって共同で開発されました。RTCA はRTCA/DO-178Bとして文書を発行し、EUROCAE はED-12Bとして文書を発行しました。技術的にはガイドラインですが、2012 年にDO-178Cに置き換えられるまで、航空電子工学ソフトウェアシステムの開発における事実上の標準でした。

連邦航空局（FAA）は、認証を求める技術基準命令（TSO）で指定されている場合、 ^[1]ソフトウェアが空中環境で確実に動作するかどうかを判断するためのガイダンスとして使用する文書としてDO-178Bを適用します。米国では、耐空性認証プロセスへのTSOの導入、およびDO-178Bの拡張は、連邦規則集（CFR）のタイトル14：航空宇宙（連邦航空規則、パート21、サブパートO としても知られています）で明示的に規定されています。

ソフトウェアレベルは、ARP4754（DO-178CではIDALをソフトウェアレベルと同義としてのみ言及している^{[2] ）で定義されているように、}設計保証レベル（DAL）またはアイテム開発保証レベル（IDAL）とも呼ばれ、システムの故障状態の影響を調べることによって安全性評価プロセスとハザード分析から決定されます。故障状態は、航空機、乗組員、乗客への影響によって分類されます。

• 壊滅的– 故障により墜落が発生する可能性があります。航空機を安全に飛行および着陸させるために必要な重要な機能のエラーまたは損失。
• 危険– 故障により安全性や性能に大きな悪影響が生じたり、身体的苦痛や作業負荷の増加により乗務員の航空機操縦能力が低下したり、乗客に重傷や致命傷が生じたりします。(安全性上重大)
• 重大– 故障は重大だが、危険な故障よりも影響は小さい（たとえば、負傷ではなく乗客の不快感につながる）、または乗務員の作業負荷が大幅に増加する（安全関連）
• 軽微– 障害は目立ちますが、重大な障害よりも影響は小さくなります（たとえば、乗客に不便を及ぼしたり、定期的な飛行計画の変更を引き起こしたりするなど）。
• 影響なし– 障害は安全性、航空機の運航、乗務員の作業負荷に影響を及ぼしません。

DO-178B だけでは、ソフトウェアの安全性を保証するものではありません。設計で機能として実装された安全性属性は、明示的な安全性要件を満たしていることの客観的な証拠を推進し、示すために、追加の必須システム安全性タスクを受け取る必要があります。通常、IEEE STD-1228-1994 ソフトウェア安全性計画が割り当てられ、ソフトウェア安全性分析タスクは、連続したステップ (要件分析、トップレベル設計分析、詳細設計分析、コードレベル分析、テスト分析、変更分析) で実行されます。これらのソフトウェア安全性タスクと成果物は、ハザードの重大度と DAL 決定をシステム安全性評価 (SSA) に文書化するためのプロセスの不可欠なサポート部分です。認証機関は、これらの包括的な分析方法を使用して正しい DAL を確立し、ソフトウェア レベル AE を確立することを要求し、DO-178B はそれを指定しています。安全性が重要な機能をコマンド、制御、監視するソフトウェアはすべて、最高の DAL (レベル A) を受け取る必要があります。システム安全性評価を推進するのはソフトウェア安全性分析であり、DO-178B で適切なレベルの厳密さを推進する DAL を決定します。SAE ARP 4754Aなどの方法と組み合わせたシステム安全性評価により、軽減後の DAL が決定され、冗長性、設計上の安全性機能、その他の危険軽減のアーキテクチャ形式が安全性分析によって決定される要件に含まれている場合、DO-178B ソフトウェア レベル目標の削減が満たされる可能性があります。したがって、DO-178B の中心テーマは、前提条件となる安全性要件が確立された後の設計保証と検証です。

達成すべき目標の数は（最終的には独立性を持って）ソフトウェア レベル AE によって決定されます。「独立性を持って」というフレーズは、ソフトウェア開発チームからの「独立性」によって検証および妥当性確認プロセスの客観性が確保される責任の分離を指します。独立性を持って達成する必要がある目標の場合、項目（要件やソース コードなど）を検証する人物は、項目を作成した人物ではない可能性があり、この分離は明確に文書化されている必要があります。^[3]場合によっては、自動化ツールが独立性に相当することがあります。^[4] ただし、ツール自体が人間によるレビューの代わりとなる場合は、ツール自体が適格である必要があります。

プロセスは、ソフトウェア レベル (A から D、レベル E は DO-178B の範囲外) に応じて目標をサポートすることを目的としています。プロセスは DO-178B では抽象的な作業領域として説明されており、プロセスの実行方法の詳細を定義して文書化するのは実際のプロジェクトの計画者の責任です。実際のプロジェクトでは、プロセスのコンテキストで実行される実際のアクティビティが目標をサポートすることを示す必要があります。これらのアクティビティは、計画プロセスの一部としてプロジェクト計画者によって定義されます。

DO-178B のこの目的ベースの性質により、さまざまなスタイルのソフトウェア ライフサイクルに従うことに関して、大きな柔軟性が得られます。プロセス内のアクティビティが定義されると、プロジェクトはプロセス内でその文書化されたアクティビティを尊重することが一般的に期待されます。さらに、DO-178B によれば、プロセス (およびその具体的なアクティビティ) には明確に定義された開始基準と終了基準が必要であり、プロジェクトはプロセス内のアクティビティを実行する際にそれらの基準を尊重していることを示す必要があります。

DO-178B のプロセスと開始/終了基準は柔軟性が高いため、これらの側面は抽象的で、作業のベースとなるアクティビティの「基本セット」がないため、初めて実装するのは困難です。DO-178B の目的は規範的になることではありませんでした。実際のプロジェクトでこれらの側面を定義するには、さまざまな方法があり、受け入れ可能です。企業がこの標準に基づいて民間航空電子工学システムを開発しようとすると、初めて困難になる可能性があり、DO-178B のトレーニングとコンサルティングのニッチ市場が生まれました。

一般的な DO-178B ベースのプロセスについては、「ソフトウェアおよび複雑な電子ハードウェアのガイダンスと作業支援」で FAA によって定義された関与の段階 (SOI) を含む視覚的な概要が提供されます。

システム要件は通常、プロジェクト全体への入力となります。

最後の 3 つのドキュメント (標準) は、ソフトウェア レベル D には必要ありません。

DO-178B はソフトウェア開発標準として意図されたものではなく、目標と厳密さのレベルを満たすための一連のタスクを使用するソフトウェア保証です。

開発プロセスの出力ドキュメント:

• ソフトウェア要件データ (SRD)
• ソフトウェア設計記述 (SDD)
• ソースコード
• 実行可能なオブジェクトコード

通常、システム要件からすべてのソース コードまたは実行可能なオブジェクト コードまでのトレーサビリティが必要です (ソフトウェア レベルによって異なります)。

一般的に使用されるソフトウェア開発プロセス:

• ウォーターフォールモデル
• スパイラルモデル
• Vモデル

このプロセスによって作成されたドキュメント出力:

• ソフトウェア検証のケースと手順 (SVCP)
• ソフトウェア検証結果 (SVR):
  • すべての要件、設計、コードのレビュー
  • 実行可能なオブジェクトコードのテスト
  • コードカバレッジ分析

通常、すべてのコードの分析と、テストおよび結果からすべての要件までのトレーサビリティが必要です (ソフトウェア レベルによって異なります)。

このプロセスには通常、次のことも含まれます。

• 要件ベースのテストツール
• コードカバレッジアナライザーツール

このプロセスで実行されるテストの他の名前は次のとおりです。

• ユニットテスト
• 統合テスト
• ブラックボックステストと受け入れテスト

構成管理プロセスによって維持されるドキュメント:

• ソフトウェア構成インデックス (SCI)
• ソフトウェアライフサイクル環境構成インデックス (SECI)

このプロセスは、問題レポート、変更、および関連するアクティビティを処理します。構成管理プロセスでは通常、次のアーカイブとリビジョンの識別が提供されます。

• ソースコード開発環境
• その他の開発環境（例：テスト/分析ツール）
• ソフトウェア統合ツール
• その他すべての文書、ソフトウェア、ハードウェア

品質保証プロセスからの出力ドキュメント:

• ソフトウェア品質保証記録 (SQAR)
• ソフトウェア適合性レビュー (SCR)
• ソフトウェア成果概要 (SAS)

このプロセスでは、DO-178B への準拠を示すためのレビューと監査を実行します。認証機関とのインターフェースも品質保証プロセスによって処理されます。

通常、指定エンジニアリング担当者(DER) が、FAA への承認申請の一環として技術データを審査します。

ソフトウェアは、DO-178B プロセスを自動化、支援、または処理したり、支援したりできます。DO-178B 開発に使用されるすべてのツールは、認証プロセスの一部である必要があります。組み込みコードを生成するツールは、組み込みコードと同じ制約を持つ開発ツールとして認定されます。コードの検証に使用されるツール (シミュレーター、テスト実行ツール、カバレッジ ツール、レポート ツールなど) は、検証ツールとして認定される必要があります。これは、ツールの 包括的なブラック ボックス テストで構成される、はるかに簡単なプロセスです。

サードパーティのツールは検証ツールとして認定できますが、開発ツールは DO-178 プロセスに従って開発されている必要があります。このようなツールをCOTSとして提供する企業は、認証機関による監査の対象となり、ソース コード、仕様、およびすべての認証成果物への完全なアクセス権が付与されます。

この範囲外では、使用されるツールの出力は人間が手動で検証する必要があります。

• 問題管理ツールは変更の追跡可能性を提供できます。
• SCI と SECI は、リビジョン管理ツールのログから作成できます。

要件のトレーサビリティは、要件の存続期間を文書化することに関係しています。トレーサビリティを実現するには、各要件の起源までさかのぼって追跡でき、要件に加えられたすべての変更を文書化する必要があります。実装された機能が展開され、使用された後の要件の使用も追跡可能である必要があります。

VDC Research は、DO-178B は今日のエンジニアのニーズや好みにうまく適応していないという点で「やや時代遅れ」になっていると指摘しています。同じレポートで、DO-178Cはこの問題に対処するのに十分であるように思われるとも指摘しています。^{[引用が必要]}

• FARパート23/25 §1301/§1309
• FARパート 27/29
• AC 23/25.1309
• AC20-115B​
• RTCA/DO-178B
• FAA 命令 8110.49 ソフトウェア承認ガイドライン

• DO-178C
• 航空電子工学ソフトウェア
• ARP4761（安全性評価プロセス）
• ARP4754（システム開発プロセス）
• DO-248B（DO-178Bの明確化のための最終報告書）
• DO-254 (DO-178B に似ていますが、ハードウェア用です)
• 要件管理(DO-178B に「直接適用」するには一般的すぎる)
• IEC61508 規格
• ISO/IEC 12207（ソフトウェアライフサイクルプロセス開発標準）
• ED-153 (ANS ソフトウェアの安全性保証に関するガイドライン)
• 修正された条件/決定範囲

• Leslie A. (Schad) Johnson. DO-178B、航空機システムおよび機器認証におけるソフトウェアの考慮事項 (軍用航空機のソフトウェア開発の文脈において、RTCA/DO-178B の現在の実践と適用の進化に関する実務家の議論)。ボーイング民間航空機グループ。2022 年 3 月 3 日閲覧。

• Leanna Rierson (2017 年 12 月 19 日) [2013 年 1 月 7 日]。安全重視のソフトウェアの開発: 航空ソフトウェアとDO-178C 準拠のための実践ガイド。CRC Press。ISBN 9781351834056. 2022年3月3日閲覧。

• AC 25.1309-1A
• AC20-115B
• FAA 命令 8110.49 変更 1