STC software evidence
STC program DO-178C software lifecycle data support
This review prepares the airborne software lifecycle data behind an STC so the package holds together at the assigned software level. A certification engineer runs it once the plans, standards, and verification records exist but before the modifier submits for formal review. It reads the PSAC, the development and verification standards, the review and test records, and the software accomplishment summary, then measures each against the certification basis. You get a gap assessment, a trace map from objectives to evidence, and a closure plan the program can work before an authority sees the data.
When this review is needed
- A modifier is assembling an STC package and the software evidence has to match the assigned level before submittal.
- A supplier delivered lifecycle data and the modifier needs it checked against the certification basis before it goes forward.
- The software level was raised late in the program and the existing objective evidence has to be re-read against the harder target.
- A prior STC reused this software and the program needs to confirm the delta evidence covers what the new installation changed.
The problem
DO-178C data arrives as a stack of plans, standards, records, and a summary that each claim compliance on their own terms. The modifier owns the STC even when a supplier wrote the software, so a thin verification record or an objective satisfied by assertion rather than evidence becomes the modifier's problem at the worst moment. Reading the level correctly and confirming the evidence actually reaches it takes engineering time the program rarely has once the submittal date is set.
What gets reviewed
- The PSAC read against the certification basis and the assigned software level
- Development, verification, and configuration management standards checked for internal consistency
- Verification records confirmed to cover the objectives the level requires
- The software accomplishment summary reconciled to the evidence it references
- Trace from requirements through design and code to verification results
- Open problem reports and their disposition against the claimed compliance
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 for the assigned level maps to a verification record that actually satisfies it, not a plan that promises it
- Requirement, design, and code trace runs both directions without a broken link at a module boundary
- Test coverage matches the structural coverage the level requires rather than a lower target
- The accomplishment summary cites evidence that exists and matches the delivered records
- Open problem reports are classified and dispositioned in a way the certification basis accepts
Evidence normally required
- The Plan for Software Aspects of Certification and the referenced lifecycle plans
- Development, verification, coding, and configuration management standards
- Review, analysis, and test records with their results
- The software accomplishment summary and configuration index
- The certification basis and the assigned software level for the function
Common discrepancies
- An objective marked satisfied in the summary with no verification record behind it
- Structural coverage taken at a lower level than the function was assigned
- A requirements-to-test trace that breaks where a module was integrated late
- Open problem reports left unclassified against the software level's acceptance criteria
What is at stake
Software data that does not reach the assigned level draws a request for correction that stalls the whole STC, the modification with it. If the shortfall is structural, a missing test case class or an unstated objective, the fix reopens verification and slides the schedule past the installation slot the modification was booked into. Reworking objective evidence after formal review has started costs far more than closing the gap before it.
How the work runs
Fix the level and basis
Confirm the assigned software level and the certification basis the evidence must satisfy for this function.
Read plans against records
Check the PSAC and lifecycle plans against the verification records that are supposed to fulfill them.
Trace objectives to evidence
Map each objective for the level to a record that satisfies it and flag the ones that do not.
Sequence the closure
Order the missing objective evidence so verification finishes before formal review opens.
What the buyer receives
- A gap assessment mapping each software objective to the evidence that supports it
- A trace map from requirements through verification the program can hand to the authority
- A closure plan sequencing the missing objective evidence before formal review
Who uses the output
- Certification engineers deciding whether the software data is ready to submit
- Program managers sequencing the software closure against the submittal date
- Modifiers accountable for a supplier's lifecycle data on their STC
How the work fits into the transaction or program
The review sits between a supplier's software delivery and the modifier's formal STC submittal. It gives the program a defensible read of the software evidence so the accomplishment summary the authority reads is backed by records that exist, and its closure plan drives the verification work that has to finish before submittal.
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 way software evidence is presented and which findings an authority raises differs by system, so the review notes where the same data may need repackaging for the second authority when the STC is heading for validation.
Regulatory limits
The review reads the software lifecycle data against the assigned level and the certification basis. It does not assign the software level, approve the software, sign a compliance finding, or make any airworthiness determination on the modification.
What this review does not cover
- Writing or re-running the software verification tests
- Assigning or changing the software level for the function
- Signing a software compliance finding or granting the STC
Specific to this review
- An objective can read as satisfied in the accomplishment summary while the record behind it proves a weaker claim, which is why the summary is reconciled to the actual evidence rather than trusted.
- Raising the software level late is the most expensive gap to close because it reopens structural coverage that lower-level testing never captured.
- The modifier carries the software compliance risk even when a supplier authored every line, so the trace has to survive a handoff the modifier did not control.
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. 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).
Frequently asked questions
Our supplier says the software is already DO-178C certified. Do we still need this?
Software is approved as part of a specific certification, not in isolation, so a supplier's prior work still has to trace to your STC's basis and installation. The review confirms the delivered evidence reaches the level your function was assigned and that the accomplishment summary matches the records, rather than taking the supplier's status on trust.
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.