RTCA DO-254「Design Assurance Guidance For Airborne Electronic Hardware」は、航空用電子ハードウェア製造の主要な指針であり、最新版は2000年に発行されました。RTCA DO-254は、アビオニクスシステムの設計ライフサイクル要件を規定し、航空機電子ハードウェアの耐空性に関するガイドラインを提供します。 DO-254は、DO-178と同様にRTCAとEUROCAEの協力により発行されました。DO-254は、航空機における各種電子機器の使用増加に対応するため、2005年にFAAによって正式に採用されました。
DO-254への準拠は、乗客・乗務員・運航者の安全性向上に寄与し、組織を強化します。さらに、一部のプロジェクトではDO-254準拠が必須要件となっているため、この準拠を提供していない他の製造・開発企業に対して競争優位性をもたらします。
DO-254認証における主要プロセスは、以下のように要約できます。
- 計画プロセス
- 開発プロセス
- 検証プロセス
開発プロセスは計画プロセスの完了後に開始する必要がありますが、検証プロセスはプロジェクトの開始から終了まで一貫して実施される必要があります。
DO-254規格は、以下をはじめとする文書によって満たされる必要があります。
- PHAC（Plan for Hardware Aspects of Certification）
- HVP（Hardware Verification Plan）
- HVP（Hardware Validation Plan）
- HPAP（Hardware Process Assurance Plan）
- HAS（Hardware Accomplishment Summary）
一部のDO-178文書は、DO-254文書と類似している場合があります。当社のDO-178文書はこちらからご確認・ご購入いただけます。
DO254文書
PHAC
PHAC（Plan for Hardware Aspects of Certification）は、計画プロセス中に作成され、認証当局による承認を受ける必要があります。 PHACは、ハードウェアの認証面を満たすために実施すべき手順・活動、および作成すべき成果物に関して、認証申請者と認証当局との間の合意を反映するものです。 この計画の中で、開発者はDO-254の適用戦略と方法を説明します。 当社のPHAC文書はこちらからご確認いただけます。
ハードウェア検証・妥当性確認計画
Hardware Verification Plan（ハードウェア検証計画）は、ハードウェアが設計要件を満たしているかを確認します。 一方、Hardware Validation Plan（ハードウェア妥当性確認計画）は、ハードウェアがユーザーの運用・機能要件を満たしているかを確認するために使用されます。 前述の定義のとおり、検証（Verification）と妥当性確認（Validation）の根本的な違いは、試験が実施される環境にあります。検証フローでは、設計の正しさが設計要件に照らして確認されます。妥当性確認フローでは、設計の正しさが対象ユーザーの要件に照らして評価されます。 これらの文書も計画プロセスの一環として作成される必要があります。
HPAP
HPAP（Hardware Process Assurance Plan）は、ハードウェア設計ライフサイクルのプロセスとデータが特定され、承認された計画に準拠しているかを確認します。定義された戦略を含め、ハードウェア設計保証目標を満たすために必要な方法が、認証当局に対して提案されます。当社のHPAP文書はこちらからご確認いただけます。
HAS
HAS（Hardware Accomplishment Summary）は、ハードウェア面で達成された内容について認証当局に通知するものです。PHACとHASの違いは、PHACでは認証当局に対して「何を行う予定か」を伝えるのに対し、HASでは「実際に何を行ったか」を伝える点にあります。HASには、承認済みのPHAC文書からの逸脱も示す必要があります。HASには、ハードウェアの識別情報、ハードウェアのステータス、バージョン履歴、および適合宣言を含める必要があります。これは、DO-178準拠に使用されるSoftware Accomplishment Summary文書とも類似しています。HASには、システムおよびハードウェアの概要、ハードウェア設計ライフサイクルの説明、ハードウェアライフサイクルデータに関するセクションを含める必要があります。当社のHAS文書はこちらからご確認いただけます。
設計フェーズ
基本設計フェーズ
基本設計フェーズは、コンセプト設計時に作成された機能ベースラインから始まり、システムレベルの機能要件を、システムを構成するサブシステムの設計要件へと変換する作業へと続きます。この変換には、コンセプト設計で開始された要件分析の継続が必要です。システムのハードウェア、ソフトウェア、要員に関する具体的な要件を定義する必要があります。便益・リスク分析が実施され、基本設計作業の結果として、システムを構成する各サブシステムに要件を割り当てた配分ベースラインが作成されます。
詳細設計フェーズ
詳細設計フェーズは、コスト・スケジュール・リスクの制約の中で規定された性能基準を満たしながら、システムが生産・実証・試験へと進めることを確実にする多分野にわたる技術プロセスです。製品ベースラインは詳細設計フェーズ中に開始されます。詳細設計の目的は、製品ベースライン内の各構成品目について製品仕様に定義された最終設計を評価し、各構成品目が詳細設計文書に組み込まれていることを検証することです。
詳細設計フェーズは、Critical Design Review（詳細設計審査）の実施をもって完了します。CDRは、システムが試験・生産へ進めることを確実にします。また、対象となる要件が予算とスケジュールの範囲内で満たせることも表明します。その結果得られる包括的な図面と仕様は、初期の製品ベースラインとともに最終ベースラインを構成します。CDRは、徹底的かつ包括的である必要があります。
最終設計フェーズ
最終設計フェーズには、プロジェクトの各構成要素に関する正確な構造図・技術図面が含まれます。一部のプロジェクトでは、最終設計報告書の作成が重要となります。特定されたすべての設計上の問題は、最終設計フェーズを完了する前に解決する必要があります。図面と報告書は、スケジュールを提示できる程度に詳細である必要があります。最終設計報告書には、更新されたスケジュール、コスト見積もり、要件を含める必要があります。また、プロジェクトが財務的に実行可能であることも確認する必要があります。最終設計フェーズ中に行われる変更は、それ以前のフェーズで行われる変更よりもコストがかかります。したがって、十分な注意を払って実施する必要があります。
著者: Can Önal（[email protected]）
