DO-178C Explained: DAL Levels, Objectives, Audits and Testing

What is DO-178C?

DO-178C, "Software Considerations in Airborne Systems and Equipment Certification", is a process standard. It does not tell you how to write code. It tells you which objectives your software life cycle must meet, and which evidence proves it. The higher the safety risk of the software, the more objectives apply, and the more of them must be met with independence.

DO-178C never works alone. The FAA states that the supplements must be used together with DO-178C, and that the PSAC (Plan for Software Aspects of Certification) must say how they combine.

System-level requirements come from ARP4754A/B (aircraft and system development) and the safety assessment. Airborne electronic hardware follows DO-254. DO-178C starts where the system allocates requirements to software.

What are the DO-178C DAL levels?

The Design Assurance Level (DAL), also called software level, comes from the system safety assessment. It reflects the worst failure condition that a software failure could cause. DAL A is the most demanding; DAL E has no DO-178C objectives.

Data coupling and control coupling coverage applies at levels A, B and C. Each step down removes objectives, independence and coverage criteria, which is why the DAL is the first cost driver of a DO-178C project. Agree it with the system safety team early: a level that changes late changes the whole verification plan.

The 10 objective tables of Annex A

Annex A of DO-178C groups the objectives into ten tables. Each objective lists the DO-178C sections that describe it, the levels where it applies, whether independence is required, and which life cycle data proves it.

1. A-1 Software planning process
2. A-2 Software development processes (requirements, design, code, integration)
3. A-3 Verification of the high-level requirements (HLR)
4. A-4 Verification of the low-level requirements (LLR) and architecture
5. A-5 Verification of the source code and integration process
6. A-6 Testing of the outputs of the integration process (the executable object code)
7. A-7 Verification of verification: test procedures, results, requirements coverage, structural coverage
8. A-8 Software configuration management
9. A-9 Software quality assurance
10. A-10 Certification liaison

Tables A-6 and A-7 hold most of the test work. A-6 asks that the executable code complies with, and is robust to, the high-level and low-level requirements, and is compatible with the target computer. A-7 asks that test procedures and results are correct, that every HLR and LLR is covered by tests, and that the structural coverage criteria of your level are met.

Which documents do auditors expect?

DO-178C proves compliance through software life cycle data. The exact names vary by company, but the content is expected in every project:

• Plans: PSAC, Software Development Plan, Software Verification Plan, Software Configuration Management Plan, Software Quality Assurance Plan.
• Standards: requirements, design and coding standards.
• Development data: high-level requirements, design (architecture and low-level requirements), source code, executable object code.
• Trace data: bidirectional links between system requirements, HLR, LLR, code and tests.
• Verification data: review and analysis records, test cases and procedures, test results, coverage analysis.
• Configuration and quality records: baselines, problem reports, change history, QA records, Software Configuration Index.
• Software Accomplishment Summary (SAS): the final statement that the plans were followed and the objectives met.

Auditors do not only read documents. They sample a requirement, follow it down to the code and its tests, and check that every link, result and review record exists and is consistent. Weak trace data is one of the most common reasons for findings.

What happens at SOI#1 to SOI#4?

The certification authority, or its delegate, reviews the project at four Stages of Involvement. FAA Order 8110.49A describes how these reviews are performed.

The cheapest moment to fix a requirement problem is before SOI#2. A missing or ambiguous requirement found at SOI#3 means new tests, new reviews and often new code.

How does testing work under DO-178C?

DO-178C only gives credit for requirements-based tests. Every test case traces to a high-level or low-level requirement. Structural coverage is not the goal; it measures whether the requirements-based tests were thorough and helps reveal code that no requirement asked for.

Normal range and robustness tests

• Normal range tests (§6.4.2.1) show the software responds correctly to valid inputs: equivalence classes, boundary values, valid state transitions, time-related functions.
• Robustness tests (§6.4.2.2) show it behaves correctly with abnormal inputs and conditions: out-of-range values, invalid states, failure modes, arithmetic overflow, timeouts. The expected behaviour must be written in the requirements.

Where tests run

Credit can be given for tests on a target emulator or a host simulator, if the environment is shown to be representative. Hardware/software integration tests that show compatibility with the target computer must run on the real target.

When coverage is below 100%

Each piece of uncovered code needs an analysis with one of four outcomes: a test is missing, a requirement is missing, the code is dead code (remove it), or it is deactivated code (justify it and show it cannot run). In practice the first two are the most frequent, and both start in the requirements.

Field note from our benchmark

In KomAInu's blind benchmark of AI-generated tests on synthetic DAL C-style requirements, most wrong tests came from two places: power-up and initialisation behaviour, and timer edges (for example, when a condition held "for more than 250 ms" with a 20 ms cycle, a naive reading fired at 280 ms instead of 260 ms). Both are robustness cases that a reviewer must check line by line.

To find these gaps before the audit, KomAInu runs a test coverage gap analysis from your requirements and existing tests, and generates the missing test cases from requirements for engineer review.

What DAL C does not require (and what it still does)

Most equipment suppliers work at DAL C or D, where the cost differences with DAL A and B are large. The table below sums up the verification differences that matter for planning.

At DAL C, developers may write their own low-level tests, which lowers cost a lot. Robustness testing, statement coverage, coupling analysis and full traceability still apply, so requirement quality stays the main driver of effort.

Bidirectional traceability and trace data

DO-178C created a separate life cycle data item, Trace Data (§11.21). It must show links in both directions: from each system requirement down to HLR, LLR, code and tests, and from each test and line of code back up to a requirement. Downward links prove that every requirement is implemented and verified. Upward links prove that nothing was added that no requirement asked for.

Keeping these links correct after every change is the slow, error-prone part. A requirements traceability matrix built and checked automatically, then reviewed by an engineer, keeps the evidence ready for SOI#2 and SOI#3.

Tool qualification (DO-330) and TQL levels

A tool must be qualified only when it eliminates, reduces or automates a DO-178C process and its output is not verified. The required Tool Qualification Level (TQL) depends on the software level and on what the tool could do wrong.

• A tool is qualified within a project, not in general. A vendor can only sell a "qualifiable" tool and a qualification kit.
• A TQL-5 kit typically contains the Tool Operational Requirements (TOR), a qualification plan, verification cases and procedures with expected results, and a Tool Accomplishment Summary.
• A generic safety certificate (for example from TÜV) does not replace DO-330 qualification.
• If the tool output is fully reviewed, the tool usually does not need qualification. Declare the approach in the PSAC early.

Can you use AI on a DO-178C project?

Yes, as an assistant whose output is verified. In a September 2026 paper to ICAO, EASA wrote that tools whose outputs are fully and independently verified may not need qualification; otherwise, qualification proportionate to the risk applies (EASA, DGCA61/DP/03/06, §1.3). EASA's AI Days 2026 material also shows that its next rule-making step, with consultation planned for Q2 2027, accepts two ways to verify AI outputs: systematic checks by staff, or automated checks by non-AI software.

ED-324 / ARP6983, the new standard for machine learning in airborne systems, reached consensus on 24 August 2026. It targets embedded ML, not verification tools.

This points to a clear architecture: the language model proposes, deterministic engines compute and check, and the engineer decides. It also means the model's numbers and units should come from code, not from text generation, and that the tool should run on a frozen, on-premise stack so results can be replayed.

Limits: synthetic requirements written by a separate agent, one run per system, blind LLM judges with about ±3 points of noise. The lesson still holds: asking the engineer targeted questions on ambiguous requirements removed every wrong test in this run, which no prompt alone achieved.

KomAInu follows this approach: it challenges each requirement, asks the engineer the questions that settle it, and writes deterministic test cases for review. It can run on-premise or air-gapped, and our engineers can run the work with your team through V&V as a Service.

Where to get the DO-178C PDF (and free resources)

The DO-178C text is copyrighted and sold by RTCA (DO-178C) and EUROCAE (ED-12C). Free copies found online are usually unofficial or outdated. Several official documents are free and useful while you wait for your copy:

• FAA AC 20-115D: how the FAA recognises DO-178C and its supplements.
• EASA AMC 20-115D: the harmonised European equivalent.
• FAA Order 8110.49A: how FAA staff conduct software reviews and SOIs.
• FAA DO-178B/C Differences Tool: what changed between DO-178B and DO-178C, section by section.
• AdaCore's booklet "Technologies for Airborne Software" (CC BY-SA): an objective-by-objective reading of the A-6 and A-7 tables.