/ Airport FIDS /
A Full Airport FIDS on Three Players — No Server, No Internet, No Per-Screen Fees
A regional international airport in an ex-USSR country runs its entire flight information display system — departures, arrivals, gate and desk routing, and advertising — on three SpinetiX EMP-III players, one per LED board. There is no dedicated processing server, no internet connection, and no per-screen CMS fee. The point of this case is simple: deploying a FIDS does not have to be a heavyweight IT project.
Illustrative FIDS layout — the kind of board SpinetiX renders natively at the screen's exact resolution (here a non-standard 1920×1200), built on the fly from the raw flight feed.
What was deployed
Three LED boards — one on the façade, two inside the terminal — show live departures and arrivals in two languages, with airline logos, gate and desk assignments, and an advertising block. Each board is driven by its own SpinetiX EMP-III player. The flight feed arrives as plain-text files over the airport's closed local network, refreshed once a minute; the boards show only the flights inside a ±2-hour window. Everything else — parsing, status, logos, translation, layout — happens on the player.
From raw feed to flight board: the data pipeline
The airport's scheduling system exports two plain-text CSV files — one for departures, one for arrivals (about 316 rows in a full feed) — to the local network once a minute. From there, everything happens inside the widget on the player. There is no parsing server, no cloud step, no middleware:
The whole transform runs in the widget's modifyData.js — a set of small,
readable functions that turn one raw feed row into one board row, in both languages:
getStatus() derives the
status and colour, getLogo() matches the airline, getLocation()
translates the destination, getFlight() cleans the flight number. No server involved.
- Status on the fly —
getStatus()reads several fields (planned vs. actual time, registration and cancellation flags) and derives states like Check-in, Boarding, Delayed and Departed, each colour-coded. - Airline logos —
getLogo()matches 100+ carrier logos by code from an on-device library, with a clean fallback when a code is unknown. - Translation —
getLocation()renders destination names in two languages from a 1,500+ entry dictionary held on the player. - Clean flight numbers & routing —
getFlight()strips service suffixes; gate, desk and terminal assignments are laid out per flight, sorted by relevance and filtered to the ±2-hour window.
Because the pipeline is code you control, it adapts to the airport's data rather than forcing the airport into a fixed import format — the foundation of true data-driven content.
Two ways to run a FIDS on SpinetiX
There are two routes to a flight board on SpinetiX. One is easy and works with what you already have. The other is the right way to build it.
Already have an HTML FIDS? It just runs — and keeps running.
If you already have a FIDS as an HTML page, running it on SpinetiX is trivial — point a player at the URL and it renders. What makes the difference is the engine underneath. Most digital-signage players embed a consumer-grade browser that was never meant to hold a single page open for years: it leaks memory, drifts, and eventually needs a reboot. SpinetiX's HTML engine is a different animal — a near-latest Chromium core, re-engineered for continuous unattended operation: compliant with IoT device standards, with auto-reloading microservices that recover the render surface on their own, and none of the consumer-browser baggage. That is why an HTML board on a SpinetiX player renders crisply and stays up for years, not weeks — secure, reliable, and with excellent HTML fidelity.
Build it natively — no browser at all.
The stronger approach — and the one this airport uses — skips the browser entirely. jSignage-driven SVG widgets take the raw flight feed and build the board on the fly, directly on the device. The result renders at the display's native resolution — pixel-perfect even at a non-standard 1920×1200 — carries any business logic you need (status derivation, gate routing, multilingual translation), and has no browser attack surface to secure or crash. It is the native, data-driven way to do signage, and it is secure and stable by construction.
Licensing and operations
The commercial and operational model is as lightweight as the architecture:
- Perpetual SYSTEMS license — one Elementi/SYSTEMS-tier license, bought once, with no per-screen monthly fees.
- Author in Elementi, publish over WebDAV — the departures, arrivals and advertising layouts are built in Elementi and pushed to the players; updates propagate without touching each screen by hand.
- Adaptive HTML control panel — operators drive the boards from a responsive web panel that works on a desktop, tablet or phone; commands travel over the LAN by RPC.
- Three display modes per board — departures + advertising, arrivals + advertising, and full-screen advertising, switched centrally.
- No single point of failure — each player is autonomous, so there is no back-end server to patch, scale or lose.
Built to stay on
A departure board is mission-critical — it cannot show a system dialog, a browser error, or a blank screen. SpinetiX players run DSOS, a purpose-built Linux appliance OS with zero published CVEs, no Windows userland and no cloud antivirus agent. When the July 2024 CrowdStrike update took Windows-based FIDS dark at airports around the world, boards running DSOS were unaffected — they share none of that stack. Running on a closed network with no internet dependency, this FIDS keeps the flight data inside the airport's own walls. See security by design for why the architecture matters.
Gate screens work the same way: one feed, thousands of screens, no server
A gate screen is not a different system — it is the same feed, filtered. Where the main departures board filters the shared feed to all flights in a ±2-hour window, a Gate Information Display (GIDS) screen filters that same feed down to a single gate: the one boarding flight, its status and its boarding call. The widget is identical; only the filter parameter changes.
Because that filtering happens on the player, the data source never changes and no server is added. Point another SpinetiX player at the same feed, give it a gate filter, and it renders its own screen. This is what makes the move to a fully server-free estate smooth — and what lets it scale: there is no central rendering server to bottleneck, so every screen from the façade board to the last gate pulls the same shared feed and filters locally. You grow the system by adding players, not servers. The three boards in this case and a whole terminal of gate, desk and baggage screens are the same architecture at different sizes.
From one airport to a network: 123CMS
A single board runs perfectly standalone. To operate FIDS across many gates, terminals or airports from one place — and to make the boards pay for themselves — 123CMS sits in front of the SpinetiX player fleet:
- Customised FIDS & gate routing — manage flight-board content and per-gate, per-zone routing logic from one customer-branded console, on your own infrastructure.
- Built-in advertising engine — the departures-plus-ads, arrivals-plus-ads and full-screen-ad modes become a monetised inventory, with proof-of-play, instead of a separate advertising platform.
- Your own build — branded, data-sovereign, cloud or on-premises, with the customisation that turns a generic board into your airport's system.
It is the difference between deploying one flight board and running a whole estate of them — with routing, scheduling and monetisation handled in one place. The same content automation extends to any live data source, from gate changes to weather to retail.
We do everything — for integrators and consultants
A FIDS is only as good as the team behind it. Media La Vista delivers the whole thing and stays on the line afterward, so integrators and consultants can add a flight-board line to their offering without building an aviation-data practice from scratch:
Turnkey delivery
Board design, jSignage widgets, data connectors, Elementi project setup, schedule-feed integration and staff training — we build and commission the complete system.
Fast Tier 1–3 support
Direct engineering support as SpinetiX Master Distributor for the region — not a ticket queue. Feed changes, new logos, new logic and firmware currency handled quickly.
Full documentation & handover
A documented widget, data contract and operations guide, so your team — or the airport's — can run and extend the system with confidence.
You keep the client
We work behind you as the FIDS specialist. You lead the relationship; we make sure the boards are right, on time and always on. See our services and partner programme.
Have a FIDS to deploy — or an HTML board that keeps crashing?
Bring your existing HTML flight board and we will run it on hardware built to stay on, or build it natively with jSignage for a solution that renders at native resolution and never touches a browser. Airports, transport hubs and smart-city operators across the region work with us as SpinetiX Master Distributor for the Middle East.
FIDS, GIDS and BIDS: the terms
Airport display systems come with an alphabet of acronyms. They all read the same schedule and, on SpinetiX, can share one feed, one widget set and one fleet:
The departures and arrivals boards passengers read across the terminal. This case is a FIDS deployment.
The screen at each gate showing the boarding flight, time and status. Driven from the same feed and logic as the FIDS.
Screens over the baggage-claim belts matching flights to carousels.
The airport's master schedule. FIDS reads an export of it — as CSV, XML or a live feed — and renders the boards from it.
Screens and maps that route passengers to gates, desks and services — often combined with FIDS on the same players.
The monetised ad blocks that share the departures and arrivals boards, with proof-of-play — handled here by 123CMS.
Frequently asked questions
What is a FIDS (flight information display system)? +
A FIDS is the network of screens that show live departures and arrivals across an airport — flight number, destination, time, terminal, gate, desk and status. A modern FIDS reads the airport's schedule (from an Airport Operational Database or a simple CSV/XML export) and renders the boards automatically, updating as flights change. On SpinetiX, a FIDS runs directly on the media players with no separate display server.
How do I display live flight information on a digital signage screen? +
Feed the flight schedule to the player and let it render the board. On SpinetiX there are two ways: run an existing HTML FIDS page on the player's hardened browser engine, or — the preferred route — build the board natively with jSignage SVG widgets that read the raw feed (CSV, XML or JSON) and compose departures and arrivals on the fly. Either way the display updates automatically as the feed changes; no operator retypes flights.
Can I run my existing HTML flight information display on SpinetiX? +
Yes, and it is one of the easiest ways to start. Point a SpinetiX player at your existing HTML FIDS page and it renders it directly. What sets it apart is the engine: SpinetiX uses a purpose-built HTML renderer based on a near-latest Chromium core, re-engineered for continuous unattended operation with auto-reloading microservices — not the consumer-grade embedded browser found in most signage players, which was never designed to hold one page open for years. Your HTML board renders crisply and keeps running for years without reboots.
What is the best way to build an airport FIDS on SpinetiX? +
The strongest approach is native, not browser-based. jSignage-driven SVG widgets take the raw flight feed and compose the board on the device in real time, with no web page in between. This gives pixel-perfect output at the display's native resolution (including non-standard sizes such as 1920x1200), unlimited business logic for status derivation, gate routing and translation, and no browser attack surface. The airport in this case study runs its departures and arrivals boards this way.
What flight-data formats can a SpinetiX FIDS read? +
Whatever the airport can export. In this deployment the scheduling system writes two plain-text CSV files — one for departures, one for arrivals — to the local network, refreshed once a minute; the widget parses them on the player. The same approach reads XML, JSON or a REST/AODB feed. Because the parsing is code you control inside the widget, you are not limited to a fixed import format — you adapt the widget to the airport's data, not the other way around.
Can an airport FIDS run fully offline, on a closed network? +
Yes. Each SpinetiX EMP-III player processes the feed autonomously on the device — parsing, status generation, airline-logo matching and destination translation all run in widget code on the player. This airport runs entirely on a closed local network with no internet dependency and no separate processing server, which keeps flight data inside the airport's own infrastructure and removes a whole class of outage and attack surface.
How do you show airline logos and multilingual destinations on a flight board? +
Both are generated on the player. A logo function matches each flight's carrier code to an on-device library of 100+ airline logos, with a clean fallback when a code is unknown. A location function translates destination names between languages from a 1,500+ entry dictionary held on the player, so the board can alternate or split between, for example, a local language and English. No manual data entry, and it works with no internet connection.
What is the difference between FIDS, GIDS and BIDS? +
FIDS is the airport-wide flight information display system (the departures/arrivals boards). GIDS is the Gate Information Display System — the screen at an individual gate showing the boarding flight. BIDS is the Baggage Information Display System over the claim belts. All three read the same airport schedule; on SpinetiX they can share one feed, one set of widgets and one fleet of players, with the layout and logic tuned per role.
How do gate information screens (GIDS) work, and how do you scale to thousands of screens without a server? +
A gate screen is the same feed, filtered. The main board filters the shared flight feed to all flights in a ±2-hour window; a Gate Information Display (GIDS) screen filters the same feed to a single gate, showing the one boarding flight, its status and boarding call. Because the filtering runs on the player, the data source never changes and no server is added — you point another SpinetiX player at the same feed, give it a gate filter, and it renders its own screen. There is no central rendering server to bottleneck, so the architecture scales to thousands of screens: façade boards, gate screens, desk screens and baggage belts all pull one shared feed and filter locally. You grow the estate by adding players, not servers.
Why did SpinetiX FIDS keep running during the July 2024 CrowdStrike outage? +
SpinetiX players run DSOS, a purpose-built Linux appliance OS with no Windows userland and no cloud antivirus agent. When the July 2024 CrowdStrike update took Windows-based FIDS dark at airports worldwide, players running DSOS were unaffected because they share none of that stack. DSOS has zero published CVEs, which is why it is trusted for mission-critical, always-on displays.
How do you manage FIDS and advertising across many gates or terminals? +
For a single board each player is standalone. To run FIDS across many gates, terminals or airports from one place, 123CMS sits in front of the SpinetiX player fleet: a customer-branded console for managing FIDS and gate-routing content, with per-zone customisation, plus a built-in advertising engine so departure and arrival boards carry monetised ad blocks with proof-of-play. It runs on your own infrastructure, cloud or on-premises.
How long does it take to deploy an airport FIDS, and who builds it? +
Media La Vista delivers it turnkey. We design the boards, build the jSignage widgets and data connectors, set up the Elementi project, integrate the airport's schedule feed, and train the staff — then hand over a documented system. Because the players are autonomous and need no server, a focused FIDS goes from feed to live boards quickly, and Tier 1–3 support and documentation continue afterward. Integrators and consultants can hand us the FIDS layer and keep their client relationship.
How much does a SpinetiX FIDS cost to run? +
There are no per-screen monthly CMS fees and no dedicated server to license or maintain. This deployment uses a perpetual SYSTEMS-tier license and three SpinetiX EMP-III players, one per board. The advertising engine can offset or exceed the running cost, since the boards carry monetised inventory instead of needing a separate advertising platform.