TSO finding closure
Closing software data that does not satisfy its assigned DO-178C level
This supports equipment suppliers whose software lifecycle data does not meet the DO-178C objectives expected at the software level the article was assigned. A specialist takes the assigned software level and the objectives that come with it, then checks the lifecycle data against each objective to find which are unmet, partially met, or met by evidence that does not carry the required independence. The work runs during the program, usually after a reviewer or a stage-of-involvement audit questions whether the data supports the level. You receive a closure brief listing the unmet objectives, an evidence request list for the artifacts that have to be produced, and a disposition package that maps lifecycle data to objectives at the assigned level.
When this review is needed
- A reviewer questions whether the lifecycle data satisfies every objective for the assigned software level.
- The software level was raised after the safety assessment, but the lifecycle data was produced for the lower level.
- Structural coverage or independence evidence expected at the level is thin or absent in the submitted data.
- A stage-of-involvement audit found objectives marked satisfied without the artifact that satisfies them.
The problem
A software level is a promise about how much assurance the lifecycle data carries, and the objectives that come with it scale sharply from one level to the next. Data produced for one level does not automatically satisfy a higher one, because the higher level adds objectives and adds independence requirements that change who could have produced the evidence. When the level assigned by the safety assessment and the level the data was actually built to drift apart, the artifacts look present but do not meet the objectives, and structural coverage and independence are usually the first things to fall short.
What gets reviewed
- The assigned software level confirmed against the safety assessment and the objectives it carries
- Each applicable DO-178C objective checked against the lifecycle data for satisfaction and independence
- Objectives that are unmet, partially met, or met without the required independence identified
- Structural coverage evidence checked against the coverage criteria the assigned level requires
- The path to produce each missing artifact scoped, whether new test, new analysis, or independent review
- A reconciled objectives table mapping every objective to the lifecycle data that satisfies it
What gets validated
- Every applicable objective for the assigned level maps to a lifecycle data artifact that satisfies it
- Objectives that require independence are satisfied by evidence produced with that independence
- Structural coverage meets the criteria the assigned level requires, with deactivated and dead code addressed
- The assigned software level is consistent with the failure condition the software contributes to
- No objective is marked satisfied by an artifact that addresses a different objective
Evidence normally required
- The plan for software aspects of certification and the software level assigned to the article
- The software lifecycle data: requirements, design, code, and verification results
- Structural coverage and test result records
- The safety assessment output that sets the software level
- Any reviewer comments or stage-of-involvement findings on the software data
Common discrepancies
- Lifecycle data built to a lower level than the safety assessment finally assigned
- A verification objective satisfied by a review that lacked the required independence
- Structural coverage short of the criteria the assigned level requires
- An objective marked satisfied in the checklist with no artifact that actually satisfies it
What is at stake
Software objectives that are unmet at the assigned level are the objectives a reviewer checks most closely, because they touch the assurance the level exists to provide. Closing them can mean regenerating test cases, rerunning coverage analysis, or reworking who performed a review to restore independence, all of which are slow and land near the end of the program. Data that ships claiming a level it does not support invites the reviewer to distrust the software submission as a whole, and software is rarely the finding a supplier can talk its way past.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Fix the level and its objectives
Confirm the assigned software level against the safety assessment and enumerate the objectives it carries.
Check the data
Test the lifecycle data against each objective for satisfaction, independence, and coverage.
Scope each gap
For every unmet or under-independent objective, scope the artifact that closes it and name the owner.
Reconcile the table
Deliver an objectives table mapping data to objectives at the assigned level with a disposition package.
What the buyer receives
- A closure brief listing each unmet or under-independent objective at the assigned software level
- An evidence request list for the test, analysis, or independent review each gap requires
- A disposition package mapping lifecycle data to objectives at the assigned level
Who uses the output
- Certification leadership deciding rework versus re-argument for each objective gap
- Software leads scheduling the test, coverage, and review work to close objectives
- Program management tracking objective closure against the software submittal date
How the work fits into the transaction or program
This checks the software submission against the level the safety assessment assigned, sitting between software development and the compliance submittal. It catches the case where the level rose but the data did not, so the objectives table the supplier submits actually carries the assurance the assigned level claims.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-178C as the means of compliance for software, and both expect the full objective set for the assigned level with the required independence. The objective checks are authority-neutral, though the depth of stage-of-involvement engagement a reviewer applies can vary with the article and the level.
Regulatory limits
The work maps lifecycle data to objectives and identifies which objectives are unmet at the assigned level. It does not perform the software verification, does not assign or approve the software level, and does not grant any authorization; the level and its acceptance stay with the safety assessment and the authority.
What this review does not cover
- Producing the missing test cases, coverage analysis, or independent reviews
- Reassigning the software level to fit the existing data
- Modifying the software to reduce the objectives that apply
Specific to this review
- Objectives scale sharply between levels, so data built one level too low is short by whole objectives, not by detail.
- Independence is the quietest gap: an objective can be met technically yet fail because the wrong person produced the evidence.
- Structural coverage is usually the first shortfall to surface, because the coverage criteria tighten as the level rises.
- When the software level is raised after the safety assessment, the lifecycle data almost always lags the new level unless someone forced a re-baseline.
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
Our software passed all its tests. Why does the data not satisfy the level?
Passing the tests you ran satisfies the objectives those tests were built for. A level mismatch appears when the assigned level requires objectives your data was not built to meet, often added structural coverage or reviews performed with independence. The tests are valid; the gap is that the assigned level demands objectives the current data does not cover.
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.