Real-time data is considered standard in public transport – but in practice, passengers often experience the opposite. Tobias Schulz-Hess, Senior IT Cloud Architect at PROTOS, explains in his article, from a project perspective, where and why real-time information is lost along the system chain – and how these structural weaknesses can be sustainably addressed through an event-driven cloud and edge architecture.
The focus is not on theoretical target scenarios, but rather on a pragmatic integration approach that incorporates existing systems and develops them further step by step.
When "real-time" doesn't reach the passenger
When I talk to IT managers at transport companies about real-time information, I keep hearing the same thing: "Passengers often complain about the app. The display and the actual operation don't always match up."
Our experience: The problem almost never lies with the app itself – but rather with what's happening behind it: a chain of ITCS, on-board computers, data hubs, and interfaces that rarely function as a truly cohesive system in everyday use.
In projects, we repeatedly see the same symptoms: ghost buses, delayed forecasts, and conflicting information. Not because the data is missing – but because it gets lost along the way through the systems, interfaces, and handoffs.
Real-time information from the passenger's perspective vs. reality within the system
For the passenger, the issue is quite simple: "I want to know when my bus is actually coming."
However, this is precisely where the biggest discrepancy we see in projects arises.
From a technical perspective, this seemingly simple question is the result of a long chain of technical and organizational handoffs:
Position data is recorded in the vehicle. The on-board computer combines this with door signals, timetable data, and other sensor data. The ITCS (Integrated Transport Control System) then uses this information to generate forecasts and identify deviations. This information is distributed via data hubs, transport associations, and state platforms.
And only at the end of this chain are the systems that the passenger actually sees – apps, displays, or screens.
In practice, this means that every single transition in this chain is a potential breaking point.
And this is exactly where the inconsistencies arise that are later perceived as an "app problem."
Where Real-Time Data Actually Gets Lost
Looking at this chain in practice, one thing quickly becomes clear:
The problems don't arise in one place – but at many small transition points.
We see these points of failure again and again in projects – and they surprisingly often follow the same pattern:
It starts in the vehicle with data acquisition.
On-board computers don't consistently operate with stable mobile connections – especially outside urban areas. Data is buffered, transmitted with delays, or lost during roaming. At the same time, proprietary protocols make seamless integration into downstream systems difficult.
These problems continue in the ITCS.
Many systems were historically designed for local operation – not for the continuous processing of millions of external real-time queries. Forecasts are often generated in fixed cycles or after manual approval, instead of reacting in an event-driven manner. Especially in disruptive situations, this leads to delays that propagate through the entire chain.
Additional inconsistencies arise in data hubs and interconnected systems.
Different data formats, parallel distribution channels, and batch-based synchronization mean that identical information is updated differently in different places. The information is there – but not consistent.
And the problem becomes apparent on the last mile to the passenger.
APIs are often generic rather than user-oriented, caching is purely technical, and continuous monitoring across all systems is lacking. As a result, errors aren't detected early, but only after the passenger has already experienced them.
We see the result time and again:
Not a single error – but a chain of small inaccuracies that accumulate.
And this is precisely how the "ghost buses" arise, which are ultimately perceived as an app problem.
We make this chain visible in our projects – and systematically stabilize it from within.
How a consistent real-time architecture emerges
The central question we ask in projects is: How do we create a system from this fragmented chain that truly functions in real time?
Our answer isn't a tool – it's an architectural principle:
Real-time must be considered holistically – from the vehicle to the API.
This is precisely the approach we pursue at PROTOS: a combination of edge intelligence and a consistently event-driven cloud architecture.
.png)
Stabilization begins in the vehicle even before transmission.
Data isn't simply passed on, but pre-processed: GPS, door, and timetable data are validated, normalized, and—if necessary—cached. This is crucial, especially with unstable connections, to prevent data loss.
In the cloud, a data stream becomes an event stream.
Instead of periodic processing, incoming information is continuously processed via streaming platforms like Kafka or MQTT. The key here is decoupling: producers and consumers no longer know each other directly—this makes the system more robust and scalable.
Forecasts are generated where they belong: in independent services.
Delays, turnarounds, or connection situations are no longer calculated in monolithic ITCS systems, but in specialized, event-driven microservices. Even manual interventions—such as trip cancellations or dispatching decisions—are treated as events and not as subsequent corrections.
From the outside, the complexity remains manageable.
Adapters convert the data into existing formats such as VDV or GTFS-RT. Clearly defined APIs are available for apps, displays, and third parties, optimized for different use cases.
And crucially, the entire chain becomes visible.
Continuous monitoring and targeted alerting ensure that problems are detected within the architecture itself, rather than only becoming apparent to passengers.
The difference to traditional approaches is fundamental:
Real-time performance is no longer achieved by simply forwarding data –
but rather by the targeted processing of events along a consistent architecture.
How this path looks in practice
The question we almost always get asked is: Does everything have to be rebuilt?
The short answer: No.
In practice, this transformation only works if it happens gradually – without jeopardizing ongoing operations. That's precisely why we at PROTOS rely on a pragmatic integration approach that incorporates existing systems instead of replacing them immediately.
The first step is transparency.
Existing vehicle fleets and ITCS systems are connected to a central streaming infrastructure – initially without interfering with existing processes. The data is mirrored and visualized under real-world conditions.
Building on this, a controlled parallel operation is established.
Existing systems remain in control, while new data flows, forecasts, and architectures are validated in so-called "shadow mode." This allows weaknesses to be identified without risk to operations.
In the next step, the focus shifts – from analysis to active use.
Streaming data is no longer just observed, but used specifically for forecasting, monitoring, and control. Bottlenecks – both technical and organizational – become visible and assessable.
Only then does the gradual migration of logic to the cloud take place.
Forecasting and decision-making logic is extracted from monolithic ITCS systems and transferred into scalable services. Existing platforms and interconnected systems remain integrated and are connected via adapters.
In the long term, this results not in a disruption, but in a controlled transformation.
Individual components are replaced without destabilizing the overall system.
This is precisely the crucial difference in our projects:
Success is not determined by the grand architectural design, but by the ability to transition existing systems to a new reality in a controlled manner.
We support our clients precisely during these transitions – from initial transparency to a stable target architecture.
