How your ridership data travels from vehicle to Swiftly Ridership
This document explains the journey your APC (Automatic Passenger Counter) data takes from the sensors on your vehicles to the ridership data you see in Swiftly Ridership. Because the exact hardware and network setup varies by agency and vendor, the stages below describe the pipeline in general terms that apply to most implementations. Understanding this pipeline is the foundation for monitoring your vehicle health and troubleshooting alerts when they appear.
Swiftly Ridership implementation · Agency reference document.
The pipeline at a glance
Data flows left to right. Stages 1–4 vary by agency and vendor setup; Stages 5–6 always happen inside Swiftly. Any stage can be the source of a failure — alerts show a symptom, not where in this chain the problem originated.
What it does: Automatic Passenger Counter hardware installed in vehicle doors uses infrared or video sensors to detect passengers crossing the threshold and record boardings and alightings. On many systems, an onboard computer (a CAD/AVL unit or similar) receives these events and associates them with vehicle IDs, run numbers, and trip assignments before the data leaves the vehicle. Some APC hardware handles this association internally, with no separate onboard step.
What can go wrong:
- APC unit physically unplugged — most often after vehicle maintenance
- Door beam sensors miscalibrated or misaligned (over or under-counting)
- APC not calibrated with the door sensor (most APCs will only count when the door is open)
- APC or onboard computer firmware outdated, preventing capture or transmission
- Vehicle ID association misconfigured, most often after vehicle maintenance
What it does: Data moves from the vehicle to fixed network infrastructure. Depending on the agency’s setup, this happens over depot Wi-Fi when the vehicle returns to the yard, continuously over cellular while in service, or through another method.
What can go wrong:
- Vehicle parked outside coverage range — data never offloads
- Router or access point failure or misconfiguration
- Cellular connectivity issues for cellular-based transfer
What it does: APC data files are written to an intermediate location before Swiftly receives them. Depending on the agency’s and vendor’s setup, this may be an agency-hosted server or cloud storage, or a vendor-hosted platform, such as the APC/AVL vendor’s own cloud.
What can go wrong:
- Server or platform is offline or unreachable
- File-generation process has stopped running (no new files to send)
- Storage path or permissions changed after a server update
What it does: Data is sent from the staging location to Swiftly Ridership. Common mechanisms include the Swiftly Ridership uploader service, SFTP push/pull, or a direct API integration with the vendor’s platform. The exact mechanism depends on the agency’s and vendor’s setup.
What can go wrong:
- Integration process stopped — for example, an uploader service halted after a server restart
- Upstream file generation failed in step #3 (Data Staging), so there’s nothing to send
- Firewall or network blocking the connection to Swiftly’s servers
- Expired credentials or authentication, for API/SFTP integrations
What it does: Swiftly Ridership ingests APC event data and cross-references it with Swiftly trip observation data to match boarding/alighting events to specific trips, routes, and stop locations. This is where raw sensor events become meaningful ridership data. Once events are correlated to a stop and trip, Swiftly Ridership runs a separate data cleaning step that evaluates each correlated event and discards or adjusts the ones that don't reflect real ridership activity — for example, an operator stepping off during a layover. Cleaning decisions are based on factors like dwell time, timing gaps between events, and load balances across the trip.
What can go wrong:
- GTFS real-time feed down — trip matching fails even if APC data is arriving cleanly
- GTFS static feed outdated after a service change — stops or routes don’t match
- Vehicle IDs in APC data don’t match IDs in the Swiftly trip observations feed
What it does: Processed ridership data appears in Swiftly Ridership.
Two data streams
Swiftly Ridership relies on two independent data streams arriving together to produce ridership data. A problem with either stream will affect the output.
Stream 1 — APC event data Raw boarding and alighting counts from the on-vehicle APC sensors. Travels through Stages 1–4 to reach Swiftly Ridership. If this stream fails:
| Stream 2 — Swiftly trip observation data (relying Trip observation data from Swiftly’s system, sourced from the agency’s GPS/AVL feed(s) and GTFS-static provided to Swiftly. Used to match APC events to specific trips and stops. If this stream fails:
|
Who owns each stage
| # | Stage | Owner | What they investigate |
|---|---|---|---|
| 1–2 | On-vehicle capture, vehicle-to-network transfer | Agency maintenance/IT, or hardware/AVL vendor (contract-dependent) | Physical hardware, firmware, depot/cellular connectivity |
| 3 | Data staging | Agency IT, or third-party vendor | Platform/server availability, file generation, permissions |
| 4 | Delivery to Swiftly | Agency IT, vendor, and/or Swiftly | Integration process running, network/firewall, credentials |
| 5–6 | Processing & ridership data | Swiftly | GTFS feeds, trip matching, data output |
Comments
Please sign in to leave a comment.