TSO authorization
DO-178C software lifecycle data support for TSO authorization
A DO-178C software lifecycle data review confirms that the software evidence in the package satisfies the objectives for the level assigned to the article. Equipment suppliers use it before submission, so the delivered data matches the software level the plan committed to rather than a lower one. It checks the plans against the assigned level, confirms the verification records satisfy the objectives that level demands, and reads the software accomplishment summary against what the underlying data actually shows. You get a gap assessment against the level's objectives, a map from each objective to its lifecycle data, and a closure plan for the objectives the data does not yet satisfy.
When this review is needed
- The software lifecycle data is assembled and its coverage has to be checked against the assigned level before submission.
- The software level was raised during the program and the existing data has to be re-checked against the harder objective set.
- The accomplishment summary is being written and needs to reflect what the verification records actually show.
- Structural coverage or independence objectives may not be satisfied at the level the plan committed to.
The problem
The objective set DO-178C requires scales sharply with the software level, and data assembled to one level does not quietly satisfy a higher one. Plans, standards, and verification records are produced by different people over a long program, and whether they collectively meet every objective for the assigned level is rarely checked as a whole until the accomplishment summary has to claim it. The summary can assert closure the underlying records do not support.
What gets reviewed
- Software plans and standards checked against the assigned software level
- Verification records confirmed to satisfy the objectives that level requires
- Structural coverage and independence appropriate to the assigned level
- The software accomplishment summary read against the underlying lifecycle data
- Configuration management and quality assurance records for the software
- Objectives the assigned level requires that the data does not yet address
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- The plans and standards commit to the objective set the assigned level requires
- Verification records exist for each objective at that level, with independence where required
- Structural coverage matches the level's expectation and gaps are analyzed, not ignored
- The accomplishment summary states only what the underlying records support
- Configuration and quality records cover the software the summary claims to have produced
Evidence normally required
- The software plans, standards, and the assigned software level
- Verification records including reviews, analyses, and test results
- Structural coverage data for the software
- The draft software accomplishment summary
- Configuration management and quality assurance records for the software
Common discrepancies
- Verification records that satisfy a lower level than the one assigned
- Independence missing on objectives the assigned level requires it for
- Structural coverage gaps left unanalyzed rather than justified
- An accomplishment summary claiming closure the verification records do not show
What is at stake
Software data that falls short of its assigned level is a finding that reopens verification, and at the higher levels the missing objectives, structural coverage or independence, are the most expensive to satisfy late. An accomplishment summary that overstates what the records show is worse, because it commits the applicant to a claim a reviewer can disprove by opening the data it summarizes.
How the work runs
Set the objective target
Establish the full objective set the assigned software level requires.
Check the records
Confirm verification, coverage, and independence satisfy each objective at that level.
Read the summary
Test the accomplishment summary's claims against the underlying lifecycle data.
Close the objectives
List the unmet objectives and sequence the verification that closes them.
What the buyer receives
- A gap assessment against the assigned level's objective set
- A map from each objective to the lifecycle data that satisfies it
- A closure plan for the objectives the data does not yet address
Who uses the output
- Certification leads presenting software compliance to the FAA
- Software leads resolving objectives the assigned level requires but the data misses
- Program managers tracking which software objectives still block the package
How the work fits into the transaction or program
The DO-178C data is the software evidence the compliance matrix and the trace both point to, so this review runs after the lifecycle data is assembled and before the accomplishment summary is finalized. Its closure plan drives the remaining verification, and its objective map becomes how a reviewer navigates the software case.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
DO-178C is the software assurance standard the FAA accepts for the article, so objective coverage is judged against FAA-accepted use of it. The same lifecycle data can support a program under another authority, but the assigned level and objective expectations are re-checked rather than assumed to carry across.
Regulatory limits
The review checks that the software data satisfies the objectives for its assigned level. It does not develop the software, run its verification, or make a finding that the software complies with DO-178C.
What this review does not cover
- Producing or verifying the airborne software
- Setting the software assurance level as a regulatory decision
- Issuing an FAA finding on the software lifecycle data
Specific to this review
- The objective set scales steeply with software level, so data built to one level does not partially satisfy a higher one, it fails the added objectives outright.
- Independence and structural coverage are the objectives most often short at the higher levels, because they cannot be recovered by re-documentation and need actual rework.
- The accomplishment summary is where over-claiming concentrates, since it asserts closure a reviewer can test directly against the records it summarizes.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
The software level was raised late. Does the existing data still count?
Some of it does, but a higher level adds objectives the earlier data was never built to satisfy, often independence and structural coverage. The review separates what carries forward from what the new level requires fresh, so the added work is scoped before the accomplishment summary claims closure.
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.