_Part two of No Blank Screens, a series on FIDS resilience: what happens to airport displays when something fails, and how to keep passengers correctly informed anyway._

TL;DR

• A FIDS is only as accurate as the data reaching it. VisionAir FIDS can be entirely healthy and still be showing a passenger the wrong gate.
• Short network drops never reach the passenger, because every screen keeps a local copy of what it is displaying and resynchronises on its own. 
• Airports set how long each screen keeps trusting that copy, so a gate display and an advertising screen can behave differently.
• Monitoring and Alerting notifies the team when a screen has dropped via email, SMS, or API.
• When a flight feed goes quiet, the Flights Contingency Tool lets operators keep updating delays, gate changes and desk assignments by hand. 
• If the airport loses external connectivity entirely, a local component within the airport's environment continues to serve live flight data over the local network. 
• One rule underneath all three: never wait for somebody else's system to come back.

The first part of this series looked at FIDS resilience: what happens when one component fails, and how VisionAir FIDS uses fault isolation and cloud redundancy to keep the airport screens running anyway.

This second article asks the question that architecture cannot answer: what happens when the data itself stops arriving? A network drop, an AODB outage, and a total loss of connectivity are three different failures with three different responses, and the difference between an airport that copes and one that goes dark is decided before any of them happen. This is what VisionAir does at each stage, from a screen quietly holding its last good copy to an operator updating gate numbers by hand.

Any FIDS, or flight information display system, is only as accurate as the data reaching it. Which means VisionAir can be perfectly healthy and still be showing passengers the wrong gate. None of that is VisionAir's fault, and none of it is the airport's fault either. The passenger standing at the wrong gate does not care whose fault it was.

An hour of wrong information on the screens is not an hour of inconvenience. It is staff pulled off their actual jobs to stand in the terminal reading gate numbers off a tablet. It is the information desk queue doubling. It is a handful of passengers who miss a connection they would otherwise have made, and the compensation conversation that follows. And it is the airline asking, reasonably, why their flight was the one showing the wrong gate.

Everybody in airport operations has a version of this story. Which is why the interesting question is never whether the feed will drop. It is what happens in the ninety minutes after it does.

Why short network drops never reach the passenger

Not every interruption is dramatic. Networks blip constantly, a few seconds here, a brief drop there, and with VisionAir, most of the time nobody notices, because they are not supposed to.

Every screen keeps a local copy of what it is displaying, so a momentary gap in connectivity does not mean a momentary gap in information for the passenger. The screen already has what it needs.

For longer gaps, VisionAir lets airports set a tolerance per screen to match each screen's actual purpose. A gate display has almost no room to show something wrong, so it can be set to switch away from stale flight data within a few minutes if the connection does not return. An advertising screen has no such urgency and can continue with its existing content for much longer because there is no risk either way. Once the connection returns, everything resynchronises on its own, with nobody having to step in.

_The first article in this series covers why the FIDS screens can behave independently at all, and what that has to do with how the platform is built._

That is the ordinary, everyday version of this problem. The harder cases are when the disruption is not measured in seconds.

When an AODB feed drops, operators take over

Before anyone can respond to a longer outage, somebody has to know it happened. VisionAir monitors every screen and raises an alert the moment one drops offline, by email, or into whatever system the team already watches. Nobody is walking the terminal to discover a dead panel, and nobody is finding out from a passenger at an information desk.

When a flight feed disappears for real, most systems have exactly one option: freeze on the last update they had, and hope it does not age too badly before the feed comes back. A ten-minute delay when the feed went down might be an hour by the time it returns, and every screen in the terminal is still telling passengers the old number.

VisionAir does not leave operators watching that clock. The moment the feed goes quiet, someone on the ground can pick up exactly where it left off, updating a delay, pushing out a gate change, or reassigning a desk or a belt, without waiting for a system that is unresponsive. That is what the Flights Contingency Tool is for, and it is part of the platform rather than an add-on.

The screen does not know or care that the update came from a person instead of a feed. It shows the same accurate information either way. The only thing that has changed is who is doing the work behind it, and only for as long as the outage lasts.

A feed going down does not have to mean the passenger experience goes down with it. The disruption stays contained to the moment it happens, rather than stretching out over the length of the outage.

FIDS offline mode: when the airport loses connectivity entirely

A feed going down is one problem. Losing the airport's entire connection to the outside world is a much bigger one, with nothing reaching VisionAir's cloud platform no matter which system it was supposed to come from.

This is the scenario that genuinely threatens to take every screen in the terminal dark at once. Connectivity is the one thing no software vendor controls, so VisionAir is built for the days an airport does not have it.

VisionAir runs a local appliance within the airport's own environment, as dedicated hardware or as a virtual machine.

It sits on the airport's network and keeps receiving live flight data from the systems that are also inside the building, whether or not the connection to the outside world is up.

So when that connection goes down, there is no scramble to get current data flowing again.

It already is.

An administrator can switch the appliance on, and screens find it and reconnect when needed within moments, without anyone touching a display.

This is the one place VisionAir asks for something inside the building, on a platform otherwise built to run on nothing but a browser and an internet connection.

It is not a permanent substitute for the cloud platform, and it is not meant to be. It is a spare tyre, not a second car. But for exactly as long as an airport has no way to reach the outside world, it is the reason the terminal keeps working instead of going dark.

The pattern behind all three: never wait for somebody else's system

Whether it is a momentary blip, a feed going quiet, or the whole airport losing its connection, the response follows the same logic. Do not wait for somebody else's system to come back online. Give the airport a way to keep passengers correctly informed regardless.

In practice, that keeps the ninety minutes after a feed drops from turning into an incident.

An alert reaches the person who needs it. Someone takes over the flight updates by hand and keeps the boards accurate while the feed is out. The screens carry on saying true things. Nobody is dispatched to the terminal with a tablet, the information desk has a normal morning, and the passenger heading for gate 14 gets there in time because the board never stopped being right.

Every answer in this article has assumed one thing stays true, though: the screens themselves still have power to run on.

What happens when that stops being true, when there is no display left to update at all?

That is no longer a data problem, and it needs a completely different kind of answer.

Next in this series: what happens when the screens themselves lose power.

Most airports find out how their FIDS behaves during an outage the hard way. VisionAir FIDS is built so you already know. _Talk to us about VisionAir FIDS._ 

No Blank Screens: A Practical Guide to FIDS Resilience

1. FIDS Resilience: What Happens When One Component Fails

2. FIDS Offline Mode: What Happens When the Flight Data Stops _(you are here)_

3. Coming next: when the screens themselves lose power

About AirportLabs

AirportLabs builds cloud native software for airport operations. Our products cover the core operational stack, including SkyCore AODB, Allegra RMS, VisionAir FIDS and AirportLabs Billing, alongside ground handling and airport collaboration tools. They are designed to work as separate systems or as a connected suite, which is why a FIDS conversation at AirportLabs usually ends up being a conversation about the data underneath it.

_Written by Bianca Făgăraș, Product Manager, VisionAir FIDS._