12.1 Aviation Software Classification and RTCA DO-178C / EUROCAE ED-12C
Key Takeaways
- RTCA DO-178C and EUROCAE ED-12C implement airborne software levels A–E, taught in industry as DAL A–E, from catastrophic failure conditions down to no safety effect.
- Appendix I topic 5.13 is not required for Category A, sits at Level 1 for B3, and at Level 2 for B1 and B2/B2L.
- A DAL letter belongs only to the released software part number that completed the planned development, verification, configuration and quality-assurance objectives.
- An unapproved field change creates a different programme that has not been shown to meet those objectives, so the original DAL no longer applies.
- Airborne software is part of the Part-21 type design; an unofficial programme is an unapproved configuration and the aeroplane is not in a condition for safe operation until the authorised part is restored.
12.1 Aviation Software Classification and RTCA DO-178C / EUROCAE ED-12C
Appendix I topic 5.13 Software management control sits at Level 2 for Categories B1 and B2/B2L, Level 1 for Category B3, and is not required for Category A. Level 2 means general knowledge of theoretical and practical aspects and the ability to apply that knowledge. The current Appendix I gives only the 5.13 heading and category levels. The pre-12 June 2024 detailed description added restrictions, airworthiness requirements, and the possible catastrophic effects of unapproved changes to software programmes; this remains useful historical study scope, not current quoted regulatory text. The industry framework that makes those restrictions intelligible is the Design (Development) Assurance Level scale DAL A–E, implemented for airborne software by RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, and its European counterpart EUROCAE ED-12C.
This chapter is independent OpenExamPrep study material. It is not an EASA, RTCA, EUROCAE or type-certificate-holder document, and it must not be read as an official means of compliance.
Software as part of the approved type design
A modern transport aeroplane implements flight-control laws, engine control schedules, navigation and terrain databases, traffic-alert logic and display formats as software programmes hosted in line-replaceable units (LRUs) or in partitioned Integrated Modular Avionics (IMA). Those programmes are part of the type design approved under Regulation (EU) No 748/2012 (Part-21). Continuing airworthiness under Regulation (EU) No 1321/2014 requires the aircraft to be maintained in accordance with approved data so that it remains in the approved configuration. If the resident software is not the authorised part, the aircraft is not in its approved type design and is not in a condition for safe operation until the configuration is restored.
Certification specifications such as CS-25.1301 and CS-25.1309 (with equivalent rules in CS-23, CS-27 and CS-29) require that equipment perform its intended function and that failure conditions classified as catastrophic be extremely improbable. Software that can cause or contribute to those failure conditions must be developed and verified to a matching assurance level. Design organisations use DO-178C/ED-12C as the usual method; EASA AMC 20-115 series material recognises that ED-12/DO-178 approach. Certifying maintenance staff do not run the DO-178C process in the hangar. They preserve the software artefact that already satisfied it.
DAL A–E: the industry airworthiness classification framework
A system safety assessment (often using SAE ARP4754A / EUROCAE ED-79A at aircraft and system level) assigns each failure condition a severity. That severity allocates a software level. DO-178C names Software Levels A through E; industry teaching commonly calls the same scale DAL A–E. The letter is not a workshop quality grade. It is a statement of how many process objectives were completed for that exact released version.
| DAL / software level | Failure-condition class | Meaning of the class (system safety language) | Illustrative airborne software (not a mandatory mapping) | Relative assurance |
|---|---|---|---|---|
| A | Catastrophic | Failure conditions that would normally prevent continued safe flight and landing; typically multiple fatalities and loss of the aeroplane | Primary fly-by-wire control laws; many FADEC paths that could cause uncommanded thrust or engine behaviour affecting the flight path | Highest: independent verification; structural coverage including modified condition/decision coverage (MC/DC) as specified for Level A |
| B | Hazardous (severe-major) | Large reduction in safety margins; physical distress or a higher workload such that the crew cannot be relied upon to perform tasks accurately; serious or fatal injury to a small number of occupants | Selected autopilot, guidance or high-criticality display functions | High, with independence on designated objectives |
| C | Major | Significant reduction in safety margins or functional capabilities; significant increase in crew workload; physical distress to occupants, possibly including injuries | Many communication, surveillance and display applications | Moderate requirements-based verification |
| D | Minor | Slight reduction in safety margins; slight increase in workload; physical discomfort | Some information-system and secondary functions | Limited objectives |
| E | No safety effect | No effect on aircraft operational capability or crew workload | Many in-flight entertainment functions | No DO-178C software objectives for that software |
Two hangar mistakes follow from misunderstanding this table. First, treating Level E entertainment-loading habits as acceptable for Level A or B avionics. Second, believing that a green BITE after an unofficial edit still means “it is Level A”. The DAL applies only to the released part number that completed the objectives. An unapproved change produces a different programme that has completed none of those objectives.
What the DAL process actually contains
DO-178C/ED-12C is process assurance. For high software levels the planning, development and integral processes typically include:
- Software requirements that are complete, consistent, accurate and traceable to system requirements.
- Design and source code that implement those requirements without unintended function.
- Verification — reviews, analyses and tests — with independence from the authors where the level demands it.
- Configuration management that uniquely identifies source, executable, tools, media and the released software part.
- Software quality assurance that the planned activities were performed.
- Certification liaison so that the compliance evidence matches the certification basis.
Related industry documents used by design organisations (not by line maintenance as a task card) include tool qualification DO-330 / ED-215, model-based development DO-331, object-oriented technology DO-332 and formal methods DO-333. They explain why a one-line parameter patch on a hangar laptop is not equivalent to the certified baseline: tools, compilers, build options and test coverage are part of the argument.
Worked hangar example: a “trivial” edit
A technician is asked to change a single conversion constant in a primary flight-control computer because a printed list of parameter names is available from another operator. The item is DAL A. Even a one-constant edit can alter timing, stack usage, monitor-channel comparison or scheduling. The DAL A safety argument never examined that field-edited image. The correct action is to refuse the unofficial change, restore the authorised software part if the image has already been disturbed, and report the occurrence through the organisation’s occurrence-reporting scheme.
IMA partitioning does not relax the rule
IMA cabinets may host applications at different software levels under time and space partitioning (industry material such as DO-297 / ED-124 and ARINC 653-style partitioning). Partitioning is part of the certified design. Loading an unapproved hosted application, or defeating a partition monitor, can allow lower-criticality software to interfere with a Level A function. Load only the authorised hosted software parts for that cabinet and aircraft effectivity.
[!WARNING] Unauthorised change defeats the DAL process. The letter A–E on a drawing, service bulletin or software status page belongs to a specific software part number. If a technician edits parameters, copies an unofficial image, mixes databases or loads a part that is not effectivity-approved, the resident programme is not the artefact that satisfied Levels A–D. The aircraft is then outside the approved type design, regardless of a successful power-up.
Maintenance restrictions taught under topic 5.13
- Do not modify airborne software except by approved design change, service bulletin, airworthiness directive or other approved data.
- Do not substitute a look-alike file because the media fits or the filename is similar.
- Do not apply passenger-entertainment (often Level E) habits to flight-control, engine-control or navigation software.
- Do not treat a loader progress bar as the airworthiness decision; identity and integrity still have to match the approved configuration.
B1/B2 Level 2 means you can explain DAL A–E and apply the restriction: unapproved change defeats the process. B3 Level 1 means you recognise that software classification exists and that unofficial changes are an airworthiness event. Later sections cover part numbering and data-loading integrity; classification is the reason those controls exist.
Under RTCA DO-178C / EUROCAE ED-12C, which software level is associated with a catastrophic failure condition?
Why does an unapproved field change to airborne software defeat the DAL process even if the technician believes the edit is trivial?
What are the Appendix I knowledge levels for topic 5.13 Software management control?
EUROCAE ED-12C is best described as which of the following?