Parameters Beyond Decidability

. Real-time systems are notoriously hard to verify due to non-determinism, concurrency and timing constraints. When timing constants are uncertain (in early the design phase, or due to slight variations of the timing bounds), timed model checking techniques may not be satisfactory. In contrast, parametric timed model checking synthe-sizes timing values ensuring correctness. IMITATOR takes as input an extension of parametric timed automata (PTAs), a powerful formalism to formally verify critical real-time systems. IMITATOR extends PTAs with multi-rate clocks, global rational-valued variables and a set of additional useful features. We describe here the new features and algorithms oﬀered by IMITATOR 3, that moved along the years from a simple prototype dedicated to robustness analysis to a standalone parametric model checker for timed systems.


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, i.e., 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: Parameter synthesis problem: Input: A network of IPTAs A and a specification ϕ Problem: Synthesize the set of parameter valuations for which A satisfies ϕ 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, e.g., XML. IMITATOR produces standardized result files (that can be possibly parsed from external tools), and can produce graphical outputs, such as in Fig. 1.
The expressive power (i.e., 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. 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, i.e., 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 working, clock x is compared to parameter p total . The guard of the transition from coffee to working compares clock t to p coffee ; this clock t 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, e.g., 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 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, e.g., 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 L A T E X formats. Fig. 2, modeling a researcher writing papers. The model features two clocks t (measuring the time when needing a coffee) and x (measuring the amount of work done on a given paper), both initially 0. Their rate is always 1, unless otherwise specified (e.g., in workingFast). Initially, the researcher is working (location working) on a paper, requiring an amount of work p total . When the paper is completed (guard x = p total ), the IPTA moves to location finished. From there, at any time, the researcher can start working on a new paper (transition back to working, updating x and t).

Example 2. Consider the IPTA in
Alternatively, after at least a certain time (guard t ≥ p need ), the researcher may need a coffee; this action can only be taken until a maximum number of coffees have been drunk for this paper (nb ≤ max − 1), where nb is a discrete global variable recording the number of coffees drunk while working on the current paper. When drinking a coffee (location coffee), the work is obviously not progressing (ẋ = 0). Drinking a coffee takes exactly p coffee time units (guard t = p coffee back to location working). Observe that, from the second paper onwards (transition labeled with restart), the researcher is already half-way of her/his need for a coffee (parametric update t ← 0.5 × p need [22]).
Also, whenever 80% of the work is done (guard x ≥ 0.8×p total ), the researcher may work twice as fast (location workingFast, with a rate 2 for clock x). In that case, (s)he needs a coffee faster too (0.6 × p need ).
All three durations p coffee , p need and p total are timing parameters. We fix their parameter domains as follows: p coffee , p total ∈ [0, ∞) and p need ∈ [1, ∞). The maximum number of coffees max ∈ [0, ∞) is also a parameter; observe that it is (only) compared to the discrete variable nb, 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.

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 (e.g., [11,19,45]), leading to termination for most case studies in practice; -outputting over-or under-approximated results, i.e., 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, i.e., whether the set of valuations is exact (sound and complete), possibly over-approximated, possibly under-approximated, or potentially invalid i.e., 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 (e.g., 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 (i.e., 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 counterexample), which attempts to exhibit at least one parameter valuation satisfying the property; often, IMITATOR still outputs a symbolic set of valuations (i.e., 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.
Throughout this section, we exemplify the main synthesis algorithms of IMI-TATOR on Example 2. 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, i.e., 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, i.e., it is impossible to reach the coffee location of the "researcher" automaton of Fig. 2.

# synth AGnot ( loc [ researcher ] = coffee )
The result is: max ∈ [0, 1) ∨ max ≥ 1 ∧ p total < p need 10 Let us explain this result. The first disjunct is trivial: if the researcher is not allowed to drink any coffee (max < 1), the transition to coffee (guarded by "nb ≤ max − 1") can never be taken. The second disjunct is, despite the relative simplicity of this model, less trivial: assume for illustration that p need = 10 and p total = 1, and let us show that the researcher is still able to start drinking a coffee in this situation. After the first paper completion (action restart), we have x ← 0 and t ← 5. After one time unit in location working (x = 1 and t = 6), the researcher moves to workingFast, and can immediately move to coffee (guard t ≥ 0.6 × p need 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 p total . This explains the strict inequality p total < p need 10 .
1 All finishing executions for our example using IMITATOR 3.0 "Cheese" ea560fd on a Dell XPS 13 7390 Intel Core TM i7-10510U CPU @ 1.80 GHz running Linux Mint 20 Ulyana terminate within < 1 s. All examples and results can be found at [9].
Reachability. Reachability can be seen as the opposite of safety, i.e., 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:

# synth EF ( loc [ researcher ] = coffee )
The result is max ≥ 1 ∧ p total ≥ p need 10 , 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 (i.e., nb ≥ 5).

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:

# synth EFtmin ( loc [ researcher ] = finished & nb >= 2)
The result is p total 2 + p need + 2 × p coffee ≤ 2 ∧ max ≥ 2 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 p need ∈ [1, ∞)).
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 p total when finishing a paper after drinking (at least) 3 coffees.

# synth EFpmin ( loc [ researcher ] = finished & nb >= 3, pTotal )
The result is max ≥ 3 ∧ p total = 2.1 ∧ p need = 1. Observe that p coffee 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 (p total ), as the progress of clock x is stopped in coffee.
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.

# synth DeadlockFree
For this property, the analysis does not terminate, as the state space is infinite (unbounded rational-valued parameters, unbounded variable nb) 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 (i.e., valuations that are guaranteed to be deadlock-free) max < 16 ∨ (max ≥ 16 ∧ p total < 27 2 p need ), and an over-approximated negative constraint (i.e., valuations that might be deadlocked) max ≥ 16 ∧ p total ≥ 27 2 p need . Observe that both constraints are complementary, i.e., 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, i.e., 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.
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, i.e., abstracting time information away) is the same as for this reference valuation.
# synth TracePreservation ( pTotal = 10 , pNeed = 5, pCoffee = 3, max = 3) 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, i.e., (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 restart action must be followed within (at most) 5 time units by the done action.

# synth pattern ( everytime restart then eventually done within 5)
A part of the valuations set is: max ≥ 6 ∧ 5 − 6 × p coffee ≥ p total ≥ 4.7 × p need .
A graphical 2D representation projected onto p total and p coffee (setting p need = 2 and max = 3) 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].

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 online 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 version 3 (made by Jaime Arias) and a prototype Web service 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].

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].

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.
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 PHAVer-Lite [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.

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.