DO-178BおよびDO-178Cソフトウェア認証規格は、耐空性を有する航空システムを製造するための指針として機能します。1992年に初版が発行されたDO-178B（Software Considerations in Airborne Systems and Equipment Certification）は、ソフトウェアベースの航空システムに関して、EASA（欧州航空安全機関）やFAA（連邦航空局）といった商用当局から必要な認証を取得するために検討すべき重要な文書でした。しかし、2013年に連邦航空規則はDO-178Cを耐空性適合を示す手法として採用しました。DO-178BおよびDO-178C規格に関するより一般的な情報については、こちらの記事をご覧ください。
DO-178BまたはDO178C規格は、以下をはじめとする例示文書によって満たされる必要があります。
- PSAC（Plan for Software Aspects of Certification）
- SDP（Software Development Plan）
- SVP（Software Verification Plan）
- SCMP（Software Configuration Management Plan）
- SQAP（Software Quality Assurance Plan）
- SAS（Software Accomplishment Summary）
DO-178BおよびDO-178C規格を満たすために必要な文書は、これらに限定されません。耐空性を高めるための他の多くの文書が存在します。これらの文書はこちらからご確認・ご購入いただけます。
DO178文書
PSAC文書
PSAC（Plan for Software Aspects of Certification）文書は、ライフサイクルデータの作成に加えて、遵守すべき必要な規格・プロセス・プロトコル・方法論を説明します。これにより、DO-178規格を満たすことができます。PSACはまた、ソフトウェア開発スケジュールとシステム全体のステータスも規定します。この文書は、承認当局と申請者の双方にとって有益なものです。PSACは、ソフトウェアの初期計画プロセス中に作成され、認証当局による承認を受ける必要があります。当社のPSAC文書はこちらからご確認いただけます。
SDP文書
SDP（Software Development Plan）文書は、開発手順、プロトコル、規格、ライフサイクル、開発環境などの必要な情報が定められているかどうかを確認することを目的としています。SDP文書は、ソフトウェア計画プロセスの重要な一部です。当社のSDP文書はこちらからご確認いただけます。
SVP文書
SVP（Software Verification Plan）文書は、必要な試験シナリオとカバレッジ、手順、プロトコル、要件検証、ソースコード検証を規定するとともに、適切なバージョン管理を提供します。SVPも計画プロセスの重要な一部です。当社のSVP文書はこちらからご確認いただけます。
SCMP文書
SCMP（Software Configuration Management Plan）文書は、計画プロセスのもう一つの重要な要素です。ソフトウェア開発プロセス全体を通じて作成された初期計画は、しばしば変更を経ることになります。SCMPは、こうした変更の検出・管理・維持・追跡を助けます。これはソフトウェア開発プロセス全体を通じて適用されます。SCMPは、エラーを最小化し、効率を最大化することを目的としています。チームメンバーは、変更を互いに報告・通知する努力をする必要があります。当社のSCMP文書はこちらからご確認いただけます。
SQAP文書
SQAP（Software Quality Assurance Plan）文書には、製品またはサービスがSRS（Software Requirement specification）に規定された仕様を満たしていることを確認するために使用されるツール、方法、技術が含まれます。SQAPは、プロジェクトにおいてSoftware Quality Assurance活動がどのように実施されるかを説明します。SQAチームはマイルストーンを設定し、各マイルストーンでプロジェクトの品質を評価します。SQAはソフトウェアライフサイクル全体を通じて実施されます。当社のSQAP文書はこちらからご確認いただけます
SAS文書
SAS（Software Accomplishment Summary）は、開発および検証プロセスにおけるソフトウェアコンポーネントのあらゆる段階を要約します。SASには、検証ツール適格性確認からの所見の要約を含める必要があります。SASについてはFAAに通知する必要があります。これにより、認証当局は検証データの所見の妥当性を確認でき、ツールの適格性状況の証拠となります。当社のSAS文書はこちらからご確認いただけます
ARP4754規格とDO178規格
ARP4754は「Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems」の略称です。ARP4754規格は航空機システム全体に対するガイダンスを提供する一方、DO178規格は飛行ソフトウェアのみに使用されます。両規格とも、FAAやEASAなどの当局によって受け入れられています。
ARP4754は、1996年にSAE（Society of Automotive Engineers）によって開発・発行されました。2010年、SAEはGuidelines for Development of Civil Aircraft and Systemsの略称であるARP4754Aを発行しました。ARP4754Aは、航空機およびシステムレベルで使用される設計保証（design assurance）の考え方を充実させるとともに、development assuranceという用語の使用を標準化しました。ARP4754は2011年11月にFAAによって承認されました。
ARP4754は、要件の特定から統合・検証プロセスの終了までの航空機開発サイクル全体をカバーします。ARP4754は、航空機、システム、コンポーネントに対する抽象化を提供します。コンポーネント設計については、ARP4754はDO-178およびDO-254を明示的に参照しています。ARP4754は、開発、設計、検証といった各種プロセスを通じた安全性評価に重点を置いています。ただし、ARP4754にはソフトウェアや電子ハードウェア開発の具体的な範囲、就航後の安全性活動、航空機構造開発プロセスは含まれていない点に留意が必要です。
設計フェーズ
基本設計審査（PDR）
基本設計は、ソフトウェア開発プロセスの重要な段階です。基本設計の段階では、システムアーキテクチャを形成するために、高レベル要件とユースケースが特定されます。設計には、インターフェース・データベース・アーキテクチャに関する文書や、コンポーネント関係の図が使用されることがあります。基本設計は、これらの入力に基づき、プロジェクト開始時点でのシステムの視覚的な描写を提供します。基本設計はまた、後続のより詳細な設計フェーズの土台を築きます。これは草案として捉えることができます。
基本設計審査（PDR）は、プロジェクトの基本設計フェーズを締めくくるものです。PDRは、詳細設計へ進めるための十分な保証を提供する必要があります。PDRの目的は、基本設計と基本的なシステムアーキテクチャが完成していること、そして要件が予算とスケジュールの範囲内で満たせるという技術的な確信があることを確認することです。
詳細設計審査（CDR）
詳細設計審査（CDR）は、プロジェクトの詳細設計フェーズを締めくくるものです。最終設計は、包括的な分析、シミュレーション、回路図、ソフトウェアコード、試験データを通じてCDRで提示されます。CDRは、システムが試験・生産へ進めることを確実にします。また、対象となる要件が予算とタイムラインの範囲内で満たせることも表明します。その結果得られる包括的な図面と仕様は、初期の製品ベースラインとともに最終ベースラインを構成します。CDRは、範囲が広く詳細である必要があります。
最終設計フェーズ
最終設計フェーズは、プロジェクト内の各コンポーネントに関する詳細な構造・工学図面を提供します。一部のプロジェクトでは、最終設計報告書の作成が必要となる場合があります。特定された設計上の問題は、最終設計フェーズが完了する前に解決する必要があります。図面と報告書は、計画的な見積もりを可能にする十分な詳細を提供する必要があります。最終設計報告書には、更新されたスケジュール、コスト見積もり、仕様を含める必要があります。また、プロジェクトが経済的に実行可能であることも確認する必要があります。最終設計フェーズ中に行われる変更は、他のフェーズと比較してコストがかかります。したがって、細心の注意を払って実施する必要があります。
SOI（Stages of Involvement）
プロジェクトのDO-178B準拠を評価するため、計画・開発・検証といったプロジェクトの各段階において、関係国の航空当局によってSOI評価が実施されます。理想的には、合計4回のSOIレビューが計画されます。
第一回のSOI評価は、プロジェクトの認証適合作業における計画段階を対象とします。第二回のSOIレビューは、プロジェクトの開発段階に重点を置きます。高レベルソフトウェア要件の開発から始まり、設計・低レベルソフトウェア要件・ソースコードがDO178Bに準拠して作成されているかどうかを検証します。第三回のSOIレビューは検証段階に重点を置きます。試験活動だけでなく、検証目的で実施されたすべての活動がレビューされます。第四回のSOIは、プロジェクトの終盤に向けて実施される締めくくりの評価であり、未完了の活動の有無、および前回の評価以降に新たな問題が発生していないかどうかを検証します。
計画段階で作成されるソフトウェア製品に対してDO-178Bが求めるのは、当局と実施企業との間で共通の規則群について合意し、プロジェクト全体を通じてこの規則群を遵守することです。言い換えれば、計画書や規格を作成する際、企業は自社のプロセスを定めるだけでなく、認証プロセス全体を通じて当局がどのように自らを評価するかについての規則も併せて記述することになります。
著者: Can Önal（[email protected]）
