GM2 to
AMC6 ATM/ANS.OR.C.005(a)(2) Safety support assessment and assurance of changes
to the functional system
ED Decision 2019/022/R
ASSURANCE
— SOFTWARE ASSURANCE LEVELS
(a) The assurance required by AMC6 ATM/ANS.OR.C.005(a)(2) can be provided with different levels of confidence depending on the rigour to which the evidence and arguments are produced. Whereas, for air traffic services (ATS) providers, the use of the SWAL concept can be helpful to provide an explicit link between the criticality of the software and the rigour of the assurance, for service providers other than ATS providers, the use of the SWAL concept may not be relevant considering that non-ATS providers may not be aware of the safety aspects of the ATS provider using their services. However, considering that the safety support assessment will be based on the evidence and arguments generated by the software assurance processes and that the safety support assessment will support a safety assessment, it is foreseen that, in many changes, the software assurance evidence and arguments will have to demonstrate a certain level of confidence and therefore will have to show compliance with the SWAL allocated by the ATS provider.
(b) The use of multiple SWALs would also allow the possibility of managing several criticalities of the different software components within the system (with partitioning or other architectural strategies) by the same set of software assurance processes. When the software assurance processes employ several SWALs, they should define for each SWAL the rigour of the assurances to achieve compliance with the objectives set out in AMC6 ATM/ANS.OR.C.005(a)(2). As a minimum:
(1) the rigour should increase as the criticality of the service supported by the software solution increases; and
(2) the variation in rigour of the evidence and arguments per SWAL should include a classification of the activities and objectives according to the following criteria:
(i) required to be achieved with independence, i.e. the verification process activities are performed by a person (or persons) other than the developer of the item being verified;
(ii) required to be achieved; and
(iii) not required.
EASA regulations for air traffic management require rigorous safety assessments for functional system changes. Software assurance levels (SWALs) link software criticality to assurance rigor, especially for air traffic services. Multiple SWALs manage varying software component criticalities, increasing rigor with service criticality, ensuring independent verification where needed.
* Summary by Aviation.Bot - Always consult the original document for the most accurate information.
Loading collections...