Lecture Notes in Computer Science 3472

18 Run-Time Verification 529
from a machine to another one before checking takes place, e.g., transferring the
file from the client machine to the vendor’s site.
To illustrate the runtime verification, a basic example will be used along
with the chapter. It is the railroad gate example. It is composed of a gate and
a light. The light can flash or be off. The gate can be closed, opened, closing
or opening. First the gate is open. Before the door closes, the light flashes to
warn the motorists of the imminent closing of the door. The light continues to
flash while the door closes until the door is again opened. The program that
implements this example is supposed to be instrumented to send information
about the state modifications of both the gate and the light. In particular, we
suppose that the program can generate the following events at run-time:
• closing when the gate begins to close
• closed when the gate is closed
• opening when the gate begins to open
• opened when the gate is open
• off when the light is off
• flashing when the light begins to flash.
During the execution of the program, a sequence of events is generated.
The sequence is an execution trace of the program. For example, three different
executions can generate these traces:
(1) open, off, flashing, closing, closed, opening, open, off.
(2) open, off, flashing, closing, closed, off, opening, open.
(3) open, off, closing, flashing, closed, opening, open, off.
A runtime verification technique checks an execution trace against requirements.
For example, the requirement that “whenever the gate begins to open,
then the gate has been closing in the past, and since then the light has not
finished flashing”, can be formalized by the past LTL formula [Pnu77]:
↑ is opening ⇒ [is closing, ↓ (is flashing))
Another requirement could be “always in the future whenever the light is
off, then the gate will not be closing until the light will be flashing”, can be
formalized by the future LTL formula:
✷(is off ⇒¬is closing U is flashing)
The notations ↑ p (begin p), ↓ p (end p), p ⇒ q (p implies q), [p, q) (qinthe
past and not q since p), ✷p (always p), ¬p (not p) and p U q (p until a) will be
introduced latter in the paper. Propositions is opening, is closing, is flashing
and is off describe intuitively the state of both the gate and the light, and they
correspond to conditions gate = opening, gate = closing, light = flashing and
light = off, respectively.
By matching the formal requirements with the three execution traces, a runtime
verification technique can detect a violation of the first requirement in the