Model Reduction Using Slicing Techniques

In contrast to the previously described methods, that are based on the formal model, the slicing technique introduced by [Weiser 81] reduces the program code. The reduction is done according to a given slicing criterion. In a first step, the code is decomposed based on a data and control flow analysis. The result is called Control Flow Graph(cfg), where nodes correspond to program statements and edges relate to the control flow. The elements of the graph that form the slice are computed according to the slicing criterion which is defined as a pair c = {s, v}, where s is a statement in the program and v represents a set of variables. 𝒙 = 𝟓 𝒙 > 𝟐 𝒛 + + 𝒚 = 𝟔 𝒚 = 𝟕 𝒐𝒖𝒕 𝒚 START END x=5; if (x>2) then y=6; else y=7; z++; output y; 𝒙 = 𝟓 𝒙 > 𝟐 𝒚 = 𝟔 𝒚 = 𝟕 𝒛 + + 𝒐𝒖𝒕 𝒚 T F Data Dependence Control Dependence

Figure 6.1: Example of a control flow graph (middle) derived from a C program (left) and the

corresponding program dependence graph (right) [Yatapanage 12]

Following research is often based on a so-called Program Dependence Graph (pdg). Here, statements and expressions represent the nodes of the graph, edges define the dependencies between the nodes (see [Ottenstein 84] for the first approach with this topic). Figure 6.1 shows an example of a cfg and a pdg from a given program.

Having this graph representation, a slice is received via a backward traversal starting from the node of interest, which is defined by the slicing criterion. Figure 6.2 shows the general procedure to create a slice from program code.

For debugging purposes usually backward slicing is used, which means that the resulting slice contains those elements that directly or indirectly influence the node of interest.

Programme _{Graph (CFG)}Control Flow DependenceProgram

Graph (PDG)

Slice

Criterion

Figure 6.2: The steps to create a slice from program code

Forward slicing [Bergeretti 85] starts from the point of interest and traverses the graph to

find out which other nodes are affected by the start node. This method is used mainly for dead code removal and software maintenance. Slicing methods can also be distinguished in static and dynamic slicing. A dynamic slice is computed with respect to a specific test case or rather a certain set of input variables. Static slices are extracted without making assumptions about the input.

Apart from the methods that operate directly on program code, several approaches that use specifications written in other languages were published in the last decade. For example, [Androutsopoulos 13] surveys the domain of state-based model slicing, which refers to slicing on the basis of finite state machine based models. Especially interesting in that context is the work of [Thrane 08], which apply slicing to Uppaal models to achieve a syntactic reduction. Their experiments proved the advantages of using slicing methods in combination with the existing internal reduction strategies. Unfortunately, this work doesn’t seem to be continued or even be integrated into the Uppaal toolbox.

[Yatapanage 10] apply slicing to models written in the graphical Behaviour Tree language, whereby a behaviour tree is derived from the requirements the system must fulfil. For the automation of the slicing procedure, the slicing criterion is not manually defined but derived from a property (often) written in a formal language. That implies, that the criterion not necessarily corresponds with one node in the pdg but can refer to several statements. This technique of property-directed slicing was first introduced by [Hatcliff 00] and will be applied to the behaviour-based system used in this thesis as well.

An approach which includes the external environment into the verification process is presented in [Matsubara 12]. The paper introduces a variable dependence graph (vdg), which is similar to a pdg with a difference in the data unit. Before the actual slicing procedure, the parts of the system that are relevant to the given property are defined manually. Irrelevant parts are treated as part of the external environment and are not modelled in detail. The authors also developed a tool which supports the slicing and verification process by graphically representing the results.

For behaviour-based systems the need to identify context-specific relevant parts is already discussed in Sec. 4.1. Influence graphs, which include those nodes that influence a certain one, seem to be similar to a slice as defined in the former. The remainder of this section, discusses the application of the slicing technique to behaviour-based systems and presents the developed tool support on an application example.

6.2.1

Slicing of Behaviour-Based Systems

In this thesis, the verification of behaviour-based systems refers to the verification of the network structure. The formalization is done by modelling each behavioural component as a set of finite-state-machines, and connect those sets according to the connections in the network. The size of the formal model is therefore related to the size of the network. This implies, that a reduction of the network would decrease the model size.

In Sec. 4.1, the network structure is presented as behaviour dependence graph. With having this structure automatically when developing behaviour-based control systems, the first two steps of the regular slicing approaches - the creation of the data flow graph and the program dependence graph (see Fig. 6.2) can be omitted.

The slicing criterion must be defined in relation to the property, that should be checked on the formal model. For the definition of the slicing criterion, the approach at hand is based on the property-directed slicing technique introduced by [Hatcliff 00]. According to this, a slicing criterion can refer to several nodes in the graph. This is important, as queries for models of behaviour-based systems often contain more than one element (see Sec. 5.4 for examples).

A slicing criterion for a behaviour dependence graph must therefore contain the set of graph nodes B(p) that corresponds to the formal query related to the property p. The slicing criterion is defined as follows.

Definition 6.1: Slicing Criterion

A slicing criterion C for a behaviour dependence graph GBD is a non-empty set of nodes {n0, ..., nk} where each ni, with i ∈ [0, k], is a node in the behaviour dependence graph. The slicing criterion C(p) for the property p contains all nodes in B(p) ⊆ GBD.

The slice S(p) for the property p is extracted from the bdg GBD via a backward traversal starting from the nodes included in the slicing criterion. Here, every node is included into the final slice only once to avoid infinite traversals. The resulting slice is a graph

S(p) ⊆ GBD that contains all components corresponding to C(p) and all components that

influence them. Usually, only one slice emerges containing all nodes of C(p). If there arise two or more slices this implies that the behavioural components of C(p) have no common basis. In order to minimise the model as much as possible, it is useful to split the property and prove each with its corresponding slice. In contrast to influence graphs presented in Sec. 4.1 a slice can have more than one start nodes and the resulting graph contains connections of all types.

According to Chap. 5.3, where an extension of the formal model is presented, properties can also include environmental conditions and states of sensor components. As those components are not part of the bdg they have no influence on the slicing process. The environment is still integrated in the model as soon as a safety behaviour is contained in the slice.

Figure 6.3 gives an example for the slicing of behaviour networks. The complete network in Fig. 6.3a contains 16 behavioural components where three are encapsulated in a group (G) G1. The property to check is Is it possible, that behaviour (F) FB4

(G) G1 (F) G1 BL4 BL0_G1 BL1_G1 (F) G0 (F) FB4 (F) FB3 (F) FB2 (F) FB1 BL3 (F) FB0 BL6 BL5 BL2 BL1 BL0

(a) Behaviour dependence graph

(G) G1 (F) G1 BL4 BL0_G1 BL1_G1 (F) FB4 BL3 (F) FB1 BL2 (b) Slice Legend: behavior fusion behavior stimulation inhibition activity transfer target rating trans- fer

Figure 6.3: The original graph 6.3a and the slice 6.3b created according to the slicing criterion

C(p) = {(F )F B4}

gets active?. From this, the slicing criterion C(p) = {(F )F B4} is formulated. The corresponding slice is pictured in Figure 6.3b.

The sliced graph S(p) consists of only eight behaviour modules which is only half the number of the original graph. The generated formal model of the sliced graph consists of 30 automata with a total of approximately 55 locations and 71 edges in contrast to the model of the full graph with 64 automata (95 locations, 143 edges).

6.2.2

Tool-Assisted Slice Generation

In this section, the advantages of the slicing procedure shall be pointed out on the example presented in the previous chapter (see Sec. 5.4). Furthermore, the extension of finstruct’s

VerificationView, that allows to execute the process and to display the results are discussed.

The property to prove is again

P1: (F) Fast Front Slow Down shall be active if an obstacle is present in front of the robot.

It was verified on a small part of ravon’s safety control, namely the group (G) Fast Front

Slow Down. This group was chosen manually in order to keep the formal model as small

as possible. This is additional effort which can be reduced when executing the previously described slicing procedure.

In order to simplify the application of slicing techniques to behaviour-based networks, the functionality is integrated into finstruct’s VerificationView. The tool is enhanced by the following features:

SV 1 Automatic slice creation for a property inserted as query

SV 2 Possibility to define the initial behavioural component for the slice manually in the graph view

SV 3 Display a slice

SV 4 Creation of a formal model from the slice

With the integrated automated slicing process, the model checking process containing the creation of the formal model and the submission of a formal property stays the same as described in Chap. 5. The slice corresponding to the given property is calculated in the background and the formal model of the slice is used as input for the model checker. This can also be done for several queries at the same time, which highlights one of the major advantages of applying the slicing procedure to the verification process of behaviour-based networks. The scope of the network must not be defined manually for each property in order to keep the resulting formal model small. It is done automatically and guarantees to output a minimal network including all relevant components.

For the developer, it might be of interest to view the slice displayed in the context of the overall network. This functionality is also integrated in the network view of finstruct. Figure 6.4 shows a detail of the group (G) Full Speed Safety Control (cp. Fig. 2.6) with the slice related to the example. All components belonging to the slice are shown in full colour, whereas other components are greyed out. Here, the slicing criterion was extracted from the property C(p) = {(F) Fast Front Slow Down}. The slice is calculated using this element as starting position in the behaviour dependence graph. The resulting slice includes the starting fusion behaviour of the group (G) Fast Front Slow Down and the four inner groups, that deliver data to it. All behavioural components inside the four groups are connected to the respective fusion behaviour and are therefore included in the slice as well. Due to readability constraints, only one of the groups is exemplarily unfolded. The example shows again the possibility to dramatically reduce the model when using slicing. The overall group contains 112 components, whereas the slice includes only 14. The advantage of using the bigger group is to be able to create several queries containing components of different groups without changing the view.

The slicing functionality can also be used independent from query definition. The network view provides the possibility to mark single behavioural components as starting point for the slicing procedure. This enables the user to easily detect dependencies in the network structure. This view can also be used for the analysis tasks discussed in Sec. 4.1.