Airborne software lifecycle data
DO-178C software lifecycle data evidence review for equipment suppliers
This review examines a supplier's DO-178C software lifecycle data as a set: the plans, the development and verification standards, the verification records, and the software accomplishment summary that ties it together. It checks that the objectives satisfied match the assigned software level and that the accomplishment summary tells a story the underlying data actually supports. A software certification engineer runs it before submittal, in response to a finding, or when a change to the level or the design reopens objectives. You receive a gap list of objectives short of their level, an evidence map, and a closure sequence for engineering leadership.
When this review is needed
- The plans were written against one software level and a later safety assessment raised or lowered it.
- Verification data was produced across multiple builds and the accomplishment summary has not been reconciled to the final one.
- A finding asks the supplier to show that structural coverage objectives were met at the assigned level.
- Reused or previously developed software is being carried into this program and its data needs to be re-baselined.
The problem
DO-178C data lives in many documents that were each correct when written but were not maintained as a coherent whole. The plans commit to a level, the standards describe practices, the verification records pile up build by build, and the accomplishment summary is drafted last, under pressure, claiming objectives are met. The claim is only as good as the data beneath it, and that data was often frozen at different moments.
What gets reviewed
- Check that the plans, standards, and accomplishment summary agree on the assigned software level
- Confirmation that the objectives satisfied match those required at that level, including independence
- Read of verification records against the structural coverage the level demands
- Reconciliation of the accomplishment summary to the final software build
- Identification of objectives claimed met without supporting lifecycle data
- Review of how previously developed or reused software was integrated and re-substantiated
What gets validated
- The software level is consistent across the plans, standards, and accomplishment summary
- Every objective required at the assigned level is addressed, with independence where required
- Structural coverage results match the level and account for any dead or deactivated code
- The accomplishment summary describes the final build, not an interim one
- Reused software carries the data needed to substantiate it at this program's level
Evidence normally required
- The software plans, including the PSAC and the verification and configuration plans
- The development and verification standards the project committed to
- Verification records covering reviews, tests, and structural coverage
- The software accomplishment summary and the software configuration index
- The assigned software level and the safety assessment that set it
Common discrepancies
- Structural coverage results that meet a lower level than the one the plans assign
- Objectives requiring independence satisfied without evidence the independence was real
- An accomplishment summary reconciled to an earlier build than the one being delivered
- Reused software claimed as credit without the data to substantiate it at this level
What is at stake
A reviewer reads the accomplishment summary and then samples the objectives it claims. When the sampled objective is short of its level, whether coverage, independence, or a missing review, the summary's other claims come under doubt and the sample grows. Reworking software lifecycle data late means reopening verification, which is among the longest closures a program can face.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Anchor the level
Confirm the assigned software level from the safety assessment and check the plans and summary all reflect it.
Map objectives to data
Walk the objectives required at that level to the lifecycle data claimed to satisfy each one.
Reconcile to the build
Confirm coverage and the accomplishment summary describe the final delivered software configuration.
Sequence the closures
Order gaps by the verification effort they demand so coverage-driven items start earliest.
What the buyer receives
- A gap list of objectives not satisfied at the assigned software level
- An evidence map from each objective to the lifecycle data that satisfies it
- A closure sequence ordering objective closures by the verification effort each needs
Who uses the output
- Engineering leadership scoping the verification rework before the data is submittable
- Certification leads presenting the software compliance argument to the authority
- Software leads reopening coverage and review activities to close objectives
How the work fits into the transaction or program
The DO-178C data set is a major branch of the compliance argument, and the software level that drives it comes from the safety assessment. This review checks the data against that level and connects to the verification trace review, since the objectives claimed here rest on the verification records that review confirms are real.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C as an acceptable means for airborne software, but each expects the software level to flow from the aircraft and system safety process rather than being assumed. This review confirms the level the data was built to matches the level the safety assessment assigns, which is where the two most often diverge.
Regulatory limits
This review evaluates the internal completeness of the software lifecycle data. It issues no airworthiness determination, approves no software, and does not decide whether the data satisfies DO-178C in the authority's judgment. That acceptance rests with the authority and its delegated software specialists.
What this review does not cover
- Performing software verification or generating structural coverage
- Writing or revising the plans, standards, or accomplishment summary
- Assessing the software's functional behavior in the target system
Specific to this review
- The accomplishment summary is written last and claims the most, so it is where the data set's optimism concentrates and where sampling starts.
- A software level raised by a late safety assessment is one of the costliest reopenings, because it can add objectives and independence to work already thought complete.
- Reused software rarely arrives with credit already earned, and re-substantiating it at a higher level than it was built to is a frequent, underestimated closure.
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
Can we get credit for software we already certified on another program?
Sometimes, but not automatically. Previously developed software has to be re-baselined against this program's assigned level and integration, and any level difference or configuration change can reopen objectives. This review identifies exactly what data the reused software still needs before the credit holds.
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.