To implement the Query language in such a framework of simulators we have used a similar approach as to the one used for UPPAAL. We have added simulators to the pre- existing approach that observe the lighting system. These (atomic/composite) propo- sition simulators interact similarly to their UPPAAL counterparts: atomic proposition simulators observe the lighting system, composite propositions simulators observe atomic propositions and monitors observe (atomic/composite) propositions. Finally, these mon- itors are observed by a judge that uses its rules to reach a verdict.
13.2.1 Atomic Proposition Simulator
Atomic proposition simulators are the entry point to the Query language implementa- tion. These simulators are the only simulators directly connecting to other simulators implementing a lighting system. These simulators act as translators, they receive for ex- ample a ButtonPressedMessage, and translate this to an EventPropositionMessage used internally by the proposition monitors. As such a publish-subscribe network is distinctly event based, updates of state propositions are only sent on flanks.
Consider for example the implementation of the ActuatorLevelProposition, in JCoSim, this proposition is implemented as a simulator subscribed to all AchievedOutputLevelMes- sages. When receiving such a message, the simulator checks that the actuator is indeed the one it is interested in and compares the newly broadcasted level with its desired state. If the state of its a proposition changes, this simulator sends a StateProposition- Holds/Refutes message over the publish-subscribe network when the proposition starts or stops holding respectively.
13.2.2 Composite Proposition Simulators
Composite proposition simulators are used to observe composite propositions. In JCoSim these are also implemented as simulators that subscribe to the (atomic/composite) sub- propositions and publish messages for the combination of these sub-propositions.
Consider for example boolean AND for states. Such a simulator subscribes to StatePropo- sitionHolds/Refutes messages and tracks the states of all state propositions it is inter- ested in. Just like the ActuatorLevelProposition simulator, once it detects change in the validity of the observed proposition (from holds to refutes or vice versa), it sends a StatePropositionHolds/Refutes message accordingly.
13.2.3 Monitor Simulators
In JCoSim, there are specialized state machines used to model the state of a controller. These state machines, and their underlying semantics, are so specific to the controller that repurposing this framework for the use of monitors is infeasible. Instead, we have added a new (generic) timed automata model as well as a corresponding execution environment to JCoSim. This execution environment is both discrete and eager, time can only progress in discrete steps and as soon as a transition is enabled, it will be taken. Furthermore, nondeterminism is implemented by choosing an arbitrary transition possibly leading to different executions for the same scenario.
The model of timed automata is much like that of UPPAAL but simplified. A transition in such a model can have a synchronization (both in and out), clock reset or simple clock guard (comparing a single clock with a fixed value). While easily extended to support variables, boolean operators in guards etc. we have not needed any of these concepts to implement the monitors of the generic translation.
Consider for example the monitor for “Between Existence” withenableras event propo-
the event proposition that should exist within that scope. The implementation of such a monitor is given in Listing 13.1.
// States of the monitor
public enum BetweenExistenceState implements MonitorState { Initial , Sensitive , Exists , ERROR
}
new Monitor <>( BetweenExistenceState . Initial , // Initial state
Arrays . asList ( // List of transitions
new MonitorTransition <>(
BetweenExistenceState . Initial , // Source state
BetweenExistenceState . Sensitive , // Destination state
enabler // Incoming sync
), new MonitorTransition <>( BetweenExistenceState . Sensitive , BetweenExistenceState . Exists , signal ), new MonitorTransition <>( BetweenExistenceState . Exists , BetweenExistenceState . Initial , disabler ), new MonitorTransition <>( BetweenExistenceState . Sensitive , BetweenExistenceState .ERROR , disabler ) ) );
Listing 13.1: Monitor implementation for Between Existence in JCoSim
The monitor simulator is then responsible to subscribe to all propositions used in such a monitor and sends messages over the publish-subscribe network indicating when it has reached a new state. For the Judge simulator, only the current state of a monitor is observable.
13.2.4 Rules, Verdicts and Judge Simulators
In UPPAAL rules are implemented as TCTL property specifications with the query evaluator acted as the judge. This judge in UPPAAL concludes for each property whether it holds or otherwise produces a counterexample. JCoSim however, has no notion of such a judge and has to be extended. Implementing this judge was not without issue, the rules specified in the monitor/rule combinations are of two kinds: safety and liveness rules. Safety rules have finite counterexamples, so in simulation it is possible to conclude that such a rules have been violated. Liveness, however, does not have finite counterexamples. Imagine for example a rule that states that a specific monitor state is eventually reached, how long do we have to simulate a lighting system to assert that such a rule holds? For
such a rule we could say that we do not know whether the property is true until we have observed the desired state. Now imagine a rule that asserts that an occurrence of a single state has to be responded to by the occurrence of another, how often do we have to observe this responding state before we can assert that such a rule holds?
These problems arise from the unique requirements for a judge in JCoSim, we want to use the judge to produce a continuous stream of verdict messages that indicate the validity of a property at this point of the simulation. UPPAAL only produces such a verdict after evaluating a potentially infinite path and can, therefore, be absolute. These verdicts for simulation fall into four categories:
Error indicates that a rule has been violated. OK indicates that a rule can no longer be violated.
Maybe Error indicates that a rule has not yet been violated but if the current situation
remains indefinitely, the rule is violated.
Maybe OK indicates that a rule has not yet been violated and if the situation remains
indefinitely the rule is not violated.
Rule instances in JCoSim observe states of monitors and produce verdicts in the fol- lowing ways:
Forbidden Rule produces the Maybe OK verdict before the forbidden state has been
reached and Error after.
Desired Rule produces the Maybe Error verdict before the desired state has been reached
and OK after.
Response Rule produces the Maybe OK verdict before a cause happened, and Maybe
Error if a cause occurred, but has not yet been responded to by the effect occurring.