For the passenger, real-time information is the difference between waiting and knowing how long there is to wait. For the operator, it is a system that cannot fail: it consumes operational data every second, turns it into a position and a prediction, and publishes them to thousands of people at once on the web, in the app and on the station displays. For Metro Bilbao, CEDESA delivered the development and web service for real-time mobile positioning on the metro network. In this article we explain, without publishing the client’s internal details, how a system of this kind works, what it demands and which design decisions make it reliable.

Where the data comes from

A passenger information system does not itself measure where the trains are: it takes their position from the operator’s operational systems and adds value to it.

Signalling and traffic control systems: on a metro network, the train supervision system knows which block sections of track are occupied and where each train is, along with the train’s identity and the service it is running. It is the most accurate source and the one that has to be integrated.
Automatic vehicle location (AVL) system, the SAE (Sistema de Ayuda a la Explotación) of Spanish operators: on surface or mixed networks, the position comes from on-board positioning (GNSS supplemented by odometry and beacons) and from the control centre, which knows which vehicles are allocated to which services.
Planning: timetables, services, train formations and the calendar, which make it possible to interpret each position as a train on a given line running a specific service, and to calculate the delay against the plan.
Disruptions and service notices from the control centre: closures, diversions, increased or reduced frequencies, which must reach the passenger together with the position.

Integration is done through interfaces with those systems, at whatever interval they allow (seconds), and with a clear contract as to which data is received, with what latency and what happens when it is missing.

How position and predicted arrival are calculated

Normalisation: each item of position data is translated into a common model of the network: line, track, previous and next station, direction, train and service, with its time stamp.
Filtering and consistency: impossible positions (jumps, backward movements, duplicates) are discarded, and sources are reconciled where there is more than one.
Arrival estimate: for each station and direction, the time until the next train arrives is calculated from its position, the typical speed on that section at that time of day, dwell times and any current disruptions. The models learn from historical data to refine the estimates by section, time and day.
Service status: actual against planned frequencies, delays, gaps and alerts, both for the passenger and for the operator itself.
Publication: the results are exposed through web services and in standard open data formats for real-time transport information, for the operator’s own website and app, for the station displays and for third parties (journey planners, aggregators) when the operator so decides.

What the passenger sees and does not see

On the screen there is a map with the trains moving, the next arrival at the passenger’s station and the service notices. Behind it lie decisions that determine whether the information can be trusted:

End-to-end latency of a few seconds, so that the position on the map matches what the passenger sees arriving.
Consistency across channels: web, app and displays must say the same thing at the same moment, so they draw on the same source.
Behaviour when the data is missing: show the last known position along with its age, or fall back on timetabled information, but never invent an arrival.
Performance under peak load: thousands of users checking at once in the rush hour or during a disruption, which is precisely when the system is consulted most.
Accessibility of the information, so that it can be used with a screen reader, with magnification and on the displays.

What a system like this demands of the supplier

24-hour availability, with redundancy, monitoring and a contingency plan, because passenger information is consulted at any hour and operations never stop.
Integration with physical infrastructure and operational systems that cannot be stopped for testing: signalling, the AVL system, displays, ticket validators.
Scalability for peaks in usage far above the average.
Security: the system is part of the infrastructure of a public transport operator, connects to operational systems and exposes services to the internet. It must be designed with the operational network separated from the publication network, and with the measures of the National Security Framework (Esquema Nacional de Seguridad, ENS) when the operator is publicly owned, as we explain in what the ENS is.
Maintenance by the same team that developed it: when it fails at seven in the morning, whoever responds must know the code.
Ownership of the software and the data by the operator, so that it can evolve the system and open the data to third parties whenever it wishes.

The development for Metro Bilbao

Metro Bilbao commissioned CEDESA to deliver the development and web service for real-time mobile positioning on its network. Without going into the functional detail or the client’s internal results, the project follows the pattern described above: integration with operational data, calculation of position and publication as a web service for the passenger information channels, with the availability, performance and security requirements that go with a metropolitan transport operator. It is one of CEDESA’s references in transport and mobility, alongside the resource management platform for the fleet and staff of TITSA, the public bus operator in Tenerife, and staff management at Puertos de les Illes Balears, the Balearic Islands’ port authority, and it is among the references that demonstrate CEDESA’s technical capacity to other operators and public authorities, as we explain in large integrator or mid-sized company.

From positioning to managing the operation

Passenger information is the visible face of data that is good for much more. The same real-time position feeds service regulation (frequencies, gaps, extra services), disruption management, compliance with the service contracted with the transport authority, staff and shift planning and the historical analysis of punctuality. That is why it makes sense to design the positioning system as an operational data platform with several consumers, and not as a stand-alone website. We cover the staff and fleet side in fleet management and time tracking for transport companies.

Frequently asked questions about real-time positioning

Where does a passenger information system get the position of the trains from?

From the operator’s operational systems: signalling and traffic control on a metro network, and the automatic vehicle location system with on-board positioning on surface networks, combined with service planning in order to know which train, on which line, each position belongs to.

How is the arrival time of the next train calculated?

From the train’s position, the typical speed on that section at that time of day, dwell times and any current disruptions, with models that learn from historical data to refine the estimate by section, time and day. When the real-time data is missing, the system must say so or fall back on timetabled information, never invent an arrival.

What format is used to publish real-time transport data?

The operator’s own web services for its website, app and displays, and standard open data formats for real-time transport information for third parties such as journey planners and aggregators, when the operator decides to open up the data.

What security requirements does a passenger information system have?

Separation between the operational network and the publication network, access control, monitoring and the measures of the National Security Framework when the operator is publicly owned, because the system connects to operations and exposes services to the internet.

Why build a custom positioning system?

Because every operator has different operational systems, information channels and integration requirements, and because owning the software and the data makes it possible to evolve the system, open up the data and change supplier without losing the system. Maintenance by the team that developed it is the guarantee of a response when it fails.

Conclusion

A real-time positioning system for passenger information integrates operational data, calculates reliable positions and predictions and publishes them with a latency of seconds to thousands of users, with permanent availability and the security of critical infrastructure. That is what CEDESA developed for Metro Bilbao and what it applies in every transport and mobility project. If you are an operator looking to improve passenger information or to turn position into an operational data platform, tell us about your project via our contact page.