30-year-old PRL system pulled to 2021

PRL is the system that dispatchers use to operate signals and switches and set routes. The system also signals failures at switches, level crossings and other elements. It is therefore a very critical system that requires 24/7 availability. Just like other organizations with complex customized legacy applications, ProRail faces the challenge: how can we modernize our landscape cost-effectively and without too much risk? In such a way that it becomes possible to quickly add new functionality and flexibly respond to what the market demands. After all, the basic functionality of the applications is still relevant, and a lot of time has gone into getting them to the current level. But they are, because of the technology used, too unwieldy and inflexible for what current times demand. Moreover, while the need for such integrations is growing, it is complicated to develop integrations to other applications. These challenges apply to almost all society-critical systems, whether they are in use in public transport, at a bank or at logistics hubs such as an (air) port.

"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, Bussines Unit Manager Rail

New construction too expensive and risky

Today's times demand rapid adaptability. You may want to completely rebuild old legacy applications. However, that is much easier said than done. Many organizations with complex custom applications have made attempts; few have been successful. Even the "successful" trajectories took longer than expected and were many times more expensive than budgeted. In the less successful projects, not even an application was delivered and only a lot of resources were burned.

Because many such complex custom applications are in use in the government, there was even a parliamentary inquiry on this subject led by Ton Elias. The picture that emerged from that actually applies to almost all society-critical systems. Namely: the applications are so large and contain so much interrelated functionality that the complexity is almost impossible to comprehend. This makes it terribly expensive and knowledge-intensive to redesign such applications, which have often been developed for decades.

Old application in a modern guise

For this reason, ProRail decided not to rebuild PRL, but to modernize it. And that, too, is certainly no mean feat, says Bob Brands, business unit manager at InTraffic. "There has been thirty years of development in PRL. It consists of several subsystems that are closely intertwined. It is only possible to understand the connection between architecture, functionalities and sub-applications if you yourself have been closely involved in the development of the application for a long time. Because then you understand what thoughts have been behind certain developments over the years. Then you know why what choices were made. And you understand what the application does in the many thousands of scenarios that can occur."

"With this new way of working, we have brought a 30-year-old legacy application to a modern DevOps environment. As a result, we enjoy all the benefits that DevOps offers in terms of faster development, more frequent delivery and more reliable delivery. And that in turn benefits our customer."

- Bob Brands, Bussines Unit Manager Rail

30-year-old application brought to DevOps environment

You need that knowledge if you want to modernize a legacy application of this size. Brands explains exactly what InTraffic did. "We transferred PRL from the Pascal programming language to C++. We replaced the Open VMS with the open-source OS Linux. We additionally replaced the hardware the environment was running on. Although the basis - that is, the one and a half million lines of code - has been converted to C++, it has otherwise remained unchanged. However, the system is now in a modern package. That means we now run PRL virtualized in containers. We develop Agile according to the Scrum method and use SAFe (the Scaled Agile Framework). We can write new code much faster as a result. We've also added test automation in an application that was set up at a time when you didn't check if the system works until production. Finally, with our modern way of working, we made it possible to deploy code automatically as well. So we started working in a very modern way. With that new way of working, we took a 30-year-old legacy application to a modern DevOps environment. As a result, we benefit from all the advantages that DevOps offers in terms of faster development, more frequent delivery and more reliable delivery." And that in turn benefits our customer.

Prepared for the future

Currently, PRL60, as the new environment is called, has been implemented at two of the 13 signal stations. The other posts will be converted in the course of this year. When PRL60 is functioning at all control stations by the end of this year, ProRail will be better prepared for the future. A future in which failures can be better prevented and handled, easier integrations can be made with ERTMS and other systems, and the subsystems that make up PRL can be more easily unbundled. "With PRL60, ProRail can respond much faster to everything that happens, whether it's malfunctions or new developments that ProRail wants to join," Brands concludes.