What It Takes to Get Automatic
Passenger Counting Right on a Large Fleet.
Retrofitting dozens of vehicles with passenger counting sounds simple until you write the actual specification. Here’s what separates a workable APC requirement from one that quietly limits your options — and how a modern sensor-plus-software solution meets it.
Picture a mid-size public transit fleet: a mix of standard and articulated battery-electric buses, several doors per vehicle, routes that carry millions of boardings a year, and — until now — no automatic passenger counting installed anywhere. That’s a common starting point for transit agencies today, and it’s a harder specification to write well than it looks.
The obvious requirements are easy: count people getting on and off, be accurate, don’t break the bank. The requirements that actually determine whether the project succeeds are less obvious. Some sections of a route may have no reliable cellular coverage — does the system keep counting, or does it just stop collecting data until a signal comes back? Some passengers use wheelchairs, strollers, or travel with children — does the sensor tell them apart, or does everyone just count as “one”? The fleet already runs on-board telematics — does a new counting system bolt on cleanly, or does it become a second system drivers have to babysit?
None of this is unusual. It’s the normal shape of an APC retrofit project on a real, operating fleet. The difference between a specification that gets a genuinely capable system and one that gets a bare-minimum counter usually comes down to whether these operational realities were written into the requirements in the first place.
A single compact sensor per door is usually all the hardware a retrofit needs.
An APC specification that only asks for “an accurate count” will get bids that all look similar on paper. The specifications that separate real capability from a checkbox product ask about offline operation, passenger classification, systems integration, and maintenance burden — before a single sensor is ever installed.
Here’s what a specification like that should actually cover, and how a modern APC solution answers each part of it.
Four Things Every APC Retrofit Has to Solve For
Across most large-fleet APC projects, these four requirements come up again and again — and how they’re specified determines what kind of system actually shows up.
Accuracy That Holds Up in the Real World
A stated accuracy percentage means little without a method behind it. Crowded doorways, low light, fast boarding at busy stops — the count needs to hold up under real operating conditions, not just in a lab test.
Routes Without Reliable Connectivity
Many transit routes pass through areas with weak or no cellular signal. A counting system that only works when it’s connected isn’t collecting data on exactly the segments an agency may care most about.
Fitting Into Systems That Already Exist
Fleets already run on-board telematics, fleet management, and often ticketing systems. A new APC platform needs to integrate with what’s there — or at minimum stay out of its way — without adding a second workflow for drivers or dispatch.
Minimal Ongoing Maintenance
A sensor that needs regular cleaning, recalibration, or specialized servicing adds real operating cost across a large fleet. The hardware needs to be built to run largely unattended for years.
How Our APC Solution Answers Each Requirement
As the North American integrator for WeBreathe’s 2FLOW Automatic Passenger Counting platform, this is the specific system we map against requirements like these.
3D Stereoscopic Counting, Verified Above 98% Accuracy
The EYES 3 sensor uses 3D stereoscopic vision and on-board AI image processing to count boardings and alightings, with a committed accuracy rate above 98% — measured against absolute error across a minimum volume of door cycles, not a best-case demo number.
Classification Beyond a Simple Headcount
The same sensor distinguishes adults from children, and identifies wheelchairs, strollers, and bicycles as separate categories — data that a plain in/out counter can’t provide, and that matters for accessibility planning and service design.
Built to Keep Counting Without a Signal
Counting data, GPS position, and timestamps are captured and stored on-board regardless of connectivity. When the vehicle re-enters coverage — or returns to the depot — the data syncs automatically, so gaps in cellular coverage don’t become gaps in the dataset.
Open Protocols for Real Integration
The on-board calculator communicates over Ethernet, WiFi, RS485, and CAN using open protocols including SOAP, TCP, UDP, FTP, and ITxPT — built to interconnect with existing telematics, fleet management, and passenger information systems rather than operate as an island.
Rugged Hardware, Minimal Upkeep
A compact, IP64/IK07-rated aluminium enclosure rated from -25°C to +70°C, with an MTBF above 1,000,000 hours, means the sensor is built to run for years without regular cleaning or recalibration — installed once per door and largely left alone.
What This Looks Like Once It’s Installed
Beyond the hardware itself, here’s what a fleet-wide APC deployment actually delivers day to day.
Counts That Hold Up to Scrutiny
Because accuracy is measured against absolute error over a real cycle of door openings — not cherry-picked conditions — the resulting data is something planners can actually build service decisions on, rather than a number that needs a caveat attached.
No Data Gaps From Coverage Gaps
Segments of a route without cellular signal still get counted and geo-tagged; the data simply queues locally and uploads once connectivity returns. Operationally, this means no missing sections of the network in the final reporting.
One Fewer System for Drivers to Think About
The sensor activates automatically on the door-open signal and requires no driver input at all. Integration with existing telematics happens at the system level, not through an extra screen or workflow on the dashboard.
Reporting That Grows With the Program
The 2FLOW software is structured in tiers — starting with core counting and reporting, and adding real-time dashboards, geo-located replay, forecasting, and open API access as an agency’s reporting needs mature. Agencies aren’t locked into paying for advanced business intelligence tools on day one if all they need is reliable counts and standard reports.
A well-specified APC system doesn’t just count people — it keeps counting through coverage gaps, tells different rider types apart, fits into the systems already running on the vehicle, and doesn’t need a maintenance crew to keep working.
EYES 3 Counting Sensor
The smallest counting cell in its class, EYES 3 uses 3D stereoscopic vision and on-board AI to count and classify riders at each door — adults, children, wheelchairs, strollers, and bicycles — without transmitting or storing raw video, only anonymized counting data.
Paired with an on-board calculator (BRAIN/WEBOX) that aggregates counts, GPS position, and timestamps across every door on the vehicle, the system transmits securely to the 2FLOW cloud platform — or a physical on-premise server, where required.
Inside the 2FLOW Passenger Counting Platform
A walkthrough of the CARE software, real-time dashboards, and reporting tools that sit on top of every APC deployment.
2FLOW CARE, API, and Monitoring platform overview — WeBreathe
What to Put in an APC Specification
Seven items worth writing directly into the requirements, based on what actually separates capable systems from bare-minimum ones.
- A defined accuracy methodology, not just a percentage — how the count is verified matters as much as the number itself
- Offline data capture with automatic sync — counts and location data shouldn’t disappear in coverage gaps
- Rider classification beyond a simple headcount — the ability to distinguish adults, children, wheelchairs, and strollers where it’s useful for planning
- Open integration protocols — compatibility with existing telematics, AVL, or fleet management systems, not a closed proprietary system
- No regular specialized maintenance or cleaning — hardware rated for years of largely unattended operation
- Secure, access-controlled data handling — passenger counting data available only to authorized personnel, with no interference in passenger movement or privacy
- Software that scales with reporting needs — core counting and reporting on day one, with room to add real-time dashboards and API access later without new hardware
Frequently Asked Questions
Can an APC system keep working on routes with no cellular signal?
Yes. Counting data, GPS position, and timestamps are captured and stored on-board regardless of connectivity, then synced automatically once the vehicle reconnects — whether that’s later on the route or back at the depot. No manual download step is required.
Do we need extra hardware to count wheelchairs and strollers separately from regular passengers?
No — the same 3D counting sensor handles this. It’s built to distinguish adults, children, and objects like wheelchairs, strollers, and bicycles as part of its standard counting output, not as a separate add-on system.
Will a new APC platform integrate with our existing on-board telematics?
In most cases, yes. The on-board calculator communicates over open protocols (Ethernet, WiFi, RS485, CAN, SOAP, ITxPT), which is what allows it to interconnect with existing fleet management, AVL, and passenger information systems rather than operating as a standalone island.
How much maintenance does an onboard passenger counting sensor need?
Very little. The sensor is a sealed, IP64/IK07-rated enclosure rated for -25°C to +70°C operation with an MTBF above 1,000,000 hours — designed to be installed once per door and run for years without regular cleaning, recalibration, or specialized servicing.
Writing an APC Specification for Your Fleet?
Send us your fleet details — vehicle types, door counts, route conditions, and what you need from the reporting side — and we’ll map exactly how our sensor and software platform meets each requirement.
Serving Canada and the United States · Tel: +1 (855) 613 4486 · info@smartsensrsolutions.com
