The network structure of behaviour-based systems can be seen as equivalent to a program dependence graph (pdg). In a pdg, program statements and expressions represent the nodes of a graph, edges define the dependencies between them. For behaviour-based systems this definition is adapted so that nodes represent the state of a behaviour component and edges the connection between components. A state of a component is defined via its stimulation, activity, inhibition, target rating and activation (see Sec. 2.2). The new structure will be called behaviour dependence graph (bdg) in the following.
Definition 4.1: Behaviour Dependence Graph
A behaviour dependence graph GBD = (N, E) is a directed graph, where N is a set of behaviour nodes and E a set of edges. A behaviour node ni is defined via its incoming and outgoing behavioural signals sb = (s, a, i, r), with s being its stimulation, a its activity, i its inhibition, and r its target rating. An edge e = (nj, nk) describes the dependence from node nk on node nj.
The understanding of how signals are propagated in the network supports the comprehen- sion of behaviour functionality. Therefore, it is of interest to create different behaviour dependence graphs according to certain signals. For example, a stimulation graph shall only contain those components that are connected via a stimulation transfer. In order to do this, the definition of the bdg is extended to
Definition 4.2: Typed Behaviour Dependence Graph
A typed behaviour dependence graph (tbdg) is a bdg with an additional type property t ∈ {s, i, d}, with s indicating stimulation, i inhibition and d data transfer. The tbdg GT BD(t) = (V, E(t)) contains those nodes n ∈ V ⊆ N that are connected via edges that transfer signals of type t.
Figure 4.4 shows two typed behaviour dependence graphs. The comparison with the example graph given in Fig. 4.2 reveals that behaviour C is not contained in GT BD(s) (Fig. 4.4a) as it does not stimulate another behaviour. The activity transfer edges from behaviours A and D to the fusion behaviour are included as they are relevant for the stimulation output of the fusion behaviour. For the data transfer graph (Fig. 4.4b), behaviour B is not contained, as it does not transfer its data to any other behaviour. The comparison of bdg’s of different types can also reveal failures in the network structure of the graph. Figure 4.4c highlights the differences in the graphs GT BD(s) and GT BD(d). Node B transfers only its activity and not its data vector to the fusion node. This transition is correct, as B stimulates the fusion node with its activity. In turn, node
C transfers its data vector without a corresponding activity vector. This is a fault and
must be corrected. A corrected version of the example graph is given in Fig. 4.5a, where all previously detected faults are eliminated. Here, the missing stimulation of behaviour
A B Fusion D E F
(a) Graph representing the
stimulation graph GT BD(s) A Fusion C D E F
(b) Graph representing the
data transfer graph GT BD(d)
A B Fusion C D E F
(c) Graph representing the
difference of GT BD(s) and
GT BD(d) in the set of nodes
Figure 4.4: Examples for typed behaviour dependence graphs
C is fixed by adding a self-stimulating edge. Additionally, the component transfers its
activity to stimulate behaviour D. The stimulation cycle A → B → F usion → E → A is disrupted by removing the edge E → A.
Another usage of behaviour dependence graphs is the influence graph. This is a sub-graph of the bdg that contains only those nodes that influence a specific one. This is especially useful in large networks to reduce the size and focus on the relevant parts. An influence graph is defined as follows
Definition 4.3: Typed Behaviour Influence Graph
A typed behaviour influence graph (tbig) GT BI(t, ninitial) is a tbdg containing the maximal set of nodes V ⊆ N such that for all n ∈ V there is a path from n to
ninitial using edges e ∈ E(t).
Figure 4.5b depicts such a graph for the start node E tracing the control data input. These kind of influence graphs can also be used to make statements about the relevance of components. The assumption is, that a component that influences many others is more relevant than a component that influences only a few. Certainly, all components in a behaviour-based control network should be relevant to make the system work as required, but, when analysing a system in order to find the causes of failures it might save time to start analysing those behaviours, that influence many others. Alg. 4.1 shows the algorithm to determine the relevance of nodes. For the determination of the number of nodes that are influenced by a special one, firstly, the tbigs for every node are created. Afterwards, the occurrence of the special node is counted over all influence graphs.
Figure 4.5c shows graphically the results of the algorithm for every node in the example graph according to the flow of control data. The colour gradient from red to yellow indicates the frequency of the individual nodes. The control data from node C influences four other nodes, namely D, F usion, E, and F . Nodes D and A influence three nodes, respectively and the fusion node the two nodes E and F . Finally, the nodes B, E and F do not influence any other node with their control data.
A B Fusion C D E F
(a) Corrected example graph
A
Fusion C
D
E
(b) Graph depicting the in-
fluence of control data on be- haviour E A B Fusion C D E F (c) Relevance of behaviours
in respect to the data flow (red: most relevant, yellow:
less relevant)
Figure 4.5: Examples for an influence graph and a graph depicting the relevance of behaviours
using different fill colours
Algorithm 4.1: Determination of frequency of occurrence of nodes
Input: graph, type, node
1 forall the n ∈ N do
2 gn := CreateInfluenceGraph(type, n);
3 Push(gn, influence_graphs);
4 end 5 count:= 0;
6 forall the gn in influence_graphs do
7 if node ∈ gnthen
8 count++;
9 end
10 end
Result: count
The automated analysis together with the multiple visualisation possibilities allow the developer a quick overview over the system. The different views facilitate the detection of faults and the verification of structural requirements.