Formalisms for Robotic Mission Specification and Execution: A Comparative Analysis
Organizations: Gran Sasso Science Institute (GSSI), L’Aquila, Italy
Abstract
Robots are increasingly deployed across diverse domains and designed for multi-purpose operation. As robotic systems grow in complexity and operate in dynamic environments, the need for structured, expressive, and scalable mission-specification approaches becomes critical, with mission specifications often defined in the field by domain experts rather than robotics specialists. However, there is no standard or widely accepted formalism for specifying missions in single- or multi-robot systems. A variety of formalisms, such as Behavior Trees, State Machines, Hierarchical Task Networks, and Business Process Model and Notation, have been adopted in robotics to varying degrees, each providing different levels of abstraction, expressiveness, and support for integration with human workflows and external devices. This paper presents a systematic analysis of these four formalisms with respect to their suitability for robot mission specification. Our study focuses on mission-level descriptions rather than robot software development. We analyze their underlying control structures and mission concepts, evaluate their expressiveness and limitations in modeling real-world missions, and assess the extent of available tool support. By comparing the formalisms and validating our findings with experts, we provide insights into their applicability, strengths, and shortcomings in robotic system modeling. The results aim to support practitioners and researchers in selecting appropriate modeling approaches for designing robust and adaptable robot and multi-robot missions.
Figures & tables
| ID | Profile | Years | Declared expertise | |||
| in role | BT | SM | HTN | BPMN | ||
| par:1 | Postdoc | 1 | 2/5 | 4/5 | 1/5 | 5/5 |
| par:2 | Postdoc | 5 | 5/5 | 5/5 | 3/5 | 3/5 |
| par:3 | Industry | 4 | 4/5 | 3/5 | 5/5 | 3/5 |
| par:4 | PhD student | 5 | 5/5 | 5/5 | 5/5 | 3/5 |
| par:5 | Roboticist | 7 | 5/5 | 4/5 | 3/5 | 2/5 |
| Sequential | Parallel | Conditional | Loop | |
| BT | From left to right from the Sequence or Fallback node | Parallel Node | Combination of Fallback, Sequence, and Condition Nodes | Decorator (possible implementation) |
| is executed before | and are executed in parallel | If is true, then is performed; if is false, then is performed | is executed -times | |
| SM | From initial to final state following triggered events | Fork pseudostate | Choice pseudostate | Transition cycles |
| When is triggered, state remains active until is triggered | The fork pseudostate splits the incoming transition into two transitions, activating and | If is true, is executed; otherwise if is true, is executed | reactivates ’s action, while terminates it |
| Abstraction Level | Example |
| Mission | Serve customers; serve as a butler |
| Task plot | Deliver coffee |
| Skill | Grasp object with constraints |
| Service | Move manipulator |
| Function | Inverse kinematics (IK) solver |
| Execution Control | Activity |
| Skill | Task | Data | Communication | Events | Errors | Pre/post-conditions | |
| BT | Action Node [ 11 , 9 ] | Sub-tree [ 11 , 9 ] | Data inputs to action nodes through ports and blackboard storage [ behaviortree.dev ] [ py-trees.readthedocs.io ] | Rely on action implementation [ 10 ] | Not explicitly modeled. Achievable thanks to conditions that reactively verify if they are true or not through the reactive nature | Not explicitly modeled. Achievable through the reactive nature and Failure propagation | Not explicitly modeled. Achievable through the Postcondition-Precondition-Action (PPA) pattern [ 11 ] |
| SM | Simple State [ 30 , p.308] | Composite State [ 30 , p.308] | Data handled inside states [ 30 ] and global variables configuration [ flexbe.readthedocs.io ] | Rely on behavior implementation | Each transition is associated with an event. But each transition can only be activated if the related state is active | A transition can be related to an error. But each transition can only be activated if the related state is active | Transition guards [ 30 , p.315] . A specialization named Protocol Transition supports pre- and post-conditions [ uml-diagrams.org ] |
| HTN | Primitive Task | Compound Task | In task header (e.g., travel(d)) (Or as a parameter in the task definition) | Rely on primitive task implementation | None | None | In the task and method definition |
| BPMN | Task [ 40 , p.154] , [ 18 , 51 ] | Call Activity or Sub-process [ 40 , p.430] | Data Objects [ 40 , p.224] and process variables [ docs.camunda.org ] | Message or Signal Events [ 40 , p.269-272] , [ 18 ] | Multiple event types capable of represent different situations [ 40 , p.232] , [ 39 , 18 ] | Error Events [ 40 , p.264] [ 39 , 18 ] | Not natively supported. Intermediate events can be used as a workaround. Some works provide extensions to support these conditions [ 52 , 53 ] |
| Concern | PB | HR | VS | KC | FL | LSL | WPH | DG | SUAVE | SA | WA |
| Reactive behavior | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Decision making | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Time-dependent behavior | ✓ | ✓ | |||||||||
| Task status | ✓ | ||||||||||
| Human-robot interaction | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Robot-robot interaction | ✓ | ✓ | ✓ |
| Mission concern | BT | SM | HTN | BPMN | Rationale |
| Reactive behavior | ● | ● | ○ | ● | BT and SM leverage their reactive nature and event-handling structures. BPMN feature boundary events and event sub-processes. HTN does not support it. |
| Decision making | ● | ● | ● | ● | SM and BPMN feature conditional control structures for runtime decision-making. In BTs it is realized by combining fallbacks and sequence nodes. HTN relies on planning according to pre- and post-conditions associated with methods. |
| Time-dependent behavior | ◐ | ◐ | ○ | ● | In BT and SM it has to be realized by manually implementing the control of timing through condition nodes and state implementations, respectively. BPMN features timer events. HTN does not support it. |
| Task status | ● | ● | ○ | ● | BT, SM, and BPMN support it through the value returned by the tick, the events outgoing from a state, and the activity lifecycle, respectively. HTN does not support it. |
| Robot-robot interaction | ◐ | ◐ | ◐ | ● | BT, SM, and HTN rely on the action nodes, states, and tasks implementation, respectively. BPMN has dedicated structures, i.e., message and signal events for communication. |
| Human-robot interaction | ◐ | ◐ | ◐ | ● | BT, SM, and HTN rely on the action nodes, states, and tasks implementation, respectively. BPMN supports user and manual tasks, and the explicit modeling of communication with message/signal events. |
| Strengths | Weaknesses |
| BT | |
| Easily express reactive behavior when the robot has to continuously react to changing conditions. Clear task status semantics, making progress and failure handling a first-class concern. | The semantics Failure is overloaded, making action and condition nodes returning Failure for different reasons (system-level failures or conditions not holding), requiring additional disambiguation through ad hoc nodes to catch possible errors. No standard way for expressing waitings, temporal constraints, and interactions, which must be manually implemented in the action/condition nodes. The use of nodes with memory for keeping track of mission execution state hinders the tree reactivity by limiting the overall tree re-evaluation. |
| SM | |
| Natively model event-driven behavior defining how the system should react to events and transition between states Easily handles task status as distinct states and via transitions outgoing from them. | Handling errors and events requires outgoing transitions from all the potentially affected states, hence requiring explicit transitions from every state for handling system-level events. Task resuming requires ad hoc history states and transitions towards each state. Interactions, messaging, and coordination with other robots, systems, or humans have to be manually realized. Time-dependent behaviors require the manual integration of timers within the state implementation. |
| HTN | |
| Provides support for decision making through runtime planning, achieved by decomposing tasks into sub-tasks using methods. Natively allows explicit definition of pre- and post-conditions. | No expressiveness for reactive behavior, which has to be realized at a different level outside of the mission model. No explicit expression of static choices, which are always demanded to planning. No task status tracking, which is totally demanded to the HTN executor implementation. Interactions, waiting, and time-driven behaviors are not natively supported and must be manually implemented within task definitions. |
| Name | Scope | Description | Documentation Reference |
| BehaviorTree.CPP | Execution; Debugging | C++ library for executing BT. Provides a rich set of control nodes, logging facilities, and interfaces for debugging purposes. | [ behaviortree.dev ] |
| PyTrees | Execution; Monitoring; Debugging | Python library for executing BT, designed to facilitate the rapid development of medium-sized decision-making engines. Offers minimal visualizations for monitoring and debugging purposes. | [ py-trees.readthedocs.io ] |
| Groot | Modeling; Monitoring; Debugging | Graphical editor for BT. Allows tree design, log playback, and real-time introspection when connected to BehaviorTree.CPP. | [ behaviortree.dev/groot ] |
| Forester | Execution | Orchestration engine implementing BT. Supports exporting trees for use with the ROS navigation library. | [ forester-bt.github.io ] |
| BehaviorTree.ROS2 | Execution | ROS-compatible implementation of BehaviorTree.CPP | [ behaviortree.dev/docs/ros2_integration ] |
| PyTrees ROS | Execution | ROS-compatible implementation of PyTrees. | [ py-trees-ros.readthedocs.io ] |
| Name | Scope | Description | Documentation Reference |
| SMACH | Execution; Monitoring | Python library for implementing hierarchical SM in ROS. Provides a runtime viewer that displays active states but offers no modeling interfaces. | [ github.com/ros/executive_smach ] |
| FlexBE | Modeling; Execution; Monitoring; Debugging | Behavior engineering toolkit with a graphical SM editor, execution engine, onboard monitoring, and debugging tools. | [ github.com/flexbe ] |
| YASMIN | Modeling; Execution; Monitoring; Debugging | ROS package for designing and executing SM using Python. Provides a shared blackboard for data exchange and a lightweight execution engine. | [ github.com/uleroboticsgroup/yasmin ] |
| SMACC2 | Execution; Monitoring; Debugging | Event-driven, asynchronous hierarchical state machine library for ROS2 in C++. | [ smacc2.robosoft.ai ] |
| RAFCON | Modeling; Execution; Monitoring; Debugging | Graphical tool for hierarchical and concurrent SM. Includes a graphical interface with visualization, variable inspection, breakpoints, and step-by-step debugging. | [ github.com/DLR-RM/RAFCON ] |
| Name | Scope | Description | Documentation Reference |
| Pyhop | Planning | Lightweight Python HTN planner. Suitable for prototyping due to its simple implementation. | [ pyhop ] |
| SHOP family | Planning | Domain-independent automated-planning systems based on ordered task decomposition. | [ cs.umd.edu/projects/shop ] |
| InductorHTN | Planning | Python and C++ lightweight HTN planning engine based on a Prolog compiler. It has been developed and used for providing planning support to agents in mobile games. | [ github.com/EricZinda/InductorHtn ] |
| HTN Planning AI | Modeling; Planning; Execution; Debugging | Plugin for Unreal Engine providing support for planning game characters’ AI. It provides support for modeling HTNs through a graphical interface, generating plans out of it, running, and debugging the plan. | [ maksmaisak.github.io/htn ] |
| ROSPlan | Planning; Execution | ROS-integrated planning framework. Generates plans and dispatches them to ROS components. | [ kcl-planning.github.io/ROSPlan ] |
| PlanSys2 | Planning; Execution | ROS package providing a planning system. After computing a plan, it automatically converts it into an executable BT, enabling integration with robot controllers. ROS planner package that, after obtaining the plan, automatically converts it into an executable BT. | [ plansys2.github.io ] |
| Name | Scope | Description | Documentation Reference |
| Camunda | Modeling; Execution; Monitoring; Debugging | Process orchestration BPMN platform. Provides graphical modeling tools, workflow engines, REST interfaces, and dashboards for runtime monitoring and debugging. | [ camunda.com ] |
| bpmn.io | Modeling | Web-based BPMN editor and viewer for designing and visualizing process models. Serves as the front-end basis for many BPMN-based applications. Provides many add-ons that can extend its scope. | [ bpmn.io ] |
| FaMe | Modeling; Execution; Monitoring | BPMN-driven framework for multi-robot system development. Provides BPMN modeling, automatic ROS-compliant mission configuration, and an execution engine implemented as a ROS node. | [ pros.unicam.it/fame ] |
| TRACE | Modeling; Execution | A BPMN execution engine providing a connector with the ROS framework. | [ github.com/nasa/trace-executive ] [ github.com/nasa/trace-ros-connector ] |
| B2XKlaim | Modeling; Execution | Translates BPMN diagrams into executable multi-robot coordination code in Klaim, enabling visual mission design and automated code generation. | [ github.com/khalidbourr/B2XKlaim ] |
Behavior Trees
Behavior trees are hierarchical, reactive control structures for organizing tasks, actions, and recovery in robots and autonomous agents.
See all 19 papers