Airborne software lifecycle data
DO-178C software lifecycle data evidence review for modifiers
A DO-178C software lifecycle data evidence review checks that the plans, standards, verification records, and accomplishment summary in the software package match the software level assigned to the function. It is run for aircraft modifiers before a submittal, in a finding response on software assurance, or when a change alters the software or its level. The review targets the objectives the assigned level demands that the data does not satisfy, and lifecycle data that reads to a lower level than the function requires. You get a gap list keyed to the objectives, an evidence map across the lifecycle data, and a closure order.
When this review is needed
- A submittal includes airborne software and the lifecycle data must satisfy its assigned level.
- A finding questioned whether the software assurance evidence meets the level the function needs.
- A change modified the software or reassigned its level and the data was not re-checked against it.
- Software was developed by a supplier and the lifecycle data must be checked before the modifier stands behind it.
The problem
DO-178C ties a defined set of objectives to each software level, and the data package is supposed to satisfy every objective at the level assigned. In practice the level is set early and the data is produced over months by people who may not track which objectives their level actually requires. The plans, the coding standards, the verification records, and the accomplishment summary can each read as complete while collectively falling short of the objectives the assigned level demands.
What gets reviewed
- The assigned software level checked against the function's failure-condition classification
- Plans and standards checked to call out the objectives the assigned level requires
- Verification records checked to satisfy the required objectives at the assigned level
- Structural coverage analysis checked against the level's coverage expectation
- The accomplishment summary checked to reflect the actual state of the lifecycle data
- Any dead or deactivated code and tool qualification claims checked for supporting rationale
What gets validated
- The assigned software level matches the failure condition the function contributes to
- The plans and standards address every objective the assigned level requires
- Verification records exist for each required objective at the assigned level
- Structural coverage meets the criterion the level demands and gaps are analyzed
- The accomplishment summary describes the data package that actually exists
Evidence normally required
- The software lifecycle data: plans, standards, verification records, and accomplishment summary
- The assigned software level and the safety rationale behind it
- The requirements and design the software implements
- Structural coverage results and any coverage gap analyses
- Tool qualification data for any tool credited in the lifecycle
Common discrepancies
- Verification records that satisfy a lower level than the function's assigned level requires
- Structural coverage short of the criterion the level demands, with gaps unanalyzed
- An accomplishment summary describing a data state the package does not match
- Deactivated code present without the rationale the level requires for it
What is at stake
A software package that satisfies a lower level than its function requires is a finding an authority takes seriously, because the shortfall bears directly on safety assurance. Discovering it late is costly, since satisfying a missing objective can require re-running structural coverage or regenerating verification records, work that does not compress well against a submittal date.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the level
Check the assigned software level against the failure condition the function contributes to in the safety assessment.
Map objectives to data
Set the objectives the assigned level requires against the plans, standards, and verification records that must satisfy them.
Check coverage and summary
Confirm structural coverage meets the level's criterion and the accomplishment summary matches the real data state.
Deliver objective gaps
Return the unmet objectives with an evidence map and a closure order that clears summary-blocking gaps first.
What the buyer receives
- A gap list keyed to the DO-178C objectives the data does not satisfy at the assigned level
- An evidence map across plans, standards, verification, and summary for the software level
- A closure order that clears the objective gaps that block the accomplishment summary first
Who uses the output
- STC program managers judging whether the software data will meet its level
- Certification engineers answering a finding on software assurance objectives
- Engineering leads scheduling the verification or coverage work the gaps expose
How the work fits into the transaction or program
Software lifecycle data feeds the compliance claim for any function the software implements, and the accomplishment summary is the document an authority reads first. Checking the data against the assigned level before submittal keeps the summary from claiming an assurance level the underlying records do not reach.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C as the software assurance means, and both weigh the level assignment against the system safety assessment. The review checks the level against the failure classification the governing basis recognizes rather than accepting the assigned level as given.
Regulatory limits
This review checks the modifier's software lifecycle data. It does not perform software verification, does not qualify tools, does not make a compliance finding, and does not determine airworthiness. Software assurance acceptance remains with the authority.
What this review does not cover
- Running software verification or generating coverage results
- Qualifying development or verification tools
- Re-authoring the software plans or accomplishment summary
Specific to this review
- The software level is set from the safety assessment, so a wrong level assignment can make an otherwise complete data package satisfy the wrong set of objectives.
- Structural coverage is where levels most often fall short, because reaching the criterion the level demands is where the last and hardest verification effort sits.
- The accomplishment summary is frequently written to the intended data state rather than the actual one, so it can claim objectives the records do not yet meet.
- Deactivated and dead code carry level-specific rationale requirements that are easy to omit when the code was never expected to run.
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
The supplier delivered the software data. Do we still need it checked?
Yes. The modifier stands behind the software data at submittal, so it is the modifier's exposure if the package satisfies a lower level than the function requires. The review checks the supplier's data against the assigned level before you carry it forward.
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.