What important system concepts can be handled "elegantly" with a selected formal method ?

Main -> FAQ -> G-EA-1


 * Theme: General Information on FM (G)
 * Role: EA

The goal of formal methods is to verify, test, or develop a model that has desired properties.
 * The properties can be either generic domain-independent such as absence of deadlocks or livelocks or domain-specific, possibly in the overall environment, such as an invariant or a deadline for a reaction of the model.
 * The model can represent a finite state machine, a more complex transition system such as a communication protocol, or a hybrid system (with both discrete and continuous behaviours), etc.

The main issue in constituting a design flow is selecting the right formal methods. These can vary greatly according to the kind of properties to prove on the targeted system. Furthermore, it is crucial to ensure that the property proven on the model makes sense in the real setting of the system.

For instance, when a property of a reactive system is verified, it is crucial for the inputs considered by the model to cover all possible inputs delivered or generated in the production/real life environment in which the product will operate. This can include timing issues, values, etc. For high assurance system, one should also consider failures of various components of the environment and erroneous inputs.

Different formal method natively support different system concepts such as real time, invariants, etc., however, one might twist a given formal method to incorporate additional concepts that it does not support natively. This twisting increases the risk to produce inelegant models, that is: hard to understand, maintain, requiring unnecessarily complex proofs etc.

In the remaining of this section, we cover several aspects of system modelling such as discrete vs. continuous, real time, and probabilities. We present facts to help industrials to select the most appropriate method for each of them, according to their specific industrial and technical setting.

Reasoning about the real world: continuous world vs. discrete model
For instance, the B formalism captures only discrete values. As a consequence, the physical dimensions captured in B models to represent the environment of the system under construction are all made discrete. This has to be taken into account when we reason about concepts that are continuous in the real world, such as the speed or distances of metro's in the context of metro driving software. In such context, two main strategies can be developed, and used together:
 * Chose a discretising that is fine enough, so that the correctness of the concrete implementation can be deduced by the correctness of the discrete model. Speed of trains can be represented in cm/sec instead of using the traditional km/h dimensions.
 * Develop a model that uses safe rounding techniques, so that the discrete values are always rounded "on the safe side", even for intricate arithmetic functions . For instance, if we prove that trains will always stop within the available stopping distance rounded down to the inferior meter, the proof makes sense in the real continuous world.

A more intricate example is when the controlled system obeys complex physical laws, as met in flight control systems such as the Traffic alert and Collision Avoidance System (TCAS). In such system, one wants to prove that airplanes will not collide when they are under the control of software that pilots the plane to perform collision avoidance manoeuvres. The trajectories followed by airplanes must always be flyable, that is: airplanes cannot brake; make sharps turns or climb abruptly. Such systems are called hybrid systems, and a specific research with specific tools has been done to handle such cases in a completely sound manner.

Real time
A more common issue in verification is real time. Real time is when the reaction of the software must obey timing constraints. The most typical constraints are deadlines, where the output of the software must come before some timeout, but other constraints can also appear such as early deadlines or concomittance where the software cannot produce an output before some timing or where it must produce two outputs at the same time or within some bounded timing interval, respectively.

Model-checking is a technique that is able to verify complex timing properties on transition systems. Most of these tools reason on models where the time is made discrete, either because it is structured along a "universal clock" that regularly ticks, and generates a new state of the system or because time progresses by one unit at each event of the considered model.
 * SMV, and its successor NuSMV are well-known representative of such formal tools. In their logics, time is discrete, and progresses along a universal clock. They support finite state machine, and properties to verify can be expressed in temporal propositional logics . For instance, one can specify that a train must stop within three "tics" after some signal is received as follows: StopSignal => ooo TrainStopped where o represents the "next" operator that captures a "tic", and => represents an implication.
 * UPPAAL is a well-known model checker that supports the notion of continuous time. In the logics of this tool, time is continuous, and progresses as in the real world, while modelled system is a finite state machine whose conditions can be expressed in term of the continuous time . For instance, on can specify the same train stopping requirement with better realism as follows: StopSignal => <>_{3 minutes} TrainStopped.

One does not always need to formally reason on timing conditions even if a formal method is in use. In the Deploy project, Siemens has reported that their control system are conceived as a single response loop that is executed repeatedly and outputs are computed in a single pass of this loop. The loop itself must execute within some time bound. This time bound is checked at run time, and in case the deadline is missed, the control system activates the emergency brakes, which is the default emergency procedure that brings the train into a safe and stable state. This approach can only support a single deadline, and can only be applied if a default safe procedure can be activated at any time.

Bosh has tried to reason about responsiveness of reactive systems modelled in Event-B. EventB does snot natively supports the notion of deadline and timing condition; rather it is aimed for reasoning about invariant, convergence, and refinement of state machines. The approach of Bosh was to adding a set of time counters within their models, and incrementing the counter at each relevant event, to model the elapsing of time. In order to prove convergence and responsiveness, they also had to develop a series of complex invariants referencing the counters from the model to capture the exact semantics of these counters. This approach requires a lot of effort in the development of invariants that capture the notion of time, and delivered very complex model, that is: hard to understand, maintain, etc. Similar patterns for reasoning about time and consistency in business information systems in Event-B have been proposed in. These patterns rely on a specific variable representing a time counter, and specific event called "tic" to model the elapsing of time.

There have been proposals to integrate the Event-B method with the SMV and UPPAAL tools in order to natively support the notion of time in the Event-B language.

However, the initial semantics of Event-B does not support the notion of responsiveness; this integration therefore required extending the language and part of its semantics.

Fault tolerance
There are several ways to reason about fault tolerance using formal methods. It depends mainly on the kind of property one wants to prove about the verification target, and on the kind of error one wants to envision.

When one wants to reason about the robustness of the verification target against some well-identified failures in the environment, a common technique is to model not only the target of verification, but also its environment. Modelling the environment allows one to capture its possible faults into the model, and to reason on the overall system. This approach has been followed during the Deploy project in the context of business information systems. They developed Event-B models that included not only the application that was the target of verification, but also part of the environment, namely the underlying communication middleware.

When ones requires quantification of some overall error rate of a system, one need to include probabilities into the model.

Probabilities
Specific probabilities for relatively simple systems can be estimated manually or with the help of common statistic tools. For more complex systems, specific tools can be used to formally reason on them.

PRISM is a good representative of probabilistic model checker. Probabilistic model checking is a formal verification technique for the modelling and analysis of stochastic systems. It has proved to be useful for studying a wide range of quantitative properties of models taken from many different application domains. This includes, for example, performance and reliability properties of computer and communication systems. It natively supports input models representing state machine with probabilistic transitions.

PEPA is a formal language which allows quantitative analysis of systems. Models can be described in a compositional way - as cooperation between individual automata that carry out actions. By associating rates to each action of the model, the description is interpreted against an interleaving semantics which gives rise to an underlying Continuous Time Markov Chain. Typical questions that can be answered by the analysis of the Markov chain are the throughput of an action or the utilisation of a component.

There have been attempts to reason on overall probability of failure of systems in Event-B. Event-B does not natively support the notion of probability.