Components of a BHS/SATE Baggage System

01 · Solution components

Seven pieces, one behavior

One brain, four screens

A central backend API calculates state, priority and alarms exactly once. WinForms, desktop web, mobile web and Android all display that same result — no client recalculates anything on its own.

Real time by event, not by refresh

Every change (a new bag, a resolved counter, an alarm) is pushed instantly to every connected client, without waiting for anyone to reload the screen.

Offline-first on mobile

The Android app keeps the last known data and stays useful even if coverage is momentarily lost on the tarmac or in the handling area.

Alarms that get ahead of it, not ones that report late

The "in transit" baggage indicator is prioritized against each flight's real closing window — not a generic threshold applied the same way to everyone.

Connects to what you already have

It integrates with the airport's existing DCS, BHS, and operational database. It doesn't replace the physical infrastructure — it makes it visible.

Adapts to each installation

If an airport has no counter identification (common outside Spain), the system adapts: it hides that information instead of showing false or incomplete data.

Automatic reconnection and sync

After a network or server connection drop, every client recovers the full state on reconnect — it never keeps showing stale data without flagging it.

02 · Illustrative use case

Any flight, minute by minute

Illustrative scenario

Flight departing at 14:30

STD 14:30 · short-connection destination

−3 h

The flight already appears in the list, but check-in hasn't opened yet. LOW — no baggage to watch yet, no attention needed.

−2 h

Check-in opens. The first bags start getting checked in and the system automatically starts monitoring the flight — with more than 30 min to closing, priority is NORMAL.

−45 min

There's still a fair amount of baggage in transit: 18 bags unconfirmed. Still within what's expected at this point — priority stays at NORMAL.

−30 min

The pace has been good: only 3 bags left. But the flight crosses the 30-minute threshold right here, and priority jumps to CRITICAL even with so few left.

CRITICAL activates automatically the exact instant both conditions are true at once — fewer than 30 minutes to closing and baggage still "in transit". It doesn't matter if 3 bags are left or 30: it's the combination that triggers the alarm.

−15 min

The 3 bags get confirmed before entering this final stretch before closing. The counter hits zero and priority drops to HIGH — no baggage at risk anymore, but the system keeps watching until departure.

Scenario built from FlightSort's actual priority logic: LOW → NORMAL → CRITICAL (fewer than 30 min to closing + baggage still in transit, regardless of how much) → HIGH once resolved. This isn't a generic marketing promise.

What the solution includes, and what a real flight looks like inside it