As briefly mentioned, these monitors act on top of the UPPAAL model. The lowest level of monitors, atomic proposition monitors, are used to relate the model to the frame- work of monitors implementing a property observer. These atomic proposition monitors translate observed propositions in either event- or state channels. Between these atomic proposition monitors and the pattern/scope monitor implementing the property are com- posite monitors that can combine propositions to form new propositions. On top of the hierarchy is the pattern/scope monitor, that observes (composite/atomic) proposition monitors and follows them blindly. Finally, the rule instance decides whether a pat- tern/scope monitor observes an error.
This layered approach allows us to extend any of these three parts making up a property specification without having to alter any other. Implementing a new boolean operator (for example, boolean implication) does not alter atomic proposition monitors nor pat- tern/scope monitors. We believe that this systematic approach to implementing property observes in UPPAAL leads to a highly extensible framework for both the lighting domain and other domains in which such a language is of use.
13 Translation to the Co-simulation
Framework
The Prisma project heavily focuses on simulation of various kinds. Simulation, compared to formal verification, has different strengths and weaknesses. The prime strength, but also the prime weakness of formal verification, is its exhaustive evaluation of all possible paths through a model. If a violation of a property exists, a formal verification tool will find such a violation given enough time and memory. However, this exhaustive search comes with scalability issues, the larger a lighting system becomes, the longer formal verification of properties takes. Increasing the system size in formal verification exponentially increases the possible states the model of such a system can be in and therefore exponentially increases verification times. Simulation, on the other hand, is much more like testing: it evaluates a scenario and concludes whether a violation of a property has occurred in that scenario.
Furthermore, formal verification is intangible. The feedback of a formal verification tool (often an error trace) is a list of actions that reproduce an error. Visualization techniques can be used to produce a tangible display of such an error.
TNO-ESI provides both a simulation and visualization environment for lighting sys- tems. The simulation framework (called Co-simulation Framework) is configured by a transformation from the lighting systems model (instances of various DSLs) to produce the specified behavior. We have extended this simulation framework, and to a lesser ex- tent the visualization environment, to support displaying property results. For validating large buildings, we advise that one first formalizes properties into instances of the Query language and uses simulation to gain an understanding of the system under test. If after substantial simulation no violations have been detected, formal verification can be used to prove that such the system is indeed without errors.
This chapter is structured similarly to the previous one. Firstly, we discuss the Co- simulation Framework as our target. Secondly, we discuss how we have implemented observers for atomic propositions, composite propositions and monitor/rule combina- tions for each pattern/scope in this Co-simulation Framework. Thirdly, we discuss in detail how the judge/verdict implementation for co-simulation was created and how visualization was extended to support verdicts. Finally, we provide an overview of a transformation to the Co-simulation Framework.
13.1 Co-simulation Framework
The Co-simulation Framework (often referred to as cosim) is an in-house developed
simulator framework. This framework aims to allow various simulators to cooperatively simulate a system. For example, in a lighting system, there may be a model for network behavior written in POOSL, whereas the continuous function used to change output levels of a single luminaire is implemented in Matlab/Simulink.
Central to the Co-simulation Framework is a publish-subscribe network that connects various simulators. This network acts as a gateway. A simulatorpublishes messages that
the framework distributes to all the subscribers of such a message. Furthermore, the
Co-simulation Framework is the arbiter of time in simulation. It provides a canonical time that should be respected by all simulators co-simulating a system.
While co-simulation itself is a concept, there is also a reference implementation for lighting systems. This implementation, named JCoSim and written in Java, uses the concepts of such a Co-simulation Framework to simulate a lighting system’s behavior. Within this implementation, there are different simulators for sensors, actuators, sensor groups, actuator groups and controllers. Common to all these simulators is that they publish messages and subscribe to messages of other simulators. The implementation of lighting systems is currently being extended, a Network model written in POOSL is being created and connected as well as a Java implementation of occupancy profiles.
Connecting to such an implementation is a matter of subscribing to the correct mes- sages and is similar to how broadcast channels would work in UPPAAL. The implemen- tation produces messages and sends them to all subscribers. If these subscribers produce a new message as a response, this message is broadcasted until no messages can be pro- cessed. During this cascading messages phase, no time is progressed. For the purpose of the implementation of the Query language, these messages are the only observable behavior of the simulation, the messages being broadcasted:
SetpointOutputLevelMessage A message from controllers to actuators that specifies
the desired output level for actuators.
AchievedOutputLevelMessage A message from actuators that specifies that a certain
output level has been reached. This message was newly added to distinguish be- tween intended and actual output. If for example, a luminaire fades between an old level and a newly requested level using a continuous function, it could continuously send new achieved output levels.
ButtonPressedMessage A message that states that a specific button (group) has been
pressed.
OccupancyDetectedMessage A message that states that a specific occupancy sensor
(group) has detected occupancy.
ControllerStateMessage A newly added message that states that the controller has
reached a specific state. This message was added because of Controller State propo- sitions that would otherwise have no way to observe in which state a controller is.
SetpointOutputLevelMessage SetpointOutputLevelMessage ButtonPressedMessage OccupancyDetectedMessage SetpointOutputLevelMessage OccupancyDetectedMessage ControllerStateMessage ButtonPressedMessage AchievedOutputLevelMessage ButtonPressedMessage OccupancyDetectedMessage AchievedOutputLevelMessage W e bs oc ke t Button Simulator[s] Controller Simulator[s] Visualization Occupancy Simulator[s] Spectrum Actuator Group Simulator[s] OccupancyDetectedMessage OccupancyDetectedMessage ButtonPressedMessage ButtonPressedMessage SetpointOutputLevelMessage Occupancy Group Simulator[s] Button Group Simulator[s] Actuator Simulator[s] Publish Subscribe Network
Figure 13.1: Framework of simulators used to implement a lighting system in JCoSim. The entire pre-existing framework of types of simulators is given in Figure 13.1. A lighting system implementation in JCoSim consists of many instances of simulators dis- played on the left.