Part of the compilation process of the abstract syntax to both UPPAAL and the Co- simulation Framework is shared in a process that is often called desugaring. In this
process, we reduce a Query language instance to a set of (atomic/composite) propositions and (instantiated) pattern/scope combinations by removing controller references and parameters. The resulting input to the specific generation steps of both the UPPAAL model as well as the Co-simulation Framework configuration resembles the abstract model presented in Figure 9.1.
Consider the example in Listing 10.1, the with-each-controller statement specifies that
ctrl1refers to a controller implementing theMeetingRoom1Template. The lighting system to
which this Query instance is bound specifies only one controller that does. In other words, we can remove the with-each-controller statement by replacing each occurrence of ctrl1
by a direct reference to that particular controller. Similarly, when multiple controllers do implement a particular template, we can “unroll” the implicit loop by systematically copying the block of the with-each-controller and replacing ctrl1with a direct reference
to each controller implementing that template.
The second form of desugaring replaces references of parameters by their concrete value. In the example in Listing 10.1 we specify a Timer proposition that fires after “hold time” seconds. This hold time is either specified in the controller or inherited from the template. Crucial, however, is that this hold time cannot change, it is aconstant. The
default value of the hold time specified in the template is 600 and the (single) controller implementing this particular template has not overridden this default. We can replace
11 Generic Translation: Monitors and
Rules
In the traditional works of pattern libraries (discussed in Chapter 5), propositions are left to be specified. Translations of pattern/scope combinations assume that these proposi- tions can be observed. For example, when translating the property specification “Glob- ally: Absence P” to CTL, the proposition P is assumed to be assigned by a labeling func- tion to states in the model for which this proposition P holds. The Query language we propose has made this labeling function explicit by introducing specifications for (atom- ic/composite) propositions. The implementation of observers for these propositions are dependent on the target for translation and will be discussed separately in Chapter 12 (for UPPAAL) and Chapter 13 (for the Co-simulation Framework) respectively.
The other aspect of translation, translating pattern/scope combinations, has been ex- tensively researched in the various pattern library approaches. While we initially planned on using an existing translation, we were unable to reuse any of these. We have therefore split our translation into two parts, first, we translate a pattern/scope combination to an intermediate form and second, we translate that intermediate form to the tools we support. This chapter will outline why we need such an intermediate form and how it was created. The two subsequent chapters discuss the implementation details for both UPPAAL and the Co-simulation Framework.
11.1 The Need for a Two-Stage Approach
As we use a pattern library approach, it would make sense to use a direct translation to temporal logics. Since we are dealing with timed temporal specifications, the obvious translation candidates would be either MTL or TCTL as described in Chapter 4.
These direct translations are problematic both in the formal verification and the simu- lation flow. The Co-simulation Framework does not have a notion of checking a property against a (path in a) lighting system meaning that either way, we have to extend the Co-simulation Framework to support the Query language. While implementing MTL or TCTL for simulated paths has been done before (for example MTL has been implemented in the TRACE tool by Hendriks et al. (2016)), we do not need the full expressiveness that such an implementation offers. The set of pattern/scope combinations is small, and therefore we only use a small number of TCTL/MTL constructs. Implementing full TCTL/MTL in the Co-simulation Framework is a sizeable amount of work that we would rather avoid for its limited use in the Co-simulation Framework.
temporal logics have been created to use in model checking and many papers have been written about how to employ these logics in such contexts. However, while not set in stone, the Prisma project has selected UPPAAL as its verification tool. UPPAAL does support TCTL, but only a very restricted subset. The restriction is so severe, that any pattern/scope combination from our pattern library almost certainly translates to a TCTL formula that is not supported by UPPAAL.
That observation raises the question whether UPPAAL is the right choice if its TCTL subset is so restrictive? While exploring different model checkers we found that UPPAAL is unique in the field of practical model checking. There are very few timed model checkers that are as well maintained as UPPAAL and we have found no model checkers that on top of that, also support full TCTL or MTL. The only other candidate we have found is called Kronos by Yovine (1997) and claims to implement both a timed formalism and full TCTL, but Kronos is largely unmaintained. Its successor, OpenKronos by Tripakis (1998) has since been released and also abandoned. Both tools have not gained the traction that UPPAAL has. UPPAAL is surprisingly unique in its formalism, its level of maturity, and its easy to use interface.
On the other hand, we have encountered many model checkers that are not timed but have implemented full (untimed) temporal logics. If the models can be transformed into a non-timed formalism, we can use an untimed model checker like NuSMV by Cimatti et al. (1999). The current model of the lighting system uses quantitative time to model timing behavior such as hold time: the time before a vacant room returns to the “Off”
preset. Hold time could however also be modeled using a non-deterministically occurring timeout event. While there are indeed cases in which timing can be removed, we have seen specifications in which it can not (for example the property specified in Listing 14.1). Furthermore, newly created auxiliary models like Network do add more timing to the model. We believe strongly that removing timing from the models will hamper both expressiveness and extensibility of the Query language approach.
Using timed temporal logics as our target for translation is infeasible in both formal verification an simulation, leaving us with no choice but to split the approach in such a way that we can express these pattern/scope combinations without using full timed temporal logics.