Airline Operations Control Software Problems: The 7 That Slow Recovery and Cost Real Money, and How to Avoid Them

Why does one screen for the duty manager become a network constraint engine?

The brief starts small: give the duty manager a single picture so nobody has to rebuild the day on a whiteboard. Then you list what has to be on that picture. Rotations with tail assignments. Crew rosters with legality state, evaluated forward across the whole pairing rather than the next sector. Maintenance status including deferred items and planned inputs. Airport and airspace constraints, meaning slots, curfews and stands. Movement data arriving continuously. Five sources, five owners, five refresh behaviours.

This is specific to airline operations because the constraints interact rather than stack. A tail swap changes crew legality, maintenance opportunity and slot position at the same time, and the change is only valid if all three still hold. A picture that shows the five things side by side without evaluating the interaction is a prettier whiteboard, and controllers will keep the real whiteboard next to it.

The fix is to fix scope around the interaction, not the display. One timeline with aircraft down one axis and time across, where a rotation block carries its crew legality, its maintenance constraint and its slot position as properties. When a controller drags a rotation to another tail, the consequences light up before anything is committed. Projects that scope a dashboard deliver a dashboard, and the twenty minutes at the start of every disruption that get spent assembling information do not go away. Say plainly at kickoff that the deliverable is a consequence preview, and everything else follows from that.

What goes wrong when schedule, rotation, crew and maintenance data are joined?

Each system is internally correct and they disagree at the edges, which is exactly where recovery happens. Flight identity is the first problem: the same flight is a flight number in the schedule, a leg in the rotation, a pairing segment in crew, and a movement message with a registration and an off block time. Joining them needs a key that survives a date change across midnight, an equipment substitution and a diversion, and most airlines discover mid build that no such key exists consistently.

The second is state timing. Crew legality is computed by the crew system against a roster that is being amended while you read it. Maintenance status reflects the last technical log entry that was actually entered, not the one the engineer is writing now. So a join taken at one instant can show a combination that was never simultaneously true.

The fix is an internal operational identity for every leg, created once and mapped to each source system's identifier, with the mapping maintained through substitutions and diversions rather than reconstructed. Then hold source values with their timestamp and show data age on screen. Where a value is being amended upstream, show it as in flux rather than as fact. Airlines that skip the identity work end up with duplicate legs after every diversion, and a controller who sees two of something loses trust in the whole screen within a week.

Why do real time feeds break after launch?

They rarely break loudly. Movement messages queue behind a slow consumer and arrive in bursts, so the screen is correct and eleven minutes late. A crew system integration keeps responding while the data behind it is being rebuilt after a roster publication, so legality answers are stale for an hour. A maintenance interface returns an empty set instead of an error when a session expires, which renders as no constraints rather than as unknown.

That last pattern is the dangerous one. In an operations control centre a stale display is worse than a blank one, because controllers act on it. The failure only surfaces during disruption, when everything is moving and nobody has spare attention to notice that a panel has not changed in twenty minutes.

The fix is to design for feed failure explicitly rather than as an exception. Every panel shows the age of its data. A feed that misses its expected cadence marks itself degraded and says so in words a controller can act on. An empty response is treated as unknown, never as none. Add a synthetic heartbeat on each interface so a quiet feed is distinguishable from a quiet operation at three in the morning. And build the replay path early, because after any outage you need to reprocess the messages that arrived while you were down, and an airline that cannot replay reconciles by hand at the worst possible time.

What happens when slots, curfews and downline crew legality are not covered?

These three are what turn a recovery plan into a second disruption. Downline legality is the most common. A swap is legal now, the crew goes illegal at sector four, and the plan collapses in the evening rather than the afternoon, when there are fewer options and more passengers already displaced. Curfews at noise restricted airports are absolute in a way that costs a diversion, and they are frequently held in a station manual rather than in any system. Coordinated airport slots and departure slots are hard constraints that a rescheduled departure can violate silently, and the violation is discovered by someone else.

The reason these gaps persist is ownership. Crew owns legality, network owns slots, station management owns curfews, and none of them is in the control centre at 15:40 when the hub closes.

The fix is to evaluate all three at the moment of the proposed change rather than after it. Crew legality has to be evaluated forward across the entire pairing, not the next sector, which means the integration has to support a hypothetical rather than only a current state. Slots and curfews belong in the system as data with effective periods, validated on every proposed movement, with the violation shown as part of the consequence preview. Maintenance opportunities become blocks on the same timeline so a controller can see the Thursday night input they are about to consume. This is unglamorous integration work and it carries most of the value, because expensive mistakes in a control centre are almost never bad judgement.

Should you build custom or configure what you already own?

Configure and stop if you already run a vendor's full suite and controllers trust it. If NetLine, Sabre AirCentre or NAVBLUE N-Ops and Crew owns your schedule, crew and operations together, building alongside creates a second source of truth, which in a control centre is genuinely dangerous rather than merely wasteful. Take the vendor's configuration path, and spend the budget on the training and process discipline that makes the existing tool authoritative.

Build nothing at all if you run under roughly twenty aircraft point to point with no bank structure. A duty manager, a whiteboard and a phone genuinely handle that operation, and software will not improve it enough to justify itself.

The build case appears in the middle: your crew system or maintenance system is not from the same vendor as your operations system, so constraints reach controllers by telephone. Controllers rebuild the day on paper during disruption. Your recovery decisions cannot be reconstructed afterwards, so post disruption reviews run on memory. Your reactionary delay bucket is large and unexamined. Or you have a hub bank where cascading failure is the dominant cost and nobody can see the cascade forming. In that situation the build is an integration and visualisation layer over the incumbents, not a replacement for them, and framing it that way is what keeps it from failing politically.

How do hidden costs get into an OCC software quote?

The largest hidden cost is not technical. It is access to upstream data from other vendors, which is a commercial negotiation with its own timeline and sometimes its own licence fee. Airlines quote the build and forget that the crew system vendor has to agree to expose a legality evaluation endpoint, and that conversation can take longer than the sprint that consumes it. Start it before the build starts, and treat a signed data access agreement as a milestone.

Second is the real time requirement itself. A screen that lags will be abandoned, so the latency budget drives architecture choices, load testing and infrastructure that a reporting tool never needs. Third is multi hub or multi certificate operations, since each carries its own bank structure, rules and station practices, and a second hub is close to a second configuration project.

Fourth is passenger data access, which usually means working through a reservation system integration with its own constraints. Fifth, and routinely omitted, is twenty four seven operational support, because a control centre system is on the critical path at three in the morning. In Digital Heroes delivery experience a first release giving controllers a single live timeline with constraints evaluated in place, plus manual recovery with consequence preview and a decision audit trail, runs 130,000 to 275,000 US dollars over 16 to 24 weeks, with a full platform at 400,000 to 1,000,000 over 12 to 20 months.

What separates an OCC build that works from one that fails?

The builds that work put the picture before the optimiser. In every control centre project we have delivered, the single timeline with live constraints removed most of the operational pain, and automated recovery added value much later and only once controllers already trusted the underlying picture. Vendors sell the optimiser because it demonstrates well. Controllers use the picture because it lets them work faster with less risk.

They also make every proposal explain itself. A recovery option presented as a score is ignored, because a duty manager has to defend the decision the next morning to a regulator, a union representative or a chief executive. Three ranked plans, each stating which flights are protected, which are cancelled, which crews are affected and how, what happens to tomorrow's first wave and an estimated cost, get used. Recording the alternatives that were on the table turns the post disruption review from an argument into evidence, and that audit trail is often worth more than the recovery logic.

The builds that fail share three habits. They are designed without anyone spending a shift in the control centre, so they miss the behavioural detail that governs adoption: how many screens a controller already has, what gets shouted across the room, which phone rings most. They capture delay codes after the fact from a movement log, which produces a large reactionary bucket nobody can decompose, when the controller knew the primary cause at the moment they held the departure. And they treat passenger impact as out of scope, so cancelling a flight with forty passengers and twelve connections looks identical to cancelling one with a hundred and sixty passengers and ninety connections onto long haul.