On December 20th 2023, both SAE and EUROCAE conjointly released the new version of the “Guidelines for the Development of Civil Aircraft and Systems”, also known as ARP4754B (SAE) or ED-79B (EUROCAE).

This standard provides a description of the processes and artifacts used in the development of civil aircraft and systems. It recommends the best practices to ensure development teams implement design discipline and a systematic approach that fully realizes and substantiates safety and operational requirements in aerospace. The new revision incorporates modifications on known errata and integrates specific industry comments necessary to keep up with the the industry’s technological development.


Among the updates introduced in ARP4754 version B are:
• The inclusion of new methods for safety analyses such as MBSA (Model-Based Safety Analysis) and CEA (Cascading Effects Analysis)
• Increased flexibility in selecting validation and verification methods
• Inclusion of the consensus for methods of demonstrating compliance into the Development Planning
• Emphasis on methods for identifying and mitigating unintended behaviors
• A focus on alignment with ARP4761A.
This article describes the changes introduced and discusses its impact on the current and future aerospace industry development activities.

ARP4754A versus ARP4754B


While ARP4754A is labelled as a ‘guideline,’ it functions as a pathway to demonstrate compliance with aviation regulations. For instance:

All of these elevates it from a ‘guideline’ to a ‘mandatory’ status, which the new version ARP4754B inherits.


During the inception of DO-178B, the necessity for system-level data to drive software development became apparent, prompting the issuing of guidelines for Aircraft/System Development and Safety Assessment. Given the critical impact of system-level decisions on aircraft safety, regulatory oversight was imperative, leading to the development of ARP4754 and ARP4761 by the skilled engineers of the SAE group at the request of the FAA.

As the aviation industry progressed, updating the guidelines for aircraft and aircraft system development became necessary. This led to the release of ARP4754A, which aligned system processes with ARP4761, DO-178C, and DO-254. Here for the first time, the concept of top-down development assurance, along with the FDAL and IDAL Allocation process was introduced.

ARP4754B primarily focuses on alignment with the recently released ARP4761A, indicating that there are no significant changes in development principles compared to ARP4754A. The core of the development process remains consistent, and we expect some big changes in the forthcoming version, ARP4754C.

This article will provide an overview of the key distinction between ARP4754B and ARP4754A

Figure 1. Development History of ARP4754 & ARP4761


Here is the Aircraft/System Development Process Model, which still comprises the three main processes.

      • Development Planning
      • Aircraft/System Development
      • Integral Process.

Upon initial examination, it may seem that the Aircraft/System Development Process has been expanded, as there are more steps depicted in the process itself. However, all these steps were inherent to development according to ARP4754A; they were merely not explicitly illustrated in this figure. For instance, the development of a PASA (Preliminary Aircraft Safety Assessment), which is the requisite output for the Safety Process (refer to Table A1 in ARP4754A or ARP4754B), necessitates the development of aircraft architecture.

In the Integral Process, the Certification & Regulation Authority Coordination process has been eliminated. However, this doesn’t signify its absence; rather, the Certification Authority Coordination chapter has been integrated into Development Planning (Section 3.3 ARP4754B). This adjustment is quite anticipated, as the establishment of communication between the applicant and the Certification Authority, and the consensus reached with Certification Authorities regarding the intended methods of demonstrating compliance with specific regulatory requirements and industry standards, occurs during the Development Planning and does not constitute an Integral Process.

ARP4754B Aircraft Systems Development Process
Figure 2. Aircraft/System Development Process Model as modified by ARP4754B

As ‘Aircraft/System Development Process Model’ figure other figures in ARP4754B have been updated, primarily for clarification purposes rather than altering the development process significantly. However, certain changes in specific processes could impact the established development procedures. Below, we will highlight key changes to each process in ARP4754B to assist users in focusing on specific sections.

Note – Please take note that certain document titles within the Outputs section have been subject to minor adjustments. For detailed information, please refer to Table A1 ARP4754B.


The range of safety analysis methods available for the development process has been broadened. In addition to familiar techniques like

  • PRA (Particular Risk Analysis), ZSA (Zonal Safety Analysis), CMA (Common Mode Analysis;
  • FTA (Fault Tree Analysis), DD (Dependency Diagram), MA (Markov Analysis)
  • FMEA/FMES (Failure Mode and Effects Analysis/Summary)

newer methods such

  • MBSA (Model-Based Safety Analysis)
  • CEA (Cascading Effects Analysis)

have been introduced, with comprehensive descriptions provided in ARP4761A.

Furthermore, while the fundamental principles of DAL assignment remained in ARP4754B, the procedural specifics were moved to ARP4761A.


Validation and verification methods

While the validation and verification processes remain unchanged, systems engineers now have increased flexibility in selecting validation and verification methods. As discussed earlier in ‘From complexity to clarity: how to develop requirements for aircraft systems?‘, the choice of methods is determined by the FDAL. In ARP4754A, validating a function with FDAL A required the use of: at least 3 methods:

  • Traceability
  • Engineering Review
  • Analysis, Modeling, or Testing

In ARP4754B, Traceability and Engineering Review remain primary methods, with additional methods like Analysis, Modeling, or Testing being optional and uses if Traceability and Engineering Review are insufficient. For example, if a requirement involves a complex state machine, modeling may be utilized.

Similarly, in verification, where testing is the primary method, supplementary methods may be employed in conjunction with testing or as alternatives if necessary or applicable.

Please note that the independence recommendation remain unchanged:

  • Validation Process independence (independence between the requirements capture activities the validation activities) is recommended for Level A and Level B requirements.
  • Verification Process independence (independence between the implementation and the verification activities) is recommended for all level A requirements, and for level B safety requirements.

Unitendent behaviour

Special emphasis is placed on Unintended Behavior (previously, in ARP4754A termed Unintended Function). As such, Development Assurance Plans should outline methods for identifying and mitigating unintended behaviors. This includes specifying the testing level (e.g., intra-system, inter-system, aircraft-level) and types of testing (scenario-based, targeted, opportunistic). The integration process provides an excellent opportunity to detect Unintended Behavior. During integration, particular attention should be given to testing functions in potentially unsafe operating conditions, such as parameters outside the expected range, data bus noise, power interruptions, etc.


This section has undergone revisions, now encompassing modifications as well as system, equipment, or item reuse. It also emphasizes the necessity of conducting a Modification Impact analysis to assign a Change Category (Unmodified and Unaffected, Affected, Modified, New). Depending on the assigned category, specific Development Assurance activities are required. It is strongly advised to thoroughly review this section before initiating any modification process, as it may be influenced by the updated information provided herein.


From my perspective, the newly introduced Appendix E, which outlines the development of a hypothetical S18 airplane Wheel Brake System (WBS), is an invaluable resource for any system engineer. It’s a step-by-step example, which serves as a helpful reference for clarifying any uncertainties encountered while studying ARP4754B. Additionally, Appendix E aligns with ARP4761A Appendix Q, providing a comprehensive example of Safety Assessment for the same Wheel Brake System (WBS), illustrating the necessary interaction between Development and Safety Assessment processes. In summary, it is essential reading for all involved.


In conclusion, ARP4754B stays true to the principles of its predecessor, ARP4754A, with a focus on alignment with ARP4761A. Lastly, thanks are extended to the engineers from a working group whose contributions led to the development of ARP4754B, shaping the landscape of aviation safety standards.

DMD Solutions RAMS Academy

If you enjoyed this content, subscribe to our newsletter now to receive articles, white papers and free webinar invites directly in your inbox.


    Aerospace Engineer Reliability Safety

    Anastasiia Balashova

    Anastasiia Balashova is an accomplished avionics engineer with a Master's degree in radio physics, boasting over nine years of expertise in adhering to ARP4754A, ARP4761, DO-178C, and DO-254 development standards. Her unwavering commitment to upholding industry regulations and desire for comprehensive analysis positions her as an invaluable resource in guaranteeing the reliability and safety of aircraft systems. Currently serving as a Senior RAMS Engineer at DMD Solutions, her primary focus centers on Reliability (RP) and Safety Analysis (SFHA, PSSA, SSA, FTA, FMEA) of avionics systems.

    DMD Solutions  provides a comprehensive range of RAMS solutions to help organizations ensure the reliability, availability, maintainability, and safety of their product. Connect with our expert team for collaborations, we would be happy to assist you. Contact us now to receive support.