Appendix A to SW 01 - Identification of AELs
1 Introduction
1.1 For the regulator to be satisfied that a software safety requirement has been implemented fully and correctly, the five objectives defined in Part 2 section 3 of SW 01 (Requirements Validity, Requirements Satisfaction, Requirements Traceability, Requirements Integrity, Freedom from Interference and Configuration Consistency) must be achieved.
1.2 In order to demonstrate that the objectives have been achieved, arguments and assurance evidence must be made available to the regulator from the behaviour of the software and certain aspects of the way in which it has been developed. The strength and depth (rigour) of that assurance evidence is driven by the safety criticality of the software safety requirement.
1.3 The safety criticality of the software safety requirement is expressed as an index in the range 1 to 5. This index is referred to as the Assurance Evidence Level (AEL). The AEL determines the minimum set of assurance evidence that is required to be available to the regulator for a given software safety requirement for any system proposed for approval. AELs are intended to be used as a strategic project management aid to ensure that appropriate software safety assurance processes are used throughout the lifecycle of safety related software.
1.4 Since the AEL determines the evidence to be available for approval of the system, it affects the products of the development process. Furthermore software safety requirements are dynamic in the sense that they can be created and altered by design decisions, as can their associated AELs. It is therefore extremely impractical for a regulator to either set or agree changes to each AEL as the associated software requirement changes during development. For this reason AELs are to be established by the Service Provider. The regulator will review them when the system is presented for approval.
1.5 The use of the AEL to assist the Service Provider in producing the optimum set of evidence and the use of SWAL does not remove from the Service Provider, the responsibility of demonstrating satisfaction of the requirement.
1.6 This Appendix provides the means whereby the Service Provider can establish the AEL of a software safety requirement.
1.7 The use of AELs as described here satisfies the requirements for Software Assurance Levels as defined in Annex I in EC Regulation 482/2008.
2 Safety Criticality
2.1 EC Regulation 2096/2005 (the Common Requirements) requires the assessment of the combined effects of hazards. Annex I of EC Regulation 482/2008 requires Software Assurance Levels to relate the rigour of software assurances to the safety criticality of the software. The use of AELs as described below is compliant with both regulations.
2.2 There are a number of indicators of criticality; the dominant one is the consequence of the software safety requirement not being met. This is expressed in terms of the impact of the failure on the likelihood and/or severity of an ensuing accident. These consequences can also be characterised by the impact of the failure on the continuation of the provision of an ATS or the need for any mandatory reporting of accident or incidents as defined in CAP 382.
2.3 Where architectural and operational defences have been taken against the consequences, they need to be taken into account when judging the criticality of the software safety requirement. Just assessing the AEL on the basis of the worst credible event in the wider system is likely to result in an unduly high AEL for the software safety requirement.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：CAP 670 Air Traffic Services Safety Requirements 1(81)
