The current Query language offers implementations in both UPPAAL and JCoSim but can easily be extended to cover a new tool. Traditional pattern libraries are translated to temporal logics, but these logics are underrepresented in simulation tools. Most tools do however have a notion of a (timed) state machine. The monitors of monitor/rule combinations described in Section 11 can then directly be translated to the new tool leaving only the rule to be specified. However, when implementing this Query language for a new tool, it is important to note that it has been build with certain underlying
features of the tooling in mind. For example, monitor automata need priority over the system under test to prevent desynchronization between the system and the monitors, for JCoSim specifically we had to add priority. Secondly, the Query language heavily uses broadcast communication. Propositions are observed by synchronizing to broadcast channels used internally, or by also subscribing to particular messages sent over the publish subscribe network. Similarly, a single proposition observer can be used in many composite proposition observers. For a tool to be able to implement the Query language, it needs to have a way to capture broadcast synchronization.
Part V
Part Outline
This part serves as a conclusion to the report, we answer the research questions, provide a brief conclusion and outline possible future work. This part is split into two chapters:
Chapter 17 reflects upon the work presented in Part III and uses the validation steps
of PartIV to answer the research questions of Chapter 3. This chapter ends with a brief conclusion of the research conducted.
Chapter 18 shows research that can be conducted to further strengthen the work pre-
sented in this report, we propose to extend the language in expressiveness, attempt reuse across domains, prove the correctness of the extension of the work of Gruhn and Laue (2006) in the form of monitor/rule implementation of pattern libraries and increase feedback provided by refuted properties. We finally discuss a possible change of metamodel used to target the UPPAAL model checker specifically.
17 Results & Conclusions
In Chapter 3 the requirements of the Query language and corresponding research ques- tions were outlined. Throughout Part III choices were made to warrant the desired requirements and in Part IV we validated whether the requirements were met. In this chapter, we first answer the subquestion and using these answers, answer the main re- search question.
17.1 Pattern Libraries as a Foundation
We have chosen to pursue a pattern library approach with the assumption that these libraries allow us to create an easy to use, complete and extensible framework for the development of Query languages. We have also challenged this assumption in validation. In this section, we outline whether using a pattern library as a basis for both the generic Query language as well as the Query language for the lighting domain is justified.
Subquestion 1 Are pattern libraries a solid foundation of an easy to use Query language?
In the usability workshop held within the Prisma team and outlined in Chapter 15, we have validated how well instantiated pattern/scope combinations are understood without significant training. This approach has allowed us to gain understanding on whether the meaning of pattern/scope combinations is intuitive: is it immediately clear whether an
instantiated pattern/scope combination holds for a particular trace? Participants noted that while they felt pattern/scope combinations to be understandable, they initially had difficulties with the concept of formal reasoning. We see the latter as a fundamental problem: regardless of how easy to use a particular Query language approach is, the user is still required to be able to reason formally. However, participants also noted that the use of pattern/scope combinations makes the specification of properties easier and showed significant improvement throughout the session. In terms of learning time, we conclude that compared to traditional temporal logics, learning pattern libraries takes less learning time, but note that both approaches require unfamiliar users to learn of formal methods first.
Subquestion 2 Can a pattern library approach cover all use cases of a formal specifica-
tion language for the lighting domain?
We have not encountered any example property that could not be captured using (a set of) pattern/scope combinations supported in the Query language for the lighting domain outlined in Section 9.4. We have however seen cases where pattern/scope combinations
may need to be altered slightly in semantics. The most notable examples being the duration patterns outlined in Section 11.3.4. We would like to note that the underlying translation to monitor/rule combinations allows these slight variations in semantics.
Subquestion 3 Does a pattern library approach allow easy extension when new use cases
are discovered?
Pattern libraries are extensible by design as only propositions introduce domain knowl- edge. That said, the current selection of pattern/scope combinations for the lighting specific Query language allows to specify temporal and timed temporal properties. If new properties are discovered that require probabilistic reasoning, significant changes may need to be made to monitor/rule combinations.
Subquestion 4 Can a pattern library approach be implemented in both UPPAAL and
the Co-simulation Framework?
The intermediate translation to monitor/rule combinations outlined in Chapter 11 is translated to both UPPAAL and JCoSim and outlined in Chapter 12 and Chap- ter 13 respectively. Implementing monitor/rule combinations in UPPAAL and JCoSim is straightforward, given the timed temporal pattern library selected. When probabilities are introduced, especially the translation to JCoSim needs to be extended heavily.
For the first stage translation, from pattern/scope combinations to monitor/rules, we would like to see a comparison with implementations in traditional temporal logics. Is an implementation of a particular pattern equal in semantics in both temporal logics and a monitor/rule combinations? This proof, however, is not trivial and remains future work.