Software certification
DO-178C software compliance support for airborne software
DO-178C software compliance support helps an avionics or equipment supplier prove that its airborne software lifecycle data satisfies the objectives the assigned software level demands. It is used by software teams whose plans, requirements, and verification evidence were assembled across a long program and may no longer line up with the level claimed. The work reviews the PSAC and the rest of the plans, the high- and low-level requirements and their traceability, the requirements-based test results, the structural coverage, and the configuration and quality records. You receive an objective-by-objective gap assessment keyed to the software level, a reconciled traceability view, and a prioritized list of the lifecycle data needed to close the package.
When this review is needed
- A software item is heading toward a stage-of-involvement review and the lifecycle data has to be checked against the objectives its level carries.
- The assigned software level changed after the safety assessment moved, and the objective set the plans committed to no longer matches.
- Structural coverage was run late and the gaps against the level's coverage criteria need to be understood before they are explained to a reviewer.
- Reused or previously developed software is being carried into a new program and the credit claimed for it has to be substantiated.
- A supplier wants an independent read of the software package before it goes to the authority or a delegate.
The problem
DO-178C ties the work to the software level, and the level is the first thing that drifts. The objective set for Level A is far heavier than for Level C, yet plans written early often promise verification independence and coverage criteria the program never actually produced. Requirements get refined, the code moves on, and the test cases trace to an earlier version of the high-level requirements. By the time anyone counts objectives, the gap between what the level demands and what the data shows is large and quiet.
What gets reviewed
- The plan for software aspects of certification and the other software plans and standards
- The assigned software level and the objective set it carries, including independence
- High-level and low-level requirements and their bidirectional traceability to code and tests
- Requirements-based test cases and procedures and their results against the requirements
- Structural coverage analysis appropriate to the level, including statement, decision, and MC/DC where required
- Derived requirements and their feedback into the safety assessment
- Software configuration management and quality assurance records and problem reports
What gets validated
- The objective set used matches the assigned software level, including the objectives requiring independence
- Every high-level and low-level requirement traces to code and to a requirements-based test
- Test results substantiate normal-range and robustness behavior for the requirements claimed verified
- Structural coverage meets the criteria the level demands and any shortfall has an analyzed justification
- Dead code, deactivated code, and derived requirements are identified and dispositioned
- Derived requirements are fed back to the safety assessment that should bound them
- Configuration baselines and problem reports pin the data to the software build it describes
Evidence normally required
- The PSAC and the software development, verification, configuration, and quality plans
- The high-level and low-level requirements and the traceability assembled so far
- Requirements-based test cases, procedures, and results, with the coverage data behind them
- The structural coverage analysis and any deactivated or dead-code dispositions
- Configuration management and quality assurance records and the open problem reports
- The assigned software level and the safety assessment that drove it
Common discrepancies
- An objective set sized for a lower level than the safety assessment now assigns
- Test cases tracing to a superseded revision of the high-level requirements
- Structural coverage short of the criteria the level requires, with no analyzed justification for the gap
- Deactivated or dead code present in the build with no disposition behind it
- Derived requirements that never returned to the safety assessment that should bound them
- Reuse credit claimed for previously developed software without the data to support it
- Problem reports closed in the tracker but not reflected in the verification status
What is at stake
When the lifecycle data does not satisfy the objectives the software level requires, the review reopens the level itself, and the program loses the schedule it spent producing data that does not count. Missing structural coverage or unjustified dead code can force re-verification of code that was thought finished, and that work lands on the software completion date the whole installation depends on.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the level
Establish the assigned software level and the exact objective set it carries, including which objectives require independence.
Reconcile traceability
Map high-level and low-level requirements through code to requirements-based tests and find where the trace breaks.
Count the objectives
Test the test results, structural coverage, and dispositions against the objective set the level demands and flag every shortfall.
Package the gaps
Produce an objective-by-objective gap assessment and a prioritized closure list ready for the stage-of-involvement review.
What the buyer receives
- An objective-by-objective gap assessment keyed to the assigned software level
- A reconciled traceability view from requirements through code to test and coverage
- A disposition log for derived requirements, dead code, and deactivated code
- A prioritized list of the lifecycle data to close before review
Who uses the output
- Certification leads preparing the software submittal or stage-of-involvement review
- Software engineering teams closing requirements, test, and coverage gaps
- Program management sequencing the remaining verification work
How the work fits into the transaction or program
The support strengthens the supplier's own DO-178C package ahead of review so the objective set holds up when an examiner counts it. It pairs with hardware and qualification work when the software sits inside a wider equipment program, and with a compliance-matrix review when the team needs the matrix itself checked.
Start with a single asset
Confirm requirements trace through verification.
Aircraft-specific considerations
The software level, not the airframe, drives how heavy the objective set is. A function whose failure is catastrophic carries Level A and its full independence and MC/DC expectations, while the same code in a function with minor failure effect may sit at Level C with a much lighter set. The review scales with the level the safety assessment assigns to the function, so the same software item can demand very different evidence depending on where it sits in the architecture.
Regulatory limits
Endeavor Elements supports the applicant's software lifecycle data. It does not act as the authority or a delegate, make compliance findings, issue any approval, or guarantee that a software level will be accepted. The applicant and the authority keep their roles, and the assignment of the software level remains a safety-assessment outcome the applicant owns.
What this review does not cover
- Making official compliance findings or acting as the authority or its delegate
- Issuing any approval, authorization, or design approval
- Writing the airborne software or running the qualification test campaign itself
Specific to this review
- DO-178C scopes its objectives by software level, so Level A carries the full set with independence while Level D carries a small fraction, and a mis-sized objective set is the most consequential finding.
- Modified condition/decision coverage is required at Level A and is where late coverage work most often falls short of the criteria the level sets.
- Deactivated code and dead code are treated differently: deactivated code needs a justified means of disabling it, while dead code generally has to be removed or analyzed.
- Reuse credit for previously developed software is allowable only with the lifecycle data to support it, which is why unsupported reuse claims surface so often.
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
Frequently asked questions
Does the review assign the software level for us?
No. The software level follows from the safety assessment, which the applicant owns. The review checks that the lifecycle data actually satisfies the objectives the assigned level carries and flags where it does not.
Can you help if structural coverage came in short?
Yes. A common engagement is analyzing a coverage shortfall against the level's criteria, separating genuine gaps from deactivated or dead code, and sequencing the re-verification needed to close the objectives.
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.