DO-178C software data evidence review for certification teams

When this review is needed

• A safety assessment raised the software level and the lifecycle data still satisfies only the lower level's objectives.
• The verification records lack the structural coverage the assigned level demands.
• The plans and standards describe a process the accomplishment summary does not show was followed.
• The team is preparing to submit and wants the lifecycle data checked against every applicable objective.

The problem

DO-178C ties a defined set of objectives to each software level, and the data package can drift out of step with the level it is supposed to satisfy. A level assignment moves up after a safety analysis, but the verification effort planned for the lower level is not expanded. The plans promise a process, yet the records show a different one was run. Structural coverage that the higher level requires is partial or absent. The package reads as a complete set of documents while quietly falling short of the objectives its level actually calls for.

What gets reviewed

• The assigned software level confirmed against the objectives the lifecycle data must satisfy
• Plans and standards checked so the process they define matches the accomplishment summary
• Verification records checked for the review, analysis, and test the level requires
• Structural coverage checked against the level's coverage objectives
• Independence checked where the assigned level requires it
• Data-item completeness confirmed across the plans, standards, and lifecycle records

What gets validated

• The objectives satisfied by the lifecycle data match the assigned software level, not a lower one
• The process the accomplishment summary records matches the plans and standards
• Verification records include the review, analysis, and test the level demands
• Structural coverage meets the level's coverage objectives with gaps explained
• Independence is demonstrated wherever the assigned level requires it

Evidence normally required

• The software plans and standards for the item
• The verification records, including review, analysis, and test results
• The software accomplishment summary and configuration index
• The assigned software level and the safety assessment that sets it
• The structural coverage analysis and any coverage gap rationale

Common discrepancies

• Lifecycle data satisfying a lower level than the software was assigned after a level increase
• An accomplishment summary describing a process the records do not show was followed
• Structural coverage short of the level's coverage objectives with no analyzed rationale
• Verification lacking the independence the assigned level requires

What is at stake

Lifecycle data that satisfies a lower level than the software is assigned is a finding that reopens verification, and closing it can mean adding coverage analysis or independence to work the team considered finished. A plan-to-record mismatch is worse, because it suggests the declared process was not the process followed, which puts the credibility of the whole software data package in question.

How the work runs

What the buyer receives

• A gap list identifying each objective the lifecycle data does not satisfy at the assigned level
• An evidence map linking every applicable objective to its lifecycle data
• A closure sequence ordering the objective-satisfaction work against submittal

Who uses the output

• Compliance managers confirming the software data meets its level before submittal
• Certification leads deciding which objective gaps must close first
• Engineering owners expanding verification to the objectives a level increase created

How the work fits into the transaction or program

The DO-178C software data satisfies the software objectives that flow from the item's design assurance level, so its adequacy is measured against a level the safety assessment sets rather than against effort alone. Reviewing it before submittal catches a level-to-data mismatch while the verification schedule can still absorb the fix, and the objective map it produces feeds the compliance matrix rows and the requirements trace the software leans on.

Jurisdiction-specific considerations

FAA and EASA both accept DO-178C for airborne software, but they differ on supplementary guidance and on how coverage and independence gaps are documented and closed. Where software is certified under both, the review notes where lifecycle data acceptable to one authority needs additional rationale or independence to satisfy the other.

Regulatory limits

The review confirms the lifecycle data satisfies the assigned level's objectives and is internally consistent. It does not assign the software level, perform verification, or determine that the software is compliant or airworthy.

What this review does not cover

• Performing the software verification or coverage analysis
• Assigning or changing the software level
• Any determination that the software satisfies its objectives

Specific to this review

• DO-178C objectives are fixed to the software level, so a level increase after a safety analysis silently raises the bar the existing data must clear.
• A plan-to-record mismatch is the most damaging finding, because it implies the process that was run was not the process the plans committed to.
• Structural coverage is where a level increase bites hardest, since the higher levels demand coverage that a lower-level verification effort simply never produced.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits