Separation Anxiety: Borrowing the Sky's Playbook (but not its numbers)

Air traffic control solved dense-traffic safety a century ago. Robot fleets have copied the clever half and skipped the half that keeps things alive.

Factories and warehouses are filling up with robots very quickly; but the improvements to the systems meant to keep them out of each other’s way are not matching that growth rate. It usually ends up as a mixture of fixed-path vehicles that follow tape or floor markers, free-roaming robots that build their own maps and reroute as they go, or collaborative arms (often, ironically, working an arm’s length) amongst humans. They all share the same concrete; and even legacy models are regarded as good news for general safety and efficient. However, the traffic management around them mostly isn’t.

What passes for traffic control on most floors today is primitive:

• A robotic vehicle follows a fixed route.

• It reserves a zone and makes everyone else wait until it’s done with it, or;

• Tt stops dead the instant a sensor sees something in its path.

Each of those rules is sensible on its own, and each is safe. But ratchet up the fleet density, and you end up with robotic vehicles attempting to work on top of each other. The outcome of that are production floors that deadlock, that freeze on a single obstruction, and whose throughput falls once you add enough robots. Past a certain density you get less work out of more machines, which is the opposite thesis of why anyone bought them.

The awkward part is that this is already a solved problem, just not by manufacturing engineers and warehousing consultants.

Air traffic control has spent the best part of a century moving traffic that’s faster, higher-stakes, and in places denser than anything on a warehouse floor, and it almost never loses an aircraft. It does that with a layered approach most robot floors have never thought to borrow, including the ones that like to describe themselves in air-traffic terms.

---

First come, first freeze

To illustrate my point, we need to take the mechanism apart. The floor gets carved into a graph of zones, and before a robot enters a zone it reserves it (akin to booking a meeting room), so everyone else waits until it’s free. It’s safe, it’s easy to reason about, but it throttles throughput the moment density climbs.

To keep this concrete I’ll use one example throughout, the kind of pinch point every floor has: a crossing where a pick aisle, a charging bay and a packing line all feed into a single intersection. Call it ‘Junction 12’. When one robot stops there, say for a person stepping across, the robot behind it reaches its own stopping distance and halts, the one behind that is already holding the next zone, and the approach backs up. Two robots that each want a zone the other is holding deadlock outright, the warehouse version of a circular wait, and neither moves until something external breaks the tie.

The deeper issue is that throughput doesn’t rise smoothly with fleet size. It rises, peaks, and then falls off once it reaches a point of critical density. Add robots past that sweet spot and they spend more time waiting on each other than working.

In the worst case the floor tips into a congested state where almost nothing moves. It’s a property of dense agents sharing space under simple local rules, and it’s been measured repeatedly. A well-known result that a robot navigating a crowd will freeze in place once the crowd gets dense enough.It still freezes even with perfect sensing, because the fix was never better perception; the fix is modelling the fact that the other agents will cooperate. But stop-on-detection has no concept of cooperation. It just has one rule, and it applies it to everything.

I‘ll address the obvious counter-argument early, because there’s probably some engineers that have already started yelling it at their screen – I’m aware that plenty of the industry already calls the fleet manager an “air traffic controller”. Omron markets it in exactly those words. Ocado describes the brain coordinating its grid as an air-traffic control system talking to a thousand bots ten times a second. Amazon pitches its newest layer as an intelligent traffic system.

My argument is that the industry appears to have copied the wrong half of air traffic control; but to clarify which half, that is, we should probably quickly run through how the tower systems actually work.

---

What the tower actually does

Most people would consider air traffic control as collision avoidance, as we see in films - a controller watching blips on a screen, and telling two of them to turn before they touch. It’s true that’s part of it, but it’s nowhere near the most important part.

The overarching concept in air traffic control towers is that of separation minima; which is the formal term for the minimum gap that must sit between two aircraft. The thing worth stealing as a transferable concept, is that it’s never one number. Aircraft are kept apart vertically, usually a thousand feet between cruising levels. They’re kept apart along their track (roughly three nautical miles near a busy airport and five miles further out); critically, the size of the gap changes with how well the controller actually knows where everyone is. When a controller has live radar, the in-trail gaps can be kept quite tight. But when they don’t, working a stretch of ocean purely off position reports and timing estimates, and that gap blows out to ten minutes or tens of miles. It is the same aircraft, in the same sky, but with a a far bigger buffer - purely because the position is inferred rather than seen. That distinction between procedural separation (you’re estimating where the traffic is) and surveillance separation (you can see it) is the single most useful idea in this whole article, so remember it, as we’ll be building on it later.

On top of separation sits flow management. The tower doesn’t just resolve conflicts where they happen. It meters traffic upstream so the conflict never forms, holding aircraft on the ground or slowing them hundreds of miles out so they arrive at the busy sector already spaced. The doctrine is explicit that delay should be absorbed early and far away, not by stacking aircraft over the airport hoping it clears.

Finally, there’s conflict resolution, which is proactive by design. A controller’s hardest job is spotting a converging pair minutes before it’s a problem and changing one aircraft’s heading, height or speed while there’s still room to do it gently. Automated tools back this up, flagging a looming loss of separation a couple of minutes out and a possible one up to twenty minutes ahead. This whole posturing is intended to make the system preventative and not reactionary.

And underneath all of it sits the last line. Every airliner carries an onboard collision-avoidance system (usually called TCAS) that works independently of the ground entirely. If two aircraft get dangerously close, their boxes talk directly to each other, agree who climbs and who descends, and order the crews to do it. Pilots are required to obey that instruction even when it contradicts the controller.

There’s some sobering examples of why that system and such rules exist, and the importance of it. Over Überlingen in 2002, two aircraft received those automated instructions, but one crew followed the controller’s contrary order instead. 71 people tragically died. So now the rule now is absolute. The automated last resort wins, because it keeps working when the layer above it is wrong.

That stack of independent layers has a name: defence in depth, or the Swiss cheese model, from James Reason back in 1990. Picture each safety layer as a slice of cheese with holes in it. Any one layer can fail, but an accident only gets through when the holes in every slice happen to line up at once. The genius isn’t any single barrier. It’s that no single failure reaches all the way through.

---

The half they copied, and the half they didn’t

So why that’s important: When the robotics world borrowed from aviation, it only took the optimizer, but left the institution.

The optimiser is the clever bit: a central brain with a god’s-eye view, computing efficient, deconflicted routes for the whole fleet. That part has been copied brilliantly. Amazon’s and Ocado’s systems are genuinely impressive pieces of coordination.

The institution is everything else. It’s the layered separation that flexes with how well you know where things are; the upstream metering; the proactive conflict resolution; the independent last resort that survives the central brain being wrong. And it’s talso the defence-in-depth philosophy tying them together.

This is the half which seems to have been omitted, and the gap is apparent in the standards. The dominant interface standard that lets different robot brands talk to one fleet manager, VDA 5050, explicitly puts traffic management, routing, congestion and deadlock resolution out of scope and leaves them to each vendor. There’s a standard pipe for commanding the robots and no standard at all for the hard part. Aviation would never accept that, as safety is the priority over efficiency - the hard part is the whole point, and should take precedence over everything else.

---

A floor that borrows the right half

So what does a floor look like if it borrows the institution instead of just the brain? We can revert back to Junction 12 examp[le to illustrate the point.

We can start by killing the single rule, and exchange one fixed number for a term which represents the space a robot needs, defined by cumulative sum of it’s component attributes which contribute to how it defines that space requirement.

That’s the sensing and localisation error, plus the distance covered while the robot decides what to do, plus its braking distance, plus how unsure it is about where the other party is, plus a designed safety margin.

The safety standards for mobile robots already compute something like this; but the piece that does the real work is , and it’s exactly the procedural-versus-surveillance idea from aviation. Two robots that both broadcast their position and intent can run a tight, “surveillance-grade” gap. A robot facing something that doesn’t communicate has to fall back to a wide, “procedural-grade” gap, because it’s guessing. One floor, two traffic classes, two separation regimes, and not one rule applied to everyone.

The part which shows why the single rule is so expensive and, neatly, where this whole analogy breaks is apparent though: On a floor, the space a robot sterilises around itself is an area, and area grows with the square of the radius. Pack robots that each need a clear radius S into a floor and the handling capacity scales roughly as:

Run one rule and you’re forced to set S to the worst case everywhere, the wide human-grade gap, even for two robots that could safely run close. Layer it, and robot-to-robot encounters drop to the tight gap. The ratio between the two regimes is the thing to remember:

In this theory, the penalty is squared. If the human-grade gap is three times the cooperative one, a single rule isn’t costing you a third of your throughput. It’s costing you roughly nine times the robot density at equal safety. (I’d probably treat that as a first-order packing argument rather than a control-theory proof, but the shape of it appears to hold true.)

The rest of the logic follows the tower systems:

• Meter robots upstream of Junction 12 so the crossing never saturates, the way aircraft are held before a busy sector, instead of letting four arrive at once and fight.

• Resolve conflicts by prediction, rerouting one robot down a parallel aisle before the crossing locks, rather than first-come-first-freeze.

• Build it in independent layers, so when the central brain hiccups or a robot drops off the network, planned separation still holds and the onboard stop still fires. The lesson of Überlingen, ported to a warehouse, is that the local safety stop has to keep working when the fleet manager is wrong. One dropped connection should never be able to reach through every layer at once.

---

Where the sky stops helping

I should caveat by stating that this can’t simplistically be lifted wholesale (I’d be lying if I pretended otherwise).

A factory floor is not airspace, and the differences are not just cosmetic. Aircraft are sparse in three dimensions and separate vertically; but your robots are more likely packed into two and can’t. That’s not a footnote, it’s the squared penalty above, the reason a margin that costs aviation a little costs most manufacturing operations a lot. Aircraft are cooperative, equipped, tracked and predictable. Controllers almost never deal with uncooperative traffic. Your floor likely has humans walking through it on their own schedule, equipped with nothing, and that’s where the deepest break is in this theory. The tower has room to breathe, the go-around, the holding stack, and the option to delay a problem in spare airspace. A packed aisle in a manufacturing facility usually has none of that slack. In essence, there’s nowhere to send the problem.

The parts of aviation that transfer are the parts that don’t depend on cooperation: layered separation, and defence in depth. The part that doesn’t transfer is the comfortable assumption that everyone in the system is equipped and behaving. So you need to design the human in as the worst case, not the exception. They’ll always get the widest envelope, permanently. They’re never assumed to communicate, signal or move predictably, because they won’t. And the densest, fastest, tightest-separation robot traffic gets physically kept out of the spaces where people roam, because the one thing a century of air traffic control can’t teach you is how to separate from something that doesn’t know the rules exist and never agreed to follow them.

So we can borrow the philosophy, the layering, the metering, the independent last resort, and the refusal to let one failure cascade.

But we can’t just borrow the numbers, as the most dangerous thing on your floor is the one agent the tower almost never has to deal with: a human, on foot, who has no idea they just froze Junction 12.

TH

---

You may find these of interest: