Meet Pilotfish at Persontrafik 2026

Putting something new on a vehicle usually means its own box, its own connection and its own integration. Do that five times and the fifth one costs more than the first, because it has to coexist with four things that were never designed to coexist with anything.

With a shared onboard network and one managed route to the back office, adding a system becomes a connection rather than a project. The same holds when you go from a pilot on three vehicles to a full fleet: the work is rollout, not redesign. It is a good thing to talk through against a real fleet, so come and find us at the stand.

Onboard IT specified in a tender this year will still be in the vehicle a decade from now. If the systems depend on each other, changing one of them means renegotiating all of them, and the supplier knows it.

An open architecture separates the functions from the foundation. Ticketing can be replaced without touching passenger counting. A camera supplier can be changed without a new gateway. That is what turns vendor independence from a line in the requirements into something you can actually exercise.

It is built on ITxPT, which exists precisely so this works across suppliers rather than only within one.

Fleets are rarely uniform any more. Diesel beside electric, buses beside trams, several vehicle generations in service at once, and sometimes more than one operator under the same authority.

When every vehicle type sits on the same architecture, they can be run and monitored as one operation instead of three parallel ones with three sets of tools and three people who each know how one of them works.

Position, CAN and FMS data, system status: it already exists in every vehicle. It is usually locked inside whichever system happened to collect it, in whatever format that supplier chose.

Collected once at the architecture level and shared in a standard format, the same data serves operations, maintenance and reporting at the same time. And it keeps working when the fleet changes, because the format does not depend on who won the last procurement.

Onboard networks usually carry ticketing, CCTV, passenger information and payment devices from several vendors on one flat network. Everything can reach everything, so a single compromised unit puts the whole vehicle at risk.

The answer is not to lock things down until nothing works. It is to separate the network into zones and permit only the traffic that has a reason to cross between them, so a compromised device reaches nothing else. Handled at the architecture level, it works without replacing the onboard hardware you already run.

It is also what produces the evidence: an inventory of what is connected, an audit trail, and a documented way of handling vulnerabilities when they turn up. Which is, in the end, what obligations under the Cyber Resilience Act and NIS2 come down to.