Specification-Based Monitoring in C++

Abstract

Software systems cannot in general be assumed proven correct before deployment. Testing is still the most common approach to demonstrate a satisfactory level of correctness. However, some errors will survive verification efforts, and it is therefore reasonable to monitor a system after deployment, to determine whether it executes correctly. Both for testing and post-deployment monitoring, it may be desirable to be able to formalize correctness properties that can be monitored against program executions. This is also referred to as runtime verification. We present a specification language and a monitoring system for monitoring such specifications against event streams. The monitoring engine front-end, written in Scala, translates the specification to C++, whereas the back-end (the monitoring engine), written in C++, interprets the generated C++ monitor on an event stream. This makes it feasible to monitor the execution of C and C++ programs online.

The research performed was carried out at Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.

A Visualization of Monitors

Textual monitors are automatically visualized using GraphViz’s dot-format [14]. This appendix shows the visualization of the textual monitors presented in Sect. 4.

Fig. 13.

Monitor M1 visualized.

Monitor M1 The monitor M1 in Fig. 2 is visualized in Fig. 13. Hot states (annotated in text with the modifier hot) are visualized as orange arrow shaped pentagons. Orange means danger: this state has to be left eventually. Non-hot states are visualized as green rectangles, we can stay in those “forever” (terminating monitoring in such a state is ok). The initial state Command is pointed to by an arrow leaving a black point. Transitions are labelled with events (and additional conditions as we shall see later). The color red in general indicates error. For example a command issued in the Succeed state causes an error, symbolized with a red cross on a horizontal line.

Monitors M1a, M1b, and M1c The three monitors M1a, M1b, and M1c in Fig. 3 are visualized in Figure 14. Figure 14a, the visualization of M1a, shows how multiple target states are visualized: the transition of the Command state triggered by a command event creates a Succeed and a Command state. This is visualized with a black triangle (symbolizing a Boolean ‘and’: $\wedge$) with dashed lines leading to the target states. Note how in the Succeed state, a succeed event leads to ok which in the visualization is shown as a green dot. The visualization of monitor M1b in Fig. 14b illustrates how an always state is visualized: with an unlabelled self loop. The difference between the visualization of this monitor and of M1c in Fig. 14c is only that the initial state in Fig. 14c has no name.

Fig. 14.

Monitors M1a, M1b, and M1c visualized.

Monitor M2 Monitor M2 in Fig. 4 is visualized in Fig. 15. The difference from previous visualizations is that now events carry data maps, which is shown. It is also shown how bindings to fields in target state maps are created. Specifically, the transition ‘command(name : x, kind :“FSW") => Succeed(c : x)’ from the initial always state is shown as an edge labelled with command(cmd : x, kind : “FSW"), and below it the binding of the c field of the Succeed state (see its definition) to the x that was bound on the left of the => symbol.

Fig. 15.

Monitor M2 visualized.

Monitor M3 Monitor M3 in Fig. 5 is visualized in Fig. 16. The only new visualization concept here is that the transition from the initial always state to the error state is now labelled not only with the event pattern succeed(name : x) but also with the condition pattern !Succeed(c : x) underneath.

Fig. 16.

Monitor M3 visualized.

Monitor M4 Monitor M4 in Fig. 6 is visualized in Fig. 17. Recall that by observing the color scheme one can from the graph quickly understand the violations being checked for: orange means terminating here is a violation, and red means an occurred violation.

Fig. 17.

Monitor M4 visualized.