A Semantics for Behavior Trees

Robert Colvin Ian J. Hayes

May 2010

Technical Report SSE-2010-03 Division of Systems and Software Engineering Research School of Information Technology and Electrical Engineering The University of Queensland QLD, 4072, Australia http://www.itee.uq.edu.au/∼ sse

A Semantics for Behavior Trees

Robert Colvin1,2 and Ian J. Hayes1,3 1The University of Queensland 2The Queensland Brain Institute 3School of Information Technology and Electrical Engineering

Abstract In this paper we give a formal deﬁnition of the requirements translation language Behavior Trees. This language has been used with success in industry to systematically translate large, complex, and often erroneous requirements documents into a structured model of the system. It contains a mixture of state-based manipulations, synchronisation, message passing, and parallel, conditional, and iterative control structures. The formal semantics of a Behavior Tree is given via a structure-preserving translation to a version of Hoare’s process algebra CSP, extended with state-based constructs such as guards and updates, and a message passing facility similar to that used in publish/subscribe protocols. We ﬁrst provide the extension of CSP and its operational semantics, which preserves the meaning of the original CSP operators, and then the Behavior Tree notation and its translation into the extended version of CSP. Key words: Behavior Trees, operational semantics, CSP, state, process algebra, requirements modelling

1. Introduction be easy for a non-expert to understand in a relatively short amount of time. A system developer is often faced with a sys- Each requirement is translated into its own, tem requirements document containing hundreds, small, Behavior Tree, and each node in the tree or even thousands, of requirements, written in a is tagged with the number of the requirement from natural language, and by a varied group of people, which it was translated, allowing traceability back each with specialised domain knowledge. Unsur- to the original informal requirements. The require- prisingly, such documents may be filled with prob- ments may then be progressively integrated into a lems, such as ambiguity, inconsistency, redundancy, whole-system tree, by finding syntactically match- and incompleteness. The process of transforming ing constructs. This process will reveal inconsis- such documents into a working system must there- tencies, redundancies, incompleteness, and ambigu- fore be able to identify issues with the natural lan- ities. The constructed tree can then serve as the ba- guage requirements in a way that is easy for the sis for discussion between developer and client for client to understand, and the model must be struc- validation purposes, using the traceability tags on tured such that it can be cross-referenced with the each node to cross reference to the original docu- original document. ment. Once a validated tree is defined, the devel- The Behavior Tree notation was developed by oper has a systematically structured representation Dromey to address this problem [6, 7, 8]. Be- of the system, which can serve as the basis for fur- cause it is designed for use by both client and ex- ther development work. pert modeller, it is a graphical notation, and con- Experience with industrial trials indicate that the tains a range of constructs that cover state-based modelling process is better at detecting errors in manipulations, as well as more abstract concepts requirements than other techniques [1, 2]. The Be- such as synchronisation and message passing, along havior Tree process has been adopted for industrial with the typical concurrency, choice and iteration use, in particular by Raytheon Australia [9], who control structures familiar to specification and pro- have invested resources to developing a Behavior gramming languages. The notation is designed to Tree editor [3]. Other tools [5, 4] include facilities Preprint submitted to Science of Computer Programming April 22, 2010 for ensuring well-formedness and model checking. different diagram types, many of which do not eas- In this paper we present a formal semantics for ily support traceability back to the original require- the Behavior Tree notation. As its base we use ments. In comparison, the Behaviour Engineer- Hoare’s process algebra Communication Sequential ing development framework comprises only two dia- Processes (CSP) [10, 11], a well-established and ele- gram types, Behavior Trees and Composition Trees, gant formal notation for describing interactions be- both of which support traceability.1 Furthermore, tween concurrent processes. We extend this lan- the semantics of UML has not been fully formalised guage to include state-based constructs such as [15, Sect. 8]. tests and updates, which are common within requirements documents, and a message passing fa- 1.2. Behavior Tree semantics cility similar to publish/subscribe models of com- There are several previous definitions of the se- munication [12]. We call this new language CSPσ. mantics of Behavior Trees. In particular a technical The extensions and operational semantics of CSPσ report by the authors of this paper [16], which de- are defined so that the original laws of CSP are fined a process algebra for capturing the constructs preserved. of Behavior Trees directly. While comprehensive, The most immediate motivation for providing a the operational semantics were overly complicated, formal semantics for the Behavior Tree notation is and did not exhibit desirable properties such as to add precision to Behavior Tree models. As a compositionality of parallel Behavior Trees. In con- result, the consequences of modelling decisions are trast, in this paper we use an existing process al- easier to understand, and ambiguities and incon- gebra, CSP, for the underlying definitions, and this sistencies are removed from the models themselves. provides a more elegant specification of interactions In the longer term, the semantics may be used as between processes, and is inherently compositional. the basis for developing automated analysis of sys- Earlier definitions of the semantics of Behavior tem behaviour, in particular, simulation and model Trees include a translation into CSP but with- checking. It is for these longer-term goals that the out the extension of state [17], and translations semantics is defined as an extension of CSP, with to automata-based languages such as action sys- the intention that tools and techniques for Behavior tems [5] and timed/probabilistic automata [18, 19]. Trees may extend existing tools and techniques for The translation in [17] is complicated when complex CSP [13, 14]. state is involved, as CSP does not naturally han- The paper is structured as follows. In Sect. 2 dle mutable state (this is explored in more detail in we present CSP extended with state. In Sect. 3 we [20]). The work in this paper uses a similar transla- present a further extension which includes message tion technique, but with a version of CSP extended passing. In Sect. 4 we present the Behavior Tree with state, which makes many of the translations notation, and in Sect. 5 we describe how to translate simpler. The translations to state-based notations Behavior Trees into the extended version of CSP. [5, 18, 19] resulted in complex configurations re- For the remainder of this section we consider related quired to represent concurrency and the control work. structures of Behavior Trees. They were also targeted specifically at model checking, and hence were written more for efficiency than elegance. In this 1.1. Requirements modelling paper, we present the semantics using an estab- The Behavior Tree notation shares much in com- lished and elegant process algebra as its core, with mon with other formal (and informal) specifica- a straightforward and structure-preserving translation languages, but is targeted at mapping typical tion process. Compared with the semantics men- requirements in a straightforward manner, rather tioned above, this gives further confidence in val- than as a vehicle for abstract specification. That is, idating the formal semantics that we present here the notation is designed so that a client can under- against the informal semantics described for Behav- stand the models, and the models can be mapped ior Trees by Dromey [6, 7, 8]. back to their original statement of requirements. 1 The Unified Modelling Language (UML) [15] is Composition Trees give the static declarations of the sys- also used for constructing a model from require- tem, such as the components, states and events which occur within the system, in a hierarchical manner similar to the ments. The main point of difference with Behavior static declarations of other languages. We do not consider Trees is that a UML model is formed from several them in detail in this paper. 2 1.3. Process algebras with state this must be explicitly disallowed in CSP#, as with CSP has been integrated with state-based lan- any language in which the State is kept globally guages, for instance, with Z by Woodcock & Cav- rather than hierarchically. Future work is to recon- alcanti (Circus) [21], with Object-Z by Smith [22] cile the differences between CSPσ and CSP#, with and Fischer & Wehrheim (CSP-OZ) [23], with Ac- the intention of using the PAT tool for model check- tion Systems by Butler [24], and with B by Butler ing and animating CSPσ processes, and therefore & Leuschel [25] and by Schneider & Treharne [26]. Behavior Trees. In comparison with these approaches to combining state-based specification with CSP, we have taken a “lightweight” approach, introducing only a sin- 2. CSPσ gle construct for defining state manipulation, and with little change to the underlying syntax and se- In this section we describe a version of CSP which mantics of CSP. In the languages mentioned above, has been extended with state-based constructs. there is a notational and informational overhead as- This was introduced in [20]; here we present a more sociated with combining two pairs of syntax and concise version, which includes definitions for in- semantics. Of course, the addition of state tests terrupts, restarts, explicit recursion, and sending and updates does not provide the same richness of expressions on channels. We also use an interface specification as afforded by a full combination of parallel composition operator rather than Hoare’s CSP with, for example, B, but does provide a use- original alphabetised parallel composition operator ful stepping stone between event-based and state- [10], as interface parallel is more flexible and cor- based specifications. We have taken this approach responds with more recent presentations of CSP for defining the semantics of Behavior Trees in an [11, 32]. attempt to keep the translation process as simple The language CSP is a process algebra which as possible and structure-preserving. σ allows concurrent processes to communicate syn- Baeten and Bergstra [27, 28] define a process al- chronously via shared events, and to manipulate gebra with state, which can be tested and updated and check the value of state variables. Synchroni- through propositional signals. In this case the state sation and variable manipulations may be combined is anonymous, and each action is separately defined atomically, subject to certain restrictions described to test or modify the state in some way. The use below. of local state by Baeten and Bergstra, as with local state in CSPσ, are examples of contexts as explored generically by Larsen and Xinxin [29]. A recent ex- 2.1. Syntax tension of CSP by Sun et al., CSP# [30], introduces shared variables and sequential programs, and is Declarations. The basic unit for synchronisation supported by the model checker PAT [31]. That are events, given by the set Σ. Elements of the language is roughly equivalent in expressiveness to set Σ are either an event name or the pairing of a CSPσ, except that CSPσ includes a general speci- channel name with an associated value in the set fication command, which abstractly represents any Val. The set Στ,X is Σ extended to include the atomic update of the state, whereas CSP# allows special events τ, representing a (hidden) internal sequential code blocks using typical imperative con- event, and X, representing termination. structs. This difference is because we define a spec- We assume a set of variable names Var, and de- ification language, while CSP# is designed for effi- fine a State (also sometimes called a valuation or cient model checking. The main point of difference store) as a finite partial mapping from variables to with CSPσ is in the style of operational semantics values. and handling of variables. Our transition rules define a relation on Processes, while the transition State == Var →7 Val rules of [30] define a relation on Process × State pairs. This means that our rules collapse to the We assume Val contains the booleans and integers, standard CSP rules when state is not involved, and and whatever other values that are required for a that the majority of rules are relatively concise. particular application. A state in which the variable This style also admits concurrent processes to use i has value 0 and j has value 1 is represented by the the same variable name without conflict, whereas mapping {i 7→ 0, j 7→ 1}. 3 Expressions and predicates. Single-state expres- A specification command x: [R] may be inter- sions are given by the type Expr1, and are terms preted as a relation, SR, on total states, that sat- which may contain elements of Var. We assume isfies R and modifies only variables in x. That is, an expression syntax which contains the standard given total states S, S 0 ∈ (Var → Val), the relation operators of arithmetic and set theory. An expres- corresponding to x: [R], given by [[x: [R]]], contains sion, E, may be instantiated with a state, σ, to (S, S 0) if S and S 0 make R true and only variables form a new expression, E[σ]; it is the expression in x may differ. obtained by replacing all of the free variables in E 0 0 0 that are also in the domain of σ with their value (S, S ) ∈ [[x: [R]]] ⇔ (R[S, S ] ∧ x −C S = x −C S ) in σ. This may return a “ground” expression (con- (The function x −C S is the function S with its do- taining no free variables) that can be evaluated to main restricted to elements not in x.) We define an element of Val, or another expression which has equivalence of specification commands as follows. fewer free variables. For instance, an instantiation (i > 0)[{i 7→ 1}] is (1 > 0) which evaluates to the c1 ≡ c2 = [[c1]] = [[c2]] true. Similarly, an instantiation (i > j )[{i 7→ 1}] b is the (boolean) expression 1 > j . We refer to A special specification command is id, which we de- boolean-valued expressions as predicates. fine as [true]. It does not depend on nor change Two-state expressions are given by the type any variables. Note that there are many other com- Expr2, and contain free variables in Var as with mands which are equivalent to id by the definition 0 Expr1, but may also contain primed versions of Var. above, such as [5 > 1], [x = x], x: [x = x]. The primed versions indicate the post-state, while the unprimed versions indicate the pre-state. An Processes. The syntax of processes is given below. instantiation of E ∈ Expr2 requires two states, i.e., τ E[σ, σ0], where the variables in the domain of σ are Process : : = (SCmd, Σ ) → Process replaced in E by their values in σ, and the primed | Process ; Process variables in the domain of σ0 are replaced by their | Process [] Process values in σ0. For instance, (i 0 = i+1)[{i 7→ 0}, {i 7→ | Process u Process 1}] is 1 = 0 + 1 which evaluates to true. When an | Process kProcess expression may be either one- or two-state, we just A use the type Expr. We say a predicate E is satis- | (µ rec • Process) fiable, written sat(E), when there exist total pre- | Process\A and post-states σ and σ0 such that E[σ, σ0] evalu- | (state State • Process) ates to true. | Process 4 Process | Process restart(Σ) Process State-based constructs. | SKIP Following Morgan [33], we introduce specification | STOP commands (SCmd) as the basic state-manipulation construct in the language. A specification com- where A represents a set of events, and rec is an mand x1, .., xn : [R] contains a two-state predicate identifier. R and a frame x1, .., xn , which is the (possibly An event appearing in processes is either an iden- empty) set of variables which the command may tifier, or ch!E, indicating output of the value of alter. Therefore, the primed variables in the predi- expression E on channel ch, or ch?y, indicating cate must be a subset of the frame. An example is receiving a value on channel ch and storing it in i: [i 0 = i + 1], which modifies the frame variable i variable y.2 so that in the post-state it has a value one greater An action prefix process (c, a) → P, where c is a than the pre-state. When the frame of a specifi- specification command, and a is an event, is a pro- cation command is empty (and hence its predicate cess that tests and/or updates the state such that does not refer to any post-state (primed) variables), we call it a guard, and write it as [g]. We also al- 2 low an update, x := E, where x ∈ Var and E is a In [20] channels could include expressions, but the rules covered only the case where the value of E could be deter- single-state expression, to abbreviate the specifica- mined locally to the sending process. This paper contains a tion command x: [x 0 = E]. full treatment. 4 the specification command c is satisfied, and syn- to id, we omit it. chronises on event a, before behaving as process P. We allow a to be τ if c is not equivalent to id. A Queue = (state {q 7→ hi} • Qrec) sequential composition P ; Q behaves as P until Qrec =bµ Q • P terminates, after which it behaves as Q. An ex- b (enq?x → (q := q a hxi) → Q) (1) ternal choice between processes P and Q is given [] (([q 6= hi], deq!head(q)) → by P [] Q. The choice is external because the envi- (q := tail(q)) → Q) ronment selects P or Q through synchronisation. In contrast, an internal choice between P and Q, writ- After an enq?x event, q is extended by x and the ten P u Q, nondeterministically chooses between P process repeats. If q is nonempty, Queue may par- and Q, without reference to the environment. Con- ticipate in a deq event, which returns the head of currency is written as P kQ, which states that the the queue, and then removes it from q. A two processes operate in parallel, synchronising on 2.2. Semantics events in the interface A, and interleaving other We formally define the meaning of CSPσ in a events. A recursive process is defined using the fix- structural operational semantics style [35] in Fig. 2, point operator µ, (µ rec • P). Free occurrences of using the variable naming conventions in Fig. 1. rec within P represent a new instance of (µ rec • P). The label on each step is a pair containing a com- A set of events, A, may be “hidden” within a pro- mand and an event. cess P, written P\A, so that any events in A are not visible externally to P (these become internal 2.2.1. Prefixing steps of P\A). A state σ ∈ State may be declared A prefix is the basic building block of a pro- local to P via (state σ • P). An interrupt P 4 Q cess. A process may be prefixed by the pairing of a behaves as P until process Q takes some externally specification command with an event. The rule is observable action, at which point it “interrupts” P straightforward – the process transitions to P, and and becomes the active process. A restart process the command and event (if any) are shown in the P restart(a) Q behaves as P until the restart event transition label. We abbreviate a label in which the a is generated by P, at which point it behaves as command is equivalent to id as just the event, and Q restart(a) Q. The restart operator is similar to if the event is τ we abbreviate the label to just the the exception operator of Roscoe [34]. The pro- command. This means, for instance, that the rule cess SKIP has only one possible behaviour, which for a guard with no event is is to terminate successfully and take no further action. The process STOP has no behaviour – it may [g] ([g] → P) −→ P never synchronise or take any other action. In general, CSP processes may also be parameterised by and the rule for an update is values, but we do not consider parameters in this paper: a comparison of parameterised values and (x := s → P) −x−:=−→s P mutable state is given in [20]. It is also the case that the usual CSP event prefix rule holds, i.e.,

a (a → P) −→ P

2.2.2. Channels As an example, consider the following specifica- Rules 2 and 3 for channels are more complex, be- tion of a queue process, which makes use of a state, cause of the possible interplay of variables in the q, which is a sequence of values, where hi represents channel expression with the command. An output the empty sequence, hvi represents the singleton ch!E must choose some value for E, say v, and sequence containing v, and a represents sequence output that value on the channel (within labels, concatenation. When the event in an action pair is channels must be paired only with values, not ex- τ, we omit it, and write just the specification com- pressions). That E does indeed have the value v mand; similarly, when the command is equivalent in context is established by adding a (satisfiable) 5 P, Q: Process a: Σ y: Var v: Val τ,X c: SCmd e: Σ x, x1, x2: P Var E, R: Expr σ: Var →7 Val id = [true] A ⊆ Σ g: Expr1

Figure 1: Naming conventions

Rule 1 (Preﬁx)

c,e ((c, e) → P)−−→P

Rule 2 (Channel output) Rule 3 (Channel input)

sat(R ∧ v = E) sat(R ∧ y0 = v) (x:[R∧v=E],ch.v) (x,y):[R∧y0=v],ch.v ((x: [R], ch!E) → P) −−−−−−−−−−−→ P ((x: [R], ch?y) → P) −−−−−−−−−−−−−→ P

Rule 4 (External choice) Rule 5 (Internal choice) (a) (b) τ 0 c,e 0 P−→P P−−→P (c 6≡ id ∨ e 6= τ) τ (P u Q)−→P τ c,e P [] Q−→P 0 [] Q P [] Q−−→P 0 and similarly for Q. and similarly for Q.

Rule 6 (Sequential composition) Rule 7 (Skip) c,e 0 X 0 P −→ P e 6= X P −→ P X (a) c,e (b) τ SKIP −→ STOP P ; Q −→ P 0 ; Q P ; Q −→ Q

Rule 9 (Hiding) Rule 8 (Recursion) c,a c,e P−−→P 0 a ∈ A P−−→P 0 e 6∈ A τ (a) (b) (µ rec•P) c c,e (µ rec • P)−→(P[ rec ]) P\A −→ P 0\A P\A−−→P 0\A

Rule 10 (Interrupt)

c,e τ c,e P−−→P 0 Q−→Q 0 Q−−→Q 0 (c 6≡ id ∨ e 6= τ) (a) (b) (c) c,e τ c,e P 4 Q −→ P 0 4 Q P 4 Q−→P 4 Q 0 P 4 Q −→ Q 0

Rule 11 (Restart)

c,e c,a P−−→P 0 e 6= a P −→ P 0 (a) (b) c,e restart c restart (P restart(a) Q)−−→(P 0 restart(a) Q) (P (a) Q) −→ (Q (a) Q)

Figure 2: Rules summary for CSPσ 6 guard to the command. In the simple case, where Combining these transitions with Rule 18 (de- a value u is sent on the channel and there is no scribed later), we have the full transition: associated command, we have the rule c,ch.1 (ch!(x + 1) → P) k (ch?x → Q) −−−−→ P k Q (ch!u → P) −ch−−.→u P where c = x: [x = 0 ∧ x 0 = 1]. If an expression is sent with no associated com- More generally, we have the following possible mand, we have transition for any v ∈ Val,

c,ch.(v+1) [v=x+1],ch.v ch!(x + 1) → P −−−−−−−−−→ P (ch!(x + 1) → P) k (ch?x → Q) −−−−−−−→ P k Q where c = x: [x = v ∧ x 0 = v + 1]. The context for all possible values v. When the context of a will determine the initial value for x, as described particular state is added (see Sect. 2.3) this will in Sect. 2.3. define the value of x and hence restrict the choice of v to the value of x + 1 in that state. 2.2.3. External and internal choice The expression E is of type Expr , and hence it 2 An external choice between two processes is re- may reference primed variables (for instance, this solved when one of them makes an observable step, allows a command which updates x and outputs its that is, engaging in an event and/or accessing a new value on ch). To be consistent, we restrict E non-local variable. Rule 4(a) allows either pro- to reference primed variables in the frame of the cess to take an internal step without resolving the associated command only. choice, while in Rule 4(b) an observable step of ei- Now consider inputting a value from a channel ther process resolves the choice in that process’s and storing it in a variable. We do not constrain favour. the input variable to be in or out of the frame of In contrast, an internal choice (Rule 5) is resolved the associated command – either is possible. This nondeterministically at any time, regardless of the allows behaviour such as receiving a new value for environment. a variable only when that value is in a desired set. When there is no associated command, the ef- 2.2.4. Sequential composition fect of a channel input is an update of the receiver The transitions for sequential composition in variable. CSPσ (Rule 6) are similar to those of CSP. The y := v,ch.v first process executes its steps (Rule 6(a)), until it (ch?y → P) −−−−−−−→ P terminates (Rule 6(b)), at which point the second Below we demonstrate communication via chan- process becomes active. The SKIP process can do nels using a simple example. nothing but generate the termination event X and then takes no further action (Rule 7). (ch!(x + 1) → P) k (ch?x → Q) 2.2.5. Recursion This command has the effect of incrementing x, The transition for a recursive process is to simply with the new value of x sent along channel ch. unfold the recursion (Rule 8). For instance, recall For the sending process we have the following the definition of Qrec (1). An unfolding of Qrec possible transition (amongst many). results in eliminating the outer µ operator and replacing the recursion variables Q with Qrec itself. [1=x+1],ch.1 (ch!(x + 1) → P) −−−−−−−−→ P (enq?x → (q := q a hxi) → Qrec) τ   Qrec −→ [] (([q 6= hi], deq!head(q)) → The specification command in the label simplifies  (q := tail(q)) → Qrec)  to [x = 0]. This indicates that a visible behaviour of this process is to output the value 1 on channel 2.2.6. Hiding ch, provided x = 0. Rule 9(a) removes the event a from the label, For the receiving process we have the following that is, it is hidden from the environment. The possible transition (amongst many). command c remains observable. If the event part of the label is not hidden, the label does not change x:[x 0=1],ch.1 (ch?x → Q) −−−−−−−−→ Q (Rule 9(b)). 7 2.2.7. Interrupt Inside a local state that maps i to the initial value Rule 10(a) is a typical step of the main process P, 5, in Rule 12 we instantiate x to {i}, y to {j }, σ0 while Rule 10(b) is the case where the interrupting to {i 7→ 0}, and hence process makes an internal step; it may evolve sep- R[σ, σ0] arately to P. Rule 10(c) handles the case where 0 0 Q makes an externally observable transition: the = (i = 0 ∧ j = 0)[{i 7→ 5}, {i 7→ 0}] = (0 = 0 ∧ j 0 = 0) execution of P is halted, and Q becomes the active 0 process. = j = 0

2.2.8. Restart The substitution serves to eliminate the parts of R that refer to the local state, while the sat(..) A restart process, (P restart(a) Q), acts similarly constraint restricts the post-state σ0 to only valid to an interrupt process P 4 Q, except that the in- choices of new values. Since sat(j 0 = 0) holds, we terrupt event, a, is generated internally. That is, may derive the following transition. a restart process (P restart(a) Q) behaves has P until it generates the (restart) event a, at which 0 j :[j =0] 0 time it will halt execution and restart, behaving as (state {i 7→ 5} • P) −−−−−→ (state {i 7→ 0} • P ) (Q restart(a) Q). Rule 11(a) states that P may be- Note that any choice for the post-state σ0 other than have normally as long as it does not generate the {i 7→ 0} will result in an unsatisfiable predicate, event a, while Rule 11(b) states that P terminates and hence prevent the rule from being applied. and restarts as Q restart(a) Q when the event a is In the case where the local state contains map- generated. The restart operator is similar to the ex- ping for both i and j , e.g., σ = {i 7→ 5, j 7→ 5}, ception operator given by Roscoe [34], except that in Rule 12 we instantiate x to {i, j }, y to ∅, σ0 to rather than terminating the process we restart it. {i 7→ 0, j 7→ 0}, and hence R[σ, σ0] simplifies to true For brevity, we make the following definition. and the resulting label is, as expected, id. restart(a, Q) = Q restart(a) Q (2) In a prefixed process, if the command is equiva- b lent to id the rule reduces to the simple case of an 2.3. State-based rules event, as given in Rule 13. The rules involving the local state construct are We now consider specialisations of Rule 12 for given in Fig. 3. These were initially introduced in guards and updates with no associated events. [20]. Rule 12 states that a process (state σ • P) Rule 14 states that if P transitions with guard may take a transition labelled by a specification g, the observable transition of (state σ • P) is the 0 command and event pair (y : [R[σ, σ ]], e) under the guard g[σ], i.e., the guard g with variables local to following conditions. P transitions in specification σ instantiated with their local values. Below are 0 command and event pair (x, y : [R], e) to P , where some examples: x is the set of frame variables in the local state σ, and y is the set of frame variables not in the local state σ. (Recall that R may refer only to primed (state {i 7→ 1} • [i 6 5] → P) variables that are in the frame.) The new local state id σ0 is the same as σ for variables outside the frame, −→ (state {i 7→ 1} • P) (3) but otherwise may choose any values for variables (state {i 7→ 1} • [i 6 x] → P) x such that R[σ, σ0] is satisfiable. The conclusion [16x] of the rule states that (state σ • P) transitions to −−−→ (state {i 7→ 1} • P) (4) (state σ0 • P 0) with label (y : [R[σ, σ0]], e), i.e., the (state {i 7→ 1} • [y 6 x] → P) visible behaviour is the event e and an update of [y6x] non-local variables y such that R holds, after vari- −−−−→ (state {i 7→ 1} • P) (5) ables in the local state are replaced by their local values in the pre- and post-states, σ and σ0. In (3) the transition label is id, which plays a simi- For example, consider a process P that transi- lar role to τ. The guard trivially evaluates to true tions with a label containing a specification com- in the local state, so to an external observer some mand that updates variables i and j to 0. internal step is taken. In (4) the guard accesses non-local variable x. The externally observable be- i,j :[i0=0∧j 0=0] P −−−−−−−−−−→ P 0 haviour of this process is that it can evolve to P if 8 Rule 12 (State)

x,y:[R],e P −−−−−−→ P 0 x ⊆ dom(σ) y ∩ dom(σ) = ∅ x −C σ = x −C σ0 dom(σ) = dom(σ0) sat(R[σ, σ0]) y:[R[σ,σ0]],e (state σ • P) −−−−−−−−→ (state σ0 • P 0)

Rule 13 (Event in state) Rule 14 (Guard)

e [g] P −→ P 0 P −→ P 0 sat(g[σ]) e [g[σ]] (state σ • P) −→ (state σ • P 0) (state σ • P) −−−→ (state σ • P 0)

Rule 16 (Update - local) Rule 15 (Update - nonlocal) P −x−:=−−E→ P 0 x ∈ dom(σ) P −x−:=−−E→ P 0 x 6∈ dom(σ) σ0 = σ ⊕ {x 7→ v} sat(v = (E[σ])) x :=(E[σ]) (state σ • P) −−−−−−→ (state σ • P 0) [v=(E[σ])] (state σ • P) −−−−−−−→ (state σ0 • P 0)

Figure 3: Rules for local state x ≥ 1. The predicate has been partially instanti- if P makes a transition which updates local variable ated according to the local state. In (5) the local x, then x is locally updated to a new value v, and state has no eﬀect on the guard: its progress is the observable transition is a guard that ensures v independent of local variables and hence is exter- is the value of expression E in context. As such, nally visible (via the transition label). A process there are many possible transitions for each local (state {i 7→ 1} • [i > 5] → P) cannot transition at update, one for each value v. However, once placed all since the guard does not hold in the local con- in a context which deﬁnes all the free variables in text. E, only the transition in which v has the value for Rule 15 states that, for a process (state σ • P), E in that state will be valid. For example: if P makes a transition which updates a non-local variable x to E, then the observable transition is an (state {s 7→ 1} • s := 0 → P) update of x to E[σ], that is, the local variables in E id are instantiated with their value in σ. For example: −→ (state {s 7→ 0} • P) (8) (state {s 7→ 1} • s := s + i → P) (state {i 7→ 1} • s := 0 → P) [i=0] −−−→ (state {s 7→ 1} • P) (9) −s−:=−→0 (state {i 7→ 1} • P) (6) (state {s 7→ 1} • s := s + i → P) (state {i 7→ 1} • s := i → P) [i=1] s := 1 −−−→ (state {s 7→ 2} • P) (10) −−−→ (state {i 7→ 1} • P) (7) (state {s 7→ 1} • s := s + i → P) Transition (6) describes an update to a non-local [i=2] variable, in which the update expression is inde- −−−→ (state {s 7→ 3} • P) (11) pendent of the local state. In (7) the local context does not include s, but does include a variable in Transition (8) is a simple example of the applica- the update expression. Since i is mapped to 1 lo- tion of Rule 16 where we make the obvious choice cally, to an external observer the process appears of 0 for v, since E[σ] evaluates to 0, and there- as an update of s to 1. fore [E[σ] = v] = [0 = 0] ≡ id. The remaining Rule 16 states that, for a process (state σ • P), transitions deal with the more complex case where 9 Rule 17 (Parallel independent) Rule 18 (Parallel synchronise)

c,e 0 x1:[R1],a x2:[R2],a P−−→P e 6∈ A ∪ {X} P −−−−−−→ P 0 Q −−−−−−→ Q 0 c,e P kQ−−→P 0 kQ sat(R1 ∧ R2) a ∈ A A A x1,x2:[R1∧R2],a P kQ −−−−−−−−−−→ P 0 kQ 0 A A and similarly for Q.

Rule 19 (Parallel – terminate one)

X Rule 20 (Parallel – terminate both) P −→ P 0 τ P kQ−→STOP kQ X A A STOP kSTOP −→ STOP A

and similarly for Q.

Figure 4: Rules for parallel composition the updated variable is local but the expression E vided that the conjunction is satisfiable. Note that is not. In these cases we cannot locally determine this rule allows x1 and x2 to overlap, and hence finds the value to which s must be updated, since the a mapping for variables in the intersection that sat- update expression accesses the non-local variable isfies both R1 and R2, should such a mapping exist. i. Locally, therefore, there are many possible tran- However, this admits rather subtle behaviour and sitions, one for each v ∈ Val to which s can be semantics; generally, it is safer to prevent synchro- updated (we have shown only the transitions for nised specification commands from modifying the v = 1, v = 2, v = 3). However, in practice, only same variable, and this constraint may be enforced one transition will be possible for a given context. statically. In this case, that will be the transition in which v Termination of a parallel composition of pro- has the value of 1 + i in that context. cesses requires all processes to have terminated, i.e., distributed termination. Rule 19 handles the case 2.4. Interface parallel where one of the processes terminates: the termi- The parallel operator used in this paper is based nated process is replaced by STOP, but this ap- on the interface parallel operator described by pears as an internal step of the parallel composi- Roscoe [11], rather than Hoare’s original alphabe- tion. In Rule 20 both processes have terminated, tised parallel [10] (which was used in [20]). The in which case the parallel composition itself visibly rules for interface parallel are given in Fig. 4. For terminates. interface parallel, the interface A defines the set of events on which the two processes must synchronise. Note that A cannot include the special events 2.5. Examples τ or X. Rule 17 states that process P may evolve to P 0 In Fig. 5 we present two executions side-by-side. independently of Q provided that the event that P For space reasons we abbreviate the state keyword l is engaging in is not a member of the interface A, to st, and use =⇒ to indicate a sequence of two and that P is not terminating. or more transitions that contain exactly one non- Rule 18 handles the more interesting case where internal step, l. Often, the omitted τ steps include both P and Q are ready to engage in a shared event the initial unfolding of a recursion. a which is in the interface A. In this case the asso- On the left of Fig. 5 is an execution of the process ciated specification commands are conjoined, pro- Q from (1) when q is initially empty. 10 Queue Sum = from (1) = from (12) b (st{q 7→ hi} • Qrec) b (st{i 7→ 1, s 7→ 0} • S) enq.v [16N ] =⇒ Rule 8, Rule 1, Rule 4, Rule 13 =⇒ Rule 8, Rule 1, Rule 4, Rule 14 a (st{q 7→ hi} • q := q hvi → Qrec) (st{i 7→ 1, s 7→ 0} • id −→ Rule 1, Rule 16 (s := s + i) → (i := i + 1) → S) id (st{q 7→ hvi} • Qrec) −→ Rule 1, Rule 16 enq.w =⇒ Rule 8, Rule 1, Rule 4, Rule 13 (st{i 7→ 1, s 7→ 1} • (i := i + 1) → S) a id (st{q 7→ hvi} • q := q hwi → Qrec) −→ Rule 1, Rule 16 id −→ Rule 1, Rule 16 (st{i 7→ 2, s 7→ 1} • S) [26N ] (st{q 7→ hv, wi} • Qrec) =⇒ Rule 8, Rule 1, Rule 4, Rule 14 (as above) deq.v =⇒ Rule 8, Rule 1, Rule 4, Rule 12 (q 6= hi) (st{i 7→ 2, s 7→ 1} • (st{q 7→ hv, wi} • q := tail(q) → Qrec) (s := s + i) → (i := i + 1) → S) id id −→ Rule 1, Rule 16 =⇒ Rule 1, Rule 16 (×2 as above) (st{q 7→ hwi} • Qrec) (st{i 7→ 3, s 7→ 3} • S) deq.w [3>N ] =⇒ Rule 8, Rule 1, Rule 4, Rule 12 (q 6= hi) =⇒ Rule 8, Rule 1, Rule 4, Rule 14 (st{q 7→ hwi} • q := tail(q) → Qrec) (st{i 7→ 3, s 7→ 3} • x := s → SKIP) id x := 3 −→ Rule 1, Rule 16 −→ Rule 1, Rule 15 (st{q 7→ hi} • Qrec) (st{i 7→ 3, s 7→ 3} • SKIP) X −→ Rule 7, Rule 13 (st{i 7→ 3, s 7→ 3} • STOP)

Figure 5: Example executions

On the right of Fig. 5 is the execution of program tion which updates x to 3. No more transitions are Sum, which is an example of how computation se- possible. The steps may be interleaved with other quences may be speciﬁed in CSPσ. processes operating in parallel by Rule 17.

Sum = (state {i 7→ 1, s 7→ 0} • S) 3. Message passing S = µbsum • b [i 6 N ] →(s := s + i) → (12) In this section we introduce a new message pass- (i := i + 1) → sum ing construct for CSP in which the sender does [][i > N ] →(x := s) → SKIP not need to block until there is a receiver. Such a construct more naturally represents some com- Sum calculates the sum to the value of (non-local) munications in certain systems; for example, a taxi variable N , and writes the final value to (non-local) company headquarters sending notification of a new variable x. Variable N is set prior to the invocation job. In addition, it allows the number of potential of Sum, and x is read after Sum terminates to re- listeners to change dynamically, as is common in trieve the result. An alternative specification would systems of many interacting autonomous agents. It be to parameterise Sum by N , and to output the follows the publish/subscribe model of communica- result on a channel, however, for illustrative pur- tion [12]. Another strength of the new construct poses we have chosen the former approach. The rel- is that it is easy to specify multiple sending pro- ative merits of shared-variable communication and cesses, which do not interact (need to synchronise) channel-based communication are explored in more with each other. detail in [20]. The definition of Sum uses local vari- We are interested in the semantics of this con- ables s and i to accumulate progressive values. struct because, as outlined above, some systems The trace of the execution of Sum is an inter- more naturally use this form of communication leaving of internal steps (id) with accesses of non- over the more abstract, and harder to implement, local variable N , until the final observable transi- synchronisation construct of CSP. Therefore when 11 Rule 21 (Message send) Rule 22 (Message Receive)

sat(R ∧ v = E) sat(R ∧ y0 = v) x:[R∧v=E],send m.v x,y:[R∧y0=v],recv m.v ((x: [R], send m.E) → P) −−−−−−−−−−−−−→ P ((x: [R], recv m.y) → P) −−−−−−−−−−−−−−→ P

Rule 24 (Message ignored) Rule 23 (Message sent) send c, m.v 0 recv m.v x1:[R1],send m.v x2:[R2],recv m.v P −−−−−−→ P Q −−−−/−→ P −−−−−−−−−−→ P 0 Q −−−−−−−−−−→ Q 0 send c, m.v 0 sat(R1 ∧ R2) P kQ −−−−−−→ P kQ A A x1,x2:[R1∧R2],send m.v P kQ −−−−−−−−−−−−−−−→ P 0 kQ 0 A A and similarly for Q.

Rule 26 (Single listener) Rule 25 (Multiple listeners) recv c, m.v 0 recv m.v x1:[R1],recv m.v x2:[R2],recv m.v P −−−−−−→ P Q −−−−/−→ P −−−−−−−−−−→ P 0 Q −−−−−−−−−−→ Q 0 recv c, m.v 0 sat(R1 ∧ R2) P kQ −−−−−−→ P kQ A A x1,x2:[R1∧R2],recv m.v P kQ −−−−−−−−−−−−−−→ P 0 kQ 0 A A and similarly for Q.

Rule 27 (Hide messages)

c,e c,e P −−→ P 0 e ∈ A (∀ m, v • e 6= recv m.v) P −−→ P 0 e 6∈ A (a) (b) c c,e P\A −→ P 0\A P\A −→ P 0\A

Figure 6: Rules for messages translating from natural language requirements this though the rules equally apply to basic messages type of communication model will be easier to apply (m). in some situations. Rule 21 and Rule 22 correspond to sending the The syntax for sending and receiving is given be- value of an expression via a channel in Rules 2 low. and 3. Rule 23 captures P sending a message to Q. The visible behaviour is the conjunction of their send recv m.E m.y respective specification commands, and that m is sent. Rule 24 states that P can still send m even Messages, as with channels, may send expressions if Q is not waiting: this is the nonblocking nature and be paired with specification commands. The l send action communicates message m, with op- of sending a message. We use the notation P −→/ tional expression E, while the recv action receives to indicate that process P cannot take a transition message m, storing any associated value in variable labelled l. Rule 25 states that two receiving pro- y. cesses can receive the same message, while Rule 26 The semantics follow a similar pattern to syn- allows a single process to receive a message if the chronisation event types; the rules for messages and other is not listening. parallel composition are given in Fig. 6. We write Note that a listening process may engage in ei- messages as message/value, message/variable, or ther Rule 26 or Rule 23 if a concurrent process is message/expression pairs (m.v, m.y or m.E), al- sending the message. That is, a listening process 12 can respond directly to a send, or ignore the send Through Rule 28 and Rule 25 we have the fol- and propagate its recv. This nondeterminism arises lowing transitions because there may be more than one producer send- recv send ing the message, and a listener is free to react to L −−−−m→ Q k R S −−−−m→ P either of them. To prevent traces where a receiver responds to an ‘external’ message, the scope over Then through Rule 23 we have which the message is listened for must be limited send (hidden) in the usual way. For instance, the small- S k L −−−−m→ P k (Q k R) est common ancestor of both sender and receiver will typically hide the receive message. Now consider two competing senders, S1 and S2, The rules in Fig. 6 apply only to messages, while operating in parallel. the rules in Fig. 4 apply only to events and chan- send send nels.3 However, the majority of rules from Fig. 2 S1 = m → P1 S2 = m → P2 and Fig. 3 hold for both events and messages, where b b Through Rule 24 only one of these process will send we allow e to range over messages as well as events. a message – they do not synchronise. Either of the The only exception is Rule 9, which requires spe- following two transitions are allowed by the rules. cial treatment for receiving messages, and is now replaced by Rule 27. Rule 27(a) is similar to send m Rule 9(a), except that it applies to synchronisa- (S1 k S2) k L −−−−→ (S1 k P2) k (Q k R) send m tion events and sent messages, but not to receiving (S1 k S2) k L −−−−→ (P1 k S2) k (Q k R) messages. To allow receive actions to become internal events through hiding would be to allow them As a final example, consider a variant of L in to transition without a corresponding send action. which one of the processes, T , is not yet ready to Hence, instead of becoming an internal step, a hid- receive the message. den receive message is prevented from transitioning recv at all. Rule 27(b) is identical to Rule 9(b) (it applies Lv = ( m → Q) k T recv to synchronisation, send, and recv actions). whereb T −−−/−m→

3.1. Example 1 We have the following transition. Consider the following simple process L which send m contains two concurrent processes listening for the S k Lv −−−−→ P k (Q k T ) same message m, and the sending process S which sends m. Although T may be a process that is interested in message m, its unreadiness does not block S from L = (recv m → Q k recv m → R) sending the message to process Q. send S =b ( m → P) b 3.2. Example 2 Before progressing we ﬁrst note the following spe- We now give a more complex example that com- cialisations of Rules 21 and 22 if there is no associ- bines state tests and updates with message pass- ated speciﬁcation command or expression. ing. Consider a network which consists of produc- Rule 28 (Message-only send/receive) ers and consumers. Producers periodically send information, which is conditionally received by all send (send m → P) −−−−m→ P ready consumers. We treat the sent information recv recv m abstractly, although it may be, for instance, (cu- ( m → P) −−−−→ P mulative) security or database updates, etc.. The conditions under which consumers receive the information are also treated abstractly, as are their

3 general tasks. Consumers may also be turned on Note that we do not examine the interface of the par- and off at any time. allel composition for messages, that is, we assume that all messages of the same name within a system are designed to For simplicity we write a recursive procedure interact. The rules may be rewritten so that the interfaces are consulted. P = (µ c • .. → c) as P = .. → P 13 b b We us this abbreviation as it simplifies the syntax Let PP1 be the producer process after it has re- and hides the unfolding steps (Rule 8) in the exe- ceived the event in1.d and as a result is about to cutions. However, the derivations we give may be send the value df (= f (d)). Then we have the fol- easily transformed to use the least-fixpoint syntax. lowing transition by Rule 21. send Pi = ini ?d → update.f (d) → Pi send update.df PP1 −−−−−−−−−→ P1 (13) Ci =b state {y 7→ 0} • (Wki k Updi ) 4 Rbti Wki =b .. The system process Sys is defined as the paral- 0 recv Updi =b ([gi (y )], update.y) → Updi lel composition of the producer and the three con- Rbti =b offi → oni → Ci sumers.

A probducer Pi receives input data d from the Sys = PP1 k ((CC1 k CC2) k CC3) environment along input channel in , then sends i b some version of d, f (d), to every consumer on the We leave the alphabets on the parallel composition network. This is done repeatedly. implicit: they do not directly aﬀect the messages. The consumer Ci contains its local state, which is The consumers CC1 and CC2 are actively listen- treated abstractly as an integer-valued variable y. ing for update messages through the Updi process. Consumers are assumed to be initially active, and For instance, for Upd1, we have the following tran- performing some work tasks given by the process, sition by Rule 22.

Wki , which we leave unspecified. In parallel, the 0 [y =df ∧g1(df )],recv update.df consumer is always ready to receive updates to y, Upd1 −−−−−−−−−−−−−−−−−−→ Upd1 given by the recursive process Upd , which receives i By Rule 12 we have any sent update d provided gi (d) holds, and updates y. At any time the consumer may be switched update.df CC1 −−−−−−→ state {y 7→ df } • .. off by the event offi , which interrupts the working 0 behaviour of the consumer. When the consumer is provided sat(y = df ∧ g1(df )), that is, provided switched back on (oni ), the consumer restarts. This g1(df ) holds. Let us assume that this is the case, “rebooting” behaviour is given by Rbti . but that g2(df ) does not hold. We also note that The interesting point to note is that this specifi- CC3 is not ready to receive the update message as cation would be cumbersome to define using CSP- it is switched off. Then we have: like synchronisation only. The sending of updates recv update.df 0 by the producers is not held up by the transient CC1 −−−−−−−−−→ CC1 (14) consumers, which may come online and offline at recv update.df any time. We also have defined it such that Ci CC2 −−−−−−/−−−→ (15) receives information that satisfies gi only, hence, recv update.df some consumers will receive only particular types CC3 −−−−−−/−−−→ (16) of updates. By (14), (15) and Rule 24 we have In general there may be M producers and N con- recv update d sumers. For presentation purposes we demonstrate . f 0 CC1 k CC2 −−−−−−−−−→ CC1 k CC2 the execution of the send/receive behaviour assuming that there is a single producer, P1, and three Hence by this, (16) and Rule 24, consumers, C1, C2 and C3. Let us assume that C1 (CC1 k CC2) k CC3 and C2 are active, and that C3 has been switched recv update d . f 0 off, and let CCi represent Ci after an unspecified −−−−−−−−−→ (CC1 k CC2) k CC3 number of steps. Finally, by this, (13) and Rule 23, we have CC = state {y 7→ u } • (Wk 0 k Upd ) 4 Rbt 1 1 1 1 1 send update.d 0 f 0 0 CC2 =b state {y 7→ u2} • (Wk2 k Upd2) 4 Rbt2 Sys −−−−−−−−−→ PP1 k (CC1 k CC2) k CC3 CC3 =b state {y 7→ u3} • on3 → C3 The net transition is that the producer PP1 has b The values ui are the local values of y, and the sent the message to CC1, while CC2 and CC3 have 0 0 processes Wk1 and Wk2 represent the current stage ignored the message, for different reasons. This of execution of the working tasks for C1 and C2. type of selective communication is more difficult to Process C3 is suspended until the event on3 occurs. specify using only CSP-like synchronisation. 14 3.3. Related work message m (storing the passed values (if any) into The motivation for the message passing scheme a list of variables). defined in this section is in modelling networks The bottom line of Fig. 7 gives four node modi- with transient agents, where other communication fiers, which operate on some node N : a well-formed schemes such as shared-variable and synchronisa- tree will therefore contain a node N at some other 4 tion are also required. The main point of technical place . A goto node indicates that the subsequent difference with CSP synchronisation are that the behaviour should be that of the subtree rooted at sender is never blocked waiting for a receiver. node N . Any such tree must appear in an alterna- A related communication mechanism is the bar- tive branch. Typically goto nodes (and reversion rier synchronisation of Occam [36], where processes nodes, see below) are leaf nodes. Goto nodes are can dynamically register an interest in a barrier, used as a shorthand when the same behaviour oc- and all such processes are blocked until every other curs in different parts of the tree. A process kill registered process is ready. In that scheme there node terminates any behaviour associated with the is no explicit sender, and as such is closer to CSP tree rooted at node N . The target node must ap- synchronisation. Other situations in which message pear in a concurrent branch. A reversion node al- passing frameworks must be combined with state- lows iteration. A well-formed Behavior Tree will based constructs include security protocols, as ex- have a node N as an ancestor of the reversion node, plored, for instance, by Chevalier et al. [37, 38]. and any behaviour associated with the tree rooted Cardelli and Gordon explore the concept of ambi- at N is restarted from that point. A synchroni- ent processes more abstractly in [39]. sation node indicates participation in a synchronisation event. Each such node synchronising on N blocks until all other such nodes are also at the 4. Behavior Trees synchronisation point, at which time they may all progress and N is executed. In this section we provide a brief and informal Each node has an associated tag, which is used for description of Behavior Trees and the method for traceability. The tag records from which require- developing specifications from requirements; more ment(s) the node originates. This allows tracking of detail on Behavior Trees, and the motivation for requirements and facilitates requirements change. them, is available elsewhere [6, 7, 8]. The Behavior In addition, nodes can be colour-coded, to indi- Tree notation as presented in [6] also includes other cate where the developer has introduced assump- constructs, which may be mapped into the basic tions/behaviour, or modified/removed behaviour primitives we give here. with respect to the original requirements.

4.1. Notation and informal description Constructors. A Behavior Tree is one of the four Nodes. The Behavior Tree node types are given forms in Fig. 8: sequential flow, alternative flow, in Fig. 7. Each node refers to a specific compo- concurrent flow or atomic composition. A sequen- nent (C ), and describes some operation involving tial flow of a node N with a tree T indicates simple that component. A state update node updates the ordering on node execution: node N is executed, state of C to some expression S, while a guard after which T is ready for execution. Because sev- node blocks until predicate P is satisfied by C ’s eral trees may be executing in parallel, it is possible state. The full Behavior Tree notation includes that the behaviour of other nodes will be interleaved many types of nodes and node combinators for ex- before and after N . pressing predicates on the state and for updates, Alternative flow indicates that one of T1, .., Tn but in this paper we have used generalised “state will be executed after N , depending on which is en- updates” and “guard” nodes. It is straightforward abled first. If none are enabled, execution blocks to map the original Behavior Tree nodes and node until one of them is ready to execute (e.g., by the combinators into our more general node. reception of a message). If more than one are en- In addition to these state-based nodes, the no- abled, a nondeterministic choice is made as to which tation includes message-based communication. An is executed. output event node indicates that C generates message m (possibly with a list of values). The re- 4This well-formedness condition, and others described ciprocal input event node blocks until C receives later, can be checked syntactically [5]. 15 C C C C Tag [S] Tag ??? P ??? Tag > m < Tag < m >

State update Guard Input event Output event

=> -- ^ @ Tag N Tag N Tag N Tag N

Goto Process kill Reversion Synchronise

Figure 7: Behavior Tree nodes

N N N N1

...

...... T T1 Tn T1 Tn Nn

Sequential Alternative Concurrent Atomic flow flow flow composition

Figure 8: Behavior Tree constructors

A concurrent flow from node N to a set of trees, them to contain some sort of defect, e.g., redun- T1, .., Tn , indicates that after N is executed, all of dancy, incompleteness, ambiguity. Particularly im- the trees are ready for execution. portant problems to detect are associated with in- An atomic composition of nodes N1, .., Nn indi- consistent vocabulary, which can be introduced in cates that there is no opportunity for processes op- documents with multiple authors: using different erating in parallel to interleave between the execu- terms to represent the same concept, and, more tion of the Ni s. Therefore the nodes operate to- insidious, using the same term to refer to differ- gether in a single atomic action, with the order of ent concepts. The process of developing a Behav- execution being sequentially from N1. Atomic com- ior Tree can be divided amongst a group of peo- position is distinguished graphically from sequential ple who work in parallel. The trees are then inte- flow by omitting the arrowhead on the connecting grated by identifying syntactically matching nodes, line. To be well-formed, an atomic composition of and joining them appropriately. The tags are also nodes must contain at most one node of type in- merged in the joining nodes, serving to highlight put/output event, process kill, reversion, or syn- the overlapping nature of the requirements. The chronisation. An atomic composition of nodes may resulting structure helps to identify errors in the take the place of a single node in the other three requirements, and the result is a single Behavior constructors. Tree which describes the system as a whole.

4.2. Application The process has the benefit that it can be initially The Behavior Tree method is designed for trans- split amongst developers working largely indepen- lating a requirements document, in which each re- dently. The combination of tagging and colour cod- quirement is numbered, into a structured model. ing means that clients can use the Behavior Tree The first step is to systematically translate each model to quickly find problems with the require- individual requirement into a Behavior Tree and ments and compare them to the original document. record the requirement number in the tag. In ad- We demonstrate the approach more fully with an dition, nodes are coloured if the developer believes example. 16 Sensor R3 < halt >

Control Sensor R1 [init] R2 > error <

Control R3 ???ready???

R1 Sensor Control Sensor > error < R1 [ready] R2 < halt >

Sensor R1 R2 R3 > error < R3

Control Control Control R4 [ready] R5 [active] R6 [ready]

R4 Control R5 Control Control Control > bpush1 < > bpush1 < R5 > bpush2 < R6 > halt <

Control Control Control Control R4 [active] R5 [modeA] R5 [modeB] R6 [shutdown]

R4 R5

Control R6 R6 [ready]

Figure 9: Individual requirements

4.3. Example R3. After telling the Control to halt, the Sensor In this section we show an example of how the waits until the Control is ready before trying Behavior Tree notation is used to construct a spec- to detect further errors. iﬁcation from natural language requirements. For R4. After the Control component is ready, if but- presentation purposes we give a partial speciﬁca- ton 1 is pressed the Control component be- tion of a controller system, with the intention of comes active. showing the type of systems and requirements for R5. While the Control component is active, if but- which the Behavior Tree notation is designed. ton 1 is pressed it enters mode A, or if button 2 is pressed it enters mode B. 4.3.1. The system and its requirements R6. At any time after the Control component has Consider an abstract system, which is comprised become ready, if a halt message is received, of a Control component with two buttons, and a the Control goes into shutdown mode before Sensor component. The behaviour of the system is returning to the ready state. given by the following requirements: R1. After performing tasks required for initialisa- 4.3.2. Individual requirements translation tion, the Control component becomes ready The translation of the individual requirements and the Sensor can detect errors. are given in Fig. 9. The translation process serves R2. When the Sensor detects an error, it tells the to compile a vocabulary of component names, com- Control to halt. ponent states, messages, and events, which are col- 17 Sensor R4 Control R2 > error < R6 [ready]

R2 Sensor R4 Control Control R3 < halt > > bpush1 < R6 > halt <

Control Control Control R3 ???ready??? R4 [active] R6 [shutdown]

Sensor ^ Control ^ R3 >error< R6 [ready]

(a) (b)

Figure 10: Partial integration of (a) Requirements R2 and R3 and (b) Requirements R4 and R6 lected in the Composition Tree5. In translating Re- system is restarted). quirement R1, we have abstracted the initialisation Several issues are raised during the translation, tasks as the state init, and used ready for the sub- for instance, in Requirement R6, is the halt message sequent state. The Sensor and Control are given as only of relevance while the Control is in the state parallel subtrees, as it appears they are intended to ready, or should the same behaviour follow even if operate concurrently. We use error as the message it has progressed to state active? For this exam- name for detecting error events from the environ- ple, we have assumed the Control will be shutdown ment. Requirement R2 is translated as a sequential anytime it receives a halt message. Another issue is flow, such that after the error event is detected, what happens if the second button is pressed while the sensor sends the halt message, which is a mes- the Control is ready? We have assumed that the sage used exclusively for communication between second button is ignored unless Control is active. the Sensor and the Control. Requirement R3 is These are exactly the types of issues that Behavior also translated using sequential flow, making use of Tree modelling is intended to highlight; while such a guard node to test the state of Control. An alter- issues will be raised whichever modelling language native to using a guard node to model the “wait” or approach is used, using Behavior Trees the task is to synchronise with the Control process on its is systematic. If the modeller notes choices and readiness, and thus move from shared-variable com- assumptions using the colour coding, they can be munication to synchronised communication. We traced back to the original requirements document explore this alternative further in Sect. 5.3.2. Once using the tags, facilitating discussion with the orig- the Control is known to be in the ready state, the inator of the requirements as the model develops. Sensor returns to its earlier behaviour of waiting for an error event. This will likely become a re- 4.3.3. Requirements integration version node, since it is repeat behaviour, but this We now integrate the individual trees to con- will be resolved during the integration phase. Re- struct a full view of the system. The integration quirement R4 and Requirement R6 are translated process is based on finding syntactically matching similarly. Requirement R5 is translated using alter- nodes, and completing other aspects of the tree such native choice between the two input events. Once as reversion. Although this process is systematic, one of the buttons is pressed, the Control enters the there are still choices for the modeller to make, in corresponding mode and will not leave it (unless the particular, if the integration results in a branch, whether the branch should be a parallel or alterna- 5As mentioned earlier, we do not consider the static in- tive choice. The order in which trees are integrated formation contained in Composition Trees in this paper. will also effect the shape of the final tree. The con- 18 Control R1 [init]

R1 Sensor R1 Control R2 > error < R4 [ready] R6

R2 Sensor R4 Control Control R3 < halt > > bpush1 < R6 > halt <

Control R4 Control Control R3 ???ready??? R5 [active] R6 [shutdown]

^ Sensor R5 Control Control Control ^ R3 > error < > bpush1 < R5 > bpush2 < R6 [ready]

Control Control R5 [modeA] R5 [modeB]

Figure 11: Fully integrated requirements tribution of the Behavior Tree modelling approach ward. The resulting Behavior Tree, giving the com- is not to eliminate such choices, but to make the plete behaviour of the system, is shown in Fig. 11. choice explicit and traceable in the model. The system has been built out of its natural lan- Requirements R2 and R3 integrate end-to-end, guage requirements in a straightforward manner. since they share a common (joining) node. Fur- Even though the requirements we have given are thermore, because the leaf node Sensor > error < contrived for simplicity, they demonstrate that even matches one of its ancestors, it is flagged as a re- in simple systems there is considerable room for version node. The resulting tree, which captures (mis)interpretation of natural language. Using the the behaviour of the Sensor component, is shown Behavior Tree approach, inconsistencies and mod- in Fig. 10(a). Note that the joining node refer- elling assumptions can be highlighted and commu- ences the tags for both requirements. Fig. 10(b) nicated to the client, and through keeping (multi- shows the result of integrating Requirements R4 ple) tags in the tree, traceability from the tree back and R6. In this case the integration point (node to the original requirements is maintained. Control[ready]) is the root node of both trees. For example, consider a variation on Require- We must decide whether the resulting branches are ment R3 in which the first phrase is omitted: The composed in parallel or as alternatives. As men- Sensor waits until the Control is ready before try- tioned above, we assume that the halt message is ing to detect further errors. The resulting trans- always of relevance, and hence is not affected by lation would appear as in Fig. 9, without the first the subsequent behaviour of Control; hence we in- Sensor < halt > node. This means that Require- tegrate the trees using parallel composition. The ment R3 no longer integrates with Requirement R2. Control[ready] leaf node is also flagged as a re- One may be tempted to treat the guard as a state version. realisation instead, and integrate it with the root It remains to integrate Requirement R5 with node of Requirement R6, but this leads to an in- Fig. 10(b), and to integrate both trees with Re- consistent tree where it is unclear that the Sensor quirement R1, both of which tasks are straightfor- process needs to be restarted. The error of omission 19 may be resolved by adding the missing node to Re- of course be unmarked. The marking is a tempo- quirement R3 and flagging it as a missing require- rary syntactic construct used only as an intermedi- ment using the colour coding, and later confirming ate step in the translation. The marking may be the decision with the client using the tags. Errors achieved through a simple depth-first traversal of of ambiguity may be discovered if there are multiple the tree, since any Behavior Tree has a finite num- integration points; redundancy may be discovered if ber of subtrees. there are identical subtrees; and inconsistency may Given the existence of a node N−− in the tree, be uncovered if integration leads to contradictory the target tree of that node, say T, is replaced by behaviour. kill:T. Tree T must be the subtree which has root node N. A similar translation occurs for trees that are the target of a reversion, or of both a process 5. Translating Behavior Trees to CSPσ kill and a reversion.

In this section we describe how Behavior Trees 5.2. Phase 2 may be translated into CSPσ processes. The trans- Having identified the targets of process kills and lation process is defined so that the structure of reversion, and having eliminated goto nodes, the the tree is preserved, and is summarised in Fig. 12. translation to CSPσ may begin. We use the The translation occurs in two phases: the first is to relation to transform a Behavior Tree to a CSPσ identify and mark subtrees that are the target of process, or a node to a CSPσ action. process kill and reversion. The second phase trans- The left-hand column of Fig. 12 for Phase 2 is a lates the marked trees recursively. We describe this left-to-right textual representation of the constructs in more detail below. Throughout the translation which were depicted graphically in Figs. 7 and 8, process we assume that given a Behavior Tree node as well as the marked trees described above. The N, a canonical representation of N may be gener- translated versions are given in the right-hand col- ated and used as events and messages. For instance, umn. from the node Control[ready] we may generate a string such as control.ready. We write rev(N) for 5.2.1. Targets of process kill the reversion (restart) event generated from node A tree with root node N that is marked as the N, and kill(N) for the kill message generated from target of a process kill node is translated to an in- node N. terrupt process, where the interrupt is triggered by the canonical message kill(N). As described below, 5.1. Phase 1 this is the message that is sent by the corresponding process kill node, N−−. After the kill message Phase 1 is an initial traversal of the Behavior Tree is received, the process terminates. to handle the node modifiers that refer to subtrees found elsewhere in the structure. The first task in 5.2.2. Targets of reversion Phase 1 is to replace goto nodes N=> with the target Before giving the translation for the target of a tree, which we write as tree(N), i.e., the subtree with reversion we first briefly discuss the difference be- root node N. For this replacement to be well-formed, tween reversion and recursion: in a reversion the the scope of the node and its target must be the behaviour of relevant sibling threads must termi- same. That is, they must reference the same set of nate. In this sense, a reversion behaves as a restart. variables, events, and messages. This is implied by When a thread with a reversion does not contain the well-formedness constraints on Behavior Trees, any parallelism, then the behaviour is identical to and that source and target nodes of a goto must that of recursion. Consider the following example: appear in sibling branches in an alternative flow. The remaining tasks of Phase 1 are to mark µ r • (µ s • .. → s) k (.. → r) trees that are the target of a process kill or reversion. Given a tree T we let kill:T be the tree There are two threads operating in parallel. The marked as the target of a process kill, rev:T be inner thread scoped by the recursion name s may the tree marked as a target of a reversion node, be thought of as a sensor, while the other thread and kill,rev:T be the tree marked as the target may be some controller thread. Under certain con- of both a process kill and a reversion. Trees may ditions, the controller thread will need to restart the 20 Phase 1. N=> becomes tree(N) Let N be root(T) T becomes kill:T if N−− exists T becomes rev:T if Nˆ exists T becomes kill,rev:T if N−− and Nˆ exist

Phase 2. 0 0 0 0 Let N be root(T), and assume T T , Ti Ti , N N , and Ni Ni kill:T T 0 4 (recv kill(N) → STOP) rev:T restart(rev(N), T 0) kill,rev:T restart(rev(N), T 0) 4 (recv kill(N) → STOP)

N -> T N 0 → T 0 0 0 0 N ->[] (T1, .., Tn) N → (T1 [] .. [] Tn ) 0 0 0 0 N -> (T1, .., Tn) N → ((T1 k T2) k .. k Tn ) A1 A2 An−1 0 0 (N1 -- .. -- Nn) (N1 ◦ .. ◦ Nn )

C[s] C := S C???s??? [C = S] C > m < recv m C < m > send m

N−− send kill(N) Nˆ rev(N) N@ (N 0, sync(N))

Figure 12: Translation summary entire system. As the program above is written, ev- 5.2.3. Targets of process kill and reversion ery time the controller restarts the system through In the case where a node is the target of both a unfolding r, a new copy of the sensor thread will process kill and a reversion, the resulting process be generated. However, this does not model the becomes a restart inside an interrupt. The process typical restart of a system, where each subthread will execute, and restart, as usual, until the kill mes- will be restarted individually. This is the meaning sage is received, and all behaviour is terminated. of reversion, and is part of the Behavior Tree notation because within requirements documents it is 5.2.4. Translation of constructors more common to find “restart” behaviour than the behaviour associated with pure recursion. A sequential flow in Behavior Trees, represented textually as N -> T, is straightforwardly translated The target of a reversion node becomes a restart to prefixing in CSPσ. Alternative flow, represented process, where the restart is triggered by the canon- textually as N ->[] (T1, .., Tn), is straightfor- ical event rev(N). This is an event that occurs in- wardly translated to external choice. ternally to T 0, and is generated by a corresponding Concurrent branching, represented textually as N source reversion node, Nˆ. When the event rev(N) is -> (T1, .., Tn), is translated to an alphabetised 0 generated by the execution of T , the subprocesses parallel composition. Given a composition T1 kT2, associated with the tree T 0 are terminated and a A new copy of T 0 begins (recall abbreviation (2)). the interface A is the intersection of the common 21 6 synchronisation events in T1 and T2. 5.2.6. Kill nodes An atomic composition of nodes, represented tex- A kill node is translated to the sending of message tually as (N1 -- .. -- Nn), are relationally com- kill(N), which is the interrupt message in the target posed into a single command/event pair. The in- process. Note that we use a message rather than dividual nodes are translated independently, and an event, in case the target thread is not active or composed in order. Since there can be at most one relevant at this point. This way the killing thread event or message in a CSPσ action, there can be does not need to wait. at most one event-based node in the chain. This means there may be at most one node of type in- 5.2.7. Reversion nodes put/output event, process kill, reversion, or syn- A reversion node, represented textually as Nˆ, is chronisation in the chain. The remaining nodes translated to the canonical event rev(N). must be guards, state updates, with potentially a By default we do not place the event rev(N) into goto node as the leaf (assuming the chain does not the interfaces of parallel composition. This means also contain a reversion). that any single reversion node will trigger a restart. The relational composition of two specification However, this may result in undesirable race condi- commands which have the same frame is given be- tions in some cases. An alternative is for all related low, and is described in detail in [20]. reversion nodes (or a selection of them) to synchro- 00 00 00 x x nise before the restart can take place. In Behavior x : [R ] ◦ x : [R ] = x : [∃ x • R [ 0 ] ∧ R [ ]] 1 2 1 x 2 x Trees, this behaviour can be expressed by coupling x 00 the reversion symbol with the synchronisation sym- The expression R [ 0 ] is R with a syntactic re- 1 x 1 bol. To translate this behaviour into CSP , the placement of variables x 0 with x 00. Note that this σ rev(N) event must be added to the interfaces of the is a different type of substitution to that involv- relevant parallel composition operators. ing states. For the purposes of defining relational composition when the frames do not match, their 5.2.8. Synchronisations frames may be widened according to the rule below. A synchronisation, represented textually as N@, 0 x : [R] = x, y : [R ∧ y = y] is mapped to a CSPσ event sync(N), which, as (17) for x ∩ y = ∅ above, we assume may be constructed canonically from N . In addition, the node N itself must We lift relational composition to command/event be translated, and this is paired with the event pairs, as defined below. sync(N). This implies that the node N must be a guard or state update, as it is not possible to (c1, τ) ◦ (c2, τ) = (c1 ◦ c2, τ) combine more than one event or message. This is (c1, a) ◦ (c2, τ) = (c1 ◦ c2, a) = (c1, τ) ◦ (c2, a) typical of process algebras, where it is not possible to atomically combine the actions of one event with The composition is undefined if more than one of another. the pairs has a non-internal event. An example of For instance, the node Control[ready]@ is trans- translating atomic composition is given in Sect. 5.3. lated to

5.2.5. Translation of state- and event-based nodes (Control := ready, control.ready) A state update C[s] is straightforwardly translated to an update of C to the value s, C := s. A where the event control.ready has been constructed guard C ???s??? is translated simply to [C = s]. from the node itself. Since all synchronisation The full syntax for Behavior Trees contains con- nodes by deﬁnition encode the same test or update structs for tests other than equality; these may be of a component, only one of the synchronisation translated straightforwardly to guards as well. nodes requires the translated node to be paired with Input nodes, C > m <, are translated to receiving the event; the remaining nodes are translated to the messages, and outputs, C < m >, to sending mes- singular event sync(N). sages. 5.3. Example translation

6This is a similar process to determining the alphabet of The translation of the Behavior Tree in Fig. 11 an individual process following the ideas of Hoare [10]. is given in Fig. 13. To ease the presentation we 22 Sys = (state {Control 7→ } • Main)\{send halt, recv halt} Main =b (Control := init) → restart b ( (rev(s), Sensor)) k (restart(rev(c), ControlReady)) Sensor = recv error → send halt → [Control = ready] → rev(s) ControlReady =b (Control := ready) → recv b halt → (Control := shutdown) → rev(c) k recv bpush1 → (Control := active) → (recv bpush1 → (Control := modeA) [] recv bpush2 → (Control := modeB))

Figure 13: Translated version of Fig. 11

break the definition into several (named) subpro- R1 Sensor ... R2 > error < cesses. Because there are no synchronisations, the interfaces of the parallel composition operators are Level R6 ??? >50 ??? empty and hence omitted. All revert events e are R2 Sensor written rev(e), and for brevity we allow leaf nodes R3 < halt > N to abbreviate the process N → SKIP. At the top Sensor -- level we define the process Sys, which gives the con- R6 > error < text of the system. It includes the variable Control Control R3 to represent the state of the Control component, ???ready??? ... which has some unknown initial value (represented by an underscore), and the halt message is hidden from external observers. The error and bpush mes- Sensor ^ sages are not hidden, since they are received from R3 >error< processes outside of the scope of Sys. The translation of this behaviour requires a new message name, say, kill(s), which is generated by This example shows the translation of the con- some environment process. This event acts as an trol structures parallel, alternative, and sequential interrupt to the Sensor process, which is now ex- flow, and the node types state update, guard, intended to handle this message. put/output event and reversion. We now provide examples of the remaining constructs. .. → [level > 50] → send kill(s) → .. k SensorInt

where SensorInt = Sensor 4 recv kill(s). The execution of this treebis straightforward application of known CSP constructs. The introduction of the process kill node means that the node Sensor >error< is now the target of 5.3.1. Process kill both a kill and a reversion.

Consider an extension to the controller system where another behaviour involves the destruction 5.3.2. Synchronisation of the sensor process when the sensor level exceeds Consider using synchronisation nodes to commu- some threshold. nicate between the Control and the Sensor. 23 Control Control by C , to represent the three nodes. R1 [init] R1 Control R4 ???ready??? R6

R1 @ R1 Sensor Control R4 Control R2 > error < R4 [ready] > bpush1 < R6

R4 Control R5 [active] R2 Sensor ... R3 < halt >

R5 Control Control > bpush1 < R5 > bpush2 < Control @ R3 [ready]

Control Control R5 [modeA] R5 [modeB]

Sensor ^ R3 >error< (C : [C = ready ∧ C 0 = active], recv bpush1) → .. Instead of a guard to check whether the Control is ready, the Sensor synchronises on the change to 5.4. Summary the ready state. Note the use of the synchronisation We have presented a general process for trans- flag “@”. lating Behavior Trees into an extended version of The synchronisation nodes are translated as de- CSP. The structure of the Behavior Tree itself is scribed earlier: we arbitrarily choose one of the preserved, with only minor additions required for nodes (in the Control process) to contain the action handling reversion and process termination. The of updating the Control, while both nodes synchro- most complex translation was that for reversion, nise on the event control.ready, which is placed into due to its subtle difference to recursion; however, the interface of the parallel operator. the restart operator is roughly of the same com- Control := init → plexity as the interrupt and exception operators of (Control := ready, control.ready) → .. CSP [11, 34]. k{control.ready} Since there is a structure-preserving mapping (.. → control.ready → ..) from Behavior Trees to an extended version of CSP, based on an operational semantics, there is scope This is a stronger, and perhaps more correct, for using program verification methods such as ani- version of the specification, since the Sensor will mation, model checking, and refinement, which can restart as soon as the Control becomes ready; us- build on existing support for CSP. Furthermore, the ing a guard, the Sensor will not become ready until structure-preserving nature of the translation also the next time the Sensor process takes a step. This admits representing the animation of the dynamic is a common issue (a “race condition”) with shared- behaviour of the models back to the original graph- variable communication. ical Behavior Tree. This “backwards-translation” 5.3.3. Atomic composition process would show the dynamic flow of control Consider a modification of the controller system through the requirements document using the tags in which, when the Control component is in the on the nodes. ready state and button1 is pushed, the Control immediately becomes active. Unarrowed lines are 6. Conclusions used to connect the first three nodes. The three nodes are combined into a single atomic action, In this paper we have presented a semantics for which is enabled based on the state of the com- Behavior Trees. This is a graphical notation used ponent Control, a message being received, and in- for building a model of a system from requirements cludes an update of the state. found in informally written documents, and as such Using relational composition as de- it contains a collection of language constructs: state scribed earlier, we generate the follow- changes and tests, message passing, and synchroni- ing single action, in which we abbreviate sation. Typical specification languages are either 24 state-based, such as Z [40] and VDM [41], or inter- References action based, such as CSP [10, 11] and CCS [42]. Our approach to defining the semantics for Behav- ior Trees was to extend CSP, which natively han- [1] R. G. Dromey, D. Powell, Early requirements defects detection, TickIT Journal 4Q05 (2005) 3–13. dles process synchronisation, to include hierarchi- [2] D. Powell, Requirements evaluation using Behav- cal state and a publish/subscribe notion of message ior Trees - findings from industry, Industry Track passing. We then give a translation from the Be- Papers, Australian Software Engineering Confer- havior Tree notation into a process in the extended ence (ASWEC), http://aswec07.cs.latrobe.edu.au/ itp-aswec2007.htm, (2007). CSP language. The formal semantics provides a [3] P. Papacostantinou, T. Tran, P. Lee, V. Phillips, Im- definition of the Behavior Tree notation which can plementing a Behaviour Tree analysis tool using Eclipse be used as the basis for developing tool support development frameworks, in: A. Aitken, S. Rosbotham such as simulators, model checking, and theorem (Eds.), 19th Australian Software Engineering Confer- ence, Experience Report Proceedings, Curtin Univer- proving. sity of Technology, 2008, pp. 61–66. Plotkin’s seminal paper on operational seman- [4] L. Wen, R. Colvin, K. Lin, J. Seagrott, N. Yata- tics [35] defines transition rules for imperative lan- panage, R. G. Dromey, “Integrare”, a collaborative environment for behavior-oriented design, in: Y. Luo guages with state. There are also many other exam- (Ed.), Cooperative Design, Visualization, and Engi- ples of such semantics in the literature, notably the neering (CDVE), Vol. 4674 of Lecture Notes in Com- semantics of Hoare and He Jifeng [43], and the se- puter Science, Springer, 2007, pp. 122–131. mantics for the programming language Occam [36]. [5] L. Grunske, K. Winter, N. Yatapanage, Defining the abstract syntax of visual languages with advanced graph Our approach is different in that the state is treated grammars - a case study based on Behavior Trees, J. as part of the process, and guards and updates are Vis. Lang. Comput. 19 (3) (2008) 343–379. treated as labels to the transition relation. This [6] R. Dromey, Formalizing the transition from requirements to design, in: H. Jifeng, Z. Liu (Eds.), Mathe- allows state accesses to be (perhaps partially) in- matical Frameworks for Component Software: Models stantiated within a context which defines the val- for Analysis and Synthesis, Component-Based Develop- ues of the local state. The traditional operational ment, World Scientific Publishing Co., Inc., River Edge, semantics approach defines the transition relation NJ, USA, 2006, pp. 156–187. [7] R. G. Dromey, From Requirements to Design: Formal- on program/state pairs, and the state is updated in izing the Key Steps, Keynote Address, in: 1st Interna- the rule for each construct (e.g., update). This ap- tional Conference on Software Engineering and Formal proach does not so easily support the hierarchical Methods (SEFM), IEEE Computer Society, 2003, pp. construction of the state as in our approach, with 2–11. [8] C. Smith, K. Winter, I. J. Hayes, R. G. Dromey, P. A. local variables in the traditional style being cap- Lindsay, D. A. Carrington, An environment for building tured as global variables with syntactic restrictions. a system out of its requirements., in: 19th IEEE Inter- In the approach adopted here, by treating state ac- national Conference on Automated Software Engineer- cess as transition labels, the state-based reasoning ing (ASE), IEEE Computer Society, 2004, pp. 398–399. [9] Raytheon Australia, http://www.raytheon.com. is ‘quarantined’ to a single, general rule (Rule 12), au/rtnwcm/groups/rau/documents/download/rau_ allowing the construct rules, e.g., Rule 1, to be de- factsheets_behaviortrees.pdf. fined concisely, and without explicit reference to a [10] C. A. R. Hoare, Communicating Sequential Processes, particular state. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1985. [11] A. Roscoe, The Theory and Practice of Concurrency, Prentice Hall, 1998. [12] P. T. Eugster, P. A. Felber, R. Guerraoui, A.-M. Ker- Acknowledgements. The authors thank the De- marrec, The many faces of publish/subscribe, ACM pendable Complex Computer-based Systems group, Comput. Surv. 35 (2) (2003) 114–131. [13] Formal Systems (Europe) Ltd, Failures-Divergence Re- especially R. Geoff Dromey and Kirsten Winter, for finement: FDR2 User Manual (1999). their help with the Behavior Tree notation. We [14] M. Leuschel, M. Fontaine, Probing the Depths of CSP- also thank the three anonymous referees of [20] for M: A New FDR-Compliant Validation Tool, in: S. Liu, T. S. E. Maibaum, K. Araki (Eds.), Formal Methods their comments on the CSPσ language, and three and Software Engineering, 10th International Confer- anonymous referees of this paper for their sugges- ence on Formal Engineering Methods (ICFEM), Vol. tions for improvement. This work is supported, in 5256 of Lecture Notes in Computer Science, Springer, part, by the Australian Research Council (ARC) 2008, pp. 278–297. Linkage Grant LP0989363, Reducing the risks asso- [15] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Mod- eling Language Reference Manual, Addison-Wesley, ciated with developing large-scale, critical software- 1998. integrated systems. [16] R. Colvin, I. J. Hayes, A semantics for Behavior Trees, 25 ACCS Technical Report ACCS-TR-07-01, ARC Centre Notes in Computer Science, Springer, 2009, pp. 709– for Complex Systems (April 2007). 714. [17] K. Winter, Formalising Behaviour Trees with CSP, [32] S. Schneider, Concurrent and Real-time Systems: The in: Integrated Formal Methods, Vol. 2999 of LNCS, CSP Approach, Wiley, 2000. Springer Verlag, 2004, pp. 148–167. [33] C. Morgan, Programming from Specifications, 2nd Edi- [18] R. Colvin, L. Grunske, K. Winter, Timed Behavior tion, Prentice Hall, 1994. Trees for failure mode and effects analysis of time- [34] A. W. Roscoe, The three platonic models of divergence- critical systems, Journal of Systems and Software strict csp, in: J. S. Fitzgerald, A. E. Haxthausen, 81 (12) (2008) 2163–2182. H. Yenigun¨ (Eds.), International Colloquium on The- [19] R. Colvin, L. Grunske, K. Winter, Probabilistic timed oretical Aspects of Computing (ICTAC), Vol. 5160 of Behavior Trees, in: J. Davies, J. Gibbons (Eds.), Pro- Lecture Notes in Computer Science, Springer, 2008, pp. ceedings of the International Conference on Integrated 23–49. Formal Methods (IFM), Vol. 4591 of Lecture Notes in [35] G. D. Plotkin, A structural approach to operational se- Computer Science, Springer-Verlag, 2007, pp. 156–175. mantics., J. Log. Algebr. Program. 60-61 (2004) 17–139. [20] R. Colvin, I. J. Hayes, CSP with hierarchical state, in: [36] Y. Gurevich, L. S. Moss, Algebraic operational seman- M. Leuschel, H. Wehrheim (Eds.), Integrated Formal tics and Occam, in: E. Börger, H. K. Buning,¨ M. M. Methods (IFM 2009), Vol. 5423 of Lecture Notes in Richter (Eds.), Proceedings of 3rd Workshop on Com- Comp. Sci., Springer, 2009, pp. 118–135. puter Science Logic (CSL 89), Vol. 440 of Lecture Notes [21] J. C. P. Woodcock, A. L. C. Cavalcanti, The seman- in Computer Science, Springer, 1990, pp. 176–192. tics of circus, in: D. Bert, J. P. Bowen, M. C. Henson, [37] Y. Chevalier, L. Compagna, J. Cuéllar, P. H. Drielsma, K. Robinson (Eds.), ZB 2002: Formal Specification and J. Mantovani, S. Mödersheim, L. Vigneron, A high level Development in Z and B, Vol. 2272 of Lecture Notes in protocol specification language for industrial security- Computer Science, Springer-Verlag, 2002, pp. 184–203. sensitive protocols, in: Specification and Automated [22] G. Smith, A semantic integration of Object-Z and CSP Processing of Security Requirements, Austrian Com- for the specification of concurrent systems, in: J. S. puter Society, 2004, pp. 193–205. Fitzgerald, C. B. Jones, P. Lucas (Eds.), 4th Interna- [38] A. Armando, D. A. Basin, Y. Boichut, Y. Chevalier, tional Symposium of Formal Methods Europe, (FME L. Compagna, J. Cuéllar, P. H. Drielsma, P.-C. Héam, 97), Vol. 1313 of Lecture Notes in Computer Science, O. Kouchnarenko, J. Mantovani, S. Mödersheim, D. von Springer, 1997, pp. 62–81. Oheimb, M. Rusinowitch, J. Santiago, M. Turuani, [23] C. Fischer, H. Wehrheim, Model-Checking CSP-OZ L. Viganò, L. Vigneron, The AVISPA tool for the au- Specifications with FDR, in: K. Araki, A. Galloway, tomated validation of internet security protocols and K. Taguchi (Eds.), Integrated Formal Methods, 1st In- applications, in: K. Etessami, S. K. Rajamani (Eds.), ternational Conference, Proceedings, Springer, 1999, Computer Aided Verification, 17th International Con- pp. 315–334. ference (CAV 2005), Proceedings, Vol. 3576 of Lecture [24] M. Butler, A CSP Approach to Action Systems, Notes in Computer Science, Springer, 2005, pp. 281– Ph.D. thesis, Computing Laboratory, Oxford Univer- 285. sity (1992). [39] L. Cardelli, A. D. Gordon, Mobile ambients, in: M. Ni- [25] M. J. Butler, M. Leuschel, Combining CSP and B for vat (Ed.), Foundations of Software Science and Compu- specification and property verification, in: J. Fitzger- tation Structure, First International Conference (FoS- ald, I. J. Hayes, A. Tarlecki (Eds.), FM 2005: Formal SaCS’98), Vol. 1378 of Lecture Notes in Computer Sci- Methods, International Symposium of Formal Meth- ence, Springer, 1998, pp. 140–155. ods Europe, Proceedings, Vol. 3582 of Lecture Notes [40] J. M. Spivey, The Z Notation: A Reference Manual, in Computer Science, Springer, 2005, pp. 221–236. 2nd Edition, Prentice Hall, 1992. [26] S. Schneider, H. Treharne, CSP theorems for communi- [41] C. B. Jones, Systematic Software Development using cating B machines, Formal Asp. Comput. 17 (4) (2005) VDM, Prentice Hall, 1990. 390–422. [42] R. Milner, A Calculus of Communicating Systems, [27] J. C. M. Baeten, J. A. Bergstra, Global renaming oper- Springer-Verlag New York, Inc., Secaucus, NJ, USA, ators in concrete process algebra, Inf. Comput. 78 (3) 1982. (1988) 205–245. [43] C. A. R. Hoare, H. Jifeng, Unifying Theories of Pro- [28] J. C. M. Baeten, J. A. Bergstra, Process algebra gramming, Prentice Hall, 1998. with propositional signals, Theor. Comput. Sci. 177 (2) (1997) 381–405. [29] K. G. Larsen, L. Xinxin, Compositionality through an operational semantics of contexts, J. Log. Comput. 1 (6) (1991) 761–795. [30] J. Sun, Y. Liu, J. S. Dong, C. Chen, Integrating specification and programs for system modeling and verification, in: W.-N. Chin, S. Qin (Eds.), Third IEEE Inter- national Symposium on Theoretical Aspects of Software Engineering (TASE), IEEE Computer Society, 2009, pp. 127–135. [31] J. Sun, Y. Liu, J. S. Dong, J. Pang, PAT: Towards flexible verification under fairness, in: A. Bouajjani, O. Maler (Eds.), 21st International Conference on Com- puter Aided Verification (CAV), Vol. 5643 of Lecture 26