Safety in Rail Control Projects https://www.prover.com/categories/safety/ Interlocking Design Automation to meet demand for complex digital train control Tue, 24 Mar 2026 11:46:50 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.4 Prover and BHEPL Partner to Bring Signaling Design Automation to India https://www.prover.com/safety/prover-and-bhepl-partner-to-bring-signaling-design-automation-to-india/ Thu, 27 Nov 2025 09:10:00 +0000 https://www.prover.com/?p=22413 The Open signaling Initiative is transforming how railway and metro signaling systems are delivered.

By combining modular technology, collaboration, and open standards, it reduces vendor lock-in, cuts lifecycle costs, and creates space for innovation.

Inlägget Prover and BHEPL Partner to Bring Signaling Design Automation to India dök först upp på Prover - Engineering a Safer World.

]]>
At Prover, we are proud to announce our strategic collaboration with BHEPL (Bharat Heavy Engineering Private Ltd) to introduce advanced Signaling Design Automation solutions to India’s rapidly expanding railway sector.

Empowering the Future of Indian Railways

India is undertaking one of the world’s largest railway modernization initiatives, with KAVACH — the nation’s indigenous Automatic Train Protection (ATP) system — at its core. Through this partnership, Prover and BHEPL will focus on automating data preparation and verification for KAVACH deployments, enabling suppliers to streamline engineering workflows, reduce manual errors and improve overall safety. 

Leveraging Prover iLock, BHEPL will customize and automate the generation of essential datasets such as RFID tag layouts, control tables, gradient plans and other key KAVACH project deliverables. These activities, traditionally performed manually over several weeks, can now be completed in a fraction of the time with higher accuracy and consistency. 

Extending Automation to Metros and Beyond

Our collaboration extends beyond KAVACH. Prover and BHEPL are actively working with metro operators, Indian Railways, and signaling suppliers to explore broader automation opportunities  ranging from interlocking design to CBTC (Communication-Based Train Control) software development. Together, we aim to accelerate the deployment of safe, efficient, and digitallyverified signaling systems across India. 

A Shared Commitment to Safety, Reliability, and Efficiency

“India’s railway modernization drive presents an incredible opportunity to showcase how automation and formal methods can enhance safety, reliability and cost efficiency,” says Gunnar Smith, Chief Product Officer at Prover. “BHEPL’s strong engineering expertise, combined with our globally proven automation tools, is a powerful combination for achieving these goals.” 

Sudhir Reddy, Director at BHEPL, adds: 
“By partnering with Prover, we aim to bring world-class automation and verification capabilities to Indian Railways and metro systems. This collaboration aligns perfectly with India’s vision for a digitally transformed rail ecosystem. The automation tools and products we are co-developing with Prover will be a significant technological advancement for Indian Railways.” 

Introducing Prover iLock for KAVACH: Generative-AI–Driven Design Document Automation for Indian Railways

Prover and BHEPL are launching a Generative AI-powered solution, based on Prover iLock, designed specifically for automating signaling and KAVACH engineering documentation. 

This solution, co-engineered with BHEPL, uses Generative AI, formal methods and rule-based validation to: 

  • Generate, verify and standardize complex signaling documents 
  • Interpret datasets such as SIPs, TOCs, gradient plans and RFID tag layouts 
  • Produce RDSO-compliant outputs automatically 
  • Reduce engineering cycle times from weeks to hours 

With adaptive learning models tailored to Indian Railways, Prover iLock understands and evolves with: 

  • National railway standards 
  • KAVACH-specific data structures 
  • Interlocking principles 
  • RFID-based control logic 

This enables Prover iLock to function not only as a documentation tool but also as a simulation, verification and validation environment capable of: 

  • Virtual testing of KAVACH configurations 
  • Simulating interlocking behavior 
  • Verifying tag placement logic 
  • Ensuring fail-safe operation before field implementation 

These capabilities significantly reduce on-site testing time and accelerate certification. 

Upcoming CBTC Automation Module

Prover and BHEPL are finalizing a CBTC design automation module, marking a major advancement for India’s metro signaling ecosystem. By integrating Prover’s proven formal verification technologies, the CBTC extension will automate the generation and verification of: 

  • Zone Controller and ATS control logic, including routing rules, interlocking behavior and operational constraints 
  • Movement authority and speed profile logic, consistent with moving block or quasi-moving block CBTC principles 
  • Interface and communication message definitions, ensuring correctness of onboard-trackside and ATS-DCS interactions 

This automation significantly reduces manual engineering effort, enhances functional safety and accelerates delivery of highly reliable, digitally verified CBTC systems – supporting India’s transition toward a fully automated, safety-assured metro network. 

About Prover 

Prover is a global leader in signaling design automation and formal verification, helping rail operators and suppliers deliver safe, certifiable signaling systems faster and more efficiently. Our tools are deployed worldwide to automate the design, verification and validation of rail control systems. 
Learn more at www.prover.com. 

About BHEPL

BHEPL (Bharat Heavy Engineering Private Ltd) is an Indian engineering company specializing in railway signaling, electrification and automation. With a strong presence in national infrastructure projects, BHEPL delivers end-to-end solutions to Indian Railways and metro systems, contributing to India’s ongoing modernization efforts. 
Learn more at  www.bhepl.com. 

Inlägget Prover and BHEPL Partner to Bring Signaling Design Automation to India dök först upp på Prover - Engineering a Safer World.

]]>
CentraleSupélec students taste Signal Design Automation https://www.prover.com/safety/centralesupelec-students-taste-signal-design-automation/ Tue, 25 Nov 2025 07:20:19 +0000 https://www.prover.com/?p=22398 The Open signaling Initiative is transforming how railway and metro signaling systems are delivered.

By combining modular technology, collaboration, and open standards, it reduces vendor lock-in, cuts lifecycle costs, and creates space for innovation.

Inlägget CentraleSupélec students taste Signal Design Automation dök först upp på Prover - Engineering a Safer World.

]]>
Another year working with the talented students of CentraleSupélec in Paris during an intensive week of railway system engineering using the latest Prover tools.

Exploring the interlocking’s full lifecycle

Our goal was to help them explore the entire lifecycle of a railway interlocking system, from layout design and safety requirements to formal verification and testing, all supported by Prover Studio and Prover iLock. The challenge was to build a complete railway line with 7 interlockings, prove the safety of the line, and simulate the behaviour of the whole system.

We began by introducing the fundamentals of railway signalling and explaining what an interlocking is. Equipped with this knowledge, the students first debugged an existing interlocking system following fundamental signalling principles by using formal verification.
Once confident, they defined and verified new safety requirements, created test cases, and implemented a manual release feature, addressing design, safety, and testing aspects within a single, integrated workflow.

Impressive Progress and Collaboration

We extend our warmest thanks to the CentraleSupélec students for their commitment and enthusiasm throughout the week. They impressed us with how quickly they are handling our tools, modelling language, and dealing with the complexities of the railway domain. Special thanks also go to Idir Ait Sadoune and the teaching team for renewing their trust in us again this year.

At Prover, we firmly believe that introducing formal methods and signalling engineering to the next generation of engineers is essential for building safer and more reliable railway systems. We look forward to seeing these talented students again, in the railway industry or the field of formal verification, as they help engineer a safer world.

Inlägget CentraleSupélec students taste Signal Design Automation dök först upp på Prover - Engineering a Safer World.

]]>
Software formal verification in the context of CENELEC EN 50716: from model to sign-off verification https://www.prover.com/webinar/software-formal-verification-in-the-context-of-cenelec-50716-from-model-to-sign-off-verification/ Fri, 21 Nov 2025 14:28:09 +0000 https://www.prover.com/?p=22390 EN 50716 (the successor to EN 50128/EN 50657) sets the software development and verification expectations for railway applications, clarifying how formal methods and tool qualification contribute to a robust safety case. This session takes a practitioner’s view of applying that framework to real systems and on‑board functions.

Inlägget Software formal verification in the context of CENELEC EN 50716: from model to sign-off verification dök först upp på Prover - Engineering a Safer World.

]]>
RECORDED WEBINAR

Safety

As rail control software gets more complex, the real challenge is to ensure that implementations meet safety and functional requirements efficiently and convincingly. EN 50716 (the successor to EN 50128/EN 50657) sets the software development and verification expectations for railway applications, clarifying how formal methods and tool qualification contribute to a robust safety case. This session takes a practitioner’s view of applying that framework to real systems and on‑board functions.

We’ll walk through a repeatable assurance workflow: capture requirements as verifiable properties, model behavior in HLL and its sequential extension sHLL, use model checking to explore relevant executions, and establish auditable conformity between specification and implementation. We’ll illustrate the approach using Prover’s toolchain (HLL/sHLL, Prover PSL, Prover Certifier) to make the approach concrete, while maintaining the emphasis on methods, evidence, and governance that can be adopted in any environment.

Agenda:
  • EN 50716 in practice. What changed from EN 50128/EN 50657, specifically regarding the role of formal methods within the lifecycle, and what auditors expect in terms of tool classification and evidence.

  • A pragmatic formal‑assurance workflow. From property‑driven requirements to HLL/sHLL models, Prover PSL model‑checking, traceability, and preparation of sign‑off evidence.

  • Software conformity by proof. How proof‑producing sign‑off with a T2‑qualified engine (e.g., Prover Certifier) demonstrates alignment between specification and implementation for SIL‑classed applications.

  • Quality & efficiency gains. Ways to shorten verification cycles, raise coverage beyond testing, and catch defects earlier—without disrupting your current development process.

Why the railway industry needs to modernize its methods of safety assurance

Yes please, send me the recording!

Speakers
Benjamin Blanc Prover

Benjamin Blanc
Solutions Manager at Prover

Inlägget Software formal verification in the context of CENELEC EN 50716: from model to sign-off verification dök först upp på Prover - Engineering a Safer World.

]]>
Formal Safety Verification – How to deliver 100% safe and compliant rail control systems without time delay https://www.prover.com/safety/formal-safety-verification-railway-safety/ Fri, 14 Nov 2025 11:32:20 +0000 https://www.prover.com/?p=22379 The Open signaling Initiative is transforming how railway and metro signaling systems are delivered.

By combining modular technology, collaboration, and open standards, it reduces vendor lock-in, cuts lifecycle costs, and creates space for innovation.

Inlägget Formal Safety Verification – How to deliver 100% safe and compliant rail control systems without time delay dök först upp på Prover - Engineering a Safer World.

]]>
The challenge of verifying safety in complex rail systems

Imagine a train weighing thousands of tons, moving at 200 km/h – and hundreds operating simultaneously across a network, guided only by software and signals. When everything works as intended, operations are seamless. However, if something goes wrong, the consequences can be catastrophic, including lives at risk, infrastructure damage, and service disruption.

Over the past decades, railway control systems have grown increasingly complex. Testing and manual reviews remain essential, but they can no longer ensure full coverage. The number of possible system states is simply too vast. In many cases, billions of combinations that no test suite could ever exhaust. Traditional methods show the existence of bugs, not their absence.

A new era of railway safety verification

Formal Safety Verification (FSV) is a breakthrough approach that utilizes mathematical proof to ensure a system meets its safety requirements in every possible state. Instead of relying on selected test cases, engineers use models and automated verification tools to prove that no unsafe scenarios can occur exhaustively.

Prover’s Solution Formal Safety Verification makes this process industrially viable. It integrates proven formal methods with efficient tooling to verify complex rail control systems at scale, across all Safety Integrity Levels (SIL 0-4) and in compliance with CENELEC standards EN 50716, EN 50126, EN 50128, and EN 50129.

How safety is usually handled

In EN 50126, safety is an independent process that starts with the identification of all potential hazards that can affect your system. Then, provided the likelihood of these risks is high enough, some mitigation is added as an extra requirement to the development of the system, with a dedicated SIL level.

For instance, a function of the control system will be tagged as SIL4, and the means to address this criticality is to develop this function following the EN 50716 process, with testing and reviews, and even formal proof to verify that the requirements are correctly implemented. The safety case then collects evidence that the whole process covers these risks, by the book.

From traditional testing to formal proof

Traditional verification relies heavily on reviews and test campaigns that are both labor-intensive and prone to human error. Engineers spend valuable time ensuring coverage and tracking potential corner cases: test scenarios are based on the experience or imagination of the test team.

Formal Safety Verification changes the paradigm. Instead of ensuring that the requirements are implemented as they should be, the new process begins with the hazards themselves, utilizing a model of the system design in a formal language to create a digital twin of the control system. Automated model checkers then verify that the model fully satisfies all hazards, independently of their mitigation. If issues exist, they are presented as high-level scenarios, such as train movements or route conflicts, enabling engineers to pinpoint and resolve potential hazards early.

The result: complete coverage, faster verification cycles, and certified safety evidence generated automatically.

Introducing Prover Diagnostic

At the heart of Prover’s solution lies Prover Diagnostic – a packaged, hazard-based formal verification tool that identifies and eliminates potential safety risks before deployment.

Prover Diagnostic integrates:

  • Safety properties, derived from system hazards (e.g., collision or derailment scenarios).
  • Environment models define real-world constraints, such as the behavior of wayside components (e.g., switch machines), train movement logic, and operational procedures.
  • Formal system models, automatically generated or imported from existing design data.

Together, these components form a rigorous verification process in which hazardous states are either proven impossible or clearly reported for review. Prover Diagnostic ensures 100% coverage, a feat no test-based approach can match.

Proven in leading railway projects

Formal Safety Verification isn’t theoretical – it’s field-proven for many years.

  • Stockholm Metro uses Prover’s formal methods for both computerized and relay-based interlockings, supported by digital twins for system-level modeling. The approach enables competition among signaling suppliers, reduces lifecycle costs, and ensures consistent safety assurance across upgrades.
  • RATP (Paris Metro) applies hazard-based formal verification using Prover tools to validate CBTC systems from multiple suppliers.
  • Alstom, one of the world’s largest rail suppliers, integrates formal methods with Prover PSL and Prover Certifier in its global verification process, enabling exhaustive, automatic safety demonstrations from design through implementation.

These projects demonstrate the maturity and scalability of Formal Safety Verification in real-world railway environments. In many cases, the process reveals and allows for the correction of critical bugs missed by traditional testing.

Formal Safety Verification: a summary of the benefits

  • 100% safety requirement coverage – mathematically proven, not sampled.
  • Early detection of design issues – reducing rework and project delays.
  • Certified safety evidence – supporting compliance with international standards.
  • Reduced testing and review effort – accelerating delivery while improving reliability.
  • Field-proven solution – trusted by leading metros, railways, and signaling suppliers worldwide.

Ready to prove safety with certainty?

Formal Safety Verification empowers rail engineers to deliver provably safe systems – faster and with complete confidence.

Watch the on-demand webinar to learn how Prover’s solution works, explore real-world case studies, and see how formal methods can transform your railway safety verification process.

Watch the webinar recording

Inlägget Formal Safety Verification – How to deliver 100% safe and compliant rail control systems without time delay dök först upp på Prover - Engineering a Safer World.

]]>
AI, a key enabler for Signaling Design Automation https://www.prover.com/webinar/ai-a-key-enabler-for-signaling-design-automation/ Thu, 09 Oct 2025 15:02:07 +0000 https://www.prover.com/?p=22299 With recent advances in AI, we can make SDA more accessible to the rail control community.

Our goal is to simplify SDA and Formal Methods, and in this webinar, we will demonstrate how AI enables us to achieve this. 

Inlägget AI, a key enabler for Signaling Design Automation dök först upp på Prover - Engineering a Safer World.

]]>
RECORDED WEBINAR

Safety

Recorded on November 5, 2025

At Prover, we address the demand for cost-efficient rail control delivery through Signaling Design Automation (SDA), based on Formal Methods. SDA is also central to the Open Signaling Initiative, promoting open, modular, and interoperable signaling systems. 

With recent advances in AI, we can make SDA more accessible to the rail control community. Adoption challenges often lie in digitizing data, managing requirements, and mastering the technologies. Our goal is to simplify SDA and Formal Methods. In this webinar, we demonstrate how AI enables us to achieve this. 

Agenda:
  • The vision for how AI will change the development of safe rail control systems

  • Introduction to Signaling Design Automation and Formal Methods

  • AI use cases in Signaling Design Automation

  • Demonstration: Requirement engineering with AI in Prover Studio

  • Interactive Q&A with Prover’s AI and product experts

Why the railway industry needs to modernize its methods of safety assurance

Yes please, send me the recording!

Speakers
Gunnar Smith Prover

Gunnar Smith
Chief Product Officer at Prover

Fei Niu Prover

Fei Niu
AI Innovation Lead at Prover

Inlägget AI, a key enabler for Signaling Design Automation dök först upp på Prover - Engineering a Safer World.

]]>
How to deliver 100% safe and compliant rail control systems without time delay https://www.prover.com/webinar/formal-safety-verification/ Thu, 14 Aug 2025 12:54:21 +0000 https://www.prover.com/?p=21997 Watch the expert-led session to discover how Formal Safety Verification helps eliminate safety risks early and ensure CENELEC-compliant rail systems.

Inlägget How to deliver 100% safe and compliant rail control systems without time delay dök först upp på Prover - Engineering a Safer World.

]]>
RECORDED WEBINAR

Safety

Recorded on September 10, 2025

As digital rail control systems evolve, so do the challenges in validating their safety. Manual testing and reviews are no longer sufficient; they are expensive, slow, and can’t guarantee complete safety. Meanwhile, the cost of missed errors or late-stage discoveries can cause severe project delays or system failures.

Prover’s Formal Safety Verification solution enables a faster, more efficient, and more reliable way to ensure your system meets all safety requirements. It is mathematically proven, highly automated, and compliant with CENELEC standards.

Watch this webinar to learn how formal methods can help you avoid costly project delays, eliminate safety gaps, and streamline your certification process. 

What you will learn:
  • Why traditional verification approaches struggle with today’s complex rail systems

  • What formal safety verification is and how it works

  • How to use model-based development and mathematical proof to ensure 100% requirement coverage

  • How Prover’s new solution enables early issue detection, automation, and certified safety evidence

  • Real-world results from leading metros, railways, and signaling suppliers.

Why the railway industry needs to modernize its methods of safety assurance

Yes please, send me the recording!

Speakers
Gunnar Smith Prover

Gunnar Smith
Chief Product Officer at Prover

Daniel Fredholm Prover

Daniel Fredholm
Senior Consultant at Prover

Inlägget How to deliver 100% safe and compliant rail control systems without time delay dök först upp på Prover - Engineering a Safer World.

]]>
Reachability analysis as a way to validate requirements and constraints https://www.prover.com/formal-methods/reachability-analysis/ Tue, 21 Jan 2025 08:07:16 +0000 https://www.prover.com/?p=21077 Discover how reachability analysis enhances formal verification by ensuring realistic scenarios and validating safety requirements in railway signaling systems. Learn about key techniques, including proof coverage, constraints softening, and early-stage validation, and explore how our tools make this process more efficient.

Inlägget Reachability analysis as a way to validate requirements and constraints dök först upp på Prover - Engineering a Safer World.

]]>

A part of a modern standard methodology for formal verification is to do reachability analysis. At Prover, we use it as an integrated part of our process to validate requirements and constraints, as well as to find design flaws.

While proof obligations are properties that must always be true (which you are required to prove), reachability obligations are properties that should be possible to make true. They state that there must be a way for the system under investigation to reach a state where they are true. There must not necessarily be one state that makes them all true at the same time (which might be impossible), but rather one scenario per reachability obligation.

Constraints for proof obligations and reachability obligations

For train and metro signaling systems, safety is very important, so proof obligations have been used for a long time: state your safety properties as proof obligations and let a model checker prove that they are always fulfilled by the signaling system. For example, a safety property might say that whenever a train receives permission to proceed (e.g. by a signal or a radio message), all switches in the route must be locked in the correct position. Formal verification is sometimes performed based on assumptions about the environment. Perhaps about the behavior of trains, or about physical equipment such as relays. Such assumptions are added as constraints in the verification model. The name constraints comes from the fact that they can be viewed as constraining the search space for possible states of the system.

Correctly used, constraints exclude non-realistic scenarios and let the model checker focus on realistic scenarios only. A mistake in the formulation of constraints can, however, have very severe consequences. If too many scenarios are excluded, then they will be ignored by the model checker, even if they can happen and would be dangerous.

For reachability analysis, constraints contribute by restricting how reachability obligations are allowed to be reached. The scenario produced will fulfill the constraints. If this is not possible, the reachability obligation is called unreachable.

Ways to find erroneous constraints

There are a number of techniques that help identify erroneous constraints.

  1. Bounded Consistency Checks. This technique, usually abbreviated BCC, has been available for a long time. It checks that constraints are consistent, meaning that they are not mutually contradictory. If they are inconsistent, they exclude all possible scenarios, including the realistic ones, which can be dangerous. Though useful, this check is also very coarse. It will only discover if all possible scenarios are excluded, not if some realistic scenarios are excluded. In other words, if the check shows that you have an inconsistency, you need to fix it, but if not, you have no guarantee that your constraints are correct. Realistic scenarios could still be excluded in the analysis.
  2. Reachability analysis. You state Reachability Obligations (ROs) that express states that the system shall be able to enter. For example, you can state that every route can be used. The model checker will then try, for each route, to find a scenario that leads to the route being used. If that succeeds, it means that these scenarios can occur, but also that they are not excluded by any constraints. In particular, it follows that the constraints are consistent, so this check says more than BCC. Much more, in fact, because it does not only tell you that there is at least one scenario that is permitted by the constraints, it also tells you that there are scenarios that reach specific, realistic, intended states. You can use these reachability obligations as regression tests, that will tell you immediately if you happen to introduce a constraint that excludes scenarios where routes are used. You can also add reachability obligations for equipment that you know can fail, and where you want to watch that no constraint is introduced that will exclude such failure from the model. For example, you can express “the lamp is turned on by the signaling system but does not acknowledge back that it works” or “the switch is being thrown to the left but not detected in the left position”. If these scenarios are not reachable, it is a clear sign that some constraints are unrealistically strict.
  3. Proof coverage. If a proof obligation is surprisingly shown Valid, or a reachability obligation surprisingly turns out to be Unreachable, it can be a sign of the presence of an erroneous constraint or a bad definition. This situation is difficult to debug, because a model checker cannot provide any counterexample to inspect in this case. It can, however, tell you which parts of the model were used when arriving at the conclusion. By inspecting them you might be able to understand where the conclusion came from.
  4. Constraints softening. Another technique available to analyze surprisingly Valid proof obligations or Unreachable reachability obligations is to soften constraints. By pointing out constraints that you want to soften, you instruct your model checker to interpret them as soft constraints. Soft constraints are assumptions that are not forced but are rather used as preferences when selecting models. They do not affect truth values of proof obligations and reachability obligations (as proper constraints do); they only contribute to the selection of which scenario to produce as a counterexample for a proof obligation, or as an example for a reachability obligation. We think of them as noise reduction, because they can make models considerably less chaotic, and thus eliminate “noise” that distracts from the important aspects of the model. The model checker will produce a scenario where the soft constraints are fulfilled as much as possible. You can then ask for information about which soft constraints were violated in the model produced. If these violated soft constraints are softened proper constraints, then it’s a good idea to review them thoroughly, because they might be stronger than you intended.

Ways to validate requirements at early stages

Reachability analysis can also be used to validate requirements. In railway signaling projects, an ontology (for example an object model) and safety requirements are usually produced during the tender phase, while the design is made much later. Mistakes in the safety requirements, such as them being mutually contradictory, are important to find early, in order not to base development on faulty requirements that will have to be changed later, causing large extra costs. Tool support for finding such mistakes is crucial.

One option is to model all variables of the ontology (object model) as free variables, and to implement the safety requirements as proof obligations. They cannot be proved until a design is available, and any attempt at proving them will fail with a counterexample, because all design variables are free. What you can do, however, is to assume those proof obligations, that is, using them as constraints, and try to prove some reachability obligations, for example that all signals can clear (not at the same time, but individually). If the requirements are not mutually contradictory, and do not forbid signal clearing directly or indirectly, you will, for each signal, receive a scenario where the signal clears in the end, and where all safety properties are fulfilled in every step. This shows that the requirements can indeed be fulfilled. In fact, by inspecting the scenarios that lead to signals clearing, you should be able to find all steps that you expect to be necessary for the signal to clear, such as switches being thrown to correct positions, objects being locked, and so on. If those steps are not there to find, it might be a sign that some requirements about the missing steps are lacking.

How to do reachability analysis

There are two possible ways to do reachability analysis.

  1. Any model checker can be used, if you are prepared to use a workaround. Say that you want to show that a system can reach a state where a lamp becomes lit. You formalize the opposite proof obligation “the lamp cannot be lit” and ask the model checker for a counterexample. If it finds a counterexample, you have proof that it is possible to find a state where the lamp is lit. This approach works but has three drawbacks.
    • It requires a workaround. This is less intuitive and more error prone.
    • It does not handle the potential issue of undefined values. For example, if you try to show that “1/x = 2” can occur for some integer x, you need to search for a counterexample to “1/x ≠ 2”. Actually, for x = 0 this statement is not even well defined, so x = 0 works as a counterexample. But this example does not work well as a reachability proof, because “1/0 = 2” is not true.
    • The interpretation of the results is error prone. You need to remember that some proof obligations are supposed to be falsifiable, and that it is an error if they are valid, because they are formulated as opposite to what you really want to see. This can be confusing and lead to erroneous conclusions.
  2. With a dedicated add-on for reachability analysis. The advantages of this approach are:
    • Proof obligations and reachability obligations can be expressed simultaneously and proved simultaneously in one run.
    • Having reachability obligations explicitly mentioned in input files makes them useful as a way to discover if the system becomes over-constrained by mistake (regression testing).
    • Reachability obligations that can be undefined (involving partial functions such as division or arrays that can be out of bounds) are handled differently than with the workaround: reachability means that there is a scenario where these are both well-defined and true in the last state.

Prover PSL 6 comes with an add-on for reachability analysis. It also comes with proof coverage inspection and constraints softening, which were other features mentioned above.

The add-on for reachability analysis is provided for free to our Prover PSL users until March 2025. Try it today and share your feedback!

Inlägget Reachability analysis as a way to validate requirements and constraints dök först upp på Prover - Engineering a Safer World.

]]>
Formal verification applications to ensure safety of CBTC systems https://www.prover.com/safety/formal-verification-applications-to-ensure-safety-of-cbtc-systems/ Wed, 31 Jan 2024 16:25:30 +0000 https://www.prover.com/?p=5850 A significant number of modern metro systems use CBTC for safer and efficient train operations. While the role of CBTC is straightforward, the systems themselves are quite complex.

Inlägget Formal verification applications to ensure safety of CBTC systems dök först upp på Prover - Engineering a Safer World.

]]>

A significant number of modern metro systems around the world use Communication-Based Train Control (CBTC) for safer and more efficient train operations. While the role of CBTC is straightforward, the systems themselves are quite complex.

Due to this complexity, coupled with high safety requirements imposed on CBTC systems, both suppliers and operators have taken to implementing formal verification methods to ensure that the deployed systems meet the highest safety standards. Here, we will walk through six of these methods. But first, let’s review the basics.

What is communication-based train control?

CBTC is a modern signaling system that keeps track of a train’s position by utilizing continuous communication between wayside and carborne equipment.

From a functional standpoint, CBTC is mainly composed of two subsystems: Automatic Train Control (ATC) and Automatic Train Supervision (ATS). The ATC guarantees the safe operation of trains, while the ATS provides an overview of the system for supervision and centralized operation. The ATC is composed of two components: Automatic Train Protection (ATP) and Automatic Train Operation (ATO). ATO is in charge of operating trains while ATP is in charge of the safety of this operation.

Generic and Specific Application Levels

The complexity of CBTC systems has led suppliers to offer generic CBTC solutions which can be deployed in different locations, only by changing the configuration data and parameters. Such solutions make it possible to optimize redundant activities so they can be done once and for all at a generic level, and reduce the required workload on the location-specific level. This is usually known as Generic Application (GA) and Specific Application (SA) level, with configuration data used to instantiate one from the other.

6 verification methods used to ensure CBTC systems meet high safety standards

To improve the correctness and safety of CBTC systems, a number of formal verification methods have been applied globally with success.

The major obstacle that has been observed in these applications is the state-space explosion due to the complexity of the studied CBTC systems. In recent years, however, this issue has been tackled in different ways and, in some applications, improved results have already been observed.

1. System Configuration Data validation

The instantiation of an SA from a GA is performed by essentially integrating the so-called configuration data relative to the specific location. In order to guarantee the safety of the resulting SA, one must ensure that the configuration data are correct. Formal methods utilizing properties formalization and exhaustive data checking have been of great help in this matter.

2. Software Configuration Data generation/validation

While System Configuration Data covers system-wide aspects, subsystem software usually requires a different presentation of this data. This software configuration data is usually derived from the system-level data with a safety-preserving process. For this matter, formal methods have also been successfully applied either to generate correct software data or to check the correctness of data previously generated with another process.

3. Verification of vital requirements on software at equipment or function level
(GA or SA)

Formal verification has also been applied to verify the correct implementation of vital requirements at the sub-system level using (the whole or parts of) the subsystem’s software as a target. Compared to classical testing approaches, formal verification helps to capture the requirements and gives wider coverage of the verified behavior. In many cases, safety-related bugs have been identified only using formal verification (in projects where both techniques were used). Requirement formalization has helped to clarify a significant number of ambiguous specifications as well.

4. Verification of safety requirements at system or equipment level
(against a formalization of the System/equipment)

At the system level, formal verification of safety properties have also been performed against a formalization of the studied system/subsystem (so-called digital twin). Functional requirements are used as a basis for the development of the formal model, with some abstractions of small details. Safety properties, usually derived from system safety studies, are then checked on the formal model. This helps identify high-level discrepancies in the system specifications that might not be seen at lower-level verification.

5. Formal development process

Formal methods have also been applied successfully for the entire development process of CBTC systems. A system-level formal specification is first developed and proven to be safe. This high-level specification is then refined to include more implementation details, with the proof that the refinement preserves the safety properties. Refinement is repeated until the resulting model is detailed enough and can be implemented by a software. Since all refinement steps are formally verified, the resulting model is correct-by-construction.

6. Equivalence proofs for generated code

In some applications, when the software is automatically generated from a formal model, formal verification has been used to check the correctness of the generated code. An equivalence proof is performed between both the formal model and a formalization of the generated software.

Would you like to know more? Let our experts show you how a formal approach can help your CBTC-project. Contact us for a meeting 

How safe and efficient are your rail control systems? Let’s find out!

Inlägget Formal verification applications to ensure safety of CBTC systems dök först upp på Prover - Engineering a Safer World.

]]>
3 scenarios where formal verification caught errors missed by traditional rail control system tests https://www.prover.com/safety/3-scenarios-where-formal-verification-caught-errors-missed-by-traditional-system-tests/ Wed, 20 Dec 2023 08:00:29 +0000 https://www.prover.com/?p=6060 Read more about 3 scenarios where formal verification caught errors missed by traditional rail control system tests.

Inlägget 3 scenarios where formal verification caught errors missed by traditional rail control system tests dök först upp på Prover - Engineering a Safer World.

]]>

As most signal and verification engineers know, when developing and verifying software for rail control systems, testing can be very tricky. Especially when it comes to finding corner cases and scenarios outside of normal operations.

When conducting a test, you typically define a test case as well as the circumstances in which you are testing your software. The problem is, when you do it that way, you’re thinking as a human. This means that, sometimes, you forget things or fail to consider the possibility that certain scenarios could even happen.

Of course, if you’ve done your work correctly, the risk of errors slipping through and actually causing an accident is very small. Field testing and simulation methods offer a lot of benefits. However, when it comes to identifying those hard-to-pinpoint cases, there is nothing like formal verification. When you perform formal verification, every possible case is considered—helping you keep even the few, otherwise overlooked, errors from slipping through and prevent accidents from happening.

What is formal verification?

Formal verification is a technique for checking that systems fulfill selected properties with 100% certainty. For example, for a rail control system, it can be checked that signals cannot display green aspects unless certain switches are in correspondence.

While testing of big systems can never reach full coverage, due to the number of combinations that have to be tested, formal verification provides full certainty because it uses a mathematical argument without gaps.

Run all possible scenarios with model-checker analysis

One of the great advantages of formal verification is the completeness of the model-checker analysis. Contrary to testing, the model-checker checks all possible sequences of inputs on every part of the track. Modelling communications between subsystems and investigating delays in such communications can help spot scenarios that would otherwise be difficult to stumble upon using traditional testing methods.

Working closely with our customers over the years, we have seen a number of issues revealed during formal verification which were not found by testing. In these cases, the conditions where the bugs appeared were difficult to reproduce in test environments, and it was not natural to even look for these kinds of bugs.

Here are three examples of scenarios discovered using formal verification that traditional test cases failed to find.

Scenario 1: Communication delays between two sub-systems

One scenario that formal verification often catches, which is nearly impossible to find using traditional testing methods, is one that appears due to communication delays between two sub-systems.

The challenge in finding such scenarios comes from the fact that both the sequence and communication delay may need to be very specific to lead to such cases. However, by using formal methods to model the communication between the different sub-systems, it is possible to spot these kinds of scenarios.

For example, the communication from A to B must be fast, the communication from B to A slow, and a specific command is received while a message is being sent from B to A. With formal proof, once the communication is modeled (e.g., max communication delay, cycle of forgiveness if no message received), the model-checker will cover every possible state to find a non-safe scenario. Once such a counter-example is found and captured, it is possible to reproduce the scenario using a simulator.

Scenario 2: Delays caused by sequences involving several trains

Scenarios involving a specific sequence of several trains are also often overlooked by traditional testing methods. Sometimes you establish configurations according to the first train, but fail to take into account the trains that come after it. The consequence is big delays.

For instance, a first train is moving to a closed level crossing and a second train is causing a particular sequence that allows the said level crossing to be opened. Such a scenario may be possible due to the level crossing’s particular configuration.

Scenario 3: Complex sequences and contexts

Another type of overlooked scenario often discovered via formal verification is one with a deeper sequence of events, which requires a very particular context or sequence in order to take place. At first normal behavior happens that sets a certain value in a given memory. Then that memorized state reveals unsafe scenarios in a nominal case, which is induced by the particular context.

For instance, a certain route 1-3 can be formed without any issues, but if it is formed after the route 1-2 has been formed and destroyed, the route can be formed while a switch within its perimeter is being commanded.

In addition to that, there are also certain counter-examples that can be caused by quick state changes. These too can be tricky to uncover during testing. A switch position change for a single cycle can cause a signal to open while a conflicting one may take a bit more time to close, causing a risk of collision.

Questions?

We invite you to read about our line of formal verification products. And if you would like to discuss how these can be applied to your specific rail control project, please feel free to book a meeting with us.

How safe and efficient are your rail control systems? Let’s find out!

Inlägget 3 scenarios where formal verification caught errors missed by traditional rail control system tests dök först upp på Prover - Engineering a Safer World.

]]>
Building a safety case for rail control software with formal verification https://www.prover.com/webinar/building-a-safety-case-for-rail-control-software-with-formal-verification/ Thu, 23 Feb 2023 11:47:30 +0000 https://stage.prover.com/?p=13574 Learn how formal verification, implemented with a pre-qualified T2 SIL4 tool, Prover Certifier, can be used in a CENELEC EN50128 compliant process.

Inlägget Building a safety case for rail control software with formal verification dök först upp på Prover - Engineering a Safer World.

]]>
RECORDED WEBINAR

Safety

An easier path to CENELEC EN50128 SIL4 compliance

In almost every rail control project the effort for achieving compliance with safety standards such as CENLEC EN50128 is a significant part of the project. Traditionally, this involves many manual steps such as reviewing verification documents, test plans, and test reports.

Much of this work can be replaced with automated formal verification, reducing effort, increasing quality, and reducing risk for project delays.

Formal verification is a technique based on mathematical proofs that gives 100 % coverage and can be fully automated. In this recorded webinar, we focus on how formal verification, implemented with a pre-qualified T2 SIL4 tool, Prover Certifier, can be used in a CENELEC EN50128 compliant process.

We also present a case study on how CASCO, a leading rail control supplier, benefits from formal verification in its safety process.

Agenda:
  • What is formal verification and why do we need it
  • Formal verification in a CENELEC EN50128 SIL4 process
  • Introduction to Prover Certifier, a T2 SIL-4 qualified formal verification tool
  • A case study: Formal safety verification at CASCO

  • Recommendations and considerations for the implementation process
Why the railway industry needs to modernize its methods of safety assurance

Yes please, send me the recording!

Hosts
Benjamin Blanc Prover

Benjamin Blanc
Solutions Manager, Prover

Olav Bandmann Prover

Olav Bandmann
Chief Technology Officer, Prover

Daniel Fredholm Prover

Daniel Fredholm
Senior Consultant, Prover

Inlägget Building a safety case for rail control software with formal verification dök först upp på Prover - Engineering a Safer World.

]]>