MightyPPL: Verification Tool for MITPPL
- MightyPPL is a verification tool for MITPPL, a decidable logic featuring future, past, and counting modalities interpreted under pointwise semantics.
- It employs a compositional translation approach by introducing propositional triggers and tester automata to convert MITPPL specifications into standard timed automata.
- The tool uses symbolic encoding and sequentialisation to mitigate state explosion, achieving significant performance improvements in finite and infinite timed-word verification.
Searching arXiv for MightyPPL and related MITL verification work. MightyPPL is a tool for the complete verification of dense-time linear-time specifications written in MITPPL—Metric Interval Temporal Logic with Past and Pnueli modalities—under the pointwise (event-based) semantics. It introduces a translation from MITPPL formulae over the pointwise semantics into standard timed automata, thereby enabling satisfiability and model checking over both finite and infinite timed words. Its stated goals are to support the full decidable logic MITPPL, to reduce verification to timed-regular language emptiness for mature back-ends, and to incorporate performance optimisations, notably a symbolic encoding of Boolean synchronisation and a sequentialisation-based symmetry reduction (Ho et al., 1 Oct 2025).
1. Verification problem and logical scope
Metric Interval Temporal Logic (MITL) is presented as a popular formalism for specifying properties of reactive systems with timing constraints. The stated motivation for MightyPPL is that existing approaches to using MITL in verification tasks either support only limited fragments of the logic or allow for only incomplete verification (Ho et al., 1 Oct 2025).
Within that setting, MightyPPL targets MITPPL, described as the full decidable logic containing future MITL, past operators, and Pnueli “counting” modalities. The tool is explicitly designed for both finite and infinite timed words. It reduces satisfiability and model checking to language emptiness of standard timed automata, rather than introducing a new automaton formalism.
A central scope condition is semantic: MightyPPL operates under the pointwise semantics. This means that formulae are interpreted at event positions in timed words. A common source of confusion in timed-temporal-logics is to conflate event-based and non-event-based interpretations; here the semantics are explicitly pointwise, with truth evaluated at positions of a timed word .
2. MITPPL syntax and pointwise semantics
Let $\AP$ be a finite set of atomic propositions and let non-singular intervals be given by
MITPPL-formulae over $\AP$ are given by
Here and are until and since restricted to , while and 0 are forward and backward Pnueli modalities (Ho et al., 1 Oct 2025).
Other operators are standard or derived; for example,
1
A timed word is
2
with 3 and non-decreasing 4. The notation 5 means that 6 holds at event 7. The key semantic clauses are:
8
These clauses make the role of the Pnueli modalities precise: they require the existence of ordered future or past positions within a common interval 9, each satisfying the corresponding argument formula. This provides the “counting” structure referred to in the tool description.
3. Compositional translation to timed automata
MightyPPL implements a compositional reduction from MITPPL to standard Alur–Dill timed automata. The construction proceeds by trigger introduction, tester-automaton generation, and synchronous composition (Ho et al., 1 Oct 2025).
For each temporal subformula $\AP$0, MightyPPL introduces a fresh propositional trigger $\AP$1 marking the “activation” positions of $\AP$2. The original formula is transformed into a propositional skeleton in which each temporal subformula is replaced by its trigger, and this is conjoined with obligations of the form
$\AP$3
For every such obligation, MightyPPL constructs a small tester automaton $\AP$4 that accepts exactly those timed words satisfying that obligation. The conjunction of obligations is then reduced to the synchronous product
$\AP$5
Its emptiness or non-emptiness corresponds to model checking or satisfiability.
Several tester constructions are singled out. For $\AP$6, one clock $\AP$7 and three locations $\AP$8 suffice; in $\AP$9, the automaton resets 0 on trigger 1 and enforces 2 until either 3 or 4 violates the interval. For the forward Pnueli modality 5, 6 “identical” component timed automata, each with one clock, track the 7 sequential obligations 8–9 within $\AP$0. For general $\AP$1 intervals, the construction avoids a monolithic blow-up by decomposing the obligation into parallel predictors that guess candidate positions of $\AP$2 and verify either interval membership for all outstanding obligations or chaining from earlier $\AP$3 events separated by $\AP$4.
The stated correctness argument proves
$\AP$5
by showing that each obligation automaton accepts exactly the models of its corresponding obligation, that the product meets all obligations simultaneously, and that trigger embedding preserves semantics.
4. Symbolic encoding and sequentialisation
Two performance optimisations are central to MightyPPL: symbolic encoding of transitions and sequentialisation as a symmetry reduction (Ho et al., 1 Oct 2025).
In the symbolic encoding, atomic propositions and Boolean trigger combinations are represented using a small set of fresh integer or bit-vector variables instead of explicit subsets of $\AP$6. Synchronisation between component timed automata is performed via a cascade of symbolic assignments or, in flattened mode, via BDD-based conjoining of guards. The stated purpose is to avoid the exponential blow-up in alphabet size and transition count inherent in naive cross-product encodings.
Sequentialisation addresses the case in which multiple obligations of the same type must be tracked in parallel, as in general-interval testers. The naive product of $\AP$7 identical components has $\AP$8 reachable location combinations. MightyPPL instead introduces fresh allocation variables $\AP$9 enforcing a circular sequential order in which obligations are handled, and restricts the product so that at most one component timed automaton is active in a non-trivial state while the indices of active components form a consecutive block.
The reported consequence is an exponential reduction in reachable discrete states. The sequentialisation lemma states: if 0 is the maximum number of overlapping obligations in a subformula with interval 1, then the sequentialised product has at most 2 reachable locations, instead of 3, with the same 4 clocks. The asymptotic drop is therefore from 5 to 6.
This suggests that the principal scalability gains are aimed at the discrete control-state explosion of general-interval constructions rather than clock-count reduction, since the clock bound remains 7.
5. Architecture, output forms, and verification back-ends
MightyPPL is organised as a front-end, a core translation layer, optional flattening or on-the-fly processing, and several back-end drivers (Ho et al., 1 Oct 2025).
The Front-End reads MITPPL, builds the obligation list, and calls Translate. The Core implements each ConstructTester(…) for all MITPPL modalities, including past, Pnueli, and 8 handling with sequentialisation. The tool can generate either a network of timed automata or a single timed automaton that is language-equivalent and compatible with multiple verification back-ends.
Two output/processing regimes are distinguished. In component mode, each obligation timed automaton is emitted separately in TChecker or Uppaal format. In flattened mode, MightyPPL computes a symbolic forward-reachability, with optional backward-pruning of unreachable Büchi states, to produce one monolithic timed automaton.
The reported back-end integrations are as follows:
- Uppaal via
verifytafor finite-word only, or via the Opal front-end plus LTSmin for infinite-word. - TChecker for both finite- and infinite-word emptiness.
- LTSmin with Opal for Uppaal format, with a user-selectable number of threads 9, and explicit support for multi-core model checking.
- Built-in Fixpoint as a bounded-stack, backward-fixpoint emptiness checker for general timed-automata Büchi emptiness, available for regression.
A common misconception would be to treat all back-ends as interchangeable with respect to word models. The integration details instead distinguish finite-word-only and finite/infinite-word configurations.
6. Empirical evaluation and reported behaviour
The evaluation covers parametrised MITL fragments, Acacia-Bonsai LTL benchmarks lifted to MITL, specification debugging, robotic mission patterns, a food-delivery case study, timed lamp and Fischer protocol instances, and pinwheel scheduling (Ho et al., 1 Oct 2025).
| Benchmark family | Reported configuration | Reported observation |
|---|---|---|
| Parametrised MITL fragments | LTSmin and Uppaal back-ends | symbolic encodings yield up to two orders of magnitude speed-up |
| Acacia-Bonsai LTL benchmarks | TChecker and built-in fixpoint | component mode is 5–10× faster than flattened mode or brute-force |
| Specification debugging | component mode + TChecker emptiness | solved most unsatisfiable checks in 0 |
| Robotic Mission Patterns | component mode | all solved in 1 |
| Food-Delivery | TChecker flatten mode; fixpoint | 2–3; up to 4 on the hardest instances |
| Timed Lamp and Fischer Protocol | TChecker flatten mode; fixpoint | lamps in 5; fixpoint times out on nested Pnueli cases |
| Pinwheel Scheduling | LTSmin; TChecker flatten mode | comparable single-threaded behaviour; LTSmin scales almost linearly with up to 16 cores |
The comparison against the state-of-the-art MightyL is reported on parametrised MITL fragments, with symbolic encodings yielding up to two orders of magnitude speed-up across LTSmin and Uppaal back-ends. On Acacia-Bonsai formulae, component mode is reported to be 5–10× faster than flattened mode or brute-force. In specification debugging, component mode with TChecker emptiness solved most unsatisfiable checks in less than 6, whereas flattened or brute-force configurations often time out.
The case studies also differentiate the operational envelopes of the available workflows. For robotic mission patterns using Pnueli and past-avoidance patterns of length up to 7, all instances were solved in less than 7 in component mode. In the food-delivery benchmark, model checking a 5-location weighted graph against combined future, past, and Pnueli constraints took 8–9 in TChecker flatten mode, while the fixpoint engine required up to 0 on the hardest instances. For timed-lamp instances, TChecker flatten mode solved typical lamps in less than 1, while the fixpoint engine timed out on nested Pnueli cases; Fischer with 4 processes and deadlines was solved in 2–3, matching Uppaal.
The reported sample performance table also illustrates that no single configuration dominates every instance. For 4, Flat+TCK is listed at 5, Comp+TCK at 6, Fixpt at 7, LTSmin(1) at 8, and LTSmin(16) at 9. For 0, Comp+TCK is 1, Flat+TCK is 2, and Fixpt is 3. For 4, Comp+TCK is 5, Flat+TCK is 6, LTSmin(1) is 7, and LTSmin(16) is 8.
Taken together, the reported results position MightyPPL as a tool whose contribution is not only logical expressiveness—future MITL, past operators, and Pnueli modalities under pointwise semantics—but also the ability to emit standard timed automata for established verification engines while mitigating classical blow-ups through symbolic encoding and sequentialisation.