DO-178C and DO-254 — Airborne systems
See how airborne assurance links system safety assessment to rigorous software and electronic-hardware lifecycle objectives, evidence and certification liaison.
After this module, you should be able to:
- Distinguish DO-178C software and DO-254 hardware scope
- Explain assurance levels and objective-based compliance
- Recognise planning, traceability and independence expectations
- Understand configuration, tool and certification evidence
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-109 and TEA-201. This is an orientation to airborne development assurance, not a certification plan.
Airborne assurance is objective-based and evidence-intensive.
DO-178C addresses software considerations in airborne systems and equipment certification; DO-254 addresses design assurance for airborne electronic hardware. System safety processes allocate functions and assurance levels before these lifecycle frameworks are applied.
The standards define objectives and expected lifecycle data rather than prescribing a single development method. Higher assurance levels introduce more objectives and greater independence. Compliance depends on the actual planning, transition criteria and evidence accepted for the certification context.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Planning | Which objectives, lifecycle, standards, tools and evidence apply? | Plans for software or hardware aspects of certification |
| Development | How are requirements, design and implementation controlled? | Requirements, design data, source or hardware artefacts |
| Verification | How are reviews, analyses, tests and coverage completed? | Verification cases, results and coverage analysis |
| Configuration and quality | Can every baseline and change be reproduced and audited? | Configuration index, records and QA evidence |
| Certification liaison | How will plans, reviews, issues and compliance be presented? | Authority submissions and accomplishment summary |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Obtain the allocated function, failure classification and assurance level from system processes
- 2. Define the lifecycle, standards, transition criteria, independence and evidence in plans
- 3. Develop high-level and low-level requirements with bidirectional traceability
- 4. Implement software or hardware design under configuration control
- 5. Verify requirements, design and implementation; resolve structural or elemental coverage gaps
- 6. Assemble reproducible baselines and compliance summaries for authority review
Worked application: flight-control monitor
System safety allocates a monitoring function and assurance level. Software requirements define detection and annunciation; hardware requirements define independent input and output paths. Verification must show requirements coverage, implementation coverage where applicable, independence and the exact airborne configuration.
Build evidence that explains the reasoning.
Lifecycle, standards, objectives, tools and independence.
Requirements, design, source or hardware implementation records.
Forward and reverse links across requirements, implementation and tests.
Reviews, analyses, tests and coverage closure.
Identified baselines, environments and lifecycle data.
Compliance position, evidence and unresolved items.
Common failure patterns
Lifecycle, independence and configuration objectives are ignored.
Assurance is assigned without the system safety assessment.
Automation output is accepted without qualification or independent checks.
Plans and interpretations are presented after evidence is fixed.
Keep software and electronic hardware assurance connected
DO-178C addresses airborne software development assurance, while DO-254 addresses airborne electronic hardware assurance. The aircraft or system safety work drives the relevant assurance level and allocation. It is not chosen from the programming language, team size or the desire for a convenient test scope.
FAA AC 20-115D recognises DO-178C and related documents within its described means of compliance. AC 20-152A addresses airborne electronic hardware, including distinctions and considerations for custom devices, commercial components and circuit-board assemblies. Use the actual certification basis and accepted plans to determine obligations.
For a controller containing an FPGA and processor, map requirements across the hardware logic, software and interfaces. A timing or reset assumption at that boundary needs evidence from both disciplines. Separate assurance records should still explain one coherent system behaviour.
Plan objectives, independence and tool use early
An assurance plan connects applicable objectives to activities, records, responsibilities and review. Keep requirements, design, implementation and verification traceability coherent, including derived behaviour that needs system-level consideration. Avoid constructing trace links after testing solely to fill a matrix.
Verification includes requirements-based evidence and the applicable structural analysis; coverage does not replace requirements completeness or correctness. The required independence depends on the applicable objectives and assurance level. Define it in the plan rather than assuming any peer review is sufficient.
Tool qualification depends on the tool’s use and the credit taken for its output. A tool that eliminates or automates a required activity can need a different justification from one whose output is independently checked. A vendor qualification kit supports a specific argument; it does not automatically qualify every version, configuration and use.
| Interface or decision | Illustrative assurance concern |
|---|---|
| FPGA → processor | Data validity, reset sequencing, latency and error signalling. |
| Generated code | Requirements, generator use, output verification and tool credit. |
| Commercial device | Used functions, configuration, errata and integration assumptions. |
| Change | Affected objectives, evidence and exact configuration baseline. |
Use reuse evidence within its real limits
A previously used component or software element may have valuable history, but a new environment, function or interface can invalidate earlier assumptions. Review differences explicitly. Confirm that configuration and lifecycle records remain available and that the required assurance claims are still supportable.
When a late change affects a low-level interface, assess both sides and the system consequence. Updating only the software test record can leave the hardware assumption unresolved. Maintain a clear problem-report and change record that a reviewer can follow from discovery to verified closure.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Review an FPGA data-ready interface change
An FPGA update changes data-ready from a level signal to a short pulse. Processor software still polls the input periodically, and nominal bench tests happen to pass.
- Identify the cross-boundary requirement and failure mechanism.
- Specify the design and verification evidence needed on both sides.
- Explain how the change should enter the assurance baseline.
Show the worked answer
Polling can miss a pulse that occurs between observations, so nominal success does not establish reliable transfer. Agree pulse width, capture or interrupt behaviour, acknowledgement, buffering and overrun handling. If the processor cannot capture every required event, revise the interface rather than relying on favourable phase.
Verify the timing relationship over relevant clocks, load and reset sequences, and test event loss or overflow. Update requirements, hardware and software design records, interface evidence and affected verification. Record the exact FPGA image and software combination with change and problem disposition. The assurance level and certification plan determine the formal objectives; the engineering defect exists regardless of that level.
Review criteria
- The missed-event mechanism is understood.
- Both hardware and software evidence are updated.
- The accepted configuration is unambiguous.
Check your understanding
Can structural coverage prove that all required functions exist?
No. It describes exercised structure; requirements-based verification and completeness analysis address what the product must do.
Is a tool qualification kit sufficient by itself?
No. The actual tool version, configuration, intended use and claimed credit must fit the qualification argument.
Further learning
- FAA AC 20-152A — Development Assurance for Airborne Electronic HardwarePublisher source supporting this module’s framework discussion.
- FAA AC 20-115D — Airborne Software Development AssurancePublisher source supporting this module’s framework discussion.
- RTCA DO-178COfficial publication information for airborne software assurance.
- RTCA DO-254Official publication information for airborne electronic hardware assurance.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.