Behavior tree: Difference between revisions

Revision as of 18:23, 4 June 2025

Latest revision as of 09:03, 7 August 2025

(26 intermediate revisions by 22 users not shown)

Line 1:

{{Short description|Structured visual modeling technique}}

{{about|behavior trees for requirement handling|another use|Behavior tree (artificial intelligence, robotics and control)}}

{{Use dmy dates|date=May 2025}}{{Use American English|date=May 2025}}

Line 5 ⟶ 6:

[[File:Static Integrated View.jpg|thumb|320px|Building a system out of its requirements – static view]]

A '''behavior tree''' is a structured visual [[modeling]] technique used in [[systems engineering]] and [[software engineering]] to represent thesystem behavior of a system. It employsutilizes a hierarchical tree-shaped diagram composed of [[node (computer science)|nodes]] and connectors to depictillustrate thecontrol flow ofand control andsystem actions within the system. By replacing ambiguous [[natural language]] descriptions with standardized visual elements—such as boxes, arrows, and standard symbols—behavior trees aim to improve clarity, reduce misinterpretation, and enhance system understanding of complex systems.<ref>{{Cite book |last=Lindsay |first=Peter A. |chapter=Behavior Trees: From Systems Engineering to Software Engineering |date=2010-09-01 |title=2010 8th IEEE International Conference on Software Engineering and Formal Methods |chapter-url=https://doi.org/10.1109/sefm.2010.11 |publisher=IEEE |pages=21–30 |doi=10.1109/sefm.2010.11|isbn=978-1-4244-8289-4 |chapter-url-access=subscription }}</ref>

== Overview ==

The extensive amount of detail involved in describing the numerous requirements forof a large-scale system using natural language can lead to [[short-term memory]] overload,<ref name="dromey07EngLgeScale">Dromey, R.G. 2007. [http://www.beworld.org/BE/resource/presentation/Eng-LargeScale-Systems.pdf Principles for Engineering Large-Scale Software-Intensive Systems]</ref><ref name="raytheonSysResearch">Boston, J. 2008. [http://www.raytheon.com.au/Default.aspx?x=501 Raytheon Australia supports pioneering systems research] {{webarchive|url=https://web.archive.org/web/20090915050723/http://www.raytheon.com.au/Default.aspx?x=501|date=15 September 2009}}</ref> hindering a comprehensive understanding of the system's needs.<ref name="raytheonAustJoint" /> In the use of [[naturalNatural language]], thereoften are oftenintroduces ambiguities, aliases, inconsistencies, redundancies, and incomplete information to concepts.<ref name = "dromey03K1-Dromey"/> This creates uncertainty and makesover-complicates the system appear more complexsystems.

The behavior tree representation (withattempts to eliminate uncertainty by limiting vocabulary to the original requirements. Large requirement sets may require the help of thea composition tree<ref name = "compositionTree">Behavior Engineering. [http://www.behaviorengineering.org/index.php?option=com_content&task=view&id=24&Itemid=34 Composition Trees] {{Webarchive|url=https://web.archive.org/web/20090302063932/http://www.behaviorengineering.org/index.php?option=com_content&task=view&id=24&Itemid=34 |date=2 March 2009 }}</ref> representation that already resolves aliasaliases and other vocabulary problems within largea setsprior ofstep. requirements)The attemptsaim to eliminate these problemsis to produce a deep, accurate, and holistic representation of system needs<ref name = "dromey07EngLgeScale"/> that can be understood by all readers (often [[Project stakeholder|stakeholders]]), because it strictly uses the vocabulary of the original requirements. Since the behavior tree notation uses [[Semantics of programming languages|formal semantics]], it can beserve madeas intoinput for further processing, such as making an [[executable]] for anya given exampleset of requirements.

=== Behavior tree forms ===

Line 17 ⟶ 18:

Both single and integrated (composite) behavior tree forms are important in applying behavior trees in [[systems engineering|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, throughusing 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.<ref name = "winters">Winter, K. 2007. [http://espace.library.uq.edu.au/eserv/UQ:100586/Formalising_behaviour_trees_with_csp.pdf Formalising Behaviour Trees with CSP]</ref> 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.

Line 24 ⟶ 25:

=== Behavior engineering process ===

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

;<nowiki>'''Representation:</nowiki>'''

* 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.

;<nowiki>'''Process:</nowiki>'''

* 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 engineering|systems]] and [[software engineering]] were originally developed by Geoff Dromey.<ref name="dromey06FormalizingTrans">R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/Dromey-Chapter-Final-20051.pdf "Formalizing the Transition from Requirements to Design"] {{Webarchive|url=https://web.archive.org/web/20110725053952/http://www.behaviorengineering.org/publications/dromey/Dromey-Chapter-Final-20051.pdf |date=25 July 2011 }}, 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)</ref><ref name="dromey03K1-Dromey">R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/K1-Dromey.pdf From Requirements to Design: Formalizing the Key Steps] {{Webarchive|url=https://web.archive.org/web/20110725054005/http://www.behaviorengineering.org/publications/dromey/K1-Dromey.pdf |date=25 July 2011 }}, (Invited Keynote Address), SEFM-2003, IEEE International Conference on Software Engineering and Formal Methods, Brisbane, Sept. 2003, pp. 2–11.</ref><ref>R.L.Glass, [http://www.behaviorengineering.org/publications/Bob-Glass-GSE-CACM.pdf "Is This a Revolutionary Idea or Not"] {{Webarchive|url=https://web.archive.org/web/20110725054100/http://www.behaviorengineering.org/publications/Bob-Glass-GSE-CACM.pdf |date=25 July 2011 }}, Communications of the ACM, Vol. 47(11), pp. 23–25, Nov. 2004.</ref><ref>R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/Dromey.pdf "Climbing Over the ‘No Silver Bullet’ Brick Wall"] {{Webarchive|url=https://web.archive.org/web/20110725054117/http://www.behaviorengineering.org/publications/dromey/Dromey.pdf |date=25 July 2011 }}, IEEE Software, Vol. 23, No. 2, pp. 118–120, (March 2006)</ref> with theThe first publication of some of the key ideas were in 2001.<ref>R.G.Dromey, Genetic Software Engineering – Simplifying Design Using Requirements Integration, IEEE Working Conference on Complex and Dynamic Systems Architecture, Brisbane, Dec 2001.</ref> 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 appearedappear 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.

Line 47 ⟶ 51:

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.<ref>{{Cite web |title=Behavior Engineering World » History of Behavior Engineering |url=https://www.beworld.org/BE/home/history-of-behavior-engineering/ |access-date=2025-05-24 |language=en-US}}</ref>

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 cancould be expressed.<ref name="probTimedBTs">Colvin, R., Grunske, L., Winter, K. 2007 [http://www.behaviorengineering.org/publications/grunske/IFM1.pdf Probabilistic Timed Behavior Trees] {{Webarchive|url=https://web.archive.org/web/20110725054158/http://www.behaviorengineering.org/publications/grunske/IFM1.pdf |date=25 July 2011 }}</ref>

== Key concepts ==

Line 71 ⟶ 75:

[[File:Requirement Translation Example.jpg|240px|thumb|Example requirement translation]]

[[File:Requirements Behavior Tree Integration.png|thumb|240px|Requirements behavior tree integration]]

Requirements’Requirements translation is the vehicle used to cross the informal-barrier. Consider the process of translation for requirement R1 below. The first tasks are to identify the components ('''bold'''), identify the behaviors (<u>underlined</u>), and identify indicators of the order (''italics'') in which behaviors take place. The corresponding behavior tree can then be constructed.

What is clear from the outcome of this process is that, apart from pronouns, definite articles, etc., essentially all the words in the sentences that contribute to the behavior they describe have been accounted for and used.

Line 90 ⟶ 94:

In general, many defects become much more visible when there is an integrated view of the requirements<ref name = "dromey07EngLgeScale"/> 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<ref name = "BTNotation" /> 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.<ref name = "buildEnv04">Smith, C., Winter, K., Hayes, I., Dromey, R.G., Lindsay, P., Carrington, D.: [https://ieeexplore.ieee.org/document/1342775 An Environment for Building a System Out of Its Requirements], 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, Sept. (2004).</ref>

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 languages|modeling notations]] and methods (i.e. [[Unified Modeling Language|UML]]), it is less clear-cut when modelingmodelling can stop.<ref name = "shuttle04" /> 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.<ref name = "Integrare07">L.Wen, R.Colvin, K.Lin, J.Seagrott, N.Yatapanage, R.G.Dromey, 2007, [http://www98.griffith.edu.au/dspace/bitstream/10072/18625/1/43991_1.pdf "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, 2007</ref><ref name = "realTimeColloab06">C. Sun, S. Xia, D. Sun, D. Chen. H.F. Shen, W. Cai: [http://portal.acm.org/citation.cfm?doid=1188816.1188821 "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.</ref>

==== Model- checking ====

A translator has been written to convert a model behavior tree into the "actions systems" language. This input can then be fed into the SAL Model- checker<ref name = "SAL2">Bensalem, S., Ganesh, V., Lakhnech, Y., Muñoz, C., Owre, et al.: "An Overview of SAL", Fifth NASA Langley Formal Methods Workshop (LFM 2000), 2000, pp. 187–196.</ref><ref>Rushby, J. [http://fm.csl.sri.com/AFM06/slides/Rushby-intro-tutorial.pdf Automated Formal Methods 2006] AFM-2006, Automated Formal Methods 2006, Seattle, August 2006, pp. 6–7.</ref> to allow checks to be made as to whether certain safety and security properties are satisfied.<ref name = "automatedFailEffect05" /><ref name="embeddedSys05">Zafar, S. and Dromey, R. G., 2005. [http://www.behaviorengineering.org/publications/dromey/Zafar-SETE2005-ManagingComplexity.pdf Managing Complexity in Modelling Embedded Systems.] {{Webarchive|url=https://web.archive.org/web/20110725054400/http://www.behaviorengineering.org/publications/dromey/Zafar-SETE2005-ManagingComplexity.pdf |date=25 July 2011 }} Systems Engineering/Test and Evaluation Conference 2005, 7–9 November, Brisbane, Australia</ref>

==== Failure mode and effects analysis (FMEA) ====

[[Model checking|Model-checking]] has often been applied to system models to check that hazardous states can’t be reached during normal operation of the system.<ref name = "probabilistic07">Grunske, L., Colvin, R., Winter, K. Probabilistic Model-Checking Support for FMEA Quantitative Evaluation of Systems. QEST 2007. Fourth International Conference on the Quantitative Evaluation of Systems, 17-19 Sept. 2007 pp. 119–128</ref> It is possible to combine model-checking with behavior trees to provide automated support for [[failure mode and effects analysis]] (FMEA).<ref name = "automatedFailEffect05" /> The advantage of using behavior trees for this purpose is that they allow the [[formal method]] aspects of the approach to be hidden from non-expert users.

==== Requirement changes ====

Line 117 ⟶ 121:

Behavior tree models are executed in a virtual machine called the behavior run-time environment (BRE). The BRE links together [[Component-based software engineering#Software component|components]] using [[middleware]],<ref name="middleware">RTI Inc. 2007 "Meeting Real-Time Requirements in Integrated Defense Systems", [http://www.rti.com/mk/defense_systems.html RTI White Paper] {{Webarchive|url=https://web.archive.org/web/20080920033015/http://www.rti.com/mk/defense_systems.html |date=20 September 2008 }}.</ref> allowing components to be independent programs written in one of several languages that can be executed in a [[Distributed computing|distributed environment]]. The BRE also contains an expression [[parser]] that automatically performs simple operations to minimize the amount of code required to be manually implemented in the component.

The [[Implementation (computing)|implementation]] of components is supported by views that are automatically able to be extracted from the DBT. These views provide the component behavior trees (CRTs) of individual components, togetheralong with thetheir interfaces of individual components. This information, together with the information in the integrated composition tree (ICT) captured about each component, provides the information needed to implement each component.

Several BREBREs can be linked together to form complex systems using a system-of-systems construct and the behaviorBehavior engineeringEngineering componentComponent integrationIntegration environmentEnvironment (BECIE). BECIE is also used to monitor and control the behavior tree models being executed within a BRE, similar to [[SCADA|supervisory control and data acquisition (SCADA)]] systems used in industrial process control.

Executable behavior trees have been developed for case studies<ref name="shuttle04">Dromey, R.G. [http://www.behaviorengineering.org/publications/dromey/Dromey-SCESM-2004N.pdf Using Behavior Trees to Model the Autonomous Shuttle System] {{Webarchive|url=https://web.archive.org/web/20110725054354/http://www.behaviorengineering.org/publications/dromey/Dromey-SCESM-2004N.pdf |date=25 July 2011 }}, 3rd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools (SCESM04) ICSE Workshop W5S, Edinburgh, 25 May 2004</ref> including automated train protection, <ref name = "integratingSoftHard08" /> mobile robots with a dynamic object following, an ambulatory infusion pump,<ref name = "integratingSafety05" />, and traffic light management systems. A version of the BRE suited for embedded systems (eBRE) is also available, that haswith reduced functionality totailored tailor it tofor small -footprint [[Microcontroller|micro-controllers]]microcontrollers.

== Applications ==

Behavior tree modellingmodeling can and has been applied to a diverse range of applications over a number of years. Some of the main application areas are described below.

=== Large-scale systems ===

Modeling large-scale systems with largeextensive sets of natural-language requirements has always been thea major focus for testing behavior trees and the overall behavior engineering process. Conducting these evaluations and trials of the method has involved work with a number of industry partners and government departments in Australia. The systems studied have included a significant number of defense systems, enterprise systems, transportation systems, information systems, health systems, and sophisticated control systems with stringent safety requirements. The results of these studies have all been classified as commercial-in-confidence. However, the results of the extensive industry trailstrials<ref name = "raytheonSysResearch" /><ref name = "raytheonAustJoint" /> with [[Raytheon]] Australia are presented below in the Industry Section. This work has consistently shown that translating requirements andinto creatingintegrated dynamicstatic and staticdynamic integratedbehavior-tree views ofrevealed requirementssubstantially leads to discovery of a very significant number ofmore major defects, over and abovethan the defectscompany’s thatstandard arereview foundprocesses by current industry best-practicedetected.<ref name = "industryTrialsPaper" /><ref name = "boston08" />

=== Embedded systems ===

Failure of a design to satisfymeet a system's requirements can result in schedule and cost overruns.<ref>Barker, D. 2000. [https://ieeexplore.ieee.org/document/890177 Requirements modeling technology: a vision for better, faster, and cheaper systems.] Proceedings from VHDL International Users Forum Fall Workshop, 2000. pp. 3–6.</ref> If there are also critical dependability issues, not satisfying system requirements can have life-threatening consequences.<ref>Leveson, N. G. Safeware: System Safety and Computers: [a guide to preventing accidents and losses caused by technology]. Addison-Wesley Publishing Company, 1995. {{ISBN|0-201-11972-2}}</ref> However, in current approaches, ensuring that requirements are satisfiedmet is often delayed until late in the development process, during a cycle of testing and debugging..<ref>Futrell, R. T., Shafer, D.F., Shafer, L.I. Quality Software Project Management (Software Quality Institute Series). Prentice Hall, 2002 {{ISBN|0-13-091297-2}}</ref> This work describes how the system development approach, behavior engineering, can be used to develop software for [[embedded system]]s.<ref name = "embeddedSys05" /> The result is a [[model-driven development]] approach that can createcreates embedded system software that satisfiesmeeting its requirements asthrough athe resultapplication of applying the development process.

=== Hardware – software systems ===

Line 139 ⟶ 143:

=== Biological systems ===

Because behavior trees describe complex behavior, they can be used for describing a range of systems not limited to those that are computer-based.<ref name = "contracts02" /> In a biological context, BTbehavior trees can be used to piece together a procedural interpretation of biological functions described in research papers, treating the papers as the requirements documents as described above. This can help to construct a more concrete description of the process than is possible from reading only and can also be used as the basis for comparing competing theories in alternative papers. In ongoing research, the behavior tree notation is being used to develop models of the brain function in rats under [[fear conditioning]].

=== Game AI modeling ===

{{main|Behavior tree (artificial intelligence, robotics and control)}}

While BTbehavior hastrees have become popular for modeling the [[artificial intelligence]] in computer games such as [[Halo (franchise)|Halo]]<ref name = "HaloBT">Damian Isla [https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai Handling Complexity in the Halo 2 AI.]</ref> and [[Spore (2008 video game)|Spore]],<ref name = "sporeBT">Chris Hecker [http://chrishecker.com/My_Liner_Notes_for_Spore/Spore_Behavior_Tree_Docs My Liner Notes for Spore]</ref> these types of trees are very different from the ones described on this page and are closer to a combination of hierarchical [[finite-state machine]]s or [[decision trees]]. Soccer-player modeling has also been a successful application of BTbehavior trees.<ref name = "SoccerBT">Xiao-Wen Terry Liu and Jacky Baltes [http://www.cs.umanitoba.ca/~jacky/Publications/pdf/liu04:_intuit_flexib_archit_intel_mobil_robot.pdf An Intuitive and Flexible Architecture for Intelligent Mobile Robots] 2nd International Conference on Autonomous Robots and Agents, December 13–15, 2004 Palmerston North, New Zealand</ref><ref name = "HoshinoBT">Yukiko Hoshino, Tsuyoshi Takagi, Ugo Di Profio, and Masahiro Fujita [http://web.mit.edu/zoz/Public/ICRA04-Hoshino.pdf Behavior description and control using behavior module for personal robot]</ref>

=== Model-Based Testing ===

[[Model-based testing]] is an approach to software testing that requires testers to create test models from requirements of Software Under Test (SUT). Traditionally, modeling languages such as UML state chartsstatecharts, [[Finite-state machine|finite-state machines]] (FSMs), EFSM ([[Extendedextended finite-state machine|Extendedmachines Finite-State Machines]](EFSMs){{expand acronym|ab|date=April 2025}}, and flowflowcharts chartshave arebeen used as the modeling language. Recently, an interesting approach in which Event-Driven Swim Lane Petri Net (EDSLPN) is used as the modeling language also appeared. Behavior tree notation should be considered as a good modeling notation to MBT also, and it has a few advantages among other notations:

# It has the same expressiveness level as UML state charts and EDSLPN.

# It is intuitive to use as a modeling notation due to its graphical nature.

# Each behavior tree node has a requirement tag; these greatly facilitate the creation of a traceability matrix from requirement to test artifact.<ref>{{CitationCite web needed|datetitle=MayA Model Based Testing tool - MBTester · 测试之家 |url=https://testerhome.com/topics/18850 |access-date=2025-06-12 |website=testerhome.com}}</ref>

== Scalability and industry applications ==

[[File:Behavior Engineering Support Environment.png|thumb|225px|Screen-shotScreenshot of behavior engineering support environment tool]]

[[File:Integrated Behavior Tree Larger System.png|thumb|225px|Integrated behavior tree – larger system (more than 1000 requirements)]]

The first industry trials to test the feasibility of the method and refine its capability were conducted in 2002. Over the last three years, a number of systematic industry trials on large-scale defense, transportation, and enterprise systems have been conducted.<ref name = "raytheonSysResearch" /><ref name="industryTrialsPaper">Powell, D. 2007. [http://www.behaviorengineering.org/docs/ASWEC07_Industry_Powell.pdf Requirements Evaluation Using Behavior Trees – Findings from Industry] {{Webarchive|url=https://web.archive.org/web/20110725061927/http://www.behaviorengineering.org/docs/ASWEC07_Industry_Powell.pdf |date=25 July 2011 }}</ref> This work has established that the method scales to systems with large numbers of requirements but also that it is important to use tool support<ref name = "Integrare07" /><ref name = "RaytheonAswec08" /> in order to efficiently navigate and edit the resultant large integrated views of graphical data. On average, over a number of projects, 130 confirmed major defects per 1000 requirements have consistently been found after normal reviews and corrections have been made.<ref name = "industryTrialsPaper" /> With less mature requirements sets, much higher defect rates have been observed.

Line 161 ⟶ 165:

An important part of this work with industry has involved applying the analysis part of the method to six large-scale defense projects for [[Raytheon]] Australia. They see the method as "a key risk mitigation strategy, of use in both solution development and as a means of advising the customer on problems with acquisition documentation".<ref name = "boston08" /><ref>McNicholas, D., (Raytheon Australia), 2007. [http://www.behaviorengineering.org/images/publications/dromey2/be-industry-benefits.doc Behavior Engineering Industry Benefits]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> An outcome of these industry trials has been the joint development<ref name="raytheonAustJoint">Raytheon Australia, 2008. [http://www.raytheon.com.au/Files/Behavior%20Trees.pdf Understanding grows on Behavior Trees] {{Webarchive|url=https://web.archive.org/web/20090915050633/http://www.raytheon.com.au/Files/Behavior%20Trees.pdf |date=15 September 2009 }}</ref> with Raytheon Australia of an industry-strength tool to support the analysis, editing, and display of large integrated sets of requirements.<ref name="RaytheonAswec08">Phillips, V., (Raytheon Australia), [http://www.behaviorengineering.org/images/publications/dromey2/bese_master_v2.ppt "Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks"]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}, Australian Software Engineering Conference (ASWEC’08), Perth, March 2008</ref> More extensive details of industry findings can be found on the Behavior Engineering website.<ref name = "BEWebsite">Behavior Engineering. [http://www.behaviorengineering.org/ Behavior Engineering website] {{Webarchive|url=https://web.archive.org/web/20090301170621/http://www.behaviorengineering.org/ |date=1 March 2009 }}</ref>

Dr. Terry Stevenson (chief technical officer, Raytheon Australia), Mr. Jim Boston (senior project manager, Raytheon Australia), Mr. Adrian Pitman from the [[Defence Materiel Organisation|Australian Defense Materiel Organization]], Dr. Kelvin Ross (CEO, K.J. Ross & Associates), and Christine Cornish (Bushell & Cornish) have provided the special opportunities needed to support this research and to conduct the industry trials<ref name = "raytheonSysResearch" /><ref name = "industryTrialsPaper" /> and live project work. This work has been supported by the [[Australian Research Council]] – [[ARC Centre for Complex Systems]] and funds received from industry.{{citation<ref>For needed|date=Aprilfurther 2015}}details see:

<ref>For further details see:

*[http://www.raytheon.com.au/Files/Behavior%20Trees.pdf Raytheon Australia – Behavior Trees Joint Development] {{Webarchive|url=https://web.archive.org/web/20090915050633/http://www.raytheon.com.au/Files/Behavior%20Trees.pdf |date=15 September 2009 }}

*[http://www.behaviorengineering.org/images/publications/dromey2/bese_master_v2.ppt "Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks"]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }} Vincent Phillips, Raytheon Australia.

Line 171 ⟶ 173:

== Advantages ==

As a behavior modellingmodeling representation, behavior trees have a number of significant benefits and advantages:

* They employ a well-defined and effective strategy for dealing with requirement complexity, particularly where the initial needs of a system are expressed using hundreds or thousands of requirements written in natural language. This significantly reduces the risk on large-scale projects.<ref name = "industryTrialsPaper"/>

* By rigorously translating then integrating requirements at the earliest possible time, they provide a more effective means for uncovering requirement defects than competing methods.<ref name = "industryTrialsPaper"/><ref name="boston08">Boston, J., (Raytheon Australia), [http://www.behaviorengineering.org/images/publications/dromey2/sp8_powerpoint_jim_boston.pdf Behavior Trees – How they improve Engineering Behaviour?]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}, 6th Annual Software and Systems Engineering Process Group Conference (SEPG 2008), Melbourne, Aug. 2008.</ref>

Line 178 ⟶ 180:

* They build the behavior of a system out of its [[functional requirements]] in a directly traceable way, which aids [[verification and validation]].<ref name = "Integrare07" /><ref name="verifValid06">Zafar, S., K.Winter, R.Colvin, R.G.Dromey, [http://www.behaviorengineering.org/publications/dromey/Zafar_Integrated_BTRBAC.pdf "Verification of an Integrated Role-Based Access Control Model"] {{Webarchive|url=https://web.archive.org/web/20110725061854/http://www.behaviorengineering.org/publications/dromey/Zafar_Integrated_BTRBAC.pdf |date=25 July 2011 }}, 1st International Workshop – Asian Working Conference on Verified Software (AWCVS'06), pp 230-240, Macao, Oct. 2006.</ref>

* They can be understood by [[Stakeholder (corporate)|stakeholders]] without the need for [[formal methods]] training. By strictly retaining the vocabulary of the original requirements, this eases the burden of understanding.

* They have a [[Semantics of programming languages|formal semantics]],<ref name = "colvinHayesNotation" /> they support [[Concurrency (computer science)|concurrency]], they are [[executable]], and they can be [[simulated]], [[Model checking|model- checked]], and used to undertake [[failure mode and effects analysis]].<ref name = "automatedFailEffect05" />

* They can be used equally well to model human processes, to analyze contracts,<ref name = "contracts02">Milosevic, Z., Dromey, R.G. [https://ieeexplore.ieee.org/document/1137692 On Expressing and Monitoring Behavior in Contracts], EDOC 2002, Proceedings, 6th International Enterprise Distributed Object Computing Conference, Lausanne, Switzerland, Sept. 2002, pp. 3-14.</ref> to represent forensic information, to represent biological systems, and a lot ofmany other applications. In each case, they deliver the same benefits in terms of managing complexity and seeing things as a whole. They can also be used for [[Safety-critical system|safety critical systems]],<ref name = "integratingSafety05" /> [[embedded system]]s,<ref name = "embeddedSys05" />, and [[real-time systems]].<ref name="realTimeCollab05">Lin, K., Chen, D., Sun, C., Dromey, R.G., [http://www.behaviorengineering.org/publications/kailin/CDVEO5_Kevin.pdf A Constraint Maintenance Strategy and Applications in real-time Collaborative Environments]{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}, 2nd International Conference on Cooperative Design, Visualization and Engineering (CDVE2005), 2005.</ref><ref name="dataflowContstraint06">Lin, K., Chen, D., Dromey, R.G., Sun, CZ.: [http://www.behaviorengineering.org/publications/kailin/IEEE06_Kevin.pdf Multi-way Dataflow Constraint Propagation in Real-time Collaborative Systems] {{Webarchive|url=https://web.archive.org/web/20110725061427/http://www.behaviorengineering.org/publications/kailin/IEEE06_Kevin.pdf |date=25 July 2011 }}, IEEE, The 2nd International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom 2006), Atlanta, Georgia, USA, Nov, 2006.</ref><ref name="timeBT07">Grunske, L., Winter, K., Colvin, R., [http://www.behaviorengineering.org/publications/grunske/ASWEC20072.pdf "Timed Behavior Trees and their application to verifying real-time systems"] {{Webarchive|url=https://web.archive.org/web/20081118165542/http://www.behaviorengineering.org/publications/grunske/ASWEC20072.pdf |date=18 November 2008 }}, Proceedings of 18th Australian Conference on Software Engineering (AEWEC 2007), April 2007, accepted for publication.</ref>

== Disadvantages ==

* For small textbook -level examples, their tree-like nature means that the graphic models produced are sometimes not as compact as the [[state diagram]] or [[state machine]] behavior specifications.

* Tool support is needed to navigate the huge integrated behavior trees for systems that have hundreds or thousands of requirements.

* Presentation to a large group can be difficult, given the inherent size of a complicated system's tree.

* A group walk-through for huge systems, good display facilities are needed.

* There is a need to provide additional sophisticated tool support to fully exploit integrated behavior tree models.

Line 203 ⟶ 205:

[[Category:Enterprise modelling]]

[[Category:Modeling languages]]

[[Category:Software engineering]]