Onboard IT in Public Transport: Systems That Enable Real-Time Operations

Onboard IT in Public Transport: Systems That Enable Real-Time Operations

Onboard IT in public transport is no longer a peripheral layer added after vehicle delivery. In modern metro fleets, regional trains, high-speed EMUs, and increasingly connected buses, it has become part of the operating system of the service itself. Dispatchers rely on it to understand where vehicles are, maintainers use it to identify faults before they cause a withdrawal, and passengers judge the network by the accuracy of information delivered through it.

The technical challenge is not simply fitting more computers, screens, sensors, and communication devices onto a vehicle. A train can carry a well-specified passenger information system, CCTV platform, event recorder, and wireless router, yet still produce fragmented operational data if those systems cannot exchange time-aligned, trustworthy information. The difference between a connected vehicle and a genuinely manageable fleet lies in architecture, interface discipline, and lifecycle control.

For rail and urban transit projects, the right question is usually not “Which onboard platform has the most functions?” It is “Which functions must remain available during degraded operation, which data must reach the control center in near real time, and which interfaces can still be supported fifteen years from now?” That is where technical evaluation becomes more demanding than a feature comparison.

The onboard system is a coordinated stack, not a single box

A typical onboard IT environment consists of several layers. The vehicle network provides the communications backbone. Edge computing equipment processes selected data locally. Passenger-facing applications distribute service information and announcements. Operational systems exchange status with depots, traffic control, and maintenance platforms. Safety-related equipment may interface with the same physical network environment, but it cannot be treated as just another application.

On rail vehicles, this distinction matters. A traction fault, brake status, door condition, train integrity signal, passenger alarm event, and camera stream do not carry the same operational consequence or bandwidth demand. Nor should they share the same cybersecurity assumptions. A central onboard computer that aggregates data can be useful, but it must not become a poorly understood single point of failure for functions that need segregation.

Technical teams often describe the architecture through vehicle buses and Ethernet networks. IEC 61375 is widely associated with train communication networks, including the Train Communication Network concept and Ethernet-based approaches. Its relevance is practical: a common communication framework can simplify integration across cars and subsystems, but only when suppliers agree early on data ownership, message structures, timing expectations, and diagnostic access. “Ethernet-compatible” is not enough of a requirement for a multi-vendor fleet.

A workable architecture normally separates at least three concerns: deterministic or tightly controlled vehicle functions; operational data used for fleet supervision; and higher-volume services such as CCTV download, passenger Wi-Fi, or software package distribution. The boundaries differ by project, but the principle holds. If a bulk camera transfer can impair essential diagnostics during a disruption, the design has not yet earned its real-time label.

Real-time operations depend on context, not raw telemetry

There is a tendency to equate real-time operations with sending every available signal to the cloud or control room. In practice, high-volume transport networks need context more than noise. A vehicle reporting thousands of status points is not automatically easier to operate. What matters is whether the data can answer operational questions quickly: Is the train ready to depart? Is a door isolated? Has a traction condition become recurrent? Is a passenger information display showing the correct diversion message? Can the next depot intervention be prepared before the vehicle arrives?

Time synchronization is central here and is often underestimated. If CCTV footage, driver actions, door events, alarm activation, and control-center messages use inconsistent timestamps, post-incident reconstruction becomes slow and uncertain. This is not merely a forensic issue. During a live disruption, teams need to correlate what happened, where it happened, and whether the vehicle’s reported state is current. The system specification should therefore address time source, synchronization accuracy appropriate to each function, behavior during communication loss, and recovery after reboot.

The same applies to location. GNSS can be valuable on open rail corridors, but tunnels, urban canyons, depots, and covered platforms create obvious limitations. Urban rail may combine trackside positioning, odometry, signaling inputs, route data, and station logic. No single source should be assumed to solve every use case. Passenger information, automatic announcements, maintenance event tagging, and emergency response all need a clear definition of what “position” means in that particular system.

Connectivity must tolerate the transport environment

Vehicle-to-ground connectivity is frequently discussed as a bandwidth procurement exercise. Coverage and peak throughput matter, but availability under realistic conditions matters more. A train moving through tunnels, cuttings, stations, border areas, or congested urban cells will not have a uniformly stable link. Systems that assume continuous connectivity tend to fail in awkward ways: duplicated messages, incomplete uploads, stale dashboards, or software updates that cannot be resumed safely.

A stronger design treats the train as an intelligent edge node. It stores data locally when the connection is unavailable, prioritizes critical messages, validates delivery, and resumes transfers without requiring manual intervention. This is particularly relevant for condition monitoring and CCTV retrieval. Sending all raw data continuously can be expensive and operationally unnecessary; sending event-triggered clips, exception reports, and selected diagnostic snapshots is often more defensible.

Communication choices may include public cellular networks, private radio arrangements, depot Wi-Fi, trackside systems, or combinations of these. The correct mix depends on route geography, service pattern, data volume, security requirements, and contractual responsibility for coverage. An intercity fleet spending extended time outside dense urban coverage has a different design problem from a driverless metro running through a controlled tunnel environment. The architecture should reflect that difference rather than copy a fashionable connectivity model.

Passenger information is an operational function

Passenger information systems are sometimes evaluated mainly through screen brightness, display resolution, and the number of supported languages. Those details are relevant, especially for accessibility, but service resilience is more revealing. During normal running, nearly any system can display the next stop. The harder test is a short-notice platform change, skipped station, diversion, split service, or partial evacuation.

For onboard IT, the key questions are who can issue messages, how authority is controlled, what happens when the control-center link drops, and whether vehicle staff can intervene without creating contradictory messages across screens, audio, mobile channels, and platform systems. A passenger display that receives incorrect journey data at scale can become a safety and crowd-management problem, not simply a customer-experience defect.

The same judgement applies to automated metros operating at GoA4. In the absence of onboard driving staff, the relationship between train status, remote supervision, emergency intercoms, CCTV, passenger messaging, and platform systems becomes tighter. A system may be highly automated and still require clear degraded-mode procedures. Automation does not remove the need for human decision-making; it changes where that decision is made and what evidence is available to support it.

Cybersecurity has to be engineered into fleet operations

As onboard systems become more connected, cybersecurity is inseparable from reliability engineering. The risk is not limited to a deliberate attack on train control. An unmanaged laptop connection, unsupported router, weak remote-access process, compromised maintenance account, or poorly signed software package can create a route into systems that were assumed to be isolated.

Standards and guidance used in industrial and rail environments, including the IEC 62443 series and the rail-focused CENELEC TS 50701, can help structure cybersecurity requirements. Their application needs to be tailored to the project and local assurance framework. It is not enough to name a standard in a tender response. Evaluators should look for evidence of asset identification, security zones and conduits, role-based access, secure update mechanisms, vulnerability management, logging, and incident response responsibilities that remain valid after warranty expiry.

One practical warning: remote maintenance is often specified as a convenience feature, then treated as an exception process when the fleet enters service. That approach usually creates workarounds. Remote access should have defined approval paths, session recording where appropriate, least-privilege permissions, and a way to revoke access rapidly. The operating organization must be able to understand who changed what on a vehicle and when.

Lifecycle fit is more valuable than a polished demonstration

Rail assets remain in service for long periods, while IT components age quickly. This mismatch is one of the central procurement risks in onboard IT public transport projects. A computing module, cellular modem, operating system, or software library may reach end of support far earlier than the vehicle overhaul cycle. If obsolescence is ignored at contract stage, operators may later face expensive redesign work just to retain a maintainable communication gateway.

Environmental qualification matters as well. Equipment mounted on rolling stock encounters vibration, electrical disturbances, temperature variation, dust, and restricted maintenance access. EN 50155 is commonly referenced for electronic equipment used on railway rolling stock, but a specification should not stop at that reference. The project still needs clarity on mounting location, cooling assumptions, connector serviceability, replacement procedure, diagnostic indicators, storage capacity, and behavior after power interruptions.

A sound evaluation should also examine configuration management. Can a replacement unit be commissioned without rebuilding the entire vehicle configuration? Are software versions traceable by vehicle and subsystem? Is rollback possible after a failed update? Are interface changes documented in a form that remains useful when the original supplier team has changed? These questions tend to reveal more about long-term risk than a demonstration dashboard.

What to test before committing to the architecture

Factory acceptance testing remains necessary, but it cannot replicate every operating condition. The most useful validation plans include realistic fault scenarios: loss of vehicle-to-ground communication, reboot of an onboard gateway, conflicting passenger message commands, partial network failure between cars, full local storage, failed software deployment, and a transition into degraded operational mode. The aim is not to prove that nothing will fail. It is to prove that failure is visible, contained, recoverable, and understandable to the people running the service.

• Define which data is safety-related, operationally critical, commercially useful, or simply desirable.
• Require interface specifications and ownership rules before integration work begins.
• Test communications loss and recovery, not only normal online performance.
• Assess software support, hardware obsolescence, and cybersecurity patching across the intended fleet life.
• Make degraded-mode passenger communication and control-center workflows part of acceptance criteria.

This perspective aligns with the wider work tracked by TC-Insight across rolling stock, urban rail, automated terminals, and bulk-handling equipment. Although the assets differ, the underlying pattern is familiar: physical machinery generates value only when its control logic, data pathways, and operating decisions remain connected under real conditions. A traction converter, automated stacker, and remotely supervised metro train each expose the same basic truth—digital systems have to serve availability, not merely collect information.

The strongest onboard IT architecture is therefore not necessarily the one with the largest application catalogue. It is the one that gives operators reliable situational awareness, gives maintainers usable evidence, protects critical functions from avoidable exposure, and remains supportable when the vehicle is halfway through its service life. For public transport networks carrying high passenger volumes every day, that is the standard worth designing toward.