What is the regulatory status of DO-178C and DO-254?

DO-178C (Software Considerations in Airborne Systems and Equipment Certification) and DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) are RTCA documents, published in Europe by EUROCAE as ED-12C and ED-80. They are not regulations. The FAA recognises DO-178C as an acceptable means of compliance in AC 20-115D and DO-254 in AC 20-152A (7 October 2022); EASA does the same in AMC 20-115D and AMC 20-152A. They become binding for a programme through its certification basis and the plans the authority accepts.

What are the levels A to E?

Each software or hardware item gets a level from the failure condition it can contribute to: A catastrophic, B hazardous, C major, D minor, E no safety effect. The level is assigned by the system development and safety assessment processes (ARP4754B and ARP4761A since December 2023), not chosen by the software or hardware team.

How many DO-178C objectives apply at each level?

The Annex A tables of DO-178C list 71 objectives at level A (30 with independence), 69 at level B (18 with independence), 62 at level C (5 with independence) and 26 at level D (2 with independence). Level E has none. The difference between A and B is small in count but large in effort, because level A adds MC/DC structural coverage and verification of object code that is not directly traceable to source.

Is DO-254 Appendix B the FPGA appendix?

No. Appendix B of DO-254 gives additional design assurance considerations for level A and B functions: architectural mitigation, product service experience and advanced verification methods such as elemental analysis, safety-specific analysis and formal methods. FPGA, ASIC and PLD devices are "custom micro-coded components" in DO-254 section 1.2, and since 2022 AC 20-152A (and AMC 20-152A in Europe) gives the detailed objectives for them, including criteria for classifying a device as simple or complex.

Is DO-254 required for DAL D hardware?

Not under AC 20-152A. The AC applies to airborne electronic hardware contributing to DAL A, B or C functions and says its use is not required for DAL D, pointing to AC 00-72 for best practices. At DAL C only a limited set of its objectives applies.

What replaced CAST-32A for multicore processors?

AMC 20-193, adopted by EASA in January 2022, and AC 20-193, issued by the FAA on 8 January 2024. Both are based on the CAST-32A position paper and are technically aligned, so a multicore programme can use one set of objectives for both authorities.

What are the main DO-178C deliverables?

The Plan for Software Aspects of Certification (PSAC), the development, verification, configuration management and quality assurance plans, the requirements, design and code standards, the requirements and design data, source and executable object code, verification results, the Software Configuration Index, and the Software Accomplishment Summary (SAS), which closes the compliance demonstration. The hardware equivalents are the PHAC and the Hardware Accomplishment Summary.

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

Hugues Orgitello updated 7 Oct 2026 13 min read

DO-178C has not changed since 2011 and DO-254 since 2000, but the rules around them have been rewritten in the last four years. The FAA replaced its 2005 hardware circular with AC 20-152A in October 2022, a complete rewrite that sets objectives for FPGAs, ASICs, commercial devices and circuit boards, and drops DAL D from its scope. Multicore processors left the CAST-32A position paper for AMC 20-193 (EASA, 2022) and AC 20-193 (FAA, 2024). And SAE replaced ARP4754A and ARP4761 with ARP4754B and ARP4761A in December 2023. This guide sets out what DO-178C and DO-254 actually require, with the objective counts, the coverage rules and the 2022 hardware objectives, and corrects some widely repeated readings, including the one that puts FPGAs in DO-254 Appendix B.

TL;DR: DO-178C (software) and DO-254 (hardware) are means of compliance recognised by AC/AMC 20-115D and AC/AMC 20-152A. Levels A to E come from the system safety assessment (ARP4754B, ARP4761A). DO-178C has 71 objectives at level A, 69 at B, 62 at C, 26 at D. MC/DC is level A only, decision coverage starts at B, statement coverage at C. For hardware, AC 20-152A covers DAL A to C, classifies custom devices as simple or complex, and accepts HDL code coverage as one way to do the elemental analysis of Appendix B, which is about level A and B, not about FPGAs as such.

The documents and when they changed

Document	Role	Current edition	Recognised by
DO-178C / ED-12C	Software development assurance	December 2011, with supplements DO-330 to DO-333	FAA AC 20-115D; EASA AMC 20-115D
DO-254 / ED-80	Airborne electronic hardware design assurance	April 2000	FAA AC 20-152A (7 October 2022, cancels AC 20-152 of 30 June 2005); EASA AMC 20-152A (ED Decision 2020/010/R)
AC 20-193 / AMC 20-193	Multicore processors	EASA January 2022; FAA 8 January 2024	Replace the CAST-32A position paper
ARP4754B / ED-79B	Aircraft and system development, level assignment	20 December 2023	Successor of ARP4754A
ARP4761A / ED-135	Safety assessment process (FHA, PSSA, SSA)	December 2023	Successor of ARP4761
DO-160	Environmental test conditions	Separate document	Environmental qualification, not design assurance

The family history explains some vocabulary still in use: DO-178 (1982), DO-178A (1985), DO-178B (1992), DO-178C (2011). Software levels and the Annex A objective tables come from DO-178B; DO-178C clarified them and moved tools, models, object orientation and formal methods into supplements.

None of these documents is a regulation. They are means of compliance: the regulations are the airworthiness codes (14 CFR Parts 23, 25, 27, 29 and 33, CS-23, CS-25 and so on) and the TSO or ETSO requirements, and a programme shows compliance through the plans it agrees with the authority.

Levels and failure conditions

Level	Failure condition	Typical quantitative objective for large aeroplanes (AMC 25.1309)
A	Catastrophic	Extremely improbable, 1E-9 per flight hour
B	Hazardous	Extremely remote, 1E-7 per flight hour
C	Major	Remote, 1E-5 per flight hour
D	Minor	No quantitative requirement (may be probable)
E	No safety effect	None

The probabilities apply to failure conditions at system level, not to a software item: software has no failure rate. The level of an item reflects the rigour of its development process, and it is assigned by the system process under ARP4754B with the safety assessment of ARP4761A, taking architecture (partitioning, independence, dissimilarity) into account. In ARP4754B the details of how the safety assessment feeds level assignment moved into ARP4761A; the general principles of function and item development assurance levels stayed.

For the system-level framing of hazard and risk methods, see risk management, ISO 14971 and IEC 31010.

DO-178C: objectives per level

Level	Objectives	With independence	Structural coverage	Other notable requirements
A	71	30	MC/DC, decision and statement	Verification of object code not directly traceable to source code
B	69	18	Decision and statement
C	62	5	Statement
D	26	2	None	Verification against high-level requirements only
E	0	0	None

The objectives sit in the ten tables of Annex A (A-1 planning to A-10 certification liaison). Data coupling and control coupling analysis is required at levels A, B and C. "Independence" means the person verifying an artefact is not the person who produced it, or a qualified tool does the verification.

MC/DC (modified condition/decision coverage) requires that every condition in a decision has been shown to independently affect the decision's outcome. Decision coverage at 100% does not imply MC/DC: a decision a && b can reach both outcomes with two tests, but MC/DC needs three.

Life cycle data

Data item	Role
PSAC, Plan for Software Aspects of Certification	Agreed with the authority: levels, life cycle, supplements, tools, alternative methods
SDP, SVP, SCMP, SQAP	Development, verification, configuration management and quality assurance plans
Requirements, design and code standards	Rules the development must follow, verified at reviews
High-level and low-level requirements, architecture	Development outputs, traced in both directions
Source code and executable object code	Built by a configuration-managed environment
Verification cases, procedures and results	Including coverage analysis
SCI and SECI	Software configuration index and life cycle environment configuration index
SAS, Software Accomplishment Summary	Closes the demonstration and lists any deviations and open problem reports

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 process AND its output is used to justify eliminating or reducing a verification process other than the one it automates, or a development process that could have an impact on the embedded software. The discriminator is not whether the tool picks the artefacts to verify, it is whether other work is dropped on the strength of what the tool produces	TQL-4
Criteria 3	The tool automates a verification process and could fail to detect an error, but nothing else is eliminated or reduced on the strength of its output (typically a coverage counter, a static analysis tool run as an additional check, a binary comparison tool)	TQL-5

A worked example makes the Criteria 2 / Criteria 3 line concrete. An abstract-interpretation analyser proving the absence of run-time errors is Criteria 2 when its proof is what lets the project drop the corresponding robustness test cases, and Criteria 3 when the full test campaign runs anyway and the analyser is only an additional check. Same tool, same configuration, two categories, decided by what the project stops doing because of it.

Two questions have to be kept apart. Whether a tool needs qualifying at all is settled by DO-178C section 12.2 against the three criteria above; at what level it is qualified is settled separately. Only Criteria 1 tracks the DAL across all four levels. Criteria 2 relaxes once the software drops below level B. Criteria 3 sits at the floor, TQL-5, at every level from A to D, so nothing drops for a coverage tool on a DAL D programme: it is TQL-5 there exactly as at DAL A. TQL-5 is a qualification level in its own right, carrying its own set of 14 objectives, not an exemption, and a project that budgets nothing for its coverage tools at DAL D still owes that qualification. Moving up to TQL-4 adds a further 24 objectives, which is where a tool procured from a supplier starts to constrain the schedule. The exact level for each combination must be read from Table 12-1 of DO-178C section 12.2, which is the authoritative source. 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, DO-332 and DO-333

Supplement	Use	What it adds
DO-331	Model-based development and verification	Objectives for specification and design models, model coverage, simulation as a verification method
DO-332	Object-oriented technology	Objectives for inheritance, polymorphism, dynamic memory, exceptions; local type consistency
DO-333	Formal methods	Conditions under which proof, model checking or abstract interpretation can replace or complement tests

Each supplement is invoked from the PSAC on top of DO-178C; a model-based project with a qualified code generator typically combines DO-178C, DO-331 and DO-330.

DO-254 and AC 20-152A

DO-254 defines a hardware life cycle (planning, requirements capture, conceptual design, detailed design, implementation, production transition) and supporting processes (validation, verification, configuration management, process assurance, certification liaison). Appendix A scales the life cycle data by level. Appendix B adds design assurance considerations for level A and B functions: architectural mitigation, product service experience, and advanced verification methods, of which elemental analysis is one.

AC 20-152A, issued on 7 October 2022 and mirrored by AMC 20-152A, rewrote how the FAA applies DO-254:

Scope: airborne electronic hardware contributing to DAL A, B or C functions; at DAL C only a limited set of objectives applies; for DAL D the AC is not required, and AC 00-72 gives best practices.
Four topics, four objective families: custom devices (CD), COTS IP inside custom devices (IP), COTS devices (COTS) and circuit board assemblies (CBA).
Custom devices are PLDs, FPGAs and ASICs, DO-254's "custom micro-coded components".
Simple or complex: a custom device is simple only if a technical assessment shows it can be comprehensively verified by deterministic tests and analyses under all foreseeable conditions. The criteria include the number and simplicity of functions and interfaces, synchronous or asynchronous design, number of clocks, and number of state machines and states. Anything not shown to be simple is complex.
Robustness: for DAL A and B, abnormal and boundary conditions and the expected behaviour must be written as requirements (objective CD-8).
HDL code coverage: recognised as a method to perform the elemental analysis of Appendix B section 3.3.1 for digital devices, when run during requirements-based verification. The applicant defines the coverage criteria (branches, conditions and so on) in its plans, and any uncovered case must be analysed and justified (objective CD-9).

There is no fixed table of RTL coverage metrics per level in DO-254 or AC 20-152A: the criteria are set by the applicant in the PHAC and agreed with the authority.

Multicore processors

AMC 20-193 (EASA, January 2022) and AC 20-193 (FAA, 8 January 2024) replaced the CAST-32A position paper for multicore processors. They cover interference between cores through shared resources, worst-case execution time and resource usage, and the planning and verification evidence expected. They apply to software running on the multicore platform and are typically referenced from the PSAC.

Certification liaison

The authority reviews the work at stages of involvement (SOI): planning (SOI 1), development (SOI 2), verification (SOI 3) and final (SOI 4). The PSAC and PHAC are the agreements that frame those reviews; changes to them are, in effect, renegotiations. On the FAA side, designated engineering representatives often perform the reviews; on the EASA side, EASA or a national authority reviews the work, and the applicant normally holds a design organisation approval (Part 21 Subpart J).

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 maths libraries, RTOS products 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 levels 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.

Readings the texts do not support

Common reading	What the text says
"DO-254 Appendix B is the FPGA and ASIC appendix"	Appendix B is additional assurance for level A and B functions; FPGAs and ASICs are custom micro-coded components (section 1.2), detailed in AC/AMC 20-152A
"DO-254 requires MC/DC-equivalent coverage on RTL at DAL A"	No fixed RTL metric: HDL code coverage is one recognised way to do elemental analysis, with criteria defined by the applicant
"DO-254 applies down to DAL D"	AC 20-152A covers DAL A to C and says it is not required for DAL D
"Minor failure conditions carry a 1E-3 per hour limit"	AMC 25.1309 sets no quantitative requirement for minor conditions
"Data and control coupling only at module level for level C"	Coupling analysis is a level A, B and C objective without that qualifier
"ARP4754A and ARP4761 are current"	Superseded by ARP4754B and ARP4761A in December 2023
"CAST-32A governs multicore"	AMC 20-193 (2022) and AC 20-193 (2024)

DO-160: the companion that is often confused

DO-160 (Environmental Conditions and Test Procedures for Airborne Equipment) specifies environmental tests: temperature, altitude, vibration, humidity, power input, EMC, lightning and electrostatic discharge. It produces test reports for the equipment, not design assurance. A DO-254 programme still needs DO-160 qualification of the hardware, and a DO-160 report says nothing about DO-254.

FAA and EASA side by side

Aspect	FAA	EASA
Airworthiness codes	14 CFR Parts 23, 25, 27, 29, 33	CS-23, CS-25, CS-27, CS-29, CS-E
Software	AC 20-115D	AMC 20-115D
Hardware	AC 20-152A (2022)	AMC 20-152A (2020)
Multicore	AC 20-193 (2024)	AMC 20-193 (2022)
Documents referenced	RTCA DO-178C, DO-254	EUROCAE ED-12C, ED-80
Review	Aircraft certification office, often with designated engineering representatives	EASA or national authority

The US-EU civil aviation safety agreement and its technical implementation procedures let a programme submit one set of plans to both authorities; differences are mostly in review scheduling and paperwork.

Common pitfalls

Starting late. Plans, standards and traceability cannot be reconstructed convincingly after the fact, and independence of past reviews cannot be created retroactively.
Choosing a level without a safety assessment. The level must come from the ARP4754B and ARP4761A process; one chosen by customer request alone fails at SOI 1.
Unqualified tools. A code generator, coverage tool or static analyser whose output removes verification work needs DO-330 qualification at the right TQL.
Treating decision coverage as MC/DC.
Classifying an FPGA as simple without the technical assessment that AC 20-152A asks for.
Ignoring COTS devices and circuit boards. AC 20-152A has its own COTS and CBA objectives; a board is not exempt because its parts are commercial.
Multicore without AMC/AC 20-193 planning. Interference analysis and worst-case timing need to be in the plans from the start.

Automotive uses ISO 26262 (ASIL A to D), general industry and rail use IEC 61508 and its sector standards, and medical software uses IEC 62304. They share planning, traceability, verification and tool qualification, but no authority recognises a mapping between DAL, ASIL and SIL. For avionics cybersecurity, see DO-326A and ED-202A.

Frequently asked questions

What is the regulatory status of DO-178C and DO-254?: DO-178C (Software Considerations in Airborne Systems and Equipment Certification) and DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) are RTCA documents, published in Europe by EUROCAE as ED-12C and ED-80. They are not regulations. The FAA recognises DO-178C as an acceptable means of compliance in AC 20-115D and DO-254 in AC 20-152A (7 October 2022); EASA does the same in AMC 20-115D and AMC 20-152A. They become binding for a programme through its certification basis and the plans the authority accepts.
What are the levels A to E?: Each software or hardware item gets a level from the failure condition it can contribute to: A catastrophic, B hazardous, C major, D minor, E no safety effect. The level is assigned by the system development and safety assessment processes (ARP4754B and ARP4761A since December 2023), not chosen by the software or hardware team.
How many DO-178C objectives apply at each level?: The Annex A tables of DO-178C list 71 objectives at level A (30 with independence), 69 at level B (18 with independence), 62 at level C (5 with independence) and 26 at level D (2 with independence). Level E has none. The difference between A and B is small in count but large in effort, because level A adds MC/DC structural coverage and verification of object code that is not directly traceable to source.
Is DO-254 Appendix B the FPGA appendix?: No. Appendix B of DO-254 gives additional design assurance considerations for level A and B functions: architectural mitigation, product service experience and advanced verification methods such as elemental analysis, safety-specific analysis and formal methods. FPGA, ASIC and PLD devices are "custom micro-coded components" in DO-254 section 1.2, and since 2022 AC 20-152A (and AMC 20-152A in Europe) gives the detailed objectives for them, including criteria for classifying a device as simple or complex.
Is DO-254 required for DAL D hardware?: Not under AC 20-152A. The AC applies to airborne electronic hardware contributing to DAL A, B or C functions and says its use is not required for DAL D, pointing to AC 00-72 for best practices. At DAL C only a limited set of its objectives applies.
What replaced CAST-32A for multicore processors?: AMC 20-193, adopted by EASA in January 2022, and AC 20-193, issued by the FAA on 8 January 2024. Both are based on the CAST-32A position paper and are technically aligned, so a multicore programme can use one set of objectives for both authorities.
What are the main DO-178C deliverables?: The Plan for Software Aspects of Certification (PSAC), the development, verification, configuration management and quality assurance plans, the requirements, design and code standards, the requirements and design data, source and executable object code, verification results, the Software Configuration Index, and the Software Accomplishment Summary (SAS), which closes the compliance demonstration. The hardware equivalents are the PHAC and the Hardware Accomplishment Summary.