Behavior tree: Difference between revisions

Content deleted Content added
Citation bot (talk | contribs)
Alter: title, template type. Add: chapter-url-access, isbn, chapter-url, chapter. Removed or converted URL. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Headbomb | #UCB_toolbar
 
(One intermediate revision by one other user not shown)
Line 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 ====
Line 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" />, and traffic light management systems. A version of the BRE suited for embedded systems (eBRE) is also available, with reduced functionality tailored for small-footprint microcontrollers.
 
== Applications ==
Line 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" />, 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 ==