SAE規格 ARP4754, Revision B, 2023: Guidelines for Development of Civil Aircraft and Systems

Description

This SAE Aerospace Recommended Practice (ARP) provides recommendations for the development of aircraft and systems, taking into account aircraft functions and operating environment. It provides practices for ensuring the safety of the overall aircraft design, showing compliance with regulations, and assisting a company in developing and meeting its own internal standards. These practices include validation of requirements and verification of the design implementation for safety, certification, and product assurance.

The guidelines in this document were developed in the context of U.S. Title 14 Code of Federal Regulations (14 CFR) Part 25 and European Union Aviation Safety Agency (EASA) Certification Specification (CS) CS-25. They may be applicable in the context of other regulations, such as 14 CFR Parts 23, 27, 29, 33, and 35, and CS-23, CS-27, CS-29, CS-E, and CS-P.

This document addresses the development cycle for aircraft and systems that implement aircraft and system functions. It does not include detailed information on the following subjects and references:

• Software development; refer to RTCA DO-178C/EUROCAE ED-12C.
• Electronic hardware development; refer to RTCA DO-254/EUROCAE ED-80.
• Integrated modular avionics development; refer to RTCA DO-297/EUROCAE ED-124.
• Airworthiness security process; refer to RTCA DO-326A/EUROCAE ED-202A.
• Safety assessment processes; refer to ARP4761A/EUROCAE ED-135.
• A process for accomplishing in-service safety assessment is described in ARP5150A and ARP5151A or in other documents such as the guidance material of EASA Part 21 (GM21) when required by applicable regulation. In this document, wherever references to ARP5150A/ARP5151A are made, the reader should understand this also implies EASA Part 21 (GM21).
• Master Minimum Equipment List (MMEL) or Configuration Deviation List (CDL) development; refer to applicable regulatory guidance from the applicable Certification Authority.
• Aircraft structure and aerodynamics development.

Figure 1 outlines the relationships between the various development documents, which provide guidelines for safety assessment, electronic hardware and software life cycle processes, and the system development process described herein.

Purpose
The guidelines herein are industry best practices for the development of aircraft and of systems. Modern aircraft typically comprise a large integrated environment consisting of multiple systems with significant dependencies and interactions. Frequently portions of these systems are developed by separate individuals, groups, or organizations. These systems require design discipline and systematic development to ensure that safety and operational requirements can be fully realized and substantiated. Adherence to these guidelines is recommended for development of all aircraft systems, especially those that may contribute to failure conditions with the potential to affect safety.

The contents are recommended practices and should not be construed to be regulatory requirements. For this reason, the use of words such as “shall” and “must” is avoided except if used in the context of an example. It is recognized that alternative methods to the processes described or referenced in this document may be available to an organization desiring to obtain certification.

This document provides neither guidelines concerning the structure of an individual organization nor how the responsibilities for certification activities are divided. No such guidance should be inferred from the descriptions provided.

Development Assurance
A process is needed which establishes levels of confidence that development errors that can cause or contribute to identified failure conditions have been minimized with an appropriate level of rigor. This henceforth is referred to as the development assurance process. To establish levels of confidence for the aircraft systems as a whole, the process outlined herein presents guidelines for developing aircraft- and system-level requirements, including requirements allocated to items. The process includes validating requirements, and verifying that requirements are met, together with the necessary configuration management and process assurance activities. As development assurance level assignments are dependent on classification of failure conditions, the safety analysis process is used in conjunction with the development assurance process defined herein to identify failure conditions and severity classifications which are used to establish the level of rigor required for development.

Development assurance is a process-based approach which establishes confidence that system development has been accomplished in a sufficiently disciplined manner to limit the likelihood of development errors that could impact aircraft safety.

Document Background
During development of Revision B to RTCA/EUROCAE document DO-178/ED-12, it became apparent that system-level information would be required as input to the software development process. Since many system-level decisions are fundamental to the safety and functional aspects of aircraft systems, regulatory involvement in the processes and results relating to such decisions is both necessary and appropriate.

This document was originally developed in response to a request from the Federal Aviation Administration (FAA) to SAE. The FAA requested that SAE define the appropriate nature and scope of system-level information for demonstrating regulatory compliance for highly integrated or complex avionic systems. The Systems Integration Requirements Taskgroup (SIRT) was formed to develop an ARP that would address this need.

The initial members of SIRT recognized that harmonization of international understanding in this undertaking was highly desirable and encouraged participation by both FAA and Joint Aviation Authorities (JAA) representatives. A companion working group was formed under EUROCAE, WG-42, to coordinate European input to the SIRT group. The task group included people with direct experience in development and support of large commercial aircraft, commuter aircraft, commercial and general aviation avionics, jet engines, and engine controls. Certification Authority personnel with a variety of backgrounds and interests participated in the work of the task group. Both formal and informal links with RTCA special committees (SC-167 and SC-180) and SAE committee (S-18) were established and maintained. Communication with the harmonization working group addressing 14 CFR/CS 25.1309 was maintained throughout development of this document.

Throughout development of this document, discussion returned repeatedly to the issue of guideline specificity. Strong arguments were presented in favor of providing a list of very specific certification steps, i.e., a checklist. Equally strong arguments were made that the guidelines should focus on fundamental issues, allowing the applicant and the Certification Authority to tailor details to the specific system. It was recognized that in either case certification of all but the most idealized systems would require significant engineering judgment by both parties. The quality of those judgments is served best by a common understanding of, and attention to, fundamental principles. The decision to follow this course was supported by several other factors; the variety of potential systems applications, the rapid development of systems engineering, and industry experience with the evolving guidance contained in DO-178/ED-12 and their revisions being particularly significant.

The current trend in system development is an increasing level of integration between aircraft functions and the systems that implement them. While there can be considerable value gained when integrating systems with other systems, the increased complexity yields increased possibilities for errors, particularly with functions that are performed jointly across multiple systems. Following the Aviation Rulemaking Advisory Committee (ARAC) recommendations to respond to this increased integration which referenced ARP4754/ED-79 in advisory materials for compliance to 14 CFR/CS 23.1309 (refer to AC23.1309-1D, issued in 2009) and 25.1309 (refer to AMC 25.1309, published in 2003 and AC 25.1309 Draft ARSENAL revised) the use of the ARP4754/ED-79 in aircraft certification has become increasingly widespread. Along with the increasing use, in particular 5.4 of the original document, assignment of development assurance levels in the original ARP4754/ED-79, come insights on the strengths and weaknesses of its guidelines. The underlying philosophy is succinctly represented in the original 5.4 of ARP4754/ED-79 as follows:

“If the PSSA shows that the system architecture provides containment for the effects of design errors, so that the aircraft-level effects of such errors are sufficiently benign, the development assurance activities can be conducted at a reduced level of process rigor for the system items wholly within the architectural containment boundary.”

Experience has shown that the processes and definitions used to determine containment have yielded different interpretation and application of the philosophy. Revision A improved the development assurance level assignment process by providing a methodology to assign the correct development assurance levels (see 5.2).

Revision A contained updates to the document that took into account the evolution of the industry over the intervening years. EUROCAE WG-42 had been closed on completion of their task, the initial publication of ARP4754/ED-79. In order to support S-18 activities in maintaining the document, a new companion working group was formed under EUROCAE, WG-63, to coordinate European input. The relationship between ARP4754/ED-79 and ARP4761, and their relationship with DO-178B/ED-12B and DO-254/ED-80 were strengthened and discrepancies between the documents were identified and addressed. Revision A also explained the top-down development assurance concept for application at the aircraft and system level and standardized the use of the term development assurance. As a consequence, for aircraft and systems, Function Development Assurance Level (FDAL) was introduced and the term Item Development Assurance Level (IDAL) is used to describe that the level of rigor of development assurance tasks performed on item(s), e.g., IDAL is the appropriate “Software Level” in DO-178B/ED-12B and “Design Assurance Level” in DO-254/ED-80 objectives that need to be satisfied for an item. It also included enhancements created by feedback from the industry since the first publication. In addition, S-18/WG-63 coordinated the Revision A effort with RTCA Special Committee 205 (SC-205)/EUROCAE WG-71 to ensure that the terminology and approach being used were consistent with those being developed for the update to DO-178C/ED-12C.

Subsequent to the publication of Revision A, the FAA recognized ARP4754A as an acceptable method for establishing a development assurance process in AC 20-174.

Revision B Overview
Revision B is primarily focused on the necessary updates to align its contents with ARP4761A/ED-135. There were extensive discussions within S-18/WG-63 on the need to limit scope of this revision versus expanding its contents to include emerging system development techniques in use by the industry. Given the timeframe of ARP4761A/ED-135 publication, and the necessity to maintain consistency between both ARP4754B/ED-79B and ARP4761A/ED-135, the first option, limiting the scope, was chosen and suggested changes that would further expand ARP4754/ED-79 contents were deferred for a new Revision C. As a result, while the general principles of FDAL/IDAL assignment were retained in ARP4754B/ED-79B, the details of FDAL/IDAL assignment activities were transferred to ARP4761A/ED-135. The same approach was adopted for all safety assessment process contents in ARP4754B/ED-79B. Validation and verification sections have been changed to allow for a less prescriptive use of the many validation and verification methods, and concepts such as “unintended behavior“ and “derived requirements“ have been further clarified based on experience in applying ARP4754A/ED-79A in recent developments. The section addressing modifications has been completely changed to better account for different change categories used by the industry, including reuse. The definitions section, the objectives appendix, and certification coordination contents have been revisited and updated accordingly. A detailed example of an aircraft system development process has been added in Appendix E. Keeping to the Memorandum of Understanding for this document, WG-63 worked alongside S-18 to ensure that ED-79B is word-for-word equivalent to ARP4754B.