Sources that disagree
The AODB says gate A14, the airline's own message says A16, and the belt allocation arrived from a third system. Without an explicit precedence rule, whichever wrote last wins — and it is often the wrong one.
SE-FIDS · Release 2026.1
Every screen in the terminal, telling the same truth.
A passenger checks four displays between the kerb and the gate. If any one of them disagrees, your contact centre finds out before you do. SE-FIDS is the control plane that keeps departures, gates, check-in, reclaim and signage consistent — driven by rules, not by someone typing into a spreadsheet at 05:00.
0Display uptime target
0Endpoints per cluster
0Feed to glass latency
0Languages per rotation
184 displays online · 0 stale
The problem
Display systems rarely fail loudly.
They fail quietly — one zone shows yesterday's gate, a player freezes on a splash screen over a holiday weekend, an airline's status update takes four minutes to reach the concourse. Nobody raises a ticket. Passengers simply stop trusting the screens and ask a person instead.
Silent player death
A media player behind a screen crashes, reboots into a desktop, and displays a wallpaper for eleven hours. Legacy systems have no heartbeat, so the first report comes from a passenger complaint.
Change requires a vendor
Adding a language, moving a boarding call five minutes earlier, or running a seasonal campaign becomes a change request with a lead time. Operations stops asking, and the system slowly drifts away from how the terminal actually runs.
What it does
Six things a FIDS has to get right.
Nothing here is exotic. It is the accumulation of details that decides whether a display estate is trusted or ignored.
01 · Ingestion
One flight record, many sources
Adapters normalise AODB and AMS records, AFTN and SITA Type B movement messages, and IATA AIDX exchanges into a single flight object. Where sources conflict, an explicit precedence table decides — per field, not per message — and the losing value is retained so an investigator can see what was rejected and why.
- Field-level precedence with per-airline overrides
- Late and out-of-order message handling
- Manual override console with mandatory reason codes
- Full-day replay for post-incident review
Design position: SE-FIDS is a consumer of operational truth, not its owner. It will not become a shadow AODB, and we will push back if you ask it to.
02 · Status rules
Status is derived, never typed
Boarding calls, gate opens and final calls are computed from scheduled, estimated and actual times, adjusted by walking distance to the gate and each carrier's own procedure. Rules are authored in the console, dry-run against a previous operating day, and promoted only once the diff is understood.
- Time-to-gate estimates per pier and per gate
- Per-airline procedure overrides
- Dry-run against historical days before promotion
- Versioned rule sets with one-click rollback
03 · Rendering
Legible at forty metres, in five scripts
Layouts are templates, not per-screen artwork. Type is sized against viewing distance rather than pixel dimensions, and language rotation carries proper font fallback for Latin, Devanagari, Arabic right-to-left and CJK — including the line-height and column widths those scripts actually need, which is where most signage systems quietly break.
- Portrait, landscape, mosaic and LED wall canvases
- Right-to-left layout mirroring, not just text direction
- Zero-flicker page transitions with pre-composited frames
- Contrast and type minimums enforced by the template
Glyph coverage of the shipped font stack. Anything below full coverage falls back to a bundled face rather than a system default, so a screen never renders a row of boxes.
04 · Resilience
The screen keeps working when the network does not
Every player holds a local cache of its last good render and a rules subset, so a core outage degrades to slightly stale times rather than a blank screen. A watchdog restarts a frozen renderer, and the monitoring console pulls a real screenshot from any endpoint on demand — so "is it actually showing something?" is a question you can answer from a desk.
- Active-active core pair with automatic promotion
- Local cache playback with a visible staleness indicator
- Watchdog restart and staged content rollout
- On-demand remote screenshot per endpoint
05 · Operations console
Airport staff and airline agents, same system, different powers
Role-based access lets a handling agent update their own carrier's flights and nothing else, while airport operations retains terminal-wide control. Every change is attributed, timestamped and reversible, and one action pushes an emergency message to every display in a zone or in the building.
- Per-carrier and per-zone permission scopes
- Attributed change log with reason codes
- Emergency broadcast to zone or terminal
- Incident timeline export for post-event review
06 · Passenger experience
Coordinated with what passengers hear
Visual boarding calls and PA announcements are triggered from the same rule, so the screen and the announcement never contradict each other. Quiet-airport policies suppress audio while keeping the visual call, and the same content stream feeds accessible kiosks for passengers who cannot read a wall-mounted display.
- Shared trigger for visual call and PA/VA
- Quiet-terminal mode with visual-only calls
- Accessible kiosk stream with screen-reader semantics
- Hearing-loop and visual-alarm coordination
Architecture
What actually runs in your data centre.
Six services, a message bus and a fleet of thin players. No component requires an internet connection to keep displays alive.
Feed adapters
One process per source protocol. Adding a carrier feed does not touch the core.
Rules engine
Deterministic, versioned, dry-runnable. The only place status is decided.
Render service
Composites frames server-side so players stay thin and cheap to replace.
Player agent
Runs on Android, Linux or Windows. Caches, restarts, reports and screenshots.
One system, every surface
The same flight record, rendered five different ways.
Each surface has a different job and a different failure mode. They share one source of truth and one rule set.
Departures summary
The highest-traffic surface and the one passengers photograph. It must paginate predictably, never reorder rows mid-read, and hold a flight visible long enough to be found again after a glance away.
- Stable sort with pinned imminent departures
- Pagination timed to reading speed, not a fixed tick
- Row-level highlight on status change, no full redraw
Gate display
A single flight, read at two metres by someone who is anxious. Boarding group, seat rows now boarding, and the honest time — not an optimistic one. Gate displays are where a wrong status costs you a misconnection.
- Boarding group and row-range sequencing
- Carrier branding within an airport-approved template
- Instant reassignment when the stand changes
Check-in row displays
Driven by the common-use desk allocation rather than by the flight schedule, because a desk serves whichever carrier holds it right now. The display follows the allocation system and reverts to a neutral state the moment a desk closes.
- CUTE/CUPPS desk allocation as the trigger
- Multi-flight desks with queue guidance
- Automatic neutral state on desk release
Baggage reclaim
Belt assignment comes from the baggage handling system, not the flight schedule, and it changes late. The reclaim display has to show the first-bag and last-bag signals honestly, because that is what stops passengers crowding a belt that has not started.
- BHS belt allocation with late reassignment
- First-bag and last-bag indicators
- Multi-flight belts with clear separation
Commercial signage
The same player fleet carries advertising and wayfinding, which is where non-aeronautical revenue lives. Operational content always wins: a campaign is pre-empted automatically by a boarding call or an emergency message, and the proof-of-play log records exactly what ran and what was displaced.
- Day-parted campaign scheduling with slot pricing tiers
- Automatic pre-emption by operational content
- Proof-of-play reporting for advertiser billing
Specifications
The page your systems integrator reads.
If something you need is missing here, ask. We would rather tell you it is unsupported than discover it during commissioning.
- Core services
- Feed adapters, normaliser, rules engine, content scheduler, render service, monitoring, operations console
- Runtime
- Containerised;
Docker Composefor single-site,Kubernetesfor multi-terminal - Data store
- PostgreSQL for the flight store and audit log; object storage for media assets
- Messaging
- Ordered per flight key, at-least-once delivery, replayable for a configurable retention window
- Player platforms
- Android 11+, Debian/Ubuntu LTS, Windows 10/11 IoT; ARM and x86
Architecture & components
- Databases
- AODB and AMS via REST, SOAP, database view or file drop, depending on your vendor
- Messaging standards
- AFTN, SITA Type B (MVT, LDM, PTM), IATA AIDX XML, ACRIS-aligned REST
- Airport systems
- CUTE/CUPPS desk allocation, BHS belt allocation, stand and gate management, PA/VA
- Conflict handling
- Field-level precedence table, per-carrier overrides, rejected-value retention
- Latency
- Under 2 s from message receipt to rendered frame under normal load
Flight data interfaces
- Resolutions
- Up to 4K per endpoint; LED walls driven as a single logical canvas across controllers
- Orientations
- Landscape, portrait, mosaic and irregular canvases; per-zone template inheritance
- Languages
- Unlimited configured, rotation typically 2–5; Latin, Devanagari, Arabic RTL, CJK, Cyrillic with bundled font fallback
- Scheduling
- Day-parting, seasonal calendars, campaign slots, operational pre-emption
- Transitions
- Pre-composited frames; no flash of unstyled or partially painted content
Display & content
- Core availability
- Active-active pair with automatic promotion; 99.9% availability target for the display estate
- Network loss
- Player continues from local cache with a configurable staleness indicator and escalation
- Health signals
- Heartbeat, render FPS, memory, display power state via DDC/CI where supported
- Remote verification
- On-demand screenshot from any endpoint; scheduled estate sweep
- Northbound
- SNMP traps, Prometheus metrics, webhook events to your NOC
Resilience & monitoring
- Authentication
- SAML 2.0 or OIDC against your directory; local accounts for break-glass only
- Authorisation
- Role-based, scoped by carrier, zone and action; separate emergency-broadcast privilege
- Audit
- Every change attributed with actor, timestamp, previous value and reason code; export on demand
- Network posture
- Players pull over TLS; no inbound route required into the display VLAN
- Air-gapped
- Supported in full — no component requires internet access
Security & access
- Deployment models
- On-premise (preferred), private cloud, or hybrid with edge render nodes per terminal
- Scale
- 500+ endpoints per cluster tested; multi-terminal via federated clusters
- Licensing
- Per display endpoint, tiered by volume; perpetual or subscription
- Support
- Standard included; Enhanced and Critical tiers available — see support tiers
- Escrow
- Source escrow available for on-premise deployments
Deployment, licensing & support
Interoperability
Systems we already speak to.
These are protocols and system classes we have built adapters for. Naming them is a statement of interoperability, not of partnership or endorsement.
AODBFlight database
AMSAirport management
AFTNFixed telecomms
SITA Type BMVT · LDM · PTM
IATA AIDXXML exchange
ACRISREST semantics
CUTE / CUPPSDesk allocation
BHSBelt allocation
PA / VAAnnouncements
SAML / OIDCIdentity
SNMPNOC monitoring
PrometheusMetrics
NTP / PTPTime sync
DDC/CIScreen power
Deployment
Three ways to run it.
On-premise
The default for airports. Everything inside your perimeter, air-gapped if required.
- Two application hosts plus storage
- No outbound internet dependency
- Your backup and DR regime
Private cloud
Core services in your tenancy, players reaching out over TLS from the terminal.
- Kubernetes with Helm charts
- Managed Postgres and object storage
- Suits multi-airport operators
Hybrid with edge render
Central control, a render node per terminal. Displays survive a WAN outage entirely.
- Per-terminal edge node
- Central rules and content authoring
- Best choice for large campuses
0Display estate availabilityContractual target, Critical tier
0Feed to glassMeasured at the render service
0Typical single-terminal go-liveDiscovery to cutover
0Vendor visits to add a languageConfiguration, not a change request
Before you ask
The questions that decide the deal.
What happens if the AODB goes down at 07:00?
The last known flight state persists and continues to render, marked with a data-age indicator once it passes a threshold you set. Rules that depend on live times stop advancing rather than guessing, and the operations console switches to manual mode so staff can drive status directly with an audit trail. Displays never blank and never invent a status.
Can you run alongside our existing FIDS during migration?
Yes, and we recommend it. The normal pattern is parallel running for two to six weeks: we consume the same feeds, render to a subset of screens — typically one pier — and you compare the two systems on live data before moving zone by zone. Rollback is a configuration change on the player, not a re-installation.
What does the passenger see if the network dies?
The player keeps rendering from its local cache, including the rules subset needed to advance time-based states. After a configurable staleness threshold it displays a small data-age marker so passengers are not misled. The console alerts your team immediately; the screen keeps working.
What does SE-FIDS deliberately not do?
It is not a resource allocation system and not a baggage reconciliation system. It does not decide stands, belts or desks — it consumes those decisions and renders them faithfully. If your airport lacks an allocation system, adding one is a different project and we will say so rather than growing FIDS into a shadow AODB that nobody owns.
How is it licensed, and what happens at renewal?
Per display endpoint, tiered by volume, available perpetual or subscription. On a perpetual licence the software keeps running if you stop paying support — you lose updates and SLA, not your displays. Source escrow is available for on-premise deployments so a supplier failure is not an operational risk.
Why not just buy from an established FIDS vendor?
If you need a global vendor's procurement paperwork and a twenty-year reference list, buy one — that is a legitimate requirement and we will lose that tender. Choose us when you want the rules and templates to be yours to change, a shorter path from request to production, and engineers who will tell you when your idea is wrong.
Also in the portfolio
Often deployed together.
See it running against your feeds.
Send us a sample AODB extract or a day of AIDX messages and we will show you your own operating day rendered on our stack — usually within a week, at no cost.