Certification problem
Software lifecycle data that does not match the assigned software level
This page is for avionics and equipment suppliers whose airborne software lifecycle data falls short of the objectives its assigned software level requires under DO-178C. It triggers when the software level was set at one assurance level while the data, structural coverage, independence, or specific lifecycle artifacts reflect a lower one. The review compares the assigned level against the objectives that apply at that level and the data produced, examining plans, coverage results, review records, and verification artifacts. You get the objectives that are unmet at the assigned level and the data each shortfall needs.
When this review is needed
- The assigned software level demands structural coverage the achieved coverage does not reach.
- Independence is required at the assigned level but the verification was done by the developer.
- A lifecycle artifact required at the level is absent or stops at a lower level of rigor.
- The team wants the produced data reconciled against the level's objectives before submittal.
The problem
A software level is a commitment to a defined set of objectives, and the data has to satisfy every one that applies at that level. Programs assign the level early, then produce data that quietly tracks a lower one as schedule pressure builds. Structural coverage stops short of what the level requires, verification independence lapses, and a required artifact is thinned out. The plans still declare the higher level, so the mismatch hides in the gap between what was promised and what the lifecycle data actually demonstrates.
What gets reviewed
- The assigned software level and the objectives that apply at that level under DO-178C
- The structural coverage achieved against the coverage the level requires
- Verification independence where the level calls for it
- Required plans and standards present and consistent with the level
- Requirements-based test results at the level's expected rigor
- Lifecycle data that stops at a lower level than the one assigned
What gets validated
- Every DO-178C objective applicable at the assigned level has corresponding data
- Structural coverage meets the type and extent the assigned level demands
- Verification independence is satisfied where the level requires it
- The plans declare a level that the produced data actually supports
- Requirements-based testing covers the requirements at the level's rigor
- No required artifact is missing or thinned below the assigned level
Evidence normally required
- The assigned software level and the system safety basis for it
- The software plans and standards declaring the level
- The structural coverage results and verification records
- Requirements-based test data and review records produced so far
Common discrepancies
- Coverage achieved below the structural type the assigned level requires
- Verification performed without the independence the level calls for
- Plans declaring a higher level than the produced data supports
- A required objective with no corresponding lifecycle artifact
- Requirements-based testing thinner than the assigned level expects
What is at stake
Software data that does not meet its assigned level is an assurance shortfall against the level the system safety analysis relied on. A reviewer comparing the level to the objective data finds coverage short or independence missing, and closing it can mean rerunning verification with independence or generating coverage the program assumed it already had, both of which are expensive late.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Anchor the level
Confirm the assigned software level and the DO-178C objectives that apply at it.
Map the data
Lay the produced lifecycle data against each applicable objective for the level.
Find the shortfalls
Flag coverage, independence, and artifacts that track a lower level than assigned.
Order the closure
Name the data each shortfall needs and sequence by cost to satisfy late.
What the buyer receives
- The objectives unmet at the assigned software level
- For each shortfall, the coverage, independence, or artifact still required
- A note where the declared level and the demonstrated rigor diverge
- A closure list ordered by the objectives most expensive to satisfy late
Who uses the output
- Software certification leads aligning the data to the assigned level
- Verification engineers closing coverage and independence gaps
- Certification engineers reconciling the plans with the demonstrated data
How the work fits into the transaction or program
This pass examines software assurance against its assigned level specifically. It complements a hardware-level check and an environmental-qualification check when a program needs its full assurance evidence reviewed.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Regulatory limits
Endeavor Elements compares the applicant's software data against the objectives of the assigned level. It does not assign the software level for the authority, perform the verification, or guarantee acceptance of the lifecycle data.
What this review does not cover
- Assigning or approving the software level
- Performing the verification or generating coverage
- Issuing approvals or making official compliance findings
Specific to this review
- A software level is defined by the set of DO-178C objectives that apply at it, so the data fails the level the moment one applicable objective has no supporting artifact.
- Structural coverage type changes with the level, so coverage that satisfies a lower level can be insufficient at the assigned one even when the percentage looks high.
- Independence is the requirement most often lost under schedule pressure, because letting the developer verify their own work is faster than arranging an independent activity.
- The plans declaring the level rarely change when the data slips, so the declared level and the demonstrated rigor drift apart silently.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
We hit high coverage numbers, so why is coverage a finding?
Because the type of structural coverage required rises with the software level. Coverage adequate for a lower level can fall short at the assigned one, so a high percentage of the wrong coverage type is still a 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.
Walk through your situation with an engineer who has done this work.