Passenger counting on a city bus
A Teltonika solution for urban transport: cameras above the doors count the people getting on and off, an FMB125 tracker with an LV-CAN200 supplies coordinates and engine data, and a RUT955 router carries all of it over a single SIM card.
A Teltonika solution for urban transport: cameras above the doors count the people getting on and off, an FMB125 tracker with an LV-CAN200 supplies coordinates and engine data, and a RUT955 router carries all of it over a single SIM card. A city bus with no passenger data is planned blind. On one route people hang off the handrails at peak times, on the next half-empty buses carry nothing but air, and the operator learns about it from complaints rather than from figures. In this use case Teltonika assembles a small network on board the bus: a tracker, a CAN adapter, a cellular router, counting cameras and the driver's tablet with a ticketing system. Everything that happens in the saloon and to the vehicle ends up on one control room server.
What this scenario solves
The operator does not know how many people actually travel on each run, or where they get on and off.
Without those figures the number of buses, the intervals and the type of vehicle on a route are chosen out of habit.
Fuel consumption, engine condition and the way drivers handle the bus also stay out of sight if the tracker sits apart from the rest of the equipment.
Every on-board device with its own SIM card pushes up communication costs across the whole fleet.
The operator does not know how many people actually travel on each run, or where they get on and off. Without those figures the number of buses, the intervals and the type of vehicle on a route are chosen out of habit. Fuel consumption, engine condition and the way drivers handle the bus also stay out of sight if the tracker sits apart from the rest of the equipment. Every on-board device with its own SIM card pushes up communication costs across the whole fleet.
The background to the problem is a serious one. The world's population has passed 7.9 billion and is growing by about 120,000 a day, and more than half of all people already live in towns and cities. The transport systems of large cities get congestion, long journeys to work, expensive fleets and rising emissions.
Then there is the economics of the ticket. According to Statista figures for 2018, the most expensive public transport fare was in London, at an average of $5.66, followed by Stockholm and Copenhagen. As energy prices rise, the cost of carrying people only goes up, and every empty run costs more.
But a city has no other way of reducing congestion than to move people onto convenient public transport. And it only becomes convenient when there are enough buses in the places and at the times they are needed. That calls not for a survey once a year but for an automatic flow of data from every vehicle every day.
What Teltonika offers
Each bus is fitted with an FMB125 tracker and an LV-CAN200 adapter, an industrial RUT955 router and counting IP cameras above the doors: all the data converges in the on-board tablet and goes out to the control room server over a single SIM card.
Installation and setup
Fitting the device and configuring it for the fleet scenario at hand.
Data transfer
The device collects data and sends it to the monitoring platform; how often depends on the model and its settings.
Analysis and control
The person in charge gets reports and alerts and looks into what stands out.
The kit looks like this. The FMB125 is a Teltonika Telematics vehicle tracker with 2G connectivity and RS485 and RS232 interfaces. The LV-CAN200 reads the bus CAN bus. The RUT955 is an industrial cellular router from Teltonika Networks. The people counting cameras are any IP model the router supports. On top of that there is the driver's tablet with a touchscreen and a ticketing system, plus an e-ticket validator.
How the devices are connected. The tracker is linked to the router over RS485 in Log Mode and passes it its AVL records — coordinates, speed, events, CAN data. The cameras and the tablet are connected to the router over Ethernet, that is, into the bus local network. The ticket validator talks to the tablet over RS232. The router brings all of this together and takes it out to the internet over the cellular network.
There is a single SIM card, and it sits in the RUT955. The tracker and the cameras need no SIM of their own; they reach the network through the router. Across a fleet of a hundred buses that is a noticeable saving on connectivity and on administering SIM cards.
What the system collects. The cameras hang above every door and count how many people got on and off. The tracker fixes coordinates from GNSS satellites, while the LV-CAN200 adds fuel level and consumption, the odometer, engine revolutions, engine temperature and door status. The validator checks e-tickets, and payment data goes to the tablet. The router also makes it possible to watch live video from the cameras.
The result is that the control room server receives a complete picture of every run: where the bus is, how many passengers got on and off at each stop, how many paid the fare, how the engine performed and how much fuel went. The data is processed by the program on the tablet and by the control room server.
What is done with it. Planners see the loading by hour and by stop and decide where to add runs, where to widen the interval and where to change the vehicle: a minibus, a standard bus, a double-decker or an articulated one. The technical department plans servicing from mileage and engine data. Management sees fuel consumption and can compare it with the norm.
Drivers are watched as well. The tracker records harsh braking and aggressive driving, which matters particularly on a bus with passengers standing. Drivers can be identified with 1-Wire or Bluetooth accessories, and their working hours and shifts recorded. A panic button for the driver with an instant notification to the control room adds safety for passengers and staff alike.
All Teltonika trackers are updated and reconfigured remotely through FOTA WEB. On a large fleet that saves dozens of trips to the depot.
An important limitation: the scheme described is built around a set of Teltonika equipment — this manufacturer's trackers, CAN adapters and routers. Devices from other makes cannot be fitted into it without extra work.
An example. A dispatcher notices from a report that on one route the morning runs between 7:30 and 8:30 travel fully loaded from the third stop onwards, while at 10 in the morning the same runs carry a handful of people. Instead of holding the same interval all day, the operator adds two buses at the morning peak and takes them off after 9:30, and puts lower-capacity vehicles on the route between the peaks.
Another typical episode. The camera data shows that at a particular stop a lot of people get off but almost nobody gets on, and two stops later the picture is reversed. That is a hint that there is something drawing people between the two — a market, a university, a hospital — and it is worth thinking about a short route or a change to the timetable.
How to start the project. It usually begins with a pilot on one or two routes: a kit goes onto a few buses, for a week or two the camera readings are checked against a manual count and the reports are set up. Only then is the equipment rolled out across the whole fleet. That approach makes it possible to find out in advance how the cameras behave in these particular buses, with their doors, steps and lighting.
A completed run or just a drive-through. For the body commissioning the service, what matters is not that the bus drove along the streets of the route but that it completed the run: passed the control stops within the permitted window against the timetable, opened its doors and took passengers on. So in the report a run is counted when three signs coincide: passing the stop geofences on GPS, the doors opening on CAN or on a sensor, and camera data on people getting on and off. A drive-through with no stops and no doors opening is marked separately.
Where the figures come from. Coordinates and times come from the tracker's GNSS. Doors, mileage and fuel come from the CAN bus. Boardings and exits come from the cameras above the doors. Payments come from the validator. It helps to name the source next to each column in the report, so that in any dispute it is clear what was measured by an instrument and what was calculated by software.
What the report for the customer looks like. For each route and each day: planned and completed runs, deviations from the timetable at the control stops, the number of people getting on and off by stop, the share of paid journeys, mileage and fuel consumption. The format and frequency of the report are agreed with the body commissioning the service before launch.
What you get
Passenger flow in figures
Cameras above the doors count boardings and exits at every stop, and the route network is planned around real loading.
One SIM card per bus
The tracker and the cameras reach the network through the RUT955, and connectivity costs across the fleet fall noticeably.
Fuel and engine under control
The LV-CAN200 supplies consumption, fuel level, revolutions and temperature, which show overuse and drive servicing plans.
Passengers and payments reconciled
Camera and ticket validator data in one system help to gauge the share of fare evasion by run and by stop, with an allowance for counting error.
Safer for passengers
Monitoring harsh braking, driver identification and a panic button help bring order to the line.
Remote maintenance of the equipment
Tracker firmware and settings are changed through FOTA WEB, with no technician visiting the depot.
Why this solution
The strength of this scheme is that the tracker, the CAN adapter and the router come from one group of companies. Teltonika Telematics and Teltonika Networks have seen to it in advance that the FMB125 hands its data to the RUT955 over RS485 in a standard mode, so the integrator does not have to write a gateway of their own.
The RUT955 is built for industrial use: vibration, unstable power, round-the-clock operation. For a bus that runs 16 to 18 hours a day that matters more than top internet speed.
The FMB125 fits because of its interfaces: RS485 for the router, RS232 for additional equipment, inputs for a panic button and driver identification. 2G connectivity is more than enough for the tracker, because the main traffic goes through the router.
The LV-CAN200 reads the CAN bus without cutting into it, so engine and fuel data can be obtained on buses of various makes, provided the particular model is on the adapter's support list.
An honest limitation: counting cameras have a margin of error when the doorway is crowded, especially at peak times. That is good enough for planning routes, but it is not worth reconciling passengers against payments person by person — better to look at the share and the trend.
How this works in Azerbaijan. The main ground for a solution like this is city buses in Baku and the suburban routes across Absheron: Khirdalan, Sumgait, Mashtaga, the settlements along the Baku ring road. The bus network here is large, at peak times the saloons on a number of routes are full, while during the day loading drops, and passenger data helps operators and the transport authorities redistribute vehicles. There is a similar demand from intercity operators running from Baku to Ganja, Sheki and Lankaran, and from corporate buses that carry staff to industrial sites and oil facilities. Points to bear in mind: in summer, at +40 °C, the air conditioning runs constantly, and monitoring engine temperature over CAN is particularly useful. Fares in Baku have long been cashless, so the camera and validator pairing gives a good reconciliation. GPS.az supplies Teltonika trackers and CAN adapters, helps to choose the router and the cameras, and brings bus monitoring, fuel data and driver behaviour onto the Wialon platform.
Related case studies
Related rollouts and equipment
Questions about the “Passenger counting on a city bus” scenario
Request a call
A specialist will call back and match a solution to your fleet and your task.