In geek speak, API stands for Application Programming Interface and it describes how computer systems can communicate with each other. When I started working in air traffic control in 2000, we used to create protocols ourselves, defining compact sets of instructions and parameters exchanged over short cables or modems and sometimes local area networks, specific to each pair of applications.
The world of IT has since evolved and APIs are now using web technologies like HTTP requests and JSON content, and a large number of standard software libraries support them. To explain it in non-technical terms, this largely standardises the ‘how’ of inter-system data exchange, letting engineers focus on other problems. Every app on your smartphone communicates with its backend using such an API, which also decouples the frontend from the backend, making systems easier to evolve.
Air traffic management systems are not there yet. Some still use proprietary ways of communicating. Others have private APIs, belonging to the supplier and closed to any external integration. And some do not offer any API at all. There are many reasons behind this:
- A closed system is sometimes seen as safer, with less risk of foreign data corruption or cybersecurity risk.
- The number of potential users remains limited, and implementing APIs might feel like too much effort for too little gain.
- Proprietary interfaces make it easy to extend a system with a module from the same family, from the same provider, and hard to add a module from another provider.
Why is this an operational problem?
Air traffic has evolved since I was implementing closed interfaces in 2000. Traffic grew by 28% but the principles of air traffic management (ATM) remained the same. Some automation systems were introduced, almost always in a closed fashion. ATM does have standardised exchanges, from OLDI and ASTERIX to newer information models and SWIM services. But these remain fragmented by domain and purpose, and ATM has nothing approaching the ubiquitous, general-purpose API ecosystem that modern IT developers take for granted. At a time when the ATM industry is discussing artificial intelligence and ever higher levels of automation, this is a remarkably basic problem to still have.
Even worse, many communications are not made using systems. For example, an air traffic controller (ATCO) opening a tower in the morning, calls the supervisor of the neighbouring centre or approach unit to say the tower is open. It is also very common to have tower controllers calling their approach colleagues to get a ‘release’ for a departing flight. Why not handle those communications via an API?
Traffic growth means more workload for ATCOs and every phone call creates additional workload, both for the caller and receiver, as it interferes with workflows in a synchronous way: when the telephone rings, ATCOs must interrupt whatever they are doing to handle the call, without forgetting the task they were performing before. Digital workflows built around standard APIs enable many such requests to be managed asynchronously, when time is available, reducing mental workload. It might introduce a bit of delay, but for anything urgent, a phone call is still possible.
Make more information available, faster
Beyond workload reduction, having standard APIs would help by making more information available. Look at the recent fatal accident in the US in which military GPS jamming played an important role. The controller was aware of the potential for jamming but was not informed about the real-time status. Beyond tactical aspects, calling civil ATC every time jamming is activated or deactivated is not practical. But this could easily be automated and provide ATCOs with real-time information.
There is more: the timeline in the report shows jamming stopped only after six minutes and at least two phone calls: the ATCO called their supervisor, and the supervisor called their military counterpart. This makes sense as the ATCO does not have the time to find the right communication partner, call them, and ask for a jamming stop. Delegating this to the supervisor makes sense in a human context.
How would this run in an API driven environment? The military would provide an API with a list of areas where jamming is active, with their geographical coordinates, real-time status, and digital contact point. The radar screen could then display this information and offer a human-machine interface element through which the controller could submit a request to stop the jamming. Two phone calls would be reduced to one click.
I can’t say whether this would have prevented the accident. But it could have shortened the reaction time and reduced workload. As traffic grows and controllers are asked to manage ever more complexity, we cannot keep solving every new information exchange with another telephone call or another proprietary interface. Modern, secure and standardised APIs are no longer optional.
Twenty-six years after I started building point-to-point interfaces, I am still waiting for my API.
