Personal story

Why do i care?

I grew up in Paris. Which means I grew up in the metro.

Line 13, mostly. If you know it, you're already nodding. One of the busiest, most overcrowded lines in the entire network, infamous for delays, crushing peak-hour density, and the particular kind of tension that builds on a platform when three trains have passed and you still can't board. I've stood on those platforms watching the minutes tick by, wondering whether the train that eventually arrives will be safe to get into. I've seen people faint from the heat and the pressure. I've watched arguments turn into something more serious in the narrow corridors of Châtelet–Les Halles.

You don't forget those experiences. And when I later found myself on the other side, working with metro operators, sitting in control rooms, and understanding how decisions get made, I kept coming back to the same question: how is it possible that the people running this network don't have a real-time picture of what's happening on their own platforms?

The answer, it turns out, is both simple and uncomfortable. The data doesn't exist. Or rather, it exists in fragments, in averages, in historical models that are always slightly behind reality. Nobody is watching the platform. Not really.

That gap between what passengers experience and what operators know is the problem VAELLA was built to solve.

Before starting VAELLA, I spent several years as project lead at KONE, working closely with one of Europe's major metro operators on how data could improve day-to-day operations. I didn't visit dozens of networks. I went deep into one, its control rooms, its dispatching teams, its maintenance schedules, its stakeholder politics.

What I found there confirmed everything I had felt as a passenger. The challenges are more universal than you'd think.

The blind spot

The real problem isn't counting people. It's the blind spot between the gate and the train

The operator I worked with had ridership data. Ticket gate counts, historical flow models, manual surveys run by a dedicated analyst with a clipboard. What they didn't have was a real-time picture of what was happening on the platform right now.

That gap between turnstile and train is where most operational problems live. Overcrowding builds there. Scheduling errors compound there. Security interventions happen too late, or unnecessarily, because of it.

Once you fill that gap with continuous, zone-level occupancy data, a surprising number of downstream problems become solvable.

Dispatching

Dispatching teams are drowning in alerts and still flying blind

When I first sat with the dispatching team, I expected to find people who lacked information. What I found was the opposite: they were overwhelmed by it. Feeds from hundreds of cameras, radio communications from field teams, service notifications, system alerts, a constant stream of signals demanding attention.

And yet, for all that noise, nobody could tell them with confidence how many people were on platform 3 right now, or whether the density on the southbound side was about to become a problem. The information that would actually help them make faster, better decisions, platform-level occupancy in real time, simply wasn't there.

The consequence is a dispatching model built on instinct and averages. Teams intervene based on experience and gut feel, deploy security based on historical patterns, and respond to incidents after they've already developed. In a busy network, that reactive posture is expensive, in staff hours, in unnecessary deployments, and occasionally in passenger safety.

Our pilot validated the technology: the data was accurate, the platform picture was real-time, and the occupancy readings matched what station agents were seeing on the ground. But technical validation is not the same as operational adoption. Getting a dispatching team to change how they work based on a new data source takes more than a proof of concept. It takes time, trust, and a deployment designed around how they actually operate, not around what the technology can do. That lesson shaped everything about how we built VAELLA.

Scheduling

Train scheduling is still largely based on averages, and averages are wrong half the time

The timetables I encountered were built on peak-hour averages, which by definition underserve demand half the time and oversupply the other half. The calculations hadn't fundamentally changed in years, not because the teams didn't want better data, but because the data simply didn't exist.

Real-time platform occupancy changes that equation. When you know how many passengers are waiting on which platform, in which direction, right now, and you have enough history to predict how that will evolve over the next ten minutes, you can start making dynamic decisions rather than static ones.

When we first showed this to the scheduling team, the reaction stayed with me: "We knew something like this must exist. We didn't think we could actually have it."

Equipment

Equipment decisions are being made blind

This one surprised me most. Escalators, platform doors, ticket machines, signage, capital investment decisions worth tens of millions of euros, made largely on manufacturer lifespan estimates and service call frequency.

The more modern equipment manufacturers do provide connected APIs, and when they work, they're useful. But here's the reality on the ground: not all equipment is connected. Older assets aren't. And the equipment that is connected speaks a different language depending on who made it. Every manufacturer has their own interface, their own data format, their own dashboard. The result is a patchwork of partial visibility. You know what your newest escalators are doing, if you've integrated that vendor's platform. You have no idea about the rest.

It's more widespread than you might think. According to a Metro Magazine industry survey, 43% of transit officials cite merging data across platforms as their top operational frustration, and that's just the equipment that is already connected. Industry analysts consistently flag fragmented legacy infrastructure as the primary barrier to smarter railway operations, a problem compounded by the fact that proprietary systems rarely talk to each other even when the technical capability exists.

Nobody had a unified picture of actual usage across the full station. Nobody knew which escalator, connected or not, new or old, was carrying three times the load of the one beside it, or whether the ticket machine placement matched where passengers actually walked.

That's exactly where independent occupancy sensing fills the gap. It doesn't rely on equipment being connected or manufacturers sharing data. It observes the flow of people around every asset, regardless of make, age, or vendor, and builds a usage picture that no single manufacturer could ever provide. For procurement teams building business cases for capital investment, that kind of truly vendor-neutral evidence is rare. And it changes the conversation entirely.

Hidden cost

The hidden cost of running stations inefficiently

Every one of these blind spots has a price tag, and most of it never appears on a single line in the budget.

To put it in perspective: the Paris metro runs across 302 stations on 16 lines, with total operational costs running at roughly €1 billion a year when combined with the RER network. That works out to an estimated €2–3 million per station per year, around €6,500 a day to keep a single station running. Of that, electricity alone accounts for over 10% of operating spend.

And yet most of it is driven by fixed, assumptions-based scheduling rather than real demand.
Escalators running in both directions during off-peak hours. Lighting systems that don't know whether a platform is empty or packed. Ticketing machines, screens, and kiosks fully powered overnight with almost no usage.

That's not an engineering problem. It's a data problem.

Then there are the staffing costs that don't show up as waste because nobody is measuring them. Security teams dispatched to platforms that turned out to be fine. Maintenance crews called out for reactive repairs that predictive data could have scheduled in advance. Supervisors making judgement calls that a clearer operational picture would make obvious.

And finally, the cost that's hardest to quantify but arguably the most significant: the cumulative effect on ridership. Passengers who experience overcrowding, delays, or broken equipment don't file formal complaints, they quietly switch to another mode of transport. Every unnecessary friction at platform level is a slow leak in revenue that rarely gets traced back to its source.

When running a single metro station costs in the order of €2–3 million a year, even a 10% efficiency gain through smarter energy and staffing decisions pays for an operational intelligence deployment many times over.

Incident risk

The incident nobody wants to explain to the board

Every senior operations professional I've spoken to carries the same quiet anxiety. Not the daily frustrations, the delays, the broken escalator, the staffing shortage. Those are manageable. The real fear is the incident that escalates faster than anyone could respond to.

A platform that fills beyond safe capacity during peak hours. A crowd surge in a narrow corridor. A situation where the first notification your control room receives is not an automated alert but a call from a station agent already in the middle of it.

These scenarios don't announce themselves in advance. They develop in the gap between what your systems can see and what is actually happening on the ground, exactly the blind spot we've been talking about. By the time the cameras confirm the problem, the window for an orderly intervention has already closed.

The question a board asks after an incident isn't "why didn't you react faster?" It's "why didn't you know sooner?" Real-time platform occupancy doesn't eliminate risk. But it moves the moment of awareness from after a situation has developed to before it becomes unmanageable, and that difference is everything.