The Behavior Tree (BT) notation is a graphical notation for specifying system behaviours, originally developed by Dromey to support the process of capturing requirements and transforming them into designs [Dro03, Dro06]. Dromey adopted the tree structure no-tation to help cope with complexity because humans have more difficulty coping with an arbitrary graph structure. Other issues that strongly influenced the design of the Behavior Tree notation include:
• traceability to requirements, and
• integrating several trees (from several requirements) into a single tree.
Figure 2.1 shows an example BT that specifies the operation of a simple, perhaps unrealistic, vending machine. The system starts with the vending machine in a ready state, and waits for a customer to insert a coin. After a customer inserts a coin, the system waits for the customer to select either candy or chips. Once the customer selects either candy or chips, the vending machine dispenses the appropriate selection, and the cycle is repeated.
A BT consists of nodes (drawn as boxes) representing actions and arrows between nodes representing control flow. The tree structure of a BT represents the basic con-trol flow structure, which consists of sequencing and branching. In the example, there is an alternative branching after a customer inserts a coin. The branch taken depends on whether the customer selects candy or chips. In the BT notation, the selection of alternatives is based on guards. There is another kind of branching in the BT notation called parallel branching. Unlike alternative branching, all branches in a parallel branch-ing are taken and each branch starts a new subthread. Sequential nodes may be merged to form an atomic composition whereby the execution of the sequence of nodes becomes indivisible and uninterruptible.
In addition to the basic control flow structure, there are other control flows in the BT notation, specified using control flow directives. In the example, there are nodes with the reversion (∧) directive. The reversion directive is the most important of all BT directives, as it is the directive for constructing a loop. It kills and restarts the execution of a subtree rooted at its “matching” node. Killing the execution of a subtree causes all threads activated in the subtree to be killed as well. Since the kill and restart are intended
2.4. BEHAVIOR TREES 19
Figure 2.1: Simple Vending Machine BT
to produce a loop, the subtree must include the node with the reversion directive, thus the matching node must be an ancestor of the node with the reversion directive. In the example, the matching node for both reversions is the root of the entire BT. Other BT directives include the reference (=>) directive (similar to “go to”), the kill (−−) directive for killing the execution of a subtree, and the synchronise (=) directive for synchronising threads.
The BT notation allows a sequence of nodes to be composed into an atomic compo-sition, drawn as a contiguous sequence of boxes without arrows. The nodes in an atomic composition is executed atomically with the effect of the execution the same as though the nodes are executed in sequence.
Each BT node refers to a component (VM or CUST in the example), and has a be-haviour that is either a state realisation (e.g., [Ready]), a guard (e.g., ???Ready???), a selection (e.g., ?Ready?), an event (e.g., ??Coin??), an internal output (e.g., <Coin>), an internal input (e.g., >Coin<), an external output (<<Coin>>), or an external input (e.g., >>Coin<<). A state realisation node indicates that a component enters a particu-lar state or that an attribute of a component gets a particuparticu-lar value. In the example, we have state realisation nodes where VM enters the “ready,” “candy” and “chips” states, modelling the corresponding behaviours abstractly. A guard node waits until its guard expression holds before proceeding. A selection node is like a guard node except it does not wait until its guard holds, instead its thread is killed if the guard does not hold. An
event node is also like a guard node, except it waits for an event. Inputs and outputs are similar to events, however, an internal input can only occur simultaneously with the cor-responding internal output (e.g., >Coin< waits for <Coin> and proceeds simultaneously with <Coin>), but internal output does not have to wait for the corresponding input to be ready. The example BT has three external input events modelling the cases where the system waits for a customer (CUST) to insert a coin, select candy and select chips respectively.
Each BT node can have a requirement tag, which provides traceability to require-ments. The example BT has all of the nodes tagged R1 since it is assumed that there is only a single requirement named R1. For a large BT that models a large set of re-quirements, each node can be tagged according to which requirements are relevant. Since requirements traceability is not relevant for this thesis, we will instead use the tags as node identifiers by tagging each node differently.
A BT node may be viewed as a guarded command [Dij75] that is executed atomically.
For an atomic composition of nodes, guards of all the nodes in the composition must be enabled for the atomic composition to be executed. The execution of BT nodes from parallel threads are interleaved, unless they are synchronised. BT nodes that are synchronised with each other are executed simultaneously. The BT notation allows for non-deterministic choice between internal behaviours in an alternative branching. In addition, when a BT is not coupled with an environment, events and external I/O may be viewed as occurring non-deterministically.
The graphical nature of the BT notation makes it natural to have tools for BTs with visual effects. An execution path of a BT (e.g., a counterexample path) may be animated by highlighting the BT nodes as the “execution” steps through the nodes. The status of active threads may also be shown in the animation, e.g., by highlighting (in a different fashion) “active” nodes. Some of the structural constraints of BTs may ease the comprehension of animations, e.g., we need not worry about a node and its ancestor being active at the same time.
The full syntax of the BT notation is described in [Beh07] and a formal semantics for the BT notation is described in [CH11]. Although the BT notation is part of a larger methodology called Behavior Engineering [BE], it is a useful in its own right as a notation for modelling behaviour.
Several tools are available for BTs. They include BESE [PLTP08], Integrare [WLC+07]
and TextBE [tex]. However, none of the tools support model checking directly, instead, the tools generate code for the Symbolic Analysis Laboratory (SAL) [dMOS03], where model checking can be performed.
2.5. SUMMARY 21