According to the IEEE [CS217], verification encompasses all techniques suitable to ensure that a system satisfies its specification. Traditional verification techniques comprise theorem proving [BC04], model checking [CGP99], and testing [MSB11]. Theorem proving is mostly manually applied and enables the check of the program’s correctness as a proof similar to proving the correctness of a theorem in mathematics. Model Checking is an automatic verification technique which is primarily applied to finite-state systems.
Definition 2.30 (Verification). Verification is formally defined in terms of system
behavior as Φ (M, P, U ) |= ψ for given system M, given set P of parameters, given set U of inputs and given property ψ which shall hold for the system.[Kap+16]
Runtime verification represents lightweight verification techniques which complement the three traditional verification techniques [LS09].
Definition 2.31 (Runtime Verification). Runtime verification encompass verification
techniques that allow to check whether a run of a system satisfies or violates a given correctness property (cf. [LS09]).
The main distinction between runtime verification and traditional verification techniques is that runtime verification is predominantly performed at runtime. Executions are the primary objects analyzed in the setting of runtime verification. While traditional verification techniques investigate whether all runs of a system adhere to given correctness properties, runtime verification works on finite (terminated) traces, finite but continuously expanding traces, or on prefixes of infinite traces.[Leu11; LS09]
A trace describes a possibly infinite sequence of system’s states or system actions. System
states are formed by the current assignments to system variables or as a sequence of
2.3. Runtime Verification
execution of the system is a finite trace and, therefore, is a finite prefix of a run.[Leu11;
LS09]
Definition 2.32 (Trace). A trace is a possibly infinite sequence of system’s states,
which are formed by the current assignments to system variables, or a possibly infinite sequence of system actions [Leu11; LS09].
Runtime verification approaches vary in the part of a system run which is considered for the verification of the system. Approaches analyze system properties based on the input/output behavior of the system, its state sequences in executions, or based on a sequence of generated events related to the system’s execution.[Leu11]
Diagnosis and reconfiguration capabilities can extend runtime verification systems in order to react to property violations and mitigate corresponding system failures (cf. [BLS06; LS09]).
Therefore, runtime verification approaches are distinguished whether they passively observe the system’s execution and report failures, or whether their monitor verdicts are used to actively modify the execution of the target system (cf. [Leu11]).
Runtime verification is closely related to the field of runtime monitoring. Monitors evaluate at runtime if the execution of the target system meets a given property. The foundations of runtime monitors are described in the following section.
2.3.1. Runtime Monitor
In runtime verification, runtime monitors are used to check whether an execution of a system meets a given property φ [BLS11; Leu11; LS09]. In general, runtime monitors are automatically generated from given property φ.
In mathematical sense, runtime verification checks if a execution w is an element of JφK, where JφK denotes the set of valid execution for the property φ. Thus, runtime verification answers the word problem, i.e., whether a given word is included in some language.[Leu11]
Definition 2.33 (Runtime Monitor). A Runtime monitor observes an execution of
a program or system and evaluates predefined properties, conditions, or invariants about the system behavior based on its observed runtime data (cf. [WH07]).
The execution trace of a system can be verified online or offline. The usage of monitors to verify the current execution of a system is denoted as online monitoring while the evaluation of recorded traces is defined as offline monitoring. Online monitoring has the advantage that the critical system behavior can be corrected based on the verdict of the runtime monitor.[LS09]
The complexity for generating the runtime monitors is often negligible because monitors are typically only generated once. However, the complexity of runtime monitors regard- ing memory and computation requirements are of vital interest because the monitor
should not interfere with the functional and non-functional behavior of the monitored systems.[BLS11]
As part of the trusted computing base, soundness, completeness, determinism, and
passivity of runtime monitors are of essential importance but are seldom defined and
documented in precise terms in the development of runtime monitors (cf. [Fra+17; WH08]). Each characteristic is described in the following:
Soundness : Runtime monitors have to correctly monitor the target systems. Any rejections raised by runtime monitors have to indeed be violations of monitored properties for the target systems.
Completeness: Runtime monitors will sufficiently observe the execution behavior of
targets systems for completeness if they detect all system behavior violating supervised properties for the target systems.
Determinism: Runtime monitors should yield to the same verification results for identical
observations from the execution of target systems.
Passsivity: Runtime monitors should not interfere with the execution of target systems. Passivity is especially critical within embedded systems, where hardware resources are limited.
For observations about the execution of the target systems, parts of the monitoring systems have to be attached to the target systems in order to extract information about the internal operation of these systems. These parts of the monitoring system are termed
probes or sensors (cf. [Sch95; WH07]). Probes (sensors) are further distinguished into hardware probes and software probes. Hardware probes monitor internal physical system
signals. Software probes are added as additional monitoring code to the code base of the target system in order to logical system signal in the code. The addition of monitoring code to the code base of the target system is termed code instrumentation (cf. [Rd04; WH07]).
Definition 2.34 (Code Instrumentation). Code Instrumentation is the modification
of the monitored system by additional code that informs the runtime monitor about events and data relevant for the monitored properties.
As code instrumentation may interfere with the system execution, runtime monitoring approaches are distinguished in invasive and non-invasive monitoring [Leu11]:
Invasive monitoring: The runtime monitors of invasive monitoring approaches have an
impact on the execution of the systems. These are primarily approaches which use code instrumentation or share the hardware resources with the target system.
Non-invasive monitoring: Non-invasive monitoring approaches segregate the target
system from the runtime monitors by using additional computation resources in order to exclude any side effects by the runtime monitors on the execution of the target system.
2.3. Runtime Verification
Other terms for invasive and non-invasive monitoring are intrusive and non-intrusive monitoring (cf. [Sch95]).
Three types of runtime monitoring are distinguished; software, hardware, and hybrid monitoring (cf. [WH07]). Each type is discussed in the following sections.
2.3.1.1. Software Monitors
Software monitoring requires the modification of the targeted systems. The primary approach is the instrumentation of the system’s application code by additional code that informs the runtime monitor about relevant events and data values. Further approaches are the instrumentation of the operating systems or the usage of a dedicated monitor process (cf.[HG08; WH07]).
Software monitoring can be used flexibly and does not require any additional hardware (cf. [Rd04; Sch95; Tha+03]). However, the integration of runtime monitoring code into the target system may introduce side effects for the target system. The software monitoring may introduce overhead on the system’s processing time and memory space consumption. Such side effects can be unacceptable for many real-time systems. An alternative approach is to introduce the instrumentation code permanently into the system, but this may be difficult for an embedded system with strict costs restrictions. [WH07]
Instead of introducing instrumentation code to the target system, additional hardware components can be introduced for the runtime monitors. Hardware monitoring is described in the following section.
2.3.1.2. Hardware Monitors
Hardware monitoring is machine dependent resp. processor architecture dependent. It comprises the modification of the hardware platform on which the target program is executed. Either internal signals of the target system are probed, or additional monitoring hardware is introduced to the hardware platform. The monitoring hardware observes the execution of the target program by, e.g., listening on the system bus. Instrumentation of system code is not required for hardware monitoring. [Sch95; WH07]
The benefit of hardware monitoring is the non-intrusive access to information about the target system. Therefore, hardware monitoring is most suitable for a system with strict real-time constraints. [WH07]
The disadvantage of hardware monitoring is the increasing costs and inherent limitations of monitoring hardware (cf. [Sch95; WH07]). Newer hardware platforms are less likely to offer possibilities for physical probe points. System-on-chip (SoC) systems with on-chip caching and complex processing and memory architectures have significantly reduced the visibility of program execution for external hardware, e.g., runtime monitoring systems. A solution to the reduced external observability of SoC systems are on-chip monitors (cf. [El 02; WH07]).
Software and hardware monitoring can be combined with hybrid monitoring in order to mitigate their disadvantages. Hybrid monitoring is described in the next section.
2.3.1.3. Hybrid Monitors
Hybrid monitoring encapsulates monitoring approaches which combine software and hardware monitoring. Hybrid monitoring tries to combine the advantages of each approach by simultaneously mitigating their disadvantages. Code instrumentation of the target system allows access to internal information about the system execution by defining relevant events for the runtime monitoring within the code of the target system. These events would not be accessible by hardware monitors. The instrumentation code is executed as a part of the target system, and relevant events are transferred to separate monitoring hardware for event detection and event processing The additional instrumentation code may potentially affect the behavior and performance of the target systems, but the usage of hardware probes reduces the amount of instrumentation code which is required to monitor these systems sufficiently. As results, hybrid monitors are less likely to interfere with the execution of the target system. [Rd04; Sch95; Tha+03; WH07]
Besides runtime verification, runtime monitoring is used in other contexts for various system types, e.g., safety-critical and mission-critical systems, enterprise systems software, autonomous systems, reactive control systems, health management systems, diagnosis systems, and system security and privacy with various purposes, e.g., debugging, test- ing, security, safety monitoring, verification, validation, faults protections, profiling, or behavior modification.[Rd04; Sch95]
For the monitoring and verification of systems at runtime, relevant system properties have to be formally defined in the system development. The following section gives an overview of the formal definition of such system properties.
2.3.2. Property Specification
Runtime Verification generally assumes a (formal) logic for the description of properties which are expected to be satisfied by the monitored system [Fra+17]. Havelund and Goldberg define in [HG08] four dimensions for the specification of the monitored system behavior:
Location quantification: Location quantification addresses if a logic allows quantifying
over locations in the monitored systems. Runtime monitors evaluate when the system reaches a specific system location during its execution. For online verification, these locations contain the monitoring code itself. For offline verification, these locations contain code which will generate events and forward them to the external runtime monitor. An example of location quantification are system invariants, state machine notations, and process algebras.[HG08]
Temporal quantification: Temporal quantification addresses if a logic allows for quan-
tification over time points. For example, whether open and close methods for access to files are called in their respective order. Such logic can either state ordering relationships over events and actions or reason about relative or absolutes time values and duration for over events and system actions. Temporal logics, e.g.,