Test oracle observation at runtime

Assess the correctness of a behaviour of a system at runtime with respect to a given property expressed in a formal specification language.
Dynamically assess the robustness of a system behaviour during its runtime by measuring how far the system is from satisfying or violating a property expressed in a formal specification language.

Runtime verification is a pragmatic, yet rigorous, technique to reason about software and systems in a systematic manner. It borrows the concept of formal specifications and combines it with the analysis of individual system behaviours. Thus, this technique does not encounter the scalability issues that are commonly associated to the formal verification. Runtime verification is a black-box method that does not require an abstract model. As a consequence, it can be used both at the design and the deployment time of a system. Runtime verification has found its way in many application areas, including the field of monitoring CPS.

Signal Temporal Logic (STL) [TOO1] is a specification formalism for expressing real-time temporal properties of CPS. In its original form, STL was designed as a declarative specification language for runtime monitoring. We can see STL specifications as binary classifiers that partition behaviours into good and bad ones (Figure ‎3.6). The following requirement is a typical example of an informal English specification that describes the rising of a continuous signal and can be naturally formalized in STL:

“The rise time of the voltage V from Vmin to Vmax must be smaller or equal than Trise is”.

The STL specification that describes the above requirement is expressed as follows.

vl = (V ≤ Vlow);

vm = (V > Vlow and V ≤ Vhigh);

vh = (V > Vhigh);

always (vl → (vm until[0,Trise] vh));

img1.png
Figure ‎3.6 Good vs. Bad Behaviours

Quantitative semantics of specification languages: Consider the predicate x ≥ 5 and the valuation in which x equals to 2. The qualitative evaluation of this simple specification tells us that the valuation violates the property. Given this numerical predicate over a real-valued variable and a variable valuation, we can also answer the question on how far the valuation is from satisfying or violating the predicate. This rich feedback contrasts the classical yes/no answer that we typically get from reasoning about Boolean formulas. Fainekos and Papas [TOO2] lifted this quantitative property of numerical predicates to the temporal case, giving rise to the quantitative semantics for STL. This extension replaces the binary satisfaction relation with a real valued robustness degree function while preserving the syntax of the specification language. The robustness degree indicates how far an observed signal from satisfying or violating the specification is. The original quantitative STL semantics have been defined in terms of the infinite form. This spatial notion of robustness was consequently extended in several directions, including time robustness and average robustness. The quantitative semantics is a powerful extension that allows ordering specifications according to their goodness or badness and opens up the possibility of building new applications.

Applications: Runtime verification is a versatile technology that has been successfully combined with many other analysis and synthesis methods. In particular, STL qualitative and quantitative monitors have been used as the basis for many new techniques for analysing CPS, such as falsification-based testing [TOO3], parameter synthesis [TOO4], specification mining [TOO5], and fault explanation [TOO6, TOO7].

  • Quantitative indicator on the degree of behaviour robustness with respect to the specification
  • Computationally inexpensive
  • Can be used both during the design of the system and during its operation
  • Black-box technique that does not require the system model
  • Can be used as the basis for developing other V&V methods
  • Not exhaustive – analysis of an individual behaviour
  • Passive observation of a behaviour (unless combined with test generation or runtime assurance)
  • Specification languages have certain expressiveness limits
  • [TOO1] O. Maler and D. Ničković, “Monitoring properties of analog and mixed-signal circuits,” STTT, vol. 15, no. 3, pp. 247–268, 2013.
  • [TOO2] G. E. Fainekos and G. J. Pappas, “Robustness of Temporal Logic Specifications,” in Proc. of {FATES} 2006: First Combined International Workshops on Formal Approaches to Testing and Runtime Verification, 2006, vol. 4262, pp. 178–192.
  • [TOO3] T. Nghiem, S. Sankaranarayanan, G. E. Fainekos, F. Ivancic, A. Gupta, and G. J. Pappas, “Monte-carlo techniques for falsification of temporal properties of non-linear hybrid systems,” in Proceedings of the 13th ACM International Conference on Hybrid Systems: Computation and Control, 2010, pp. 211–220.
  • [TOO4] E. Asarin, A. Donzé, O. Maler, and D. Ničković, “Parametric Identification of Temporal Properties,” in Proc. of RV 2011: the Second International Conference on Runtime Verification, 2012, vol. 7186, pp. 147–160.
  • [TOO5] Z. Kong, A. Jones, and C. Belta, “Temporal Logics for Learning and Detection of Anomalous Behavior,” IEEE Trans. Autom. Contr., vol. 62, no. 3, pp. 1210–1222, 2017.
  • [TOO6] Ezio Bartocci, Thomas Ferrère, Niveditha Manjunath, Dejan Nickovic: Localizing Faults in Simulink/Stateflow Models with STL. HSCC 2018: 197-206
  • [TOO7] Ezio Bartocci, Niveditha Manjunath, Leonardo Mariani, Cristinel Mateis, Dejan Nickovic: Automatic Failure Explanation in CPS Models. SEFM 2019: 69-86
Method Dimensions
In-the-lab environment, Open evaluation environment, Closed evaluation environment
Experimental - Monitoring
Hardware, Model, Software
Operation, Acceptance testing
Thinking, Acting
Non-Functional - Safety, Functional
SCP criteria
Relations
Contents

There are currently no items in this folder.