No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
The First Twenty-Five Years of Industrial Use of the B-Method
Abstract
The B-Method has an interesting history, where language and tools have evolved over the years. This not only led to considerable research and progress in the area of formal methods, but also to numerous industrial applications, in particular in the railway domain. We present a survey of the industrial usage of the B-Method since the first toolset in 1993 and the inauguration of the driverless metro line 14 in Paris in 1999. We discuss the various areas of applications, from software development to data validation and on to systems modelling. The evolution of the tooling landscape is also analysed, and we present an assessment of the current situation, lessons learned and possible new directions.
... Model-based development relies on rigorous techniques (e.g., the B family [32]) to derive a concrete (low-level) implementation from an abstract (high-level) specification by successive refinement steps based on model transformation. During refinement, a specification is complemented with details that are unnecessary in the higher-level specifications. ...
... The last decade has seen several introductions and accounts of trends and experiences concerning the role of formal methods in the development of safety-critical applications [29,75,83], in particular in the railway domain and from an academic viewpoint by Fantechi et al. [59][60][61]63] and in the general transportation domain and from an industrial viewpoint, focusing mostly on SCADE and/or the B method, by Boulanger [22][23][24]. Further studies are lessons learned and obstacles found with respect to decades of integrating formal methods in research, education and industrial practice, in particular in the transportation domain [18,32,50,95,103]. We also mention a number of recent surveys in the railway domain at large [58,86,97,99,105,122,129], neither of which involve formal methods. ...
Formal methods are mathematically based techniques for the rigorous development of software-intensive systems. The railway signaling domain is a field in which formal methods have traditionally been applied, with several success stories. This article reports on a mapping study that surveys the landscape of research on applications of formal methods to the development of railway systems. Following the guidelines of systematic reviews, we identify 328 relevant primary studies, and extract information about their demographics, the characteristics of formal methods used and railway-specific aspects. Our main results are as follows: (i) we identify a total of 328 primary studies relevant to our scope published between 1989 and 2020, of which 44% published during the last 5 years and 24% involving industry; (ii) the majority of studies are evaluated through Examples (41%) and Experience Reports (38%), while full-fledged Case Studies are limited (1.5%); (iii) Model checking is the most commonly adopted technique (47%), followed by simulation (27%) and theorem proving (19.5%); (iv) the dominant languages are UML (18%) and B (15%), while frequently used tools are ProB (9%), NuSMV (8%) and UPPAAL (7%); however, a diverse landscape of languages and tools is employed; (v) the majority of systems are interlocking products (40%), followed by models of high-level control logic (27%); (vi) most of the studies focus on the Architecture (66%) and Detailed Design (45%) development phases. Based on these findings, we highlight current research gaps and expected actions. In particular, the need to focus on more empirically sound research methods, such as Case Studies and Controlled Experiments, and to lower the degree of abstraction, by applying formal methods and tools to development phases that are closer to software development. Our study contributes with an empirically based perspective on the future of research and practice in formal methods applications for railways. It can be used by formal methods researchers to better focus their scientific inquiries, and by railway practitioners for an improved understanding of the interplay between formal methods and their specific application domain.
... Despite several success stories on railway applications of formal methods (cf., e.g., [22,24,27,23,5,15]) these mathematically-based methods and tools for system development still find significant obstacles to their adoption in railway software industry. ...
... Formal Verification by Model Checking One of the project's main goals is to transform these standard UML/SysML designs, whatever supporting tool is chosen, into verifiable formal models. Theorem proving and model checking can be considered the two most used approaches to system verification, also in railway related contexts [3,5,28,15]. However, theorem proving, for instance as supported by Atelier B, fits better a specification refinement process that guides the correctby-construction generation of code starting from an initial formal design. ...
The Shift2Rail Innovation Programme is focussing on in- novative technologies to enhance the overall railway market segments. Formal methods and standard interfaces have been identified as two key concepts to reduce time-to-market and costs, whilst ensuring safety, in- teroperability and standardization. However, the decision to start us- ing formal methods is still deemed too risky. Demonstrating technical and commercial benefits of both formal methods and standard inter- faces is necessary to address obstacles of learning curve and lack of clear cost/benefit analysis that are hindering their adoption, and it is the goal of the 4SECURail project. In this paper we provide the reasoning and the rationale for designing the formal methods demonstrator for the 4SE- CURail project. The design concerns three important issues that have been analysed: (i) the usefulness of formal methods from the point of view of the infrastructure managers, (ii) relating this demonstrator with other similar initiatives, (iii) the adoption of semi-formal SysML notation within our formal methods demonstrator process.
... Formal methods have been experimented on software development, bringing a new perspective and showing that considerable improvements with respect to correctness proofs and verification can be achieved [46,82]. Despite several obstacles regarding their applicability for complex real-world systems [57], industry has been successfully exploring the benefits of introducing formal methods to their development processes [11,79]. Such methods have been used for specification and verification, and also for testing and code generation [7]. ...
Porting software to new target architectures is a common challenge, particularly when dealing with low-level functionality in drivers or OS kernels that interact directly with hardware. Traditionally, adapting code for different hardware platforms has been a manual and error-prone process. However, with the growing demand for dependability and the increasing hardware diversity in systems like the IoT, new software development approaches are essential. This includes rigorous methods for verifying and automatically porting Real-Time Operating Systems (RTOS) to various devices. Our framework addresses this challenge through formal methods and code generation for embedded RTOS. We demonstrate a hardware-specific part of a kernel model in Event-B, ensuring correctness according to the specification. Since hardware details are only added in late modeling stages, we can reuse most of the model and proofs for multiple targets. In a proof of concept, we refine the generic model for two different architectures, also ensuring safety and liveness properties. We then showcase automatic low-level code generation from the model. Finally, a hardware-independent factorial function model illustrates more potential of our approach.
... The B method is a formal method for software [1] and systems development [2] as well as data validation [9]. Specifications are written in the B language, which is rooted in predicate logic, arithmetic and set theory. ...
The B method is a formal method supported by a variety of tools. Those tools, like any complex piece of software, may suffer from performance issues and vulnerabilities, especially for potentially undiscovered, pathological cases. To find such cases and assess their performance impacts within a single tool, we leverage the performance fuzzing algorithm BanditFuzz for the constraint solving backends of the ProB model checker. BanditFuzz utilises two multi-armed bandits to generate and mutate benchmark inputs for the ProB backends in a targeted manner. We describe how we adapted BanditFuzz for the B method, which differences exist to the original implementation for the SMT-LIB standard, and how we ensure well-definedness of the randomly generated benchmarks. Our experiments successfully uncovered performance issues in specific backends and even external tooling, providing valuable insights into areas which required improvement.
... The Event-B verification method guarantees the detection of many serious bugs. Despite a large number of various applications, there are factors that limit the wide application of the Event-B approach, which is noted in [3]. ...
... Still on the translation from UML-like models to other formal notations, recent works have focused on transforming these models into mCRL2 [59,20]. Many studies also focus on the translation from UML into the B/Event-B notation [57,58], with formal verification performed by means of Atelier B and ProB [22]. ...
The use of formal methods can reduce the time and costs associated with railway signalling systems development and maintenance, and improve correct behaviour and safety. The integration of formal methods into industrial model-based development tools has been the subject of recent research, indicating the potential transfer of academic techniques to enhance industrial tools. This paper explores the integration of an academic formal verification tool, UML Model Checker (UMC), with an industrial model-based development tool, Sparx Enterprise Architect (Sparx EA). The case study being analyzed is a railway standard interface. The paper demonstrates how formal verification techniques from academic tools can be integrated into industrial development practices using industrial tools, and how simulation in Sparx EA can be derived from traces generated by the UMC formal verification activity. From this experience, we derive a set of lessons learned and research challenges.
... In [43], authors presented a conversion of software modules written in different languages to timed automata, function block is applied, also it adopted a format PLC open XML. A semantic characterization of PLC programs based on the extended -calculus [44]. Other techniques are presented:In [45] Hybrid system , diagnostic model Ludia .In [46], a Fully automated generation of test cases. ...
Developing High-confidence Cyber-Physical Produc- tion System (CPPS) is essential to ensure system efficacy and safety. Engineering requirements for CPPS is quite tricky because of system heterogeneity. Moreover, system bugs and malfunctions may occur, requiring a test to ensure the robustness of CPPSs. There are several kinds of CPPS test Methods in research. This work aims to categorize test methods of cyber-physical production systems in research. We follow a Systematic Lit- erature Review (SLR) method to review existing research. We synthesize a dataset of 220 papers published from 2006 until 2021 seeking to survey and give structured research in the area of the CPPS test. We categorized CPPS test methods by presenting traditional methods of CPPS tests, such as formal techniques and simulation, in addition to the most used methods as testbed and containerization. We also presented used tools for testing CPPSs, and the objectives of testing CPPS.
... ProB is being used by several companies for safety-critical applications (Butler et al. 2020), for example, in the development of railway systems as a tool of class T2 as defined by the European norm EN 50128. 1 However, we strive for ProB to be also used as a tool of class T3. 2 The use of a non-mainstream language like Prolog is one obstacle for T3 certification of ProB, among other aspects. Although ProB features an extensive test suite that will often detect Prolog system bugs (Bendisposto et al. 2014), this risk can be reduced even further by verifying the results using a second, independent Prolog implementation. ...
Even though the core of the Prolog programming language has been standardized by ISO since 1995, it remains difficult to write complex Prolog programs that can run unmodified on multiple Prolog implementations. Indeed, implementations sometimes deviate from the ISO standard and the standard itself fails to cover many features that are essential in practice. Most Prolog applications thus have to rely on nonstandard features, often making them dependent on one particular Prolog implementation and incompatible with others. We examine one such Prolog application: ProB, which has been developed for over 20 years in SICStus Prolog. The article describes how we managed to refactor the codebase of ProB to also support SWI-Prolog, with the goal of verifying ProB’s results using two independent toolchains. This required a multitude of adjustments, ranging from extending the SICStus emulation in SWI-Prolog on to better modularizing the monolithic ProB codebase. We also describe notable compatibility issues and other differences that we encountered in the process, and how we were able to deal with them with few major code changes.
... There is a growing number of railway signalling companies that use verification techniques based on formal proofs for demonstrating and assuring system safety. The automated technologies, including AtelierB [1,2], Ovado/Rodin [3], Prover [4] and Spark Ada [5], formally verify that a system satisfies a collection of identified safety properties. These tools report violations found during verification to the signalling engineers, who use that information to guide the rework process. ...
This industrial experience report discusses the problems we have been facing while using our formal verification technology, called SafeCap, in a substantial number of live signalling projects in UK mainline rail, and the solutions we are now developing to counter these problems. Symbolic execution and safety invariant verification are well-understood subjects and yet their application to real life high assurance systems requires going a few steps beyond the conventional practice. In engineering practice it is not sufficient to simply know that a safety property fails: one needs to know why and hence where and what exactly fails. It is also crucial to positively demonstrate that no safety failure is omitted from consideration. In this industrial report we show how to derive a list of all potential errors by transforming a safety invariant predicate using information from the constructed state transition system. The identified possible errors are verified by an automated symbolic prover, while a report generator presents findings in an engineer-friendly format to guide subsequent rework steps. The scalability and the efficiency of the proposed mechanism (which is now fully integrated in the SafeCap technology) have been demonstrated in several live signalling projects.
... There has been a long history of applying formal methods and tools in the railway domain [9], with the B method being the most popular industry-strength method [10]. One of the most successful areas of railway has been safety verification of interlocking in the Communication-Based Train Control (CBTC) railway lines, including metro, subway, light and shuttle trains. ...
SafeCap is a modern toolkit for modelling, simulation and formal verification of railway networks. This paper discusses the use of SafeCap for formal analysis and automated scalable safety verification of solid state interlocking (SSI) programs a technology at the heart of many railway signalling solutions around the world. The main driving force behind SafeCap development was to make it easy for signalling engineers to use the technology and thus to ensure its smooth industrial deployment. The unique qualities and the novelty of SafeCap are in making the use of formal notations and proofs fully transparent for the engineers. In this paper we explain the formal foundations of the proposed method, its tool support, and their successful application by railway companies in developing industrial signalling projects.
... • An Event-B method as the instrument for system level modeling and analysis, e.g., to formally check the design of communication-based train control system [5]; its practice of industrial use is over two decades [6]. ...
... Later the command-line interface probcli was developed, which is still being heavily used for testing, data validation, and batch verification. For example, probcli is used for data validation of railway systems, see [7,27] or Sect. 4 of [3]. ...
ProB2-UI is a modern JavaFX-based user interface for the animator, constraint solver, and model checker ProB. We present the main features of the tool, especially compared to ProB’s previous user interfaces and other available tools for B, Event-B, and other formalisms. We also present some of ProB2-UI’s history as well as its uses in the industry since its release in 2019.
Formal methods encompass a wide choice of techniques and tools for the specification, development, analysis, and verification of software and hardware systems. Formal methods are widely applied in industry, in activities ranging from the elicitation of requirements and the early design phases all the way to the deployment, configuration, and runtime monitoring of actual systems. Formal methods allow one to precisely specify the environment in which a system operates, the requirements and properties that the system should satisfy, the models of the system used during the various design steps, and the code embedded in the final implementation, as well as to express conformance relations between these specifications. We present a broad scope of successful applications of formal methods in industry, not limited to the well-known success stories from the safety-critical domain, like railways and other transportation systems, but also covering other areas such as lithography manufacturing and cloud security in e-commerce, to name but a few. We also report testimonies from a number of representatives from industry who, either directly or indirectly, use or have used formal methods in their industrial project endeavours. These persons are spread geographically, including Europe, Asia, North and South America, and the involved projects witness the large coverage of applications of formal methods, not limited to the safety-critical domain. We thus make a case for the importance of formal methods, and in particular of the capacity to abstract and mathematical reasoning that are taught as part of any formal methods course. These are fundamental Computer Science skills that graduates should profit from when working as computer scientists in industry, as confirmed by industry representatives.
Static type checking helps catch errors in manipulating variables values early on, and most specification languages, like Event-B, are strongly typed. However, the type system of Event-B language is relatively simple and provides only a way to specify discrete behaviour using Integer type. There is no possibility to model continuous behaviour, which would have helped analyse hybrid systems. More precisely, the Event-B language doesn’t consider in its type-checking system the possibility of defining such behaviours and checking the correctness of the values of the continuous variables within the Event-B models. In this article, we propose to extend the type-checking system of Event-B to include Float variables by specifying a floating point numbers theory using the theory plugin.
Automatic railway signalling generation from a railway layout helps reduce human errors while considerably speeding up the process of signalling placement. In that regard, we designed an automated process that we named Railway Network Analyzer (RNA). This article will present that process, stating what an RNA implementation must observe to generate signalling from a railway layout stored in railML, a European open-standard used for railway infrastructure data exchange. The RNA analyses the layout’s static characteristics and gives essential information for further dynamic analysis. We will also introduce our RNA implementation in Python and comment on the obtained results of automatically processing canonical test layouts. Finally, railway practitioners conducted an analysis of an actual railway station using RNA, which confirmed the usability and robustness of our approach.
This work aims to formally ensure the safety of modern moving block systems. For this a proof model was developed in Event-B which captures several safety critical aspects. The new model identifies several key concepts, that are at the heart of the mathematical safety proof and which should later be at the heart of the safety case for a moving block system with trackside train detection. Some of the key concepts were inspired by earlier CBTC models and adapted for ETCS moving block, and a few novel key concepts were developed to deal safely with delays of train position reports and trackside train detection.
The invariants of the proof model have proven mathematically with the Rodin toolset, thereby establishing safety properties of the modelled system. The proof model can also be animated and visualised using the ProB validation tool. By necessity, the proof model abstracts away from irrelevant details and still has some restrictions in scope (such as linear topology). Nonetheless, even with current restrictions, the key concepts already proved valuable when reasoning about safety of moving block systems. In the article we also present our modelling and tooling methodology, outlining the importance of complementing proof with animation. We also explain the importance of inductive properties and argue that a train-centric approach is more promising for proof of a moving block system than a track-centric approach.
From simulating galaxy formation to viral transmission in a pandemic, scientific models play a pivotal role in developing scientific theories and supporting government policy decisions that affect us all. Given these critical applications, a poor modelling assumption or bug could have far-reaching consequences. However, scientific models possess several properties that make them notoriously difficult to test, including a complex input space, long execution times, and non-determinism, rendering existing testing techniques impractical. In fields such as epidemiology, where researchers seek answers to challenging causal questions, a statistical methodology known as Causal Inference has addressed similar problems, enabling the inference of causal conclusions from noisy, biased, and sparse data instead of costly experiments. This paper introduces the Causal Testing Framework: a framework that uses Causal Inference techniques to establish causal effects from existing data, enabling users to conduct software testing activities concerning the effect of a change, such as Metamorphic Testing, a posteriori . We present three case studies covering real-world scientific models, demonstrating how the Causal Testing Framework can infer metamorphic test outcomes from reused, confounded test data to provide an efficient solution for testing scientific modelling software.
ProB is an animator, model checker and constraint solver for high-level formal models. It has been developed for over 20 years and has built on the power of Prolog to help users develop safe systems, by bringing their formal mathematical models to life and uncovering unexpected behaviour. Almost all of ProB’s features require constraint solving for an undecidable mathematical language with existential and universal quantification, higher-order sets, functions and relations and unbounded variables. ProB has been used by many academics in teaching and research. It has been used at the heart of a considerable number of academic and industrial tools. In particular, ProB has been used by several companies to validate the safe configuration of train systems around the world. In this setting ProB has been certified according to the European norm EN 50128. The long-term vision is to be able to routinely use formal mathematical models as runtime artefacts and make a larger subset of mathematics itself executable.
The correct-by-construction state-based Event-B formal method lacks the ability to express liveness properties using temporal logic. To address this challenge, two approaches can be envisioned. First, embed Event-B models in another formal method supporting liveness properties verification. This method is cumbersome and error-prone, and the verification result is not guaranteed on the source model. Second, extend Event-B to support the expression of and reasoning on liveness properties, and more generally temporal properties. Following the second approach, in [20], J.-R. Abrial and T. S. Hoang proposed an axiomatisation of linear temporal logic (LTL) for Event-B with a set of proof obligations (POs) allowing to verify these properties. These POs are mathematically formalised, but are neither implemented nor generated automatically. In this paper, using the reflexive EB4EB framework [37, 38] allowing for manipulation of the core concepts of Event-B, we propose to formalise and operationalise the automatic generation of proof obligations associated to liveness properties expressed in LTL. Furthermore, relying on trace-based semantics, we demonstrate the soundness of this formalisation, and provide a set of intermediate and generic theorems to increase the rate of proof automation for these properties. Finally, a case study is proposed to demonstrate the use of the defined operators for expressing and proving liveness properties.KeywordsProof and state-based methodsEvent-B and TheoriesMeta-theoryReflexive EB4EB frameworkTemporal logicLiveness propertiesTraces and soundness
Partial order reduction (POR) has considerable potential to reduce the state space during model checking by exploiting independence between transitions. This potential remains, however, largely unfulfilled for high-level formalisms such as B or TLA. In this article, we report on our experiments regarding POR: We empirically assess that our current implementation of POR in ProB does not have any impact for a vast majority of B machines. We then analyse why POR fails to achieve reductions and identify minimal examples without reduction that make use of high-level constructs in B, and provide several new ideas to make POR pay off for more complex formal models. A proof-of-concept implementation then yields two orders of magnitude reduction in the state space for a particularly challenging case study, a railway interlocking model that escaped our POR techniques thus far.
The design of complex and/or critical systems requires handling the environment constraints in which these systems evolve. Formal methods allow system developers to design models of such systems. They provide constructs for modelling components and views of these systems. However, these formal methods do not include built-in constructs for modelling the environment, and more broadly, domain knowledge associated with system models. Although ontologies have demonstrated their efficiency in modelling domain-specific features, they are not available as built-in constructs in formal methods.
This paper shows how formal ontologies can be used to model domain-specific knowledge, as well as how system models may refer to these ontologies through annotation. We rely on the Event-B refinement and proof state-based method, and the associated theories, to define a framework in which domain-specific knowledge ontologies are formalised as Event-B theories defining data types used to type Event-B system design models. Finally, this framework is deployed for the specific case of interactive critical systems. To illustrate the proposed approach, a case study of the Traffic Collision Avoidance System (TCAS) is developed.
Reliability engineering of railway infrastructure aims to understand failure processes and to improve the efficiency and effectiveness of investments and maintenance planning such that a high quality of service is achieved. While formal methods are widely used to verify the design specifications of safety-critical components in train control, quantitative methods to analyze the service reliability associated with specific system designs are only starting to emerge. In this paper, we strive to advance the use of formal fault-tree modeling for providing a quantitative assessment of the railway infrastructure’s service reliability in the design phase. While, individually, most subsystems required for route-setting and train control are well understood, the system’s reliability to globally provide its designated service capacity is less studied. To this end, we present a framework based on dynamic fault trees that allows to analyze train routability based on train paths projected in the interlocking system. We particularly focus on the dependency of train paths on track-based assets such as switches and crossings, which are particularly prone to failures due to their being subject to weather and heavy wear. By using probabilistic model checking to analyze and verify the reliability of feasible route sets for scheduled train lines, performance metrics for reliability analysis of the system as a whole as well as criticality analysis of individual (sub-)components become available. The approach, which has been previously discussed in our paper at FMICS 2019, is further refined, and additional algorithmic approaches, analysis settings and application scenarios in infrastructure and maintenance planning are discussed.
Programmable Logic Controllers (PLC) are widely used in Industrial Control Systems (ICS) with strict safety assurance requirements. Unfortunately, traditional techniques for debugging prefer to use post-development approaches, such as simulation and black-box testing, rather than enhancing safety before programing. In this paper, we propose a refinement-based approach to model and verify PLC systems, aiming to assure safety properties by construction. It uses the Event-B formalism and focuses on the levels of requirement analysis, specification refinement, and system development. This approach takes a three-layer framework stepwise to specify the behaviors and properties of PLC programs, thereby reducing the modeling complexity. The basic firmware layer models the general mechanisms of PLC firmware, such as periodical instruction execution and centralized I/O scanning, which are application-independent models with fundamental safety properties at an abstract level. The middle layer establishes configuration models. These models correspond to the PLC settings and interactive environments of a specific system, such as I/O addresses and peripheral devices. The business layer models business logic with more specific system-level safety requirements. With our approach, the safety properties of PLC systems can be verified throughout the modeling and refinement process. In addition, rules are proposed to convert the most concrete Event-B model into PLC code satisfying the IEC 61131-3 standard. We demonstrate this approach with a real-world running example of a pump control system for gas transmission.
Formal system modelling languages lack explicit constructs to model domain knowledge, hindering clear separation of this knowledge from system design models. Indeed, in many cases, this knowledge is hardcoded in the system formal specification or is simply overlooked. Providing explicit domain knowledge constructs and properties would yield a significant improvement in the robustness and confidence of the system design models. Therefore, it speeds up formal verification of safety properties and advances system certification since certification standards and requirements rely on domain knowledge models. The purpose of this paper is to show how formal system design models can benefit from explicit handling of domain knowledge, represented as ontologies. To this end, state-based Event-B modelling language and theories are used to model system models and domain knowledge ontologies, respectively. Our proposition is exemplified by the TCAS (Traffic Collision Avoidance System) system, a critical airborne avionic component. Finally, we provide an assessment highlighting the overall approach.
The B landscape can be confusing to formal methods outsiders, especially due to the fact that it is partitioned into classical B for software and Event-B for systems modelling. In this article we shed light on commonalities and differences between these formalisms, based on our experience in building tools that support both of them. In particular, we examine not so well-known pitfalls. For example, despite sharing a common mathematical foundation in predicate logic, set theory and arithmetic, there are formulas that are true in Event-B and false in classical B, and vice-versa.
Hybrid systems are complex systems where a software controller interacts with a physical environment, usually named a plant, through sensors and actuators. The specification and design of such systems usually rely on the description of both continuous and discrete behaviours. From complex embedded systems to autonomous vehicles, these systems became quite common, including in safety critical domains. However, their formal verification and validation as a whole is still a challenge.
To address this challenge, this article contributes to the definition of a reusable and tool supported formal framework handling the design and verification of hybrid system models that integrate both discrete (the controller part) and continuous (the plant part) behaviours. This framework includes the development of a process for defining a class of basic theories and developing domain theories and then the use of these theories to develop a generic model and system-specific models. To realise this framework, we present a formal proof tool chain, based on the Event-B correct-by-construction method and its integrated development environment Rodin, to develop a set of theories, a generic model, proof processes, and the required properties for designing hybrid systems in Event-B.
Our approach relies on hybrid automata as basic models for such systems. Discrete and continuous variables model system states and behaviours are given using discrete state changes and continuous evolution following a differential equation. The proposed approach is based on refinement and proof using the Event-B method and the Rodin toolset. Two case studies borrowed from the literature are used to illustrate our approach. An assessment of the proposed approach is provided for evaluating its extensibility, effectiveness, scalability, and usability.
European digitalisation initiatives in the Command Control and Signaling (CCS) domain
such as EULYNX aim at a reference CCS architecture in which the system elements are equipped with standardised interfaces. In this poster, we present a case study of the integration of formal methods into the EULYNX Model-Based system engineering(MBSE) approach using UML-B and Event-B.
We demonstrate refinement-based formal development of the hybrid, 'fixed virtual block' approach to train movement control for the emerging European Rail Traffic Management System (ERTMS) level 3.
Our approach uses iUML-B diagrams as a front end to the Event-B modelling language. We use abstraction to verify the principle of movement authority before gradually developing the details of the Virtual Block Detector (VBD) component in subsequent refinements, thus verifying that it preserves the safety properties. We animate the refined models to demonstrate their validity using the scenarios from the Hybrid ERTMS Level 3 (HLIII) specification. We reflect on our team-based approach to finding useful modelling abstractions and demonstrate a systematic modelling method based on the state and class diagrams of iUML-B. The component and control flow architectures of the application, its environment and interacting systems emerge through the layered refinement process. The runtime semantics of the specification's state-machine behaviour are modelled in the final refinements. We discuss how the model could be used to generate an implementation using code generation tools and techniques.
After a number of success stories in safety‐critical domains, we are starting to witness applications of formal methods in contemporary systems and software engineering. However, one thing that is still missing is the evaluation criteria that help software practitioners choose the right formal method for the problem at hand. In this paper, we present the criteria for evaluating and comparing different formal methods. The criteria were chosen through a literature review, discussions with experts from academia and practitioners from industry, and decade‐long personal experience with the application of formal methods in industrial and academic projects. The criteria were then evaluated on several model‐oriented state‐based formal methods. Our research shows that besides technical grounds (eg, modeling capabilities and supported development phases), formal methods should also be evaluated from social and industrial perspectives. We also found out that it is not possible to generate a matrix that renders the selection of the right formal method an automatic process. However, we can generate several pointers, which make this selection process a lot less cumbersome.
The railway sector has seen a large number of successful ap- plications of formal methods and tools. However, up-to-date, structured information about the industrial usage and needs related to formal tools in railways is limited. As a first step to address this, we present the results of a questionnaire submitted to 44 stakeholders with experience in the application of formal tools in railways. The questionnaire was oriented to gather information about industrial projects, and about the functional and quality features that a formal tool should have to be successfully applied in railways. The results show that the most used tools are, as expected, those of the B family, followed by an extensive list of about 40 tools, each one used by few respondents only, indicating a rich, yet scat- tered, landscape. The most desired features concern formal verification, maturity, learnability, quality of documentation, and ease of integration in a CENELEC process. This paper extends the body of knowledge on formal methods applications in the railway industry, and contributes with a ranked list of tool features considered relevant by railway stakeholders.
This paper describes a safety analysis effort on RATP’s communication-based train control (CBTC) system Octys. This CBTC is designed for multi-sourcing and brownfield deployment on an existing interlocking infrastructure. Octys is already in operation on several metro lines in Paris, and RATP plans its deployment on several other lines in the forthcoming years. Besides the size and complexity of the system, the main technical challenges of the analysis are to handle the existing interlocking functionalities without interfering with its design and to clearly identify the responsibilities of each subsystem supplier. The distinguishing aspect of this analysis is the emphasis put on intellectual rigor, this rigor being achieved by using formal proofs to structure arguments, then using the Atelier B tool to mechanically verify such proofs, encoded in the Event-B notation.
This paper describes the process of data validation for railway safety-critical computer-based systems formally implemented by Systerel as supplier of railway industry's companies. More precisely, it describes the validation of data against the requirements it has to meet to ensure systems safety. International standards, especially CENELEC EN 50128, recommend the use of formal methods for designing the most critical safety-related systems. We use the OVADO formal tool to perform data validation. For that, we model data requirements by using the specification language of the B method, namely the B language, before using OVADO that automatically checks that data meet requirements. This tool integrates two independent components that must give the same results when they are applied on the same data, according to the principle of redundancy. An example of data validation for a CBTC system is also given.
The validation of formal models is a challenge for formal methods. We propose JeB, a framework which generates and executes simulations of Event-B models, even highly non-deterministic ones. JeB allows users to safely insert pieces of code to supply deterministic computations where the automatic translation fails. We present how JeB translates Event-B model into JavaScript. We define Fidelity as the formal notion which captures the idea of the correctness of a simulation. We define it through proof-obligations.
Refining a B specification into an implementation can be a complex
and time consuming process. This process can usually be separated in two
distinct parts: the specification part, where the refinement is used to introduce
new properties and specification details, and the implementation, where
refinement is used to convert a detailed B specification into a B0
implementation. This article presents experience on the development and use of
a refiner tool that automates the production of implementable models, in a
number of industrial applications.
Over the years, ProB has moved from a tool that complemented proving, to a
development environment that is now sometimes used instead of proving for
applications, such as exhaustive model checking or data validation. This has
led to much more stringent requirements on the integrity of ProB. In this paper
we present a summary of our validation efforts for ProB, in particular within
the context of the norm EN 50128 and safety critical applications in the
railway domain.
The stepwise formal development of safety critical software is now a well established engineering practice, noticeably in railway systems. However, it has not been applied as successfully to hardware development, where formal methods are mainly used for verification and gate level transformations and optimizations. In this paper, we report our recent experience in the stepwise formal development of a real macro-cell, that opens the way to the design of synchronous digital circuits with zero functional bugs. We propose a development flow suited for obtaining proven correct-by-construction circuits that further possess additional robustness properties desirable for secure chips. The reported work is prospective and is meant to show the feasibility of such a technique for high confidence trustful devices.
In this paper, we present an environment for boundary-value test generation from Z and B specifications. The test generation method is original and was designed on the basis of several industrial case-studies in the domain of critical software (Smart Card and transport areas). It is fully supported by a tool-set: the BZ-Testing-Tools environment. The method and tools are based on a novel, set-oriented, constraint logic programming technology. This paper focusses on how this technology is used within the BZ-TT environment, how Z and B specifications are translated into constraints, and how the constraint solver is used to calculate boundary values and to search for sequences of operations during test generation.
This paper provides an overview of the CODA framework for modelling and
refinement of component-based embedded systems. CODA is an extension of Event-B
and UML-B and is supported by a plug-in for the Rodin toolset. CODA augments
Event-B with constructs for component-based modelling including components,
communications ports, port connectors, timed communications and timing
triggers. Component behaviour is specified through a combination of UML-B state
machines and Event-B. CODA communications and timing are given an Event-B
semantics through translation rules. Refinement is based on Event-B refinement
and allows layered construction of CODA models in a consistent way.
This article presents a verification and validation activity performed in an
industrial context, to validate configuration data of a metro CBTC system by
creating a formal B model of these configuration data and of their properties.
A double tool chain is used to safely check whether a certain given input of
configuration data fulfill its properties. One tool is based on some Rodin and
open source plug-ins and the other tool is based on ProB.
This article presents industrial experience of validating large data sets
against specification written using the B / Event-B mathematical language and
the ProB model checker.
In this article we would like to present some recent applications of the B formal method to the development of safety critical systems, namely platform screen door controllers. These SIL3/SIL4 1 compliant systems have their functional specification based on a formal model. This model has been proved, guaranteeing a correct by construction behaviour of the system in absence of failure of its components. The constructive process used during system specification and design leads to a high quality system which has been qualified 2 by French authorities.
We examine the the industrial application of formal methods using data gathered in a review of 62 projects taking place over
the last 25 years. The review suggests that formal methods are being applied in a wide range of application domains, with
increasingly strong tool support. Significant challenges remain in providing usable tools that can be integrated into established
development processes; in education and training; in taking formal methods from first use to second use, and in gathering
and evidence to support informed selection of methods and tools.
This article presents industrial experience of applying the B formal method in the industry, on diverse application fields
(railways, automotive, smartcard, etc.). If the added value of such an approach has been demonstrated over the year, using
a formal method is not the panacea and requires some precautions when introduced in an industrial development cycle.
This paper proposes an approach to the evaluation of B formal specifications using Constraint Logic Programming with sets.
This approach is used to animate and generate test sequences from B formal specifications. The solver, called CLPS-B, is described
in terms of constraint domains, consistency verification and constraint propagation. It is more powerful than most constraint
systems, because it allows the domain of variable to contain other variables, which increase the level of abstraction. The
constrained state propagates the non-determinism of the B specifications and reduces the number of states in a reachability
graph. We illustrate this approach by comparing the constrained states graph exploration with the concrete one in a simple
example: Process scheduler.
Term rewriting has a significant presence in various areas, not least in automated theorem proving where it is used as a proof technique. Many theorem provers employ specialised proof tactics for rewriting. This results in an interleaving between deduction and computation (i.e., rewriting) steps. If the logic of reasoning supports partial functions, it is necessary that rewriting copes with potentially ill-defined terms. In this paper, we provide a basis for integrating rewriting with a deductive proof system that deals with well-definedness. The definitions and theorems presented in this paper are the theoretical foundations for an extensible rewriting-based prover that has been implemented for the set theoretical formalism Event-B. Comment: In Proceedings PAR 2010, arXiv:1012.4555
Visualization is important to present formal models to domain experts and to spot issues which are hard to formalise or have not been formalised yet. VisB is a visualization plugin for the ProB animator and model checker. VisB enables the user to create simple visualizations for formal models. An important design criterion was to re-use scalable vector graphics (SVG) generated by off-the-shelf graphic editors using a lightweight and easy-to-use annotation mechanism. The visualizations can be used to formal models in B, Event-B, Z, TLA+ and Alloy.
The CLEARSY Safety Platform (CSSP) is aimed at easing the development and the deployment of safety critical applications, up to the safety integrity level 4 (SIL4). It relies on the smart integration of the B formal method, redundant code generation and compilation, and a hardware platform that ensures a safe execution of the software. This paper exposes the programming model of the CSSP used to develop control & command applications based on digital I/Os.
We wish to model railway control systems in a formally precise way so that product lines can be adapted to specific customer requirements. Typically a customer is a railway operator with national conventions leading to different variation points based on a common core principle. A formal model of the core product must be precise and manipulatable so that different feature variations can be specified and verified without disrupting important properties that have already been established in the core product. Cyber-physical systems such as railway interlocking, are characterised by the combination of device behaviours resulting in an overall safe system behaviour. Hence there is a strong need for correct sequential operation with safety “interlocks” making up a process. We utilise diagrammatic modelling tools to make the core product more accessible to systems engineers. The RailGround example used to discuss these techniques is an open source model of a railway control system that has been made available by Thales Austria GmbH for research purpose, which demonstrates some fundamental modelling challenges.
The application of formal methods to the development of reliable interactive systems usually involves a multidisciplinary team with different roles and expertises (e.g. formal engineers, user interface designers and domain experts). While formal engineers provide the necessary expertise in formal methods, other roles may not be well versed in formal methods, such as user interface engineers or domain experts; consequently barriers may arise while working in a multidisciplinary team. For instance, communication problems and challenges in the rigorous use of formal method tools. Tools like BMotion Studio may reduce these barriers by creating visualizations of formal specifications, however, lacks features needed for the analysis of interactive systems. In this paper, we present a novel graphical environment that continues the ideas of BMotion Studio called BMotionWeb to provide support for the rapid creation of formal prototypes. A formal prototype links a mockup of a graphical user interface or device to an animated formal specification with the aim of providing lightweight formal validation of interactive systems. In order to demonstrate the application of BMotionWeb, we provide two case studies: a formal prototype of a simple phonebook software and a cruise control device.
Since several years, ClearSy has driven large projects about using formal proofs at system level in the railway domain. The fundamental goal in these projects is to extract the rigorous reasoning establishing that the considered system ensures its requested properties, and to assert that this reasoning is correct and fully expressed. In this paper, we give feedback about the methodology used in all these projects, about the differences made by whether the concerned system is currently under design or already existing and about the benefits obtained. The formal proofs are performed using Event-B, with the Atelier-B toolkit.
Constraint satisfaction and data validation problems can be expressed very elegantly in state-based formal methods such as B. However, is B suited for developing larger applications and are there existing tools that scale for these projects? In this paper, we present our experiences on two real-world data validation projects from different domains which are based on the B language and use ProB as the central validation tool. The first project is the validation of university timetables, and the second project is the validation of railway topologies. Based on these two projects, we present a general structure of a data validation project in B and outline common challenges along with various solutions. We also discuss possible evolutions of the B language to make it (even) more suitable for such projects.
In this talk, we give an historical account of the development of the Rodin Platform during the last 10 years.
In this chapter, we describe the successful application of ProB in industrial projects realised by Siemens. Siemens is successfully using the B-method to develop software components for the zone and carborne controllers of CBTC systems. However, the development relies on certain assumptions about the actual rail network topology which have to be validated separately in order to ensure safe operation. For this purpose, Siemens has developed custom proof rules for Atelier B. Atelier B was, however, unable to deal with properties related to large constants (relations with thousands of tuples). These properties thus have, until now, had to be validated by hand at great expense (and revalidated whenever the rail network infrastructure changes). In this chapter we show how we have used ProB to overcome this challenge. We describe the deployment and current use of ProB in the SIL4 development chain at Siemens. To achieve this, it has been necessary to extend the ProB kernel for large sets and improve the constraint propagation phase. We also outline some of the effort and features involved in moving from a tool capable of dealing with medium-sized examples to one able to cope with actual industrial specifications. Notably, a new parser and type checker have had to be developed. We also touch upon the issue of validating ProB. © 2013 Springer-Verlag Berlin Heidelberg. All rights are reserved.
The DEPLOY project has provided a rare opportunity to explore and document the potential benefits of and challenges to creating and exploiting usable formal methods. Using the results of an updated review of 98 industrial applications, we identify trends relating to analytic power, robustness, stability and usability of tools, as well as to the quality of evidence on costs and benefits of deployment. A consideration of the DEPLOY applications reinforces these trends, additionally emphasising the importance of selecting formalisms suited to the problem domain and of effectively managing traceable links between requirements and models. © 2013 Springer-Verlag Berlin Heidelberg. All rights are reserved.
Various solvers are linked via reification and Prolog co-routines. The overall challenge of ProB is to solve constraints in full predicate logic with arithmetic, set theory and higher-order relations and functions for safety critical applications. In addition to the tool development, this chapter provides details about various industrial applications of the tool as well as the efforts in qualifying the tool for usage in safety critical contexts. It describes the experiences in applying alternate approaches, such as Systematic Approach to Training (SAT) or Satisfiability Modulo Theories (SMT). The B-method is a formal method for specifying safety critical systems, reasoning about those systems and generating code that is correct by construction. The ProB kernel can be viewed as a constraint solver for the basic datatypes of B and the various operators on it. It supports Booleans, integers, user-defined base types, pairs, records and inductively: sets, relations, functions and sequences.
Tribute Foreword Introduction Part I. Mathematics: 1. Mathematical reasoning 2. Set notation 3. Mathematical objects Part II. Abstract Machines: 4. Introduction to abstract machines 5. Formal definition of abstract machines 6. Theory of abstract machines 7. Constructing large abstract machines 8. Examples of abstract machines Part III. Programming: 9. Sequencing and loop 10. Programming examples Part IV. Refinement: 11. Refinement 12. Constructing large software systems 13. Examples of refinement Appendixes Index.
In this paper we describe the successful application of the ProB validation tool on an industrial case study. The case study centres on the San Juan metro system installed by Siemens. The control software was developed and formally proven with B. However, the development contains certain assumptions about the actual rail network topology which have to be validated separately in order to ensure safe operation. For this task, Siemens has developed custom proof rules for AtelierB. AtelierB, however, was unable to deal with about 80 properties of the deployment (running out of memory). These properties thus had to be validated by hand at great expense (and they need to be revalidated whenever the rail network infrastructure changes).
In this paper we show how we were able to use ProB to validate all of the about 300 properties of the San Juan deployment, detecting exactly the same faults automatically in around 17 minutes that were manually uncovered in about one man-month. This achievement required the extension of the ProB kernel for large sets as well as an improved constraint propagation phase. We also outline some of the effort and features that were required in moving from a tool capable of dealing with medium-sized examples towards a tool able to deal with actual industrial specifications. Notably, a new parser and type checker had to be developed. We also touch upon the issue of validating ProB, so that it can be integrated into the SIL4 development chain at Siemens.
Eight years ago, Siemens Transportation Systems accomplished the first successful application of the B Method on an industrial
project. The vital software of the METEOR automatic train control system, with very strong dependability and safety needs,
was specified and coded in B. Beyond the technological challenge of using such a complex formal method in an industrial context,
it is now clear for us that building software using B is not more expensive than using conventional methods. Better, due to
our experience in using this method, we can assert that using B is cheaper when considering the whole development process
(from specification to validation and sometimes certification). Since METEOR, Siemens Transportation Systems has generalized
the use of B for building all vital software of its systems in particular its Communication Based Train Control Systems (CBTC)
recently enacted on the New York City Canarsie Line. This short paper shares the Canarsie line experience in the B landscape.
In this article, we first briefly present a proof assistant called the Predicate Prover, which essentially offers two functionalities:
(1) an automatic semi-decision procedure for First Order Predicate Calculus, and (2) a systematic translation of statements
written within Set Theory into equivalent ones in First Order Predicate Calculus. We then show that the automatic usage of
this proof assistant is limited by several factors. We finally present (and this is the main part of this article) the principles
that we have used in the construction of a proactive interface aiming at circumventing these limitations. Such principles are based on our practical experience in doing many
interactive proofs (within Set Theory).
The Atomic Weapons Establishment (AWE) has been responsible for the United Kingdom’s nuclear deterrent for more than 50 years.
Its work covers the entire development lifecycle – from the initial research and design, through manufacture, in- service
support and, finally, decommissioning and disposal. In order to maintain its reputation as a world-class company, AWE upholds
strict working procedures and demands high standards.
Clearsy is an engineering company specialized in system dependability.
It verifies the concepts and tools required to create secure systems and uses formal techniques to define, design and validate
systems, then create critical software for their integration.
In B, the expression of dynamic constraints is notoriously missing. In this paper, we make various proposals for introducing them.
They all express, in different complementary ways, how a system is allowed to evolve. Such descriptions are independent of
the proposed evolutions of the system, which are defined, as usual, by means of a number of operations. Some proof obligations
are thus proposed in order to reconcile the two points of view. We have been very careful to ensure that these proposals are
compatible with refinement. They are illustrated by several little examples, and a larger one. In a series of small appendices,
we also give some theoretical foundations to our approach. In writing this paper, we have been heavily influenced by the pioneering
works of Z. Manna and A. Pnueli [11], L. Lamport [10], R. Back [5] and M. Butler [6].
Automated test generation from B abstract machines is commonly used in the smart card industry since 2003. Several domains are concerned such as mobile communication applications (e.g. SIM cards) [1], identity applications (e.g. health cards or identity cards) and banking applications. The model-based testing tool LTG (LEIRIOS Test Generator) [2] makes it possible to generate executable test scripts from a B formal model of the functional requirements. Therefore, the design of the test cases and the development of the test scripts are based on a modeling and automated test generation approach.
The model-based testing process is structured in 3 main steps:
Model. The first step consists in developing a behavior model using the B abstract machine notation. The model represents the expected behavior of the smart card application under test.
Configure test generation. The configuration of the test generation with LTG is based on model coverage criteria. Three families of criteria give a precise control over the test generation: decision coverage, operation effect coverage and data coverage.
Adapt. The generated test cases are then translated in executable test scripts using an adaptor customized for the test execution environment and the project.
This talk show how B abstract machines are developed in the context of model-based testing of smart card applications, how model coverage criteria makes it possible to generate accurate test cases and how those test cases are adapted into executable test scripts for a targeted test execution environment.
The communication between a developer and a domain expert (or manager) is very important for successful deployment of formal
methods. On the one hand it is crucial for the developer to get feedback from the domain expert for further development. On
the other hand the domain expert needs to check whether his expectations are met. An animation tool allows to check the presence
of desired functionality and to inspect the behaviour of a specification, but requires knowledge about the mathematical notation.
To avoid this problem, it is useful to create domain specific visualisations. One tool which performs this task is Brama.
This tool is very important for ClearSy, and is being used for several industrial projects and has helped to obtain several
contracts. However, the tool cannot be applied in conjunction with ProB. Also, creating the code that defines the mapping
between a state and its graphical representation is a rather time consuming task. It can take several weeks to develop a custom
visualisation.
The B Method is a full spectrum formal software development method that covers the software process from specification to implementation. The method uses state machines, defined using logic and set theory with a notation similar to that of Z, that export operations. The method supports a notion of refinement and implementation, which is based on the notion of refinement in the refinement calculus with the exception that there is no distinction between procedural and data refinement. The B Toolkit is a configuration tool that manages developments under the B Method, generating proof obligations and supporting tools for the discharge of those proof obligations. There is also support for the generation of documentation, and for the browsing of developments.
A practical text suitable for an introductory or advanced course in formal methods, this book presents a mathematical approach to modelling and designing systems using an extension of the B formal method: Event-B. Based on the idea of refinement, the author's systematic approach allows the user to construct models gradually and to facilitate a systematic reasoning method by means of proofs. Readers will learn how to build models of programs and, more generally, discrete systems, but this is all done with practice in mind. The numerous examples provided arise from various sources of computer system developments, including sequential programs, concurrent programs and electronic circuits. The book also contains a large number of exercises and projects ranging in difficulty. Each of the examples included in the book has been proved using the Rodin Platform tool set, which is available free for download at www.event-b.org.
This paper gives a tutorial introduction to the ideas behind system development using the B-Method. Properly handled, the crucial relationship between requirements and formal model leads to systems that are correct by construction. Some industrial successes are outlined.