The design assurance level of an AI model is set by what its failure could do to the aircraft, not by the fact that it learned its behaviour from data. For helicopter rotor and drive-system vibration health monitoring, UK CAA CAP 753 places monitoring for maintenance personnel only at DO-178B Level D or higher. Ground processing may fall under DO-278 instead, and a function with no safety effect sits at Level E, which carries no DO-178C objectives. The programme’s system safety assessment decides which of these applies, agreed with the certification authority early enough to shape the evidence plan.
TechnoLynx supports this tiering step through the AI Readiness Scorecard: it documents the model’s role, inputs, outputs and failure modes in a form the safety assessment can use, frames the ML evidence to match whatever level is assigned, and structures validation so it can scale up if the level rises. The engagement starts with model identification, which means writing down what the model does and who acts on its output.
How design assurance levels are assigned to software
DO-178C defines five software levels, A to E, which correspond to failure condition categories running from catastrophic to no safety effect, and the applicable objectives and independence requirements change with the level. A level is assigned to a software item by the system safety assessment process, based on the potential consequences of its failure or malfunction. Flight control computer software, for example, is typically classified as Level A because its failure could be catastrophic. The assigned level also depends on the type of aircraft, and the familiar table is the one for Part 25 (large) aircraft.
DO-178C levels at a glance
| Level | Failure condition | Objectives | Of which verification | Structural coverage |
|---|---|---|---|---|
| A | Catastrophic | 71 | 43 | MC/DC |
| B | Hazardous / severe | 69 | 41 | Decision coverage |
| C | Major | 62 | 34 | Statement coverage |
| D | Minor | 26 | 9 | No structural coverage analysis (reviews and testing) |
| E | No safety effect | 0 | 0 | None |
Objective counts per level are from DO-178C as summarised in two published studies. Coverage requirements by level are as the 2025 study of a Scrum-based framework under DO-178C describes them. Severity categories follow the DO-178B definitions reproduced in an FAA research report.
The step that matters most for a maintenance model is the one between C and D: 36 fewer objectives (62 minus 26), and verification objectives falling from 34 to 9. Level D verification is limited to basic reviews and testing, with no structural coverage analysis. The tier therefore deserves an argument rather than an assumption.
Does using ML change the design assurance level of an AI model?
Using ML does not by itself set the level a function needs. The FAA’s Roadmap for Artificial Intelligence Safety Assurance (Version I) says industry standards determine the safety criticality of a subsystem or algorithm and designate a design assurance level from that, within performance-based regulations that require a system to perform its intended function without introducing an unacceptable hazard. Under ARP4754A, the functional development assurance level is assigned from the functional hazard assessment classification, and the item level follows the hazard the item supports.
A published case study shows this with a single network. The same deep neural network component could be categorised as DAL D, C or B depending on the use case. Where its safety impact is minor, DAL D can be justified; one variant could be classified as DAL C; and a version controlling the aircraft would be highly safety critical, at DAL B or A depending on aircraft category.
ML does change which levels a regulator will currently accept. EASA’s AI Concept Paper Issue 02 says the agency will initially accept only applications where AI/ML constituents contain no IDAL A or B items (nor SWAL 1 or 2, nor AL 1, 2 or 3). The paper also says it will initially accept only applications where AI/ML constituents include IDAL D, SWAL 4 or AL 5 items. It also says no assurance level reduction should be performed for items within AI/ML constituents. The function’s hazard sets the level it needs. Under EASA’s paper, ML caps what is approvable today and rules out assurance level reduction within AI/ML constituents.
What level does a turbine-vibration anomaly model feeding maintenance decisions need?
The UK CAA’s CAP 753 covers vibration health monitoring (VHM) of helicopter rotors and rotor drive systems. For VHM applications providing monitoring for maintenance personnel only, whose failure could result in a major or hazardous event, CAP 753 sets the software level at DO-178B Level D or higher. Functions whose failure could be catastrophic are outside its scope. Applications that also seek maintenance credit may need a higher integrity level.
FAA approvals of rotorcraft HUMS add a relevant condition. Rotorcraft HUMS applications approved to date have been approved on a no-maintenance-credit basis, meaning maintenance actions are not predicated on the data those applications collect and process. In our judgement, that condition is the clause a maintenance-advisory model’s tiering argument most depends on.
Three details in CAP 753 shape the answer for an anomaly model. Performance criteria apply to the end-to-end process, from sensor to alert to instructions for continued airworthiness. The software level should result from that end-to-end criticality assessment and is in general the same as the airborne software. Alerts can be set either as advisory information for preliminary investigation or as a flight-limiting alert requiring maintenance before further flight, the latter expected only where type certificate holder vibration limits already exist.
EASA’s scope line is useful as a test. Its ML guidance covers maintenance systems that support scheduling and performance of tasks intended to detect or prevent unsafe conditions (ALS inspections, CMRs, safety category tasks), or tasks that could create unsafe conditions if performed improperly.
Decision table: what the model’s role points to
| Role of the model’s output | What the guidance points to |
|---|---|
| Monitoring for maintenance staff only, not changing maintenance practices or flight operations | DO-178B Level D or higher for maintenance-only VHM |
| Output used to replace or reschedule a maintenance task (maintenance credit) | May need higher integrity than maintenance-only monitoring |
| Output supports ALS inspections, CMRs, safety category or critical maintenance tasks | Inside EASA’s ML guidance scope for maintenance |
| Ground software that determines component life | DO-178B or an acceptable alternative, at the FHA-derived level |
| Alerts streamed to crew in flight | Not supported at current VHM integrity |
| No safety effect | Level E, no DO-178C objectives |
The decision logic underneath is simple to state. If the model’s output can directly or indirectly trigger an unsafe maintenance action without human review, tier it higher and plan for a full DO-178C evidence set. If the output is advisory and always passes through a maintenance engineer’s review, a lower path may be justified, but the programme’s certification owner makes that call.
This guidance concerns aircraft; for turbines in power generation, see our page on AI engineering for energy and utilities.
Ground-side analytics: DO-178C, DO-278 or ARP4754A?
These documents address different layers: airborne software, ground software and system development. DO-178B (now DO-178C) gives guidance for software in airborne systems, while DO-278 gives guidance for flight-related software in ground-based systems. For rotorcraft health monitoring, the HUMS advisory circulars (AC 27-1B and AC 29-2C) add guidance on installation, credit validation and continued airworthiness. HUMS installation covers the whole end-to-end application, airborne and ground equipment alike.
An FAA research report on ground-based COTS components says a HUMS must determine its end-to-end criticality by performing a functional hazard assessment that includes ground components, such as operating systems, databases and communications drivers. Any COTS component that determines component lifetime must come under DO-178B or an acceptable alternative, and mitigating actions can reduce the final qualification level. The same report notes that, as the publication of DO-278 showed, not all ground-based systems align well with the assurance level objectives. The FAA’s AC 20-115D now recognises DO-178C and its DO-330 to DO-333 supplements.
ARP4754A works at system level. Its purpose is to guide the generation of evidence that errors in system requirements, design and implementation have been found and corrected. EASA and the FAA recognise it as an acceptable means of compliance (for example through AC 20-174). In ARP4754B the principles of DAL assignment remain, while the procedural specifics moved to ARP4761A. The system-level process (ARP4754A/B with ARP4761A) allocates the level, and DO-178C or DO-278 governs the software built to it.
Can a purely advisory maintenance model end up with no formal DAL?
Possibly, but regulatory guidance on certifiable condition-based maintenance is sparse, so treat it as an argument you have to win rather than a default. DO-178C already has a slot for it: Level E, no safety effect, with zero objectives. EASA’s ML guidance applies to airworthiness systems whose improper functioning would reduce safety, and to maintenance systems tied to unsafe-condition or critical tasks; a tool that does neither is, on our reading, outside that guidance rather than at a low level within it. A 2025 review by Meissner et al. in Progress in Aerospace Sciences found regulatory guidance for certifiable condition-based maintenance sparse, with current use cases limited to non-critical tasks or avoiding unscheduled breakdowns.
Be careful with helicopter VHM specifically. CAP 753 sets Level D or higher for maintenance-only VHM software whose failure could result in a major or hazardous event.
What to document to justify a low or no assigned level
- A concept of operations stating the task split between maintenance engineers and the model, with operational limitations captured (EASA objective CO-04).
- A functional analysis and allocation that marks which items carry AI functions (EASA objective CO-06).
- A declaration of intended capability: what is monitored, which failures, and the end-to-end performance expected.
- An end-to-end functional hazard assessment that includes ground hardware and software.
- An explicit statement that maintenance actions are not predicated on the model’s output, mirroring the no-maintenance-credit basis.
- Metrics, thresholds and evaluation periods showing the design assumptions still hold in service (EASA objective SA-03).
The record should also say what would reopen it. One Level D certification proposal lists performance degradation, dataset shift, changed operating conditions and changed uncertainty handling as reasons to recertify. We would add tighter integration with flight operations to that list, since an alert wired into dispatch decisions is no longer purely advisory.
Who owns the assurance-level decision, and how early?
TechnoLynx prepares the model documentation your system safety assessment works from, but that assessment assigns the level, and the result must adhere to the levels the certifying authority sets. ARP4754A states which objectives follow from each assignment but does not justify them, and applying it takes significant engineering judgement.
With AI, the FAA expects early engagement. The FAA’s roadmap plans a policy statement asking applicants to disclose AI use and discuss a certification path early in development, and says the FAA will be directly involved because such projects are novel. It also encourages companies to engage the FAA early to build common methods of compliance. The vehicle is the Plan for Software Aspects of Certification (PSAC), which records agreements with the authority and checks the proposed lifecycle against the rigour the level demands. For VHM, CAP 753 expects the in-service activity to be set out in a plan agreed before initial approval.
Misjudging the tier low leaves a large evidence gap. Moving from Level D to Level C adds structural coverage and 25 further verification objectives (34 minus 9). We would rather plan validation so it can scale to the next level from day one than gamble on the lower one. Turning the agreed level into a validation depth is the next step, covered in scoping validation depth from risk tiering to evidence packs.
DO-178C in a nutshell, mapped onto an ML model
DO-178C, developed by RTCA and EUROCAE, is a process-oriented assurance framework defining objectives, activities and lifecycle data, with rigour set by the software level. It specifies what must be achieved, not how. It also does not describe the certification process itself, which comes from the authorities’ regulations and guidance.
| Area | How it reads for an ML model (Level D workflow) |
|---|---|
| Requirements | The trained model is positioned as low-level software requirements, following DO-331’s model-based example |
| Traceability | Tracing weights to functions is not achievable, but low-level requirement objectives do not apply at Level D |
| Verification | Model testing can serve as the means of compliance for most low-level verification objectives |
| Structural coverage | Achievable but not representative, since one random input can reach full code coverage |
| Configuration management | Technology-agnostic, so it applies to training data with traditional methods |
Under that workflow, a 2022 arXiv analysis concludes that neither traceability nor ML verification issues prevent Level D objectives being met, and the NASA-hosted case study reached the same conclusion for its network. Above Level D, that study lists alternative mitigations needed for ML’s incompatibilities. The FAA roadmap is blunter, saying existing software guidance is not adequate for learned AI and new assurance methods are needed. EASA’s answer is “learning assurance”, extending development assurance to the data-driven learning process, with a complete operational design domain definition as a prerequisite for data set quality. The FAA also distinguishes learned (static) models from learning (dynamic) ones; a frozen anomaly model is the easier of the two to argue.
What TechnoLynx does and does not do
TechnoLynx prepares the engineering side of a maintenance-advisory model’s tiering: a written account of what the model does, what it consumes and emits and how it can fail, with ML evidence framed to the assigned level. We treat that tiering record as an engineering output in its own right, because it is the artefact a safety reviewer or approver will read and sign against.
The scope has hard edges. We do not assign the DAL, sign off a certification basis or act for the authority; that stays with your certification function and its designees. Where you need someone authorised to approve compliance findings, a certification consultancy or designated engineering representative is the right route, not an AI engineering team.
FAQ
What is the difference between DO-178B and DO-178C?
DO-178C supersedes DO-178B, improving and clarifying its guidance and adding supplements for tool qualification, model-based development, object-oriented technology and formal methods (DO-330 to DO-333). The FAA’s AC 20-115D recognises DO-178C and those supplements as an acceptable means of compliance.
