Despite exciting technological advancements, carrying out a successful rail control project today remains a complex burden with a multitude of challenges for both infrastructure managers and suppliers. Here, we\u2019ll take a deeper look at the underlying issues and discuss how implementing Signal Design Automation can help you eliminate inefficiencies and costly errors\u2014and finally gain control over your systems.<\/p>\n
What\u2019s standing in the way of your successful rail control project?<\/h3>\n
There are a number of factors standing in the way of a successful rail control project. Rail control systems are expensive to procure, develop, and maintain. Costs and schedules are routinely exceeded. Errors and shortcomings in procured systems are often discovered late when it\u2019s too difficult to make changes. And attempting to address all these problems causes further delays to the entire process before systems can finally be put into revenue services. All in all, this generates a lot of frustration for all parties involved and contributes to the end customer feeling out of control.<\/p>\n
Underlying these challenges is the fact that the railway market is still relatively conservative when it comes to adopting future production processes that are related to these systems. And the relatively small number of dominant suppliers in the market today makes driving the change that\u2019s needed even more difficult.<\/p>\n
Common challenges in rail control projects<\/h3>\n\n- Systems are costly to procure, develop, and maintain<\/li>\n
- Costs and schedules are routinely exceeded<\/li>\n
- Proprietary solutions, reducing competition and creating vendor lock-in<\/li>\n
- Errors and omissions are discovered late<\/li>\n
- End customer not in control<\/li>\n
- Conservative attitude to future production processes (slow and inefficient production)<\/li>\n
- Supplier landscape \u201coligopoly\u201d (few dominant suppliers)<\/li>\n
- Status quo being preserved<\/li>\n<\/ul>\n
Rail control project stakeholders<\/h3>\n
In rail control projects, the main stakeholders are the Infrastructure Managers (IM), who own the rail control systems, and the Suppliers who develop these systems. There are also a number of system consultants and vendors involved.<\/p>\n
Addressing the root causes<\/h3>\n
By digging down to the root of the common challenges in rail control projects, we can more easily identify what kinds of solutions are needed in order to move past them. There are three main root causes that need to be addressed.<\/p>\n
Root cause #1: Tender requirements tend to be imprecise
\nThe first root cause is related to what the customer actually needs. Tender requirements for rail control systems tend to be imprecise, with a lack of clarity regarding what the requirements actually are for the system standard. This can lead to suboptimal design choices, with drawbacks that might not be discovered until it\u2019s too late and too expensive to make changes. It can also lead to a system being delivered based on proprietary choices, resulting in vendor lock-in.<\/p>\n
Root cause #2: Verifications are based on traditional methods
\nAnother root cause is the fact that the verification activities, which are used during development and before commissioning, are very much based on outdated methods. For instance, the time-consuming and error-prone review and testing processes. While reviews and testing are useful and important, the verification coverage is poor. That is, you can detect the issues but you cannot prove that there are no issues remaining. So, together with the first root cause, vague and imprecise requirements make it really difficult to perform verifications well because relying only on human judgement usually causes a bottleneck.<\/p>\n
Root cause #3: Lack of standard architecture and interfaces
\nThe third root cause is a lack of standard architecture and interfaces. Of course, standards and standard interfaces do exist, but when it comes to the actual systems, there are many parts of those systems or subsystems that don\u2019t really belong to a standard architecture or have standard interfaces. This makes it a little more difficult to reuse requirements and know-how about systems. And if you have multiple suppliers, you may have to duplicate the effort for each system. This also makes it harder to use commercial, off-the-shelf components and prevents you from going as far as you may want to when it comes to plug-and-play concepts.<\/p>\n
Our solution: Signaling Design Automation (SDA)<\/h3>\n
All of the challenges infrastructure managers and suppliers run up against during rail control projects can be solved by adopting a better production process. At Prover, our mission is to supply the industry with tools and processes that meet the requirements and expectations of the end customers. We do this by focusing on the requirement specifications, using automation to develop the systems, and applying formal and automated methods to prove that the requirements are fulfilled.<\/p>\n
So what does a better production process look like? Our solution is something we call Signaling Design Automation (SDA).<\/p>\n
What is SDA?<\/h3>\n
SDA is a set of automation tools and processes, based on generic, formal specification principles, that is used to develop the software for rail control projects. The idea is that SDA instantiates these generic principles for a particular configuration and produces the design and software code for a particular system. SDA also performs safety verification to produce safety evidence, as well as automated testing to create a test report. These point tools are highly automated and based on the principles, the configuration, and the actual code. Of course, it\u2019s also possible to use different code generation back-ends to generate the code.<\/p>\n
4 steps to a successful rail control project<\/h3>\n
Here is a summary of the actions needed to address the most common challenges and, finally, run a successful rail control project using SDA.<\/p>\n
1. Structure your configuration data and system requirements
\nThe key to success in any rail control project is creating a proper specification of the project\u2019s needs, requirements, and expectations. The infrastructure manager needs to specify their own knowledge of both the solutions that they already have and of the solutions that they want to be delivered in the future.<\/p>\n
2. Create a Digital Twin before tender
\nWith this in mind, infrastructure managers can do a better job with tender specifications. Creating a Digital Twin before a tender is made is a practical way to get to a point where requirements are more precise and systems can be verified. Of course, this is also a critical action when it comes to procuring systems at a reasonable price, because it gives suppliers a better chance of meeting expectations<\/p>\n
3. Use SDA tools to improve approval-related V&V
\nBoth infrastructure managers and suppliers can use SDA tools to improve the verification and validation (V&V) that needs to take place before software systems can be approved for revenue service. This can include both simulation (standard test suites) and formal verification (verifying requirements on configuration data and safety as well as testing). This also gives improved coverage in V&V and reduces the effort and time required for safety assessment. Especially if you replace more traditional approaches.<\/p>\n
4. Use SDA to deliver software based on the Digital Twin
\nFinally, SDA can be used in its full context to develop and deliver software based on the Digital Twin. This is a way to adopt future production processes, including more automation and stronger V&V tools, and\u2014as a result\u2014 reduce risks and resource needs, and allow high-quality software to be delivered in a more predictable way.<\/p>\n
Learn more about how Signaling Design Automation can help you run a more successful railway development project here<\/a>.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
Rail control project stakeholders<\/h3>\n
In rail control projects, the main stakeholders are the Infrastructure Managers (IM), who own the rail control systems, and the Suppliers who develop these systems. There are also a number of system consultants and vendors involved.<\/p>\n
Addressing the root causes<\/h3>\n
By digging down to the root of the common challenges in rail control projects, we can more easily identify what kinds of solutions are needed in order to move past them. There are three main root causes that need to be addressed.<\/p>\n
Root cause #1: Tender requirements tend to be imprecise
\nThe first root cause is related to what the customer actually needs. Tender requirements for rail control systems tend to be imprecise, with a lack of clarity regarding what the requirements actually are for the system standard. This can lead to suboptimal design choices, with drawbacks that might not be discovered until it\u2019s too late and too expensive to make changes. It can also lead to a system being delivered based on proprietary choices, resulting in vendor lock-in.<\/p>\n
Root cause #2: Verifications are based on traditional methods
\nAnother root cause is the fact that the verification activities, which are used during development and before commissioning, are very much based on outdated methods. For instance, the time-consuming and error-prone review and testing processes. While reviews and testing are useful and important, the verification coverage is poor. That is, you can detect the issues but you cannot prove that there are no issues remaining. So, together with the first root cause, vague and imprecise requirements make it really difficult to perform verifications well because relying only on human judgement usually causes a bottleneck.<\/p>\n
Root cause #3: Lack of standard architecture and interfaces
\nThe third root cause is a lack of standard architecture and interfaces. Of course, standards and standard interfaces do exist, but when it comes to the actual systems, there are many parts of those systems or subsystems that don\u2019t really belong to a standard architecture or have standard interfaces. This makes it a little more difficult to reuse requirements and know-how about systems. And if you have multiple suppliers, you may have to duplicate the effort for each system. This also makes it harder to use commercial, off-the-shelf components and prevents you from going as far as you may want to when it comes to plug-and-play concepts.<\/p>\n
Our solution: Signaling Design Automation (SDA)<\/h3>\n
All of the challenges infrastructure managers and suppliers run up against during rail control projects can be solved by adopting a better production process. At Prover, our mission is to supply the industry with tools and processes that meet the requirements and expectations of the end customers. We do this by focusing on the requirement specifications, using automation to develop the systems, and applying formal and automated methods to prove that the requirements are fulfilled.<\/p>\n
So what does a better production process look like? Our solution is something we call Signaling Design Automation (SDA).<\/p>\n
What is SDA?<\/h3>\n
SDA is a set of automation tools and processes, based on generic, formal specification principles, that is used to develop the software for rail control projects. The idea is that SDA instantiates these generic principles for a particular configuration and produces the design and software code for a particular system. SDA also performs safety verification to produce safety evidence, as well as automated testing to create a test report. These point tools are highly automated and based on the principles, the configuration, and the actual code. Of course, it\u2019s also possible to use different code generation back-ends to generate the code.<\/p>\n
4 steps to a successful rail control project<\/h3>\n
Here is a summary of the actions needed to address the most common challenges and, finally, run a successful rail control project using SDA.<\/p>\n
1. Structure your configuration data and system requirements
\nThe key to success in any rail control project is creating a proper specification of the project\u2019s needs, requirements, and expectations. The infrastructure manager needs to specify their own knowledge of both the solutions that they already have and of the solutions that they want to be delivered in the future.<\/p>\n
2. Create a Digital Twin before tender
\nWith this in mind, infrastructure managers can do a better job with tender specifications. Creating a Digital Twin before a tender is made is a practical way to get to a point where requirements are more precise and systems can be verified. Of course, this is also a critical action when it comes to procuring systems at a reasonable price, because it gives suppliers a better chance of meeting expectations<\/p>\n
3. Use SDA tools to improve approval-related V&V
\nBoth infrastructure managers and suppliers can use SDA tools to improve the verification and validation (V&V) that needs to take place before software systems can be approved for revenue service. This can include both simulation (standard test suites) and formal verification (verifying requirements on configuration data and safety as well as testing). This also gives improved coverage in V&V and reduces the effort and time required for safety assessment. Especially if you replace more traditional approaches.<\/p>\n
4. Use SDA to deliver software based on the Digital Twin
\nFinally, SDA can be used in its full context to develop and deliver software based on the Digital Twin. This is a way to adopt future production processes, including more automation and stronger V&V tools, and\u2014as a result\u2014 reduce risks and resource needs, and allow high-quality software to be delivered in a more predictable way.<\/p>\n
Learn more about how Signaling Design Automation can help you run a more successful railway development project here<\/a>.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
![](\"https:\/\/www.prover.com\/wp-content\/uploads\/2024\/07\/safety.png\" "\\"safety\\"")
<\/span><\/div><\/div><\/div>