Assignm ent of Assignm ent of Design Assurance Levels Design Assurance Levels SAE S1 8 & EUROCAE W G-6 3 Presented by Steve Beland Associate Technical Fellow Boeing Com m ercial Airplanes August 20, 2008 FAA Software & AEH Conference 1
Status of New Draft Guidance � SAE S-18 Airplane Safety Assessment Committee updating SAE ARP 4754 Subcommittee: Fellowship of the DAL (FotDAL) � � Regular coordination with EUROCAE WG-63 � Mature text inserted as Sec 5.2 in Draft G2, S18 meeting Jan ’08 Delicate consensus, WG-63 participated remotely � Established baseline � � Draft H2 contains April joint meeting effort Flowchart added � Consensus strengthened, FotDAL done � August 20, 2008 FAA Software & AEH Conference 2
FotDAL Problem Statement � Initial DAL has not always been based on rigorous safety analysis � Delineation of the architectural containment boundaries were not always properly defined � Inconsistency between guidance sources � Difficult to delineate the subtleties between “independence” and “dissimilarity” � Probabilities have often been improperly linked to development assurance levels � Present ARP 4754 Section 5.4 does not clearly distinguish between loss vs. erroneous output of a function (but it is there “between the lines” of Table 4) August 20, 2008 FAA Software & AEH Conference 3
Situation � Use of ARP4754 is becoming more common ARP4754 was published in 1996 � Referenced in AMC 25.1309, AC 23.1309-1C and � draft 25.1309 (Arsenal) published in 2002 � FAA Policy Memo allows ESF for Part 25 Section 5.4 permits reduced level of process rigor � for development assurance activities provided proper safety analysis shows architectural containment Some perceived inconsistencies between ARP4754 � and DO-178B and DO-254 exist (Ref. FAA Policy Statement ANM-10-117-09, Jan 2004) August 20, 2008 FAA Software & AEH Conference 4
Related Changes to ARP4754 � Revision A restructured to include both the aircraft and system development life cycle process models � Document outline has a smoother flow � Sections 4 through 10 combined into 2 sections Section 4 outlines the aircraft/system development � process model Section 5 addresses the integral processes used � during aircraft/system development � New Section 5.2 is influenced by existing ARP 4754 Table 4 and the Functional Failure Path Analysis concept in RTCA DO-254 Appendix B Includes constraints to preclude extreme FFPA � interpretations August 20, 2008 FAA Software & AEH Conference 5
Development vs. Design Assurance � Development Assurance: 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 satisfies the applicable certification basis. Note: The development assurance of an item has sometimes been called design assurance, such as in RTCA/EUROCAE DO-254/ED-80. � Development Assurance Level (DvAL) Applies to aircraft and systems � V&V Process defined in SAE ARP4754A � Includes Safety Analysis � Influences Architectures � August 20, 2008 FAA Software & AEH Conference 6
Development vs. Design Assurance � Design Assurance: All of those planned and systematic actions used to � substantiate, at an adequate level of confidence, that design errors have been identified and corrected such that the items (hardware, software) satisfy the applicable certification basis. � Design Assurance Level (DsAL) Applies to items (software / hardware) � V&V Process defined in RTCA DO-178 & DO-254 � August 20, 2008 FAA Software & AEH Conference 7
Layered Development Life Cycle Airplane Systems Aircraft Function DvAL n Systems in Airplane System Function DvAL m Items in n Systems I tem DsAL August 20, 2008 FAA Software & AEH Conference 8
Assurance Activities At system level At Hardware Level At Software Level Assurance Activity ARP 4754/ED-79 DO-254/ED-80 DO-178B/ED-12B FHA Yes None None PSSA/SSA Yes None None FMEA Yes Implied via Functional None Failure Path Analysis. Common Cause Analysis Yes None None (including SW and complex HW common mode failures) Requirement Capture Yes Yes Yes Requirement Validation Yes Yes , for HW specific Yes , for SW specific requirements requirements Implementation Yes Yes Yes Verification Configuration Yes Yes Yes management Process assurance Yes Yes Yes August 20, 2008 FAA Software & AEH Conference 9
FotDAL Approach to Assigning Levels � Existing ARP explicitly addresses system level (with only some mention of airplane level) Level assignment/reduction applied to items � defined from the system architecture � New ARP addresses airplane & system levels explicitly DvAL is effectively new for the new ARP and should � be assigned to the systems from the aircraft architecture using the PASA/PSSA DsAL assignment should be similar to existing ARP � � Discusses “independence” rather than “dissimilarity” � Emphasize assigning levels rather than reducing levels “Reduction” is a misnomer, but arises when a function � has a level lower than its parent function August 20, 2008 FAA Software & AEH Conference 10
ARP4754A Draft Outline � 4 AIRCRAFT & SYSTEM DEVELOPMENT PROCESS 4.1 Conceptual Aircraft/System Development Process � 4.2 Aircraft Function Development � 4.3 Allocation of Aircraft Functions to Systems � 4.4 Development of System Architecture � 4.5 System Implementation � � 5 INTEGRAL PROCESSES 5.1 Safety Assessment � � 5 .2 Developm ent Assurance Level ( DvAL) Assignm ent 5.3 Requirements Capture � 5.4 Requirements Validation � 5.5 Implementation Verification � 5.6 Configuration Management � 5.7 Process Assurance � 5.8 Certification and Regulatory Authority Coordination � August 20, 2008 FAA Software & AEH Conference 11
System Development Process Model INTEGRAL PROCESSES - 5.1 SAFETY ASSESSMENT - 5.2 DEVELOPMENT ASSURANCE - 5.3 REQUIREMENTS CAPTURE - 5.4 REQUIREMENTS VALIDATION PLANNING - 5.6 CONFIGURATION MANAGEMENT - 5.7 PROCESS ASSURANCE 3.0 - 5.8 CERTIFICATION & REGULATORY GUIDANCE COORDINATION 5.5 IMPLEMENTATION VERIFICATION AIRCRAFT/SYSTEM DEVELOPMENT PROCESS 4.1 CONCEPT FUNCTION FUNCTION ARCHITECTURE REQUIREMENT SYSTEM DATA & DESIGN DEVELOPMENT ALLOCATION DEVELOPMENT ALLOCATION IMPLEMENTATION DOCUMENTATION 4.2 4.3 4.4 4.5 4.6 6.0 Figure 4 -2 August 20, 2008 FAA Software & AEH Conference 12
5.2 Assurance Level Assignment � 5.2.1 Introduction � 5.2.2 General Principles � 5.2.3 Independence Attributes � 5.2.4 DvAL & DsAL Assignment Guidelines August 20, 2008 FAA Software & AEH Conference 13
DvAL/DsAL Assignment Process Figure 5 -2 August 20, 2008 FAA Software & AEH Conference 14
Terminology � Functional Failure Set: � A single member, or a specific group of members (not necessarily limited to one system) whose anomalous behavior (random failure or systematic error) leads to a top level Failure Condition. An FFS member can be related to a function, a sub-function, or an item. August 20, 2008 FAA Software & AEH Conference 15
DvAL Assignment General Principles � Catastrophic Failure Condition: At least 1 development process is Level A, or at � least 2 independent development processes are Level B, but none any lower than their individual hazard and no lower than Level C Overall integration process is Level A � � Hazardous Failure Condition: At least 1 development process is Level B, or at � least 2 independent development processes are Level C, but none any lower than their individual hazard and no lower than Level D Overall integration process is Level B � August 20, 2008 FAA Software & AEH Conference 16
Independence Attributes � Functional: members with different fcns & reqts Common requirements errors � Requirements interpretation errors � � Design: members with different designs Hardware or software design errors � Software language or HDL errors � Design tool errors � � Others: do not influence DvAL/ DsAL assignment Physical � � Redundancy, installation Process � � Between independent designs or functions � Between development/design vs. verif/validation August 20, 2008 FAA Software & AEH Conference 17
Independence Attributes � DvAL considers the functional independence of the aircraft (or system) functions � DsAL considers the design independence of items � Once the DsALs are assigned to items, they should be fed back to the system and aircraft processes to ensure that no common mode is inadvertently introduced that violates any claimed functional independence. � The assertion of independence needs to be substantiated & address potential common-modes � One type of independence does not necessarily imply the other August 20, 2008 FAA Software & AEH Conference 18
Recommend
More recommend
