Rule Systems for Run-time Monitoring: from EAGLE to RULER

Abstract

In , Vol. 2937, EAGLE was introduced as a general purpose rule-based temporal logic for specifying run-time monitors. A novel interpretative trace-checking scheme via stepwise transformation of an EAGLE monitoring formula was defined and implemented. However, even though EAGLE presents an elegant formalism for the expression of complex trace properties, EAGLE's interpretation scheme is complex and appears difficult to implement efficiently. In this article, we introduce RULER, a primitive conditional rule-based system, which has a simple and easily implemented algorithm for effective run-time checking, and into which one can compile a wide range of temporal logics and other specification formalisms used for run-time verification. As a formal demonstration, we provide a translation scheme for linear-time propositional temporal logic with a proof of translation correctness. We then introduce a parameterized version of RULER, in which rule names may have rule-expression or data parameters, which then coincides with the same expressivity as EAGLE with data arguments. RULER with just rule-expression parameters extend the expressiveness of RULER strictly beyond the class of context-free languages. For the language classes expressible in propositional RULER , the addition of rule-expression and data parameters enables more compact translations. Finally, we outline a few simple syntactic extensions of 'core' RULER that can lead to further conciseness of specification but still enabling easy and efficient implementation.

Runtime Monitoring for Concurrent Systems

“…Many specification-based runtime-monitoring frameworks have been proposed, including four approaches to parametric monitoring: an automaton-based approach [5,7,15,16,18,20,28,34]; a regular expression-and grammar-based approach [1,18,24]; an approach based on temporal logic [6, 8, 9, 18-20, 24, 32, 33, 39, 48-50]; and a rule-based approach [4,6,35].…”

TraceContract: A Scala DSL for Trace Analysis

“…This specification style is very close to the way such past time properties are specified in RULER and LOGSCOPE. Indeed, [7] presents a translation scheme from future and past time LTL to RULER, the past time part of which can be fully mimicked to obtain a formal translation of past time LTL into TRACECONTRACT. Essentially, there is one key difference between the two.…”

“…Our own work includes several such systems, most of which put emphasis on expressiveness, in order to be able to capture the many different logics provided in other systems. Amongst these systems are EAGLE [4] -based on recursive definitions of temporal predicates; RULER [7] -a rule-based framework providing the same level of formal expressivity as EAGLE but with a simpler and more efficient step-wise monitoring algorithm; and LOGSCOPE [5] -a state machine-like subset of RULER with the addition of a temporal logic. From these experiences, we observe two key points: (i) once a DSL is defined, it is laborious to change/extend it later; and (ii) users often ask for additional features, some of which are best handled by a general purpose programming language.…”

Comprehension of Spacecraft Telemetry Using Hierarchical Specifications of Behavior

“…These systems support various formalisms, such as state machines [14,19,11,7,5], regular expressions [4,19], variations over the µ-calculus [6], temporal logics [6,19,7,15,9,10,12], grammars [19], and rulebased systems [8,17]. Some of these systems focus on being efficient.…”

“…However, this efficiency is typically achieved at the price of some lack of expressiveness, as discussed in [5]. Our previous research has focused on more expressive formalisms, including rule-based systems, such as Ruler [8] and more recently LogFire [17]. Rule-based systems in general provide a rich formalism, which can be used to encode the kind of abstraction needed for our behavior definitions.…”