DEV Community: Dimitri Rudenko

Counting people at a bus door: why 98% accuracy is an engineering problem, not a sensor spec

Dimitri Rudenko — Wed, 04 Nov 2026 16:28:08 +0000

Disclosure: I work at ACOREL, a French company that builds automatic passenger counting (APC) systems for public transport. This post is about the engineering problem, not about our products.
A bus door is about a metre wide. People go in, people go out. Counting them sounds like a weekend project with a camera and an object detector.
Then you look at what the numbers are used for. Transit agencies plan timetables with them. In integrated fare systems, operators split ticket revenue based on how many passengers each one carried. Public service contracts pay per passenger-kilometre. At that point, 95% accuracy isn't "pretty good". It's a 5% error in somebody's revenue.
Getting from 95% to 98% is not about buying a better sensor. It's about the whole chain: geometry, tracking, edge processing, validation and data integration. Here's how that chain works.

1. Why the doorway is a hard place to count

A doorway is a narrow, crowded, constantly changing scene. A few things that break naive counting:

People stop. Someone stands in the door to let others out, or to check the route number. A track that lingers can be counted twice, or not at all.
People overlap. In rush hour, two or three people move through at once, shoulder to shoulder. From above they can merge into one blob.
Not everything that moves is a passenger. Prams, suitcases, wheelchairs, bikes, dogs, a backpack held at chest height.
Children walk close to adults. Small, close together, sometimes carried.
People change their mind. One step in, one step back out. Net zero, but two line crossings.
The environment changes. Sunlight through the door, darkness at night, rain, reflective floors, vibration while the vehicle moves.

Each of these produces noise in the raw signal. Most of the engineering is about removing that noise without removing real passengers.

2. Why depth beats a normal camera

A regular 2D camera pointed at a doorway sees colours and shapes. It struggles with shadows, sudden light changes and people who overlap. It also captures faces, which creates a privacy problem before you've written a single line of code.
Most modern APC systems use 3D sensors mounted above the door, looking straight down. From above, people rarely hide each other, and every point in the image has a height. The two main approaches:

The key advantage of depth is simple: a head is a local maximum in a height map. That one property makes it much easier to separate two people walking side by side, ignore a suitcase on the floor, or tell a pram from the adult pushing it.

3. The counting logic: detect, track, cross a line

Once you have a depth map, the pipeline usually looks like this:

Detect candidate heads: local height maxima above a minimum height, with a plausible size.
Track each candidate across frames, so the same person keeps the same ID.
Count when a track crosses a virtual line in the doorway, in a given direction.
Gate counting with the door state: count only while the door is open.
A simplified version of the line-crossing step:

# Simplified illustration, not production code.
# Each track is a sequence of (x, y) positions of one detected head.
# The counting line is y = LINE_Y; inside the vehicle is y > LINE_Y.

LINE_Y = 0.0
MIN_TRAVEL = 0.25  # metres travelled past the line before we trust a crossing

def count_track(positions):
    start_y = positions[0][1]
    end_y = positions[-1][1]

    # Ignore tracks that never really crossed: someone who stepped
    # in and back out, or stood in the doorway.
    if abs(end_y - LINE_Y) < MIN_TRAVEL or abs(start_y - LINE_Y) < MIN_TRAVEL:
        return 0, 0

    if start_y < LINE_Y < end_y:
        return 1, 0   # boarding
    if start_y > LINE_Y > end_y:
        return 0, 1   # alighting
    return 0, 0

The hard part isn't this function. It's everything that feeds it: keeping IDs stable when two people merge and split, deciding whether a small height maximum is a child or a bag, and handling a track that starts or ends outside the field of view. Counting on the net movement of a track, not on every crossing, is what stops one indecisive passenger from becoming two.

4. Privacy by design: process at the edge, export only counts

This is the part I find most interesting from an architecture point of view.
In Europe, anything that can identify a person falls under GDPR. You could collect images, send them to a server and anonymise them there. But then you've built a system that handles personal data at every step: storage, transfer, access control, retention, breach risk.
The alternative is to make sure personal data never exists outside the sensor:

[3D sensor] -> depth frames -> [on-device processing] -> events -> [vehicle gateway] -> [back office]
                                  detect / track / count       boardings, alightings,
                                  frames discarded             door ID, timestamp

The result is a system where privacy isn't a policy added later. It's a property of the architecture. That's much easier to defend to a regulator, a city council or a passenger who asks, "Is that a camera?"
The trade-off is real, though. If you don't keep frames, you can't go back and re-run a better algorithm on last month's data. You have to get the edge processing right, and you need a separate, controlled way to collect reference data for validation.

5. Validation: how do you prove 98%?

"Our sensor is 98% accurate" means nothing without saying how it was measured.
The usual approach is to compare the system's counts with ground truth: manual counting, or counting from a reference video recorded only for the test, under controlled conditions. Then you look at two different things:

Per-event error: how far off each door opening is.
Systematic error (bias): whether the system over- or under-counts on average across many events.

The distinction matters because errors cancel out. A system that counts +1 at one stop and -1 at the next looks perfect in aggregate. For planning, that may be fine. For revenue, what matters most is that there's no systematic bias: an operator must not be consistently over- or under-paid.

# Simplified bias check over a validation sample
def bias(system_counts, reference_counts):
    total_system = sum(system_counts)
    total_reference = sum(reference_counts)
    return (total_system - total_reference) / total_reference

# +0.008 means the system over-counts by 0.8% on this sample

In Germany, the industry standard VDV 457 formalises this. It defines how to build the sample, how to compare with reference counts, and how to show statistically that the bias stays within a tight limit. Operators across Europe use it as a reference in tenders.
This is also why a lab figure is worth very little. Accuracy has to be shown in your conditions: your vehicles, your doors, your rush hour, your winter coats and prams. A sample that only covers quiet midday trips will flatter any system.

6. From counts to decisions: the data pipeline

A count from one door is not useful yet. Before anyone can plan a timetable or split revenue, the data has to go through several steps:

Aggregate doors into vehicle-level boardings and alightings per stop.
Match to location and schedule: combine with the vehicle's GPS or AVL data and the timetable (often GTFS) to know which stop, trip and route each event belongs to.
Check plausibility: over a full trip, boardings should roughly equal alightings, and the load on board can never be negative.
Balance and correct: distribute small imbalances in a documented, consistent way, so corrections don't introduce their own bias.
Integrate: send the clean data to the systems that use it: scheduling, ticketing and revenue sharing, network planning, real-time crowding information for passengers.

The plausibility check is a nice example of how a domain constraint catches errors that the sensor alone can't see:

def check_trip(stops):
    # stops: list of (boardings, alightings) in stop order
    load = 0
    for i, (on, off) in enumerate(stops):
        load += on - off
        if load < 0:
            return f"Negative load at stop {i}: check counts or stop matching"
    if abs(load) > 2:
        return f"Trip ends with {load} passengers on board: imbalance to review"
    return "OK"

In my experience, this is where many projects lose value. A good sensor with poor integration produces a nice dashboard that nobody uses. A good sensor with clean, validated data in the scheduling and revenue systems changes real decisions.

Takeaways

Accuracy is a property of the whole system, not of the sensor alone.
Depth sensing from above turns a hard vision problem into a much easier geometry problem.
Processing at the edge and exporting only counts makes privacy a property of the architecture.
Validate against ground truth, in real conditions, and look at bias, not only average error.
The value appears only when counts are matched to the schedule, checked for plausibility and integrated into the systems that make decisions.

If you've worked on people counting, tracking in crowded scenes or edge processing under privacy constraints, I'd like to hear which edge case gave you the most trouble.

Inside People Flow Management: How Acorel Turns Sensor Data Into Building Intelligence

Dimitri Rudenko — Wed, 08 Jul 2026 11:25:50 +0000

If you've ever wondered how a shopping mall knows exactly how crowded its west wing is right now, or how an airport terminal predicts a security queue backing up 20 minutes before it happens, you've bumped into the world of people flow management — a category of systems that sits at the intersection of edge sensing, computer vision, and IoT integration.

Acorel is one of the more interesting players in this space, with roots going back to 1989 and deployments ranging from the Musée d'Orsay to SNCF trains to EuroAirport. As a dev, I found the architecture underneath their products worth unpacking — not because it's exotic, but because it's a genuinely solid reference pattern for anyone building sensor-to-decision pipelines.

The problem: counting people is a harder distributed-systems problem than it sounds

Naively, "count how many people are in a room" sounds like a single sensor and a counter variable. In practice, at any real scale, you're dealing with:

Occlusion — people walking close together, or standing behind an object
False positives — luggage, strollers, security robots
Multi-zone deduplication — a person crossing from zone A to zone B shouldn't be counted twice, or lost entirely
Latency vs. accuracy tradeoffs — a security team needs alerts in seconds, not after a nightly batch job
Privacy constraints baked into the pipeline itself, not bolted on after the fact

Acorel's platform (branded VISION, with vertical variants like VISION Pop for public venues, VISION Rail for transit, and VISION Air for airports) is built around solving these problems with a fairly classic edge + cloud split.

The sensor layer: multiple modalities, not one

Rather than betting on a single sensing technology, the stack mixes:

Infrared — cheap, reliable for simple entrance/exit counting
3D stereoscopic and LiDAR — for accurate headcounts in crowded or high-density areas, where 2D approaches lose accuracy fast
Computer vision on existing CCTV — this one's the clever bit: rather than requiring new hardware everywhere, the platform can run inference on camera feeds a venue already has, which massively cuts deployment time and cost for large sites like train stations

This mirrors a pattern worth stealing for any IoT project: don't assume homogeneous sensor hardware. Design your ingestion and normalization layer to accept multiple sensor types and reconcile them into one canonical occupancy signal, rather than hard-coding assumptions about a single sensor's data format.

Privacy by design, at the pipeline level

This is the part I think is most relevant to developers outside the physical-sensing world too. Acorel's stated approach is "Privacy by Design": no images are stored, and no faces are identified — the anonymization happens at the point of capture, not as a downstream filtering step.

If you're architecting any system that ingests video or biometric-adjacent data (this applies well beyond people counting — think fleet dashcams, retail analytics, workplace tools), the lesson generalizes:

BAD:  camera → store raw frames → run face detection → discard PII downstream
GOOD: camera → on-device inference (headcount only) → emit anonymized event → transmit

Doing the reduction at the edge, before data ever leaves the device, means there's no raw PII sitting in a bucket somewhere waiting for a misconfigured ACL to leak it. It also happens to make GDPR/CNIL compliance a much easier conversation, since there's no personal data to protect in the first place — you're not protecting it well, you're simply not collecting it.

The integration layer: an open API as the actual product

A counting sensor on its own is just a number. The interesting engineering — and the actual value for a customer — is what that number triggers. Acorel exposes flow and occupancy data through an open API that connects into:

Building management systems (BMS) — adjusting HVAC and lighting based on real occupancy instead of a fixed schedule
Ticketing and access-control systems — for venues like museums and stadiums
CRM and passenger information systems — for transit and airport contexts

A simplified version of what a downstream integration might look like:

import requests

# Illustrative pattern — check Acorel's own docs for actual endpoint specs
def get_zone_occupancy(zone_id: str, api_key: str) -> dict:
    resp = requests.get(
        f"https://api.acorel.example/v1/zones/{zone_id}/occupancy",
        headers={"Authorization": f"Bearer {api_key}"},
    )
    resp.raise_for_status()
    return resp.json()

def maybe_trigger_hvac_boost(occupancy: dict, threshold: int = 150):
    if occupancy["current_count"] > threshold:
        # push a signal into the BMS integration
        notify_bms_system(zone=occupancy["zone_id"], action="increase_ventilation")

(Note: the endpoint above is illustrative — I don't have Acorel's actual API schema, so treat this as "the shape of the pattern," not a working snippet.)

What makes this pattern powerful is that the counting system isn't the end product — it's the trigger layer for a whole set of downstream automations: staffing decisions, energy savings, safety alerts, passenger information displays. The actual ROI for a customer comes from that last mile, not the raw count.

Where this shows up in production

A few deployments worth knowing about if you're benchmarking this category:

SNCF uses 3D stereoscopic sensors to monitor passenger occupancy on regional (TER) trains and at stations.
Musée d'Orsay has run Acorel's people-counting tech for 15+ years, with security staff monitoring zone-by-zone occupancy on tablets during high-traffic exhibitions.
Airport deployments (branded VISION Air) cover the full passenger journey — check-in, security, passport control, boarding — rather than a single chokepoint, with predictive congestion modeling layered on top of raw counts.

That range — trains, museums, airports, retail — on one underlying platform is really a story about a well-abstracted data model: an "occupancy event" is an occupancy event whether it happens on a train platform or in a gallery, and the differentiation happens in the vertical-specific dashboards and integrations built on top, not in the core sensing pipeline.

Takeaways for building your own flow/IoT system

If you're building anything in this space — smart building, retail analytics, transit ops — a few patterns worth borrowing:

Normalize multi-sensor input early. Don't let downstream logic know or care whether a count came from infrared, LiDAR, or a repurposed CCTV feed.
Push privacy-preserving reduction to the edge. Anonymize before transmission, not after storage.
Treat the sensor as a trigger, not a report. The real product is what the data automates — HVAC, staffing, alerts — not the dashboard showing the number.
Design one canonical data model across verticals. An occupancy/flow event schema that works for a train platform should also work for a retail floor, with vertical differences living in the application layer, not the core pipeline.

People counting sounds like a solved problem until you actually have to build it at scale, across sensor types, with hard privacy constraints and real-time SLAs. Worth studying if you're in IoT, smart buildings, or anything adjacent.