Software-related functional errors can impact the safety of air traffic control services. The complexity of functional errors is related to the uncertainty attached to their appearance.
Before proceeding with details about a Functional Error I will like to bring your focus for a while toward the fact that Air Traffic Control Services are heading towards fully automated monitoring and control.The same is the case with the job of ATSEP as both jobs seem to be converging in the context of a highly structured and well-monitored working environment. It is expected that revolutionary changes are going to eliminate the need for physical intervention both for ATCO as well as for ATSEP. But we should not forget according to Kurt Lewin’s Change model, during the transition phase the change is taking place hence during it both sets of systems coexist.
To implement the EU’s ATM Master Plan, the current technological environment was unfreezed.Then we have a transition phase through which we are passing by and after successful completion the change process will be freezed again or refrozen. More or less ATSEP will be faced with the same challenge. They will be provided with a newer environment to operate in that will be highly sophisticated and more service-oriented as compared to the previous one. But in case of failure of the support system ATSEP will have to be skilled enough to come forward and make a physical intervention for rectification of error with the system.
Although it is never expected in case of failure of the control system a back system will always be there. But in order to avoid catastrophic conditions due to total system collapse as an alternate choice the old validated system will be there for support. It is the same scenario for which Air Traffic Control Officers are trained for procedural control even knowing that it is an old technique of controlling traffic without the support of radar.
As we all are now aware of the European Air Traffic Management Master Plan. The first Phase of change is planned to last till 2025 that is aimed at enhancing capacity. This phase of change is related to infrastructural changes to ensure better interoperability among different systems not only within the premises but across borders. This requirement of interoperability at a wider level confirms more probability of catastrophic impact of errors. Hence there is a need to understand all of such errors and their prompt rectification to limit the impact.
The first Phase of the transition requirement of System capacity building has brought System Monitoring and Control out of the fragmented approach towards unified Monitoring services where all systems are monitored simultaneously. This will be possible as systems are more sophisticated and based on service-oriented programming that brings different service-related aspects under one roof of System Monitoring and Control Services. ATSEP apparently has nothing to do with errors related to software but there are scenarios where their physical intervention will be required for prompt rectification of errors when the automated system will not rip any fruit. In the new era, The Air Traffic Control System is supported by different software. These are normally based on service-oriented programming.
The current ATSEP will be living in a parallel paradigm due to the first phase of change. Hence the presence of support from other software will be coexisting even in presence of a fully service-oriented program due to multiple reasons like adherence to the old system as backup, transition phase of change, etc. Supplementary types of software are being integrated to provide supplementary support to the system as a whole. Such supplementary support software includes Air Traffic Services Revenue Management System and docking system. These types of software are properly integrated with each other at the stage of synchronization. Imagining such a network of software working around the Air Traffic Control Environment the ATSEP should never forget that there are ample chances of their interaction with errors related to this whole system of software.
Even after the successful implementation of change, we cannot undermine the probability of such errors to occur.
There are different functions within the software. These functions are specific in terms of their functionalities. Sometimes a feature of software or an entire software package is unable to function as intended due to an error. Such errors are termed functional errors. Hence the functional errors can be considered exceptions. Let us understand the concept of functional errors in the context of issues that are often faced by air traffic control officers.
Some of the functional errors that can take place in Air Traffic Control Services are as follow
This is the situation where the required system is unable to perform due to an error and stops responding.
A Voice Communication Control System (VCCS) is advanced digital voice communication technology. It supports the concept of a global SWIM community that is a Service-oriented approach while designing a program in order to ensure complete facilities for functional programming and procedural programming.
Voice Communication Control System (VCCS) has a specific digitally designed architect for visual display. This system provides the option for the best selection of offset carrier operation as well as the best signal selector. Switching between different options is done through the selection that is achieved by clicking on digitally designed buttons. Now imagine an air traffic control officer who is busy in the provision of air traffic control services. He encounters some distortion in a frequency in order to switch to another frequency he de-selects the previous frequency. Then he touches on the button that is integrated with the selection of other frequencies. But as he touches the required button for confirming the selection of a new frequency the required frequency is failed to select or the button does not respond. The unified SMC will reflect this error. Automated AI-based error resolution services will be provided based on synchronized and interconnected seamless data information from different sources. Service-oriented architecture is an architectural approach that aims at developing modular applications consisting of independent services, which fulfill a specific task and communicate with each other in concordance. This communication also facilitates the flow of data across different modules. Then these modules generate results in response to it. But if it becomes eminent that the advanced system is unable to resolve the problem ahead then support for the trial and error method should be obtained. After rigorous trial and error, if it is realized that the system got hanged. All ATSEPs should remember that this is a classic example of functional error. The same situation can occur with the radar scope and if it does the probability is high for functional error.
The ATSEP should remember that once you are confronted with such a situation, always check if the system got frozen. Upon confirmation, the ATSEP should restart the system in accordance with the instructions mentioned in the concerned manual.
Air Traffic Control Service revolves around the provision of safety to air traffic. The air traffic controller is observing traffic on a radar monitor throughout his duty. He is able to apply separation standards based on the visualized traffic. Hence we can consider the importance of aircraft visualization on the radar scope. The target is required to be very precise. But due to some error, the aircraft position depicted on the screen is incorrect.
Sometimes internal system errors happen that result in the inability of the tracker algorithm to perform a required function correctly.
There are four common track algorithms.
The function of these tracker algorithms is related to the identification of aircraft positions.
Aircraft position is based on the data acquired in the valid span of time during which flights co-exist in close or far ends. The air traffic controller gets traffic situational predictions related to the near future generated by the system logic. But due to this functional error, the system failed to operate or function in a normal and correct manner. As a result, the incorrect position of an aircraft is depicted on the screen. In a high-workload environment like air traffic control, this situation is extremely dangerous.
ATSEP should rely on additional coordination with other controllers in order to confirm the existence of such an error. Upon confirmation of such functional error either the unified SMC will make an error indication or system-based automated rectification of error will occur that will lead to switching towards the backup tracker. In case of a lack of a support system, the ATSEP who is trained for it will make the choice of the backup tracker.
This is the situation where the aircraft target is not in synchronization with flight plan information.
The Flight Plan Information is gathered in a separate module created within the ATM. For reception of the Flight Plan, it is mandatory that the format should be in accordance with ICAO Flight Plan 2012. The flight should be provided with an address code for the required ATM. The Flight Plan through Automatic Message Handling System is received and transmitted automatically without human intervention towards the ATM.
The flight plan data is connected to the ATM. The aircraft is always depicted on the radar screen as a tagged icon. Whenever this tagged icon is pointed it reflects the flight details that are part of its current flight plan available in the system. Sometimes the flight plan information is partially available. And sometimes this error results in a lack of complete flight plan information. Such type of error is complex in the aspect that sometimes it appears to impact one aircraft and sometimes a number of aircraft.
ATSEP should recognize such errors as related to functional errors and as a remedy, he should advise air traffic controllers to use the manual description of the aircraft symbol. Such a manual description option is available with the aircraft-tagged icon. A manual Correlation option is also present. One aspect that should be considered is the lack of a proper ATM address in the flight plan message by the operator. So much functional error can be an outcome related to incorrect input information that restricts the proper execution of a function.
This is the situation where the Conflict Alarm System is unable to perform a warning function efficiently as required.
The track algorithms-related errors sometimes appear to hinder the functional ability of the alarm system. Errors, incorrect information, partial information, or lack of complete information impact tracker algorithms. This impact affects warning system efficiency to incline towards erroneous predictions.
Air traffic control systems are provided with the ability to trigger an Alarm in case there is some conflict resolution required due to the close proximity of aircraft. Such alarm systems can be divided into two types which are as follow:
Sometimes due to it STCA or MTCD warnings start appearing on the scope and making specific alarm signaling. These false alarms are being observed very commonly in the air traffic environment. Such a false alarm is an example of a functional error. Such alarms appear to decrease the importance of STCA and MTCD. The importance is impacted due to changes in perception related to these alarm systems. The perception is altered due to frequent encounters with false alarms. As a consequence controllers can overlook such alarms while performing their duty.
ATSEP should take a close look at such alarms. And this can be observed on the radar display available in the technical control room. They should remember this to be a functional error. ATSEP should try to find out the cause whether related to incorrect information or system error. The ATSEP should inform the air traffic controller to disable the alarm to avoid this false error. The ATM manager should be informed about the cause and other concerned sections to be reported for carrying inspection by a software-related team to quality check the system and rectify the bugs.
ATSEP should acquire support from the required manual. But still, it is understood that errors related to software are sometimes predictable and sometimes unpredictable. We can predict the cause but when an error may appear, this is completely uncertain. Even the sequencing of errors to appear is unpredictable. ATM systems are now a day prepared based on Service-oriented programming in a larger perspective that is to become the part of global SWIM community.
This standardized development requires vigorous testing and quality control. But still, errors can occur due to very minute or complex reasons. Because of this uncertainty, ATSEP cannot have an analysis of such errors to the required perfection. It is expected of the advanced service oriented technology to be self-regulated based on the power of automation and interoperability. But as a backup for circumstances during which support is not available due to malfunctioning the only option left with ATSEP under such a scenario is to use the thumb rules based on expert opinions or heuristics from people who have faced and resolved such a situation. There exist very clear possibilities for including semantics as a probable solution for rectifying errors that happen suddenly.