When evaluating such a split, UPPAAL is of first concern. UPPAAL, unlike the Co- simulation Framework, cannot be extended easily and therefore we need to create the pattern/scope combinations using the tools it provides. In UPPAAL, the modeling for- malism is timed automata while the property specification language is a subset of TCTL. This subset consists of five temporal operators operating on boolean expressions. These expressions reason about the current state of the system (variables, current state, clocks, etc.). The five temporal operators supported in UPPAAL are:
model. In TCTL:EFexp.
Invariantly An expression is true in all states along all possible paths in the model. In
TCTL:AGexp.
Potentially Always An expression is true in all states along at least one possible path in
the model. In TCTL:EGexp.
Eventually An expression is eventually true along all possible paths in the model. In
TCTL:AFexp.
Leads To If along a possible path an expression is true, then at some point in the
future of that path, another expression becomes true as a response. In TCTL:
AGpexp1 ÑAFexp2q.
This set appears to have been carefully selected to cover different properties. There are temporal operators for specification of liveness properties (Possibly, Eventually, Leads To) and temporal operators for specification of safety properties (Invariantly, Potentially Always). Some operators specify properties that hold for all paths (Invariantly, Eventu- ally, Leads To), others specify properties that can also be true if they hold for at least a single path (Possibly, Potentially Always) etc.
Not only is the set of temporal operators carefully selected, the modeling formalism (timed automata) is also quite expressive. Doornbos et al. (2015) have used UPPAAL to verify parts of the lighting systems of Philips Lighting manually. While they did not employ a generic approach as outlined in this research, they found that splitting property specifications into an automaton and a (simple) TCTL query is indeed expressive enough to cover properties they intended to verify. Furthermore, the works by Gruhn and Laue (2006) have shown that pattern libraries can also be translated to (a more expressive version of UPPAAL’s) timed automata.
The realization that the TCTL subset of UPPAAL is not as restrictive as we had feared, the promising results by Doornbos et al. as well as the pattern library translations to timed automata by Gruhn and Laue (2006) made us split the translation in what we call a monitor and a rule. These monitor/rule combinations offer an alternative way
of translating a timed pattern/scope combinations to a form usable in both the Co- simulation Framework and UPPAAL.
A monitor is a timed state machine that faithfully follows the execution of the system under test. A monitor automaton is reactive: it can respond to observations made of the actions in the system under test but does not progress on its own. A monitor is also impartial, while the structure of such a monitor encodes a certain pattern/scope combination, a monitor alone cannot conclude that a property is violated. Finally, a monitor is prioritized over the rest of the model, meaning that if a monitor can transition, it will do so before any transition in the model can be taken. These monitors are like the observers of Gruhn and Laue (2006) but we separate rules and monitors, provide implementations of extra patterns, have slight variations on semantics of some patterns
and better monitors for properties on state propositions. While certainly overlapping with the work of Gruhn and Laue, we do add on top of their approach.
Rules operate on top of these monitors and analyzes the sequence of states that a mon- itor is in. These rules correspond to three of the TCTL queries expressible in UPPAAL’s TCTL subset: Invariantly, Eventually and Leads To. The two remaining UPPAAL oper- ators, Possibly and Potentially Always, are of the existential kind, but no pattern/scope combination in our library is. These rules are more explicitly executable in both UPPAAL and the Co-simulation framework. The three rules are:
Forbidden Rule A state of the monitor cannot be reached, if the state is reached the
property is refuted. In TCTL:AG ERROR.
Eventually Rule A state of the monitor has to be reached eventually, if it is never reached
the property is refuted. In TCTL:AFOK.
Response Rule An occurrence of a certain monitor state has to be followed by the occur-
rence of another certain monitor state eventually, if the “cause” happened, but no “response” happens, the property is refuted. In TCTL: AGpCauseÑAFEffectq.
Finally, what we call a judge is the (part of a) tool that receives the (consecutive)
states of a monitor and produces a verdict. This verdict is a message that conveys the
validity of a property. In UPPAAL we reuse the model checker as the judge, rules are specified in TCTL and the model checker either says the property holds or is refuted. In the Co-simulation Framework, however, we have created a custom judge as part of the framework that produces verdicts continuously.
To support a new tool, a system has to be found or created that can act as a judge, the rules have to be translated to some form that the tool understands and finally, the monitors have to be implemented. We believe that this framework of rules, monitors, judges and verdicts is easier to implement in a new tool than implementing a full timed temporal logic.