Conference PaperPDF Available

Formal Methods in Safety-Critical Railway Systems

Authors:

Abstract

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.
Formal Methods in Safety-Critical Railway Systems
Thierry Lecomte
1
, Thierry Servat
1
, Guilhem Pouzancre
1
1
ClearSy, Aix en Provence, France.
{thierry.lecomte, Thierry.servat, guilhem.pouzancre}@clearsy.com
Abstract. 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/SIL41 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
qualified2 by French authorities.
1. Introduction
Historically, the B Method was introduced in the late 80s' to design correctly safe software (see
[Abrial 96]). Promoted and supported by RATP3, B and Atelier B, the tool implementing it, have
been successfully applied to the industry of transportation. First real success was Meteor line 14
driverless metro in Paris: Over 110 000 lines of B models were written, generating 86 000 lines of
Ada. No bugs were detected after the proofs, neither at the functional validation, at the integration
validation, at on-site test, nor since the metro lines operate (October 1998). The safety-critical
software is still in version 1.0 in year 2007, without any bug detected so far. Today, Alstom
Transportation Systems and Siemens Transportation Systems (representing 80% of the worldwide
metro market) are the two main actors in the development of B safety-critical software
development. Both have a product based strategy and reuse as much as possible existing B models
to develop future metros. For the time being, ClearSy has developed for Siemens the biggest B
application: the Charles de Gaule airport shuttle automated pilot is a 150 000 lines of code program.
On a different domain, Gemplus has developed a smartcard java bytecode verifier [Casset 99].
A more widely scope use of B appeared in the mid ‘90s, called Event-B, to analyze, study and
specify, not only software, but also whole systems (see [Abrial 05]). Event-B has been influenced by
the work done earlier on Action Systems by the Finnish School (Action System however remained
an academic project). Event-B is the synthesis between B and Action System. Itt extends the usage
of B to systems that might contain software but also hardware and pieces of equipment. In that
respect, one of the outcome of Event-B is the proved definition of systems architectures and, more
generally, the proved development of, so called, “system studies”, which are performed before the
specification and design of the software. This enlargement allows one to perform failure studies
right from the beginning in a large system development. Event-B has been applied in many cases to
various fields: certification of smartcard security policies (level EAL5+, Common Criteria),
1
SIL (Safety Integrity Level) is defined as a relative level of risk-reduction provided by a safety function, or to specify a target level
of risk reduction. Four SIL levels are defined, with SIL4 being the most dependable and SIL1 being the least. A SIL is determined
based on a number of quantitative factors in combination with qualitative factors such as development process and safety life cycle
management.
2
French authorities define Qualified as « Certified and working » while Certified is mainly a verification of conformance to
specification (the system produced may or may not work properly).
3
Régie Autonome des Transports Parisiens : operates bus and metro public transport in Paris
verification of Ariane 5 launcher embedded flight software, generation of proven hardware
specification, etc. Event-B has now its own modelling and proof platform Rodin4.
In this article, we try to make clear what the different usages of B are, and to which extent its
recent use in railway industry, at the system level, is a success. Section 2 presents the main
differences between software development in general and software development in B. Section 3
details the first platform screen door system which has been modelled in B, details the development
process and presents qualitative and quantitative results. Section 4 presents another PSD controller
system under construction. Section 5 concludes.
2. Specifying safety-critical software or systems
Specifying safety-critical software or systems share the same philosophy: make use of abstraction,
refinement and proof to mathematically demonstrate that a collection of models is coherent. First,
internal coherency is checked for each model (described behaviour complies with properties).
Second, each refinement is checked not to contradict its abstraction (the model containing fewer
details). At the end, when this collection of models is proved, the concrete part is considered
complying to the abstract specification and the model is then ready to be translated, as described in
figure 1.
Figure 1. Modelling and proof cycle in B
Both approaches make use of set theory, first order logic and generalized substitution calculus.
The main difference relies on the modelling paradigm and the way to structure the models. In
software modelling, behaviour is described in terms of operations which represent programming
functions that execute in sequence. The modelling language is different in specification and in
implementation (no sequence in specification, no parallel action in implementation, no loop in
specification, only implementable types in implementation, etc). Implementation B language is
called B0. An implementation may import other models (abstract machines) and possibly delegate
implementation of variables. That way, program specification is broken into smaller components
that help to manage complexity. Design (refinement, decomposition with importation) are verified
by proof on the fly, not when the development has been completed.
In system modelling, behaviour is described in term of atomic events that modify state variables
of the system. One model represents a complete view of a closed system. The language is
4
http://sourceforge.net/projects/rodin-b_sharp/
homogeneous during the complete development process; there is no specific language for final
implementation. Event-B language slightly differs from B language, as it has been simplified and
made unambiguous. This approach is well suited to represent asynchronous behaviour, such as
interruption based software.
3. COPPILOT: A platform screen door controller
3.1. Presentation
In France, RATP has used for years platform screen doors (PSD) that prevent customers to enter
or to fall on tracks. Such a system was adopted by the METEOR driverless metro, as it dramatically
improves trains availability. In order to offer higher quality services and more safety to its
customers, RATP was trying to introduce this kind of protection system in several lines, automated
or not. For practical reasons, trains and cars could not be modified with the introduction of PSD.
Before starting to deploy a new PSD system in an entire line, RATP initiated a project aimed at
developing a prototype PSD system for three stations of line 13.
Figure 2. COPPILOT Platform Screen Door
These prototypes would be evaluated during eight months. ClearSy was in charge of developing
the SIL3 compliant (probability of system failure less than 10
-7
), control command controller. This
controller is in charge of detecting the arrival, presence at a standstill and departure of trains without
direct connection with them (on the contrary, Meteor5 trains communicate with PSD through
dedicated communications lines). Once the train is at standstill, the controller should be able to
detect train doors opening and closing, and then issue PSD opening and closing orders. These orders
have to be securely issued (failure by elaborating a wrong opening order may lead to customers
injury or death), and controller have to be designed, tested and validated in accordance with railway
regulations (IEC 50126, 50128, 50129 in particular).
The timescale of this project was quite short as the PSD controller would be installed in only 10
months after the beginning of the project. Given these strong timing constraints, we decided to
adopt a secure architecture able to be quickly qualified by regulation authorities, loosely coupled
5
First driverless metro operated in Paris
with sensor technology. The final architecture was based on Siemens safety automaton (Simatic S7),
SIL3 compliant, and ordinary infra-red and radar sensors. In this case, security relies on the safety
automaton and on sensor measure redundancy, not on the safety properties of the sensors. This
approach leads to a decrease in system costs as usual since non-safety sensors are really cheaper
than safety ones, leading to easier provisioning (shorter delay, no dependency towards a unique
provider).
3.2. The development process
In order to reach the required safety level during project timescale, we decided to set up a
development method aimed at reaching targeted reliability, and also ensuring traceability between
the different stages of the projects in order to reduce the validation effort. This method was heavily
based on the B formal method, and applied during most phases of the project.
Before any development activity, a formal functional analysis of the system was performed, to
evaluate “completeness” and ambiguity freeness of the statement of work. At that time, the solution
imagined by RATP was to point two laser telemeters on the platform, and to apply two independent
2D image recognitions in order to detect train arrival and departure, as well as train door opening
and closing. The B method was used to:
- Verify on the overall system (PSD + controller) that functional constraints and safety
properties were verified (no possibility to establish forbidden connections between train and
platform or between train and tracks).
- Lead to the observation of dangerous system behaviour.
Telemeter based solution was then evaluated in order to verify that its compliancy with project
constraints. This solution was finally abandoned due to the fact that designing two independent (but
concordant) image recognition algorithms was judged too risky during the short lifetime of the
project.
A new architecture was then imagined and proposed, making use of usual sensors and processing
based on temporal sequence recognition of sensor events. Hyper frequency, infrared and laser
sensors help to improve system resistance to various perturbations. Redundancy among sensors
using different technology raises measures confidence. These sensors were positioned on the
platform and pointed to the tracks in order to measure train position, train speed and train door
movements.
System and software specification were then formalized in B by the development team, taking
into account only nominal behaviour for the sensors (in absence of perturbation). Models obtained
from previous functional analysis (independent from any PSD controller architecture) were directly
reused. The proposed architecture was modelled and inserted in these previous models. New
architecture was successfully checked by proof to comply with functional specification of the
system, including parts of the French underground regulations. Controller functions were then
precisely modelled (train arrival, train detection, train departure, train door opening, train door
closing, etc). In the meantime, an independent safety case6 was developed in parallel by the security
team, in order to precisely define how external perturbations may influence the behaviour of the
PSD controller. Perturbations were given a priori or a posteriori frequencies, depending on
availability of such data at RATP, and a mathematical model, independent from the B model, was
set up in order to determine quantitatively the security level of the system. A priori frequencies were
6
Safety oriented study that provides a convincing and valid argument that a system is adequately safe for a given
application in a given environment.
verified during the eight month experiment. In case these frequencies were not verified and lower
system security below SIL3 level, the PSD controllers would have to be redesigned considering this
new information.
Figure 3. Development and verification process
The resulting B model was animated with the Brama animator7, in order to verify on given
scenarios that the model produced was corresponding to the real system we were modelling. This
model animator was not part of the validation process, as this would require it to be qualified as a
SIL3 software, but it helped us to check models against reality and to internally verify their
suitability. In figure 4, the left window displays the list of events of the model (fireable ones have a
checkbox before their name) and the list of variables and associated values. Values can be modified
on the fly to setup a starting point, the animator verifying that proposed values comply with the
invariant properties.
Specification documentation was partly elaborated from the system level models developed
during this project. The composys8 tool has no proof capabilities but, as an engineering tool, helps
the modeller to add contextual information (comments, description, component name, etc) in B
models that are used to generate in natural language the specification documentation describing the
complete system. As events are associated to components and as variables are used within events
(read/write), Composys computes relationships among components constituting the system being
modelled, depending on how variables are read or modified.
7
http://www.brama.fr
8
http://www.composys.fr
Figure 4. Animation of B refinements with Brama
These relationships are then graphically displayed, boxes represent components, ovals represent
medium linking two or more components (medium can be an electric wire, a network, etc) and text
near connecting lines are description of variables involved in the information exchange (Figure 5).
This document was used to check models with experts of the domain, unable to read and understand
formal models.
Figure 5. Example of relationships within a B model exhibited by Composys
The development of the software was based on the formal models, as B enables the production of
source code, proven to comply with its specification. Siemens automaton can be programmed in the
LADDER language but, unfortunately, requires entering program source code via its graphical
interface (according to its certificate) to keep its SIL3 accreditation. A dedicated translation schema
(from B to LADDER) was elaborated. B to LADDER state diagrams translation is straightforward
and some optimisations were introduced in order to verify temporal constraints (cycle time in
particular). During validation phase, one can determine which event of the B model corresponds to
the path of the LADDER program for a cycle (a LADDER program is defined by logical equations
and is analyzed in term of execution path). In case the source code is automatically generated by a
qualified translator (as for automatic pilots, by Siemens and Alstom), no unit test is required, this
testing phase being covered by the proof of the model. In this project, as the source code was not
generated automatically by such a translator, test was required and test specification was elaborated
by usual means. Some months after the beginning of the project, we obtained a fully functional,
tested and validated application. The process described above has enabled us to produce a 100%
tested, error free (against its specification) software when running validation test bench for the first
time. A dedicated test bench was designed to simulate major perturbations (sensors were emulated)
and run during days, but no faulty behaviour was observed.
Integration testing was performed on a dedicated testing platform installed in the METEOR line.
Tracks and sensors being already protected by PSD in the line, measurement campaigns were setup
quickly in order to assess as quickly as possible security, availability, response time, etc). Sensor
technology choices were validated at that occasion.
3.3. Results
Finally, 4 months after the beginning of the project, the PSD controller was deployed on 3
platforms on line 13, for a 8 month experiment. The following metrics were obtained:
- equip: a project manager, a developer, a validation engineer, a safety engineer
- initial system level functional specification: 130 page document
- safety case: 15 documents representing 300 pages
- development documentation: 30 documents representing 600 pages
- formal B models: 3500 lines of code, representing about 1000 proof obligations. 90 % were
demonstrated automatically, the remaining proof obligations were discharged in two days
with the Atelier B interactive prover.
This system was experimented during 8 months, controlling around 96 000 trains. No fault was
observed. Hypotheses made during the safety case were confirmed and made more accurate. System
availability conformed to expectations and, after initial setup and tuning, no passenger remained
stuck in the train (PSD should open 9999 out of 10000 times when a valid train is at standstill
opening its doors).
4. DOF1: another platform screen door controller
At the end of the experiment, ClearSy was given the responsibility to design a similar system: the
DOF1 PSD controller system. In the context of the "Paris Subway Line 1 Automation" project, the
SIL4 DOF1 safety system, which is independent from the automatic train system, will command the
opening and closing of the platform screen doors installed on all the line's platforms.
This system will be used with existing trains and will be compatible with the new automatic
trains that will progressively replace the current ones. DOF1 also prevents the train doors on the
opposite side of the platform from opening. DOF1 will be installed on 26 stations and 52 trains.
Figure 6. The DOF1 architecture
DOF1 will then be disassembled when all the automatic trains are in operation on Line 1.
The DOF1 system includes an embedded portion on the train that processes the train door
opening and closing commands issued by the conductor and sends the command to the portion
located in the platform’s technical office. The command to open the door is processed and sent to
the landing doors. This architecture is presented in figure 6.
This system is SIL4-level safe to ensure the landing doors can only be opened when the train has
reached the platform. The solution is based on Siemens SIL3 automatons.
Figure 7. The DOF1 animated model submitted to the call for tender
We adopted an original method to submit to the call to tender: a B model of the specifications
was constructed with the Composys tool, then graphically animated with the Brama tool (figure 7).
We were therefore able to define the needs of the RATP by transcribing our understanding of the
system into a model and then validating this understanding by animating the system in various
scenarios viewed on the screen. Questions could therefore be asked and a detailed response
provided, as the system must be designed in only six months.
As for the COPPILOT system, we use a development process that integrates the B method, from
the system specifications up to the code stage. The B models developed participate in demonstrating
the system's safety and the level of availability of the system that must be very high in order to
ensure fluid traffic.
5. Conclusion
The methodology we have developed appears to be efficient and well suited to address projects
requiring high level of safety and short development time. The B formal method was not initially
considered by RATP, but is now well accepted. The writing of some extra documents were required
to help RATP engineers to fully understand, verify and qualify our deliverables. Reuse of existing
models for similar projects proved to be efficient.
Several issues have to be overcome in order to obtain a more efficient process:
- Manual translation from B models to the target language (LADDER in our case) is error
prone and require specific verification process (a dedicated verification guide was written,
enabling RATP to cross-check software). One possible solution is to develop a dedicated
translator (from B to automaton assembly). That translator should be certified. Another
possibility is to use a model animator (like brama) to automatically produce test benches and
to validate manually developed applications on the final target.
- Functional and dysfunctional models are disjoint and also error prone. Research project
related to the combination of B and Altarica [Rauzy 98] (used by EADS on A350 Airbus
program for reliability studies) languages is ongoing.
Acknowledgements
The authors would like to acknowledge the support of the RODIN (Rigorous Open Development
Environment for Complex Systems) Project funded by the European IST.
References
Abrial, J.R. (1996) , The B-book: Assigning programs to meanings, Cambridge University Press
Abrial, J.R (2005)., Rigorous Open Development Environment for Complex Systems: event B language
Burdy, L.(1996) , Automatic Refinement. In Proceedings of BUGM at FM'99
Casset, L.,(1999) A formal specification of the Java byte code verifier using the B method, Lisbonne 99
Rauzy, A., (1998),The Altarica Language In Proceedings of the International Conference on Safety and Reliability, ESREL'98,
Sabatier, D. & al (2006), Use of the Formal B Method for a SIL3 System Landing Door Commands for line 13 of the
Paris subway, Lambda Mu 15
... Abrial, Lee, et al. 1991] is one example of a formal language that, together with its supporting tools, allow the system specification, verification, analysis, refinement, implementation and automatic code generation. In fact, the B-method has been already successfully applied in industrial railway projects ( [Behm et al. 1999], [Lecomte, Servat, Pouzancre, et al. 2007]). ...
... Some formal languages have already been used in industry with successful results. One of the examples is the B-method, which is considered as one of the strongest approaches for the specification of railway systems [Fantechi, Fokkink, and Morzenti 2013] and which has already been successfully used for the analysis and development of software in many different projects, like METEOR [Behm et al. 1999], COPPILOT [Lecomte, Servat, Pouzancre, et al. 2007] and SACEM [Guiho and Hennebert 1990]. Other examples of languages used in this context are Petri Nets [Peterson 1977], CSP [Schneider 2000] and Z [Spivey and J. Abrial 1992], used in works like [Sun, Collartdutilleul, and Bon 2015], [Winter 2002] and , respectively, as discussed in the Figure 1.9 -Representation of a relay-based RIS implemented as a piece of software that communicates with the track-side components through the system inputs (in yellow) and outputs (in green). ...
... One example of a formal language that has been successfully used in industry for the development and verification of railway systems is the B-method. It has been used in projects like METEOR [Behm et al. 1999], COPPILOT [Lecomte, Servat, Pouzancre, et al. 2007] and SACEM [Guiho and Hennebert 1990], for instance. Furthermore, it is known to be one of the strongest approaches for the development of railway systems [Fantechi, Fokkink, and Morzenti 2013]. ...
Thesis
Full-text available
Relay-based Railway Interlocking Systems (RIS) are critical systems and must be specified and safety proved in order to guarantee the absence of hazards during their execution. However, this is a challenging task, since Relay-based RIS are generally only structurally modelled in a way that their behavioural analysis are made manually based on the experts knowledge about the system. Thus, the existence of a RIS behavioural formal description is imperative in order to be able to perform safety proofs. Furthermore, as Computer-based RIS tend to be less expensive, more maintainable and extendable, the industry has interest in the existence of a methodology for transforming the existing Relay-based RIS into Computer-based RIS.Formal specification methodologies are grounded in strong mathematical foundations that allow the systems safety proof. Besides, many formal specification languages support not only the verification, but also the implementation of these systems through a formal development process. Thus, Formal Methods may be the key in order to prove the RIS safety and implement them with computer-based technologies.This thesis addresses two main propositions. Firstly, it presents an analysis of the relay diagrams information and a formalisation of the Relay-based RIS structure and behaviour based on mathematical expressions as a way to create a certain level of formalisation of the systems. The resulting model can be extended and adapted in order to conform to different railway contexts and it can be used in order to support the specification of these systems in different formal specification languages. Then, this thesis presents how the RIS formal model can be adapted in order to formally specify these systems in B-method, a formal specification language with a successful history in the railway field and which allows the system safety proof and implementation as computer-based systems.As a result, this thesis presents a complete methodology for the specification and verification of Relay-based Railway Interlocking Systems, giving support for the systems safety proof in different contexts and for their specification and implementation in many different formal languages.
... Many publications related to IV&V are based on formal methods, which use algebraic and special notations like B, Z, Event-B, VDM, and temporal logic as well as appropriate methods for verifying the correctness of the description and fulfillment of requirements within the relevant formal systems [7][8][9][10]. Some cases of their use in industrial systems have been successful [1,9]. of invariants are analyzed in Section 4. Principles and stages of FPGA project invariant development are described in Section 5. A case study of safety invariant-based assessment of the FPGA project is presented in Section 6. Section 7 concludes the research results and discusses future steps. ...
... Many publications related to IV&V are based on formal methods, which use algebraic and special notations like B, Z, Event-B, VDM, and temporal logic as well as appropriate methods for verifying the correctness of the description and fulfillment of requirements within the relevant formal systems [7][8][9][10]. Some cases of their use in industrial systems have been successful [1,9]. of invariants are analyzed in Section 4. Principles and stages of FPGA project invariant development are described in Section 5. A case study of safety invariant-based assessment of the FPGA project is presented in Section 6. Section 7 concludes the research results and discusses future steps. ...
Article
Full-text available
This paper describes a proposed method and technology of safety assessment of projects based on field programmable gate arrays (FPGA). Safety assessment is based on special invariants, e.g., properties which remain unchanged when a specified transformation is applied. A classification and examples of FPGA project invariants are provided. In the paper, two types of invariants are described. The first type of invariants used for such assessment are those which are versatile since they reflect the unchanged properties of FPGA projects, hardware description languages, etc. These invariants can be replenished as experience gained in project implementation accumulates. The second type of invariants is formed based on an analysis of the specifics of a particular FPGA project and reflects the features of the tasks to be solved, the algorithms that are implemented, the hardware FPGA chips used, and the computer-aided design tools, etc. The paper contains a description of the overall conception and particular stages of FPGA projects invariant-based safety assessment. As examples for solving some tasks (using of invariants and defect injections), the paper contains several algorithms written in the VHSIC hardware description language (VHDL). The paper summarizes the results obtained during several years of practical and theoretical research. It can be of practical use for engineers and researchers in the field of quality, reliability, and security of embedded systems, software and information management systems for critical and business applications.
... Applying formal methods to critical industrial software was met with successes. For instance the Paris subway lines 1 and 14 are fully automated; the correct behaviour of their software was proven using the Method B and Atelier B [Cle], a kind of formal methods; other components of subway lines can be proven correct as well [LSP07]. We call the process of verifying software using formal methods the process of formal veri cation. ...
Thesis
Full-text available
Machine Learning techniques, Neural Networks in particular,are going through an impressive expansion, permeating various domains, becoming the next frontier forhuman societies. Autonomous vehicles, aircraft collisionavoidance, cancer detection, justice advisors, or mooring line failure detection are but a few examples of Neural Networks applications.This effervescence, however, may hold more than benefits,as it slowly but surely reaches critical systems.Indeed, the remarkable efficiency of neural nets comes at a price, more and more underlined by the scientific consensus : weakness to environmental or adversarial perturbations, unpredictability... which prevents their full-scale integration into critical systems. While the domain of critical software enjoys a plethora of methods that help verify and validate software (abstract interpretation, model checking, simulation, bounded tests...),these methods are generally useless when it comes to Neural Nets.This thesis aims at bridging formal software verification and machine learning, in order to bring trust in critical systems incorporating Neural Networks elements.
... The B-method was initially provided with two complete tool sets (Atelier-B from ClearSy (France) and B-Toolkit from B-Core (UK)) and a methodology that could be used in the industry. The first real industrial success was Meteor line 14 driverless metro in Paris (110 000 lines of B models) [LSP07]. Recently, another formal method using refinement called Event-B 3 has been developed to cover the modeling of a complete system. ...
Thesis
The growing share of driver assistance functions, their criticality, as well as the prospect of certification of these functions, make their verification and validation necessary with a level of requirement that testing alone cannot ensure. For several years now, other industries such as aeronautics and railways have been subject to equivalent contexts. To respond to certain constraints, they have locally implemented formal methods. We are interested in the motivations and criteria that led to the use of formal methods in these industries in order to transpose them to automotive scenarios and identify the potential scope of application.In this thesis, we present our case studies and propose methodologies for the use of formal methods by non-expert engineers. Inductive model checking for a model-driven development process, abstract interpretation to demonstrate the absence of run-time errors in the code and deductive proof for critical library functions.Finally, we propose new algorithms to solve the problems identified during our experiments. These are, firstly, an invariant generator and a method using the semantics of data to process properties involving long-running timers in an efficient way, and secondly, an efficient algorithm to measure the coverage of the model by the properties using mutation techniques.
Chapter
Scientific research is devoted to determining the areas of integrated application of the formal method Event-B for the development of environmental management systems. The practice of prevention and elimination of environmental emergencies indicates the general nature of risks in the field of environmental, industrial and occupational safety. Accordingly, the management of these risks is optimally carried out on a single basis - in the framework of the creation of environmental management systems (objects of management are considered man-made hazardous objects, ecosystem objects). The application of the method of formal verification of Model Checking and the method of specification of requirements of Event-B at synthesis of administrative ecological decisions is offered. The formalization of management decisions in the system of ecological management in the conditions of abnormal ecological situations is given.KeywordsFormal methodsEvent-BFailure modesEffects (and criticality) analysisFault tree analysisReliability of computer systemsEcological management systemEcological systems
Chapter
Formal Methods are one means in software engineering that can help to ensure that a computer system meets its requirements. Using examples from space industry and every programmer’s daily life, we carefully develop an understanding of what constitutes a Formal Method. Formal Methods can play multiple roles in the software design process. Some software development standards actually require the use of Formal Methods for high integrity levels. Mostly, Formal Methods help to make system descriptions precise and to support system analysis. However, their application is feasible only when they are supported by tools. Consequently, tool qualification and certification play a significant role in standards. Formal Methods at work can be seen in the many (academic) surveys, but also in numerous published industrial success stories. Hints on how to study Formal Methods in academia and on how to apply Formal Methods in industry conclude the chapter.
Thesis
Full-text available
Although current quantum computers are limited to the use of a few quantum bits, the foundations of quantum programing have been growing over the last 20 years. These foundations have been theorized as early as in the 80’s but the complexity of their implementation caused these leads to be out of reach until very recently. In this context, the objective of this thesis is to contribute to the adaptation of the methods of formal specification and deductive verification of classical programs to quantum programs. I thus present my contributions to the study of quantum properties with the end goal of formalizing them. I study in particular quantum entanglement and quantum contextuality. These properties allow to classify quantum states and protocols, and in particular to differentiate them from classical ones. My study of entanglement is based more specifically on the evolution of entanglement during two quantum algorithms: the Grover algorithm and the Quantum Fourier Transform. To quantify entanglement along those algorithms, I use Mermin’s polynomials, which have the advantage of being implementable in actual quantum computers. My study of contextuality, on the other hand, relies on finite geometries representing experiments, which are said to be contextual when no non-contextual classical theory can predict the results. These geometries are associated with the binary symplectic polar spaces. We study their structure, and eventually use this structure to get insights on quantum protocols using contextuality. The study of these properties led to interesting conjectures which we started to formalize in proof environments, such as Coq and Why3, but are left as perspective as these works have not reach a conclusion yet.
Article
Full-text available
Safety critical systems, such as medical, automotive, and avionics systems, play an important role in our daily lives. Increasing demand for new technologies in these safety critical systems requires rapid adoption of commercial hardware and software. However, the adoption of new hardware and software increases life‐threatening vulnerabilities. To aid in the reduction of these vulnerabilities and system failures, this paper proposes a framework based on formal methods for developing safety‐critical systems from requirements analysis to code generation. This framework includes a development process for documenting system requirements using tabular expressions, automatic formal model generation from the documented requirements, verification and validation of the generated formal models using proof techniques and animations, interactive simulation for validating the required behavior of the developed models by enabling domain experts to observe the system states according to, and finally, code generation from the formal model into a desired language. A prototype toolchain is developed to automate this framework. An assessment of the proposed framework is undertaken through a case study: insulin infusion pump (IIP).
Article
The CD31 (platelet endothelial cell adhesion molecule-1 [PECAM-1]/endothelial cell adhesion molecule [endoCAM]) molecule expressed on leukocytes, platelets, and endothelial cells is postulated to mediate adhesion to endothelial cells and thereby function in immunity, inflammation, and wound healing. We report the following novel features of CD31 which suggests a role for it in adhesion amplification of unique T cell subsets: (a) engagement of CD31 induces the adhesive function of beta 1 and beta 2 integrins; (b) adhesion induction by CD31 immunoglobulin G (IgG) monoclonal antibodies (mAbs) is sensitive, requiring only bivalent mAb; (c) CD31 mAb induces adhesion rapidly, but it is transient; (d) unique subsets of CD4+ and CD8+ T cells express CD31, including all naive (CD45RA+) CD8 T cells; and (e) CD31 induction is selective, inducing adhesive function of beta 1 integrins, particularly very late antigen-4, more efficiently than the beta 2 integrin lymphocyte function-associated antigen-1. Conversely, CD3 is more effective in inducing beta 2-mediated adhesion. Taken together, these findings indicate that unique T cell subsets express CD31, and CD31 has the capacity to induce integrin-mediated adhesion of T cells in a sensitive and selective fashion. We propose that, in collaboration with other receptors/ligands, CD31 functions in an "adhesion cascade" by amplifying integrin-mediated adhesion of CD31+ T cells to other cells, particularly endothelial cells.
Article
Several adhesion molecules contribute to the interaction between T cells and antigen presenting cells or target cells. Leukocyte function-associated molecule-1 (LFA-1[CD11a/CD18]) and intercellular adhesion molecule-1 (ICAM-1 [CD54]) are one such critical adhesive receptor-counter-receptor combination. The importance of ICAM-1 dependent adhesion in the rejection response was initially demonstrated in cynomolgus renal allograft recipients treated with the anti-ICAM-1 murine monoclonal antibody BIRR1. BIRR1 also appeared to limit ischemic damage in these animals. A Phase I clinical trial has subsequently been completed in 18 patients who received cadaver donor renal allografts at high risk for delayed graft function (prolonged preservation time, highly-sensitized recipient). An adequate BIRR1 serum level was associated with significantly less delayed graft function (P<.01) and rejection (P<.01). In 1-hr biopsies, mouse IgG was detected along the endothelium of the vessels and glomeruli in the graft. There were no instances of primary nonfunction (PNF), and current allograft survival (follow-up: 16-30 months) in these ''high-risk'' mAb-treated patients is 78%. There were 3 instances of PNF and a graft survival rate of 56% in the recipients of the contralateral kidney allografts treated with conventional immunosuppression. No significant ''first-dose'' effect was associated with BIRR1 administration. These results establish a dosing schedule and the clinical safety of BIRR1. They also suggest that inhibition of leukocyte adhesion by mAb therapy may be useful in controlling allograft rejection and possibly in limiting reperfusion injury. Thus, these observations support the clinical importance of accessory molecules in T cell function. We hypothesize that anti-CD54 mAb acts by blocking leukocyte adhesion to the endothelium, thereby interfering with sensitization or target cell interaction.
Article
We have employed a murine model of cardiac transplantation and two monoclonal antibodies, M/K-2 and MECA-32, to study the responses of graft endothelia during allograft rejection. Using immunohistologic techniques, we demonstrate that the monoclonal antibody M/K-2, which binds to the murine cellular adhesion molecule VCAM- 1, reacts with an inducible endothelial epitope found in rejecting cardiac allografts, but not in cardiac isografts, normal cardiac tissues, or extracardiac vasculature from allografted mice. Similar, but focal, M/K-2 reactivity is also found in nontransplanted hearts undergoing virally induced myocarditis. M/K-2 reactivity does not develop in the nonrejecting cardiac allografts from nu/nu mice, and M/K-2 reactivity is found only in grafts that develop CD25+ graft-infiltrating cells-i.e., allografts but not isografts. PCR analyses of grafts during development of VCAM-1 expression indicate that allografts, but not isografts, contain mRNA for the cytokines IL-2 and IFN-gamma, and either of these cytokines may be associated with the expression of M/K-2 reactivity in rejecting allografts. Unlike M/K2, MECA-32 identifies an inducible epitope that is observed on myocardial endothelia of both isografts and allografts, but not normal cardiac tissues. Further, expression of the MECA-32 epitope can occur in grafts that do not develop CD25+ infiltrating lymphocytes, since it is observed in isografts and the native hearts of transplanted or sham-operated mice. Indeed, MECA-32 reactivity may be T cell independent, since it is also found in nonrejecting allografts of nu/nu mice. PCR analyses of grafts during development of MECA-32 reactivity indicate that cardiac isografts contain mRNA for IL-1, IL-6, TNF, and lymphotoxin. One or more of these might be associated with induction of MECA-32 reactivity.
Article
L'inhibition transitoire des fonctions des leucocytes des recepteurs avec un anticorps anti-LFA1 (qui reagit avec la chaine β comme de l'antigene fonctionnel des leucocytes humains) n'a pas semble faciliter la prise de greffe de la transplantation de moelle osseuse allogene debarassee des cellules T pour les leucemies
Article
Antigen-specific T cell activation depends on T cell receptor-ligand interaction and costimulatory signals generated when accessory molecules bind to their ligands, such as CD28 to the B7 (also called BB1) molecule. A soluble fusion protein of human CTLA-4 (a protein homologous to CD28) and the immunoglobulin (Ig) G1 Fc region (CTLA4Ig) binds to human and murine B7 with high avidity and blocks T cell activation in vitro. CTLA4Ig therapy blocked human pancreatic islet rejection in mice by directly affecting T cell recognition of B7^+ antigen-presenting cells. In addition, CTLA4Ig induced long-term, donor-specific tolerance, which may have applications to human organ transplantation.
Article
Adhesion of lymphocytes to endothelium is vital to lymphocyte migration into lymphoid tissue and into inflammatory sites. In this review, Yoji Shimizu and colleagues identify the molecules that mediate lymphocyte-endothelial cell adhesion, describe the underlying principles of lymphocyte migration, and discuss a model of the sequence of events that allow a lymphocyte to successfully attach to endothelium and migrate into the surrounding tissue.
Book
The B method is a means for specifying, designing and coding software systems. The long-awaited B Book is the standard reference for everything concerning this method. It contains the mathematical basis on which it is founded, the precise definitions of the notations used, and a large number of examples illustrating its use in practice. J.-R. Abrial, the inventor of B, has written the book in such a way that it can be used for self-study or for reference. It is in four parts, the first dealing with the mathematical foundations, including a systematic construction of predicate logic and set theory, and the definition of the various mathematical structures that are needed to formalize software systems; the author places special emphasis on the notion of proof. The second part contains a presentation of the Generalized Substitution Language and of the Abstract Machine Notation, which are both used to specify software systems; the author gives examples to show how large specifications can be constructed systematically. The next part introduces the two basic programming features of sequencing and loop, with examples showing how to construct small algorithms. The last part covers the very important notion of refinement. It shows how to construct large software systems by means of layered architectures of modules. It culminates with the presentation of several examples of complete development with a special emphasis on the methodological approach. Finally, appendices give summaries of all the logical and mathematical definitions, and of all the rules and proof obligations. With the appearance of The B Book, formal methods practitioners, computer scientists, and systems developers at last will have access to the definitive account of what will become one of the standard approaches to the construction of software systems.
Article
An indefinite survival of cardiac allografts between fully incompatible mice strains was observed when monoclonal antibodies (MAbs) to intercellular adhesion molecule-1 (ICAM-1) and leukocyte function-associated antigen-1 (LFA-1) were simultaneously administered after the transplantation for 6 days. Mice with long-term surviving cardiac allografts accepted skin grafts from the donor-strain but rejected skin grafts from a third-party strain. Because MAbs to ICAM-1 or LFA-1 alone were insufficient for prolonged tolerance, the two MAbs probably acted synergistically to induce specific unresponsiveness. Thus, ICAM-1----LFA-1 adhesion participates in the induction of allograft rejection and MAbs may be useful as therapeutic agents.
Article
Guidelines for submitting commentsPolicy: Comments that contribute to the discussion of the article will be posted within approximately three business days. We do not accept anonymous comments. Please include your email address; the address will not be displayed in the posted comment. Cell Press Editors will screen the comments to ensure that they are relevant and appropriate but comments will not be edited. The ultimate decision on publication of an online comment is at the Editors' discretion. Formatting: Please include a title for the comment and your affiliation. Note that symbols (e.g. Greek letters) may not transmit properly in this form due to potential software compatibility issues. Please spell out the words in place of the symbols (e.g. replace “α” with “alpha”). Comments should be no more than 8,000 characters (including spaces ) in length. References may be included when necessary but should be kept to a minimum. Be careful if copying and pasting from a Word document. Smart quotes can cause problems in the form. If you experience difficulties, please convert to a plain text file and then copy and paste into the form.