ETSO authorization
DO-178C software lifecycle data support for ETSO
This review examines the DO-178C software lifecycle data supporting an EASA European Technical Standard Order authorization, meaning the plans, development standards, verification records, and accomplishment summary that show the airborne software was developed to its assigned level. A certification specialist checks that the objectives DO-178C requires at that software level are actually addressed by the data, with the independence and rigor the level calls for. It runs as the lifecycle data matures, before the accomplishment summary is finalized. You receive a gap assessment against the software level, an evidence map from objective to data, and a closure plan for the objectives not yet satisfied.
When this review is needed
- The software lifecycle data has matured and the supplier wants it checked before the summary is finalized.
- The assigned software level demands objectives with independence that the verification records must show were met.
- A previously developed software component is being reused and its data has to be assessed for the new level.
- The PSAC and the actual lifecycle data have drifted apart during development.
The problem
DO-178C ties a defined set of objectives to the assigned software level, and the data has to show each of those objectives met, some with independence. Over a development, the plans get written, the code gets built, and the verification runs, but the three do not always stay aligned to the level. A component developed to a lower level gets pulled into a higher-level function, verification is run without the independence the level requires, or the standards named in the plans were not the ones actually followed. The data volume looks complete, but the objective coverage at the assigned level is not.
What gets reviewed
- The plans, including the PSAC, against the assigned software level and the ETSO
- Development and verification standards named versus those actually applied
- The verification records against the objectives the level requires, including independence
- The software accomplishment summary against the data it claims to summarize
- Reused or previously developed software and its coverage for the current level
- Consistency between the software data and the compliance matrix and safety assessment
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 DO-178C objective for the assigned software level is addressed by lifecycle data
- Objectives requiring independence show verification performed with that independence
- The standards the code was built and reviewed against match those the plans name
- The accomplishment summary reflects the data actually produced, not the data planned
- Reused software carries coverage or supplemental data adequate for the current level
Evidence normally required
- The software lifecycle data set at its current maturity
- The plan for software aspects of certification and the development plans
- The verification records and their independence evidence
- The assigned software level and the failure-effect classification behind it
- The accomplishment summary if it has been drafted
Common discrepancies
- Objectives requiring independence verified without the independence shown
- A component developed to a lower level than the function it now serves
- Standards named in the plans that differ from those actually followed
- An accomplishment summary claiming coverage the verification records do not show
What is at stake
If objectives for the assigned level are unmet or lack the required independence, the software is not shown to that level, and the function it supports cannot be authorized as claimed. Recovering that late can mean re-running verification with independence, or re-planning the whole component to the correct level, which is among the most expensive corrections a supplier can hit near submittal.
How the work runs
Confirm the level
Establish the assigned software level from the failure-effect classification and the EASA agreement.
Map the objectives
Check each DO-178C objective for that level against the lifecycle data, noting where independence is required.
Test the reuse
Assess reused or previously developed software for coverage adequate to the current level.
Reconcile the summary
Deliver a gap assessment and a closure plan for objectives the accomplishment summary overstates.
What the buyer receives
- A gap assessment of objectives unmet for the assigned software level
- An evidence map from each level objective to the lifecycle data that meets it
- A closure plan for the objectives needing rework or supplemental verification
Who uses the output
- Certification leads confirming the software meets its level before summary
- Compliance managers reconciling the software data to the matrix and safety case
- Software engineers closing the objective gaps the review identified
How the work fits into the transaction or program
The software level flows down from the article's failure effects, and the lifecycle data has to hold to that level or the function it supports cannot be authorized. Checking objective coverage against the level before the summary is cut means the software case that reaches EASA is one the objectives actually support, rather than a data set that is voluminous but short at the level that matters.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
EASA accepts DO-178C as the software means of compliance for an ETSO and expects the assigned level to match the article's contribution to failure conditions. The review reads objective coverage against the EASA-agreed level and any additional considerations EASA has raised, rather than assuming the level a lighter reading might allow.
Regulatory limits
The review evaluates the supplier's software lifecycle data. It does not develop or verify the software, accept the data on EASA's behalf, or determine that the software meets its level in the authority's judgment. Final acceptance of the lifecycle data belongs to EASA.
What this review does not cover
- Developing or verifying the airborne software
- Accepting the software data on the authority's behalf
- Assigning the software level itself
Specific to this review
- Independence is where higher software levels are most often short, because it constrains who may perform a verification, beyond the question of whether it was performed at all.
- Reused software carries only the coverage of the level it was developed to, so pulling it into a higher-level function creates an objective gap that is invisible in the volume of data.
- The accomplishment summary is a claim, not evidence, so a summary can assert coverage the underlying records do not actually contain.
Sources
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
We reused a software component from an earlier product. Does that reduce the review?
It changes the focus. Reused software only carries the objective coverage of the level it was originally developed to, so the review concentrates on whether that coverage is adequate for the level the component now serves, and what supplemental data closes any shortfall.
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.