A behavior tree is a structured visual modeling technique used in systems engineering and software engineering to represent system behavior. It utilizes a hierarchical tree diagram composed of nodes and connectors to illustrate control flow and system actions. By replacing ambiguous natural language descriptions with standardized visual elements—such as boxes, arrows, and standard symbols—behavior trees improve clarity, reduce misinterpretation, and enhance understanding of complex systems.

Overview The extensive amount of detail involved in describing the numerous requirements of a large-scale system using natural language can lead to short-term memory overload,Dromey, R.G. 2007. Principles for Engineering Large-Scale Software-Intensive SystemsBoston, J. 2008. Raytheon Australia supports pioneering systems research hindering a comprehensive understanding of the system's needs.Raytheon Australia, 2008. Understanding grows on Behavior Trees Natural language often introduces ambiguities, aliases, inconsistencies, redundancies, and incomplete information to concepts. This creates uncertainty and over-complicates systems.

The behavior tree representation attempts to eliminate uncertainty by limiting vocabulary to the original requirements. Large requirement sets may require the help of a composition treeBehavior Engineering. Composition Trees representation that resolves aliases and other vocabulary problems in a prior step. The aim is to produce a deep, accurate, and holistic representation of system needs that can be understood by all readers (often stakeholders). Since the behavior tree notation uses formal semantics, it can serve as input for further processing, such as making an executable for a given set of requirements.

Behavior tree forms

Both single and integrated (composite) behavior tree forms are important in applying behavior trees in systems and software engineering.

Requirement behavior trees (RBT): Initially, individual requirement behavior trees are constructed to capture all behavioral fragments from each natural language requirement, using a rigorous translation process that preserves both intent and vocabulary. The translation process can uncover a range of defects in original natural language requirements. Integrated behavior trees (IBT): Because a set of requirements imply the integrated behavior of a system, all the individual requirement behavior trees can be composed to construct an integrated behavior tree that provides a single holistic view of the emergent integrated behavior of the system. This enables the construction of the system's integrated behavior from its requirements.Winter, K. 2007. Formalising Behaviour Trees with CSP An analogy to help describe this process is the transition from a randomly arranged set of jigsaw puzzle pieces to putting each of the pieces in its appropriate place. When this happens, each piece of information is placed in its intended context and their collective emergent properties become clear.

Having all the requirements converted to behavior trees (RBT) is similar to having all the pieces for a jigsaw puzzle randomly spread out on a table – until all the pieces are connected, the emergent picture remains unclear, and it is uncertain whether any pieces are missing or don’t fit. Constructing an integrated behavior tree (IBT) reveals emergent behavior and missing pieces.

Behavior engineering process Critical aspects of behavior engineering representation and process are listed below.

Representation: The composition tree's role in the overall process is to provide a means to overcome the imperfect knowledge associated with the large set of requirements for a system. Process:

Behavior engineering uses behavior trees to control complexity while growing a shared understanding of a complex system.

A shared holistic understanding of a complex system integrates requirements to show its implied emergent behavior.

History Behavior trees and the concepts for their application in systems and software engineering were originally developed by Geoff Dromey.R.G.Dromey, "Formalizing the Transition from Requirements to Design" , in "Mathematical Frameworks for Component Software – Models for Analysis and Synthesis", Jifeng He, and Zhiming Liu (Eds.), World Scientific Series on Component-Based Development, pp. 156–187, (Invited Chapter) (2006)R.G.Dromey, From Requirements to Design: Formalizing the Key Steps , (Invited Keynote Address), SEFM-2003, IEEE International Conference on Software Engineering and Formal Methods, Brisbane, Sept. 2003, pp. 2–11.R.L.Glass, "Is This a Revolutionary Idea or Not" , Communications of the ACM, Vol. 47(11), pp. 23–25, Nov. 2004.R.G.Dromey, "Climbing Over the ‘No Silver Bullet’ Brick Wall" , IEEE Software, Vol. 23, No. 2, pp. 118–120, (March 2006) The first publication of some of the key ideas were in 2001.R.G.Dromey, Genetic Software Engineering – Simplifying Design Using Requirements Integration, IEEE Working Conference on Complex and Dynamic Systems Architecture, Brisbane, Dec 2001. Early publications on this work used the terms "genetic software engineering" and "genetic design" to describe the application of behavior trees. The reason for originally using the word "genetic" was because sets of genes, sets of jigsaw puzzle pieces, and sets of requirements, when represented as behavior trees, all appear to share several key properties:

They contained enough information as a set to allow them to be composed – with behavior trees, this allows a system to be built out of its requirements. The order in which the pieces were put together was not important – with requirements, this aids in coping with complexity. When all the members of the set were put together, the resulting integrated entity exhibited a set of important emergent properties.

For behavior trees, important emergent properties include: The integrated behavior of the system is implied by the requirements. The coherent behavior of each component is referred to in the requirements.

These genetic parallels, in another context, were originally spelled out by Adrian Woolfson.A. Woolfson, Life Without Genes, Flamingo, 2000, Berlin, I. The Crooked Timber of Humanity: Chapters in the History of Ideas, Ed., H.Hardy, Princeton University Press, 1998

Despite these legitimate genetic parallels, it was felt that this emphasis led to confusion with the concept of genetic algorithms. As a result, the term behavior engineering was introduced to describe the processes that exploit behavior trees to construct systems.

Since the behavior tree notation was originally conceived, several people from the Dependable Complex Computer-based Systems Group (DCCS – a joint University of Queensland, Griffith University research group) have made important contributions to the evolution and refinement of the behavior tree notation and usage.

Probabilistic timed behavior trees have been developed by researchers such as Rob Colvin, Lars Grunske, and Kirsten Winter of the DCCS, so that reliability, performance, and other dependability properties could be expressed.Colvin, R., Grunske, L., Winter, K. 2007 Probabilistic Timed Behavior Trees

Key concepts

Behavior tree notation

A behavior tree is used to formally represent the fragment of behavior in each requirement. In general, behavior for a large-scale system, where concurrency is admitted, appears abstractly as a set of communicating sequential processes. The behavior tree notation captures these composed component-states and represents them as a tree-like form.

Traceability tags (see Section 1.2 of behavior tree notation) in behavior tree nodes link the formal representation to the corresponding natural language requirement.Dromey, R.G. "Genetic Design: Amplifying Our Ability to Deal With Requirements Complexity" , in S.Leue, and T.J. Systra, Scenarios, Lecture Notes in Computer Science, LNCS 3466, pp. 95–108, 2005.

A behavior tree with leaf nodes may revert (symbolized by adding the caret operator "^") to an ancestor node to repeat behavior or start a new thread (symbolized by two carets "^^").

For a complete reference to behavior tree notation, see Behavior Tree Notation v1.0 (2007).Behavior Tree Group, ARC Centre for Complex Systems, 2007. Behavior Tree Notation v1.0 (2007)

Semantics The formal semantics of behavior trees is given via a process algebra and its operational semantics.Colvin, R., Hayes, I.J. 2006 A Semantics for Behavior Trees The semantics have been used as the basis for developing simulation, model checking, and failure modes and effects analysis.L.Grunske, P.Lindsay, N.Yatapanage, K.Winter, An Automated Failure Mode and Effect Analysis Based on High-Level Design Specification with Behavior Trees, Fifth International Conference on Integrated Formal Methods (IFM-2005), Eindoven, The Netherlands, 2005.Zafar, S. and Dromey, R. G., (2005), Integrating Safety and Security Requirements into Design of an Embedded System. Asia-Pacific Software Engineering Conference 2005, 15–17 December, Taipei, Taiwan. IEEE Computer Society Press. pp. 629–636.

Requirements translation

Requirement integration Operations on integrated behavior trees Once an integrated behavior tree has been composed, there are a number of important operations that can be performed upon it.

Inspection: defect detection and correction In general, many defects become much more visible when there is an integrated view of the requirements and each requirement has been placed in the behavior context where it needs to execute. For example, it is much easier to tell whether a set of conditions or events emanating from a node is complete and consistent. The traceability tags also make it easy to refer back to the original natural-language requirements. There is also the potential to automate a number of defect and consistency checks on an integrated behavior tree.Smith, C., Winter, K., Hayes, I., Dromey, R.G., Lindsay, P., Carrington, D.: An Environment for Building a System Out of Its Requirements, 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, Sept. (2004).

When all defects have been corrected and the IBT is logically consistent and complete, it becomes a model behavior tree (MBT), which serves as a formal specification for the system's behavior that has been constructed out of the original requirements. This is the clearly defined stopping point for the analysis phase. With other modeling notations and methods (i.e. UML), it is less clear-cut when modelling can stop. In some cases, parts of a model behavior tree may need to be transformed to make the specification executable. Once an MBT has been made executable, it is possible to carry out a number of other dependability checks.

Simulation A model behavior tree can be readily simulated to explore the dynamic properties of the system. Both a symbolic tool and a graphics tool have been constructed to support these activities.L.Wen, R.Colvin, K.Lin, J.Seagrott, N.Yatapanage, R.G.Dromey, 2007, "Integrare, a Collaborative Environment for Behavior-Oriented Design", in Proceedings of the Fourth International Conference on Cooperative Design, Visualization and Engineering, LNCS 4674, pp. 122–131, 2007C. Sun, S. Xia, D. Sun, D. Chen. H.F. Shen, W. Cai: "Transparent adaptation of single-user applications for multi-user real-time collaboration", ACM Transactions on Computer-Human Interaction, Vol. 13, No.4, December 2006, pp. 531–582.

Model checking