1、_ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising there
2、from, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions. Copyright 2012 SAE International All rights reserved. No part of this p
3、ublication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-497
4、0 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org SAE values your input. To provide feedback on this Technical Report, please visit http:/www.sae.org/technical/standards/AIR6218 AEROSPACE INFORMATION REPORT AIR6218 Issued 2012-09 Constructing Developm
5、ent Assurance Plan for Integrated Systems RATIONALE This SAE Aerospace Information Report presents a collection of lessons learned for constructing development assurance plans for integrated systems based on past certification programs. FOREWORD Integrated aircraft system architectures have flourish
6、ed in civil aircraft development since the 1990s, and the use of such architectures will likely accelerate in future design practices. To date, the industry standards (and regulatory guidance) on integrated systems have not progressed much further than a firm acknowledgment of the rapid integrated s
7、ystems growth trend, and a recognition of potential safety risks if development errors are not identified and corrected during the development process. Chapter 4 of the SAE ARP4754A, Guidelines for Development of Civil Aircraft and Systems, recognizes this issue and states, “Complex systems and inte
8、grated aircraft level functions present greater risk of development error (requirements determination and design errors) and undesirable, unintended effects.“ In todays practices, development assurance plans for integrated systems are predominantly based on the tried-and-true concept of separation o
9、f responsibilities between various disciplines. This is incongruent with the demands of integrated system architectures. While system separation, fault isolation, or error containment, will continue to be effective risk management practices that must not be compromised or overlooked, a new approach
10、for constructing a development assurance plan for integrated systems is needed to cope with the reality of system design trends. SAE AIR6218 Page 2 of 10 1. SCOPE This SAE Aerospace Information Report (AIR) supplements ARP4754A by identifying the crucial elements to be considered when constructing t
11、he development assurance plans described in Chapter 3 (Development Planning) of ARP4754A for integrated systems. This AIR presents a collection of lessons learned from past certification programs involving integrated systems. This AIR is not guidance for system integration technologies. 2. APPLICABL
12、E DOCUMENTS The following publications form a part of this document to the extent specified herein. The latest issue of SAE publications shall apply. The applicable issue of other publications shall be the issue in effect on the date of the purchase order. In the event of conflict between the text o
13、f this document and references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. 2.1 SAE Publications Available from SAE International, 400 Commonwealth Drive, Warrend
14、ale, PA 15096-0001, Tel: 877-606-7323 (inside USA and Canada) or 724-776-4970 (outside USA), www.sae.org. ARP4754A Guidelines for Development of Civil Aircraft and Systems Beland, S. and Miller, A., “Assuring a Complex Safety-Critical Systems of Systems,“ SAE Technical Paper 2007-01-3872, 2007, doi:
15、10.4271/2007-01-3872 3. DEVELOPMENT ASSURANCE PLANNING Development Assurance involves all of those planned and systematic actions used to substantiate, at an adequate level of confidence, that errors in requirements, design and implementation have been identified and corrected such that the system s
16、atisfies the applicable certification basis. Chapter 3 of ARP4754A provides a general planning process to address development assurance. This general process involves a number of “development planning elements,” repeated in Table 1: TABLE 1 - DEVELOPMENT PLANNING ELEMENTS Planning Elements Element D
17、escription Development Establish the process and methods to be used to provide the framework for the aircraft/system architecture development, integration and implementation. Safety Program Establish scope and content of the safety activities related to the development of the aircraft or system. Req
18、uirements Management Identify and describe how the requirements are captured and managed. Sometimes these elements are included in conjunction with the validation elements. Validation Describe how the requirements and assumptions will be shown to be complete and correct. Implementation Verification
19、Define the processes and criteria to be applied when showing how the implementation satisfies its requirements. Configuration Management Describe the key development related configuration items and how they will be managed. Process Assurance Describe the means to assure the practices and procedures
20、to be applied during system development are followed. Certification Describe the process and methods that will be used to achieve certification. SAE AIR6218 Page 3 of 10 The various planning data described in ARP4754A is reproduced graphically in Figure 1 using the traditional development “V” diagra
21、m. This graphic conveys a potential for gaps in conventional system development planning to occur (i.e., the white space in between the aircraft plans and the system plans). An integrated system may, therefore, have these same plan disconnects as well as additional system implementation strategy ind
22、uced short falls. Although the ARP4754A comprehensively describes a general development process and life cycle, it does not focus on the development assurance activities that are unique to integrated systems. To begin this discussion we need to have a common set of terms. Within this AIR we consider
23、 the following: 1. What is an “integrated system”? In the context of this AIR, an “integrated system” is the set or arrangement of interdependent systems that have complex relationship or connection to provide a given capability. It can be visualized as a system of systems. Integrated systems enable
24、 more efficiency and robustness in providing system functions. Shared system resources, especially computers and communication networks, enable the implementation of functions more complex than can be provided by an individual system. However, integrated system architectures can introduce complex me
25、chanisms for cascading failures or other unintended consequences. 2. How is the Development Assurance Plan for Integrated Systems (DAPIS) different from the plan elements shown in Table 1 and graphed in Figure 1? The planning elements shown in Table 1 and Figure 1 reflect practices commonly associat
26、ed with the development of stand-alone systems. While the concept they represent is generally applicable to any system arrangement, be it integrated or standalone, DAPIS focuses on the interrelationships between those elements, to help answer lingering concerns that something may be missing or overl
27、ooked when integrated systems are developed and certified. Compared to standalone system development, the integrated system plan must contemplate the larger number of multi-dimensional interactions between functions, systems, and the organizations who work on them to minimize the risk of “missing so
28、mething important.” This AIR provides a “hands-on” set of elements based on lessons learned from past certification programs. Because a plan is tailored to the needs of the individual project, the elements discussed in Section 4 are not intended to be a general “template”. Rather, they provide insig
29、hts on issues that experience has shown may not always be obvious (i.e., missing) when the development assurance activities of ARP4754A are planned or executed. 4. DEVELOPMENT ASSURANCE PLANNING FOR INTEGRATED SYSTEMS (DAPIS) The classic planning considerations prescribed in ARP4754A provide for nom
30、inal integration of systems with considerations for the physical interfaces between electrical systems, interfaces between electrical systems and mechanical systems, or logical interfaces between hardware and software. These considerations may not be enough to assure the development of integrated sy
31、stems. The planning elements for integrated systems should also be considered when executing the planning process described in ARP4754A. DAPIS effects on the overall planning process should cover some or all of the following: design, test, manufacturing, maintenance, make allowances for follow-on pr
32、oduct improvement. The following integrated systems effects on the ARP4754A plans should be contemplated. Note: As the following information is a collection of “lessons learned,” readers should assess them for applicability to their projects and the equivalency of their existing methods and tools. F
33、igure 2 presents the additional planning and implementation relationships for integrated systems. The magenta highlighted integration plans gain importance when the development objective is an integrated system. The mechanisms for interface control also increase the interactions between activities a
34、nd enhance communication for the integrated system. SAE AIR6218 Page 4 of 10 FIGURE 1 - ARP4754A PLANNING RELATIONSHIPS SAE AIR6218 Page 5 of 10 FIGURE 2 - DAPIS PLANNING RELATIONSHIP SAE AIR6218 Page 6 of 10 4.1 DAPIS Effects on Aircraft Certification Plans It is crucial that the system-level plans
35、 are congruent with each other and with the aircraft-level plan. The OEM should conduct oversight to ensure process assurance, and the objectives of the aircraft-level plan are met by the system-level plans. Aircraft-level plans should be developed early in the development, before the system-level p
36、lans are completed. 4.1.1 Certification and Safety Issue Identification Develop a communication plan (e.g., organization and schedule for technical panels discussion with certification authorities). A technical panel dedicated to aircraft-level safety is recommended for a new aircraft program. See a
37、lso the discussion on “Master documents” below. Communicate the “design for safety” approaches within a developers organization. Integrated system development can no longer rely on stovepipe practices where safety activities are separate from the design activities. It is a collaborative, not indepen
38、dent effort, between Safety and Design organizations. Appendix B of ARP4754A provides guidelines for the creation of a Safety Progam Plan which can be used to develop the interface between the design and safety organizations. The safety assessments need to contemplate the effects of having multiple
39、functional failures (e.g., loss, degradation or erroneous operation) that could result from a single shared resource failure. Although an individual functional failure is not so severe, in combinations they may have a more severe hazard classification than the effects of any one of the functions tak
40、en alone. 4.2 DAPIS Effects on Safety Program Plans 4.2.1 “Master” Documents The use of “master” documents to capture the development process to be applied across all systems and their interfaces is recommended. This master document serves as a reference point for anyone working on the program to us
41、e as an authoritative source of common information. This master document should contain (or have pointers to) the following types of information: The common set of data related to the intended operations of the product (for example, average flight profile, probability values of specific failures or
42、external events, specific criteria that are not apparent in the regulatory guidance, etc.). This set of data is used as a baseline for all safety analyses performed on the product. The overarching safety analysis methods that clarify, or expand on, aspects of selected regulations to ensure consisten
43、cy of understanding of such regulations, and compliance determination between interfacing systems. Completion criteria for the development assurance activities, especially completion criteria for the validation and verification activities. These criteria, or at least a framework thereof, should be d
44、eveloped and presented to the certification authorities as early as possible in the development life cycle. It is recommended that “master documents” be agreed to by all influencing parties at the beginning of the program. SAE AIR6218 Page 7 of 10 4.3 DAPIS Effects on Development Plans (for aircraft
45、 and system-level process assurance) 4.3.1 Organizational Interaction Management The responsibilities, capabilities, work statements for each activity should be defined across organizational and programmatic execution boundaries, for example, interactions between the OEM and the suppliers, or betwee
46、n the organizations internal to the OEM. This establishes the roles and responsibility expectations for system integrators, suppliers, etc. for validation, verification, process assurance, configuration management and problem reporting. 4.3.2 Integrated System Boundary Definition A definition of wha
47、t the integrated system will encompass should be defined. The integrated system boundary may encompass: Aircraft and system functions. Aircraft and system architectures, and their interdependencies. Man-machine interfaces, especially a strategy for multiple (and potentially simultaneous) alerting fu
48、nctions. While integrated systems can ease flight crew workload, a failure in an integrated system can generate multiple alerts (e.g., through cascading effects) and may complicate flight crews ability to isolate or prioritize corrective actions. Shared resource capabilities and capacities. Criteria
49、 for selecting which functions are to be integrated (e.g., use the shared resource), and which should stand alone. This involves an analysis of the criticalities of the functions, leading to the identification of the potential needs for more rigorous controls of selected functions or design parameters. 4.3.3 System Interface Management The following system interface constructs are recommended for integrated syste
