DO-178C and DO-254: avionics software and hardware

Author Hugues Orgitello Last updated 27 May 2026 ~6 min read

Guide · DO-178C / DO-254

DO-178C and DO-254 are the two reference documents recognised by the FAA and EASA for demonstrating the airworthiness of software and electronic hardware embedded in a civil aircraft. Published by RTCA in the United States, mirrored as ED-12C and ED-80 by EUROCAE in Europe, they have since 1992 (DO-178A/B) and 2000 (DO-254) been the accepted process baseline used by regulators to address respectively airborne software and airborne electronic hardware under Federal Aviation Regulations (FAR Parts 23, 25, 27, 29) and the equivalent European Certification Specifications (CS-23, CS-25, CS-27, CS-29). This page describes the architecture of both documents, their relationship with the SAE system-level processes ARP4754A and ARP4761, the Design Assurance Levels and their mapping to failure conditions, the DO-330/DO-331/DO-332/DO-333 supplements, and the pitfalls observed in practice.

A family of process documents, not a regulation

Neither DO-178C nor DO-254 is a regulation. They are technical documents published by RTCA, a private US standardisation body for aviation, mirrored in Europe by EUROCAE as ED-12C and ED-80. Their regulatory force comes from explicit acceptance by certification authorities:

• the FAA publishes Advisory Circular AC 20-115D, which declares DO-178C acceptable as a Means of Compliance for the software aspects of type certification under FAR Parts 23, 25, 27, 29;
• EASA publishes the AMC (Acceptable Means of Compliance) 20-115, which recognises ED-12C (the EUROCAE edition of DO-178C) as a Means of Compliance for CS-23/25/27/29;
• for electronic hardware, the FAA AC AC 20-152A (as revised) and the corresponding EASA position reference DO-254/ED-80.

This acceptance pattern explains a feature of the aviation domain that is often misunderstood: a project does not "certify" a piece of software or hardware in isolation. The DO-178C or DO-254 compliance demonstration is integrated into the certification basis negotiated with the authority for the aircraft type or for the equipment (for example via a TSO/ETSO). Compliance with DO-178C is one Means of Compliance among others theoretically available, even though in practice no other route is used at scale.

For the general CE framework, see the CE page; for the glossary of acronyms (DAL, FHA, PSSA, PSAC, CEH, etc.), see the glossary.

ARP4754A and ARP4761: the system frame around DO-178C and DO-254

DO-178C and DO-254 never address a system as a whole. They address a software item (DO-178C) or an electronic-hardware item (DO-254) that has already been carved out by the system process. That carve-out is the job of two SAE documents:

• ARP4754A "Guidelines for Development of Civil Aircraft and Systems" defines the aircraft and systems development process. It covers functional decomposition, allocation to items, system-level verification and validation, requirements management and the management of Design Assurance Levels. It is itself accepted by FAA AC 20-174 and by EASA AMC 25.1309.
• ARP4761 "Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment" defines the safety-assessment methods: Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA), Common Cause Analysis (CCA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA).

The intended flow is as follows:

[ARP4754A : system development]                  [ARP4761 : safety assessment]
            |                                                    |
            v                                                    v
  Functional decomposition  <------- FHA at aircraft level ----->
            |                                                    |
            v                                                    v
  Allocation to items                            PSSA : DAL allocation
            |                                                    |
            +------ software items ---> DO-178C / ED-12C --------+
            |                                                    |
            +------ hardware items ---> DO-254 / ED-80 ----------+
            |                                                    |
            v                                                    v
   System integration   <----- SSA : verification of safety budget
            |
            v
  Type Certification / STC / TSO / ETSO  (FAA / EASA)

This relationship explains why Design Assurance Level allocation is not a decision taken by the software or hardware designer: it follows directly from the FHA and PSSA conducted under ARP4761, which start from the severity of failure conditions at aircraft and system level and propagate that severity down to items while accounting for architecture (partitioning, redundancy, dissimilarity, monitoring).

DAL to failure-condition mapping

The mapping between failure-condition severity and the DAL that applies to an item is set by ARP4761 and used unchanged by DO-178C and DO-254. It is strictly identical in the two documents: a software item and a hardware item allocated to the same critical function are developed at the same DAL.

DAL	Failure condition	Description (FAR/CS 25.1309)	Max probability per flight hour
A	Catastrophic	Prevents continued safe flight and landing; multiple fatalities	< 1E-9
B	Hazardous / Severe Major	Reduces the crew's ability to operate the aircraft, serious injuries possible, extreme workload	< 1E-7
C	Major	Significant reduction in safety margins or in crew capability, discomfort for occupants	< 1E-5
D	Minor	Slight reduction in safety margins, increased but manageable workload, minor inconvenience	< 1E-3
E	No Safety Effect	No effect on flight safety or crew workload	unconstrained

The probability values are defined at system level by CS-25.1309 / AC 25.1309-1A (and equivalents for the other Parts). They do not apply mechanically to a software item taken in isolation, but to the failure condition resulting from the combination of items. The DAL allocated to an item reflects the assurance effort expected on the process of development, not a probability that can be directly quantified for software (software has no statistical "failure rate" in the hardware sense).

DO-178C: objective architecture

DO-178C structures its requirements as objectives, grouped into three families of process activities and listed in the Annex A tables (Tables A-1 through A-10). It is the objective-per-table structure that gives the document its process-centric character.

The three process pillars

• Planning: production of plans (PSAC, SDP, SVP, SCMP, SQAP) and standards (Software Requirements Standards, Software Design Standards, Software Code Standards). These documents are produced at the start of the programme and submitted to the authority for acceptance.
• Development: high-level software requirements (HLR), low-level software requirements (LLR), software architecture, source code, executable object code.
• Integral processes: verification, configuration management, software quality assurance, certification liaison. These run in parallel with development and gate final acceptance.

Decreasing objectives with the DAL

At DAL A, the full set of objectives across Tables A-1 to A-10 applies, with a portion requiring independence between the person producing an artefact and the person verifying it. Moving down to lower DALs operates on two levers:

1. some objectives drop (an objective applicable at DAL A may be marked "not applicable" at DAL C or D),
2. some objectives lose the independence requirement, which is a different relief but reduces the organisational cost.

The total number commonly cited in the professional literature is 71 objectives at DAL A. The exact count per DAL must be read from Annex A of DO-178C, which is the authoritative source; DO-178B and DO-178C do not have identical counts (DO-178C reorganised and clarified several objectives).

DAL	Assurance effort expected
A	All applicable objectives, maximum independence, Modified Condition/Decision Coverage (MC/DC) on the executable code
B	Large subset, independence on most objectives, Decision Coverage required
C	Reduced subset, lower independence, Statement Coverage required
D	Minimal subset, little independence, requirement-driven verification only
E	No DO-178C activity required (the item is treated outside DO-178C with a justification of safety-effect absence)

The MC/DC (Modified Condition/Decision Coverage) requirement at DAL A is arguably the most discriminating requirement in the document: it demands that, during testing, each boolean condition of a decision has independently affected the decision outcome. For non-trivial embedded code, this requires test benches that are specifically instrumented, and analytical coverage that is often automated.

Independence: an often under-estimated lever

Independence is one of the most structuring concepts in DO-178C. Independence does not mean "double verification" but rather organisational separation: the person who produces an artefact (for example the Low-Level Requirements) cannot be the same as the person who verifies it. The separation can be organisational (two distinct people, distinct teams) or tooled (a qualified verification tool whose DO-330 qualification guarantees objectivity).

Independence is required at DAL A on most verification objectives, partially required at DAL B (independence on a reduced subset), and generally absent at DAL C and D. This grading has a direct impact on project team size: a DAL A programme almost always requires a verification team distinct from the development team, which for medium-sized programmes represents a significant cost frequently under-estimated at the start.

Coverage criteria by DAL

The coverage criteria required vary with the DAL and are one of the most visible cost differences between levels. Three criteria stack in practice: requirements coverage (each requirement is demonstrated by at least one test case), structural code coverage, and coupling coverage analysis.

DAL	Requirements coverage	Structural coverage	Coverage Analysis
A	100% HLR + 100% LLR	Modified Condition/Decision Coverage (MC/DC) on executable code, plus Decision Coverage, plus Statement Coverage	Data Coupling and Control Coupling required
B	100% HLR + 100% LLR	Decision Coverage plus Statement Coverage	Data Coupling and Control Coupling required
C	100% HLR + 100% LLR	Statement Coverage	Data Coupling and Control Coupling required at module level
D	100% HLR	No structural coverage required	Not specified
E	Not applicable	Not applicable	Not applicable

Data Coupling analysis verifies that every data item exchanged between components is exercised by the tests. Control Coupling analysis verifies that all invocation paths between components are exercised. These two analyses, tightened by DO-178C relative to DO-178B, often generate additional test cases late in the cycle, which surprises programmes that under-estimated that workload.

DO-178C documentary deliverables

Deliverable	Acronym	Role
Plan for Software Aspects of Certification	PSAC	Master document, submitted to the authority, that declares the compliance strategy, the DAL selected, the supplements applied (DO-330/331/332/333), and any deviations
Software Development Plan	SDP	Describes the adopted development cycle (waterfall, iterative, etc.), the phases, the reviews, the responsibilities
Software Verification Plan	SVP	Describes the verification strategy: reviews, analyses, tests, coverage, traceability
Software Configuration Management Plan	SCMP	Describes configuration management of artefacts, version control, baselines
Software Quality Assurance Plan	SQAP	Describes the SQA organisation, its independence, its audit plan
Software Requirements / Design / Code Standards	(standards)	Three distinct standards that codify writing and review rules
Software Requirements Data	HLR	High-level software requirements, derived from the system requirements
Software Design Description	LLR + Architecture	Low-level software requirements and software architecture
Source Code	(code)	Source code conforming to the Software Code Standards
Executable Object Code	(binary)	Binary produced by the tool chain; tools may be subject to DO-330 qualification
Verification Results		Review, analysis and test results, with coverage
Software Configuration Index	SCI	Index of artefacts in a release baseline
Software Accomplishment Summary	SAS	Closure document, submitted to the authority, summarising the compliance demonstration

The real list can be longer (Software Life Cycle Environment Configuration Index, Problem Reports, Software Change History, and so on). The PSAC declares the effective list applicable to the programme.

The four DO-178C supplements

DO-178C was published in 2011 alongside four supplements that are not meant to be read on their own: they are invoked only as a complement to DO-178C, each targeting a particular development style or technology.

Supplement	Topic	Purpose
DO-330	Software Tool Qualification Considerations	Defines criteria and process for qualification of the software tools used in the cycle (verified compilers, code generators, coverage tools, static analysis tools). Five Tool Qualification Levels (TQL-1 to TQL-5) depending on the impact of the tool on the final product and on whether the tool is a development or a verification tool
DO-331	Model-Based Development and Verification Supplement	Extends DO-178C objectives when some or all of the requirements or design are expressed as formal models (e.g. SCADE, Simulink/Stateflow) and when code generation is automated
DO-332	Object-Oriented Technology and Related Techniques Supplement	Adds objectives when the code uses object-oriented techniques (inheritance, polymorphism, dynamic allocation, exceptions) and related techniques (genericity, virtualisation) that raise traceability and verification questions not covered by baseline DO-178C
DO-333	Formal Methods Supplement	Extends DO-178C objectives when formal methods (theorem proving, model checking, abstract interpretation) are used to satisfy some or all of the verification objectives, either replacing or complementing testing

A typical project applies DO-178C alone. A model-based project applies DO-178C + DO-331 + DO-330 (code-generation and verification tools usually being qualified). A C++ project applies DO-178C + DO-332. A high-criticality project relying on formal proof may combine DO-178C + DO-333 + DO-330.

Tool Qualification Levels TQL-1 to TQL-5

DO-330 defines five Tool Qualification Levels, from TQL-5 (minimal effort) to TQL-1 (effort comparable to developing a DAL A software item). The level is set by crossing two dimensions: the tool category (Criteria 1, 2 or 3, encoding the impact of the tool on the final product) and the DAL of the software produced.

Tool category	Description	TQL at DAL A
Criteria 1	The output of the tool is part of the embedded software (typically an automatic code generator). A tool defect can introduce a defect in the embedded binary	TQL-1
Criteria 2	The tool automates a verification activity AND selects the artefacts to verify (typically an automated test bench that picks cases and evaluates results without intermediate human verification)	TQL-4
Criteria 3	The tool automates a verification activity without selecting artefacts (typically a coverage counter, a static analysis tool in preprocessing, a binary comparison tool)	TQL-5

At lower DALs, the required TQL drops. At DAL D, almost all Criteria 3 tools require no formal qualification, only a justification. The practical rule: if the tool produces the embedded binary (Criteria 1), its qualification is the largest effort of the project after the software itself.

DO-331 and certifiable code generation

DO-331 treats three categories of models: specification (the model expresses requirements), design (the model expresses architecture and behaviour), and implementation (the model is generated as code and the code is embedded). Several commercial tool chains (ANSYS SCADE Suite, MathWorks Embedded Coder with Polyspace) offer qualifiable generators that cover the DO-331 objectives along with their DO-330 qualification.

The key issue in DO-331 is model-to-code equivalence: traceability between the source model and the generated code must be demonstrated, and the required coverage applies either to the model (model coverage) or to the code (object code coverage) depending on the case. The supplement also clarifies the status of derived elements of modelling that do not appear in upstream requirements (for example, automatically generated internal states).

DO-333 and the status of formal methods

DO-333 recognises three categories of formal methods usable to satisfy verification objectives: deductive proof (theorem proving, for example with Coq, SPARK/Ada, Frama-C), model checking (exhaustive verification of a finite model), and abstract interpretation (for example with Astree for the proof of absence of run-time errors on C code). The supplement does not mandate one particular method; it sets the conditions under which a formal method may substitute for a test in demonstrating an objective.

Formal methods usage in aviation remains a minority by volume but is growing on the highest-criticality functions. The economic case appears when the cost of testing and its coverage (typically MC/DC at DAL A) exceeds the cost of proof, which happens on small but maximally critical functions (primary flight surface control, for example).

DO-254: assurance for airborne electronic hardware

DO-254 treats electronic hardware with a process approach equivalent to that of DO-178C, adapted to the specifics of hardware.

General structure

The body of DO-254 defines a hardware life cycle: planning, requirements, conceptual design, detailed design, implementation, transition to production. It identifies integral processes equivalent to DO-178C: verification, validation, configuration management, process assurance, certification liaison.

DALs A through E are identical to those of DO-178C in meaning (mapping to failure conditions), with the same propagation from ARP4761. Verification and validation effort scales with DAL.

Appendix B: Complex Electronic Hardware

The Appendix B of DO-254 sets additional considerations for Complex Electronic Hardware (CEH): parts whose complexity prevents exhaustive verification through testing alone. In practice, Appendix B applies to FPGAs, ASICs and complex PLDs developed for the programme, and possibly to certain highly integrated programmable parts.

Appendix B extends the hardware life cycle in several ways:

• verification of logic programming (VHDL/Verilog RTL) with functional and structural coverage equivalent in spirit to software code coverage,
• tool qualification for synthesis, place-and-route, simulation and bitstream generation, in a logic parallel to DO-330 on the software side,
• design data management (schematics, RTL, timing constraints, configuration files) under strict configuration management,
• handling of derived requirements with feedback to the ARP4761 safety assessment.

A simple electronic component (resistor, capacitor, discrete transistor, standard voltage regulator) stays within the general DO-254 perimeter but outside Appendix B. Its qualification relies on the manufacturer specification, environmental qualification (DO-160 for environmental tests) and selection under reliability criteria.

Commercial components versus custom electronic hardware

DO-254 distinguishes two situations for electronic hardware:

• Component Off-The-Shelf (COTS): a commercial part purchased from a vendor catalogue, with no visibility on its internal development. The aircraft programme must justify the use of the part through its specification, its aviation service history (Service Experience), additional tests where necessary, and a manufacturer errata analysis where appropriate.
• Custom Electronic Hardware developed in-house: a specific circuit designed for the programme, or an FPGA programmed by the team. The full DO-254 cycle applies, and Appendix B is invoked if the complexity warrants it.

That distinction is the subject of many review discussions: the boundary between COTS, CEH and "complex part" is not binary, and the authority's position can vary across programmes and across the service history of the part.

Transition to production

DO-254 covers a transition to production phase: the cycle does not end at prototype delivery, it must demonstrate that the industrial process reproduces the verified unit. For an FPGA, that covers bitstream traceability, programming sequence, production test. For a PCB, it covers assembly procedures, production tests (ICT, AOI, X-ray) and obsolescence management.

Verification techniques within Appendix B

Appendix B identifies a set of verification techniques that the programme can combine to reach a given DAL. The main ones are:

• Element Analysis: analysis of the functional decomposition of the complex part, identifying internal blocks and their role in the declared function,
• Architectural Mitigation: explicit use of redundancy, partitioning, dissimilarity, monitoring to reduce the effective DAL of a sub-block. For example, two independent DAL B blocks can collectively achieve a DAL A function if independence and dissimilarity are demonstrated,
• Design Assurance Methods: verification through exhaustive functional simulation (over a bounded perimeter), review, hardware prototyping, on-target testing,
• Service Experience: use of a documented service history to anchor part of the assurance demonstration. This path is restrictive and reserved for parts with significant and traceable flight history.

Design Assurance Methods are rarely used alone; a typical project combines several techniques with a coverage justification argued in the PHAC.

Coverage on RTL code

For FPGAs and ASICs under Appendix B, verification relies on coverage criteria analogous to those of DO-178C but adapted to RTL:

RTL coverage	DAL A	DAL B	DAL C
Statement coverage (every RTL statement is exercised)	Yes	Yes	Yes
Branch coverage (every if/case branch is taken in both directions)	Yes	Yes	Recommended
Condition coverage (every boolean condition takes both values)	Yes	Yes	Optional
MC/DC equivalent (each condition of a decision independently affects the outcome)	Yes (at DAL A)	Optional	No
Toggle coverage (every signal bit has transitioned 0 to 1 and 1 to 0)	Yes	Yes	Recommended
FSM coverage (every state and every transition of a state machine is reached)	Yes	Yes	Yes

These criteria are usually achieved in simulation with a qualifiable coverage tool (Mentor Questa, Cadence Xcelium, Synopsys VCS in their instrumented variants). Qualifying the coverage tool is itself a DO-330-like sub-project adapted to hardware.

DO-160: a frequent companion to DO-254, often confused with it

A common confusion involves DO-160 "Environmental Conditions and Test Procedures for Airborne Equipment". DO-160 is neither DO-178C nor DO-254: it specifies environmental tests (temperature, altitude, vibration, shock, humidity, EMC, lightning, ESD) that airborne equipment must pass. DO-160 applies to any equipment regardless of DAL, and produces an environmental test report, not a process assurance file. DO-254 and DO-160 are complementary: DO-254 addresses design assurance, DO-160 addresses environmental qualification of the realised hardware.

Certification liaison: the authority interface

Both DO-178C and DO-254 provide for a formal certification liaison process between the supplier and the authority. This axis is often under-estimated, yet the quality of that interaction is what determines the smoothness of certification.

Typical milestones are the Stage of Involvement (SOI) audits:

• SOI 1: review of plans (PSAC, SDP, SVP, SCMP, SQAP) at the start of the programme,
• SOI 2: review of standards and of the initial development phase,
• SOI 3: review of verification (coverage, test results, traceability),
• SOI 4: final review, conditioning certificate issuance.

On the FAA side, the dialogue runs through the relevant Aircraft Certification Office (ACO), sometimes with delegation to a Designated Engineering Representative (DER) for the review of software and hardware artefacts. On the EASA side, the dialogue runs through EASA inspectors or through a national authority operating under mandate, and the supplier organisation usually holds a Part 21J (design) and Part 21G (production) approval.

The PSAC on the software side, and its equivalent PHAC (Plan for Hardware Aspects of Certification) on the hardware side, are the documents that frame this liaison contractually. Their revision is treated as a renegotiation of the certification basis: they are typically very stable once initially accepted.

Reuse: Previously Developed Software and Service Experience

DO-178C explicitly recognises the reuse of previously developed software artefacts. Two mechanisms coexist.

Previously Developed Software (PDS) designates a piece of software or a software component already certified on a prior programme (for example, a computation library, a certified RTOS, an ARINC communication stack). Reusing PDS in a new programme requires demonstrating three points: the prior usage domain covers the target usage, upstream documentation is available and consistent with the new context, and the execution environment (target, compilation, integration) is equivalent or the deviations are justified. When those conditions are met, PDS avoids redoing the full DO-178C effort. In practice this applies to certified math libraries, RTOSes such as VxWorks 653, INTEGRITY-178, PikeOS, and ARINC 653 stacks.

Service Experience designates the use of operational history of a piece of software to anchor part of the assurance. This path is highly restrictive: it requires significant flight history, traceable to the exact software version, and documented incident and anomaly reporting. In practice, Service Experience is rarely the main path, more often a complement.

DO-254 offers an equivalent path on the hardware side via Service Experience applied to COTS: a part with a long avionic service history may be accepted more readily than a brand-new equivalent part, but the weight given to that history remains at the authority's discretion and is discussed on a case-by-case basis.

Software and hardware at integration: consistency of the bases

Consistency between the DO-178C software demonstration and the DO-254 hardware demonstration is not built at integration time; it is built upstream through ARP4754A. Several cross-cutting topics deserve specific attention:

• DAL allocation: if a software item and a hardware item collaborate on the same critical function, their DALs may be identical (the simple case) or differentiated if the architecture justifies it. For example, two dissimilar channels developed respectively as DAL B software and DAL B hardware can collectively implement a DAL A function if dissimilarity is demonstrated in the ARP4754A sense.
• Partitioning: separation between software items of different DALs on a common platform (ARINC 653 partitioned RTOS, certified hypervisor) must be demonstrated by the RTOS or hypervisor itself, which is then either a PDS or an item developed at the highest DAL of the partitions it hosts.
• Hardware/Software Interface (HSI): the interface document between hardware and software is a specific deliverable that is often neglected. It pins down the memory map, registers, interrupts, configuration sequences. A stable HSI is a prerequisite for on-target software verification.
• Cross-verification: some system requirements are satisfied by a software + hardware combination (for example, a software timeout backed by a hardware watchdog). Cross-verification must be planned in both PSAC and PHAC.

See also

• DO-326A and ED-202A: avionics cybersecurity airworthiness
• MIL-STD-461 and MIL-STD-464, defense EMC standards
• AEC-Q100, Q101, Q200: automotive component qualification
• IATF 16949: automotive quality management

Working on cross-cutting framing of an assurance-heavy programme (ARP4754A / DO-178C / DO-254 reading) for a real product? AESTECHNO can audit your design and certification plan. Get in touch →

Articulation with other assurance standards

DO-178C and DO-254 are not the only software and hardware assurance frameworks. Other regulated domains use neighbouring frameworks, sometimes heavily inspired but legally independent:

• automotive applies ISO 26262, with Automotive Safety Integrity Levels ASIL A to D and a V-cycle documentation pattern conceptually close to DO-178C;
• general industry and rail apply IEC 61508 and its derivatives (IEC 61511 for process industry, EN 50128 for railway software, EN 50129 for railway systems), with Safety Integrity Levels SIL 1 to 4;
• medical applies IEC 62304 for software and a combination of IEC 60601-1 and ISO 14971 for the equipment, on a software-safety-class basis (Class A/B/C) and a clinical-risk basis.

These standards share a common grammar: separation of planning, development and verification; traceability from requirements to design, code and tests; configuration management; tool qualification; graded assurance levels. They are not interchangeable, however: DO-178C has no regulatory standing in automotive, ISO 26262 has none in avionics. The mapping between levels (DAL, ASIL, SIL) is the subject of a substantial body of literature but is never formally recognised by the authorities.

FAA versus EASA submission

On substance, the FAA and EASA recognise DO-178C/DO-254 equivalently. On process, several nuances are worth noting for a dual programme.

Aspect	FAA	EASA
Regulatory text	FAR Parts 23/25/27/29	CS-23/25/27/29
Software acceptance	AC 20-115D	AMC 20-115
Hardware acceptance	AC 20-152A (as revised)	EASA equivalent position
Reference adopted	DO-178C / DO-254 (RTCA)	ED-12C / ED-80 (EUROCAE)
Technical instruction	ACO plus optional DER	EASA or approved national authority
Supplier organisation	TSO/PMA for some production	Part 21J (design) + Part 21G (production)
Mutual recognition	US-EU BASA, executive procedures FAA-EASA	same on the European side

In practice a dual programme PSAC is unified: it declares a single DO-178C compliance strategy submitted concurrently to both authorities, leveraging the BASA. Divergences mostly concern SOI scheduling and administrative paperwork.

Common pitfalls observed in programmes

Without claiming to cover every review topic, several issues recur in the public literature and in industry feedback.

• Late invocation: bringing DO-178C/DO-254 into the picture after integration phase, when upstream documentation (plans, high-level requirements, traceability) has not been produced in real time. Reconstructing it after the fact is technically feasible but very expensive, and some objectives (notably those requiring independence in reviews) cannot be demonstrated retroactively.
• DAL allocated without safety assessment: choosing a DAL by hypothesis or by customer requirement, without a documented FHA/PSSA under ARP4761. The allocation becomes indefensible at SOI 1 and the programme must redo the safety analysis.
• Confusion DO-178C / DO-254 / DO-160: applying DO-160 (environmental tests) under the assumption that it covers DO-254 (design assurance), or the reverse. The three documents are complementary, not interchangeable.
• Non-qualified tools: using a code-generation, coverage or static-analysis tool without a DO-330 qualification effort. If the tool "eliminates, reduces or automates" a verification activity, qualification is required according to the DAL.
• Broken traceability: gaps between system requirements, HLR, LLR, code and tests. SOI 3 typically fails when the traceability chain is incomplete or not bidirectional.
• MC/DC misunderstood at DAL A: confusion between decision coverage (each decision has taken the values true and false at least once) and MC/DC (each condition has independently driven the decision outcome). A 100% decision coverage does not demonstrate MC/DC.
• Confusion COTS / CEH / Appendix B in DO-254: a pre-programmed catalogue FPGA does not become COTS; it remains CEH if its configuration is project-specific. Conversely, a very simple FPGA may fall outside Appendix B on the basis of a documented justification.
• PSAC frozen too early: a PSAC written too early, without enough clarification of the architecture and the software perimeter, forces renegotiation of the certification basis at each iteration. Conversely, a delayed PSAC saturates SOI 1.

Further reading

This page describes the general DO-178C/DO-254 frame. For cross-domain reading with other assurance frameworks, see ISO 26262 (automotive) and IEC 61508 (general industry). For the full glossary (DAL, FHA, PSSA, PSAC, PHAC, SOI, DER, CEH, MC/DC), see the glossary.

Need help?

A 30-minute audit with AESTECHNO engineers.

AESTECHNO is the electronics design house that edits spilma. We help product teams scope their certification effort and avoid the common mistakes.

Book a free audit

Sources & references

1. RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification , RTCA www.rtca.org/
2. RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware , RTCA www.rtca.org/
3. EUROCAE ED-12C / ED-80 (European counterparts of DO-178C / DO-254) , EUROCAE www.eurocae.net/
4. FAA Advisory Circular AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178 , FAA www.faa.gov/regulations_policies/advisory_circulars
5. EASA AMC 20-115, Software Aspects of Certification , EASA www.easa.europa.eu/en/document-library/general-publications/easy-access-rules-acceptable-means-compliance-and-guidance
6. SAE ARP4754A, Guidelines for Development of Civil Aircraft and Systems , SAE International www.sae.org/standards/content/arp4754a/
7. SAE ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment , SAE International www.sae.org/standards/content/arp4761/