Content deleted Content added
mNo edit summary Tags: Visual edit Mobile edit Mobile web edit |
|||
| (8 intermediate revisions by 7 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 system behavior. It utilizes a hierarchical tree diagram composed of [[node (computer science)|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.<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 ==
Line 24 ⟶ 25:
=== Behavior engineering process ===
Critical aspects of behavior engineering representation and process are listed below.
* 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.
* 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
== History ==
Behavior trees and the concepts for their application in [[systems engineering|systems]] and [[software engineering]] were originally developed by Geoff Dromey
* 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 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
==== Simulation ====
Line 121 ⟶ 125:
Several BREs can be linked together to form complex systems using a system-of-systems construct and the Behavior Engineering Component Integration Environment (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" />
== Applications ==
Line 147 ⟶ 151:
=== 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
# 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>{{
== Scalability and industry applications ==
[[File:Behavior Engineering Support Environment.png|thumb|225px|
[[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.
*[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 179 ⟶ 181:
* 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 many 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" />
== Disadvantages ==
Line 203 ⟶ 205:
[[Category:Enterprise modelling]]
[[Category:Modeling languages]]
[[Category:Software engineering]]
| |||