Upskill / Regulation & business / Software and hardware assurance: DO-178C, DO-254 and design assurance levels

Software and hardware assurance: DO-178C, DO-254 and design assurance levels

How airborne software and complex electronic hardware are assured: from failure conditions to assurance levels, the DO-178C plans, objectives and structural coverage including MC/DC, DO-254 for FPGAs and ASICs, and the evidence authorities review, following one brake-by-wire system. Part 3 of the Systems engineering and safety series.

By Aerospace Garage Desk · Managing it · 45 minutes · 24 narrated pages

What you will be able to do

✓ Explain how failure condition classifications set function and item development assurance levels, and how FAA and EASA documents recognise DO-178C and DO-254.
✓ Describe the DO-178C planning, development and integral processes, the five plans and how objectives and independence vary by software level.
✓ Apply requirements-based testing and structural coverage, including building an MC/DC test set, and determine when a tool needs qualification and at what level.
✓ Classify custom electronic devices as simple or complex under AC 20-152A and interpret elemental analysis results for DAL A and B hardware.
✓ Prepare for authority reviews: life cycle data, stages of involvement and the classification of open problem reports.
✓ Draw software assurance lessons from the official findings on the Ariane 501 failure.

Course content

Session 1 · From safety assessment to assurance levels

1.1

Errors, not failures: where Part two left off · free preview
From function levels to item levels
The recognition documents: how the standards become acceptable means
Worked example: assigning levels to Halny's items

Session 2 · DO-178C structure: planning, development and objectives

1.2

How DO-178C is organised: processes, objectives and data
Planning: the PSAC and the four supporting plans
Development: from system requirements to executable code
Worked example: Halny's planning review

Session 3 · Verification: testing, structural coverage and tools

1.3

Requirements-based testing, reviews and analyses
Structural coverage: statement, decision and MC/DC
Tools and supplements: DO-330, model-based, object-oriented and formal methods
Worked example: MC/DC on an anti-skid release decision

Session 4 · DO-254 and complex electronic hardware

1.4

Why complex hardware needs design assurance
Simple or complex: the first hardware decision
Levels A and B: Appendix B and elemental analysis
Worked example: reading the wheel controller coverage report

Session 5 · What certification evidence looks like

1.5

Life-cycle data: what the authority actually sees
Stages of involvement: when the authority looks
Problem reports and open problem reports
Worked example: getting ready for the verification review

Session 6 · Reuse, independence and the lessons of Ariane 501

1.6

Reused and legacy software
Independence and dissimilarity: what assurance cannot buy
Towards Part four: models as engineering data
From the investigation file: Ariane 501, 1996

MRO deals and approvals, 5-11 Nov 2026
3 · World n/a
Aviation Week and AviTrader, 9-11 Nov 2026

Market Pulse →

Who this course is for

Software, FPGA and avionics engineers at airframers and suppliers who plan, develop and verify airborne software and complex electronic hardware
Certification, verification and quality assurance engineers who prepare PSACs, PHACs, coverage evidence and accomplishment summaries for FAA or EASA review
Engineering and programme managers who must budget assurance levels, tool qualification, stages of involvement and open problem reports

You need: Parts 1 and 2 of this series (requirements, the V-model and safety assessment) or equivalent experience; basic logic (true/false conditions) helps for the MC/DC example.

Upskill courses are for professional development and are not approved by any aviation authority. Learner Terms