We talk about this all the time: an industry cannot be automated until it is digitised. This is why aviowiki exists, to digitise aviation so that all the cool automated things can work.

In digitising any information we first need to have a good idea of what problem we want to solve. Based on that, we can then specify what data we need and then go on to decide how to extract it from the information source.

For complex things, like airport opening hours, we had to make certain choices in the beginning of our journey. One of these choices was to fully rely on human intervention to manage airport opening hours exceptions. This means that for any specific point in time, the airport and its services (ARFF, ATC, and Customs), could be either “Open”, “Closed”, or “Limited”.

In the case of “Open” or “Closed” the situation was clear: either a clear go-ahead or a clear show-stopper. With “Limited” we always included a free-text note that would explain all limitations. This is what we would recommend our customers to show to a human to make a decision.

For the gurus of aviation digitisation, this started not to be enough. So here we are, expanding our data model to bridge that gap and make “Limited” machine readable.

How did we do this? Go on, keep reading!

Who is the airport open for?

In simple terms, all of the Limited opening hours meant that there were some conditions to be met for aircraft to use the airport. Usually these looked something like “Available only for Medevac, SAR, Ambulance, and State flights”. In some cases we had exceptions like “Available with 6h PNR, for a fee”.

So after analysing a few hundred cases, we decided that the best thing to do to cover most scenarios of Limited opening hours, was to create a data model to specify who the airport is open for. So enter our ‘openFor’ property!

Whenever an airport availability block has status of “Limited” we now have the possibility of including a list of exceptions for which the airport can be considered open, in the new ‘openFor’ property of the availability block. Each element in the list describes what types of flight can access the airport, and under what condition, if any particular.

For example, we can now specify that at a certain time only scheduled airline flights can operate, or that all VFR flights require 3 hours notice, or again that during a night closure the airport remains available to Hospital and SAR flights.

We can describe each case accurately, using an extensive digital model that draws inspiration from ICAO’s Doc 4444 in the way it classifies a flight. Additionally we can also say if a prior notice is required to operate such flight, and if any extra cost is involved.

Why go in such details?

Well, this goes back to the initial point: there’s no automation without digitisation.

Aviation is an industry made of exceptions. There are exceptions possible to all sort of rules. And Airports operations are no… exception!

So it makes total sense to us to dive deeper in the complexities of the Airport opening hours, and digitise more and more special cases. By doing this we enable more automation. Our customers’ systems are able to handle more scenarios without having to raise exceptions to humans, which makes a stronger case for the adoption of digital data.

What’s next?

Our goal is to digitise everything, so we’ll certainly continue to iterate on this model, expand it and refine it. But we will not stop there!

We’re constantly poked with questions like “do you also have this information”? And we certainly draw a lot of ideas from conversations with our customers. So perhaps you can help us here. What’s bothering you today? What process you cannot automate because the data is not there yet?

Be sure to let us know by writing to hello@aviowiki.com, LinkedIn, or Twitter.

And if you don’t want to miss a beat of our innovations, please consider subscribing to our newsletter. We’re very sensible and won’t spam your inbox.