Airborne software lifecycle data
DO-178C software lifecycle data evidence review for avionics suppliers
This review reads an avionics supplier's DO-178C lifecycle data as a set and asks whether it holds together at the software level actually assigned. A certification specialist checks that the plans commit to the right objectives, the standards were followed, the verification records show those objectives satisfied with the required independence, and the accomplishment summary tells a story the underlying data supports. It runs before submittal, during a finding response, or when a change reopens objectives that were closed. You receive a gap list, an evidence map from objective to record, and a closure sequence.
When this review is needed
- A software data package is nearly ready and the objectives-versus-evidence picture needs an outside read before it goes out.
- The software level was raised after the plans were written and the evidence has to catch up to the new objectives.
- A finding challenges whether structural coverage or independence was actually achieved at the assigned level.
- A change reopens verification for objectives the accomplishment summary already reported as complete.
The problem
DO-178C produces a large body of data across plans, standards, requirements, code, and verification, and the objectives that tie it together are easy to satisfy on paper. A plan commits to an objective, the verification runs, and the accomplishment summary reports it done, but the independence, the coverage, or the review record behind that objective may not survive an actual read. The assigned level sets what is required, and level creep during development quietly leaves earlier data short.
What gets reviewed
- Plans checked so the objectives they commit to match the software level actually assigned
- Software standards confirmed defined, with evidence that they were applied rather than only published
- Verification records checked against the objectives, including the independence the level requires
- Structural coverage analysis reviewed for completeness and for justified handling of any shortfall
- Accomplishment summary reconciled against the underlying data it claims to summarize
- Problem reports and open items assessed for their effect on the objectives reported closed
What gets validated
- Objectives listed in the plans are the objectives the assigned software level requires
- Verification records show the independence the level demands, evidencing who reviewed rather than that review merely happened
- Structural coverage is complete or every gap has an analyzed and justified disposition
- The accomplishment summary's claims resolve to actual verification and review records
- Open problem reports do not undercut an objective the summary reports satisfied
Evidence normally required
- The plans for software aspects of certification and the supporting development, verification, and configuration plans
- The software requirements, design, and code standards with evidence of application
- Verification cases, procedures, results, and review records at the current baseline
- Structural coverage analysis and any dead or deactivated code justification
- The accomplishment summary, configuration index, and the open problem report list
Common discrepancies
- Verification performed without the independence the assigned level requires for that objective
- Structural coverage gaps left without an analyzed rationale for why they are acceptable
- An accomplishment summary that reports objectives closed against a superseded verification run
- Plans still written to a lower level than the one the project later assigned to the software
What is at stake
Software data that does not match its level is the kind of gap an authority finds late, when the airplane program is counting on the box. Missing independence or short structural coverage cannot be closed by editing the summary; it takes real verification work, and running that work under a delivery deadline is where schedules break and where a Stage of Involvement review turns adversarial.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the assigned level
Confirm the software level the project committed to and align the plans' objective set to that level before reading evidence.
Read objective to record
Follow each objective to its verification and review evidence, checking independence and revision rather than accepting the summary.
Test coverage and problem reports
Examine structural coverage dispositions and open problem reports for any that undercut an objective reported closed.
Sequence real work first
Order closures so verification and coverage tasks lead and documentation reconciliation follows, since only the former moves the schedule.
What the buyer receives
- A gap list naming each objective whose evidence is missing, short on independence, or misreported
- An evidence map from every claimed objective to the record that satisfies it
- A closure sequence that puts real verification work ahead of documentation cleanup
Who uses the output
- Certification leadership judging whether the software data is ready for a Stage of Involvement review or submittal
- Software verification leads who need a precise list of objectives to rework
- The team preparing responses to a software finding an authority or delegate has raised
How the work fits into the transaction or program
DO-178C data does not stand alone; it feeds the system-level safety and verification story the whole certification rests on. This review checks the software layer against its assigned level so the item integrates cleanly, catching level and independence gaps while they are still a software problem rather than a program one.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C, but the review depth an authority or delegate applies varies with the software level and the Stage of Involvement schedule. The review reads the data against the level the program committed to and the involvement points that authority will actually exercise, since the same package draws lighter or heavier scrutiny depending on both.
Regulatory limits
This review assesses the supplier's DO-178C data against its assigned level and reports where it holds or falls short. It does not accept the software, does not issue a compliance finding, and does not make an airworthiness determination. Acceptance stays with the authority or the delegate exercising the Stage of Involvement.
What this review does not cover
- Performing the verification, coverage analysis, or reviews the gaps require
- Rewriting the plans or standards to close a documentation shortfall
- Granting or accepting a software compliance finding
Specific to this review
- Level creep is the recurring trap: software raised from a lower design assurance level mid-program leaves plans and early evidence written to objectives that no longer apply.
- Independence is the objective most often claimed and least often evidenced, because it is a property of who performed the review rather than of any artifact.
- Structural coverage shortfalls cannot be closed by argument alone; each uncovered branch needs an analyzed disposition, and a blanket justification rarely survives review.
- The accomplishment summary is a narrative, and its worst failure is quiet: it can read complete while pointing at verification runs the configuration index shows were superseded.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
What if the software level was raised partway through development?
That is one of the most common reasons this review is worth running. Raising the level adds objectives and often tightens independence, and the plans and early evidence usually still reflect the old level. The review isolates exactly which objectives the new level introduced and which existing evidence no longer suffices.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.