ATM/ANS.OR.C.001 Scope

Regulation (EU) 2017/373

This Subpart establishes the requirements to be met by the service provider other than the air traffic services provider, in addition to the requirements set out in Subparts A and B.

ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the functional system

Regulation (EU) 2017/373

(a) For any change notified in accordance with point ATM/ANS.OR.A.045(a)(1), the service provider other than the air traffic services provider shall:

(1) ensure that a safety support assessment is carried out covering the scope of the change which is:

(i) the equipment, procedural and human elements being changed;

(ii) interfaces and interactions between the elements being changed and the remainder of the functional system;

(iii) interfaces and interactions between the elements being changed and the context in which it is intended to operate;

(iv) the life cycle of the change from definition to operations including transition into service;

(v) planned degraded modes;

(2) provide assurance, with sufficient confidence, via a complete, documented and valid argument that the service will behave and will continue to behave only as specified in the specified context.

(b) A service provider other than an air traffic services provider shall ensure that the safety support assessment referred to in point (a) comprises:

(1) verification that:

(i) the assessment corresponds to the scope of the change as defined in point (a)(1);

(ii) the service behaves only as specified in the specified context;

(iii) the way the service behaves complies with and does not contradict any applicable requirements of this Regulation placed on the services provided by the changed functional system; and

(2) specification of the monitoring criteria necessary to demonstrate that the service delivered by the changed functional system will continue to behave only as specified in the specified context.

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

ED Decision 2017/001/R

GENERAL

(a) The safety support assessment should be conducted by the service provider itself. It may also be carried out by another organisation, on its behalf, provided that the responsibility for the safety support assessment remains with the service provider.

(b) A safety support assessment needs to be performed when a change affects a part of the functional system managed by a service provider other than an air traffic services provider and it is being used in the provision of its services. The safety support assessment or the way it is conducted does not depend on whether the change is a result of a business decision or a decision to improve the service performance.

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

ED Decision 2017/001/R

SAFETY SUPPORT ASSESSMENTS BY PROVIDERS THAT ARE ALSO ATS PROVIDERS

(a) Only air traffic services providers can perform a safety assessment. Service providers other than air traffic services providers can only perform a safety support assessment to determine that the new or changed service behaves only as specified in a specified context.

(b) A safety support assessment should be carried out for changes that cross the organisation’s boundary.

(c) An air traffic services provider may choose not to perform a safety support assessment of changes to its functional system when the changes do not cross the organisation’s boundary. In this specific case, the safety assessment of changes to the functional system should be performed.

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

ED Decision 2017/001/R

SAFETY SUPPORT ASSESSMENT

(a) A safety support assessment is needed whenever the functional system of a service provider other than an air traffic services provider changes. This may be as a result of:

(1) the provider proposing a change to:

(i) its functional system;

(ii) the services it provides;

(iii) the context in which its functional system operates; or

(iv) the context in which the service is provided;

(2) the services used by the provider in the delivery of its services being planned to change; or/and

(3) a change to the context in which the service provider’s functional system operates as a result of a proposed change by another service provider, another organisation regulated by Regulation (EC) No 216/2008 or an unregulated body.

(b) The granularity of the safety support case report will depend on:

(1) the scope of the change;

(2) the nature and number of arguments; and

(3) the necessary and sufficient evidence needed to provide appropriate confidence that the safety support assurance is valid (complete and correct).

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

ED Decision 2017/001/R

SCOPE OF THE CHANGE

(a) The description of the elements being changed includes the nature, functionality, location, performance, maintenance tasks, training and responsibilities of these elements, where applicable. The description of interfaces and interactions, between machines and between humans and machines, should include communication means, e.g. language, phraseology, protocol, format, order and timing and transmission means, where applicable. In addition, it includes the description of the context in which they operate.

(b) There are two main aspects to consider in evaluating the scope of a change:

(1) The interactions within the changed functional system.

(2) The interactions within the changing functional system, i.e. those that occur during transitions from the current functional system to the changed system. During such transitions, components are replaced/installed in the functional system. These installation activities are interactions within the changing functional system and are to be included within the scope of the change.

As each transition can be treated as a change to the functional system, the identification of both the above has a common approach described below.

(c) The scope of the change is defined as the set of the changed components and affected components. In order to identify the impacted components and the changed components, it is necessary to:

(1) know which components will be changed;

(2) know which component’s (components’) behaviour might be affected by the changed components, although it is (they are) not changed itself (themselves); and

(3) detect indirectly affected components by identifying:

(i) new interactions introduced by the changed or directly affected components;

(ii) interactions with changed or directly affected components via the context.

Furthermore, directly and indirectly impacted components will be identified as a result of applying the above iteratively to any directly and indirectly impacted components that have been identified previously.

The scope of the change is the set of changed, directly impacted and indirectly impacted components identified when the iteration identifies no new components.

(d) The context in which the changed service is intended to be provided (see ATM/ANS.OR.C.005(a)(1)(iii)) includes the interface through which the service will be delivered to other service providers.

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

ED Decision 2017/001/R

TRAINING

If the change modifies the way people interact with the rest of the functional system, then they will require training before the change becomes operational. Care should be taken when training operational staff before the change is operational, as the training may change the behaviour of the operational staff when they interact with the existing functional system before any other part of the change is made, and so the training may have to be treated as a transitional stage of the change. For example, as a result of training, ATCOs may come to expect information or alerts to be presented differently. People may also need refreshment training periodically in order to ensure that their performance does not degrade over time. The training needed before operation forms part of the design of the change, while the refreshment training is part of the maintenance of the functional system after the change is in operation.

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

ED Decision 2017/001/R

INTERACTIONS

The identification of changed interactions is necessary in order to identify the scope of the change because any changed behaviour in the system comes about via a changed interaction. Changed interaction happens via an interaction at an interface of the functional system and the context in which it operates. Consequently, identification of both interfaces and interactions is needed to ensure that all interactions have identified interfaces and all interfaces have identified interactions. From this, all interactions and interfaces that will be changed can be identified.

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

ED Decision 2017/001/R

FORM OF ASSURANCE

Service providers other than air traffic services providers should ensure that the assurance is documented in a safety support case.

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

ED Decision 2017/001/R

COMPLETENESS OF THE ARGUMENT

The argument should be considered complete when it shows that:

(a) the safety support assessment of ATM/ANS.OR.C.005(b) has produced a service specification and context specification where:

(1) the service has been defined in terms of functionality, performance and the form of the interfaces;

(2) the specification of context correctly and completely records the conditions under which the specification of the service is true;

(3) the interaction of components, under failure conditions or failures in services delivered to the components, have been assessed for their impact on the service and, where necessary, degraded modes of service have been defined; and

(4) the specification encompasses the interaction with the environment;

(b) safety support requirements have been placed on the elements changed and on those elements affected by the change;

(c) the behaviour necessitated by the safety support requirements is the complete behaviour expressed by the service specification;

(d) all safety support requirements have been traced from the service specification to the level of the architecture at which they have been satisfied;

(e) each component satisfies its safety support requirements; and

(f) the evidence is derived from known versions of the components and the architecture and known sets of products, data and descriptions that have been used in the production or verification of those versions.

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

ED Decision 2017/001/R

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.

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

ED Decision 2017/001/R

DETERMINATION OF THE SPECIFICATION OF THE CHANGED SERVICE

When determining the changes in the service specification that have resulted from the change to the functional system, service providers other than air traffic services providers should ensure that:

(a) the properties specified for the service can be observed and measured either directly or indirectly with a degree of certainty commensurate with the level of confidence sought from assurance; and

(b) the specification of the changed service must cover everything that has changed in the service provided when operated within the declared operational context.

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

ED Decision 2017/001/R

DETERMINATION OF THE OPERATIONAL CONTEXT FOR THE CHANGE

(a) When determining the operational context for the change, service providers other than an air traffic services provider should ensure that:

(1) the specification of the operational context can be shown to be true for all circumstances and environments in which the changed service is intended to operate;

(2) the operational context is completely and coherently specified; and

(3) the specification of the operational context is internally consistent.

(b) The operational context must be specified so that its adherence to (a)(1) and (a)(2) is observable and measurable either directly or indirectly with a degree of certainty commensurate with the level of confidence sought from assurance.

AMC5 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

(a)  When a change to a functional system includes the introduction of new software or modifications to existing software, the service provider should ensure the existence of documented software assurance processes necessary to produce evidence and arguments that demonstrate that the software behaves as intended (software requirements), with a level of confidence consistent with the needs of the required application.

(b)  The service provider should use feedback of software experience to confirm that the software assurance processes are effective and, when used, the allocated software assurance levels (SWALs) and the rigour of the assurances are appropriate. For that purpose, the effects from 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) reported according to the relevant requirements on reporting and assessment of service occurrences should be assessed in comparison with the effects identified for the system concerned as per the service specification demonstration.

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

GM1 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 PROCESS

(a)  The term ‘correct and complete software verification’ is understood to be all software safety requirements, which correctly state what is required of the software component by the risk assessment and mitigation process and their implementation is demonstrated to the level required by the software assurance level.

(b)  The term ‘software timing performances’ is understood to be the time allowed for the software to respond to given inputs or to periodic events, and/or the performance of the software in terms of transactions or messages handled per unit time.

(c)  The term ‘software capacity’ is understood to be the ability of the software to handle a given amount of data flow.

(d)  The term ‘software accuracy’ is understood to be the required precision of the computed results.

(e)  The term ‘software resource usage’ is understood to be the amount of resources within the computer system that can be used by the application software.

(f)  The term ‘software robustness’ is understood to be the behaviour of the software in the event of unexpected inputs, hardware faults and power supply interruptions, either in the computer system itself or in connected devices.

(g)  The term ‘overload tolerance’ is understood to be the behaviour of the system in the event of, and in particular its tolerance to, inputs occurring at a greater rate than expected during normal operation of the system.

(h)  The term ‘software life cycle data’ is understood to be the data that is produced during the software life cycle to plan, direct, explain, define, record, or provide evidence of activities; this data enables the software life cycle processes, system or equipment approval and post-approval modification of the software item.

(i)  The term ‘COTS’ is understood to be a commercially available application sold by vendors through public catalogue listings and not intended to be customised or enhanced.

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.

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.

GM4 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 — EXAMPLES OF EXISTING INDUSTRIAL STANDARDS

(a)  The service provider is responsible for the definition of the software assurance processes. In this definition of processes, the service provider may consider the guidance material contained in existing industrial standards for the software assurance considerations of software. It should be considered that not all standards address all aspects required and the service provider may need to define additional software assurance processes. The guidance material typically includes:

(1)  objectives of the software life cycle processes;

(2)  activities for satisfaction of those objectives;

(3)  descriptions of the evidence, in the form of software life cycle data, that indicates that the objectives have been satisfied;

(4)  variations according to the SWAL, to accommodate the different levels of rigour of the software assurances; and

(5)  particular aspects (e.g. previously developed software) that may be applicable to certain applications.

(b)  The following table presents some of the existing industrial standards (at the latest available issue) used by the stakeholders:

EUROCAE ED-109A/RTCA DO-278A and EUROCAE ED-12C/RTCA DO-178C make reference to some external documents (supplements), which are integral part of the standard for the use of some particular technologies and development techniques. The supplements are the following:

(1) Formal Methods Supplement to ED-12C and ED-109A (EUROCAE ED-216/RTCA DO-333)

(2) Object-Oriented Technology and related Techniques Supplement to ED-12C and ED-109A (EUROCAE ED-217/RTCA DO-332)

(3) Model-Based Development and Verification Supplement to ED-12C and ED-109A (EUROCAE ED-218/RTCA DO-331)

When tools are used during the software development lifecycle, EUROCAE ED-215/RTCA DO330 ‘Software Tool Qualification Considerations’ may be considered in addition to EUROCAE ED12C RTCA/DO-178C and EUROCAE ED-109A/RTCA DO-278A.

(c)  The definition of the software assurance processes may be based on one of these industrial standards, without combining provisions from different standards as far as the consistency and validation of each of the industrial standards have only been performed at individual level by each specific standardisation group.

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

ED Decision 2017/001/R

SPECIFICATION

‘Continue to behave only as specified in the specified context’ means that assurance needs to be provided that the monitoring requirements are suitable for demonstrating that the service behaves only as specified in the specified context during operation.

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

ED Decision 2019/022/R

ASSURANCE LEVELS

(a) The use of assurance level concepts, e.g. design assurance levels (DALs), software assurance levels (SWALs), hardware assurance levels (HWALs), can be helpful in generating an appropriate and sufficient body of evidence to help establish the required confidence in the argument.

(b) The term ‘software assurance level (SWAL)’ is understood to be the level of rigour of the software assurances throughout the software lifecycle. In this context, the software life cycle is understood to be:

(1) an ordered collection of processes determined by an organisation to be sufficient and adequate to produce a software item;

(2) the period of the time that begins with the decision to produce or modify a software item and ends when the item is retired from service.

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

ED Decision 2017/001/R

SAFETY SUPPORT REQUIREMENTS

The complete behaviour is limited to the scope of the change. Safety support requirements only apply to the parts of a system affected by the change. In other words, if parts of a system can be isolated from each other and only some parts are affected by the change, then these are the only parts that are of concern and so will have safety support requirements attached to them.

The following list contains examples, not exhaustive, of safety support requirements that specify:

(a) for equipment, the complete behaviour, in terms of functions, accuracy, timing, order, format, capacity, resource usage, robustness to abnormal conditions, overload tolerance, availability, reliability, confidence and integrity;

(b) for people, their performance in terms of tasks (e.g. accuracy, response times, acceptable workload, resilience to distraction, self-awareness, ‘team-playerness’, adaptability, reliability, confidence, skills, and knowledge in relation to their tasks);

(c) for procedures, the circumstances for their enactment, the resources needed to perform the procedure (i.e. people and equipment), the sequence of actions to be performed and the timing and accuracy of the actions; and

(d) interactions between all parts of the system.

AMC1 ATM/ANS.OR.C.005(b)(1) Safety support assessment and assurance of changes to the functional system

ED Decision 2017/001/R

VERIFICATION

The service provider other than the air traffic services provider should ensure that verification activities of the safety support assessment process include verification:

(a) that the full scope of the change is addressed throughout the whole assessment process, i.e. all the elements of the functional system or environment of operation that are changed or affected by the change and those unchanged elements that depend upon them and on which they depend are identified;

(b) that the way the service behaves complies with and does not contradict any requirements placed on the changed service by another part of the regulations or conditions attached to the providers’ certificate;

(c) that the specification of the way the service behaves and the safety support requirements are complete and correct;

(d) that the specification of the operational context is complete and correct;

(e) that the specification was analysed in the context in which it is intended to operate;

(f) of the completeness of the argument as per AMC2 ATM/ANS.OR.C.005(a)(2);

(g) that the safety support requirements are correct and complete by reference to the specification; and

(h) to the intended degree of confidence, that the implementation satisfies the safety support requirements and behaves only as specified in the given operational context.

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

ED Decision 2017/001/R

DESCRIPTION OF THE SCOPE — ‘MULTI-ACTOR CHANGE’

In the case where the change is a ‘multi-actor change’ in reference to ATM/ANS.OR.A.045(e), the interfaces and interactions include the interfaces with the other service providers and/or aviation undertakings that are also affected by the change.

Information related to cooperatively identifying the scope of ‘multi-actor changes’ may be found in EUROCAE ED-78A.

GM2 ATM/ANS.OR.C.005(b)(1) Safety support assessment and assurance of changes to the functional system

ED Decision 2017/001/R

VERIFICATION

This requirement is seeking verification because it is a simple cross-check of available material, i.e. that the specification reflects the requirements of other parts of this Regulation.

(a) Behaviour

ATM/ANS.OR.C.005(b)(1)(ii) requires that the service meets its specification. Consequently, the specification must be complete and valid, i.e. it includes the behaviour addressed in ATM/ANS.OR.C.005(b)(1)(iii) and any additional behaviour in the specified context.

(b) Compliance with other requirements

(1) ATM/ANS.OR.C.005(b)(1)(iii) requires the service providers to identify all parts of this Regulation that impose behaviour on the changed service and also includes any conditions attached to the certificate. They have to identify only those parts of this Regulation that describe required behaviour relevant to the changed service. The identified behaviour shall be included in the specification of the changed service.

Note that the Regulation or conditions attached to the certificate may render compliance with technical standards and ICAO SARPs mandatory.

(2) Compliance with other non-mandatory standards may also be a necessary condition for other reasons.

(3) ATM/ANS.OR.C.005(b)(1)(iii) does not state that the service only meets the requirements of the other parts of this Regulation. It may do other things as well, as described in (5) below.

(4) In ATM/ANS.OR.C.005(b)(1)(iii), ‘does not contradict’ is used to express the concern that behaviour beyond that required by a standard might cause the behaviour required by the standard to be undermined.

(5) The behaviour of a service is likely to include behaviour unspecified in standards; such behaviour may come from:

(i) the behaviour of degraded modes of operation;

(ii) additional behaviour not required by the standard, but put there for commercial purposes, e.g. competitive edge; or

(iii) other behaviour identified by the customer, e.g. an air traffic services provider.

(6) Consequently, the total behaviour should be specified.

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

ED Decision 2017/001/R

MONITORING

Service providers other than an air traffic services provider should ensure that within the safety support assessment process for a change, the monitoring criteria that are to be used to demonstrate that the safety support case remains valid during the operation of the changed functional system, i.e. that the changed service continues to meet its specification, are identified and documented. These criteria should be such that:

(a) they indicate that the assumptions made in the safety support case remain valid; and

(b) if the properties being monitored remain within the bounds set by these criteria, the service will be behaving as specified.

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

ED Decision 2017/001/R

MONITORING OF INTRODUCED CHANGES

(a) Monitoring is intended to maintain confidence in the safety support argument during operation of the changed functional system. Monitoring is, therefore, only applicable following the entry into service of the change.

(b) Monitoring is likely to be of internal parameters of the functional system that provide a good indication of the performance of the service. These parameters may not be directly observable at the service level, i.e. at the interface of the service with the operational environment. For example, where a function is provided by multiple redundant resources, the availability of the function will be so high that monitoring it may not be useful. However, monitoring the availability of individual resources, which fail much more often, may be a useful indicator of the performance of the overall function.