Digitising Flight Progress Strip Displays

  • Home 2016 Digitising Flight Progress Str....

Digitising Flight Progress Strip Displays

55TH ANNUAL CONFERENCE, Las Vegas, USA, 14-18 March 2016

WP No. 160

Digitising Flight Process Strip Displays

Presented by TOC

Summary

The paper-based Flight Progress Strip is an old and venerable tool of our trade, but it is getting to the end of its lifecycle. This paper aims to chart the possibilities for replacement, the new opportunities that these replacements offer, but also to consider the potential difficulties and hazards associated with replacing the paper flight strip.

Introduction

1.1 The Flight Progress Strip has been in use in ATC for decades. It serves multiple purposes. Mainly, it is the carrier of crucial information about a particular flight. It is also a reminder of traffic under the ATCO’s control. It is a notepad to keep track of issued clearances or other relevant information regarding the flight. It can be used to alert the controller that (potential) conflicts exist between two or more flights under their control. During handovers, it is a physical reminder that a flight has been transferred from one controller’s responsibility to another.

(Paper strips at YMML tower)

1.2 Data recorded on the strip only passes from user to user when the strip is handed over. A large advantage of managing strip data electronically is that relevant information can be passed directly to other operational users, which may be further ahead or even outside the natural workflow. In this way they have improved situational awareness and can adjust their plans accordingly.

1.3 Around the world, systems are being (and have been) implemented that replace the paper flight strip. Although the technology has existed for around 20 years, the use of it has not been very widespread. Recently the rate of spread and implementation has increased. Having the data entered on the strip available electronically, allows for significant new features to be implemented, ranging from safety features to functions that increase ATC capacity. It also enables information sharing with external systems and airport processes.

Discussion

2.1 General

2.1.1 There are two widely used ways of transitioning from paper strips to electronic strips. One transfers the data from paper strip to a label on the controller’s surveillance scope. These systems represent the relevant information in compact labels on the screen and allow the ATCO to edit the label with new clearances, keeping all the information that is necessary directly in the controller’s field of vision as they are working their sector. This is widely known as the ‘stripless’ approach. This paper will touch on this subject lightly.

2.1.2 Another possibility is to replace paper strips one-on-one with electronic strips. For Towers, this is often the only possibility, as in general, not all operations can be made visible and labelled on a surveillance display all the time. These electronic strips have a similar appearance as paper strips and can also be arranged in bays, just as their paper counterparts are. Inputs on the strips are possible through touch-enabled screens, operated by finger or stylus/pen or via keyboard and mouse as preferred. Of course it is also possible to produce a new representation based on the capabilities of the EFS system, in which case the workflow and layout of the strips is changed during the transition, rather than keep the established practices for paper going. The paper will focus mostly on this version of digitised flight strips.

(EFS Stripboard at EETN)

2.1.3. There might also be drawbacks to working with electronic flight strips. For example, if alerts are implemented poorly they might become a hindrance rather than an asset. If the user interface is cumbersome and/or complicated, EFS systems might increase head-down time, or the time needed to complete an operation. There is a good reason that pen and paper are still available at most controller working positions. Contingency is also an issue which must be considered carefully. In case of EFS system failure, the most obvious remedy would be to fall back on paper strip usage. It may be difficult however to maintain an adequate level of training for controllers to utilise paper strips effectively over the years in which case a degradation might lead to severe capacity restraints and in a worst case scenario an airspace closure.


2.2. Information in EFS

2.2.1.  Flight progress strips’ primary function is to serve as an information carrier. The information they carry vary from unit to unit and ANSP to ANSP, as required, although some items are omnipresent. In an electronic flight strip system, it should become easier to manage data entered on the strips and distributing it to relevant other parties. Instead of having to physically pass the strip, or pass the information verbally, the system could (and should) do this for you. This would eliminate the need for controllers and/or FDOs (Flight Data Officers) to spend much of their time coordinating as the standard coordination now happen automatically. The EFS system acts as an information hub and controllers have more time to focus on their actual job, separating aircraft.

2.2.2.  There might be situations where one controller in a unit writes information on a strip which is useful for their role or sector, but the next position doesn’t need. On a paper strip this information remains and takes up valuable real estate on the strip. On an electronic strip, this information could be removed easily as required.

2.2.3.  In addition, an operational user may not need all the information printed on a paper strip. This can be the case in an environment where different operational roles use the same copy of a paper strip. In an EFS system, the information that is not necessary for a particular role can be hidden, in order to reduce clutter on the strip. The information should still be available through interaction, but only the most relevant information should be displayed. Operational users should have the final say in what is presented to them on their working positions.

2.2.4.  If the system has a two-way interface with the flight plan database, it could also amend the flight plan according to clearances issued and distribute this information to relevant units along the way. It is important to note that once a flight strip is in use that the system should not make alterations to the information on the strip without alerting the user, assuming that all the information displayed is relevant to the current traffic situation. Controllers rely on the information on the strip being correct and consistent and any change without notice could create a hazard.

2.2.5.  EFS systems can make CPDLC, FANS-1A and pre-departure clearance/ACARS interaction easier. If EFS integrates these functions, there is no need for parallel user interactions to operate these other systems, as sending the message could be as simple as clicking a button on the strip.

2.2.6. EFS systems can be of great help while interfacing with Departure and Arrivals Management systems. As estimated times are electronically available, these could be shared automatically with planning tools, making the process of planning inbound and outbound sequences much quicker, easier and more efficient.

2.2.7 Having information available in the electronic environment can facilitate easy interaction with a host of other systems. From pure ATC functionality to terminal passenger information displays. More important though are safety net features, which we will discuss below.


2.3 Safety Net Features

2.3.1.  The most advanced versions of EFS systems offer integration with entire ATS suites, which incorporate links to surveillance data. This allows for the system to provide alerts for various incidents. Non-adherence to clearances, runway incursions, the crossing of an ignited stop bar etc.

2.3.2.  In many locations systems have been implemented that make use of the downlink of pilot selected level through mode S. They link the cleared level that the ATCO has entered in the system and the level the pilot selects in the cockpit. The label on the scope now provides a visual cue if there is a mismatch between cleared level and pilot selected level allowing for a significant reduction in level busts and losses of separation in the administered airspace.

2.3.3.  IFATCA policy is:

Conflict Detection Tools (CDTs) are computer based Controller Tools that identify conflicts and then provide system generated conflict advice to controllers.

CDTs can provide conformance monitoring to ensure that aircraft comply with instructions issued to resolve a detected conflict.

Responsibility and legal implications should be fully addressed before implementation of CDTs.

During degraded modes, clearly defined operational procedures must exist. Nuisance and false alerts must be kept to an absolute minimum.

(IFATCA Technical and Professional Manual – ATS 3.20. – Page 3 2 3 21)

 

This policy is relevant as EFS systems might allow for a feature where a controller is alerted when issuing a clearance which appears to be in conflict with other traffic. For example: a runway check is in progress. The controller has placed a vehicle strip in the runway bay. When inputting a take-off clearance on a flight strip in the same runway bay subsequently, the system might caution the user that there is a strip which conflicts with the issued clearance. Of course, the controller should always be able to override the system, and the system cannot prevent the controller from issuing the clearance by voice regardless. It might, however, prevent a fatal mistake from occurring.

2.3.4.  STCA and MTCD are also often integrated into stripless surveillance environments, in order to aid the controller as a memory back-up. There is some discussion over the usefulness of STCA as a tool, rather than a safety net. From a safety point of view, TOC believes that use of STCA as a tool is not desirable.

2.3.5.  If the EFS system is linked to surveillance data (A-SMGCS), the system could remove or place strips in the runway bay as detected. It could potentially also alert the controller to non-adherence to issued clearances, if they are properly recorded in the system. A system like this should be subject to rigorous quality and design requirements, as false occupancy or non-detection of occupancy could have very serious consequences. A feature that moves strips of its own accord might not be desirable as it might encourage assumptions and mistakes. A visual warning that requires acknowledgement by the user might be preferable. At the very least a system with such a feature should always be able to be overridden by the user in case of error. Systems of the sort are already in development, and early versions are operational.


2.4. Implementation and Transition

Adopting electronic flight strips or a stripless system requires a significant redesign of the Controller Working Position (CWP).

2.4.1. At conference in Kathmandu, 2012, the following policy was adopted:

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

  • Establish user requirements.
  • Determining operational training requirements before implementation.
  • To participate in the risk assessment process.
  • To validate the system.
  • To provide feedback in the further development of the system.

(IFATCA Technical and Professional Manual – AAS 1.13. – Page 3 2 1 18)

 

This policy is relevant to the implementation of EFS systems, although sadly, this principle is still ignored in projects the world over.

2.4.2.  Systems that are implemented without design input and rigorous validation by the end users are invariably flawed. They tend to miss out on opportunities to make ATCOs lives easier and often include features that subsequently turn out to be useless or may even create a hazard in the overall ATM system.

2.4.3.  TOC and PLC jointly presented a paper on the process of screen design at the IFATCA conference in Sofia in 2015. The Executive Board of IFATCA was tasked to develop principles for on-screen alerts and the display of operational information. These principles would be of great help to projects implementing a large change like an EFS system because they would apply to the HMI of the system. More generally, there is currently no guidance material available for ANSPs that want to implement EFS systems, aside from that which is provided by manufacturers. Principles and best practices provided by an organisation like ICAO or IFATCA would be of great use to ANSPs transitioning to a new operational environment.

2.4.4.  There have been reports of increased head-down time directly after implementation, due to HMI issues that could have been resolved before installation of the system. If proper input from operational end users is not sought, however, systems will inevitably have avoidable HMI flaws.

2.4.5.  IFATCA policy is:

The stop bar HMI design, location, implementation and automation should prevent an unacceptable increase of workload, distraction and head down operations.

(IFATCA Technical and Professional Manual – ADME 2.12 – Page 3 2 2 15)

 

Even though this policy is nominally about stop bars, it should apply to any system that the controller is required to interact with. Integration of stop bar controls in EFS systems is a feature most manufacturers offer as well as other integrated functions that would reduce the number of different HMIs controllers have to interact with. This offers benefits, but also makes the design qualities more important, since the user will only interact with one. It was decided that a general policy on HMI design would be ineffectual at achieving our goals, and that policy AAS 1.13 mentioned above covers the necessary ground.

2.4.6.  EFS and stripless systems reduce clutter and noise, resulting in a more tranquil and focused environment. Towers in particular seem to benefit from this effect.

2.4.7.  Transitional training for operational controllers can be a complicated issue. In the case of towers, most ANSPs do not have the resources to run two towers at the same time, or create enough spare positions to run shadow operations. More often, operational controllers will have to train in a simulated environment on a prototype version of the system to be implemented in reality, before being thrown in at the deep end. If this is the case, traffic restrictions may be necessary when the new system goes live, in order to ease the transition.

2.4.8. At units where EFS or stripless systems are implemented, there is a risk of increased head down time while controllers adjust to the new situation. Of course this situation is not ideal and it could be a hazard if controllers are not fully comfortable with and aware of the workings, capabilities and limitations of the new operational environment.

2.4.9 It is advisable to convert spare positions first, so that the controllers can acquaint themselves with the reality of the new environment before operating in it.


2.5. Degradation and Contingency

The risks of failure of an EFS or stripless system must be carefully considered before committing to implementation as failure of the display of operation information or degradation of the reliability of the information could have serious safety and capacity repercussions.

2.5.1.  Especially in cases where digitised flight strip displays are highly integrated with other functions of the ATM system at the unit in question, it is important to have robust redundancy and back-ups to existing systems and procedures to prevent a catastrophic failure in case of system degradation.

2.5.2.  In case of total failure of the information display, the most obvious answer would seem to be to fall back to the use of paper strips. In practice, it can prove difficult to maintain operational currency on the use of paper as it is hard to maintain an adequate level of training in the use of paper strips. Especially new personnel that was only trained after the electronic version was implemented would have great difficulty working in a situation that requires the use of paper strips.

2.5.3.  If a unit is working with digitised flight strip displays, it is safe to assume that a majority of the coordination with other units has also been digitised as all relevant information should be available electronically. In case of a failure of the EFS system which affects the availability or reliability of said information, it might be the case that coordination must now be performed by older links or even by voice. In high density airspace, this could lead to an increase in the workload that may require significant restrictions to traffic, in order to keep operations manageable.

2.5.4.  Controllers must have the resources to deal with an unexpected system degradation in a safe manner.

2.5.5. It is advisable to spread the risk of failure over several systems or isolated components, so that there can be no single point of failure which destabilises the entire operation. Not all contingencies (e.g. power outage) can be covered in this way however, and robust degradation procedures are of the utmost importance no matter the reliability of the system in question.

Conclusions

3.1  Paper Flight Strip replacements have been in existence for quite some time, but have recently begun to become much more commonly used around the world.

3.2  There are generally two ways in which the paper flight strip can be digitised. Either by a stripless system in which the required information is available on a radar scope, or a one-on-one analogous system where a screen displays electronic versions of paper strips.

3.3  Digitised Flight Strip systems provide extensive possibilities to increase capacity at any unit. Integrated coordination and planning functions can reduce controller workload by significant amounts. Information becomes more easily manageable as it is available electronically and can be distributed more effectively among all relevant parties.

3.4.  Digitised Flight Strip systems can be fitted with safety net features as well. It is paramount that these safety net features are rigorously designed and tested and do not constitute any new hazards. Before implementation, responsibility and legal ramifications must be fully clear, to ensure that controllers can perform their duties without reservations. Controllers should always remain in control of the decision making process.

3.5.  Existing IFATCA policy relating to design and implementation is fully applicable to EFS and stripless systems (namely AAS 1.13 and ADME 2.12). In order to ensure functionality, safety and workability, controllers must be consulted during the design and implementation phase of the new system.

3.6.  During implementation and transition, special care must be extended to ensuring controllers are comfortable working with the new tools and their new operational environment to ensure that safety standards remain as high as before.

3.7.  In the highly automated environment that the EFS or stripless system exists in, robust redundancies and back-up procedures must be in place, in order to guarantee safe operations in case of an unexpected system degradation. Controllers must always have the resources to perform their duties and ensure safety of traffic under their control.

3.8.  In recognition of the fact that there is currently no guidance material available for ANSPs and controllers involved in the implementation of Digitised Flight Strip Systems, and referring to last year’s Screen Design Process paper by PLC and TOC, TOC believes that principles and best practices on the adoption of such a system should be available.

Recommendations

It is recommended:

That the EB is tasked to publish principles and best practices on the implementation of digitised flight progress strip displays.

References

IFATCA Technical and Professional Manual

ICAO Annex 11, Air Traffic Services

With contributions from:

Jan Fait, TWR/APP controller in Prague, Czech Republic

Blaž Gorican, ACC/APP controller in Ljubljana, Slovenia

Tim Kerr, TWR/APP controller in Melbourne, Australia

Last Update: October 1, 2020  

January 23, 2020   135   Jean-Francois Lepage    2016    

Comments are closed.


  • Search Knowledgebase