Formalisms for Robotic Mission Specification and Execution: A Comparative Analysis

Gianluca Filippone; Sara Pettinari; Patrizio Pelliccione

cs.SEMar 16, 2026

Formalisms for Robotic Mission Specification and Execution: A Comparative Analysis

Authors: Gianluca Filippone, Sara Pettinari, Patrizio Pelliccione

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

Fig. 1: Core BT elements.

Fig. 2: Example of mission expressed as a BT.

Fig. 3: Core SM elements.

Fig. 4: Example of mission expressed as a SM.

Fig. 5: Core HTN elements.

Fig. 6: Example of mission expressed as a HTN.

Fig. 7: Core BPMN elements.

Fig. 8: Example of mission expressed in BPMN.

Fig. 9: Research method.

ID	Profile	Years	Declared expertise
ID	Profile	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

TABLE I: Questionnaire participants overview (grey-highlighted rows indicate interviewed participants).

	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)

	$A1$ is executed before $A2$	$A1$ and $A2$ are executed in parallel	If $C$ is true, then $A1$ is performed; if $C$ is false, then $A2$ is performed	$A1$ is executed $n$ -times
SM	From initial to final state following triggered events	Fork pseudostate	Choice pseudostate	Transition cycles

	When $e1$ is triggered, state $S$ remains active until $e2$ is triggered	The fork pseudostate splits the incoming transition into two transitions, activating $S1$ and $S2$	If $g1$ is true, $S1$ is executed; otherwise if $g2$ is true, $S2$ is executed	$e1$ reactivates $S$ ’s action, while $e2$ terminates it

TABLE II: Control structures.

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

TABLE III: Abstraction levels in robotic systems (adapted from [ 49 ] ).

	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 ]

TABLE IV: Mission concepts.

Fig. 10: PPA pattern in BTs.

Panel of Figure 15 — Fig. 11: Likert responses for BTs (22 respondents).

Panel of Figure 16 — Fig. 12: Likert responses for SMs (27 respondents).

Panel of Figure 17 — Fig. 13: Likert responses for HTNs (10 respondents).

Panel of Figure 18 — Fig. 14: Likert responses for BPMN (14 respondents).

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					✓			✓		✓

TABLE V: Robotic scenarios and associated concerns. Acronyms used in the table: PB (Pick Ball), HR (Humanoid Robot), VS (Vital Signs Monitoring), KC (Keeping Clean), FL (Food Logistics), LSL (Lab Samples Logistics), WPH (Welcome People to Hospital), DG (Deliver Goods), SUAVE, SA (Smart Agriculture), WA (Warehouse Automation).

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.

TABLE VI: Summary of formalism expressivity for mission concerns. (●: full support; ◐: partial support; ○: no support)

Fig. 15: Example of reactive behavior realized through BT.

Fig. 16: Example of decision-making realized through HTN.

Fig. 17: Example of time-dependent behavior realized through BPMN.

Fig. 18: Example of task status handling with SM.

Fig. 19: Example of robot-robot interaction with BPMN.

Fig. 20: Example of robot-human interaction with BPMN.

Panel of Figure 27 — Fig. 21: Examples of explicit waiting realized through BT.

Strengths	Weaknesses
BT
$\bullet$ Easily express reactive behavior when the robot has to continuously react to changing conditions. $\bullet$ Clear task status semantics, making progress and failure handling a first-class concern.	$\bullet$ 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. $\bullet$ No standard way for expressing waitings, temporal constraints, and interactions, which must be manually implemented in the action/condition nodes. $\bullet$ 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
$\bullet$ Natively model event-driven behavior defining how the system should react to events and transition between states $\bullet$ Easily handles task status as distinct states and via transitions outgoing from them.	$\bullet$ 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. $\bullet$ Task resuming requires ad hoc history states and transitions towards each state. $\bullet$ Interactions, messaging, and coordination with other robots, systems, or humans have to be manually realized. $\bullet$ Time-dependent behaviors require the manual integration of timers within the state implementation.
HTN
$\bullet$ Provides support for decision making through runtime planning, achieved by decomposing tasks into sub-tasks using methods. $\bullet$ Natively allows explicit definition of pre- and post-conditions.	$\bullet$ No expressiveness for reactive behavior, which has to be realized at a different level outside of the mission model. $\bullet$ No explicit expression of static choices, which are always demanded to planning. $\bullet$ No task status tracking, which is totally demanded to the HTN executor implementation. $\bullet$ Interactions, waiting, and time-driven behaviors are not natively supported and must be manually implemented within task definitions.

TABLE VII: Overview of formalism expressivity strengths and weaknesses.

Panel of Figure 29 — Fig. 22: Likert responses for VQ2.1.

Panel of Figure 30 — Fig. 23: Likert responses for VQ2.2.

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 ]

TABLE VIII: Identified tools for BT (Grey-highlighted rows indicate baseline tools supporting the core formalism and used as foundations for ROS-based packages).

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 ]

TABLE IX: Identified tools for SM.

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 ]

TABLE X: Identified tools for HTN (Grey-highlighted rows indicate baseline tools supporting the core formalism and used as foundations for ROS-based packages).

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 ]

TABLE XI: Identified tools for BPMN (Grey-highlighted rows indicate baseline tools supporting the core formalism and used as foundations for ROS-based packages).

Panel of Figure 35 — Fig. 24: Tool mentions grouped by formalism ( $\ast$ -marked tools represent the ones suggested by respondents).

Panel of Figure 36 — Fig. 25: Likert responses for VQ3.2.

Figure 37

Figure 38

Figure 39

Behavior Trees

Behavior trees are hierarchical, reactive control structures for organizing tasks, actions, and recovery in robots and autonomous agents.

See all 19 papers

Task-Driven Co-Design of Heterogeneous Multi-Robot Systems
Apr 23, 2026Maximilian Stralz, Meshal Alharbi, Yujun Huang +1Multi-Robot Systems
Laboratory for Information & Decision Systems, Massachusetts Institute of Technology, Cambridge, MA 02139
Foundation Models in Robotics: A Comprehensive Review of Methods, Models, Datasets, Challenges and Future Research Directions
Apr 16, 2026Aggelos Psiris, Vasileios Argyriou, Evangelos K. Markakis +4Large Language Model-Based Robot Planning Robot Foundation Models
Department of Informatics and Telematics, Harokopio University of Athens, Athens, Greece · Department of Networks and Digital Media, Kingston University, London, United Kingdom · Department of Electrical and Computer Engineering, Hellenic Mediterranean University, Heraklion, Greece +4
Behavior Trees for Robotic Systems: An Empirical Study on Practices and Experiences
Sep 18, 2026Razan Ghzouli, Jennifer Horkoff, Daniel Strüber +1Behavior Trees Robotics
Department of Computer Science and Engineering, Chalmers University of Technology and University of Gothenburg, Gothenburg, Sweden · Department of Software Science, Radboud University, Nijmegen, The Netherlands · Software and Societal Systems Department, Carnegie Mellon University, Pittsburgh, PA, USA

Apr 23, 2026J/K move · Enter open · S save

Task-Driven Co-Design of Heterogeneous Multi-Robot Systems

Maximilian Stralz, Meshal Alharbi, Yujun Huang, Gioele Zardini

Laboratory for Information & Decision Systems, Massachusetts Institute of Technology, Cambridge, MA 02139

Multi-Robot Systems

Open paper AskPDF arXiv

Designing multi-agent robotic systems requires reasoning across tightly coupled decisions spanning heterogeneous domains, including robot design, fleet composition, and planning. Much effort has been devoted to isolated improvements in these domains, whereas system-level co-design considering trade-offs and task requirements remains underexplored. In this work, we present a formal and compositional framework for the task-driven co-design of heterogeneous multi-robot systems. Building on a monotone co-design theory, we introduce general abstractions of robots, fleets, planners, executors, and evaluators as interconnected design problems with well-defined interfaces that are agnostic to both implementations and tasks. This structure enables efficient joint optimization of robot design, fleet composition, and planning under task-specific performance constraints. A series of case studies demonstrates the capabilities of the framework. Various component models can be seamlessly incorporated, including new robot types, task profiles, and probabilistic sensing objectives, while non-obvious design alternatives are systematically uncovered with optimality guarantees. The results highlight the flexibility, scalability, and interpretability of the proposed approach, and illustrate how formal co-design enables principled reasoning about complex heterogeneous multi-robot systems.

Abstract

Behavior Trees

Explore similar work

Task-Driven Co-Design of Heterogeneous Multi-Robot Systems

Foundation Models in Robotics: A Comprehensive Review of Methods, Models, Datasets, Challenges and Future Research Directions

Behavior Trees for Robotic Systems: An Empirical Study on Practices and Experiences