TEA-304STANDARDS & GUIDANCEAIRBORNE SYSTEMS

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

01 / INTENT

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.

SYSTEM SAFETYAllocate assuranceFailure conditions and development assurance levels

LIFECYCLE DATAMeet objectivesPlans, requirements, design, verification and configuration

COMPLIANCEShow controlIndependence, quality assurance and authority liaison

Certification credit follows controlled evidence.A capable process or tool does not earn credit by reputation; its intended use, outputs, verification and configuration must support the applicable objectives.

02 / FRAMEWORK

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.

03 / APPLICATION

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.

04 / EVIDENCE

Build evidence that explains the reasoning.

Approved plans

Lifecycle, standards, objectives, tools and independence.

Development data

Requirements, design, source or hardware implementation records.

Traceability

Forward and reverse links across requirements, implementation and tests.

Verification results

Reviews, analyses, tests and coverage closure.

Configuration index

Identified baselines, environments and lifecycle data.

Accomplishment summary

Compliance position, evidence and unresolved items.

Common failure patterns

Testing equals compliance

Lifecycle, independence and configuration objectives are ignored.

Level chosen locally

Assurance is assigned without the system safety assessment.

Tool trust

Automation output is accepted without qualification or independent checks.

Late authority contact

Plans and interpretations are presented after evidence is fixed.

05 / REFERENCES

Further learning

RTCA DO-178COfficial publication information for airborne software assurance.
RTCA DO-254Official publication information for airborne electronic hardware assurance.

KEY TAKEAWAY

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.