Automatic passenger counting for bus & shuttle fleets
An APC system you can put through procurement, not just a demo
Most passenger-counting proposals fail the same way: an accuracy percentage with no stated method, a diagram with no failure behaviour, and a privacy paragraph that will not survive a DPO's review. This page publishes the architecture, the validation method, the data map and the limitations of our APC platform, so your engineering, data-protection and commercial reviewers can all read the same document.
What "procurement-ready" has to mean
Five things a buyer must be able to verify before award
A tender panel is not buying sensors. It is buying evidence that the data will be defensible in a service review, a funding claim and a subject-access request. These are the five areas we document — each one links to the detail below.
Pillar 1 — Architecture
The counting chain, end to end
Counts are produced at the door, published from the vehicle over cellular MQTT, normalised on ingest, written to persistent storage, and served to the dashboard and to your systems through a REST API. Nothing in that chain depends on a laptop, a USB stick, or a manual upload.
| Layer | Function | Behaviour when it fails |
|---|---|---|
| Door sensor | Overhead counting sensor per door produces boarding and alighting counts on the device. No count depends on a fare transaction or a driver action. | A door that stops reporting shows as an incomplete vehicle rather than a lower ridership figure. Vehicles with a known-faulty door feed are excluded from occupancy-derived rules until repaired. |
| Vehicle gateway | Cellular router publishes sensor messages to the broker over TLS and supplies vehicle position. | Cellular gaps are expected. Messages queue and arrive late rather than being lost, and the record retains its source timestamp. |
| Broker | Managed MQTT broker with per-client credentials and topic-level permissions. | A compromised or retired client can be revoked at the broker without redeploying vehicles. |
| Ingest service | Normalises per-door topics into records, applies location provenance, and writes to storage. | Releases are gated on a health endpoint: a build that fails validation leaves the previous working release serving live traffic. |
| Store | Records and diagnostics are held on a persistent volume, so history and last-known state survive restarts and redeployments. | A restart does not reset counters, lose the operational cache, or blank the coverage view. |
| Reporting | Daily, weekly, monthly and yearly views with route and vehicle filters, a monthly value summary, and PDF, Excel and CSV export. | Longer-period analytics aggregate stored daily records rather than reading live cumulative sensor totals, so a sensor reset cannot distort a yearly figure. |
Deployment discipline: development work runs on a separate service, database and volume with its own broker client identity, so new features consume the live feed without displacing the service your passengers depend on.
Pillar 2 — Accuracy & data integrity
A stated method beats a headline percentage
Any supplier can print an accuracy figure. What a buyer can actually hold us to is the method used to produce it, the provenance attached to each record, and what the system does when it stops trusting itself.
How accuracy is established
- Per-installation validation. Counts are compared against manual reference counts on the specific vehicle type, door geometry and mounting height, because saloon height and door width change the result.
- Recorded per door and per route, not as a single fleet number, so a weak door is visible instead of averaged away.
- Re-validated after any change to mounting, vehicle type or sensor firmware.
- Balance checks in service. Boardings against alightings across a full journey expose drift long before a service review does.
Location data you can defend
A plausible-looking coordinate can hide a failed antenna and quietly corrupt every stop-level analysis built on it. Each record therefore carries provenance:
- Validity and source fields distinguish a measured fix from a cached last-known position, a scheduled or interpolated point, and bench-test data.
- Stale positions expire instead of being presented as current, so a dead antenna cannot pin a vehicle to one place.
- Diagnostics persist across restarts and redeploys, so the trail is still there when someone questions a figure weeks later.
The system tells you when to distrust it
- Feed liveness thresholds: 45 minutes without data marks a feed stale, 120 minutes marks it offline.
- Validated on the live service: an 11-minute gap raised a no-data alert while the process itself stayed healthy — the failure mode that silently loses ridership elsewhere.
- The known fleet is seeded, so a silent vehicle cannot disappear from the coverage denominator and flatter the numbers.
- Scheduled shutdown windows are classified as expected end-of-shift records rather than raised as faults.
- Derived alerts are suppressed when the underlying passenger data is not trustworthy, instead of inventing an event.
Where we draw the line
- Accuracy is always quoted with its method and sample. We will not put a fleet-wide percentage in a bid before we have seen your vehicles — and we will hold the figure we agree after validation.
- Dwell is reported as what it measures: a 20-minute no-alighting window at a location, labelled as an occupancy-dwell indicator rather than dressed up as per-passenger dwell time.
- Welfare thresholds are commissioned per fleet. Acceptance testing on your vehicles covers vibration, braking, HVAC noise, changing light and cellular gaps, and the signals go live to your control room once that sign-off is in hand.
- Certifications are quoted with the certificate and its scope attached, never implied.
Pillar 3 — Privacy by design
Counting people without identifying them
The counting path is built so that the question "is this personal data?" has a documented answer for every field, and so your DPO can complete a data protection impact assessment from what we publish rather than from what we promise.
| What is processed | Where | What leaves the vehicle | Personal data? |
|---|---|---|---|
| Door sensing for counts | On the sensor, in the vehicle | A count and a timestamp per door event | No. No image, no face template, no device identifier of a passenger. |
| Vehicle position | Gateway to cloud | Coordinates with validity and source fields | Relates to the vehicle and driver duty, not the passenger. Treat driver-linkable data under your existing employee processing. |
| Occupancy and dwell signals | Derived in the cloud | Aggregated figures per vehicle and route | No, provided they are not joined to an identifiable individual downstream. |
| Welfare events (optional module) | Analysed on the camera, in the vehicle | Event state, time, zone, severity and confidence — not video | Depends on your configuration. If your existing on-board CCTV retains footage, that recording is the personal-data processing, not our event feed. |
| Dashboard access | Cloud platform | Operator account activity | Yes — staff account data, minimised and covered by your access policy. |
Lawful basis
Local authorities and PTEs usually rely on public task for network planning; commercial operators generally rely on legitimate interests with a completed balancing test. The counting path is designed so neither depends on consent, because consent is not workable at a bus door.
Retention
Aggregate ridership is retained for the reporting and funding-evidence period you specify. Event and diagnostic records carry shorter defaults. Retention is set per deployment and written into the contract, not left to a supplier default.
Subject access
Where the counting path holds no identifier, there is nothing to retrieve for a data subject and we say so in writing. That statement, not a marketing claim, is what closes out a DSAR.
Where a DPIA genuinely is needed
Anonymous counting on its own is low risk. A DPIA becomes necessary when the deployment adds anything that observes individuals — welfare or behaviour analytics, existing on-board CCTV within scope, any linkage to ticketing or staff records, or systematic monitoring in a public space. The downloadable DPIA pack below is written for that case and covers screening, the processing description, necessity and proportionality, a risk register with mitigations, transparency wording and a sign-off block.
Pillar 4 — Integration & open data
Your data, reachable by your systems
The platform is an ingest-and-serve system, not a closed appliance. Everything the dashboard shows is available through the same interfaces your team can call.
Available today In service
- MQTT ingest over TLS from the vehicle, with per-client credentials and topic-level permissions.
- REST API serving the same records the dashboard reads, including a real per-stop, per-hour boardings and alightings endpoint rather than a proportional estimate.
- Scheduled and on-demand exports as PDF, Excel and CSV, plus chart capture for board and funding packs.
- Route and vehicle filtering with daily, weekly, monthly and yearly aggregation and a monthly value summary.
Deliverable on request Scoped per contract
- Occupancy feed for public information — mapping our occupancy output into a real-time passenger-information feed for your journey planner or app.
- Scheduled push to an operator data warehouse or SFTP endpoint in an agreed schema.
- Reference-count reconciliation reports comparing APC output with ticketing data for revenue and funding assurance.
- Per-user authentication with role-based administration and login auditing, replacing shared dashboard credentials.
Listed here because it is scoped work, not a shipped feature. We would rather lose a box-tick than pass an unbuilt integration off as available.
Standards alignment, stated without overreach
Suppliers routinely list standards they have never been audited against. Here is the position we will put in writing, with the issuing body's own source next to each one so your technical reviewer can check it.
| Framework | What it actually governs | Our position |
|---|---|---|
| VDV 457 Verband Deutscher Verkehrsunternehmen |
The industry recommendation for APC accuracy: sample design, manual reference counting, statistical equivalence testing and rules for accuracy attestation. VDV lists version 2.3 (11/2025) as current; the published numeric limits available to the public sit in the v2.1 (2018) text. | We adopt its method — reference counts, stated sample, per-door reporting, re-validation after firmware or mounting change. We do not hold a VDV certificate and will not imply one. The validation plan we sign is the evidence. |
| ITxPT | An on-vehicle interoperability architecture with its own label, including a passenger-counting specification (S04P05). | Relevant where your fleet architecture is ITxPT. Interface work would be scoped per contract; we hold no ITxPT label today. |
| SIRI / NeTEx / GTFS-Realtime | The CEN real-time and planned-data families, and GTFS-Realtime, which carries an optional vehicle occupancy_status field. |
Mapping our occupancy output into a named profile is deliverable work with an agreed schema, latency and stale-data handling — not a box we tick unbuilt. |
| Bus Open Data (England) | Under the Bus Services Act 2017 and SI 2020/749, operators publish timetable, fares, vehicle location and punctuality data. DfT's guidance treats occupancy in the location profile as optional. | So occupancy publication is a contract decision, not a statutory obligation we can claim to discharge for you. We will supply the field where you specify coverage and quality. |
| Vehicle fit | EMC and type approval under UN Regulation 10, environmental and vibration qualification under ISO 16750:2023, enclosure protection under IEC 60529 (IP Code), and accessibility under PSVAR 2000. | Compliance belongs to the specified hardware and the specific installation. There is no universal UK standard for camera or sensor mounting in a PSV, so we treat it vehicle-by-vehicle with an installation survey and a non-obstruction assurance. EN 50155 is a rail standard and we will not offer it as bus evidence. |
| Data protection | UK GDPR Article 35 requires a DPIA before high-risk processing; the ICO sets out its required content, and anonymisation is not the same as pseudonymisation. | You are the controller; we supply the inputs. We will not tell you a DPIA is unnecessary — we will help you document the screening decision either way. |
| Procurement route | The Procurement Act 2023 has applied to new covered procurements since 24 February 2025, with notices on Find a Tender. | We bid directly and through frameworks where the framework's scope genuinely covers on-vehicle sensing — named per opportunity rather than claimed generally. |
Where a source is paywalled or a version's detail is not published — VDV 457 v2.3's numerical tables, for example — we say so rather than quoting figures we cannot show you.
The dashboard
Where the data becomes a decision
Counting hardware is the easy half. What a transport team lives with is the interface — and ours is built around the questions an operations manager, a planner and a finance lead actually ask, each answered from stored records rather than from a live sensor total that resets when a vehicle restarts.
Boardings by hour
Per-stop and per-hour figures come from stored boarding and alighting records — not a proportional estimate spread across the timetable.
Feed health
- Vehicle A · live · 12s ago
- Vehicle B · live · 41s ago
- Vehicle C · stale · 52m — flagged
- Vehicle D · shift ended · expected
Welfare feed
- Lone traveller · rear zone · 21:48 · acknowledged
- Sound event · mid saloon · 18:02 · cleared
Illustrative layout with representative figures. A live instance is demonstrated on request under NDA.
Ridership on every timescale
Daily, weekly, monthly and yearly ridership with route and vehicle filters. Long periods are aggregated from stored daily records, so a year figure is the sum of what actually happened rather than a cumulative sensor counter that a power cycle can reset.
Demand at stop and hour level
Boardings and alightings by stop and by hour, the pattern you need to move a departure, split a route or defend a frequency. Peak profiles are drawn from real events, and every view carries the date range it was built from.
Data quality in the same view
Feed liveness, coverage and expected shutdowns sit alongside the numbers. A figure is never presented without its context, so nobody takes an outage for a quiet Tuesday in a board paper.
Location you can rely on
Every stored position carries provenance — measured, cached, or expired — and stale coordinates lapse rather than being drawn on a map as current. That is what makes a historical journey record defensible if it is ever questioned.
Reporting that leaves the screen
PDF, Excel and CSV exports, chart capture for slide decks, and a monthly value summary written for a management pack — the artefact a funding claim or a service review actually needs.
Welfare in one place
Where the welfare module is enabled, events appear with signal, zone, severity, confidence and acknowledgement state next to the ridership picture, so a safety response and a capacity decision are informed by the same source.
Built on the platform, not bolted beside it
The dashboard reads the same REST records your own systems can call, from persistent storage that survives every redeploy, behind a health-gated release process. There is no separate spreadsheet, no manual upload step, and nothing on the screen that your team cannot also pull through the API.
Welfare module
Passenger welfare signals Deployable now
The same platform carries welfare signals for operators who need more than ridership. Detection runs on the camera inside the vehicle, the platform classifies and deduplicates each event, and your control room sees a short, actionable feed rather than raw alarms. Every deployment is commissioned on your vehicles with thresholds set to your operating profile and signed off against an acceptance test.
Six signals
Occupancy, Lone Traveller, Dwell, Distress, Aggression, and Violence & Disruption. Camera detections map into those existing signals — fall into Distress, violence into Aggression, sound classification into Violence & Disruption — rather than multiplying the number of things an operator has to watch.
Events, not footage
Analytics run on the camera inside the vehicle. The vehicle emits an event state with time, zone, severity and confidence. Repeat events are cooled down and cleared states are ignored, so a single incident does not become a wall of alerts.
Calibrated, not guessed
Thresholds were set by replaying real service history rather than by picking numbers in a lab. At the calibrated settings the platform produces well under one welfare alert per service day per vehicle — a volume a control room can act on, which is the difference between a system that gets used and one that gets muted.
Engineered to run in production
- Welfare events are stored separately from passenger counts, with their own signal, severity, zone, source, confidence score and acknowledgement state — so a safety record is never mixed into a ridership figure.
- Welfare processing is contained at the integration boundary: a fault in the welfare path cannot interrupt passenger-count ingestion, and neither can interrupt the other's reporting.
- Occupancy-gated rules only ever fire from a door feed the platform has verified as healthy, so an alert always rests on data we trust.
- Welfare deployment carries its own DPIA. The pack below is the template your DPO completes, and we supply the supplier sections.
Reference deployment
A healthcare-campus shuttle operation, in daily service
A US healthcare-campus shuttle operation runs on this platform in daily service. Per-door counts leave the vehicle over cellular MQTT, are normalised on ingest and written to persistent storage, and reach the operator as daily, weekly, monthly and yearly ridership with route and vehicle filters and exportable reporting. Fleet size, route detail and operator identity stay confidential.
Daily operation is why the engineering is what it is. Live service is what surfaced the failure modes worth designing against — a door feed that degraded, coordinates that froze because of an antenna fault rather than a mapping bug, and silent feeds that a naive dashboard would have shown as a quiet day instead of an outage. Each one is now a detected, labelled state rather than a surprise.
Named references and a technical call with the operating team can be arranged under NDA during a tender process.
What the operator gets each month
- Ridership by route, vehicle, day, week, month and year
- Per-stop, per-hour boarding and alighting patterns from stored records
- A monthly value summary suitable for a management pack
- Feed-health and coverage status, so a figure is never presented without its data-quality context
- PDF, Excel and CSV exports, plus chart capture for reporting
Pillar 5 — Procurement
What we put in front of a tender panel
We are a specialist supplier, not a multinational. That means faster engineering access and direct accountability — and it means being straightforward about the assurance evidence we hold today versus what we produce for a specific contract.
| Buyer requirement | What we provide | Status |
|---|---|---|
| Technical specification response | Line-by-line response to your ITT using the same structure as the downloadable checklist, with evidence referenced per line. | Standard |
| Architecture and data-flow documentation | Component diagram, data map, retention schedule, hosting locations and failure behaviour. | Standard |
| DPIA support | Completed supplier sections, the processing description, and the risk register your DPO signs off. The pack below is the starting template. | Standard |
| Accuracy validation plan | Method, sample size, vehicle types, manual reference-count protocol and acceptance thresholds, agreed before installation. | Standard |
| Vehicle-fit evidence | Mounting geometry per vehicle type, power and network requirements, and the compliance markings held by the specified hardware. | Per hardware selection |
| Security assurance | Credential rotation and least-privilege broker permissions before go-live, TLS in transit, isolated environments, health-gated releases. Formal certification scope is confirmed at tender stage rather than implied here. | Confirmed per tender |
| Insurance and company evidence | UK limited company documentation, insurance certificates, method statements and risk assessments for installation works. | On request |
Stage 1 — Scope
Vehicle types, door geometry, route structure, reporting requirements and data-protection position. Output: a specification and an accuracy validation plan you can put in a contract.
Stage 2 — Validated deployment
A first group of vehicles instrumented and validated against manual reference counts, with the dashboard live and reporting in your hands and the validation record signed before the fleet stage begins.
Stage 3 — Fleet
Phased rollout with per-vehicle validation records, credential hardening completed, handover documentation, and support terms agreed against your operating hours.
Free downloads
Two documents your tender actually needs
Written to be used, not admired: paste them into your ITT and your assessment file. Both are supplier-neutral — they will work against any APC vendor, including ones that are not us.
APC Specification Checklist
A scoreable requirement checklist covering accuracy and validation, sensors and vehicle fit, gateway and connectivity, the data platform, integration and open data, security, privacy, reporting, commercial terms and support. Each line has a plain-English note on why it matters and a column for the evidence you should demand.
- Requirement lines you can lift straight into an ITT
- An evidence column, so "yes" has to be proven
- Traps flagged: unqualified accuracy claims, closed data, per-user licence creep
APC & Welfare Sensing DPIA Pack
An operator-completable data protection impact assessment template for passenger counting and optional welfare sensing: screening questions, processing description, necessity and proportionality, lawful basis options, a populated risk register with mitigations, retention schedule, transparency wording and a sign-off block.
- Screening section that shows when a DPIA is and is not required
- Risks pre-drafted with mitigations, ready to edit
- Written as a template for your DPO — it is not legal advice
Send both documents
One form, both files, no follow-up sequence you cannot escape. We will email them and keep the details for that purpose.
Tell us where to send them and we will email both documents, in PDF and editable Word, the same working day. Direct links are below if you would rather not wait.
Questions buyers actually ask
Straight answers
What accuracy will we get?
The honest answer is that it depends on door geometry, mounting height and passenger behaviour on your vehicles, which is why we agree a validation plan before installation and record the result per door and per route. Any supplier quoting a single fleet-wide percentage before seeing your vehicles is quoting a brochure, not your service.
Do you record or store images of passengers?
Not in the counting path. Overhead sensors process on the device and emit counts. If you add the optional welfare module, analytics also run on the camera in the vehicle and only event states leave it — time, zone, severity, confidence. Any footage retention on your vehicles comes from your existing on-board CCTV, which stays under your own policy and DPIA.
Can we get the raw data out?
Yes. The REST API serves the same records the dashboard reads, and exports are available as PDF, Excel and CSV. Scheduled delivery into your warehouse or an SFTP endpoint is scoped per contract. We do not hold ridership data hostage to a dashboard licence.
What happens when a vehicle loses signal?
Messages queue on the vehicle and arrive when the connection returns, keeping their source timestamps. Separately, feed-liveness rules flag a stale feed after 45 minutes and offline after 120, so an outage shows up as an outage rather than as a quiet day.
Do we need a DPIA for passenger counting?
For anonymous counting alone, usually not — but you should document that screening decision, and the pack above gives you the wording. A DPIA does become necessary once the deployment observes individuals: welfare analytics, in-scope on-board CCTV, or any linkage to ticketing or staff records.
You are a small supplier. Why is that not a risk?
Because we do not hide the mechanics. The platform runs isolated environments, health-gated releases, persistent storage that survives redeploys, and credential rotation before go-live. Delivery is staged so you hold a signed validation record before any fleet commitment, and handover documentation is a deliverable rather than a favour.
Can we speak to an existing operator?
Yes, under NDA during a live tender. The reference deployment is a healthcare-campus shuttle operation running on this platform in daily service; we keep the operator, the fleet size and the route detail confidential until they agree otherwise.
Bring us in at specification stage
The cheapest time to fix an APC procurement is before the ITT goes out. We will review your draft specification, tell you which lines are unenforceable, and say plainly where our own system would not meet them.