figure a

1 Introduction

Real-time systems are often used in critical environments, and may be verified using formal methods. Such systems are notoriously hard to verify due to nondeterminism, concurrency and timing constraints. Timed model checking provides designers with techniques to formally verify a real-time system. However, timed model checking may not always be fully satisfactory: First, in the early design phase, timing constants may not be known and, without them, model checking is not possible; Second, at runtime, timing constants may vary (due to uncertain bounds, or to processor clock drifts), in which case the model checking result may not hold anymore. In contrast, parametric timed model checking synthesizes timing values ensuring the system correctness.

Parametric timed automata (PTAs) are a powerful formalism to reason about, and formally verify critical real-time systems [5]. PTAs are finite state automata extended with clocks, real-valued variables evolving linearly, that can be compared with either integer constants or parameters in guards (constraints to take a transition) and invariants (constraints to remain in a location).

IMITATOR takes as input networks of “IMITATOR PTAs” (IPTAs) extending PTAs with several convenient features such as stopwatches, multi-rate clocks or global shared rational-valued variables.

IMITATOR answers variants of the following problem:

figure c

IMITATOR answers this problem by synthesizing sets of parameter valuations in the form of a finite disjunction of linear constraints over the parameters.

IMITATOR is a command-line only tool; its input is text-based (partially inspired by HyTech syntax [41]) and is “human-readable”, different from, XML. IMITATOR produces standardized result files (that can be possibly parsed from external tools), and can produce graphical outputs, such as in Fig. 1.

Fig. 1.
figure 1

Examples of graphical outputs

Full size image

The expressive power ( ease to write a complicated model in a compact manner) of the tool has been largely improved since IMITATOR 2.5 [17], and IMITATOR is now a parametric timed model checker taking as inputs a model and a property, implementing various synthesis algorithms.

2 An Expressive Input Language

Parametric Timed Automata (PTAs). Timed automata (TAs) [3] extend finite-state automata with clocks, real-valued variables evolving at the same rate 1, that can be compared to integers along edges (“guards”) or within locations (“invariants”). Clocks can be reset (to 0) along transitions. PTAs extend TAs with (timing) parameters, unknown rational-valued constants [5].

Example 1

In the model in Fig. 2 (that goes beyond the syntax of PTAs, see Example 2), there are four locations, depicted as rounded rectangles. Invariants are depicted using dotted rectangles. In the invariant of location  , clock  is compared to parameter . The guard of the transition from to compares clock  to ; this clock  is reset to 0 along this transition.

IMITATOR Parametric Timed Automata (IPTAs). IMITATOR takes as input models described as networks of IMITATOR parametric timed automata (IPTAs). IPTAs extend PTAs with a set of useful features, described in the following.

Global Rational-Valued Variables. Global variables (called “discrete”) can be defined, and are part of the discrete part of a state, together with locations (and different from clocks and parameters that are part of the continuous part). Global variables in IMITATOR are exact rationals, following exact arithmetics (as opposed to, floating-point arithmetic that can accumulate errors and lead to faulty assertions). Exact rationals are encoded in IMITATOR using the GNU MP library. Such discrete variables can be updated along transitions, and can also be part of the clock guards and invariants; in fact, virtually any linear expression over clocks, parameters and discrete variables can be used in guards, invariants and updates. Non-linear arithmetic expressions over sole discrete variables are allowed too.

Automata Synchronization. IPTAs can be synchronized together on shared actions, or by reading shared variables. All variables (clocks, parameters, discrete) are potentially global in IMITATOR. This allows users to define models component by component.

Arbitrary Flows. Since version 3.0, IMITATOR supports arbitrary (constant) flows for clocks; this way, clocks do not necessarily evolve at the same time, and can encode different concepts from only time: temperature, amount of completion, continuous cost... Their value can increase or decrease at any predefined rate in each location, and can become negative. In that sense, IMITATOR’s clocks are closer to continuous variables (as in hybrid automata) rather than TAs’ clocks; nevertheless, we keep the name clock for sake of backward-compatibility. This makes IMITATOR support a parametric extension of multi-rate automata [2]. This notably includes stopwatches, where clocks can have a 1- or 0-rate [36].

Additional Syntax Improvements. Beyond the aforementioned increase of the syntactic expressive power, the syntax was enhanced with accepting locations (that can be used in properties), global constants, “if... then... else” conditions in updates, and with the ability to include model fragments from different files (new syntax #include(modelpart.imi)). Several simplifications were made to the syntax to keep it “human-readable”. For example, location of Fig. 2 is written in IMITATOR syntax as follows:

figure m

Translations. Finally, translations of the model are available to other model checkers such as HyTech [41] and Uppaal [42] (in both cases, not all features can be translated since some of the features of IMITATOR do not exist in the target tool, Uppaal does not support parameters nor complex linear constraints over clocks (only “diagonal”)). Graphical translations of the model are also available to JPEG, PDF and formats.

Fig. 2.
figure 2

An IPTA example: writing papers and drinking coffee

Full size image

Example 2

Consider the IPTA in Fig. 2, modeling a researcher writing papers. The model features two clocks (measuring the time when needing a coffee) and (measuring the amount of work done on a given paper), both initially 0. Their rate is always 1, unless otherwise specified ( in ). Initially, the researcher is working (location ) on a paper, requiring an amount of work . When the paper is completed (guard ), the IPTA moves to location . From there, at any time, the researcher can start working on a new paper (transition back to , updating and ).

Alternatively, after at least a certain time (guard ), the researcher may need a coffee; this action can only be taken until a maximum number of coffees have been drunk for this paper (), where is a discrete global variable recording the number of coffees drunk while working on the current paper. When drinking a coffee (location ), the work is obviously not progressing (). Drinking a coffee takes exactly time units (guard back to location ). Observe that, from the second paper onwards (transition labeled with ), the researcher is already half-way of her/his need for a coffee (parametric update  [22]).

Also, whenever 80% of the work is done (guard ), the researcher may work twice as fast (location , with a rate 2 for clock ). In that case, (s)he needs a coffee faster too ().

All three durations , and are timing parameters. We fix their parameter domains as follows: and . The maximum number of coffees is also a parameter; observe that it is (only) compared to the discrete variable , and therefore can be seen as a “discrete parameter”—which is allowed by the liberal syntax of IMITATOR.

The example in Fig. 2 could not be modeled with Uppaal due to the presence of timing parameters, stopwatches, multi-rate clocks and non-0 update. It may be modeled using HyTech; however, most algorithms implemented in IMITATOR (even the most basic ones, such as liveness synthesis) do not exist in HyTech, as HyTech mainly focuses on basic state space computation.

3 A Variety of Synthesis Algorithms

The formalism of networks of IPTAs is “highly undecidable” for most problems. Indeed, while several problems are decidable for timed automata (notably the reachability [3]), most interesting problems become undecidable in the presence of timing parameters [5, 8] , notably when such parameters are unbounded [35]. On top of this, multi-rate automata together with linear constraints over the clocks also yield undecidability [2]. Finally, the mere use of stopwatches, even without the aforementioned extensions, brings undecidability [36]. Also note that, in contrast to several existing model checkers, IMITATOR offers the use of unbounded rational variables, therefore with an infinite domain. For all these reasons, it is always possible to find examples of IPTAs for which the algorithms implemented in IMITATOR would not terminate with an exact (sound and complete) result. The rational behind IMITATOR is therefore to follow a “best-effort” approach, by:

  • using aggressive optimizations and abstractions (  [11, 19, 45]), leading to termination for most case studies in practice;

  • outputting over- or under-approximated results, the set of synthesized parameter valuations may be larger or smaller than the exact result.

IMITATOR outputs a standardized result (in a text file), that contains the synthesized constraint with a set of information, and notably the validity of the constraint, whether the set of valuations is exact (sound and complete), possibly over-approximated, possibly under-approximated, or potentially invalid when both under-approximating and over-approximating heuristics were used. By default, IMITATOR attempts to synthesize an exact result; only when some specific options are used ( a limit on the number of states explored, or on the computation time), approximations may be used. These approximations are conservative for most algorithms; for example, if an approximation is used for safety synthesis, then the result will be under-approximated ( the system is safe for all synthesized valuations—even though some more safe valuations may exist).

IMITATOR offers two main classes of synthesis: i) Witness (or counter-example), which attempts to exhibit at least one parameter valuation satisfying the property; often, IMITATOR still outputs a symbolic set of valuations ( a linear constraint over the parameters), but stops the analysis as soon as one such set is found. ii) Normal synthesis, where IMITATOR attempts to synthesize all parameter valuations satisfying the property.

Properties include reachability (denoted by “EF”, following the TCTL syntax), safety (denoted by “AGnot”), liveness, deadlock-freeness, robustness, and some others.

Throughout this section, we exemplify the main synthesis algorithms of IMITATOR on Example 2.Footnote 1 All the results synthesized in the following are exact (sound and complete), unless otherwise specified.

Safety. A first algorithm of IMITATOR is safety synthesis, synthesizing parameter valuations for which a discrete state (location and/or valuation of the discrete variables) is unreachable for all runs. For example, one synthesize the valuations for which it is impossible to drink any coffee, it is impossible to reach the location of the “researcher” automaton of Fig. 2.

figure ah
figure ai

Let us explain this result. The first disjunct is trivial: if the researcher is not allowed to drink any coffee (), the transition to (guarded by “”) can never be taken. The second disjunct is, despite the relative simplicity of this model, less trivial: assume for illustration that and , and let us show that the researcher is still able to start drinking a coffee in this situation. After the first paper completion (action ), we have and . After one time unit in location ( and ), the researcher moves to , and can immediately move to (guard is now satisfied). This scenario, that can be seen on the parametric state space output by IMITATOR (see Fig. 1a), is also possible for larger values of . This explains the strict inequality .

Reachability. Reachability can be seen as the opposite of safety, the goal is to synthesize parameter valuations for which a discrete state is reachable for at least one run. For example, one can ask for the valuations for which it is possible to drink at least one coffee:

figure ao

The result is , which is obviously the complement of the result synthesized for the aforementioned safety property.

One can also synthesize valuations for which it is possible to drink at least five coffees while working on some article ( ).

figure aq

The result is .

Minimum-Time Reachability. Minimal-time synthesis [12] aims at synthesizing parameter valuations minimizing the time needed to reach a discrete state. Here, we can ask for the valuations for which it is possible to finish an article after drinking at least 2 coffees:

figure ar

The result is and the minimal time is 2. That is, any of these valuations guarantee the reachability of a state where the researcher has drunk 2 coffees, and the minimum time is 2 (recall that ).

Optimal Parameter Reachability. One can ask here for the valuations for which the value of a given parameter is minimized or maximized when reaching a given state. Let us ask for the valuations minimizing the value of when finishing a paper after drinking (at least) 3 coffees.

figure as

The result is . Observe that is not involved in this constraint (contrarily to minimum-time synthesis); indeed, the time spent in drinking coffee does not impact the total duration of the work (), as the progress of clock  is stopped in  .

Parametric Deadlock Freeness. Deadlocks are states in which no discrete action can be taken, and time cannot elapse (“timelock”). Such situations may denote ill-formed models. IMITATOR offers an algorithm [7] synthesizing parameter valuations for which the model is deadlock-free. In case of “early termination” (predefined bound on the depth of the state space or on the computation time), a backward procedure synthesizes a subset of correct (deadlock-free) valuations.

figure au

For this property, the analysis does not terminate, as the state space is infinite (unbounded rational-valued parameters, unbounded variable ) and IMITATOR needs to explore it as a whole to deduce deadlock-freeness for our example.

Adding a bound on the depth of the state space (option -depth-limit 40) yields termination, with a pair of constraints: an under-approximated positive constraint ( valuations that are guaranteed to be deadlock-free) , and an over-approximated negative constraint ( valuations that might be deadlocked) . Observe that both constraints are complementary, IMITATOR is sure that the former set is deadlock-free, and is not sure that the latter set contains deadlocks. (Note that, in fact, the model is very likely to be deadlock-free for all valuations, even though IMITATOR is not able to show it.)

Liveness Synthesis. A new feature of IMITATOR 3 is cycle synthesis, parameter valuations for which there exists an infinite run, possibly passing infinitely often by a given discrete state (Büchi condition). IMITATOR uses by default an original algorithm by Laure Petrucci and Jaco van de Pol based on NDFS extended with parametric subsumption and pruning [45] (other algorithms, such as BFS, are also available [11]). In our running example , one can ask for the valuations for which the researcher infinitely often writes papers after drinking (at least) 3 coffees for each of them.

figure az

The result is .

Robustness. Inherited from earlier versions of IMITATOR, one can apply the inverse method [29] (also called trace preservation [21]) that, given a reference parameter valuation, synthesizes the set of parameter valuations for which the set of “traces” (discrete behaviors, abstracting time information away) is the same as for this reference valuation.

figure bb

The result is: . The synthesized constraint can be seen as a characterization of the robustness of the original parameter valuation.

Synthesis Using Patterns. Another way to specify properties is to use a set of predefined observer patterns [6, 28]. Observer patterns are translated into observer automata (called reachability testing in [1]), and their correctness reduces to reachability. This procedure is transparent to the user, (s)he only needs to specify the pattern and IMITATOR takes care of the translation and synthesis. IMITATOR patterns specify the order between actions, extended with (possibly parametric) timing information. The syntax is detailed in the user manual, and the semantics is given in [6].

For example, one can synthesize the set of valuations such that, every time the researcher restarts a new article, (s)he completes it within 5 time units. That is, every occurrence of the action must be followed within (at most) 5 time units by the action.

figure bf

A part of the valuations set is: .

A graphical 2D representation projected onto and (setting and ) is given in Fig. 1b.

Other Algorithms. IMITATOR features a number of additional algorithms, including i) non-Zeno infinite run synthesis [27], ii) behavioral cartography [16] that partitions the parameter space into tiles where the discrete behavior is uniform, or iii) parametric reachability preservation, that takes as input a discrete state and a reference valuation, and synthesizes valuations for which this discrete state is reachable iff it is reachable for the reference valuation [25]. The two latter algorithms can be distributed over a cluster, showing interesting results, and can be used to perform reachability synthesis while being faster than the normal reachability synthesis algorithm for some benchmarks [14, 15]. Finally, compositional verification for a subclass of IPTAs (a parametric extension of event-recording automata [4]) was proposed in [24].

4 Distribution

IMITATOR is distributed under the terms of the GNU General Public License. Its source code is therefore publicly available, and benefited from several contributors’ additions. IMITATOR is available onlineFootnote 2, together with its documentation, and a benchmarks library [26].

IMITATOR depends on several libraries. Notably, the core engine relies on the Parma Polyhedra Library (PPL) [32] for the computation of symbolic states. As a consequence, IMITATOR can be cumbersome to compile. For this reason, standalone binaries are available for all Linux-like systems. A Docker versionFootnote 3 (made by Jaime Arias) and a prototype Web serviceFootnote 4 are available too.

An extensive user manual, explaining all algorithms and providing users with a full description of the input syntax for models and properties, is available [10].

5 A Selection of Applications

IMITATOR was applied to a variety of both academic and industrial case studies over the last few years. These applications range within several domains, including real-time systems, testing and monitoring, cybersecurity, or hardware verification. One can cite:

  • the parametric verification of an asynchronous memory circuit by ST-Microelectronics (from a model described in [37]),

  • verification of parametric scheduling problems by Astrium Space Transportation [40] and ArianeGroup SAS [13],

  • analysis of music scores [38],

  • verifying the multi-processor image processing system of an unmanned aerial aircraft with uncertain periods, as a benchmark made public by Thales [46],

  • parametric pattern matching and monitoring of logs from the automative industry [20],

  • synthesis of timing/cost parameters in attack-fault trees [23, 31],

  • testing product lines using parametric constraints [44],

  • verification of an industrial asynchronous leader election algorithm by Thales using IMITATOR combined with abstractions [18],

  • performing parametric opacity analyses for timed automata [30], and

  • synthesis of parameter valuations guaranteeing liveness properties for the Bounded Retransmission Protocol [11].

6 Related Tools

HyTech [41] was the first model checker for hybrid systems (a class of formalisms beyond PTAs), including parameters; it is not maintained anymore.

Uppaal [42] is a state-of-the-art tool for modeling and verifying systems modeled as networks of timed automata and extended with variables and data structures; while Uppaal became a major tool for model checking timed automata, it does not support parametric verification, and the use of clocks is restricted to comparing one clock with one constant or with another clock, while IMITATOR allows a liberal syntax based on polyhedra.

RomÉo [43] performs parameter synthesis for parametric time Petri nets with inhibitor arcs  [47].

While RomÉo shares similarities with IMITATOR, it does not support (extensions of) timed automata, and notably not multi-rate clocks.

SpaceEx [39] is a tool for verifying hybrid systems. It is not specifically dedicated to parameter synthesis, and mainly targets safety and reachability, in contrast to IMITATOR that proposes multiple synthesis algorithms.

IMITATOR’s input syntax also shares some similarities with that of PHAVerLite [33] (a fork of PHAVer and predecessor of SpaceEx, that uses PPLite [34] instead of PPL [32]), coming from the fact that both IMITATOR and PHAVerLite originate from the HyTech syntax.

7 Perspectives

To gain some further speed for models that require less expressiveness (notably no strict inequality nor rational-valued variables), offering to replace PPL [32] with PPLite [34], or using standard 32-bit integers instead of GNU MP rationals is on our agenda.