Successful modernization of process control

PRL is the system used by railway schedulers to operate signals and switches and set up tracks.
The system also detects malfunctions of switches, viaducts and other elements. This makes it into a highly critical system that requires 24/7 availability. Like other organizations with complex custom legacy applications, ProRail also faces the challenge: how can we modernize our landscape cost-effectively and without excessive risks? In a way that it becomes possible to quickly add new functionality and respond flexibly to market demand. After all, the application’s basic functionality is still relevant and a lot of time has been spent on upgrading the applications to the current standard. However, the technology used makes them too cumbersome and inflexible for today’s demands. Moreover, it is difficult to integrate into other applications, while the need for such integrated technology is increasing. These challenges play a role in almost all socially critical systems, whether they are in use in public transport, at a bank or at logistics hubs such as ports and airports.

New development too expensive and risky
Our time requires quick adaptability. You may be looking to rebuild your legacy applications, but this is much easier said than done. Many organizations with complex custom applications have made attempts, but only a few have succeeded. Even the ‘successful’ routes took longer than expected and turned out to be much more expensive than budgeted. In the less successful projects, the team did not even succeed in delivering an application, while a lot of resources ended up being wasted.
Because a huge number of these complex custom applications are used by the government, there has even been a parliamentary inquiry into this subject, led by Ton Elias. The picture that emerged from the inquiry actually applies to almost all socially critical systems: the applications are so large and contain so much interrelated functionality that the complexity is almost unforeseeable. This makes it terribly expensive and knowledge-intensive to redesign such applications, which have often been developed over a period of decades.

Old application in modern style
This was the reason for ProRail to decide not to rebuild PRL, but to modernize it. And even this is certainly not an easy task, says Bob Brands, Business Unit Manager at InTraffic. “The application was developed in PRL over a span of thirty years. It consists of various subsystems that are closely intertwined. You can only understand the coherence between architecture, functionalities and sub-applications if you have been closely involved in developing the application for an extended period of time. Because that’s when you get to the depth of the thought processes underlying certain developments that took place over the years. And then you learn why certain choices were made. And you understand what the application does in the many thousands of scenarios that may occur.”

“We develop Agile according to the Scrum method and use SAFe (the Scaled Agile Framework). This allows us to write new code much faster. We also added test automation in an application.”

Bob Brands, Business Unit Manager Rail

30-year-old application upgraded to DevOps environment
You need that knowledge if you want to modernize a legacy application of this size. Brands explains exactly what InTraffic has done. “We transferred PRL from the Pascal programming language to C++. The Open VMS was replaced by the open source OS Linux. In addition, we replaced the hardware that the environment ran on. Although the basis – i.e. the one and a half million lines of code – has been converted to C++, it has remained unchanged. However, the system has been modernized. That means we’re now running PRL in containers as a virtualized process. We develop Agile according to the Scrum method and use SAFe (the Scaled Agile Framework). This allows us to write new code much faster. We also added test automation in an application that was developed at a time when you would only check whether the system was working when it was in production. Finally, our modern way of working also allowed us to deploy the code automatically. Which means that we started working in a very modern way. Thanks to this new way of working, we managed to upgrade a thirty-year-old legacy application to a modern DevOps environment. As a result, we benefit from all the advantages offered by DevOps in terms of faster development, more frequent deliveries and more reliable delivery.” And of course, these factors are major benefits for our customer.

Prepared for the future
Currently, PRL60, as the new environment is called, has been implemented at two of the thirteen signalling stations. The other stations will be converted during the course of this year. By the time PRL60 works at all operating stations by the end of this year, ProRail will be better prepared for the future. A future in which malfunctions can be better prevented and handled, it will be easier to integrate the application into ERTMS and other systems, and the subsystems that make up PRL can be more easily untangled. “PRL60 allows ProRail to respond much faster to everything that happens, whether this involves disruptions or new developments that ProRail wants to implement,” Brands concludes.

“Thanks to this new way of working, we managed to upgrade a thirty-year-old legacy application to a modern DevOps environment. As a result, we benefit from all the advantages offered by DevOps in terms of faster development, more frequent deliveries and more reliable delivery.” And of course these factors are major benefits for our customer.

– Bob Brands, Business Unit Manager Rail