DO-178C コンプライアンスへの道

Demystify the who, what, when and why of successful DO-178C compliance.

 
DO-178C/ED-12C（以下DO-178C）は 、連邦航空局（FAA）、 欧州航空安全機関（EASA） 、 カナダ運輸省などの認証機関が、民間航空アビオニクスシステムのソフトウェアの承認にあたり参照する主要な文書です。この文書は、 RTCA（旧Radio Technical Committee for Aeronautics）とEuropean Organisation for Civil Aviation Equipment（EUROCAE） によって共同で発行されています 。

DO-178Cとは何ですか？

DO-178Cは、民間航空電子システム向けに開発されるソフトウェアの正しさと堅牢性を保証するための、ソフトウェアライフサイクル全体（計画プロセス、開発プロセス、および統合プロセス）を網羅する公式のプロセス規格です。統合プロセスには、ソフトウェア検証活動、ソフトウェア品質保証、構成管理保証、そして規制当局との認証リエゾンが含まれます。DO-178Cを含む民間航空電子システム向けに策定された規格は、防衛分野においてもベストプラクティスとして認知されるようになってきています。
 

DO-178C と DO-178B の違いは何ですか?

2012年1月、DO-178Cは長年使用されてきたDO-178B規格に代わり、民間航空分野における組込みソフトウェア開発の事実上の標準となりました。その導入により、民間航空電子システムの開発および検証活動における安全要件と新技術の導入が改善されました。
DO-178Bは現在も認められており、レガシープロジェクトに使用できますが、新規プロジェクトではDO-178Cの使用が強く推奨されています。新規申請者や開発者に対し、DO-178Cに準拠したソフトウェアライフサイクルプロセスを確立することをFAAは推奨しています。
LDRAは、約20年にわたり、DO-178BおよびDO-178Cの両委員会に幅広く参加してきました。LDRAのCEOであるMike Hennellは、構造カバレッジ解析を含む複数の試験測定オブジェクティブを規格に盛り込むことに尽力しました。また、LDRAツールスイート（LDRA tool suite®）は、DO-178B認証のための検証自動化支援の先駆者です。

DO-178C に関連する他の規格は何ですか?

民間航空電子システムに適用可能なソフトウェアシステムの開発において、集合体として使用することを目的とした規格やその他のドキュメントがいくつかあります。
 

DO-178CとSAE ARP4754

SAE ARP4754：民間航空機とシステムの開発に対するガイドライン
ARP 4754はシステム開発の包括的なフレームワークを提供し、DO-178Cはシステム内のソフトウェアの開発と認証に関する具体的なガイダンスを提供します。これら2つの文書は、ソフトウェアコンポーネントを含む航空機システム全体が、航空宇宙産業における認証に必要な安全性と信頼性の基準を満たすことを保証するのに役立ちます。 

DO-178CとSAE ARP4761

SAE ARP4761：民間航空機システムおよび機器の安全性評価プロセス実施のためのガイドラインと方法
ARP 4761は、 ARP4754に従って開発されたシステムの安全性評価を実施するためのガイダンスを提供します。一方、ARP 4754はシステム開発の包括的なフレームワークを提供し、DO-178Cはシステム内のソフトウェアの開発と認証に関する具体的なガイダンスを提供します。

DO-178CとDO-278A/ED-109

RTCA DO-278A 通信、ナビゲーション、監視、航空交通管理 (CNS/ATM) システムのソフトウェアの整合性保証に関するガイドライン。
DO-278Aは、地上システム向けとしてDO-178C（航空機搭載システム向け）と同様の目的を果たし、並行して開発されました。そのため、約75%が類似しています。

DO-178CとDO-330/ED-215

RTCA DO-330：ソフトウェアツール認定に関する考慮事項
「ツール認定」とは、ツールのエラーがシステムの安全性に影響を与えるリスクが許容できるほど低いことを保証するプロセスを指す一般的な用語です。これは、エラーが殆ど無いか、安全性に影響を与えないことを意味します。DO-330は、DO-178CおよびDO-278Aのツール認定を達成するためのガイダンスを提供し、これらの文書への準拠を目指すツールに適用されます。また、補足文書DO-332やDO-333とは異なり、他の分野での使用も想定されています。
LDRAツールスイートは、ツール認定サポートパッケージ（TQSP：Tool Qualification Support Package）を適用することでシームレスにツール認定できます。各TQSPモジュールは、プロジェクト固有の環境で検証ツールとして使用するために、LDRAツールスイートを認定するプロセスを簡素化するための成果物とガイダンスを提供します。

DO 178CとDO-331/ED-216

RTCA DO-331：DO-178C および DO-278A に対するモデルベースの開発および検証の補足
DO-331はDO-178CおよびDO-278Aを補足するものであり、モデルベース開発（MBD）を規定の認証プロセスに統合するためのガイダンスを提供します。
LDRAツールスイートは、モデルから自動生成されたコードと、補足的な手書きコードの両方の検証をサポートします。パートナー企業のモデルベース開発ツールと統合することで、セーフティクリティカルなソフトウェアの開発と検証のためのシームレスなワークフローを提供します。

DO-178CとDO-332/ED-217

RTCA DO-332：DO-178C および DO-278A を補足するオブジェクト指向技術や関連技術
DO-332はDO-178CとDO-278Aを補足するものであり、オブジェクト指向プログラミングおよび補完的なプラクティスの使用時に適用される追加のオブジェクティブが含まれています。また、オブジェクト指向（OO）環境においてDO-178Cのオブジェクティブにどのように取り組むべきかについてのアドバイスも提供しています。
LDRAツールスイートは、C++の包括的なサポートと、すべての言語に同様に適用可能な他のツール属性を通じて、DO-332準拠を支援します。

DO-178CとDO-333/ED-218

RTCA DO-333：DO-178CおよびDO-278Aに対する形式手法補足
DO-333はDO-178CおよびDO-278Aを補足するものであり、ソフトウェアライフサイクルの一環として形式手法を用いる際に適用される追加のオブジェクティブを特定しています。また、形式手法を適用する際にDO-178Cのオブジェクティブにどのように取り組むべきかについてもアドバイスを提供しています。

DO-178CとDO-200/ED-76

RTCA DO- 200：航空データの処理に関する企画
DO-200は、航法、飛行計画、地形/障害物認識、操縦室ディスプレイ、フライトシミュレータ、その他様々なアプリケーションに適用される航空データの取り扱いに関する必須の基準と推奨事項を定めています。データ品質管理の開発、変更評価、および実装支援に関する要件を概説しています。この規格は、航空データベースと関連するデータ処理を対象としており、航空機搭載製品で使用されるDO-178C準拠アプリケーションと直接インターフェースする場合があります。 

DO-178CとA(M)C 20-193

A(M)C 20-193：マルチコアプロセッサの使用
CAST-32Aは、マルチコアプロセッサ（MCP）に関するポジションペーパーであり、Certification Authorities Software Team （CAST）によって執筆されました。マルチコアプロセッサは民間航空の世界では比較的新しい課題であり、このペーパーでは、DO-178C準拠プロジェクトでマルチコアプロセッサが採用された場合に達成すべき一連のオブジェクティブについて説明しています。CASTペーパーは公式のガイダンスではありませんが、権威あるものであり、そのアドバイスは、後に公開される規格に正式に統合される前から採用されることがよくあります。　
CAST-32Aは、EASAおよびFAAの管轄下にあるプロジェクトでは廃止されました。マルチコアプロセッサに関するCAST-32Aの推奨事項は、  EASA AMC 20-193およびFAA AC 20-193 （総称してA(M)C 20-193）という整合規格に組み込まれています。これらの文書に含まれるアドバイスとガイダンスは、DO-178CおよびDO-278Aなどの関連規格を補足することを目的としています。
LDRA ツールスイートのTBwcetは、 MCPの使用によって生じる、干渉パスとそれによる最悪実行時間（WCET）への潜在的な影響に関連する多くの課題をサポートします。

DO-178C準拠には何が含まれますか?

DO-178Cは、ソフトウェアライフサイクル全体、すなわち計画プロセス、開発プロセス、そしてソフトウェアの正しさと堅牢性を確保するための統合プロセスを網羅しています。統合プロセスには、ソフトウェア検証活動、ソフトウェア品質保証、構成管理保証、そして規制当局との認証リエゾンが含まれます。
 

DO-178Cは、ソフトウェアの安全性はソフトウェアライフサイクル全体を通して体系的に取り組まなければならないことを認識しています。これには、ライフサイクルトレーサビリティ、ソフトウェア設計、コーディング、検証、そしてソフトウェアの正しさ、制御性、信頼性を保証するための検証プロセスが含まれます。これらのプロセスが確実に遵守され、その遵守の証拠を提供するために、いくつかのメカニズムが定義されています。
 

DO-178Cで要求される計画文書について

DO-178Cに規定された計画文書は、航空機搭載ソフトウェアの開発と認証のための包括的な枠組みを提供します。これらの文書は、すべての活動が以下の要件に従って計画、管理、検証されることを保証することを目的としています。
 

• Plan for Software Aspects of Certification (PSAC): ソフトウェア開発プロセスが DO-178C 要件に準拠する方法を概説します。
• Software Development Plan (SDP): 方法論、規格、開発環境、構成管理プラクティス、スケジュールを参照しながら、ソフトウェア開発アクティビティの詳細なロードマップを提供します。
• Software Verification Plan (SVP): DO-178C への準拠を保証するためにソフトウェア検証活動を実施する方法を詳細に説明します。
• Software Configuration Management Plan (SCMP): ソフトウェア構成管理プラクティスが実施されていることを確認します。
• Software Quality Assurance Plan (SQAP): 品質保証活動がソフトウェア開発プロセスに統合されていることを確認します。
• Tool Qualification Plan (TQP): ソフトウェアの開発と検証に使用されるツールの認定プロセスの詳細を示します。

 

Stages Of Involvement (SOI) について

DO-178Cでは、4段階のStage of Involvement（SOI）なるレビューが規定されています。これらは、ソフトウェア開発プロセスと出力がDO-178Cの厳格な要件に準拠していることを監査するために設計されています。FAAのDER（Designated Engineering Representative）やEASAのSME（Subject Matter Expert）などの認証局担当者は、特にSOI監査への関与を通じて、DO-178Cプロセスを監督します。SOIレビューは、ソフトウェア開発ライフサイクルの様々な段階で構造化されたチェックポイントを提供し、DO-178Cへの準拠を達成するための規律ある体系的なアプローチを確保します。

DO-178C Software Accomplishment Summary (SAS) について

Software Accomplishment Summaryは、DO-178Cソフトウェア開発および検証プロセスにおけるすべてのステップを網羅した包括的な文書です。ソフトウェア開発活動の要約、検証結果の要約、検証ツールの適格性評価の結果などが含まれます。

DO-178Cセクション5.0: （SOFTWARE DEVELOPMENT PROCESSES）では何がカバーされていますか?

DO-178Cセクション6.0: ソフトウェア検証プロセス（SOFTWARE VERIFICATION PROCESSES）では何がカバーされていますか?

DO-178Cセクション6.0は、ソフトウェア検証プロセスに焦点を当てています。ソフトウェアが要件を満たし、正しく機能することを検証するための目的と方法を概説しています。これには、低レベルテスト、ソフトウェア統合テスト、ハードウェア/ソフトウェア統合など、様々なレベルでのレビュー、解析、テストが含まれます。
動的解析では、「テストケースと手順」（test cases and procedures、DO-178Cセクション6）を用いて、現場で実際に展開される対象を代表させる形で実行可能オブジェクトコード（EOC：Executable Object Code）を実行します。これにより、正しい機能と、それを実現するために実行されたコード部分（「構造カバレッジ」）の両方の証拠が得られます。「テストケースと手順」には、低レベルテスト（ユニットテストと呼ばれることもあります）、統合テスト、システムテストを任意に組み合わせて含めることができます。
低レベルテストは、Software Verification Plan（SVP）に規定された低レベル要件の完全かつ排他的な実装を検証します。一方、ソフトウェア統合テストは、要件とソフトウェアキテクチャを参照しながら、ソフトウェアコンポーネント間の関係を検証します。実際には、低レベルテストで使用されるメカニズムは統合テストにも適しており、コールツリーのコンテキストにおける動作を検証することがよくあります。
変更が行われるたびに、影響を受けるすべての低レベルテストと統合テストを再実行する必要があります（「回帰テスト」）。回帰テストを開発の進行に合わせて再適用することで、新しい開発によって既存の機能が損なわれていないことを確認できます。

構造カバレッジはDO-178C準拠にとってどのように重要ですか?

構造カバレッジ解析は、要件ベースのテストがコードを徹底的に実行したという証拠を提供します。テスト中にソフトウェア構造のどの部分が実行されたかを測定することで、コンプライアンスと安全性の保証の両方をサポートします。必要なカバレッジレベルは、設計保証レベル（DAL）によって異なります。
 

• Modified Condition/Decision Coverage(MC/DC)
  デシジョン（条件判定全体）内の各コンディション（条件）が全体の判定結果に独立して影響を与えることを保証します。DAL Aに必須です
• Decision Coverage
  すべてのデシジョンポイントが少なくとも1回は真と偽の両方に評価されることを確認します。DAL AおよびBに必須です　
• Statement Coverage
  コード内のすべての実行文が少なくとも1回は実行されることを検証します。DAL A、B、Cに必須です
• Data Coupling and Control Coupling Coverage
  モジュール間で渡されるすべてのデータ（データ結合）と制御の相互作用（制御結合）が確実に実行されるようにします。DAL AおよびBでは必須、Cでは推奨です
• Verification of Additional Code Not Traceable to Source
  コンパイラまたはツールによって生成された、ソースコードまで追跡できないオブジェクトコードを、オブジェクトコード検証など追加の検証手法を使用して検証します。DAL Aに必須です

 
ブログ記事「DO-178Cと構造カバレッジ解析」で、関連する原則についてさらに詳しく説明しています。
構造カバレッジの照合には、ソースコードをインスツルメントし、高レベル要件、そして必要に応じて低レベル要件から派生したテストを実行することが含まれます。このプロセスは、テストされていないコード、誤った要件、またはデッドコードの存在を特定するのに役立ちます。LDRAツールスイートが提供する可視化機能は、カバレッジデータの解釈とそれに基づく処理を支援し、検証プロセスをより効率的にします。
 

 
DAL Aソフトウェアの場合、DO-178Cでは、元のソースコードに直接トレースできない追加のオブジェクトコードについても、プログラマーの意図を確実に解釈できるよう解析することが義務付けられています。オブジェクトコード検証（OCV：Object Code Verification）は、ソースコードとアセンブリレベルのカバレッジを比較することで、この課題に対処する体系的な手段を提供します。適切なツールの支援機能により、この多層的なアプローチはコンプライアンスを効率化するだけでなく、最終的なソフトウェア製品の信頼性と確定性に対する信頼度を高めます。
 
構造カバレッジは単なるメトリクスではなく、規律あるテスト、詳細なトレーサビリティ、準拠システムに期待される厳格さに沿った、対象を絞った検証活動を通じて、航空機搭載ソフトウェアの整合性を強化するプロセスです。

データ結合と制御結合はDO-178C準拠にとってどのように重要ですか?

モジュール化（ソフトウェアを明確なインターフェースを持つ明確に定義された機能単位に編成すること）は、長年にわたりソフトウェアエンジニアリングの基本原則となっています。DO-178Cにおいて、この原則は設計でのベストプラクティスであるだけでなく、規制上の期待値でもあり、ソフトウェアコンポーネント間の相互作用、特にデータ結合と制御結合は厳格な精査の対象となります。
DO-178Cは、前身のDO-178Bと比較して、これらの結合の検証に重点を置きます。セクション6.4.4.2.cでは、「要件ベースのテストにおいて、コードコンポーネント間のデータと制御の結合が検証されていることを確認するための解析」の必要性が規定されており、主に設計レベルの解析から、実際のテスト実行から得られる経験的証拠に重点が移っています。
データ結合と制御結合（DCCC：Data Coupling & Control Coupling）はそれぞれ異なるものですが、ソフトウェアコードに関連した特性です。
 
制御結合は、DO-178Cにおいて「あるソフトウェアコンポーネントが別のソフトウェアコンポーネントの実行に影響を与える方法または程度」と定義されています。関数コールカバレッジ（Procedure/Function Call Coverage）は、ギャップを特定し、対象となる検証活動をガイドするために、要件ベースのテストの実行から導き出される必要があります。
 
構造カバレッジ解析はこれらの活動をサポートし、関連するオブジェクティブA-7.8の達成に役立ちます。
データ結合は、規格では「ソフトウェアコンポーネントが、そのソフトウェアコンポーネントの制御下にないデータに依存すること」と定義されています。オブジェクティブA-7.8では、「データ結合と制御結合の両方を含むソフトウェア構造のテストカバレッジを達成すること」が求められています。データフロー解析はすべて、要件ベースのテストから導き出されなければなりません。

LDRAはDO-178Cへの準拠にどのように役立ちますか?

DO-178C規格（特にセクション5.0および6.0）では、コンプライアンスを確認するために、開発の過程で検証および妥当性確認技術を適用しながら段階的に開発を進めることが求められています。LDRAツールスイート の妥当性確認および検証機能は、サードパーティの開発ツールとの統合が容易で、準拠したアプリケーション開発のためのシームレスなプラットフォームを提供します。

静的解析

LDRAツールは、DO-178Cの推奨プラクティスに従ってコードの静的解析を実行します。静的解析は、ソースコードの自動「検査」に例えることができ、レビュー対象のコードを選択されたソフトウェアコーディング規約と比較し、コード品質メトリクスを導き出します。DO-178Cの要件に従って、不適合箇所は、複雑度が高いなどのその他の望ましくない特性とともに強調表示されます。　

動的解析

LDRAツールの動的解析機能を使用するには、低レベル（ユニット）テスト、統合テスト、システムテストの一環として、コードの一部または全部を実行します。ここでの目的は、コードが十分に実行され、要件に従って動作することを示すことです。オンターゲットの動的テスト機能は、コードがターゲット環境に適していることを示す上で特に重要です。　
構造カバレッジは、要件ベーステスト手順の実行中にどのコード構造とコンポーネントインターフェースがテストされたかを特定するために使用され、要件ベーステストの有効性を実証的に測定することを容易にします。その名の通り、構造カバレッジ解析では、構造カバレッジを精査し、十分にテストされていないコード部分があるかどうか、また、テストされていない場合はその理由を特定します。必要なカバレッジレベルは、開発中のソフトウェアの設計保証レベル（DAL）に見合って高くなります。
オプションのTBjustifyモジュールを指定すると、認証およびコンプライアンスの目的で、対象範囲に関する正当性の文書を管理できます。

マルチコアプロセッサ、実行タイミング、干渉の調査

リアルタイムクリティカルなシステムでは、迅速な意思決定プロセスが求められます。これらのシステムは閉ループ制御を採用しており、データの収集、処理、そしてシステムの更新に限られた時間枠しか与えられません。CAST-32AおよびA(M)C 20-193文書で言及されているように、ハードウェア共有リソース（HAR：Hardware Shared Resource）とそれに伴う干渉チャネルは、マルチコアプロセッサ（MCP）上で動作するシステムの開発において特に困難な課題となります。LDRAは、実行時間解析という課題に対応し、最悪実行時間（WCET：Worst Case Execution Time）が割り当てられた時間枠を超えないことを実証するための、独自の柔軟性を備えたツールセットを提供します。

双方向の要件トレーサビリティ

DO-178Cでは、システム要件は開発のあらゆる段階まで追跡可能であるべきであり、コードベース全体が要件まで追跡可能であることを保証するため、その逆もまた同様とされています。LDRAは、双方向のトレーサビリティを実現する包括的なロールベースのアプローチを提供します。
システム要件と検証タスクをチームメンバーに割り当て、結果として得られる成果物をすべて集約しリンクできます。これにより、ライフサイクル全体にわたる完全な双方向プロセスが実現し、要件、設計、ソースコードへの変更を容易に理解、検証、追跡できるようになります。
LDRAツールは、要件や開発されるソフトウェアの変更を検出し、影響を受けるコンポーネントに対して適切なテストを容易に編成・再実行するのに役立ちます。要件や設計の上流、あるいは実装とテストの下流において、影響解析を実施するための最適な環境を提供します。
DAL Aソフトウェアの場合、DO-178Cでは、元のソースコードに直接トレースできない追加のオブジェクトコードについても、プログラマーの意図を確実に解釈できるよう解析することが義務付けられています。オブジェクトコード検証（OCV：Object Code Verification）は、ソースコードとアセンブリレベルのカバレッジを比較することで、この課題に対処する体系的な方法を提供します。適切なツールと連携することで、この多層的なアプローチはコンプライアンスを効率化するだけでなく、最終的なソフトウェア製品の信頼性と確定性に対する信頼度を高めます。
構造カバレッジは単なるメトリクスではなく、規律あるテスト、詳細なトレーサビリティ、準拠システムに期待される厳格さに沿った対象を絞った検証活動を通じて、航空機搭載ソフトウェアの整合性を強化するプロセスです。
 

データ結合と制御結合（DCCC）

LDRA検証ツールは、DO-178Cのデータと制御の結合メトリクスに関する要件を満たす機能を提供します。その目的は、ソフトウェアモジュールがソフトウェア設計で意図された方法でのみ相互に影響を及ぼし、計画外の動作、異常な動作、またはエラーが発生しないことを保証することです。設計中にデータと制御の結合を文書化することで、ソフトウェア統合プロセス中にテストするための一連の要件が提供されます。
 

 
同様に、ソフトウェアテスト中にモジュール間のデータ結合と制御結合が実行され、障害が発生しないことを確認することで、ソフトウェアの統合とアーキテクチャが完全に検証されたことが証明されます。

Modified Condition / Decision Coverage（MC/DCカバレッジ）

レベルAソフトウェアでは、ステートメントとブランチカバレッジに加えて、MC/DCカバレッジが必須です。
MC/DCは、複数の条件判定におけるカバレッジの指標です。すべての可能な組み合わせを実行する必要はなく、条件の数よりも1つ多いテストを実行するだけで済みます。この例では条件が6つあり、合計64通りの組み合わせが可能ですが、MC/DCカバレッジを達成するために必要なテストはわずか7つです。
 

 
ただし、これらのテストでは、各条件が独立して結果に影響を与えることを示す必要があり、どの入力値がそれを達成できるかは必ずしも明らかではありません。LDRA検証ツールは、そのプロセスを自動化するメカニズムを提供します。

ソースコードからオブジェクトコードへのトレーサビリティ

レベルAのシステムでは、ソースコードレベルでの構造カバレッジだけでは不十分です。コンパイラはしばしばコードを追加したり制御フローを変更したりし、どのように変更されるかを前もって知ることは困難です。正しい動作が損なわれないようにするため、DO-178C 6.4.4.2.bではソースコードからオブジェクトコードへのトレーサビリティが求められており、以下のように規定されています。
「ソフトウェアレベルがAであり、コンパイラ、リンカ、またはその他の手段によってソースコードステートメントに直接追跡できない追加コードが生成される場合、生成されたコードシーケンスの正しさを確認するために追加の検証を実行する必要がある」
検証の証拠を提供する自動化メカニズムがあれば、そのプロセスははるかに効率的になります。オブジェクトコードとアセンブリコードの間には直接的な1対1の関係があるため、ツールでこれを表現する一つの方法は、ソースコードのグラフィカル表現と、それに相当するアセンブリコードの表現を並べて表示することです。オブジェクトコード検証（OCV）は、ソースコードとアセンブリコードをそれぞれ順番にインスツルメント化することで、両方のレベルでコードカバレッジを測定します。

証拠資料の照合

DO-178Cに準拠するには、ソフトウェア開発および検証プロセスがDO-178Cに準拠していることを示すために、コンプライアンス実証データ (ドキュメント、記録、証拠の集合) を規制当局に提示する必要があります。
このデータには通常、ソフトウェアがどのように開発、テスト、検証されたかを示すさまざまなレポートと成果物が含まれており、LDRAツールスイートによって生成されるレポートはその目的に適するように設計されています。
例えば、DO-178Cコンプライアンス実証データの主なコンポーネントは次のとおりです。
 

• Software Accomplishment Summary (SAS)
  ソフトウエア開発および検証アクティビティの全体的な概要を提供し、コンプライアンスの位置、タイミング、メモリマージンを示し、逸脱や未解決の問題をまとめます。
• Software Verification Results（SVR）
  レビュー、解析、テストなどの検証活動の結果を一覧表示します。合格および不合格の検証タスクに関する情報に加え、トレーサビリティおよびカバレッジデータも含まれます。
• Traceability Matrix
  ソフトウエア要件、設計成果物、検証アクティビティ間のトレーサビリティを示し、各要件が対応する検証タスクでカバーされていることを確認します。
• Code Coverage Analysis Report
  テストケースによってソースコードがどの程度実行されたかに関する情報を提供します。これは、ソフトウエアが徹底的にテストされていることを確認するために重要です。
• Structural Coverage Analysis Report
  ブランチ、ステートメント、コンディションなど、コード内のさまざまな構造化要素のカバレッジを調べて、テストの徹底度を評価します。
• Object Code Verification Report
  重要なソフトウエア レベルに必要なこのレポートは、バイナリ、すなわち実行可能コードがソース コードと一致し、コンパイル プロセスが正しく実行されたことを示します。

 
このデータは、ソフトウェアが航空機での使用を認証される前に、航空当局に提出され、審査と承認を受けます。従来の労働集約的な方法でこれを達成するには、時間とコストがかかります。
LDRAツールスイートのTBmanagerコンポーネント は、デスクトップトレーサビリティアプリケーションであり、コードレビュー、データ結合・制御結合解析、低レベルテスト、コードカバレッジツールと統合されています。異なるリポジトリ間でも、ソースコードやテストケースに至るまでの要件トレーサビリティマトリックスを常に維持することで、複雑さに伴うプロジェクト管理の課題を軽減します。
LDRAVaultはTBmanagerを補完するツールです。Webベースのエンタープライズレベルアプリケーションで、プロジェクトやプログラム全体の認証成果物を集約・管理し、開発・検証プロセスの透明性を高めます。データアクセスを容易に制御でき、解析結果とコンプライアンス結果を規制当局などの関係者と容易に共有できます。例えば、コードレビュー、コードカバレッジ解析、ユニットテスト結果などが挙げられます。
 

ツール認定

DO -178Cへの準拠に使用する開発ツールは、認定されていることが義務付けられています。LDRAのツール認定サポートパック（TQSP：Tool Qualification Support Packs）には、DO-330ソフトウェアツール認定に準拠したツールスイート自体の構造カバレッジ解析とコーディング規約チェック機能を実証するためのテストケースが含まれています。さらに、製品の開発と検証のための関連ドキュメント（計画、手順、期待される結果など）も提供されます。

認証サービス

LDRA認証サービス（LCS：LDRA Certification Service）は、LDRAの一部門であり、FAAおよびEASAの規格に完全準拠した包括的な認証ソリューションを提供しています。商用および軍用機の耐空証明制度（airworthiness regimens）に精通したLCSは、システムおよび安全性の解析、管理と計画、スタッフのトレーニング、開発、検証など、認証に関連するあらゆる重要なプロジェクト要件に対応できます。 
 
 
原文ページには、各種追加情報へのリンクがあります