race conditions and deadlocks in Java programs by analyzing single execution paths. Currently, runtime verification techniques are often presented with various alternative names, such as runtime monitoring, runtime checking, runtime reflection, runtime analysis, dynamic analysis, runtime/dynamic symbolic analysis, trace analysis, log file analysis, etc., all referring to instances of the same high-level concept applied either to different areas or by scholars from different communities. Runtime verification is intimately related to other well-established areas, such as testing (particularly model-based testing) when used before deployment and fault-tolerant systems when used during deployment. Within the broad area of runtime verification, one can distinguish several categories, such as: "specification-less" monitoring that targets a fixed set of mostly concurrency-related properties such as atomicity. The pioneering work in this area is by Savage et al. with the Eraser algorithm monitoring with respect to temporal logic specifications; early contributions in this direction has been made by Lee, Kannan, and their collaborators, and Havelund and Rosu,. Basic approaches The broad field of runtime verification methods can be classified by three dimensions: The system can be monitored during the execution itself (online) or after the execution e.g. in form of log analysis (offline). The verifying code is integrated into the system (as done in Aspect-oriented Programming) or is provided as an external entity. The monitor can report violation or validation of the desired specification. Nevertheless, the basic process in runtime verification remains similar: A monitor is created from some formal specification. This process usually can be done automatically if there are equivalent automata for the formulas of the formal language the property is specified in. To transform a regular expression, a finite-state machine can be used; a property in linear temporal logic can be transformed into a Büchi automaton (see also Linear temporal logic to Büchi automaton). The system is instrumented to send events concerning its execution state to the monitor. The system is executed and gets verified by the monitor. The monitor verifies the received event trace and produces a verdict whether the specification is satisfied. Additionally, the monitor sends feedback to the system to possibly correct false behaviour. When using offline monitoring the system of cause cannot receive any feedback, as the verification is done at a later point in time. Examples The examples below discuss some simple properties that have been considered, possibly with small variations, by several runtime verification groups by the time of this