By Miguel Munoz, Global Rail Director, Expleo Group
Signalling practices today are often influenced by a historical perspective shaped years ago, when the primary engineering focus was on building and maintaining physical infrastructure.
But that view is long out of date. Today, most signalling engineering effort is driven by software, from developing safety-critical code to testing, integrating, and validating it. The centre of gravity has shifted from physical infrastructure to digital engineering.
While engineering trains and tracks remains heavily dependent on physical equipment, requiring manufacturing facilities, components, and direct access to the vehicle and infrastructure, signalling follows a fundamentally different V-cycle.
As more signalling engineering moves into software and cloud-based environments, systems can be designed, integrated, tested, and validated virtually. Much of the engineering can happen remotely, long before anything reaches the track or the train – and this changes not just how we engineer signalling, but how quickly we can deliver it.
A broader view of the railway
The shift to software-defined systems engineering has also changed the nature of the work.
Today’s signalling engineers are expected to take a much broader view of the rail network: one that treats software, communications, rolling stock, and physical infrastructure as interdependent parts of the same safety-critical system.
They also have to account for the wider operating environment, including the operator’s requirements and the existing infrastructure the signalling system needs to work with. That’s a very different engineering problem from the one the industry was built around.
That broader systems view has placed much greater emphasis on standardisation and interoperability.
EULYNX, for instance, is pushing the industry towards more modular signalling architectures and common interfaces, making it easier to change or replace individual components without having to renew everything around them. In a sector where different countries have historically worked with their own signalling systems and operational requirements, shared standards provide a more consistent basis for connecting technology across rail networks.
Siemens’ Signaling X is moving in a similar direction. Signalling applications can be centralised on standardised computing infrastructure and connected through open, standardised interfaces, reducing reliance on proprietary hardware and enabling greater interoperability.
Updating an outdated engineering model
To me, the harder change is organisational, rather than technological.
Signalling engineering has moved from an electro-mechanical equipment-led challenge to a software-defined one, but the way we approach programs hasn’t kept pace.
Too often, a safety-critical product such as an interlocking is treated as a standalone piece of equipment to be commissioned. Yet a modern interlocking sits within a much wider safety-critical system, where software, communications, cybersecurity, and the physical railway all play an important role. As systems grow in scale and become increasingly interconnected, interoperability and future requirements also need to be considered from the outset.
To be clear, this is not just a skills-gap problem. Signalling engineers are already doing the difficult software work and have been for years. The main challenge is getting the engineering model to catch up, moving away from projects conceived around individual assets and towards software-defined systems that are engineered around the railway as a whole.
We already have the tools and the expertise. What matters now is whether we can change engineering processes at the same pace as the technology itself has changed.
Ready to rethink your approach to signalling engineering?
Discover how Expleo’s rail engineering services can support your move towards software-defined, integrated systems.
