If you are planning a DO-178C program, one question quickly becomes expensive: which software level applies? It is tempting to answer from the code—how large, complicated, or new it looks. Certification starts somewhere else.
The system safety process sets the minimum software level from the severity of the failure conditions the software can cause or contribute to. More severe potential aircraft effects require more development assurance. Code size, architecture, budget, and schedule affect the work, but none of them decides the level on its own.
By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed August 2026.
What “DAL” means on a software project
Most teams call it the Design Assurance Level, or DAL. That is useful shorthand, but it can hide three different decisions.
At the system level, SAE ARP4754A uses a Functional Development Assurance Level, shortened to FDAL, and an Item Development Assurance Level, or IDAL. DO-178C, Software Considerations in Airborne Systems and Equipment Certification, uses the term software level.
The levels are related, but they are not interchangeable. The system safety and development-assurance work determines how aircraft and system functions are allocated to items. Your software plans then identify the software level that applies to each software component and show how it follows from those system-level decisions.
This distinction is more than vocabulary. If a plan says only “DAL C,” a reviewer still needs to know whether that label applies to a function, an item, or the software itself—and where the assignment came from.
Federal Aviation Administration (FAA) Advisory Circular (AC) 20-115D recognizes DO-178C as an acceptable means of showing that airborne software satisfies applicable airworthiness requirements. The circular says the system safety process assigns the minimum development-assurance level from the severity of the associated failure conditions. The applicant then satisfies the DO-178C objectives associated with that level and produces the applicable software life-cycle data.
The practical rule: name the level precisely, identify the safety assessment that supports it, and keep that connection visible in the software plans.
The decision starts with what can go wrong
The safety process begins with the aircraft or system function. What must it do? How could it fail? What would happen to the aircraft, occupants, or crew if that failure occurred?
Those failure conditions are classified by severity. The software level follows the most severe failure condition to which the software can contribute:
| Software level | Associated failure-condition severity |
|---|---|
| Level A | Catastrophic |
| Level B | Hazardous or Severe-Major |
| Level C | Major |
| Level D | Minor |
| Level E | No effect on safety |
These letters do not measure how likely a programmer is to make a mistake. They measure the potential consequence if the software behaves incorrectly in the installed system.
Consider one example: a short routine provides the sole command that deploys a safety-critical aircraft function. Its small size does not make the required assurance small. If incorrect output can contribute to a severe failure condition and no valid architectural mitigation changes that effect, the level follows the failure condition—not the number of lines of code.
Architecture can change the answer, but only through a supported safety argument. Partitioning, monitoring, redundancy, independence, and other design features may change how a failure propagates or which item can contribute to it. Your software team cannot claim a lower level simply because one of those features appears on an architecture diagram. The feature, its assumptions, and its limitations must be established in the system safety process.
The same rule applies to reused software. A component does not carry one universal level into every aircraft installation. Its existing evidence may be useful, but AC 20-115D says software used in a new installation must satisfy the level assigned for that proposed installation.
The correct target is not the highest level your team can afford or the lowest level it can argue for. It is the level the installed system’s safety analysis supports.
What the software level changes
A higher level does not mean the software performs a more complicated function. It means the program needs stronger assurance that errors have been prevented, detected, and addressed in proportion to the possible safety effect.
The assigned level determines which DO-178C objectives apply. It also affects where independence is expected and which life-cycle data must support the compliance showing. The impact reaches planning, requirements, design, coding, integration, verification, configuration management, quality assurance, and certification liaison—not just final testing.
That is why the software level is a major cost and schedule driver. Assuming a higher level than the safety assessment supports creates unnecessary work. Assuming a lower level can leave the team with plans, reviews, tests, tools, and records that are insufficient for the assigned failure effects.
AeroCert’s article What does DO-178C certification cost a small company? explains how software level fits with verification, tool qualification, planning, and other cost drivers. The important connection is that the cost follows the justified assurance work; the budget does not set the level.
The level also influences—but does not completely determine—the FAA’s review involvement. FAA Order 8110.49A says the review scope depends partly on software level and also on factors that include complexity, novelty, design, and project circumstances. A Level A project does not receive its exact review plan from the letter alone, and a lower-level project is not automatically simple.
Get the level right early enough that your team can plan the right objectives, independence, data, tools, and reviews from the beginning.
How to establish the level before your plans harden
Start above the software. Identify the aircraft and system functions your software implements, monitors, protects, or influences. Then connect those functions to the failure conditions, classifications, and architectural assumptions in the safety assessment.
Before treating the level as settled, make sure your team can answer these questions:
- Which aircraft or system functions depend on this software?
- What failure conditions can result from lost, incorrect, untimely, or misleading behavior?
- How were those failure conditions classified?
- Which mitigations are credited, who controls them, and how is their independence supported?
- Can the software contribute to more than one failure condition?
- Which failure condition drives the minimum software level?
- Does a supplier’s proposed level agree with the installation-level safety assessment?
- Where is the rationale recorded, and how does it trace into the software plans?
For projects using SAE ARP4754A, FAA AC 20-174 recommends documenting proposed FDALs, IDALs, their justifications, and associated objectives in the certification plan and coordinating them early with the certification authority. The software level and its basis should also be visible in the Plan for Software Aspects of Certification, commonly called the PSAC, and remain consistent with the system safety data.
Early coordination matters when the assignment depends on novel functions, complex integration, reused software, unusual architecture, or assumptions controlled by another organization. The authority or an authorized representative does not perform the applicant’s safety analysis, but early review can expose a disagreement before the software process is built around the wrong level.
Keep the assignment under change control. If the function, installation, interface, architecture, mitigation, or safety classification changes, revisit the software level and the affected plans and life-cycle data.
Finally, make the decision easy to audit. A reviewer should be able to move from the software component to its functions, from those functions to the relevant failure conditions, and from the severity classifications to the assigned level without relying on undocumented team knowledge. AeroCert’s guide to what the FAA examines during Stage of Involvement reviews shows how that evidence is examined as the program matures.
Your software level is a result of the installed system’s safety analysis: establish it from credible failure effects, document the assumptions behind it, and let the level drive the assurance plan—not the other way around.
As a next step, use AeroCert’s free public-tier checklist library to review the planning, requirements, development, verification, configuration-management, tool-qualification, and certification evidence affected by the assigned level. It includes seven plain-language DO-178B/C checklists with 88 checkpoints, free to use and share.
Primary sources
- FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), especially paragraphs 4.1, 7.1, and 8.4.2.
- FAA AC 25.1309-1B, System Design and Analysis, for transport-category airplane guidance on failure-condition classification and development assurance.
- FAA AC 20-174, Development of Civil Aircraft and Systems, especially paragraph 7 on early coordination and documenting proposed FDALs, IDALs, and their justifications.
- FAA Order 8110.49A, Software Approval Guidelines, for factors used to determine FAA software-review involvement.
- RTCA DO-178C, the software-development-assurance standard recognized by AC 20-115D. Section 2.3 and Annex A contain the detailed software-level framework and objectives; no proprietary standard text is reproduced here.
This article is educational guidance. It does not replace the applicable certification basis, project-specific safety assessment, FAA coordination, a qualified authorized representative, or an FAA finding of compliance.