Fast-Time Simulation: Testing Decisions Before You Make Them

Some decisions cannot be A/B tested.

You cannot close a runway for thirty minutes to see what happens. You cannot add five flights an hour to find out whether the taxiways absorb it. You cannot try a new pushback procedure on a Tuesday and roll it back on Wednesday. The experiment itself is the damage.

Fast-time simulation is how you run those experiments anyway.

Fast-time simulation is a modelling technique that reproduces hours or days of a real operation in seconds, with no human in the loop, so the same scenario can be run hundreds of times and compared against alternatives. It is the engine underneath most digital twins of physical systems: airports, ports, factories, hospitals.

What fast-time simulation means

A real-time simulator runs at the speed of life. One hour of operation takes one hour. That is what flight simulators do, because a pilot has to experience the thing at human speed.

Fast-time simulation throws that away. It has no human in the loop, so it does not need to respect the clock. A full day of airport operations can be modeled in seconds.

That single property is what makes it useful, and for a reason that is not obvious: it lets you run the same day hundreds of times.

Why one simulation run tells you nothing

The systems worth simulating are full of randomness. Aircraft arrive a few minutes early or late. Turnaround takes longer when a jet bridge sticks. Taxi times shift with traffic. None of these are fixed numbers, they are distributions.

So a single simulation run gives you one possible day. It might be an unusually smooth day or an unusually bad one, and nothing in the output tells you which.

Run it three hundred times and you get the shape of the outcome. Not "the delay will be nine minutes," but "the delay is usually six to eleven minutes, and about one day in twenty it exceeds twenty." That distribution is the actual answer, because it is what you plan capacity and staffing against.

This is the same reasoning behind Monte Carlo methods anywhere else. One sample is an anecdote. The distribution is the finding. The same trap shows up in model evaluation, which I wrote about in a single test split isn't enough to compare models.

What goes into a fast-time simulation model

A useful simulation of a physical operation has four parts.

The infrastructure. A digital version of the place. Runways, taxiways, gates, airspace sectors, and crucially the rules connecting them: which taxiway feeds which runway, how much separation is required, which gates take which aircraft.

The actors. Aircraft, controllers, ground equipment. Each follows the same procedures its real counterpart follows.

Time and randomness. The model advances event by event, second by second. Arrival times, turnaround durations, taxi times, and delays are drawn from probability distributions rather than fixed values. This is what makes repeated runs produce different days.

The scenarios. A baseline representing today, then the variants you actually want to compare against it.

That last part is where the value is. A model that only reproduces the present is an expensive way to describe something you already have. The point is the comparison.

How a fast-time simulation study actually runs

It goes in one direction, and each step depends on the one before it:

Gather. Operational history, schedules, procedures, infrastructure layout. This is most of the work and the least discussed part of it.

Model, repeatedly. Build the digital version and run it many times, so the randomness has room to express itself.

Evaluate. Compare scenarios against the baseline on metrics that matter operationally: throughput, taxi times, queue lengths, delay propagation. Simulation tells you how a system behaves; mathematical optimization tells you what to do about it, the way a mixed-integer flight cancellation model I built picks which flights to drop once a shortage is unavoidable. They are complements.

Understand the system. This is the actual deliverable, and it is easy to skip past. The number the model produces matters less than knowing why the system behaves that way, because that understanding transfers to situations you never simulated.

The questions it answers

They all have the same shape: what if.

What happens if we add five flights per hour. What happens if a runway closes for thirty minutes at the worst possible time. What happens if we change taxi procedures. What happens if weather deteriorates during the busiest bank of the day.

A dashboard cannot answer any of these, because a dashboard reports what happened. These questions are about things that have not happened yet, and in most cases must never be allowed to happen unplanned.

One pattern shows up constantly and is worth knowing in advance: the disruption is rarely the expensive part. Close a runway for thirty minutes and the thirty minutes are not the problem. The problem is the queue that builds while it is closed, which then has to be worked off after it reopens, at a rate the system was never designed for. Recovery takes considerably longer than the outage. A model shows you that curve. Intuition consistently underestimates it.

When a digital twin is worth building

You need this when the system is complex, the cost of failure is high, and real-world experimentation is risky or expensive. All three, not one.

You do not need it when the system is simple, when failure is cheap, or when a dashboard already tells you what you need. Building a digital twin of something you understand is an expensive way to confirm what you know.

The honest test is whether a decision is genuinely waiting on the answer. If nobody is going to act differently based on the result, the model is a demonstration rather than a tool.

The real argument

The value is not that the simulation predicts the future accurately. It will not. Every model is wrong about something, and the useful ones are wrong in ways you can characterize.

The value is that it converts a decision from an argument about opinions into an argument about evidence. When someone senior says the airport can absorb more traffic and someone else says it cannot, that disagreement has no resolution mechanism. Both people are reasoning from experience, and both sets of experience are real.

A model does not settle it by being right. It settles it by making the assumptions explicit, so the disagreement moves to something checkable.

In complex systems, confidence without simulation is a liability. Not because people are wrong, but because nobody can hold that many interacting queues in their head at once, and being confident anyway is exactly how you end up committing capital to the wrong bottleneck.