Comparing LTL Semantics for Runtime Verification

Abstract

When monitoring a system w.r.t. a property defined in a temporal logic such as LTL, a major concern is to settle with an adequate interpretation of observable system events; that is, models of temporal logic formulae are usually infinite words of events, whereas at runtime only finite but incrementally expanding prefixes are available.In this work, we review LTL-derived logics for finite traces from a runtime-verification perspective. In doing so, we establish four maxims to be satisfied by any LTL-derived logic aimed at runtime verification. As no pre-existing logic readily satisfies all of them, we introduce a new four-valued logic Runtime Verification Linear Temporal Logic RV-LTL in accordance to these maxims. The semantics of Runtime Verification Linear Temporal Logic (RV-LTL) indicates whether a finite word describes a system behaviour which either (i) satisfies the monitored property, (ii) violates the property, (iii) will presumably violate the property, or (iv) will presumably conform to the property in the future, once the system has stabilized. Notably, (i) and (ii) correspond to the classical semantics of LTL, whereas (iii) and (iv) are chosen whenever an observed system behaviour has not yet lead to a violation or acceptance of the monitored property.Moreover, we present a monitor construction for RV-LTL properties in terms of Moore machines signalizing the semantics of the so far obtained execution trace w.r.t. the monitored property.Runtime verification of a given correctness property ϕ formulated in linear temporal logic (LTL) [18] requires at its core the evaluation of the semantics of ϕ w.r.t. to a finite observed system behaviour. But the evaluation of LTL properties on finite traces proved to be an obstacle, as LTL is usually evaluated over infinite traces and since the standard semantics of LTL on finite traces [15] is unsatisfactory for the purpose at hand.While the syntax and semantics of LTL on infinite traces is well accepted in the literature, there is no consensus on defining LTL over finite traces. Besides the definition in [15], a number of two-valued semantics for LTL on finite traces have been proposed [9,13,14,12,20,6], see Eisner et al. [8] for a comprehensive survey on this topic. Alternatively, it has been proposed to restrict the syntax of LTL for runtime verification, such that formulae which may contain certain future obligations cannot be specified at all [10].In monitoring a property, there arise at least three different situations: in the first case, the property is satisfied after a finite number of steps, independently of the future continuation; second, the property is shown to evaluate to false for every possible continuation, and third, the finite, already observed prefix still allows different continuations leading to either satisfaction or falsification. A prefix leading Vol. 20 No. 3, We consider in this article the traditional two-valued semantics with truth values true, denoted with , and false, denoted with ⊥, next to truth values that give more information to ...

Runtime Verification of Component-Based Systems

“…We follow a general approach considering verification monitors as deterministic finite-state machines producing a truth-value (a verdict) in an expressive 4-valued truth-domain B 4 def = {⊥, ⊥ c , c , }, introduced in [3] and used in [4]. B 4 consists of the possible evaluations of a sequence of events and its possible futures relatively to the specification used to generate the monitor:…”

“…This allows a direct relation between the underlying semantic model and its implementation. Runtime-verification (RV) [2][3][4] is an effective technique to ensure, at runtime, that a system meets a desirable behavior. It can be used in numerous application domains, and more particularly when integrating together unreliable software components.…”

Run-Time Assertion Checking of Data- and Protocol-Oriented Properties of Java Programs: An Industrial Case Study

“…This restriction is not specific to our approach: liveness properties in general cannot be rejected on any finite prefix of an execution, and monitoring only checks finite prefixes for violations of the specification. Most liveness properties fall in the class of the non-monitorable properties [2,19]. However it is possible to ensure liveness properties for terminating programs: they can then be reformulated as safety properties.…”

Combining Monitoring with Run-Time Assertion Checking

“…This restriction is not specific to our approach: liveness properties in general cannot be rejected on any finite prefix of an execution, and monitoring only checks finite prefixes for violations of the specification. Most liveness properties fall in the class of the non-monitorable properties [61,7]. However it is possible to ensure liveness properties for terminating programs: they can then be reformulated as safety properties.…”