1.4 This paper aims to analyse IFATCA policy related to the integration of Human Factors in new systems with the objective of better influencing such changes within ATM.

2.5.2  The Human Factors Case has been developed to provide a comprehensive and integrated approach to ensure that the design of a technical, human, and/or procedural system can deliver the desired performance improvements. It is consistent with E-OCVM (European Operational Concept Validation Methodology – E-OCVM has become a standard for European projects (ratified by European Commission) and been adopted by SESAR) aims and objectives and is designed to be simple, practical and effective, describing users (not only HF specialists) who does what, what documents to use and to produce, how to produce these documents and when.

2.5.3  The HF Case has five specific stages:

Stage 1 – Fact Findings and scoping

This stage collects the necessary information to scope the project, and get an appropriate level of understanding to start considering human factors matters relevant to the project, including interactions between operational environment, working environment, people, procedures and equipment.

Stage 2 –Benefits and issues generation

The goals of this stage are to identify the project specific HF benefits and issues, identify their potential impact, prioritise them and propose idea(s) for mitigation.

Human Factors benefits are potentially positive HF consequences of the new concept/system/tool that should be verified and/or validated, while Human Factors issues are potentially negative HF consequences that need further investigation or mitigation.

Stage 3 – Mitigation planning and benefit clarification

The main goal of this Stage is to refine and finalise the information generated in Stage 2 by bringing together the list of issues, mitigations and benefits with existing expertise, experience and knowledge of Human Factors matters. While elaborating and refining the most important issues and benefits generated during Stage 2, some human factors investigations will be required; this will also rationalise and validate the information gathered.

Stage 4 – HF requirements and validation needs

The objectives of this Stage are:

To derive the HF design requirements that accommodate the issues and their associated mitigations and identify the validation evidence that is required to demonstrate these are achieved,

Based on the benefits identified in Stage 3; to define the significant benefits to the system performance and identify the validation that is required to demonstrate these are achieved.

Stage 5 – HF Case monitoring, management and control

This Stage may be seen as a transversal stage that is conducted in parallel to the core process of the case (Stages 1 to 4). Its purpose is to:

Ensure the quality and the completeness of Stages 1 to 4 through the systematic review step as the HF Case progresses

Collect and integrate information for external use, e.g. any information contributing to the Safety Case or to the Business Case

Be used to build a body of evidence to show that (and how) HF has been integrated into the planning/design process

Ensure regular reporting, traceability of iteration and adequate level of evidence for the stage of development of the concept

Allow the opportunity to identify missing elements by reviewing – with the project manager (or delegated expert) – each stage prior to completion of HF Case

Provide a mechanism for extracting management related information that can be used to provide assurance that HF issues are being thoroughly considered

2.6.3  This effect, defined by Edward Thorndike in 1920s as a “…tendency to think of the person in general as rather good or rather inferior and to colour the judgments of the qualities by this general feeling”, is very important for a change management because it is widely demonstrated that ATCOs’ behaviours (as human in general) are heavily influenced by their perceptions of the system and of its environment. Although in ATM, behaviour is particularly (and desirably) subject to the external constraints of operating procedures (neither the pilot nor controller has autonomy of action, but is subject to the evolving constraints of the strategic and tactical control environment). The theory of Planned Behaviour uses and confirms this effect aiming to predict deliberated behaviour in the context of (perceived) control.

2.6.4  The Theory of Planned Behaviour uses three basic constructs as ‘predictors’ of the intention of an individual carrying out a desired action:

• ‘attitude’ (a favourable disposition towards the action),
• ‘subjective norm’ (perceived social pressure to take the action), and
• ‘perceived behavioural control’ (whether the individual feels in control of the process of action).

2.6.5  During the study, the Theory of Planned Behaviour constructs was integrated with the Seven Stages of Change model. These stages (see Figure 3) represent the theoretical, cognitive and conative ‘process’ through which an individual may move from one type of behaviour to another. The study states that in order to successfully implement change in ATM, it is necessary to appreciate that all types of change require some type of ‘buy-in’ to work. This does not just mean accepting that a change needs to take place, or accepting some responsibility, or recognising some benefits as these alone are insufficient, but all actors of the change should be fully motivated towards the new process.

2.6.9 In view of these requirements, it becomes clear that differentiated training measures for executives in the field of change management are more necessary than ever. In order to be able to deal successfully with change on an almost daily basis, it is vital for an executive not to be just superficially concerned with strategies or measures, but to understand the background issues, i.e. essential psychological processes and emotions (Gerkhardt and Frey 2006). Only when these are internalised does it become possible to successfully realise the expected achievement (change).

2.7 IFATCA policy

IFATCA policy statements relevant to the topic are the following:

2.7.1

2.7.2

2.7.3

2.8 Human factors integration in IFATCA policy

2.8.1  As shown, IFATCA states that training related to the use of new systems is fundamental and it shall include Human Factors aspects of automation; however, the statement related to the ATCO roles in the design, development and implementation of such systems does not consider training. It is the opinion of the PLC that this list should be amended as follows:

Operational controllers shall be involved in the design, development and implementation of new ATM systems. Their role shall include:

• establishing user requirements.
• defining operational training requirements prior to implementation.
• participating in the risk assessment process.
• validating the system.
• providing feedback in the further development of the system.

2.8.2  Moreover, IFATCA 12 WP No 87 “ Determining operations readiness of new ATM systems”, §2.4.3, states that:

To integrate human factors the development team should include people with the following profiles:

• system developers, typically software engineers;
• end-users, usually the operational controllers, supervisors and maintenance engineers;
• managers responsible for directing the development process;
• human factors specialists, who participate to ensure the integration of human factors.

2.8.3  However, this is still not included in IFATCA Technical and Professional Manual. Nevertheless, the analysis conducted in 2012 can be useful to supplement what is already stated by IFATCA policy statements. Specifically IFATCA policy (§2.5.1) requests practitioners able to provide

“…proof that the combined automated/human systems can operate safely at the levels of workload predicted, and to be able to satisfactorily manage normal and abnormal occurrences….”

and to identify and define

“…The legal aspects of a controller’s responsibilities…”.

Therefore, to integrate human factors, the design, development and implementation team must be heterogeneous and should include, at least, people with the following profiles:

• system developers – typically software and hardware engineers (- should normally be those responsible for the technical design of the product with the goal to merge all inputs received from the team into a technically achievable system);
• project managers, responsible for directing the development process, for taking decisions and coordinating the team members, having in mind the expected results;
• end-users – usually the operational controllers, supervisors and ATSEPs (Air Traffic Safety Electronics Personnel) – are the experts of their working environment. They are the ones able to understand what is helpful to achieve their tasks and what is not;
• human factors specialists with experience in the management of change, responsible for ensuring the integration of human factors;
• legal experts, responsible for adapting the product to the legal environment;
• safety specialist, who assess the safety impact of the system.

2.8.4 Each element of the list has its unique value in the process because it represents a different perspective, background, training and expectation; what could be easily recognised by one element may not be readily identified by the others. All team members must collaborate proactively, respecting the role of the others and their contributions because they are complementary to provide the holistic approach needed for the introduction of a new ATM system.

2.8.5 Human factors specialists would certainly play the most important role in the integration of human factors into new systems, nevertheless the participation of all practitioners listed is fundamental because at the end front-line operators will use the new equipment/tool, facing all the aspects characterising their environment. Therefore, elements such as operators’ concerns related to possible legal implications or related to safety, for example, can heavily affect its use.

2.9 Intrinsic vs tactical safety

2.9.1 IFATCA defines intrinsic and tactical safety, respectively as:

• Safety aspects inherent to the design of the system;
• Safety aspects related to the application of procedures and to the adoption of defences, where the design of the system is inadequate to achieve a given safety level.

2.9.2  This implies, as stated during the 47th IFATCA Annual Conference in Arusha (2008) (47th IFATCA Annual Conference – Agenda item C.6.9 – “Investigate the professional aspects of the difference between intrinsic and tactical safety in the aerodrome domain” (Working Paper presented by PLC)), that tactical safety relies on fallible means because it is based on mitigation measures for unsafe conditions, while intrinsic safety is based on the elimination of any possible hazard during the design phase of a system.

2.9.3  Therefore, the previously mentioned list would certainly contribute to obtaining a system as intrinsically safe as possible, proposing a holistic approach able to identify and solve problems early in the system life-cycle, and to reduce the need to adopt corrective actions (tactical measures) later. Ultimately, the adoption of the list mentioned in §2.8.3 would facilitate the new system/tool’s safe implementation and future usage.