|
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 ==
=== 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 trials<ref name = "raytheonSysResearch" /><ref name = "raytheonAustJoint" /> with [[Raytheon]] Australia are presented below in the Industry Section. This work has shown that translating requirements into integrated static and dynamic behavior-tree views revealed substantially more major defects than the company’s standard review processes detected.<ref name = "industryTrialsPaper" />
=== 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 ===
|
