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

COMPLETENESS OF THE ARGUMENT

(a)Sufficiency of specifications The way the service specification is arrived at is not of particular interest in a safety support case and so it is not dealt with here. A specification that is sufficient implies that the service meets the provider’s intent, i.e. it is valid. Two necessary conditions for a sufficient specification are provided here:

(1)Assessment of failure conditions

(i)Failures or failure conditions are malfunctions of behaviour. This means either the loss or corruption of some intended behaviour, e.g. behaviour that is considered to be:

(A)more than (quantity, information);

(B)less than (quantity, information);

(C)additional to;

(D)faster than;

(E)slower than;

(F)part of;

(G)reverse of;

(H)other than;

(I)not;

(J)earlier than;

(K)later than;

(L)before; or

(M)after that which was intended. If the behaviour of the service is altered in any way during malfunctions, the altered behaviour needs to be included in the specification. Further details could be found GM1 ATM/ANS.OR.C.005(b)(1) and GM1 ATM/ANS.OR.C.005(b)(2).

(ii)Some failures may not result in a degraded service.

(iii)Some failures may not be relevant in the context of use.

(iv)Strictly speaking, the failure and failure conditions described here are malfunctions of the services delivered by a component and may be caused by failures of components, errors in design, failures of services used by the component, or failures of the activities associated with installing the component, i.e. failure to install the component in the intended manner.

(v)When a redundancy within a component is no longer available, the behaviour of the component is considered to have changed, e.g. the reliability of the component will have changed and an indication of the loss of redundancy will have been provided.

(2)Evaluation of the behaviour It is necessary to argue that the behaviour of the implementation, i.e. the system as built, matches the specification and there is no additional (unspecified) behaviour. This implies verification of service behaviour, which is required by ATM/ANS.OR.C.005(b)(2) and stated here in a more specific way. It is also necessary to argue that the behaviour of the change during transition into service matches the specification and there is no additional (unspecified) behaviour. If transition into service causes disruption to the service being changed or other services provided by the service provider, then it may be necessary to include, within the specification, a specification of the intended installation activities. This implies an assessment of failure conditions associated with the installation activities and the specification of any necessary mitigations, should the failures materialise and the installation not be performed as intended.

(b)Safety support requirements

(1)The safety support requirements are 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 specifications are met.

(2)The highest-layer of safety support requirements represents the desired behaviour of the change at its interface with the operational context. These, ultimately become the specification, once the implementation is verified.

(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 support requirements are necessary.

(4)The way safety support requirements are achieved, is not of particular interest in a safety assessment, because a safety support argument demonstrates the trustworthiness of the specification.

(5)The architecture may not have requirements. During development, the need to argue satisfaction of system level requirements, 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.

(6)Demonstration that safety support requirements at system level are met allows them to be transformed into the safety support specification.

(c)Satisfaction of safety support requirements

(1)The concept laid down in AMC2 ATM/ANS.OR.C.005(a)(2) is that, provided the system and each subsystem/component/element meet its requirements, the system will behave as specified. This will be true provided (2), (3) and (4) below are met.

(2)The activity needed to meet objective (c) of AMC2 ATM/ANS.OR.C.005(a)(2) consists of obtaining sufficient confidence that the set of requirements is complete and correct, i.e. that:

(i)the architectural decomposition leads to a complete and correct set of requirements being allocated to each subsystem/component/element;

(ii)each 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 requirements allocated to a subsystem/component/element necessitate the complete required behaviour of the subsystem/component/element in the target environment.

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

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

(ii)subsystem/component/element requirements that are not directly related to the desired behaviour of the functional system. This kind of requirement can, for instance, ask that the subsystem/component/element be developed in a given syntax or be designed in a certain way. These requirements often relate to technical aspects of the subsystem/component/element. Activities should be undertaken to ensure that each of these requirements is a correct, complete and unambiguous statement of the desired effect, and does not contradict another requirement or any other subset of requirements.

(4)The system behaviour should be considered complete in the sense that the specification is only true for the defined context. This restriction to the context of the use of the service makes safety support assessment and assurance of changes to the functional system a practical proposition.

(d)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. It is likely and completely acceptable that this point will be reached at a different architectural level for each element.

(e)Satisfaction of safety support requirements

(1)The component view taken must be able to support verification, i.e. the component must be verifiable — see guidance in (b).

(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.

(3)The context argument needs to demonstrate that the context in which a component is verified does not compromise the claim that the specification is true over a specified context, i.e. the component verification context is correctly related to the context claimed for the operation of the functional system.

(f)Configuration identification

(1)This is only about configuration of the evidence and should not be interpreted as configuration management of the functional system. However, since the safety support assessment is based on a set of elements and the way they are interlinked, the safety support assessment should only be valid if the configuration remains as described in the safety support argument.

(2)Evidence for the use of a component should rely on testing activities considering the actual usage of 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.