Explainable Online Monitoring of Metric Temporal Logic

. Runtime monitors analyze system execution traces for policy compliance. Monitors for propositional specification languages, such as metric temporal logic (MTL), produce Boolean verdicts denoting whether the policy is satisfied or violated at a given point in the trace. Given a sufficiently complex policy, it can be difficult for the monitor’s user to understand how the monitor arrived at its verdict. We develop an MTL monitor that outputs verdicts capturing why the policy was satisfied or violated. Our verdicts are proof trees in a sound and complete proof sys-tem that we design. We demonstrate that such verdicts can serve as explanations for end users by augmenting our monitor with a graphical interface for the interactive exploration of proof trees. As a second application, our verdicts serve as certificates in a formally verified checker we develop using the Isabelle proof assistant.


Introduction
In runtime verification, monitoring is the task of analyzing an event stream produced by a running system for violations of specified policies.An online monitor for a propositional policy specification language, such as metric temporal logic (MTL), consumes the stream event-wise and gradually produces a stream of Boolean verdicts denoting the policy's satisfaction or violation at every point in the event stream.MTL monitors [3,19,24,27,33] use complex algorithms, whose correctness is not obvious, to efficiently arrive at the verdicts.Yet, users must rely on the algorithms being correct and correctly implemented, as the computed verdicts carry no information as to why the policy is satisfied or violated.
The two main approaches to increase the reliability of complex algorithm implementations are verification and certification.Formal verification using proof assistants or software verifiers is laborious and while it provides an ultimate level of trust, the user of a verified tool still gains no insight into why a specific, surely correct verdict was produced.In contrast, certification can yield both trust (especially when the certificate checker is itself formally verified) and insight, provided that the certificate is not only machine-checkable but also human-understandable.
In this paper, we develop a certification approach to MTL monitoring: instead of Boolean verdicts, we require the monitor to produce checkable and understandable certificates.To this end, we develop a sound and complete local proof system ( §2) for the satisfaction and violation of MTL policies.Following Cini and Francalanza [15], local means that a proof denotes the policy satisfaction on a given stream of events and not general MTL satisfiability (for any stream).Our proof system is an adaptation of Basin et al.'s [4] local proof system for LTL satisfiability on lasso words to MTL with past and bounded future temporal operators.A core design choice for our proof system was to remain close to the MTL semantics and thus to be understandable for users who reason about policies in terms of the semantics.Therefore, proof trees in our proof system, or rather their compact representation as proof objects ( §3), serve as understandable certificates.
With the certificate format in place, we devise an algorithm that computes minimal (in terms of size) proof objects ( §4).We implement the algorithm in OCaml and augment it with an interactive web application 1 to visualize and explore the computed proof objects ( §5).Independently, we prove the soundness and completeness of our proof system and formally verify a proof checker using the Isabelle/HOL proof assistant.We extract OCaml code from this formalization and use it to check the correctness of the verdicts produced by our unverified algorithm.To ensure that our correct verdicts are also minimal, we develop a second formally verified but less efficient monitoring algorithm in Isabelle, which we use to compute the minimal proof object size when testing our unverified algorithm.
Finally, we demonstrate how our work provides explainable monitoring output through several examples ( §6) and empirically evaluate our algorithm's performance in comparison to other monitors ( §7).In summary, we make the following contributions: -We develop a sound and complete local proof system for past and bounded future MTL that follows closely the semantics of the MTL operators.-We develop and empirically evaluate an efficient algorithm to compute size-minimal proof objects representing proof trees in our proof system.-We implement our algorithm in a new, publicly available monitoring tool EXPLANA-TOR2 [22] that includes a web front end and a formally verified proof object checker.
Related Work.We take the work by Basin et al. [4] on optimal proofs for LTL on lasso words as our starting point but change the setting from lasso words to streams of time-stamped events and the logic from LTL to MTL.Moreover, Basin et al. considered the offline path checking problem, whereas we tackle online monitoring here.Parts of the work presented here are also described in two B.Sc. theses by Yuan [39] and Herasimau [16].Yuan developed the MTL proof system we present here as well as a monitoring algorithm for computing optimal proofs based on dynamic programming (similarly to Basin et al.'s algorithm [4]).Herasimau formalized Yuan's development in Isabelle/HOL.We use his work as the basis for our formally verified checker.Here, we present a different algorithm that resembles the algorithms used by state-of-the-art monitors for metric first-order temporal logic [5,29], which perform much better than dynamic programming algorithms for non-trivial metric interval bounds.
Basin et al.'s approach [4] is parameterized by a comparison relation on proof objects that specifies what the algorithm should optimize for.Yuan [39] discovers a flaw in the correctness claim for Basin et al.'s algorithm and corrects it by further restricting the Fig. 1: Semantics of MTL for a fixed trace ρ = ⟨(π i , τ i )⟩ i∈N supported comparisons.Herasimau [16] relaxes Yuan's requirements while formally verifying the correctness statement.Our algorithm minimizes the computed proof objects' size as this both simplifies the presentation and caters for a more efficient algorithm.
Formal verification of monitors is a timely topic.Some verified monitors were developed recently using proof assistants, e.g., VeriMon [29] and Vydra [28] in Isabelle and lattice-mtl [8] in Coq.Others leveraged SMT technology to increase their trustworthiness [12,14].To the best of our knowledge, we present the first verified checker for an online monitor's output, even though verified certifiers are standard practice in other areas such as distributed systems [35], model checking [37,38], and SAT solving [11,21].
Several monitors visualize their output [1,2,7,18,25,30]; some of these even present visually separate verdicts for different parts of the policy.Our work takes inspiration from these approaches, but goes deeper: our minimal proof trees characterize precisely how the verdicts for the different parts compose to a verdict for the overall policy.
Our work follows the "proof trees as explanations" paradigm and thereby joins a series of works on LTL [4,15,32], CFTL [13], and CTL [9].Of these only Basin et al. [4] supports past operators and none support metric intervals.Two of the above works [9,15] use proof systems based on the unrolling equations for temporal operators instead of the operator's semantics, which we believe is suboptimal for understandability: users think about the operators in terms of their semantics and not in terms of unrolling equations.
Outside of the realm of temporal logics one can find the "proof trees as explanations" paradigm in regular expression matching [31] and in the database community [10].Metric Temporal Logic.We briefly recall MTL's syntax and point-based semantics [6].MTL formulas are built from atomic propositions (a, b, c, . ..) via Boolean (∧, ∨, ¬) and metric temporal operators (previous I , next I , since S I , until U I ), where I = [l, r] is a non-empty interval of natural numbers with l ∈ N and r ∈ N ∪ {∞}.We omit the interval when l = 0 and r = ∞.For the until operator U [l,r] , we require the interval to be bounded, i.e., r ̸ = ∞.Formulas are interpreted over streams of time-stamped events ρ = ⟨(π i , τ i )⟩ i∈N , also called traces.An event π i is a set of atomic propositions that hold at the respective time-point i. Time-stamps τ i are natural numbers that are required to be monotone (i.e., i ≤ j implies τ i ≤ τ j ) and progressing (i.e., for all τ there exists a timepoint i with τ i > τ).Note that consecutive time-points can have the same time-stamp.Figure 1 shows MTL's standard semantics for a formula φ at time-point i for a fixed trace ρ.
Fix a trace ρ = ⟨(π i , τ i )⟩ i∈N .The earliest time-point of a time-stamp τ on ρ is the smallest time-point i such that τ i ≥ τ and is denoted as ETP ρ (τ).Similarly, the latest timepoint of a time-stamp τ ≥ τ 0 on ρ is the greatest time-point i such that τ i ≤ τ and is denoted as LTP ρ (τ).Whenever the trace ρ is fixed, we will only write ETP(τ) and LTP(τ).

Local Proof System
We introduce a local proof system for monitoring MTL formulas as the least relation satisfying the rules shown in Figure 2. It contains two mutually dependent judgments: for I = [l, r], which correspond to the earliest and latest time-point within the interval I, respectively, when formulas having S I as their topmost operator are considered.In the definition of L p i (I) we take the minimum to account for consecutive time-stamps with the same value.For formulas having U I as their topmost operator, both definitions are mirrored, resulting in E f i (I) := max(i, ETP(τ i + l)) and L f i (I) := LTP(τ i + r).The semantics of the MTL operators directly corresponds to the satisfaction rules ap + , ¬ + , ∨ + L , ∨ + R , ∧ + , S + , U + , + , and + .For instance, consider two time-points j and i such that j ≤ i.The rule S + is applied whenever the time-stamp difference τ i −τ j belongs to the interval I, and there is a witness for a satisfaction proof of β in the form of j ⊢ + β together with a finite sequence of satisfaction proofs of α for all k ∈ ( j, i].The violation rules for the non-temporal operators ap − , ¬ − , ∨ − , ∧ − L , ∧ − R are dual to their satisfaction counterparts.On the other hand, the violation rules for the temporal operators I , I , S I , and U I are derived by negating and rewriting their semantics.Consider S I with I = [l, r]: The rules S − , S − ∞ , and S − <I correspond to the three disjuncts in Equation (1).We argue that these three cases intuitively represent different ways of violating a since operator.In the first disjunct, α is violated at some time-point after the interval starts and β is violated from that time-point until the interval ends.Indeed, the violation proof j ⊢ − α is enough to dismiss all previous occurrences of a satisfaction of β.Moreover, if l ̸ = 0, i.e., if the interval does not include the current time-point, then α may be violated between the interval's end and the current time-point.
The rules U − and U − ∞ correspond to the two disjuncts in Equation ( 2).In the first disjunct, β is violated from the interval start until a time-point j at which also α is violated.Symmetrically to S − , we can dismiss all satisfactions of β after j because of the violation proof j ⊢ − α.In the second disjunct, β is violated at every time-point inside the interval.
In other words, proof trees in our proof system contain all the necessary information to explain why a formula has been satisfied or violated on a given trace.A mechanically checked proof of the above statement can be found in our Isabelle formalization [22].

Proof Objects
To make proofs from our proof system explicit, we define an inductive syntax for satisfaction (sp) and violation (vp) proofs and call this representation proof objects.Proof objects allow us to easily compute with, modify and compare the size of proof trees.From now on, the term proof will be used for both proof tree and proof object.
Here, sp and vp denote finite non-empty sequences of sp and vp subproofs and sp ∅ and vp ∅ denote finite possibly empty sequences of sp and vp subproofs.We define p = sp ⊎ vp to be the disjoint union of satisfaction and violation proofs.Given a proof p ∈ p, we define V(p) to be ⊤ if p ∈ sp and ⊥ if p ∈ vp.Each constructor corresponds to a rule in our proof system.Each proof p has an associated time-point tp(p) for which it witnesses the satisfaction or violation.In some cases, tp(p) can be computed recursively from p's subproofs.For example, tp(S + (p, [q 1 , . . ., , and S − ∞ , explicitly store the associated time-points as an argument of type N because we cannot compute them from the respective subproofs.For example, tp(ap + ( j, a)) = j and tp(S − ( j, q, [p 1 , . . ., p n ])) = j.
Given a trace ρ = ⟨(π i , τ i )⟩ i∈N and a formula φ, we call a proof p valid at tp(p), denoted by p ⊢ φ, if p represents a valid proof according to the rules of our local proof system.Note that once again we leave the dependency on ρ implicit in p ⊢ φ.Formally, validity p ⊢ φ is defined recursively, checking for each constructor that the corresponding rule has been correctly applied.For example, atomic proofs are valid if the mentioned atom is (not) contained in the trace at the specified time-points: Multiple valid proofs may exist for a time-point i and formula φ as we demonstrate next.
Example 2. The proof object representing the proof tree from Example 1 is ).However, we could have argued differently, using the fact that c is violated at all time-points inside the interval.Then, S − ∞ would be used instead to construct the proof ), which is also a valid proof at tp(P 2 ) = 5.In addition, ) is another valid proof at tp(P 3 ) = 5.It is structurally identical to P 1 , but instead of using the violations of b as witnesses for time-points 3 and 4, it uses the violations of c.In fact, both b and c are violated at time-points 3 and 4, so we can use either to justify the violations of b ∧ c.
We now compare P 1 , P 2 , and P 3 .The proof P 2 uses S − ∞ , so we must store a witness of the violation of b ∧ c for each one of the 4 time-points inside the interval.The proofs P 1 and P 3 use S − , taking advantage of the violation proof 3 ⊢ − a that allows us to dismiss both 1 ⊢ + a and 2 ⊢ + a. Formally, we define the size |p| of a proof p to be the number of proof object constructors occurring in p.Then, |P 1 | = |P 3 | = 6, and We are particularly interested in small proofs as they tend to be easier to understand.Given a trace ρ and a formula φ, a proof p is minimal at time-point i if and only if it is , and all other valid proofs q (at i) have greater or equal size (q ⊢ φ and tp(q) = i implies |p| ≤ |q|).In our example, P 1 and P 3 are minimal.

Computing Minimal Proofs
Given an MTL formula φ, our (online) monitor incrementally processes a trace and for each time-point i it outputs a minimal proof of the satisfaction or violation of φ at i.The algorithm constructs this minimal proof of φ by combining minimal proofs of φ's immediate subformulas.To do this efficiently, the monitor maintains just enough information about the trace in its state so that it can guarantee to output minimal proofs.
In case the monitored formula includes (bounded) future operators, the monitor's output may be delayed, such that a single event may trigger the output of multiple proofs at once.In this section, we describe our algorithm in detail and explain its correctness.

Monitor's State
Figure 4 shows the types of our algorithm's main functions init, which computes the monitor's initial state, and eval, which processes a time-stamped event while updating the monitor's state and producing a list of minimal proofs (satisfactions or violations) for an in-order (potentially empty) sequence of time-points.Our monitor's state (type state in Figure 4) has the same tree-like structure as the monitored MTL formula.Additionally, it stores operator-specific information for each Boolean and temporal operator.For example, in the state of α S I β, we store the interval I, the states of the subformulas α and β, a buffer buft for proofs (and associated time-stamps) coming from the recursive evaluation of subformulas and the operator-specific data structures saux.Our monitor's overall structure is modeled after VERIMON [29], which has a similar interface (init and eval) and state type including the used buffers buf and buft.The main novelty is our design of the saux and uaux data structures, which store sufficient information to compute minimal proofs for formulas with topmost operator S and U. Here, we only describe saux in detail.
The data structure saux for a formula φ = α S I β is a record consisting of nine fields.We will describe it next assuming that φ is being evaluated at the current time-point cur.Furthermore, some fields have the type option, which means they are of the form ⊥ (if no value is available) or ⌊v⌋ (storing the value v).The function THE retrieves the optional I)) and after the interval (between L p cur (I) + 1 and cur), respectively.The other fields store satisfaction (prefix s ) or violation (v ) proofs.Specifically, s beta alphas in stores S + proofs inside and s beta alphas out stores S + proofs after the interval.Crucially, while s beta alphas out is an ordinary list, s beta alphas in has type slist, which is a variant of the list type that indicates that the stored proofs are sorted in ascending order (with respect to size).We maintain this invariant to optimize the number of proofs we must store, i.e., if a proof enters the interval, we can delete all larger proofs that entered the interval prior to it.In addition, we can quickly access the first proof of this list which necessarily has minimal size.On the other hand, s beta alphas out must store all proofs because it is not possible to predict when and which of these proofs will enter the interval.Furthermore, v alpha betas in is the analogue of s beta alphas in for S − proofs with a violation of α inside the interval, and a sequence of violations of β until the end of the interval.Note that S − proofs can also be constructed using a single violation proof of α that occurs after the interval, and these are instead stored in the also sorted list v alphas out .Moreover, S − ∞ proofs require that β is violated at all time-points inside the interval, so v betas in stores a suffix of β violations inside the interval.Finally, v alphas betas stores all α and β violations outside the interval, so all other components that store violation proofs inside the interval can be efficiently updated when the interval shifts.

State Update
Algorithm 1 shows the skeleton of our procedure for updating (and simultaneously evaluating) the state of a since operator.The state update for φ = α S I β is parametrized by the interval I = [l, r], the current time-point cur and its time-stamp τ cur , minimal proofs p 1 and p 2 (obtained recursively) for the subformulas α and β, respectively, and the current state saux.The procedure first checks if cur is the first time-point to arrive and initializes ts zero accordingly (line 2).Next, we add the new subproofs to their destinations (ADD SUBPS).For example, if p 1 ∈ sp then all proofs from s betas alphas in and s betas alphas out are extended with this additional satisfaction proof for α.In contrast, if p 1 ∈ vp then both s betas alphas lists are emptied and the violation of α is stored in v alphas out and v alphas betas out instead.A similar case distinction happens for p 2 .After storing the proofs, we handle the case where cur is a time-point at the beginning of the trace for which the interval has not started yet (lines 4-6), which corresponds to the S − <I case depicted in Figure 3(b) on the right.Here, we add a new time-stamp-time-point pair to ts tp out (line 5), and return the proof S − <I (cur) and the updated saux.In the general case (when the interval has started), we compute the absolute timestamp pair lr that constitute the boundaries of the past interval I relative to τ cur (line 8).We use the absolute boundaries to identify a potential interval shift and move proofs in saux from the out lists to the in lists accordingly (line 9).Lines 13-18 provide additional details in which order the various components are shifted.Lastly, we compute a minimal proof (line 10), performing a case distinction.If s beta alphas in is non-empty, then its head must be a minimal satisfaction proof.Otherwise, the formula is violated and a minimal violation proof is either the head of v alpha betas in or the head of v alphas out (after adding a S − constructor) or the application of S − ∞ to v betas in (provided that this suffix spans the entire interval which can be deduced by comparing the lengths of v betas in and ts tp in ).We extract these (at most three) candidates, compute their sizes, and pick one of minimal size.This minimal proof and the updated saux are then returned (line 11).
Example 3. To illustrate how the state is updated, we once again consider the formula and trace introduced in Example 1. Figure 5 shows the saux states of our algorithm and the produced minimal proof after processing every event.In every state, we only show the non-empty components.Initially, all components of the state are empty except for ts zero , which is ⊥.When the first event ({a, b, c}, 1) arrives, the list ts tp out is updated accordingly and a pair with time-stamp 1 and a S + proof using the satisfactions of b and c is added to s beta alphas out .This proof is clearly not valid for the current time-point 0, considering that the interval [1,2] has not yet started, so the monitor outputs the trivial proof S − <I (0).The time-stamp of the first event moves inside the interval when the second event ({a, b}, 3) arrives, and both ts tp out and ts tp in are updated accordingly.Furthermore, the algorithm extends the S + proof previously stored in s beta alphas out by adding ap + (1, a) to the sequence of a satisfactions, after which the resulting proof is moved to s beta alphas in .The algorithm also appends the proof ap − (1, c) to v alphas betas out .Because s beta alphas in is not empty, the monitor outputs the first proof of this list.
In the next step, event ({a, b}, 3) arrives and the monitor proceeds similarly, adding the proof ap + (2, a) to the S + proof in s beta alphas in .Aside from outputting the extended satisfaction proof, the algorithm also adds the proof ap − (2, c) to v alphas betas out .
) When event ({•}, 3) arrives, the sequence of a satisfactions comes to an end, which indicates that the proofs in s beta alphas in and s beta alphas out are no longer valid nor useful.Hence, we clear both lists.In addition, the proof ap − (3, a) is stored in v alphas out , since the a violation happens after the interval.This subproof is also appended to v alphas betas out along with the violation of the conjunction ∧ − L .The algorithm then proceeds to construct a violation proof S − (3, ap − (3, a), [•]) using the subproof stored in v alphas out and outputs it.When ({a}, 3) arrives, the algorithm appends the proof ∧ − L to v alphas betas out and again uses the same subproof stored in v alphas out to construct S − (4, ap − (3, a), [•]).Note that this proof has an associated time-point of 4, which is the only distinction from the last proof that the monitor output.
Finally, when the last event ({a}, 4) arrives, the interval shifts and ts tp in and ts tp out change accordingly.At this stage, the algorithm populates v alpha betas in and v betas in with the subproofs stored in v alphas betas out .In particular, it constructs and stores the proof S − (5, Fig. 6: The algorithm's invariant (soundness) sequence of violations of the conjunction inside the interval is stored in v betas in .This sequence of violations fills the entire interval, so it is then used to construct the proof ).The S − proof corresponds precisely to the proof tree presented in Example 1, and the proof object P 1 in Example 2, whereas the S − ∞ proof corresponds to the proof object P 2 .Lastly, the size of these two proofs is computed, and the algorithm selects the S − proof, since it is smaller (i.e., it includes fewer constructors).■

Correctness
We now formally describe the invariant we maintain for saux.We write ts(p) for the timestamp associated with a proof, i.e., the time-stamp τ tp(p) of the associated time-point tp(p).We also use functional programming notations like λ-abstractions and the list map function.We define the predicate sorted(seq) := ∀ (τ i , p i ) , (τ j , p j ) ∈ seq.(i < j) ∧ ( j < length (seq)) → τ i ≤ τ j ∧ |p i | ≤ |p j | over a sequence of pairs of time-stamps and proofs and assume that every sequence below is monotone with respect to time-stamps (i < j implies τ i ≤ τ j ).The fields ts zero , ts tp in and ts tp out are characterized as follows: The desired properties of the objects stored in other fields are given in Figure 6.
We describe each of the invariant's statements.In (1) a proof in s beta alphas in (which must be sorted) must have form S + (p, q) and be a valid proof of α S I β at the current time-point, with time-stamp ts (p).Next, (2) requires proofs to have the same form but instead be valid for a modified formula without the interval I.In this case, we can relax the timing constraint because these proofs will only be valid at a later time-point, namely once ts(p) moves inside the interval.The statement (3) is precisely the same as (1), but for S − proofs.In (4), each proof p in v alphas out (which must too be sorted) must be a valid subproof of a S − proof at the current time-point with time-stamp ts(p).In (5), each subproof corresponding to the violation of β must be inside the interval with time-stamp ts(p).The statement (6) specifies that outside the interval there is either a subproof of a violation of α or β or there are no such proofs.These statements formalize what must hold for the things stored in saux, which yields soundness.We briefly consider completeness, In words: for any valid S + proof for φ = α S I β at time-point cur, we must store in s beta alphas in another proof at most as large and old, that is also valid for φ at cur.Other fields of saux have similar completeness statements and so have other state components.
Together, soundness and completeness ensure that given a formula, a trace, and a timepoint i, our online monitoring algorithm will eventually output a valid minimal proof at i.

Implementation
We implement our algorithm in a new tool called EXPLANATOR2 [22].The implementation amounts to around 4 000 lines of OCaml.In addition, a 6 900 lines long OCaml program is extracted from our Isabelle formalization consisting of 19 000 lines of definitions and proofs.The extracted program contains the proof object validity checker in the form of a function is valid : trace → formula → proof → bool, which effectively implements what we denote by p ⊢ φ.Moreover, it also contains the minimality checker is minimal : trace → formula → proof → bool that given a trace ρ, a formula φ, and a proof p computes a proof q for φ on ρ at time-point tp(p) with a minimal size using a verified dynamic programming algorithm and then checks that |p| ≤ |q|.Note that q may differ from p because minimal proof objects are not unique.Herasimau [16] provides more details on the formalization and the dynamic programming algorithm.We used the verified validity and minimality checkers to thoroughly test our unverified algorithm.Our tool includes a command line option to enable the verified certification of its output, which slows down computation as the verified algorithm is rather inefficient but increases trustworthiness.
EXPLANATOR2 also includes a JavaScript web front end.To this end, we transpile the compiled OCaml bytecode to JavaScript using Js of ocaml [36].The resulting JavaScript library runs in any web browser.We augment the library with an interactive visualization using React [17].Figure 7 shows the visualization of our Example 1.On the left, the visualization shows the trace (from top to bottom) consisting of the atomic propositions (columns a, b, and c), the time-stamps (column TS) and associated time-points (column TP).The following columns show either the topmost operator of the different . . .In particular, the column labeled with φ's topmost operator, namely S [1,2] , shows the Boolean verdicts that a traditional monitor would output.Users of EXPLANATOR2 can further inspect the Boolean verdicts by clicking on them.Figure 7 shows the visualization's state after clicking on φ's violation at time-point 5.The visualization highlights the time interval and the Boolean verdicts for subformulas that justify the verdict associated with the inspected formula and time-point.Furthermore, it shows the relevant violations of φ's subformulas a and b ∧ c: the subformula a is violated at time-point 3 and b ∧ c is violated at time-points 3 and 4, which corresponds to a valid S − proof.The user could continue the exploration by further clicking on the two b ∧ c violations to find out that the tool used b violations to justify both.The visualization uses black circles to denote combinations of subformula and time-point that are relevant for at least one of φ's verdicts.The Boolean value for these relevant subformula verdicts is only revealed upon exploration.

Examples
We demonstrate how the minimal proofs produced by our monitor can be useful when trying to comprehend a satisfaction or violation of an MTL formula.To this end, we consider Timescales [34], a benchmark generator for MTL monitors.Timescales uses predefined MTL formulas that represent temporal patterns that commonly occur in real system designs [20].It generates traces, in which the time-stamps are equal to their corresponding time-points.We selected the two most complex properties and generated their corresponding traces.At the end of both traces there is a violation of the pattern, and we use our approach to explain these violations.In addition to the operators presented in Figure 2, we extended our proof system and algorithm with the following operators: ⊤ (truth), ⊥ (falsity), → (implies), ↔ (iff), ■ I (historically), □ I (always), ♦ I (once), and ♢ I (eventually).
To prove the violation of the implication (the formula's topmost operator) the subformula on the left (assumption) must be satisfied and the subformula on the right (conclusion) must be violated.For this reason, two subproofs are constructed.In the left subproof, we can see that the subformula on the left is violated because both conjuncts r ∧ ¬q and ♦q are satisfied at time-point 61.This part of the formula enforces that: (i) r is satisfied (and q is not satisfied) at the current time-point; and (ii) q is satisfied at some point in the past.Note that (ii) corresponds exactly to ♦q.In the left subproof, we have 61 ⊢ + r ∧ ¬q because r is satisfied and q is violated at time-point 61.Moreover, the proof 61 ⊢ + ♦q uses the fact that q is satisfied at time-point 56, which is when the last q had arrived.Moving to the subproof 61 ⊢ − (♦ [0, 3] (p ∨ q)) S q, the violation occurs because both subformulas are violated at time-point 61.The subproof 61 ⊢ − ♦ [0,3] (p ∨ q) uses the violations of p and q in the last 3 time units (58, . . ., 61), whereas the proof 61 ⊢ − q indicates that q is not satisfied at the current time-point.This is sufficient to show that since the last q has arrived (at time-point 56), it is neither the case that a new sequence started (with a new occurrence of q) or that a sequence finished (with an occurrence of p) within 3 time units in the past.
Figure 9 shows our visualization of the above proof.Starting from →, the columns show the topmost operators of φ 1 's subformulas (including atomic propositions).For example, φ 1 is violated because the left subformula is satisfied (the first ∧ column) and the right subformula is violated (column S [0,∞) ).All subformulas have a corresponding column and the order of the columns is such that immediate subformulas of a subformula appear further to the right.The same atomic proposition may occur in different subformulas, in which case there will be multiple columns showing the same proposition (but potentially different time-points of interest).Continuing our example, the right subproof from Figure 8 starts in column S [0,∞) in Figure 9.The formula (♦ [0, 3] (p ∨ q)) S q is violated at time-point 61 because both subformulas are violated.In the visualization, we focus (by clicking) on the subformula ♦ [0, 3] (p ∨ q) (displayed when hovering over the corresponding cell) and observe that it is violated because p ∨ q is violated at time-points 58, . . ., 61 (highlighted cells in the ∨ column).Also, the context of this subproof, i.e., all parent nodes in the proof tree, is highlighted.In this case, these are → and S [0,∞) at time-point 61.Even though it presents the exact same information as the proof tree, our interactive visualization makes the proofs easier to navigate, explore, and digest.
Bounded Response Between q and r.Closely related to the bounded recurrence, the bounded response property specifies the following pattern: between events q and r, event s must respond to event p within the interval [l, u].In MTL, this pattern is specified by the formula φ 2 = ((r ∧ ¬q) ∧ ♦q) → s → ♦ [l,u] p ∧ ¬ ¬s S [u,∞) p S q .We consider the trace ⟨. . ., ({q}, 58), ({p}, 59), ({•}, 60), ({•}, 61), ({•}, 62), ({•}, 63), ({r}, 64)⟩ and set l = 0 and u = 3. Figure 10 shows a violation proof for φ 2 at time-point 64.The implication's assumption in φ 2 is the same as the assumption in φ 1 (the bounded recurrence formula).We omit the corresponding subproof P from Figure 11 as it has the same structure as the subproof of the bounded recurrence example.(Yet, there are differences in the time-points.)The conclusion of φ 2 has the form α S q.It is violated at time-point 64 because α is violated at time-point 62, and from this point onward until the current time-point 64, q is always violated.According to our proof system, we only need to consider violations of q starting at time-point 62, because α is violated at that point.The formula α = s → ♦ [0,3] p ∧ ¬ ¬s S [3,∞) p captures two properties: (i) if there is a response s then there must be a recent challenge p (i.e., p must be satisfied within the last 3 time units); (ii) there are no challenges p more than 3 time units in the past without a response s.In our proof, the violation of α is constructed using the violation of (ii).After applying the negation rule, the proof 62 ⊢ + ¬s S [3,∞) p uses the fact that p is satisfied at time-point 59 and that s is violated at time-points 60, 61 and 62.In other words, there was no response s to the challenge p within the required time constraint.Figure 11 shows the visualization of this subproof.While the static image already helps with the intuition, we invite the reader to explore this and the previous example in our interactive visualization.

Performance
We empirically evaluate our tool by answering the following research question: How does EXPLANATOR2 scale with respect to the formula size when compared to other state-ofthe-art monitoring tools?To this end, we reuse the evaluation setup of the MTL monitor HYDRA [26].We consider two different settings: (i) past-only MTL formulas; and (ii) MTL formulas (mixing past and future operators).For each setting we pseudo-randomly generate a trace with 100 000 events and collections of five different formulas for each size s ∈ {6, 17, . . ., 50} .We measure the time and space usage of the EXPLANATOR2, HYDRA and VYDRA [27], AERIAL [3] MONPOLY [5], and VERIMON [29].Our verified dynamic programming algorithm is not included because it times out (with a time-out of 200 seconds) even for the smallest formulas of size 6.The experiments were conducted on a computer with an AMD Ryzen 5 5600X CPU and 16GB of RAM.The results are presented in Figure 12.Each filled shape is an average of the measurements for the corresponding formula size.(Unfilled shapes show the individual runs, but are sometimes invisible.)The axes showing time and space usage measurements are of logarithmic scale.
Time-wise, EXPLANATOR2 outperforms MONPOLY and VERIMON (first-order monitors), and is on par with most of its competitors in the past-only setting.When we include future operators, EXPLANATOR2 performs worse than its competitors, although only by a narrow margin.However, we must consider that in contrast to the others our tool has a clear disadvantage: it produces checkable and understandable output instead of Boolean verdicts.Thus, these results reassure us that we do not compromise too much by providing this feature, and that our algorithm is indeed efficient.In terms of space usage, EXPLANATOR2 performs worse than other monitoring tools in both settings.This is hardly surprising, given that proofs can be huge (e.g., they may contain the entire trace).

Conclusion
We have developed an online MTL monitor that outputs detailed verdicts in the form of proof trees, which serve as both understandable explanations and checkable certificates.Our monitor incorporates a formally verified checker and an interactive visualization.Our empirical evaluation demonstrates the reasonable performance of our monitor, even though it provides a strictly more informative output than its competitors.Overall, we believe that our approach significantly improves the user experience when using an MTL monitor.In particular, the generated explanations provide insight into root causes of violations and can help with specification debugging.Another plausible application of explanations is teaching temporal logics to students and engineers.
As future work, we will lift our approach to the more expressive metric first-order temporal logic.The main challenge here is to incorporate parametric events and quantification.Moreover, we are interested in optimizing other aspects of the proofs than their size.

Fig. 2 :
Fig. 2: Local proof system for MTL for a fixed trace ρ = ⟨(π i , τ i )⟩ i∈N (for satisfaction proofs) and ⊢ − (for violation proofs).A satisfaction (violation) proof describes the satisfaction (violation) of a formula at a given time-point on a fixed trace ρ.Each rule is suffixed by + or − , indicating whether an operator has been satisfied or violated.Moreover, we define E p i (I) := ETP(τ i − r) and L p i (I) := min(i, LTP(τ i − l)) for I = [l, r], which correspond to the earliest and latest time-point within the interval I, respectively, when formulas having S I as their topmost operator are considered.In the definition of L

Fig. 7 :
Fig. 7: Visualization of Example 1 by answering the question of what must be stored, on the example of s beta alphas in :

Fig. 12 :
Fig. 12: Evaluation results ts zero : ts option, ts tp in : (ts × tp) list, ts tp out : (ts × tp) list, s beta alphas in : (ts × sp) slist, s beta alphas out : (ts × sp) list, v alpha betas in : (ts × vp) slist, v alphas out : (ts × vp) slist, v betas in : (ts × vp) list, v alphas betas out : (ts × vp option × vp option) list } type state = Pred S string | Neg S state | And S state state buf | Or S state state buf | Prev S I state bool p (ts list) | Next S I state bool (ts list) | Since S I state state buft saux | Until S I state state buft uaux function init :: formula ⇒ state function eval :: ts × tp ⇒ atom set ⇒ state ⇒ p list × stateFig.4: Types of the monitor's state and evaluation functions valid at i (p ⊢ φ and tp(p