As mentioned before, the formulation of formal properties is a tedious task and knowledge about the formal language and the procedure to translate a property is needed. In Sec. 2.4 as well as in [Armbrust 14a] and [Ropertz 12], an extension of the finstruct tool is
described, which enables the user to graphically define queries. The underlying concept is to select behavioural components in the VerificationView of finstruct, transfer them to the Query Development User Interface (QDUI) and connect them via edges representing their relation. The presented concept allows to define rather complex properties, which cannot be formulated in one query. They are automatically transferred to observer automata, which can then be checked to verify the property on the system model. The extension about the environmental influences described in the previous sections can not be represented in that standard VerificationView as the components modelling the sensor chain are not represented there. That means, properties including special conditions of sensors need to be written by hand. This can get a really tedious and error-prone task. The procedure of checking safety related properties shall be presented on the example introduced in Sec. 5.2.2, where a robot faces an obstacle to its front and shall slow down. The example is restricted to the part of the safety layer of ravon given in Fig. 2.10 for readability reasons. The state of this sub-network depends on the output of the fusion behaviour (F) Fast Front Slow Down. The property to be checked in this example can be written as follows:
R1) (F) Fast Front Slow Down ((F) Fast Front SD) shall be active if an obstacle is present in front of the robot.
The corresponding query
E<> F_Fast_Front_Slow_Down_a_value==0 && scenario_now.obstacle_front && !Processing()3
uses the negation of the property “(F) Fast Front SD shall be active”.
The result of the model checker states that it is possible that the behavioural component will not get active even if there are obstacles. The back trace reveals that failures in all sensor chain links can lead to that result. As consequence, failures must be excluded step-by-step to find the conditions under which the property is fulfilled. For example,
E<> F_Fast_Front_Slow_Down_a_value==0 && scenario_now.obstacle_front
&& laser_2d_real_sensor.Correct && front_cartesian_laser_2d_virtual_sensor.Correct
can be used to check whether the property is fulfilled in the case of one correct working real sensor and a corresponding correct virtual sensor.
To simplify the creation of such requests, an extension to the VerificationView is developed. The new SafetyQueryView (SQV) shall fulfil the following requirements:
SQVR 1) Components of the sensor chain and scenario information shall be integrated into the VerificationView of RRLABfinstruct
SQVR 2) Graphical support during query generation
SQVR 3) Integrated possibility to check the query on the formal model from within finstruct
SQVR 4) Display the trace of the witness or counterexample in the TraceView of finstruct using the integrated representation from the first requirement
Figure 5.20: Main window of finstruct’s VerificationView showing a small part of ravon’s
safety layer with integrated sensor chain (yellow boxes) (cp. Figure 2.10 showing the same network without the integration)
Figure 5.20 shows the integration of the sensor chain and the scenario into the Verifica-
tionView (requirement SQVR 1). The information of the connections between sensors and
safety behaviours is extracted from the formal model that underlies the following model checking procedure. The model serves as basis for all parts of the SafetyQueryView.
(a) The tab of the SQCW showing the behavioural components included in the model and
some of their properties
(b) The tab of the SQCW showing the scenario automaton
Figure 5.21: Two views of the Safety Query Construction Window (SQCW)
For the graphically supported creation of queries (requirement SQVR 2) a new window, called Safety Query Construction Window (see Fig. 5.21), is created. It displays the different components of the formal model in different tabs (All as table,Scenario,Real
Sensor, Virtual Sensors, Behaviours). These tabs contain tables with one line for every
behaviour/sensor automaton and columns with the name and properties of the component. As example, for behaviours the properties Active and Inactive are displayed, as those are the most frequently asked properties of a safety behaviour. For the definition of other properties, the table can be easily extended. The cells corresponding to a special
3
As mentioned in Sec 5.2.1, the Processing flag needed because of Uppaal’s special restrictions. For the sake of clarity it is left out in the following queries.
Figure 5.22: Extended TraceView including the sensor chain and the scenario. The states of
the sensor components that represent states of the backtrace of the model checker are displayed in the yellow box below the component’s box. The green and red balls on the upper left edges of the boxes illustrate the state of the component additionally.
component and property contain a drop-down menu to allow the user to define the state (Forced, Forbidden or Don’t care) of the property for this component. Once, the user chooses a special state, the respective part of the query is written in the query text field in the lower half of the window. As the component tables can become very large for big networks, it is possible to select a component in the VerificationView, which will highlight the corresponding component in the table to simplify the identification. One exception of the table representation of the components is the Scenario tab. As the scenario is normally a very simple automaton, a more intuitive representation which shows the original automaton with the possibility to right-click on a location to select a certain state is chosen (see Fig. 5.21b). The query field shows the final query and offers the possibility to select the type of the query and to negate the whole query. Additionally, a comment can be added.
The window offers the functionality to create several different queries for the model and save them into a file. Furthermore, according to requirement SQVR 3, it is possible to automatically check the query/queries on the formal model. Here, it is also possible to choose a verifier on an external machine, which is useful in case of computationally intensive queries.
The result of the model checking process is displayed in a pop-up window and the trace to the witness or counter-example can be shown in the TraceView as required in SQVR 4. The trace is a sequence of states of the formal model. This means the state of every automaton is given for every step in the trace. An example that depicts one of these steps is presented in Fig. 5.22. It shows the same components as Fig. 5.20 with the difference that additionally the states of the automata corresponding to the sensor processing components are illustrated. This is done using a textual information with the state name as well as a symbol indicating if this is a failure state. This visual support allows the developer a quick and easy insight into the model checker’s result. More information about the implementation details of the SafetyQueryView and the underlying concepts can be found in the bachelor’s thesis of [Vonwirth 15].