What is Development Assurance Level (DAL) in Aerospace?

Development Assurance Level (DAL) is an important aspect in ensuring aerospace system safety. DALs directly influence the scope of validation and verification activities to provide evidence for implementation of required objectives, as per APR4754B and ARP4761A. Despite the significance of DAL, accessible, easy-to-follow and practical guidance on DAL (especially around its assignment and decomposition) remains limited leading to ambiguous and inaccurate DAL assignment.

In all safety-critical systems across industries, their respective standards utilize some sort of equivalence to Development Assurance. For electrical, electronic and programmable electronics across industries, Safety Integrity Level (SIL) is defined in IEC 61508 as a measure of performance of a safety system. A similar concept is outlined in ISO 26262, defining Automotive Safety Integrity Level (ASIL).

This blog series aims to demystify DAL through a step-by-step approach, starting with this post, which introduces the purpose and role of DAL and outlines a general process for assigning DALs. Future posts will provide an overview of the decomposition process with relevant examples, and how DAL compares to SIL (and ASIL).

Why DAL was introduced?

As aerospace systems have grown more complex, the potential for both systematic and random failures leading to hazardous events has increased. To address these risks, the concept of Development Assurance Level (DAL) was introduced in the early 1990s, along with the growing reliance on software and complex electronic hardware in airborne systems. DAL was first referred in DO-178 to specifically address the development assurance requirements associated with software development and implementation of such software in the aircrafts.

This marked a major shift in the aerospace industry, moving away from a traditional prescriptive approach towards a more flexible, objective-driven methodology.

Hence, DALs were established to allow software engineers to follow different development paths while ensuring compliance with rigorous airworthiness standards and requirements. At the equipment level, DAL-driven assurance activities are guided by system design features such as redundancies, monitoring mechanisms, and functional partitioning. More on decomposition will be discussed in the next post, stay tuned for regular updates.

To keep pace with industry advancements, aerospace standards were eventually updated to recognize DAL as a critical component of development assurance, ensuring safety is inherently implemented in all modern airborne systems.

What is Development Assurance Level (DAL)?

Development Assurance, as per ARP4761A, is all the planned and systematic actions used to substantiate, at an adequate level of confidence, that development errors have been identified and corrected such that the system satisfies the applicable certification basis. The rigor of this assurance and evaluation is determined by allocating ‘Development Assurance Level’ (DAL).

To identify the required DAL, a top-down approach outlined in ARP4761A is followed from the

aircraft and system functions to the item (H/W and S/W) level. The highest DAL is assigned to

the top-level failure condition assessed as ‘Catastrophic’ following a gradual scale with reducing severity levels as described below.

Function Failure Severity	DAL	Impact	Examples
Catastrophic	A	Loss of aircraft, multiple fatalities possible	Primary flight and propulsion control systems
Hazardous	B	Serious or fatal injuries, significant increase in crew workload	Thrust Management, Flight Director guidance
Major	C	Crew discomfort, potential injury to passengers increased crew workload	Stability Control mechanisms and actuators
Minor	D	Minor injuries or inconvenience, manageable by the crew	Cabin state monitors, backup instruments and displays
No Safety Effect	E	No impact on safety or continued safe flight of the aircraft	Passenger entertainment means, reading lights

Note: The examples provided refer to generic aerospace systems and may not necessarily highlight the actual DAL assignment. Compliance will vary depending on the specific aircraft development activities.

Development assurance is fundamentally about instilling confidence in the behavior and properties of a system or item. It is achieved by establishing and meeting specified objectives, and applying configuration control to the development lifecycle artefacts for the assigned DAL.

These objectives offer a consistent, measurable framework for evaluating different forms of evidence and safety artefacts, both qualitative and quantitative. As part of the overall safety process, Functional DALs (FDALs) and Item DALs (IDALs) are assigned to define the necessary rigor of development assurance activities. These levels are then used to demonstrate that any potential development errors that could contribute to failure conditions have been adequately identified and mitigated.

By adopting an objective-based approach, the guidelines and standards allow developers the flexibility to select methods and techniques that best align with their system requirements and goals, as long as the resulting evidence convincingly and adequately meets the assurance objectives.

How is DAL assigned?

As discussed, DAL is assigned by following a top-down approach, this begins at the aircraft functional level and decomposes to the item level. The DAL assignment process is carried out in two distinct phases: Functional Development Assurance Level (FDAL) and Item Development Assurance Level (IDAL) assignment.

• FDAL: It is assigned based only on the function and the associated failure condition severity. Following the initial aircraft level assignment, the functions are evaluated for independence in their Functional Failure Sets (FFS) for potential FDAL assignments based on the architectural considerations. The worst severity of the functional failure from the FFS drives the FDAL associated with that function.

  
  

• IDAL: The IDAL assignment follows the FDAL assignment process. The lower-level item designs that implement the functions are evaluated for independence before assigning IDALs. If independence cannot be confirmed, then this lack of independence should be fed back to the FDAL and/or IDAL assignment process. The objectives for IDALs are outlined in RTCA DO-178C (for software) and RTCA DO-254 (for Airborne Electronic Hardware).

FDAL/IDAL assignment process based on ARP4761A

Application of the process to the V-model (Aircraft Safety Lifecycle)

How this DAL assignment process is linked to the safety development lifecycle (V-model) is often faced with ambiguity. This is a nuanced process that can be prone to mistakes if not done with due diligence.

Drawn from years of experience in the aerospace system safety field working with suppliers, OEMs and vertically integrated organizations, the following are the steps that can be performed to apply this concept to the safety lifecycle for efficient:

Phase	Description	Safety Development Phase	Safety Artefacts
Planning	To drive the development through all levels. The means must be outlined in which the objectives can be met for specific product development.	Concept Development	Development Assurance Plan Safety Program Plan
Requirement Allocation	Refinement, allocation and decomposition of requirements from the Aircraft to the item level. FDAL allocation, from aircraft functions down to system level functions based on functional failure severities. IDAL allocation at the lowest level of the V-model to meet higher level objectives	Preliminary and Detailed Design PDR and CDR	Aircraft FHA System FHA PASA PSSA
Validation	The iterative process of baselining requirements to ensure their correctness, completeness, and consistency with higher-level requirements on the left side of the V-model. It also reviews that appropriate and accurate DALs have been assigned to all system and item-level work products.	Preliminary and Detailed Design PDR and CDR	Aircraft FHA System FHA PASA PSSA
FDAL/IDAL Verification	To ensure all requirements and objectives have been successfully implemented and satisfied all the way to the aircraft level on the right side of the V-model.	Integration and Testing	SSA ASA
Implementation of Supporting Processes and Assessments	Configuration Management of H/W, S/W and all supporting data, Process Assurance, that is all quality assurance and quality control processes, Safety Assessment Process, which drives the DAL allocation and the required derived system behaviors, Regulatory Certification Liaising	Overall Development Lifecycle	All principal safety assessment documents

Challenges in the application of DAL

Development Assurance of critical systems is an onerous undertaking and is therefore often faced by apprehension by developers who do not fully understand the underlying arguments behind the objective-based development outlined in the safety standards.

• Engineers who are not familiar with DAL objectives find the processes and definitions unclear. Standards that are supposed to serve as guidance material often lack detailed and specific guidance which gives rise to errors in working with DAL objectives.

• As aircrafts, systems and items have become increasingly complex, there can be variations in how OEMs and suppliers interpret the application of DAL. This requires thorough understanding and subject-matter experts which are a limited resource in a highly competitive environment.

  
  

• DAL objectives do not directly translate to failure rates, or probabilities. Hence, DAL achievement does not imply fulfilling failure rate probability budget allocations. This leads to confusion and additional resource allocation towards achieving required independence, implementation and substantiation objectives.

Conclusion

The concept of DAL in the aerospace industry ensures that aerospace safety-critical systems are developed with sufficient rigor to identify and correct design errors early in the design phase. By assigning Development Assurance Levels (DALs) based on failure severity, it ensures that the functions, systems and hardware components undergo the required level of scrutiny in development.

Irrespective of the industry, safety-critical system development emphasizes heavily on the concept of development assurance. The system safety standards and guidelines recommend using the objectives-based approach introduced with the concept of Development Assurance in ARP4761A and ARP4754B. It provides flexibility by allowing design teams to select methods and tools that best suit their requirements and level of rigor to be applied.

Finally, with increasing complexity in the systems being developed, the concept of DAL assignment and decomposition is often faced with some complexities as clear, concise guidance material is limited. Additionally, DAL is not always directly linked to quantitative failure rates leading to inaccurate implementation.

This post kicks off our step-by-step explanation of the Development Assurance Levels (DAL), introducing its purpose and the initial process for assigning DAL. In the upcoming posts, we'll explore system decomposition in more detail and compare DAL with related concepts like SIL and ASIL, continuing to build a clearer understanding of this critical assurance framework.