A passenger information system, or PIS, is the set of components that turns what your vehicles are actually doing into something a passenger can act on: a predicted arrival time at a stop, a message about a diversion, a live position on a map. It spans data capture on the vehicle, prediction logic on the server, and delivery across screens, apps, SMS and third-party journey planners.
This guide is about choosing between suppliers. If you are at the earlier stage of writing the specification itself, our guide on passenger information system tender requirements covers what to put in the document. Here we assume the requirement exists and you are now looking at three or four very different-looking proposals and trying to compare them.
What a passenger information system actually includes
Vendors scope the term differently, which is the root of most comparison problems. A complete PIS covers four layers, and any proposal you receive will be strong in some and thin in others.
Real-time position and prediction
Everything downstream depends on this layer. The vehicle reports its position, the platform matches it to a scheduled trip, and a prediction engine estimates arrival times at the stops ahead. The quality difference between suppliers is almost entirely in the prediction, not the tracking. Anyone can put a dot on a map. Predicting that the dot will reach stop 14 in seven minutes, on a congested corridor, at 17:40, is the hard part.
Delivery channels
This is where scope varies most:
- On-street displays, from mains-powered LED panels to solar e-paper units at low-traffic stops
- Onboard screens and audio announcements, increasingly mandatory for accessibility compliance
- A passenger app or mobile web view, owned by the operator or the authority
- Push channels, mainly SMS and app notifications, for disruption alerts
- Third-party journey planners, meaning Google Maps, Moovit, Apple Maps and national or regional planners
That last channel is the one operators consistently undervalue. For most networks, more passengers check a general-purpose journey planner than ever open the operator's own app.
Disruption messaging
Schedule adherence information handles the normal day. Disruption messaging handles the day that matters: a diversion, a cancelled trip, a road closure. The test here is operational rather than technical. How many separate places does a controller type the message before every channel reflects it? If the answer is more than one, the system will fail during a real incident, because nobody has time to publish four times.
Reporting
Authorities increasingly require evidence of information quality, not just of punctuality. Prediction accuracy, display uptime and feed availability are becoming reportable metrics. A PIS that cannot produce that evidence turns every reporting cycle into a manual exercise.
The four types of vendor you will meet
When you tender for a PIS, you will get proposals from four fundamentally different kinds of company. Comparing them line by line without recognising the category is how evaluations go wrong.
Display hardware manufacturers
They make the panels, and often the on-street infrastructure around them. The hardware is usually excellent and the roadside experience is well understood. Their software layer is typically built to drive their own displays, which means the app, the third-party feeds and the disruption workflow tend to be lighter than the brochure suggests. Ask specifically what happens if you later want a different display brand at some stops.
Journey planner and app specialists
Strong passenger-facing experience, good design, fast iteration. Their weakness is upstream: they consume real-time data rather than generate it, so they depend on the quality of whatever your operations system produces. If your prediction layer is weak, a beautiful app makes the weakness more visible to more people.
AVL and AVM platforms with passenger information built in
These start from the operations side. The advantage is that prediction, schedule adherence and disruption handling come from the same data the control room is using, so there is one version of the truth. The thing to verify is display integration breadth and how many hardware families they actually drive in production, not in principle.
Systems integrators
They assemble a solution from other people's components. This can be the right answer for a large multimodal authority with unusual constraints. The cost is that you are buying an integration project, with a project timeline and a project risk profile, and long-term evolution depends on the integrator staying commercially interested in your network.
None of these categories is wrong. But a hardware manufacturer and an operations platform answering the same tender are not offering the same thing, and a purely commercial comparison will pick the wrong one.
Evaluation criteria that actually separate suppliers
Prediction accuracy, measured and disclosed. Ask for mean absolute error on arrival predictions, broken down by prediction horizon. A supplier who tracks this will share it. A supplier who does not track it is telling you something.
End-to-end latency. Not the vehicle reporting interval, the total time between a position changing and every channel reflecting it. Ask for the number for each channel separately, because public feeds are often throttled well below the internal dashboard refresh.
Native standards support. GTFS for static schedules, GTFS-RT for real-time updates, SIRI for European authority interfaces, NeTEx where the national profile requires it. Native means the platform produces it, not that a consultant can build an exporter.
Single point of entry for disruptions. One input, all channels updated. Verify this in a live demo with a real diversion, not a slide.
Display hardware independence. Which display families are driven in production today, and what is the contractual position if you add another brand in three years.
Behaviour during connectivity gaps. Rural and peri-urban routes lose coverage. Ask whether positions are buffered and reconciled, or whether the gap is simply skipped and stale data shown as current. The second behaviour is worse than showing nothing.
Accessibility compliance. Audio announcements, visual contrast, screen reader compatibility on the app. In most European markets this is now a legal requirement rather than a differentiator, and retrofitting it is expensive.
Total cost over the concession term. Licences, hardware, installation, connectivity subscriptions, display maintenance, and the integration work you will do yourself. Suppliers quote different subsets of that list. Normalise before comparing.
The standards question, in plain terms
Standards are the part of a PIS purchase that determines how trapped you are in five years.
- GTFS describes your scheduled service. It is the entry ticket for Google Maps, Moovit and most journey planners.
- GTFS-RT carries real-time updates, in three feed types: trip updates, vehicle positions and service alerts.
- SIRI is the European real-time profile, and it is what most national and regional authority systems expect. Common profiles are stop monitoring, vehicle monitoring and situation exchange.
- NeTEx covers richer network and timetable description, and appears in national access point requirements.
A supplier who supports GTFS and GTFS-RT but not SIRI will work fine for consumer journey planners and cause you problems the first time an authority asks for a compliant interface. A supplier who supports SIRI but treats GTFS-RT as an afterthought leaves you invisible in the apps your passengers actually open.
Frequently asked questions
What is the difference between a PIS and an AVM or AVL system?
An AVM or AVL system exists to help you run the service: locate vehicles, detect deviations, support the control room. A PIS exists to tell passengers what is happening. They share the same underlying position and prediction data, which is why the two are increasingly bought together, but the users and the success criteria are different.
Do we need our own passenger app?
Often not, or not first. For most networks, the highest-return channel is a reliable GTFS-RT feed into Google Maps and Moovit, followed by disruption messaging. An owned app is worth building when you need a channel you fully control, for example for school transport or subscription services.
How long does a PIS deployment take?
Software and third-party feed publication can be live in weeks once the static schedule data is clean. On-street display deployment is the long pole, because it involves civil works, power and connectivity per stop. Plan the two tracks separately and do not let the display rollout gate the digital channels.
What is the single most common reason PIS projects disappoint?
Schedule data quality. Prediction cannot be better than the timetable and stop data it is matched against. Networks that clean their GTFS before deployment get results months earlier than networks that treat it as a formality.
How to run the comparison
Build one table, put every supplier in the same rows, and force each one into a category before you score anything. Then insist on a demo using your own network data, including one diversion and one connectivity gap. Almost every meaningful difference between PIS suppliers shows up in those two scenarios, and almost none of it shows up in a slide deck.
If you want to see how passenger information behaves when it comes from the same platform as your operations data, including how a single disruption entry propagates to screens, SMS and public feeds, Pysae's team can walk through it on your network.