GM1 to AMC2 ATS.OR.205(a)(2) Safety assessment and assurance of changes to the functional system

COMPLETENESS OF THE ARGUMENT

(a)Sufficiency of safety criteria

(1)A sufficient set of safety criteria is one where the safety goal of the change is validly represented by the set of individual safety criteria, each criterion of which must be valid in its own right and not contradict another criterion or any other subset of criteria. A valid criterion is a correct, complete and unambiguous statement of the desired property. An individual valid criterion does not necessarily represent a complete safety criterion. An example of an invalid criterion is that the maximum take-off weight must not exceed 225 Tonnes because weight is measured in Newtons and not in Tonnes. An example of an incomplete criterion is that the accuracy must be 5 m because no reliability attribute is present. This implies it must always be within 5 m, which is impossible in practice.

(2)Optimally, a sufficient set of criteria would consist of the minimum set of non-overlapping valid criteria and it is preferable to a set containing overlapping criteria.

(3)Criteria that are not relevant, i.e. ones that do not address the safety goal of the change at all, should be removed from the set as they contribute nothing, may contradict other valid criteria and may serve to confuse.

(4)There are two forms of overlap: complete overlap and partial overlap.

(i)In the first case, one or more criteria can be removed and the set would remain sufficient, i.e. there are unnecessary criteria.

(ii)In the second case, (partially overlapping criteria) if any criterion were to be removed, the set would not be sufficient. Consequently, all criteria are necessary; however, validating the set would be much more difficult. Showing that a set of criteria with significant overlap do not contradict each other is extremely difficult and consequently prone to error.

(5)It may, in fact, be simpler to develop an architecture that supports non-overlapping criteria than to attempt to validate a partially overlapping set of criteria.

(b)Safety requirements

(1)The safety requirements are design characteristics/items of the functional system to ensure that the system operates as specified. Based on the verification/demonstration of these characteristics/items, it could be concluded that the safety criteria are met.

(2)The highest layer of safety requirements represents the desired safety behaviour of the change at its interface with the operational context.

(3)In almost all cases, verification that a system behaves as specified cannot be accomplished, to an acceptable level of confidence, at the level of its interface with its operational environment. To this end, the system verification should be decomposed into verifiable parts, taking into account the following principles:

(i)Verification relies on requirements placed on these parts via a hierarchical decomposition of the top level requirements, in accordance with the constraints imposed by the chosen architecture.

(ii)At the lowest level, this decomposition places requirements on elements, where verification that the implementation satisfies its requirements can be achieved by testing.

(iii)At higher levels in the architecture, during integration, verified elements of different types are combined into subsystems/components, in order to verify more complete parts of the system.

(iv)While they cannot be fully tested, other verification techniques may be used to provide sufficient levels of confidence that these subsystems/components do what they are supposed to do.

(v)Consequently, since decomposing the system into verifiable parts relies on establishing requirements for those parts, then safety requirements are necessary.

(4)The architecture may not have requirements. During development, the need to argue satisfaction of safety criteria, which cannot be performed at the system level for any practical system, drives the architecture because verifiability depends on the decomposition of the system into verifiable parts.

(c)Satisfaction of safety criteria

(1)The concept laid down in AMC2 ATS.OR.205(a)(2) is that, provided each element meets its safety requirements, the system will meet its safety criteria. This will be true provided (2) and (3) below are met.

(2)The activity needed to meet this objective consists of obtaining sufficient confidence that the set of safety requirements is complete and correct, i.e. that:

(i)the architectural decomposition of the elements leads to a complete and correct set of safety requirements being allocated to each sub-element;

(ii)each safety requirement is a correct, complete and unambiguous statement of the desired behaviour and does not contradict another requirement or any other subset of requirements; and

(iii)the safety requirements allocated to an element necessitate the complete required safety behaviour of the element in the target environment.

(3)This should take into account specific aspects such as:

(i)the possible presence of functions within the element that produce unnecessary behaviour. For instance, in the case where a previously developed element is used, activities should be undertaken to identify all the possible behaviours of the element. If any of these behaviours is not needed for the foreseen use, then additional requirements may be needed to make sure that these functions will not be solicited or inadvertently activated in operation or that the effects of any resulting behaviour are mitigated;

(d)other requirements that are not directly related to the desired behaviour of the functional system. These requirements often relate to technical aspects of the system or its components. Activities should ensure that each of these requirements does not compromise the safety of the system, i.e. does not contradict the safety requirements or criteria.

(e)Traceability of requirements The traceability requirement can be met by tracing to the highest-level element in the architectural hierarchy that has been shown to satisfy its requirements, by verifying it in isolation.

(f)Satisfaction of safety requirements

(1)The component view taken must be able to support verification, i.e. the component must be verifiable.

(2)Care should be taken in selecting subsystems that are to be treated as components for verification to ensure that they are small and simple enough to be verifiable.

(g)Adverse effects on safety

(1)Interactions of all changed components or components affected by the change, operating in their defined context, have to be identified and assessed for safety in order to be able to show that they do not adversely affect safety. This assessment must include the failure conditions for all components and the behaviour of the services delivered to the component including failures in those services.

(2)Interactions between changing components, as they are installed during transitions into operation, and the context in which they operate have to be identified and assessed for safety in order to be able to show that they do not adversely affect safety. This assessment must include the failure conditions for all installation activities. In some cases, installing components during transition into operation may cause disruption to services other than the one being changed. These services fall within the scope of the change (see GM1 ATM/ANS.OR.A.045(c); (d)), and consequently the safety effects failures of these services, due to failures of the installation activities, have to be assessed as well and, if necessary, their impacts mitigated.

(3)Interactions in complex systems are dealt with in ATM/ANS.OR.A.045(e)(1).

(h)Configuration identification

(1)AMC2 ATS.OR.205(a)(2), point (f) is only about configuration of the evidence and should not be interpreted as configuration management of the changed functional system. However, since the safety case is based on a set of elements and the way they are joined together, the safety case will only be valid if the configuration remains as described in the safety case.

(2)Evidence for the use of a component should rely on testing activities considering the actual usage domains and contexts. When the same component is used in different parts of the system or in different systems, it may not be possible to rely on testing in a single context since it is unlikely that the contexts for each use will be the same or can be covered by a single set of test conditions. This applies equally to the reuse of evidence gathered from testing subsystems.