Airborne software
DO-178C software lifecycle data support for installation approval
DO-178C data support checks that the software lifecycle data behind an installed article satisfies the objectives its assigned design assurance level demands, and that the data set is internally consistent from plans through to the accomplishment summary. It is prepared by or for the modifier ahead of an installation approval package. The work reads the plans, the development and verification standards, the verification records, and the summary, then tests whether the objectives claimed as satisfied are actually evidenced at the level the software was assigned. You receive an objective-coverage view keyed to the software level, a gap assessment naming under-evidenced objectives, and a closure plan for the lifecycle data.
When this review is needed
- A software item was developed to one design assurance level and is now being installed in a role that the safety assessment assigns a higher level.
- The lifecycle data came from a supplier and the modifier has to show it satisfies the objectives for the level claimed.
- Plans, standards, and verification records were produced by different teams and were never checked for consistency against each other.
- An accomplishment summary asserts every objective is met and the project wants that assertion tested before a reviewer does.
The problem
DO-178C compliance is a set of objectives that scale with the software level, and the hard part is proving each objective was satisfied with independence where the level requires it. Lifecycle data assembled over a long development, or inherited from a supplier at an unknown level, can look complete while missing the structural coverage, the independent review, or the traceability that the assigned level actually calls for. The accomplishment summary claims closure, but the claim rests on data the summary itself does not display.
What gets reviewed
- The plans, development standards, and verification standards checked for mutual consistency
- Objective coverage assessed against the assigned software level, not a generic checklist
- Verification records tested for the independence the level requires where it requires it
- Coverage evidence confirmed to match the assigned level and the code actually installed
- The accomplishment summary reconciled to the underlying data it claims to summarize
- A closure plan for objectives that are claimed but not supported by producible evidence
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
- Each objective the assigned software level requires has evidence, with independence shown where mandated
- The software level in the data matches the level the safety assessment allocates to the function
- Coverage results correspond to the code baseline being installed, not an earlier build
- Verification records trace to the requirements and to the version under review
- The accomplishment summary's claims each resolve to a producible lifecycle artifact
Evidence normally required
- The Plan for Software Aspects of Certification and the associated development and verification plans
- Software development and verification standards
- Test results, verification records, and structural coverage analysis
- The Software Accomplishment Summary and configuration index
- The software level allocated by the safety assessment
Common discrepancies
- An objective satisfied without the independent verification the assigned level requires
- Structural coverage evidence produced against a build earlier than the installed one
- A software item developed to a lower level than the installation role now demands
- An accomplishment summary claim that has no producible verification record behind it
What is at stake
Software objectives that are claimed but not evidenced at the assigned level draw the deepest review of any installation evidence, because a reviewer can sample any objective and ask for the artifact behind it. A shortfall found late means reopening verification activities, structural coverage analysis, or independent review that cannot be recreated quickly, and the software item can hold up the entire installation approval while it is redone.
How the work runs
Confirm the assigned level
Establish the software level the safety assessment allocates and use it, not the data's origin level, as the yardstick.
Map objectives to evidence
Bind each objective the level requires to its lifecycle artifact and note where independence is mandated.
Reconcile the summary
Test each accomplishment summary claim against a producible record and against the installed build.
Plan the closure
Sequence the under-evidenced objectives by the verification or analysis effort each one needs.
What the buyer receives
- An objective-coverage view keyed to the assigned software level
- A gap assessment naming each objective that is claimed but under-evidenced
- A closure plan for the lifecycle data before the package is submitted
Who uses the output
- Certification project managers judging whether the software data will withstand sampling
- Engineering leads scoping the verification or coverage work an open objective needs
- Compliance staff presenting the objective coverage and independence to the reviewer
How the work fits into the transaction or program
Software lifecycle data is one of the deepest evidence streams in an installation package, and the safety assessment sets the level it must reach. This coverage view confirms the data meets that level before it is bound into the compliance matrix, so a level mismatch or an independence gap is caught while there is still time to close it rather than at the review that samples it.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-178C as the means of compliance for airborne software, and the objective set does not change between them. What can differ is how the software level is allocated through the certification basis and the safety assessment, so the coverage view is read against the level this installation's basis assigns rather than a level carried over from the software's origin.
Regulatory limits
The work assesses the lifecycle data against its assigned level and flags under-evidenced objectives. It does not develop or verify software, does not assign the software level, and does not make a compliance finding or grant an approval. Verification activity and the compliance determination rest with the applicant's team and the authority.
What this review does not cover
- Performing software verification, testing, or structural coverage analysis
- Allocating the software level or writing the safety assessment
- Any compliance finding or approval on the software item
Specific to this review
- A level mismatch is the costliest software finding, because raising a lower-level item to a higher level reopens objectives that independence rules made expensive the first time.
- Structural coverage is where installed data most often detaches from the build, since coverage analysis is run once and rarely regenerated against a later code change.
- The accomplishment summary is a claim, not evidence, so a clean summary tells a reviewer nothing until the objectives it asserts can each be produced.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
The software was already certified in another aircraft. Is that enough?
Not on its own. Prior use shows the item was assessed at some level, but the installation role here may demand a higher level, and the lifecycle data has to satisfy the objectives for the level this basis assigns. The review checks the data against that level rather than accepting the origin level.
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.