Field approval, airborne software
Field-approval DO-178C software lifecycle data support
This support readies airborne software lifecycle data so a field-approval package holds up when the FAA opens formal review. It reads the plans, development and verification standards, review and test records, and the software accomplishment summary against the assigned software level, then flags where the evidence falls short of that level. An engineer who has assembled DO-178C data for installed equipment runs it before the package is submitted. You receive a level-by-objective gap assessment, a traceable evidence map from requirement to test, and a sequenced closure plan.
When this review is needed
- An installed piece of equipment runs software and the field-approval package has to carry DO-178C evidence for it.
- The software level was assigned late, and the lifecycle data on hand was produced against a lighter set of objectives.
- Verification records exist but no one has confirmed they satisfy every objective the assigned level demands.
- A prior submission stalled because reviewers could not follow requirements down to test evidence.
The problem
DO-178C evidence is voluminous and produced across a project's whole life, so by submission time the plans, standards, review records, and accomplishment summary rarely line up cleanly. A field approval reviewer reads for objective coverage at the assigned software level, and any objective without traceable evidence stops the read. The modifier is usually assembling this from a supplier's data pack they did not build and cannot fully vouch for.
What gets reviewed
- Plans for software aspects of certification read against the assigned software level and its objectives
- Development and verification standards checked for the coverage the level requires
- Requirement, design, and code traceability confirmed down to review and test records
- The software accomplishment summary reconciled to the evidence it cites
- Open problem reports and their disposition against the level's objectives
- Tool qualification data where a tool output substitutes for a lifecycle activity
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
- Every objective at the assigned software level maps to a specific, retrievable piece of lifecycle evidence
- Requirement-to-test traceability holds without a break at the design or code boundary
- The plans and standards on file describe the process the evidence actually reflects
- Open problem reports are dispositioned in a way the assigned level permits
- Tool qualification evidence exists wherever a qualified tool result stands in for review or test
Evidence normally required
- The plan for software aspects of certification and the associated development and verification plans
- Software requirements, design, and code with their traceability data
- Review, analysis, and test records covering the verification objectives
- The software accomplishment summary and configuration index
- The assigned software level and the relevant certification basis
Common discrepancies
- Verification evidence sized for a lower software level than the one now assigned
- A traceability chain that breaks between high-level requirements and the design that implements them
- An accomplishment summary that cites test results the data pack does not contain
- A qualification-required tool used with no qualification data on file
What is at stake
A package that claims a software level its evidence does not support gets returned, and the modification waits on the certificate the field approval was meant to grant. Rebuilding verification evidence after the fact costs far more than confirming coverage before submission, and an installation already flying on an interim basis stays exposed until the data closes.
How the work runs
Fix the level and its objectives
Confirm the assigned software level and list the objectives the evidence has to satisfy at that level.
Trace requirement to test
Follow each requirement through design and code to the review and test records that verify it.
Reconcile the summary
Check the software accomplishment summary against the evidence it claims and note the mismatches.
Sequence closure
Order the missing lifecycle data by effort and dependency so the package can be completed.
What the buyer receives
- A gap assessment keyed to the objectives of the assigned software level
- A traceability map running requirement to design to code to verification evidence
- A closure plan sequencing the missing lifecycle data before submission
Who uses the output
- Engineering leads deciding what software evidence still has to be produced or recovered
- Compliance managers assembling the field-approval package for submission
- Maintenance leadership tracking when the installation can move off any interim basis
How the work fits into the transaction or program
This work sits between the supplier's software data pack and the FAA's formal review of the field approval. It converts a pile of lifecycle artifacts into a coverage picture the modifier can stand behind, and its closure plan feeds the evidence back into the package before it is submitted rather than after it is returned.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review measures software lifecycle data against the objectives of the assigned level and reports where coverage is missing. It does not assign the software level, make a compliance finding, approve the data, or determine that the installation is airworthy. Those decisions rest with the FAA.
What this review does not cover
- Writing or re-running the software verification tests behind a gap
- Assigning or reclassifying the software level
- Any airworthiness or approval decision on the installation
Specific to this review
- A software level assigned or raised late in a program is the usual reason lifecycle evidence falls short at submission.
- Objective coverage is read at the assigned level, so evidence adequate for a lower level reads as a gap at a higher one.
- A qualification-required tool used without qualification data can undo verification evidence that otherwise looks complete.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
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 came from a supplier. Can you review data we did not produce?
Yes. Most field-approval software evidence originates with a supplier the modifier is installing on the aircraft. The review works from the delivered data pack and the assigned level, and it flags exactly where the supplier's evidence does not reach the objectives the package has to demonstrate.
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.