AMC6 ATM/ANS.OR.C.005(a)(2) Safety support assessment and assurance of changes to the functional system

• ED Decision 2019/022/R found in: ATM/ANS Provision of Services (2017/373) (Feb 2023)

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 PROCESSES (a)       The software assurance processes should provide evidence and arguments that they, as a minimum, demonstrate the following: (1)       The software requirements correctly state what is required by the software, in order to meet the service and safety support requirements, as identified by the safety support assessment ([AMC2 ATM/ANS.OR.C.005(a)(2)](#_DxCrossRefBm1726555126)). For that purpose, the software requirements should: (i)        be correct, complete and compliant with the upper level requirements; and (ii)       specify the functional behaviour, in nominal and downgraded modes, timing performances, capacity, accuracy, resource usage on the target hardware, robustness to abnormal operating conditions and overload tolerance, as appropriate, of the software. (2)       The traceability is addressed in respect of all software requirements as follows: (i)        Each software requirement should be traced to the same level of design at which its satisfaction is demonstrated. (ii)       Each software requirement allocated to a component should either be traced to an upper level requirement or its need should be justified and assessed that it does not affect the satisfaction of the safety support requirements allocated to the component. (3)       The software implementation does not contain functions that adversely affect the satisfaction of the service specification. (4)       The functional behaviour, timing performances, capacity, accuracy, resource usage on the target hardware, robustness to abnormal operating conditions and overload tolerance, of the implemented software comply with the software requirements. (5)       The software verification is correct and complete, and is performed by analysis and/or testing and/or equivalent means, as agreed with the competent authority. (b)       The evidence and arguments produced by the software assurance processes should be derived from: (1)       a known executable version of the software; (2)       a known range of configuration data; and (3)       a known set of software items and descriptions, including specifications, that have been used in the production of that version, or can be justified as applicable to that version. (c)        The software assurance processes should determine the rigour to which the evidence and arguments are produced. (d)       The software assurance processes should include the necessary activities to ensure that the software life cycle data can be shown to be under configuration control throughout the software life cycle, including the possible evolutions due to changes or problems’ corrections. They should include, as a minimum: (1)       configuration identification, traceability and status accounting activities, including archiving procedures; (2)       problem reporting, tracking and corrective actions management; and (3)       retrieval and release procedures. (e)       The software assurance processes should also cover the particularities of specific types of software such as commercial-off-the-shelf (COTS), non-developmental software and previously developed software where generic assurance processes cannot be applied. The software assurance processes should include other means to give sufficient confidence that the software meets the service and safety support requirements. If sufficient assurance cannot be provided, complementary mitigation means aiming at decreasing the impact of specific failure modes of this type of software, should be applied. This may include but is not limited to: (1)       software and/or system architectural considerations; (2)       existing service level experience; and (3)       monitoring. 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 PROCESSES (a) The software assurance processes should provide evidence and arguments that they, as a minimum, demonstrate the following: (1) The software requirements correctly state what is required by the software, in order to meet the service and safety support requirements, as identified by the safety support assessment ([AMC2 ATM/ANS.OR.C.005(a)(2)](#_DxCrossRefBm647742301)). For that purpose, the software requirements should: (i) be correct, complete and compliant with the upper level requirements; and (ii) specify the functional behaviour, in nominal and downgraded modes, timing performances, capacity, accuracy, resource usage on the target hardware, robustness to abnormal operating conditions and overload tolerance, as appropriate, of the software. (2) The traceability is addressed in respect of all software requirements as follows: (i) Each software requirement should be traced to the same level of design at which its satisfaction is demonstrated. (ii) Each software requirement allocated to a component should either be traced to an upper level requirement or its need should be justified and assessed that it does not affect the satisfaction of the safety support requirements allocated to the component. (3) The software implementation does not contain functions that adversely affect the satisfaction of the service specification. (4) The functional behaviour, timing performances, capacity, accuracy, resource usage on the target hardware, robustness to abnormal operating conditions and overload tolerance, of the implemented software comply with the software requirements. (5) The software verification is correct and complete, and is performed by analysis and/or testing and/or equivalent means, as agreed with the competent authority. (b) The evidence and arguments produced by the software assurance processes should be derived from: (1) a known executable version of the software; (2) a known range of configuration data; and (3) a known set of software items and descriptions, including specifications, that have been used in the production of that version, or can be justified as applicable to that version. (c) The software assurance processes should determine the rigour to which the evidence and arguments are produced. (d) The software assurance processes should include the necessary activities to ensure that the software life cycle data can be shown to be under configuration control throughout the software life cycle, including the possible evolutions due to changes or problems’ corrections. They should include, as a minimum: (1) configuration identification, traceability and status accounting activities, including archiving procedures; (2) problem reporting, tracking and corrective actions management; and (3) retrieval and release procedures. (e) The software assurance processes should also cover the particularities of specific types of software such as commercial-off-the-shelf (COTS), non-developmental software and previously developed software where generic assurance processes cannot be applied. The software assurance processes should include other means to give sufficient confidence that the software meets the service and safety support requirements. If sufficient assurance cannot be provided, complementary mitigation means aiming at decreasing the impact of specific failure modes of this type of software, should be applied. This may include but is not limited to: (1) software and/or system architectural considerations; (2) existing service level experience; and (3) monitoring.