Below is an overview covering DO-178C and DO-254, two crucial standards in the aerospace industry. These lines introduce, explain, and compare both standards, their processes, objectives, and common practices.
DO-178C (Software Considerations in Airborne Systems and Equipment Certification)
DO-178C is a guidance document for developing airborne software.
It is published by RTCA, Inc. and recognized by regulatory agencies like the FAA and EASA.
The full name is "Software Considerations in Airborne Systems and Equipment Certification."
It is the successor to DO-178B and includes clarifications and new supplements.
DO-178C provides a framework to ensure software safety and reliability.
It is required for commercial aircraft software that could affect airworthiness.
It defines five software levels, A to E, based on failure impact.
Level A is catastrophic, while Level E has no effect on safety.
The higher the level, the more rigorous the process and documentation.
DO-178C is process-based, not prescriptive in tools or languages.
Planning, development, verification, configuration management, and quality assurance are key processes.
Each process must meet defined objectives depending on the software level.
Verification includes both reviews and testing to confirm requirements are met.
Traceability is essential from requirements through code and tests.
DO-178C mandates independence between development and verification for higher assurance.
Software planning documents include PSAC, SDP, SVP, and more.
Verification documents include test procedures, test cases, and results.
Structural coverage analysis is required at Levels A and B.
Level A requires MC/DC (Modified Condition/Decision Coverage).
DO-178C includes supplements such as DO-331 for model-based development.
DO-330 covers tool qualification guidelines.
DO-332 addresses object-oriented technologies.
DO-333 discusses formal methods as part of software verification.
DO-178C does not directly mandate coding standards but encourages their use.
Common tools used include SCADE, LDRA, VectorCAST, and others.
Certification is usually done in coordination with FAA Designated Engineering Representatives (DERs).
DO-178C is often used alongside ARP4754A for system-level development.
Test independence is required for high-assurance levels.
Software Configuration Index (SCI) and Software Life Cycle Environment Configuration Index (SECI) are outputs.
DO-178C promotes iterative and incremental development cycles.
Review of software design is mandatory for Levels A-C.
Testing must confirm both normal and robustness (abnormal) behavior.
Derived requirements must be tracked and justified.
Each software requirement must be verified.
DO-178C does not focus on performance, just functional safety.
It aligns with the V-Model for system development.
Peer reviews are strongly encouraged, especially for high-level artifacts.
Bidirectional traceability is a core compliance objective.
Safety assessments must guide software level determination.
Software Load Control Procedures are required for Level A/B systems.
DO-178C is applicable to new developments, upgrades, and legacy systems.
Transitioning from DO-178B to C requires careful gap analysis.
Coding errors must be detected early to avoid rework.
Verification metrics are recorded to support certification.
A robust defect tracking system supports the quality process.
DO-254 (Design Assurance Guidance for Airborne Electronic Hardware)
46. DO-254 focuses on airborne electronic hardware instead of software.
47. It is the hardware equivalent to DO-178C.
48. Also published by RTCA and used by FAA and EASA.
49. It applies to complex hardware like FPGAs, ASICs, and PLDs.
50. It does not apply to simple hardware, which is verified solely through testing.
51. Hardware Development Assurance Levels (DALs) mirror software levels A to E.
52. DO-254 enforces structured hardware development and verification processes.
53. Hardware planning includes PHAC, HDP, HVP, and HRP documents.
54. The document outlines objectives for planning, requirements, design, and verification.
55. Requirements capture must be complete, correct, and consistent.
56. Derived requirements must be traceable and justified.
57. The design process includes conceptual, detailed, and implementation phases.
58. DO-254 encourages modular and hierarchical design practices.
59. Like DO-178C, DO-254 requires traceability throughout the development cycle.
60. Verification includes reviews, analysis, simulation, and lab testing.
61. Simulation tools must be qualified for DAL A/B systems.
62. Requirements-based testing is crucial.
63. Structural coverage is required for HDL code (e.g., VHDL or Verilog).
64. FPGA designs must be verified under representative environmental conditions.
65. Like DO-178C, tool qualification is necessary under DO-330.
66. DO-254 aligns with the system-level guidance in ARP4754A.
67. The role of hardware configuration management is central.
68. Documenting baselines, changes, and approvals is critical.
69. A verification matrix maps requirements to tests and results.
70. Reviews are conducted at various design stages.
71. Peer reviews and inspections help catch early defects.
72. The independence of verification is emphasized for higher DALs.
73. Problem reporting and corrective action must be in place.
74. Hardware Process Assurance ensures compliance and process adherence.
75. Certification data must be complete, organized, and auditable.
76. The FAA expects detailed evidence of verification for approval.
77. DO-254 does not define specific design methods, only objectives.
78. Design tools, especially synthesis tools, may need qualification.
79. Hardware reuse is allowed if properly justified and verified.
80. End-to-end traceability from system requirements to test results is mandatory.
81. DO-254 can apply to commercial aircraft, UAVs, satellites, and more.
82. Timing, power, and thermal analysis may be part of verification.
83. Changes after certification must follow strict change control.
84. Documentation is central—poor documentation can delay certification.
85. Risk management is integrated throughout the development cycle.
86. DO-254 supports incremental development and COTS hardware.
87. Multiple DALs may apply within a single hardware project.
88. Failure modes and effects analysis (FMEA) is commonly used.
89. Safety-critical paths must be independently verified.
90. DO-254 requires early and continuous engagement with certification authorities.
91. Field-programmable devices must be frozen before final production.
92. Hardware qualification may involve physical testing under environmental stress.
93. A robust verification environment improves confidence and certification speed.
94. Documentation should clearly show conformance to all objectives.
95. The level of rigor is driven by hardware failure impact on safety.
96. DO-254 development teams must include both design and verification roles.
97. Schedule alignment with software and system teams is critical.
98. Certification credit is only granted with full objective compliance.
99. Certification readiness reviews are part of final approval.
100. DO-254, like DO-178C, is essential for safe, certifiable avionics.
Training for DO-178C (software) and DO-254 (hardware) is offered by several globally recognized providers, both online and in person. Below are some reputable training options for each:
1. AFuzion
Website: www.afuzion.com
Training Type: In-person and online (private or public workshops)
Features:
Global leader in DO-178C and DO-254 training.
Offers certification-ready training with customizable content.
Used by FAA, EASA, Boeing, Airbus suppliers, and many aerospace startups.
They also provide Tool Qualification and DER Services.
2. ConsuNova
Website: www.consunova.com
Training Type: On-demand, virtual, and onsite workshops.
Features:
Offers standard and advanced courses in both DO-178C and DO-254.
Courses taught by FAA-recognized DERs and aerospace engineers.
Includes practical workshops and case studies.
3. RTC Group (Avionics Certification Conference & Workshops)
Website: www.avionicscertconference.com
Training Type: Conferences and certified workshops.
Features:
Focuses on the latest updates, tools, and best practices.
Often hosts AFuzion or ConsuNova instructors.
Good for networking with OEMs and Tier 1 suppliers.
4. SAE International
Website: www.sae.org
Training Type: Online and in-person workshops.
Features:
Technical courses on avionics systems including DO-178C and DO-254.
Training aligned with industry standards like ARP4754A and ARP4761.
Often run by certified engineers and industry experts.
5. Udemy / Coursera (Introductory only)
Training Type: Online self-paced.
Good for:
Basic understanding of avionics certification.
Not suitable for full compliance or engineering team certification.
Great for junior engineers or non-technical managers.
6. Avionics Academy (South Africa)
Occasionally offers DO-178C and system engineering-related workshops.
You may need to request a custom corporate training module.
Check local institutions like CSIR or Denel Aviation for industry workshops.
Courses taught by FAA/EASA-experienced trainers or DERs.
Hands-on case studies (real-world DO-178C objectives, traceability exercises).
Templates and examples of PSAC, SDP, SVP, etc.
Advanced options for Tool Qualification (DO-330), Model-Based Dev (DO-331).
Certificate of completion or record for compliance documentation.
Here's a 100-line breakdown of what’s covered in the key planning documents of DO-178C:
PSAC (Plan for Software Aspects of Certification)
SDP (Software Development Plan)
SVP (Software Verification Plan)
These documents are central to a DO-178C compliance package and are required by certification authorities like FAA/EASA.
Describes the overall approach to meeting DO-178C certification.
Identifies the aircraft/system context and software role.
States the software level (A–E) based on system safety assessment.
Lists all software components and applications.
Describes partitioning and mitigation strategies (if applicable).
Specifies which development processes will be followed.
Lists all applicable supplements (DO-330, DO-331, DO-332, DO-333).
Identifies certification authorities involved (e.g., FAA, EASA).
Describes how software requirements will be derived and validated.
Lists all intended life cycle data items (plans, standards, reports).
Identifies the applicants’ organizations and roles.
Lists all subcontractors and third-party contributors.
Describes configuration management approach.
Summarizes verification strategy (how objectives will be shown).
Defines the tool qualification approach (DO-330 if applicable).
References the SDP, SVP, SCMP, SQAP, and other planning docs.
Details how compliance to DO-178C objectives will be shown.
Contains a certification liaison plan (how authority reviews will be handled).
Lists any COTS (commercial off-the-shelf) software or tools used.
Includes software architecture overview (basic block diagrams).
Details the life cycle model used (e.g., waterfall, Agile, V-model).
Describes software development phases and workflows.
Explains requirements development process.
Outlines design practices and constraints.
Describes low-level design and source code generation practices.
Defines programming languages and coding standards used.
Specifies software modeling tools or methods.
Lists derived requirements handling strategy.
Explains software traceability mechanisms.
Details how consistency across lifecycle data will be maintained.
Lists all development environment tools.
Describes the software build process and release procedures.
Covers software integration strategies.
Defines software unit-level and integration development steps.
Describes developer roles, responsibilities, and required qualifications.
Includes interface control methods and baselining.
Explains peer reviews or inspections in development.
Mentions reuse strategies and handling of legacy software.
Specifies how documentation will be controlled.
References software requirements standards and design standards.
Explains the verification approach for all lifecycle stages.
Identifies the specific objectives to be met for the given DAL.
Details verification roles and responsibilities.
Describes verification independence levels and assignments.
Lists planned reviews and inspections (requirements, design, code).
Specifies types of test environments and target hardware.
Describes unit, integration, and system-level test strategies.
Covers robustness testing for abnormal inputs.
Describes interface testing with hardware and other software.
Lists structural coverage metrics (statement, decision, MC/DC).
Details structural coverage analysis procedures.
Defines criteria for test case creation and traceability.
Includes approach for test procedure development.
Describes how anomalies will be captured and tracked.
Specifies test tool strategy (manual vs. automated).
Lists test tools and their qualification needs (if any).
Describes pass/fail criteria for each test stage.
Describes data recording and analysis strategy.
Covers re-verification criteria and retesting rules.
Details regression testing approach.
Explains the use of simulators or stubs.
Describes result documentation and reporting.
Defines test coverage completeness metrics.
Explains verification records maintenance.
References the Software Verification Results (SVR) data item.
Provides a schedule or milestones for verification phases.
Links to the Test Environment Configuration Index (TECI).
Alignment with overall system development and safety process.
Explicit mapping to DO-178C objectives and corresponding data items.
Handling of anomalies, deviations, and issue reporting.
Description of how corrective actions will be tracked.
Integration of quality assurance in planning and oversight.
Reference to Software Quality Assurance Plan (SQAP).
Planning for configuration audits and reviews.
Use of checklists for reviews and compliance validation.
Treatment of COTS and previously developed software (PDS).
Inclusion of traceability matrices across all artifacts.
Document versioning and update history included.
Plans are usually reviewed by a Designated Engineering Representative (DER).
Authority approval may be required depending on DAL and scope.
Planning documents may be updated during development ("living documents").
Changes must be logged and re-reviewed if they affect objectives.
Final conformity must be demonstrated via the Software Accomplishment Summary (SAS).
Plans are submitted early in the certification process.
Review milestones include SOI-1 through SOI-4 (Stages of Involvement).
Quality of plans directly influences certification success.
Standard templates are often used for consistency.
Tool-generated documents must still meet content requirements.
Plans must be aligned with company and regulatory standards.
The maturity of the plans reflects organizational readiness.
Regulatory audits focus heavily on what is declared in these plans.
Even Agile teams must map to the plan-based structure of DO-178C.
Verification and development must proceed as described in the plans.
Plans must explicitly address how each DO-178C objective is met.
Failure to follow plans can invalidate testing or deliverables.
Planning must include schedules, resources, and tools used.
Authority questions often refer back to declared planning strategy.
PSAC is the anchor document tying all the others together.
These plans are essential to demonstrating airworthiness.
Without well-crafted PSAC, SDP, and SVP documents, certification is not achievable
Below is a professional template for the PSAC (Plan for Software Aspects of Certification), structured according to DO-178C expectations. This document serves as the anchor for all other DO-178C planning and compliance documents. The structure aligns with FAA/EASA guidance and industry best practices.
Project Name: [Insert Project Name]
Software Title: [Insert Software Name]
Software Level: [A/B/C/D/E]
Document Version: [X.Y]
Date: [YYYY-MM-DD]
Prepared By: [Your Company Name]
1.1 Purpose
This document defines the approach to software development, verification, configuration, and quality assurance in compliance with RTCA/DO-178C.
1.2 Scope
Applies to [Project/System Name] software intended for installation on [Aircraft/System Name].
1.3 Project Overview
Brief description of the system, aircraft, or equipment and the function of the software.
1.4 Certification Basis
Applicable certification authority: [FAA / EASA]
Applicable regulations: [e.g., 14 CFR Part 25, Part 23]
2.1 Software Functionality
Summary of the software’s intended functionality and its operational environment.
2.2 Safety Classification
Software Level [A/B/C/D/E], as determined by system safety assessment.
2.3 Software Architecture Overview
Overview of major software components
Interfaces and data flow diagrams (may reference appendix)
2.4 Use of COTS or Reused Software
Description of any COTS tools, reused components, or previously developed software.
3.1 Life Cycle Model
Description of the development model used (e.g., V-model, iterative, agile-hybrid).
3.2 Development Phases
Summary of each phase: requirements, design, code, integration.
3.3 Development Environment
Description of operating systems, languages, compilers, modeling tools.
Lists all related plans and their relationships.
Document
Reference ID
Description
Software Development Plan
SDP-001
Development activities
Software Verification Plan
SVP-001
Verification and testing activities
Software Configuration Plan
SCMP-001
Configuration control process
Software Quality Assurance Plan
SQAP-001
Quality assurance measures
Tool Qualification Plan (if any)
TQP-001
DO-330 compliance for tools
5.1 Objectives Mapping
Table or summary mapping the 71 DO-178C objectives to the project and software level.
5.2 Transition Criteria Between Phases
Description of required criteria to exit each lifecycle phase.
5.3 Traceability
Description of traceability strategy (requirements ↔ design ↔ code ↔ tests).
6.1 Requirements Standards
Description of how software requirements will be written and managed.
6.2 Design Standards
Description of structure, naming, and modularity rules.
6.3 Coding Standards
Coding language(s) used and applicable coding rules.
6.4 Test Standards
How test cases, procedures, and environments will be defined.
High-level overview of how requirements, design, and code will be verified.
Levels of independence for reviews and testing.
Structural coverage goals (statement, decision, MC/DC as applicable).
List of software tools used in the development or verification process.
Indicate which tools require qualification and at what Tool Qualification Level (TQL).
Reference the Tool Qualification Plan (if applicable).
Overview of configuration management processes and tools.
Change tracking, version control, and baseline definition.
Reference SCMP document.
Description of planned audits, reviews, and QA checks.
Independence of quality assurance team.
Reference to SQAP document.
List of all expected deliverables:
Requirements specification
Design documents
Code listings
Test plans, procedures, and reports
Traceability matrices
Problem reports and change requests
Life Cycle Environment Configuration Index (SECI)
Software Configuration Index (SCI)
Software Accomplishment Summary (SAS)
Points of contact for FAA/EASA
Schedule of certification reviews (SOI-1 to SOI-4)
DER involvement and review plan
Define key terms and acronyms used throughout the document.
Appendix A: Software architecture diagram
Appendix B: Objective mapping matrix
Appendix C: Tool listing
Appendix D: Compliance checklist
Version
Date
Author
Description
1.0
YYYY-MM-DD
[Your Name]
Initial draft
1.1
YYYY-MM-DD
[Reviewer Name]
Updates after internal review
Always version-control this document.
Submit PSAC early for authority feedback (prior to SOI-1).
Customize the structure slightly to match your certification authority or DER expectations.