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 definition 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 first 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 rela- tively 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 re- quirements 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 tar- geted 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 transla- tion 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.