← All posts

How an Idea From Music Research Tracks Shuttle Fleets

By Quantiva Team

How an Idea From Music Research Tracks Shuttle Fleets

A leading shuttle manufacturer, with both electric and combustion fleets, came to us to build the software behind their largest deployment: an operator moving thousands of riders a day across a major airport. They needed three things:

  • Real-time tracking of the fleet,
  • Accurate arrival times for riders, and
  • Proof to the airport that service levels are being met.

Off-the-shelf transit software wasn't built for this, so the company had built its own version in-house. Even that couldn't reliably give riders an accurate ETA. Why the problem is so hard is the whole story, and the answer came from an unlikely place: research on tracking live musicians through sheet music.

Why shuttles break standard transit software

Almost every transit software package rests on one assumption: a trip runs from A to B. A vehicle departs, arrives, ends the trip, and begins another. The data model inherits that assumption, and so do the arrival logic and the reporting.

Shuttles don't fit that mold, and they don't all behave alike. Some run a schedule; others run on frequency with no timetable. Some loop the same stops all day; others don't. A driver might start partway along the route, or skip a stop with nobody waiting. A vehicle might finish a lap, park to refuel or let the driver take lunch, and stay assigned to the route the whole time.

They improvise, too, taking detours, rerouting around a closed lane, or cutting across the lot when a flight sends a crowd to one terminal. Much of an airport route runs on private service roads that public maps don't show. You can't pre-map a path a shuttle invents on the spot.

So the software has to predict what the driver will do next and report it correctly, both to the operator and to public feeds like Google and Apple transit. It has to do this from noisy GPS alone, with no door sensors and no onboard signal to tell it when a vehicle is in service.

Feed that into trip-based software and it fails in quiet, trust-destroying ways. The system decides a trip has "ended." A vehicle leaves the mapped route and the tracker loses it. ETAs flip, and arrivals get double-counted or lost.

For an operation that runs on reliable arrival times, this breaks the product. No amount of debugging fixes it, because the code is doing its job. The model behind it is wrong. The software does exactly what it was built to do, against a problem it was never built for.

The hard part: Where is the vehicle, really?

The hardest question is the most basic one. Given a noisy GPS signal, where on the route is this vehicle right now?

On a loop that overlaps itself, the obvious answer is wrong. The outbound and return paths run close together, so the nearest point on the map can be a spot the vehicle won't reach for several minutes. Snap to it and the map lies. A shuttle in a parking garage, where GPS is worst, appears to teleport across the route.

This is where the music comes in. There's a field of research called score-following, in which software listens to a live performance and tracks, note by note, where the musician is in the written score, even as they speed up, slow down, or repeat a passage. It's the same shape of problem: a live, imperfect signal moving through a known sequence that can repeat and double back. The question isn't "what's the closest note?," it's "given everything I've heard so far, where in the piece are we?"

We adapted that idea. Instead of recalculating the position from the nearest point on the map every second, the system weighs the whole recent history of movement and commits to the single most coherent answer. The route is the score, even when it isn't on any public map, and following it through bad GPS and detours is the performance.

We modeled the day the way a driver lives it, one lap after another, so the handoff between laps that trips up other systems becomes routine.

None of this is magic AI. It's well-grounded probabilistic modeling, chosen to fit the problem. The cleverness is in the fit, not the trick.

The foundations under it

Tracking is the visible part. Underneath, the platform is built to a higher bar than the story so far shows. Many operators run on one shared system, so each operator's data is walled off from every other's. That separation is enforced automatically, so a leak between operators can't ship by accident.

Access is just as controlled. Everyone from a platform admin to an operator's dispatcher to a rider sees only what they should, with no way to reach across that line. Every change to the record is logged, so the service numbers an operator reports up the chain can always be traced back to what actually happened.

Why the reports are the real product

For the operator, the live map and the route views that depict how shuttles are spaced run the daily operation, and dispatchers lean on them constantly. The compliance reporting is what renews the contract.

The airport holds the operator to measurable service levels: how often a shuttle arrives, when vehicles depart the terminal, and how many are running at once. Those metrics aren't a dashboard nicety. They are the contract.

Most systems reverse-engineer those numbers from raw GPS with a pile of heuristics, which is exactly why the numbers are open to dispute. Ours are computed from the same coherent record of what each vehicle actually did, lap by lap, terminal by terminal. Get the model right and the reports come out trustworthy without extra effort.

The takeaway

The breakthrough didn't come from transit expertise. It came from recognizing that tracking a shuttle and following a musician are the same problem, then borrowing a solution from a field nobody in mobility was looking at.

That's the work we do. The obvious tool rarely solves a hard enterprise problem, and a team that has only worked one way will reach for that way again. We connect a problem in one industry to a solution proven in another, then get the domain model right so the clever part holds up in production. Here, this approach produced software both simpler and more correct, for a problem that off-the-shelf vendors had given up on.

If the standard tools don't fit your problem, there's usually a better idea waiting somewhere less obvious. Quantiva can help you find it, and apply the machine learning and AI to turn it into working software. Get in touch.

MobilityMachine LearningFleet OperationsReal-Time SystemsSaaS