The Challenges of Modern Rail Control and How to Overcome them

Infrastructure managers (IM) that tender and purchase new rail control and signaling systems, seek to have the new systems delivered on time and with correct functionality at first installation. This is important to achieve, as it means that the costs for the IM will be within the tendered cost; conversely, not achieving this means delays and budget overruns. Often, delivery schedules include a first pilot line to be delivered and approved, followed by a larger scope of system deliveries.

Manage change for a Modern Rail Control solution

As computerised modern rail control systems have a long life time (some 15-25 years) and operate in a complex environment with many sub-systems with different life-time, the IM expects to be able to make upgrades to support change of requirements and functionality over time, and to replace individual sub-systems with minimal impact on surrounding systems. This is important in order to not disrupt operations, and to achieve reasonable life cycle cost (LCC).

Costs increase is a Major Challenge

The current situation is far from meeting the infrastructure manager expectations; a project to deliver a new rail control system often experiences challenges in the delivery of the first systems to be installed. The Safety Assessment is time consuming, and errors and omissions are found in a late stage in the software development process. This leads to that the first installation becomes delayed. Naturally, this affects the larger scope roll-out phase, making schedules long and unpredictable. This in turn delays the benefits of the new rail control systems, public perception suffers and costs increase.

Overall, the current situation is far from ideal for the infrastructure manager (IM), since the IM has to bear the cost and responsibility of all challenges related to the long and unpredictable delivery schedules. The need to make changes that are discovered late increase the costs, with higher cost the later the change is introduced.

The root causes

There are a number of factors contributing to the current situation as outlined above, both on the infrastructure manager side and the supplier side. One of the main factors is actually in the hands of the infrastructure manager (IM), at the very beginning of the process.

• Examples of these root causes can be:
• Vague tender requirements
• Manual development methods
• Traditional test & safety verification
• Lack of standard interfaces

You can read more about these root causes in our whitepaper on Interlocking Design Automation (IDeA).

A major issue today is the cost of change problem, which is due to the following main root causes:

• Vague and imprecise requirements
• Manual development methods
• Traditional verification methods
• Senior skills/expertise required

Address the root causes

A first key point to address the root causes of the cost of change problem is to establish useful requirements, so that they can be used with automation tools. This means that requirements need a high level of precision, to enable automated processing with modern tools, and to reduce the dependency on manual expertise for interpretation of requirements.

The second key point is that requirements need to clearly separate requirements that should be verified using functional testing from requirements that should be used in safety verification. The reason for this separation is to enable verification of the different types of requirements, using verification tools that are dedicated and specialized for safety assessment and functional testing, respectively.

You can read more about solutions to these issues – download our White paper on Interlocking Design Automation.