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

Acorel — 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.