With a new set of research questions comes a new approach. We have focused less on making a Query language that iscomplete for the lighting domain and more on a Query
language that isextensible. To do so, we have split the approach in two: a generic Query
language usable in any domain and a specific Query language for the lighting domain. For the basis of this generic Query language we have chosen to pursue a pattern library approach for two reasons: pattern libraries are domain agnostic and they appear easier to use than full blown temporal logics. We feel that pattern libraries allow us to set up a framework for property specification easily while remaining open to extension. The exact concepts of this generic Query language can be found in Chapter 8.
The specific Query language, an instance of the generic Query language, serves as a prototype to demonstrate the use of a Query language for the lighting domain. For this specific Query language, we have made a selection of patterns and scopes, composite operators and propositions that can be found in Chapter 9. Furthermore, for this selection we have implemented easy to use syntax and semantics presented in Chapter 10.
The specific Query language for the lighting domain transforms to input for two tools: UPPAAL for formal verification, and the Co-simulation Framework for simulation. By supporting both simulation and formal verification we aim to show Philips Lighting that both techniques are feasible for validation of lighting systems. We have developed a new translation based on the work of Gruhn and Laue (2006) consisting ofmonitorsandrules,
its need and its implementation are outlined in Chapter 11. Finally, in Chapter 12 and Chapter 13 we will describe how these monitor/rule combinations translate to UPPAAL models and Co-simulation Framework configurations, respectively.
8 Generic Query language
The design of the Query language is split into two: a domain specific part and a part that is shared across domains. In this chapter, we will discuss the generic part that consists of concepts common to a Query language for any domain. The subsequent chapter will
discuss how we used these concepts to make a Query language specifically for the lighting domain.
In this chapter, we discuss the abstract concepts ofpropositions,compositions of propo- sitions andproperties. The following chapter creates propositions, selects composite op-
erators for these propositions and finally selects a subset of pattern/scope combinations specifically for property specification in the lighting domain.
8.1 Propositions
A property specification in the generic Query language consists of a pattern holding in a scope, that are both instantiated by propositions. This pattern/scope combination is domain agnostic, but propositions are not. A proposition then, is a truth value, a statement that is true or false. For example, for a lighting system, a proposition could be “The luminaire is on”.
We call a propositionatomic when for a given domain, the proposition cannot be de-
composed into smaller propositions. This atomicity of a proposition is domain specific, for example in the domain of lighting systems, a sensor event is non-decomposable, whereas, in the domain of just sensors, this sensor event might be decomposed in propositions about heat signatures, movement etc.
We make a distinction between two types of propositions:
State Propositions are propositions that are true for a non-infinitesimal interval. “It is
raining” or “A light is on”. At any given moment a state proposition canhold or be refuted.
Event Propositions are propositions that are true for an infinitesimal interval. “It
started raining” or “A message arrived”.
While being different, we can convert state propositions to a pair of event propositions, just take the period in which the state proposition holds and create two event propositions for when itstarts and stops holding. However, converting event to state propositions is
not always possible. A single button press, for example, is singular in nature and does not signal that some sort of observable state property holds for a while. Which (pairs) of event propositions can be converted to state propositions, and how this conversion works depends on the domain.
8.1.1 Proposition Selection per Domain
When selecting propositions to implement in a Query language for a specific domain there are various considerations to be made. First of all, the set of implemented propositions has to evolve together with the domain model for a particular domain: if the domain model is extended to cover a particular (new) aspect of that system (for example, energy usage), new propositions have to be added to write property specifications about that new aspect as well.
Secondly, propositions not only differ per domain, but within a domain a choice can be made to hide or expose particular propositions. In a black-box approach, the system
is regarded as closed and only the externally visible behavior of the system is allowed to be used in property specifications. White-box (sometimes called transparent-box) approaches, however, also allow to use internal details in property specifications.
Both white- and black-box approaches have benefits and drawbacks. While white- box approaches are often easier to use for system property specification, any of these property specifications is stained with knowledge of the internals of a system. This knowledge could hide assumptions that in a black-box approach have to be specified explicitly. Black-box testing, however, can be cumbersome because of limited externally visible behavior. Whether to pursue a black- or white-box approach is a choice that has to be made when instantiating the generic Query language.