Verification of domain specific models

A way to ease the use of model checking is to replace the formal languages byDomain Specific Language (DSL). These languages propose a simpler syntax

— because they use idioms that are close to the domain concepts — while preserving a precisely defined semantics and therefore usable in model checking.

This approach goes as follows. First an engineer (called language engineer) captures the concepts, the vocabulary and the business of a given domain. Then, the language engineer describes the syntax of a language that is very close to the domain of the designer as well as a transformation from the DSL (e.g.,mobile phone, automotive, . . . ) to a given formal language (e.g.,automata, π-calculus, Algebraic Petri Nets (APNs), . . . ). The language as well as the transformations

8 Chapter 1. Introduction must take care of the counter-examples. Namely, a part of the DSL must be responsible for the presentation of counter-examples in a user-friendly way. The last step is to validate the language and its semantics with domain experts. This transformation gives a precise semantics to the DSL. This approach has been used in [SBH⁺11] in the case of biological processes and in [PRBA10] for control systems.

The goal of theDSLapproach is to free the system designer from the formal language syntax and its heaviness. The domain specific language is then inte-grated in the model checking process as described by Fig. 1.2. A tool called a model checker (e.g.,SPIN [Hol03], NuSMV [CCGR99], GreatSPN [BBC⁺09], Algebraic Petri Nets Analyzer (AlPiNA) [BHMR10b]) analyzes the transformed model and produces a counter-example when a property (i.e.,the specification) does not hold on it (e.g.,a state of the Ther25 in which the X-ray beam is ac-tive while the collimator is not in place). This counter-example is expressed is the formal syntax of the model checker and therefore must be translated back to a language understandable by the system designer. Using the counter-example the designer can correct the model of the system.

Because the designer only manipulates concepts that he masters, his trust in the model and in its semantics improves. This reassures the designer that the model of the system and the specifications conform to the customer expectations.

To that purpose, the semantics of each elements of the DSL should result of a consensus between the system designer and the language engineer.

Another positive point in the DSL approach is that it allows to transparently integrate a number of techniques and heuristics that alleviate theState Space Ex-plosion (SSE) during the transformation. Therefore, the system designer does not have to learn the arcane knowledge of formal verification. Besides, these heuristics can be improved by meta-data that can be part of the DSLand hence indirectly provided by the designer and extracted during transformation. Some of the heuristics used to mitigate theSSEare bound to the domain or to the kind of model (e.g.,concurrent, modular, real time, . . . ). Hence, using a modeling lan-guage that is close to the domain integrates meta-data in a very natural way and allow to exploit them during transformation. Finally, this approach limits the man-ual intervention of the designer to the conception work only, leaving the technical details to the language engineer and to the model checker.

The approach described previously is covered with great details in [JS06]. Im-plementing this approach requires a framework with the following properties:

1.2. Model checking 9

• to support a modeling and specification formalism that are sufficiently ex-pressive to represent all the models that might be built using the DSLand sufficiently flexible to limit the complexity of the transformation from and to theDSL,

• to provide optimizations that alleviate the SSE. Moreover, these optimiza-tions must be enabled automatically during the transformation,

• to the greatest extend possible; the features that alleviate theSSE must be hidden (at least to the system designer). Namely, the configurations relative to the model checking optimizations must be intuitive and not requiring to master the underlying technical details.

Model Checker

Transformation Transformation

Domain Specific Language Model of the system

Model of the system Algebraic Petri Nets

Counter-example Counter-example Domain Specific

Language

Algebraic Petri Nets

Automatic processing Manual intervention

models

Designer

Figure 1.2: Approach domain specific language applied to model checking.

10 Chapter 1. Introduction

1.3 AlPiNA: a symbolic model checker for high-level Petri nets

To reach the objective presented in Section1.2.2, the verification of domain spe-cific models has been split along several work packages in the SMV laboratory.

The objective of the AlPiNA project, which is in the center of this thesis, is to provide a framework that has the properties enunciated in Section 1.2.2. Other members of the SMV laboratory, Matteo Risoldi [Ris10] and Luis Pedro [Ped09]

covered the DSL and the transformation parts in extensive details. Henceforth, we do not considerate the part of Fig. 1.2 that concerns theDSL and we admit that an advanced user directly produce models as well as specifications in a formal language as described in Fig. 1.5. Because, he should manipulate the modeling and verification concepts as well as the techniques to mitigate theSSE, this advanced user has to master the formalism and the way the optimizations work. The language engineer that defines the transformation normally assumes this role.

Fig. 1.3 gives an overview of ^AlPiNA’s approach to the model checking ac-tivity usingBusiness Process Modeling Notation (BPMN). First (“Designing the model”) the user designs a model of the system to analyze, as well as a set of prop-erties that are expected to hold on the system. This activity requires both a model (to describehowthe system works) and a specification language (to describewhat the system does). Then (“Performing verification”)AlPiNAeither confirms that the properties hold, or reports a violation. In the latter case, it provides a counterex-ample,i.e.,a state that violates the property. The user may use the counterexample to refine the model of the system or to correct the property. Also (“Scaling up the model”) the user may provide optimization information to improve the verification performance.

property does not hold property holds

counter-example

Figure 1.3: Model checking process using AlPiNA

1.3. AlPiNA: a symbolic model checker for high-level Petri nets 11