AML STC expansion
DO-178C software lifecycle data support for an AML STC expansion
This work reviews the DO-178C software lifecycle data supporting an approved model list expansion, confirming the data set matches the software level the added installation assigns. It supports avionics and equipment suppliers extending an STC to new models, before submission. The review checks plans, standards, verification records, and the accomplishment summary for consistency with the assigned design assurance level, and finds where objectives for that level are claimed but not evidenced. You receive a gap assessment, a level-to-data map, and a closure plan for the lifecycle data still owed.
When this review is needed
- The added installation drives a software level for a function that differs from the level the software was originally approved to.
- Software changed for the expansion and the lifecycle data has to catch up to the new version and its objectives.
- The accomplishment summary predates the added models and its claims have to be re-checked against the current data.
- A reviewer will read the PSAC and accomplishment summary against the assigned level and the supplier wants that read done first.
The problem
DO-178C data is only coherent if the plans, the standards, the verification records, and the accomplishment summary all describe the same software at the same level. On an expansion, the level a function is assigned can rise if the added installation makes its failure condition more severe, and the lifecycle data written to the original level then falls short of the objectives the new level demands. The accomplishment summary still claims completeness against the old target.
What gets reviewed
- The software level assigned by each added installation confirmed against the failure-condition classification
- Plans and standards checked for consistency with the assigned level
- The verification records reviewed against the objectives the assigned level requires
- The accomplishment summary reconciled to the current software version and data
- Objectives claimed complete but not evidenced for the assigned level identified
- Open lifecycle data assembled into a closure plan for the STC holder
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 assigned software level matches the failure-condition classification for the added installation
- Plans and software standards are consistent with the objectives of the assigned level
- Verification records satisfy the coverage and independence the level requires
- The accomplishment summary describes the software version actually being submitted
- No objective for the assigned level is claimed complete without supporting data
Evidence normally required
- The PSAC and the other DO-178C plans for the software
- The software requirements, design, and coding standards
- Verification records including review, analysis, and test results
- The software accomplishment summary and configuration index
- The failure-condition classification driving the level on the added models
Common discrepancies
- A function whose software level rises on the added installation with data still built to the lower level
- Verification records that lack the structural coverage the assigned level requires
- An accomplishment summary describing a software version earlier than the one submitted
- Independence objectives claimed satisfied without evidence of the independent activity
What is at stake
A software level driven up by the added installation, with lifecycle data still built to the lower level, is a substantive gap: objectives required at the higher level are simply not satisfied. A reviewer reading the accomplishment summary against the assigned level finds the shortfall, and closing it can mean additional verification, coverage analysis, or independence that was never in the original plan. The expansion waits on software work that has real lead time.
How the work runs
Confirm the assigned level
Establish the software level each added installation drives from its failure-condition classification.
Check plans and standards
Confirm the plans and software standards are written to the objectives the assigned level demands.
Test data against objectives
Review verification records and the accomplishment summary for the coverage and independence the level requires.
Plan the open data
Sequence the lifecycle data still owed into a closure plan before submission.
What the buyer receives
- A gap assessment of lifecycle data that falls short of the assigned software level
- A level-to-data map showing where objectives are met and where they are open
- A closure plan for the software lifecycle data still owed before submission
Who uses the output
- STC holders confirming the software data holds up against the assigned level
- Certification leadership deciding where additional verification or coverage is required
- Program managers planning software lead time into the expansion schedule
How the work fits into the transaction or program
The software data review depends on the safety assessment, which sets the failure-condition classification that drives the assigned level. It runs after the compliance map and alongside the hardware lifecycle review, and its findings feed the verification trace, since an objective shortfall is also a hole in the evidence that closes requirements.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-178C, but the depth of scrutiny on stage-of-involvement records and on the accomplishment summary can differ. The review flags where the lifecycle data is thin against the assigned level so the software argument holds for either authority reviewing the expansion.
Regulatory limits
This work reviews the lifecycle data against the assigned level. It does not audit the software development, accept the data on the authority's behalf, or make a compliance finding on the software.
What this review does not cover
- Performing the software verification or coverage analysis that closes an open objective
- Assigning the software level or the failure-condition classification
- Any finding of compliance on the airborne software
Specific to this review
- An added installation can raise a function's software level by making its failure condition more severe, and lifecycle data written to the old level then falls short.
- The accomplishment summary is the fastest place a level mismatch shows: it claims completeness against a target the data no longer meets.
- Structural coverage and independence are the objectives most often missing when a level rises, because they were never required at the original assignment.
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.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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
What happens if the added installation raises the software level?
The lifecycle data has to satisfy the objectives of the higher level, which the original data set may not. That usually means additional verification, structural coverage, or independence rather than a rewrite. The review isolates exactly which objectives are now open so the added software work is scoped to what the higher level actually requires.
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.