Airborne software
DO-178C software data evidence review for software assurance teams
This review checks that a DO-178C software lifecycle data package holds together at the assigned software level before it goes to the authority or answers a finding. A certification engineer reads your plans, standards, verification results, and Software Accomplishment Summary as one body of evidence, then confirms every claim in the summary points back to a record that supports it. Software assurance teams use it ahead of a submittal, a finding response, or a change that reopens verification. You get a gap list keyed to objectives, an evidence map, and a closure sequence that says what to fix first.
When this review is needed
- A software data package is nearly ready for submittal and you want an outside read before the authority sees it.
- The authority raised a finding against your lifecycle data and the response has to be evidence-backed, not assertion.
- A design change touched verified code and you need to know which objectives reopened.
- The software level moved up during development and the earlier evidence has to be re-checked against the higher level.
The problem
A DO-178C package accumulates over years, across tool changes and staff turnover, and the Software Accomplishment Summary ends up describing evidence that the record set no longer fully backs. The team that wrote the plans is rarely the team closing them, so a claim of structural coverage or a resolved problem report can read as complete while the underlying artifact is stale, superseded, or missing. Nobody wants to be the one who finds that during a stage-of-involvement audit.
What gets reviewed
- Plans (PSAC, SDP, SVP, SCMP, SQAP) read against each other for consistency and against the assigned software level
- Software standards for requirements, design, and code, and evidence they were actually applied
- Verification results, including review, analysis, and test records tied to the objectives they satisfy
- Structural coverage evidence appropriate to the level, with dead and deactivated code addressed
- Problem reports and their disposition, traced to the change that closed each one
- The Software Accomplishment Summary checked claim by claim against the record behind it
What gets validated
- Every objective claimed satisfied in the summary maps to a specific verification record, not a plan promise
- Structural coverage matches the software level, and gaps carry a documented analysis rather than a silent pass
- Requirements-based test cases trace up to requirements and down to the code they exercise
- Open problem reports are either closed with evidence or carried with a stated rationale
- The plans describe the process the records actually show, with no divergence introduced by later tool or method changes
Evidence normally required
- The full plan set: PSAC, SDP, SVP, SCMP, SQAP at the revision proposed for submittal
- Software requirements, design description, and source with the applicable standards
- Verification results and structural coverage reports for the current build
- The problem report log with dispositions
- The Software Accomplishment Summary and configuration index
Common discrepancies
- A structural coverage claim that rests on an older build than the one described in the configuration index
- Requirements-based tests that pass but do not trace to a low-level requirement
- A problem report marked resolved with no verification record showing the fix was re-tested
- Plan language written for a lower software level than the one finally assigned
What is at stake
A summary that overstates the evidence invites findings that stall the submittal and force rework under a deadline that was already tight. If the gap surfaces after the authority has started its review, the team loses control of sequencing and closes objectives in the order the finding letter dictates rather than the order that would have been efficient.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Read the plans as a set
Check the PSAC and its companions against each other and against the assigned level before touching the evidence.
Trace the summary claims
Take each claim in the accomplishment summary and follow it to the verification record that backs it.
Test the coverage and problem reports
Confirm structural coverage fits the level and that resolved problem reports carry re-test evidence.
Sequence the closure
Rank the gaps by exposure and effort so the remaining work runs in a defensible order.
What the buyer receives
- An objective-level gap list ranking each shortfall by effort and by exposure at review
- An evidence map linking each summary claim to the record that supports it
- A closure sequence that orders the remaining work for the fastest defensible submittal
Who uses the output
- Software assurance leads deciding whether the package is ready to submit or needs another pass
- Certification leadership setting the response to an authority finding on lifecycle data
- Engineering leads scoping the verification rework a change reopened
How the work fits into the transaction or program
The review sits between the last verification activity and the moment the data package leaves your hands. It takes the artifacts your process produced and reads them the way an authority reviewer will, so gaps surface while you still control the schedule rather than after a finding fixes it for you.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C as an acceptable means of compliance, but they diverge on how transition and additional considerations are handled and on the certification liaison expected at each stage. The review notes where a claim that satisfies one authority's expectation would draw a question from the other, so a package aimed at both does not carry an assumption that only holds for one.
Regulatory limits
This is an evidence read, not an approval. It does not make a compliance finding, sign off any objective on the authority's behalf, or determine that the software is airworthy. Those decisions rest with the authority and its designees.
What this review does not cover
- Writing or re-running the verification tests behind an objective
- Developing plans, standards, or requirements the package is missing
- Any compliance finding or authority acceptance of the data
Specific to this review
- The Software Accomplishment Summary is where overstatement hides, because it is written to persuade and is often finalized before the last build settles.
- Structural coverage evidence detaches from the build faster than any other artifact, so its provenance is checked before its numbers.
- Raising the software level mid-program rarely triggers a full re-read of the earlier plans, which is where level-mismatch findings originate.
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
Do you re-run our verification, or only review the records?
We review the records. The point is to read the evidence the way the authority will and to find where a claim outruns the artifact behind it. Re-running tests is your team's work, and our gap list tells you exactly which ones warrant it.
Can this be scoped to a single finding response instead of a full package?
Yes. When the authority has raised a specific finding, the review narrows to the objectives and records that finding touches, plus anything upstream that the response depends on, so you answer once rather than reopening the letter.
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.