This article is part one 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 using our very own VisionAir FIDS.

TL;DR

• Most legacy FIDS (Flight Information Display Systems) run on one central server handling data, logic, rendering, and scheduling together. When that server fails, every screen it feeds fails with it.
• A screen frozen on old data is more dangerous than a blank one. A blank screen sends a passenger to find staff. Frozen sends them, confidently, to the wrong gate.
• VisionAir FIDS separates operational control, screen delivery, and data integration into three parts that fail independently, so a fault in one does not reach the others.
• Screens hold content locally and keep showing the last valid information if they lose contact with the platform. How long a screen trusts that copy is configurable per screen type, because a gate board and an advertising panel have different tolerances for old data.
• Architecture limits damage from problems inside the platform. It does nothing about a source system going quiet, which is where this series goes next.

It is 6 am and a connection pool has just filled up

The first check-in wave of the day arrives all at once. A database connection pool fills. One service, the one carrying that morning surge, stops responding.

Everything that happens in the next ten seconds was decided years earlier by whoever chose how the system was put together.

In a monolithic FIDS, that service is not really a separate thing at all. It is one function inside a single central server that is also pulling flight data, applying logic, rendering layouts, and running the schedule. When one part of that server has a bad day, the server has a bad day, and every screen it feeds goes down at the same moment.

Or, worse, does not go down. It freezes on data that is no longer true.

That second outcome is the one to worry about. A blank board tells a passenger something is wrong and sends them to find a member of staff. A frozen board tells them, with complete authority, to walk to a gate their flight left from an hour ago.

To the IT team, this is a ticket. To the passenger in Terminal 2 with forty minutes to a connection, it is the worst part of their week. To the airport's reputation, it's a photograph taken on a phone, posted to social media, a PR crisis seen by thousands of people before the help desk has even logged the call.

In VisionAir FIDS, the same 6 am spike plays out differently. The service handling that morning surge crashes, but because it runs as an independent piece of the platform, not a fragment of one giant system, it goes down on its own, and nothing else goes with it.

Why one server failing takes every screen with it

A single point of failure is any component whose failure stops the whole system.

In a flight information display system, the classic single point of failure is that central server, because it combines data handling, logic, rendering, and scheduling in one place. Those functions share a server, so a fault in any one of them removes all of them. Every screen downstream loses its source at once, and the scope of damage from one small fault becomes the entire terminal.

Most of the work of FIDS resilience is the work of making that scope smaller.

What changes when the parts can fail separately

The move from monolithic to service-based architecture has been one of the larger shifts in enterprise software over the past decade. The CNCF Annual Survey tracks how far it has gone, with container and Kubernetes use now standard across most organisations it surveys.

The principle underneath it is not complicated.

Instead of one large system that does everything, you build a set of small independent services that each do one job. When one stops, the others carry on.

VisionAir FIDS was built on that principle from the first line of code, with one rule holding it together: no single component should be able to take down an airport's passenger communication.

In practice, that means separating three things legacy systems usually combine.

Operational control. The console your team works in to schedule content, manage screen infrastructure, and run the boarding and check-in workflows that keep passengers correctly informed. This is governed centrally, which gives an airport one coherent point of control over everything on every screen.

Screen delivery. The application that actually drives the screens, fully decoupled from the console operators use to manage it. A problem on the operational side has no effect on what a passenger is looking at. Screens carry on with the last valid data and configuration they received, whatever state the management layer above them is in.

Data integration. Flight data does not travel from source to screen down one channel. The integration layer handles several concurrent streams, so the pipe carrying the data is not a single point of failure in its own right.

Three independent failure domains instead of one shared one. Which is why, back at 6 am, three things can be true at the same time. The operational side has a problem. The screens do not. The data keeps arriving.

Centralised control, in other words, without a centralised point of failure.

Why a gate board and an advertising screen need different patience

The separation carries all the way down to the individual screen.

Each screen holds its content locally on the device. If it briefly cannot reach the platform, it is not stranded, because it already has what it needs to keep going.

What happens after that is an operational decision rather than a technical detail, and it is the part worth pausing on. How long a screen keeps trusting its stored copy before it changes behaviour is configurable, because not every screen has the same tolerance for old data.

A board showing gate assignments has a short patience window. Wrong information is worse than no information, so that screen needs to stop presenting stale data as current fairly quickly.

An advertising or media screen has a much longer one. Nobody misses a flight over an out-of-date promotion, and there is no safety implication either way.

That is a judgement your team makes per screen, not a behaviour the platform decides on your behalf. When the connection returns, everything resynchronises on its own.

Running on cloud is not the same as being built for it

Architecture does not stop at the software. Where a platform runs matters as much as how it is written, and the hosting approach follows the same rule as the code: no single point of failure.

Widen the 6 am problem out. Instead of one service failing, an entire node has an issue.

VisionAir FIDS runs on public cloud infrastructure spread across multiple availability zones, so the platform does not depend on any one piece of hardware or any one data centre staying healthy.

That sits behind a 99.99% availability target and a disaster recovery plan that can restore the platform on an entirely different provider if it ever comes to that.

The number matters less than the practices behind it. Infrastructure is fully scripted, so it is rebuilt in minutes rather than assembled by hand over hours. Tiered backups on a continuous schedule. Containerised services that come back quickly because they were never handcrafted in the first place. A dedicated team watching it around the clock.

And disaster recovery drills that actually get run, because a recovery plan nobody has tested is a document rather than a plan.

What this does not fix

None of this makes failure impossible. Nothing makes failure impossible.

What it does is keep the scope of any single fault as small as it can reasonably be. A service, a screen, a zone. Not a terminal.

But architecture only defends you against problems inside your own platform, and the harder question sits upstream.

VisionAir FIDS takes its flight data from whichever AODB an airport runs, our own SkyCore AODB or somebody else's.

So what happens when the fault is not in VisionAir FIDS at all, but in the system feeding it? What happens when the AODB goes quiet, every screen in the building is working perfectly, and every one of them is confidently wrong?

Next in this series: what happens when the data stops arriving, from a two-second network blip to an airport losing its connection to the outside world entirely.

_Talk to us about VisionAir FIDS._

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.