GM3 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 ALLOCATION
The process to allocate a SWAL to a software consistently with its foreseen criticality, as identified by the safety support assessment and requirements, should consider the following elements:
(a) Â Â Â Â The SWAL allocation should relate the rigour of the software assurances to the foreseen criticality of the software.
(b) Â Â Â The allocated SWAL should be commensurate with the worst credible effect that software malfunctions (i.e. the inability of a programme to perform a required function correctly) or failures (i.e. the inability of a programme to perform a required function) may cause, as assessed by the ATS provider that is planning to make use of the non-ATS services.
(c) Â Â Â Â The software components that cannot be shown to be independent of one another should be allocated to the SWAL of the most critical of the dependent components. In this context, the term âsoftware componentsâ is understood to be a building block that can be fitted or connected together with other reusable blocks of software to combine and create a custom software application, and âindependent software componentsâ are those software components which are not rendered inoperative by the same failure condition.
(d) Â Â Â The allocated SWALs should be consistent with the levels defined in the software assurance processes.
Software changes in air traffic management require rigorous safety assessments. The software assurance level (SWAL) must match the potential impact of malfunctions, considering worst-case scenarios. Interdependent software components inherit the highest SWAL of the group, ensuring consistent safety standards across all levels.
* Summary by Aviation.Bot - Always consult the original document for the most accurate information.
Loading collections...