More efficient rail control projects using Signaling Design Automation

The delivery of rail control projects often suffers from high costs, unpredictable schedules and delays. Moreover, the life cycle of modern, computerized, signaling systems is often shorter than those of traditional relay-based systems, with higher maintenance costs. At the same time the need for new, more advanced rail control systems is growing, to optimize the use of existing, congested, infrastructure and to meet the demands from an increasing number of passengers. This situation drives the need for more efficient ways to deliver and ensure safety in Rail Control Projects. 

In this series of three blog posts on the subject we call Signal Design Automation, we will take a look at the reasons for this situation, present a solution and finally look at a case study where a Signal Design Automation process has been successfully applied in a real-life project.

Expectations and challenges in rail control projects

The successful delivery of a rail control system should meet the following typical expectations from the Infrastructure Manager:

• Improved interoperability and reliability, supporting system upgrades
• 1st delivery of the system shall be on time and have the correct functionality
• Efficient safety assessment for guaranteed safety
• Reduced life-cycle cost
  • Individual sub-systems should be separated with clear interfaces, providing flexibility in extending the overall life cycle
  • Support for change of requirements and functionality over time

Unfortunately, this is often quite far from the reality, and Infrastructure Managers (IM) are instead faced with signal modernization projects that:

• Requires multiple deliveries before the correct functionality can be demonstrated
• Safety Assessment is time consuming and largely done at late, critical stage in the rail control project
• Exceeds budgets and are delayed
• Locks the Infrastructure Manager to the same vendor for a long time, making maintenance and upgrades costly

In our experience, there is a number of root causes to this situation, both at the Infrastructure Manager side and on the supplier side. Naturally, suppliers may not benefit from delivering systems with open interfaces between sub-components and, if they are not required to do otherwise, they will happily stick to proprietary systems, enabling the supplier to dictate the conditions when the Infrastructure Manager is looking for an upgrade or component replacement. Here the Infrastructure Managers must drive the shift to industry standards and open interfaces and indeed there are initiatives in this direction, such as euLynx, in which thirteen European Infrastructure Managers are working together to define standard interfaces for interlocking systems. 

Meeting the expectations in rail control project delivery

A key factor to success in any project is that the stakeholders can agree on the requirements, i.e. what is to be delivered, and that it is easy to validate that a delivery meets the requirements. In many tender specifications, the technical requirements formulated by the Infrastructure Manager are kept vague. Either as a deliberate strategy to give the supplier freedom to bid with the most cost-efficient solution, or since the requirements, and their importance, are not fully understood by the procuring organization.

A big risk with this approach is that there are a lot of implicit expectations and requirements that are not communicated with the supplier, and in the end the users may not get the system they wanted, even though it fulfills all the specified requirements. Without clear requirements it can also be difficult to understand the impact of different design solutions until the system is close to completion, at which time changes can be very costly. On the other hand, if the supplier can present the Infrastructure Manager with a clear specification, where functionality can be demonstrated with early prototyping at the start of the project, the chances of agreeing on the requirements and succeeding with the project are greatly improved. 

The other option is for the Infrastructure Manager to take control of the requirements and clearly specify, already at the tender stage, exactly what is expected of the system. Then it also becomes natural to require that the systems make use of open interfaces, addressing the issues of vendor-lock in and high cost of upgrades during the life cycle. And it works the other way around too; if you already have clear definitions of the system interfaces, then it becomes natural to provide clear requirement specifications for the overall system as well.

Clearly defined requirement specifications also pave the way for automation, as the step to formalize, or implement, them in a way that can be interpreted by automation tools will be small. The coding, functional testing and safety verification that turns the specifications into revenue services software can then be done automatically from simple application configurations.

A high level of automation means that it will be less costly to implement and evaluate the impact of changed requirements and increases the chances of getting the functionality right at the first installation. The use of automated, formal, safety verification, addresses many of the issues around the safety assessment in traditional development processes and can be applied throughout the development. Finally, a Signal Design Automation solution need not be vendor specific, and thus can further help avoiding vendor lock-in, especially if it is combined with the use of standardized components and interfaces. 

Formal Verification, a key to success in your rail control project

Formal Verification is a method to prove with 100% certainty that a system fulfills a given set of safety requirements. In practice this verification is automated, using computer programs that implement mathematical algorithms performing the proofs. Formal Verification is a key component to maximize the level of automation in the delivery of Rail Control Software, as it can remove many of the manual safety review tasks typically used in traditional safety assessment processes. It is also the only manageable way to deal with the safety verification of more and more complex systems, without risk of losing the confidence in the system safety, or accelerating the verification costs and delivery times.

If you want to know more about Formal Verification you can study our recorded webinar here.