In the past half of a century the Aerospace products have grown increasingly complex, interconnected and fiendishly difficult to understand for any single individual. With the growing complexity the number of misunderstandings, insufficient communication and coordination and the resulting errors and malfunctions in the products have only grown

That has been recognized very early in the area that basically exploded in scope first – the development of software, and thus the process-oriented standard DO-178/ED-12, that introduced a concept of qualitative objectives/different levels of design assurance based on safety-criticality in addition to quantitative/reliability/availability objectives, has been published and recognized by the regulators in the 1980ies as the means to minimize the number of such events/faults in a software to a minimum.

In the 1990ies the growth of systems and subsystems in large transport aircrafts led to the introduction of the SAE’s Aerospace Recommended Practices ARP-4754/ED-79 and ARP-4761(later also as ED-135) industry standards describing a practical methodology and processes helping with a development of correctly functioning and reliable/safe products.

One of the key concepts added in later revision was the distinction between the Functional Development Assurance Level and Item Development Assurance Level that gave the designer option how to architect his aircraft/system/subsystem in the best and most efficient way in order to meet all the quantitative and qualitative objectives.
These ARPs have been increasingly recognized by the Aerospace industry as really helpful tools, regardless of whether the regulators recognized it as the Acceptable Means of Compliance for a given category of products or not. As such we have seen use of these in the military domain as well and by the integrator driven contractual pressure even in companies that did not see the need for these standards initially.

Well, now the “noose around the neck” seems to be finally tightening for the bystanders that have thus far avoided deployment of these best practices as described in these standards. EASA has published on December the 17th of 2024 a Certification Memorandum CM-DASA-002 on ‘Development Assurance Considerations in Product Certification’ that will basically push the deployment of these standards as the Acceptable Means of Compliance into the remaining product areas as seen below:

Plus there is Development Assurance categories for CS‐23 and CS‐27:  

In order to define the category applicable to the product or some of its systems, different factors should be assessed and early coordination with EASA is necessary in order to determine Development Assurance requirements, except for: 

CS‐23 AL4 1, AL 2, CS‐27 Class I and Class II products –  No Development Assurance is expected for a system of those products, when the system meets the following criteria:  

‐ The system failure or combination of failures cannot directly lead to CAT or HAZ aircraft level failure condition OR  

‐ The system is not integrated and is conventional.  

 

Also, more surprisingly for some, changes to existing, already certified products, that will be assessed for criticality & scope of change & acceptability of existing processes (using an impact analysis evaluation per ARP-4754B), might need to follow/use the Development Assurance concept/ARPs as well. The logic behind this decision is that the changes could be, and often are, quite extensive when compared to their initial certification. 

Last, but not least, the need for an independent compliance review (in addition to the process assurance as defined in ARP-4754/ED-79) is recognized in the proposal. The recommendation here is that this should follow a gated process which includes a planning review, a design review, a verification review and a final compliance review, all of which need to be done by a someone not directly involved in the development assurance activities of the project. 

To sum it all up, this last push to deploy these best practices into the remaining pockets of resistance will lead to better and safer products. And for us, designers, it will finally standardize the practices we encounter and have to follow in our work – which again should lead to less misunderstanding, miscommunication and errors/malfunctions.