Software lifecycle data
Closing STC software data inconsistent with its assigned DO-178C level
This closure work checks that an STC's software lifecycle data actually meets the DO-178C objectives for the level assigned to it. It is run for the modifier when software is claimed at a given design assurance level but the lifecycle evidence does not carry all the objectives that level demands, or when the assigned level and the evidence on file disagree. The work maps the delivered lifecycle data to the objective set for the level, marks each objective with no satisfying evidence, and identifies whether the fix is missing data or a level that was set wrong. You receive an objective-by-objective map, an evidence request list for the unmet objectives, and a disposition package aligning the software level with its evidence.
When this review is needed
- Software is claimed at a level but the lifecycle data does not carry all its objectives.
- A supplier delivered software qualified to a lower level than the installation needs.
- The safety assessment raised the required level after the software data was produced.
- A reviewer asked which DO-178C objectives the evidence satisfies and the map is missing.
The problem
DO-178C assigns each software item a level, and each level carries a specific set of objectives with defined independence and data expectations. Trouble appears when the level on the plan and the evidence in the data set do not line up. Software may have been developed to a lower level and then installed where the safety assessment demands a higher one, or the objectives for the assigned level were partly met and partly assumed. Because the objective set grows sharply between levels, a mismatch is not a single missing document but a pattern of gaps across the lifecycle data that only a structured objective map exposes.
What gets reviewed
- The design assurance level assigned to each software item
- The DO-178C objective set for that level, including independence expectations
- The delivered lifecycle data mapped against each objective
- Objectives with no satisfying evidence marked as gaps
- A determination of whether the fix is missing data or a mis-set level
What gets validated
- Every objective for the assigned level maps to a specific lifecycle data item
- Objectives requiring independence show it in the evidence, not just in the plan
- The assigned level agrees with the level the safety assessment requires
- Lifecycle data covers the current software configuration, not an earlier build
- No objective is treated as satisfied on the strength of the plan alone
Evidence normally required
- The software level assigned in the plan and the safety assessment
- The DO-178C lifecycle data delivered for the software item
- The plan for software aspects of certification and the accomplishment summary
- Verification results and the traceability behind them
- Supplier data agreements where the software was developed elsewhere
Common discrepancies
- Software developed to a lower level than the installation's safety assessment requires
- Objectives requiring independence met without the independence recorded
- Lifecycle data that covers a build superseded by the delivered software
- An objective assumed satisfied by the plan with no lifecycle artifact behind it
What is at stake
Software evidence short of its assigned level is a gap that can require reworking lifecycle data, adding independence, or re-running verification, none of which is quick. If the level itself was set too low, the mismatch reaches back into the safety assessment. A reviewer who finds the objective set incomplete will not accept the level on assertion, so the finding blocks the software compliance and, through it, the function the software supports.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Confirm the assigned level
Establish the level each software item holds and the level the safety assessment requires.
Lay out the objective set
List the DO-178C objectives for that level, including where independence applies.
Map data to objectives
Match each objective to lifecycle evidence and mark the ones with nothing behind them.
Diagnose and package
Decide whether each gap is missing data or a mis-set level and assemble the disposition.
What the buyer receives
- An objective-by-objective map of the assigned level against the delivered data
- An evidence request list for the objectives with no satisfying artifact
- A disposition package aligning the software level with its lifecycle evidence
Who uses the output
- Certification leads confirming the software meets its assigned level before submittal
- Software engineering owners producing the missing objective evidence
- Program managers scoping rework when the level was set below what is needed
How the work fits into the transaction or program
Software level compliance connects the safety assessment, which sets the level, to the lifecycle data that has to meet it. This work runs during finding closure, alongside the hardware and requirements checks, so a level mismatch that reaches into the safety assessment surfaces before a reviewer relies on the software compliance claim.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
Both authorities recognize DO-178C as the software assurance framework, but the acceptance of supplier data and the handling of previously developed software can differ between them. The closure work notes where software accepted at a level for one authority needs additional lifecycle data or independence evidence to satisfy the other on a validating submission.
Regulatory limits
This work maps lifecycle data to DO-178C objectives and identifies gaps against the assigned level. It does not develop software, run verification, set the required level, approve the modification, or grant the STC. Whether the objective evidence is sufficient remains the authority's finding.
What this review does not cover
- Producing or re-running software verification or lifecycle activities
- Assigning or changing the software design assurance level
- Any determination that the software satisfies its level
Specific to this review
- The objective count rises steeply between DO-178C levels, so a one-level mismatch is a broad set of gaps rather than a single missing document.
- Independence is the objective most often claimed in the plan but not evidenced in the data, because the plan states it and the artifacts have to show it.
- A level set too low reaches back into the safety assessment, so the cheapest software fix can turn into the most expensive safety rework.
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 was developed to a lower level than we now need?
Raising the effective level means meeting the additional objectives that level requires, which can mean new verification, added independence, or reworked lifecycle data. The closure work identifies exactly which objectives are unmet so the scope of that rework is known, rather than discovered piecemeal as a reviewer probes.
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.