Disciplined use of BPMN for mission modeling of Multi-Robot Systems Khalid Bourr1 , Flavio Corradini1 , Sara Pettinari1 , Barbara Re1 , Lorenzo Rossi1 and Francesco Tiezzi2 1 School of Science and Technology, University of Camerino, Italy 2 Dipartimento di Statistica, Informatica, Applicazioni “Giuseppe Parenti” (DISIA), University of Florence, Italy Abstract Nowadays, Multi-Robot Systems are an emerging research field under the umbrella of Cyber-Physical Systems. They consist of a group of robots that cooperate to accomplish a common mission. Examples of these systems are present in many application fields, e.g., agriculture, manufacture, industry, military, and health. As a consequence, there exist many frameworks facilitating the development of robotics systems. However, these tools require high skills for programming each robot’s behavior and coordinating the interactions among them, which overall should produce the cooperative behavior of the Multi-Robot System needed to carry out its mission successfully. To address this problem, we propose an approach for high-level modeling the cooperative behavior of Multi-Robot Systems through disciplined use of collaboration diagrams as they are provided by the BPMN 2.0 standard. The definition of our modeling proposal has been driven by ROS2, taken as the reference framework for programming robotics systems, and its DDS implementation for intra- and inter-robot communication. We illustrate the proposed approach through a Multi-Robot System in a smart agriculture scenario. Keywords Multi-Robot Systems, BPMN modeling, ROS2, DDS 1. Introduction In the Cyber-Physical Systems (CPS) domain, collaborative scenarios involving multiple robots are gaining more and more interest. The term Multi-Robot System (MRS) refers to a group of robots that work together to accomplish a common mission faster and cheaper than a single- robot system while providing scalability, reliability, flexibility and versatility [1]. In these kinds of systems, a single entity has few functionalities since the real power lies in the cooperation and the coordination of multiple robots. MRSs bring advantages in different application domains, e.g., agriculture, manufacture, industry, and health. This because they reduce the need of (possibly dangerous) human operations, e.g., the cleanup of toxic waste and rescue missions in disasters. Moreover, MRSs reduce human errors in repetitive tasks, and improves the productivity and the quality of services in human-centered applications [2]. To foster the development of MRSs, many robotic-centered frameworks provide tools by which developers can build robotics software without worrying about the underlying hardware. One of the most prominent development frameworks is Robot Operating System (ROS), which comes with ready-to-use libraries handling complex tasks. Despite the facilities provided PoEM’21 Forum: 14th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modelling, November 24-26, 2021 © 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Wor Pr ks hop oceedi ngs ht I tp: // ceur - SSN1613- ws .or 0073 g CEUR Workshop Proceedings (CEUR-WS.org) 1 by ROS, developing reliable MRSs is still a challenging task [3], which requires advanced programming skills to consider all at once the distributed computations made by each robot and the message exchanges needed to coordinate them. Overall, the behavior of single robots and their interactions should produce the cooperative behavior of the system that should lead to the successful accomplishment of the mission. To cope with this challenge, the literature presents several approaches belonging to Model-Driven Engineering (MDE) and Domain Specific Languages (DSL), that promise efficient and flexible methodologies for modeling and developing robotic systems [4, 5]. Nevertheless, these approaches either lack in providing a high-level abstraction of the the whole system behavior, or even discard at all scenarios involving multiple robots. To fill this gap, we propose a disciplined use of BPMN [6] for enabling the high-level modeling, and hence facilitating the development of the cooperative behavior of MRSs. The motivation behind using BPMN, and in particular the collaboration diagrams, comes from its wide usage in MDE approaches for CPS [7]. BPMN collaborations are highly expressive and encapsulate in a unique diagram the interplay among control-flow, data-flow and communication in a flexible and understandable way, making the modeling activity easier. The resulting models are easy to read by humans and, at the same time, suitable for model-to-code solutions. Furthermore, BPMN relies on several techniques from the BPM research community supporting the development of high-quality systems, such as formalization [8], execution and animation [9], and verification [10]. It is worth noticing that many of the works that foster the use of BPMN for modeling IoT and CPS (see [7] for a survey on this topic) propose extensions of the notation to capture domain specific features. Differently from these works, we rely only on the elements of collaboration diagrams defined in the specification document of the BPMN 2.0 standard. In fact, we show that it is possible to successfully model the behavior of a cooperative MRS, without extending the standard. This brings two main advantages: (i) model designers are not required to learn new concepts, and (ii) existing BPMN tools can be used without the need of any customization. The definition of our modeling proposal results from a balance of opposing forces. On the one hand, it is driven by the need of providing a notation at a high-level of abstraction, which facilitates the modeling of cooperative behaviors. For example, we identified off-the-shelf building blocks, reusable in different application scenarios (e.g., the take off action for drones), that can be used together with custom activities to form more complex behaviors. The resulting complexity can be mastered in a standard way via modularisation of the model and the use of BPMN call activities. On the other hand, differently from other similar proposals, we were also driven by practical aspects of the robotics system programming. In this regard, we have taken as reference framework ROS, due to its large adoption by the robotics community. In particular, we have considered the second version of ROS, as it natively supports MRSs via its implementation of the Data Distribution Service (DDS) standard used for intra- and inter-robot communication. This is reflected, for example, on the usage we propose of BPMN events and related event sub-processes for modeling, respectively, the DDS communication mechanism and the event handlers associated with DDS topics via subscription. Summing up, in this paper we present an original approach for modeling the cooperative behavior of MRSs through the use of the BPMN collaboration diagrams. Its novelty lies in the fact that we defined a disciplined use of the BPMN standard notation for dealing at once with: (i) scenarios with multiple robots, by means of collaboration diagrams; (ii) the topic- 2 DDS network Topic A Service A Topic B Topic D Topic C ROS nodes Arm Laser Motors Camera Controller Laser Weels Controller Arms Robot 1 Robot 2 Robot 3 Figure 1: Communication in ROS via DDS. based communication, by means of signal events and event sub-processes; and (iii) reuse of predefined/custom blocks by means of modularisation and use of call activities. These are distinctive features of MRSs programming that, to the best of our knowledge, are not considered altogether by any other modeling proposal. The rest of the paper is organized as follows. Section 2 provides notions concerning the technologies at the basis of our approach and presents a running example depicting a smart agriculture scenario. Section 3 proposes our disciplined use of BPMN for describing MRSs, and illustrates the approach at work on the running example. Section 4 compares our solution with respect to the related works. Finally, Section 5 concludes the paper and touches upon directions for future works. 2. Background This section introduces the background concepts about the development of MRSs by means of the ROS framework and its DDS implementation. Robot Operating System. ROS (www.ros.org) is one of the most famous and used open-source frameworks for programming robots. It provides an abstraction layer on top of which developers can build robotics applications. ROS is designed as a framework of distributed nodes, which are processes able to perform computations and designed to achieve single purposes, e.g., controlling motors or the ultrasonic sensor. Nodes are embedded in a network, they can communicate with each other by sending and receiving data via topics. Topics exploit a publish-subscribe pattern permitting to perform topic-based communication, where a message published over a topic can be read by any number of other nodes subscribed to that topic. The first version of ROS, i.e., ROS1, is suited for developing single-robot systems, while in recent years a second release, i.e., ROS2, has been proposed with the aim of overcoming ROS1 performance and scalability problems, thus achieving full support for MRSs. ROS2 provides real- time control and exploits a communication mechanism more suitable for inter-robot interactions. This motivates why in this paper we take ROS2 as reference release; from now on, for the sake of presentation, we will refer to ROS2 simply as ROS. The keystone enabling the development of MRSs in ROS is the OMG standard DDS (www. omg.org/spec/DDS). It enables real-time distributed systems to operate securely as an integrated whole. It introduces a global data space where applications can share information by simply reading and writing data objects. ROS takes advantage of DDS to enable several features. Among them, the one that mostly facilitates the development of MRS is the distributed discovery system that allows ROS nodes to communicate with each other without the use of a master. The communication among ROS nodes via DDS is illustrated in Figure 1. 3 Before deploying the ROS code into real robots, a good practice is exploiting simulation environments. The reference simulator for ROS is Gazebo (www.gazebosim.org). It permits to rapidly design and test robotics applications into a safe, yet realistic, environment. Running Scenario. To better reason on how to specify the behavior of a MRS, we present here a running example depicting a smart agriculture scenario. The cooperation between unmanned ground vehicles, e.g. smart tractors or harvesting robots, and unmanned aerial vehicles, usually called drones, is a promising solution to achieve a fully autonomous and optimized farming system. The proposed application scenario consists of two, or possibly more, tractors and one drone that cooperate to identify and remove weed grass in a farmland to enhance the yields. Both the drone and the tractors are equipped with a controller, enabling computations and communications, a battery, and several sensors and actuators. At the system start-up, the drone is the only robot that can start its behavior: it receives the field’s boundaries to inspect, and starts the exploration. During the overflight of the area, the drone uses the camera to recognize weed grass areas and, when found, it sends to the tractors the coordinates. This enacts the tractors, which store the weed grass coordinates and send back to the drone their distance to the weed grass area. The drone can hence elect the closest tractor and notify it. At this point, the selected tractor starts moving towards the field, avoiding possible obstacles. Once it reaches the weed grass area, it activates the blade to cut the weed, and stops its process until it receives a new position from the drone. 3. Disciplined Use of BPMN In this section, we present our approach for modeling the collective behavior of a MRS in ROS. We first introduce a subset of BPMN elements we selected for describing the robots’ mission. Then, we present a list of guidelines driving the use of the selected BPMN elements to compose a collaboration diagram that specifies actions and interactions of each robot in a MRS. Selection of BPMN elements for MRSs. Figure 2 shows the subset of BPMN elements adopted in our approach. The considered elements are the result of several discussions we did to select, on the huge list of more than 85 elements, those that best fit with the needs of MRSs. The debate was driven, in a top-down fashion, by the modeling activity we did on different application scenarios, and, in a bottom-up fashion, by the experiments we carried out with ROS implementations via the Gazebo simulator. Let us briefly introduce the BPMN elements resulting from our selection. A collaboration diagram consists of a collection of (possibly multi-instance) pools, which contain processes. In their own turn, a process consists of activities, gateways and events connected to each other by means of sequence flows, and data objects connected to activities and events by means of data associations. Activities represent one or more pieces of work to be performed within a process. Specifically, a Call Activity is a call to another process; this element enables the structuring of (possibly large and complex) models in terms of decoupled reusable processes. A Script Task refers to a piece of code to be executed. An Event Sub-Process is a sub-process that is not part of the normal flow of its parent process. Gateways are used to control the execution flow of a process, by managing parallel activities (AND gateway) and internal/external choices (XOR and Event-based gateways). Events represent something that can happen at the beginning, during, 4 Figure 2: Selected BPMN elements. or at the close of the process execution (Start, Intermediate, or End events, respectively). Start events are alternative entry points for enacting a process. When used in an event sub-process, they can interrupt or not the parent process. Intermediate events can happen during the normal flow of the process, by connecting them with sequence flows, or during an activity execution, by attaching them to the activity border. End events represent the possible termination of a process or a sub-process. All these events can be further characterized to describe their type and a different semantic meaning. Specifically, we consider Timer and Conditional events, to react respectively on a time delay or a condition; Error events, to throw or catch execution errors; Signal events, to describe broadcast and point-to-point communications that may carry data (see [6, p. 235]); and the Terminate events to kill all the processes in a pool. Finally, Data objects are information and material flowing in and out of activities and events. Notably, we do not consider message flows in our BPMN fragment; in fact, all communications are modeled by means of signals, which better reflect the topic-based communication mechanism based on DDS adopted by ROS for intra- and inter-robot interactions. Guidelines for MRSs modeling. We provide here a list of guidelines to be used during the modeling of a MRS through a BPMN collaboration. These guidelines define a disciplined use of the BPMN elements introduced before to represent MRS’s cooperative behavior while leaving the designer enough freedom to specify almost any MRS mission. Considering the running scenario of Section 2, the BPMN collaboration in Figure 3 is a possible result of our approach; we refer to it to better present the following guidelines. G1 Robots as pools. Robots involved in a MRS are abstracted by pools, representing the participants in the collaboration. G1.1 Heterogeneous robots as single-instance pools. Robots that are heterogeneous, i.e., robots of a different kind or robots with different missions, are abstracted by single-instance pools. Considering Figure 3, the drone is represented as a single-instance pool. G1.2 Homogeneous robots as multi-instance pools. Robots that are homogeneous, i.e., robots of the same kind with the same mission, are abstracted by multi-instance pools. This simplifies the resulting diagram, as a multi-instance pool represents many robots in terms of several instantiations of the same process, avoiding to repeat the same robot process into different pools. Considering Figure 3, the tractors are represented as a multi-instance pool. 5 Figure 3: Collaboration diagram of the smart agriculture scenario. G2 Mission as a process. The mission to be performed by a robot is abstracted by a process diagram within the pool of the considered robot. The process diagram expresses the control flow of the mission. For instance, the process contained into the drone pool in Figure 3 depicts the robot’s behavior from the take-off until the return to the base. Activities are related to each other via sequence flows, to define their execution order, and via gateways (see guidelines G2.3-2.5), to control the execution flow. G2.1 Actions as activities. A robot mission is mainly made by a set of actions; these actions are abstracted by activities within the mission process diagram. Based on the complexity of the action to specify, we distinguish the type of activity to use in the model between call activities and script tasks. G2.1.1 Complex actions as call activities. Complex actions, e.g., navigation, perception and control, that can be decomposed into several steps and/or reuse already modeled procedures, are abstracted by call activities. Indeed, a call activity can be used for referencing another process diagram or other existing activities. This enables the modularisation of diagrams and lowers their dimension, speeding up the modeling of the MRS through the re-use of already modeled behaviors. Considering Figure 3, the call activity Return to Base appears three times in the diagram, indicating that in all these cases the called procedure is implemented in the same way. G2.1.2 Simple actions as script tasks. Simple actions, which does not require any further decomposition, are abstracted by script tasks. This element refers to a piece of code to be executed by the considered robot. Considering Figure 3, to get the tractor closest to the weed, it is used the script task Update Closest that performs simple mathematical operations. G2.2 Event handlers as event sub-processes. Procedures handling an event (such as the expiration of a timer, the satisfaction of a condition, the occurrence of an error, or the reception of a signal) are abstracted by event sub-processes. Indeed, this element triggers an handling process concurrent to the main process describing the robot mission. Based on the event 6 type, the main process can be interrupted or not. For example, checking the battery after an amount of time, as depicted in Figure 3, can be performed in parallel with the mission, and thus it is abstracted by a non-interrupting start event. G2.3 Concurrent behaviors by means of AND gateways. Concurrent behaviors in a robot mission are rendered by means of AND split gateways. G2.4 Internal choices as XOR gateways. Internal choices in a robot mission are rendered by XOR split gateways. In Figure 3, the decision taken on the basis of the battery charge in the Battery check event sub-process is rendered as a XOR gateway, with two possible outcomes. G2.5 External choices as event-based gateways. Choices driven by events in a robot mission are abstracted by means of event-based gateways. Referring to Figure 3, a tractor waits for a closest_tractor signal at most for 30 seconds by means of an event-based gateway followed by two catching events. G2.6 Missions activation as start events. The beginning of a mission is abstracted by a start event. In more detail, a none start event fires immediately the robot mission. The other event types activate the mission when a specific circumstance occurs. Referring to Figure 3, the main process of the drone contains a none start event triggered at the system start-up, while the tractors are activated only when they receive the weed_position signal. G2.7 Missions shutdown as end events. The end of a mission is abstracted by an end event. The none end event stops only the current execution flow of a mission, while the terminate end event completely stops the mission. G3 Communication via signal events. Intra- and inter-robot communications, even in presence of a payload, are abstracted by signal events. The sending of a message corresponds to a throwing signal event, and the receiving of a message is made by a catching signal event. The correlation between one or more senders and one or more receivers is made by means of the event name. Considering Figure 3, the signal event weed_position corresponds to the same-named topic of which the drone is the only publisher, and the tractors are the subscribers. G4 Data as data objects. The data used along the execution of the robot’s mission are abstracted by data objects. They provide storage in which activities and signal events can read or write information. We explicitly represent in the model, in terms of data objects, only the information used to drive the decision making and the data exchange in the mission execution. Of course, at implementation level, other data will be required. However, since they are confined within low-level pieces of code and do not play any role at the abstraction level of the model, they are omitted. This permits reducing the complexity of the diagram. BPMN-driven ROS applications. To assess the suitability of our approach to support the development of MRSs, we used some BPMN collaboration models of MRS missions following the above guidelines to drive the implementation of the corresponding ROS applications. We consid- ered the agricultural scenario, modeled in Figure 3, as well as other scenarios concerning smart warehousing and surveillance. The full description of all the scenarios, the BPMN models and the ROS code, are made available online at https://bitbucket.org/proslabteam/multirobotsimulation. 7 4. Related Works A big amount of literature has been published on MDE and DSL supporting the development of robotics applications. Indeed, over the last years, researchers have attempted to define notations closer to the robotics domain in order to raise the level of abstraction and increasing the level of automation. This resulted in the proposal of many DSLs we discuss in the following. Targeting single-robot systems, Bubeck et al. [11] present BRIDE, a platform for component- based modeling of robotic systems. Components are modeled using UML and converted to ROS meta-models, in order to generate a runnable ROS C++ code. Likewise, Brugali et al. [12] propose the HyperFlex toolchain to model software control systems for ROS. HyperFlex differs from BRIDE for the providing of two model transformations for the generation of launch files. With a different approach, Hue et al. [13] propose a DSL based on AutomationML as modeling language with the aim of generating a runnable C++ code. Similarly, Bardaro et al. [14] use AADL as modeling language to abstract the architecture of ROS-based systems. A code generator is provided to transform models to C++ ROS code. Winiarski et al [15] propose EARL, a DSL based on SySML for designing ROS-based control system. The approach relies on a mathematical method of robot controller specification, using the concept of embodied agent. Moving on to the textual DSLs for ROS-based systems, Losvik and Rutle [16] and Sharovarskyi [17] proposed two works based on custom modeling languages. The former presents a model- driven approach for the development of MRSs made up of four components: a DSL, a task allocation module, a ROS module and a web interface. The latter proposes an approach using the modeling language Rebeca to check the safety of robots in an environment with obstacles. This work does not provide the code generator module, thus there is not a complete and automatized transition from the models to the robot code. Adam et al. [18] propose DeROS, a DSL targeting the security and safety of ROS-based systems. Another approach has been proposed by Bettini et al. [19] to leverage the powerfulness of the high-level programming language X-Klaim to deal with the distributed nature of robots’ software. Although these approaches are adequate to design CPSs, they do not consider inter-robot communication aspects, so there is not a language suitable to abstract the interactions between multiple robots. We present below the works that model the workflow of robots’ activities. Bozhinoski et al. [20] describe a tool for the mission specification for a team of multicopters and the generation of a detailed flight plan, by a custom DSL that is translated into an intermediate language which represents the basic actions of an aerial vehicle. Exploiting the same tool, Ciccozzi et al. [21] define a set of DSLs to specify the civilian missions for unmanned aerial vehicles. The mission specification is done through a web-based graphical interface, that communicates with some ROS-based controllers which send commands to the copters. A use of the BPMN notation is shown by De la Croix et. al [22], which describe the TRACE tool to tailor BPMN to the robotics domain in order to model a sequence of robotic activities. The aim of this approach is to understand what will happen after an unplanned event and check if it will compromise the mission. The authors applied their proposal to a single robot equipped with ROS, which can execute its tasks and autonomously act to unexpected events. Otsu et al. [23] present an application of the TRACE tool to a multi-robot scenario. The mission is specified in a BPMN file, uploaded inside all the vehicles, and each block of the model corresponds to a robot behavior. The system uses the ROS framework with an open-source package that allows a custom message 8 passing among multiple master nodes. This approach could be avoided and improved by using ROS2 with DDS. Another integration of BPMN standard with an autonomous robot is presented by Rey et al. [24]. The authors automatize a warehouse process by implementing a human-robot cooperation system managed by a web interface able to control the entire process in real-time. For what concerns the verification of MRSs, López et al. [25] provide an automatic method to verify the task-level control in autonomous robotic systems using Petri nets as input language for a model-checking tool. The Task Definition Language is used to define the workflow of a robot’s task and all the constraints that must be satisfied. Each global action is then translated into a Petri net and verified in order to check system fairness and efficiency. The approach is validated in a single vehicle scenario, equipped with ROS. Figat and Zielinski [26] present a methodology for the description of a multi-robot workflow and the related application to a ROS-based system. The model uses Hierarchical Petri Net to abstract the activities of a MRS. The C++ ROS code is generated after detecting deadlocks through simulating the execution. The analysis of the literature review shows that there is a huge gap in meeting the real-time condition, since all the works mentioned focus on the ROS1 framework that does not meet this requirement. Another drawback of using ROS1 is that the communication is managed by a single master. It creates a centralized system with a single point of failure, making it unsuitable for the development of MRSs applications. Indeed, most of the works do not consider MRSs in their approaches. All these shortcomings are taken into account in the design of our disciplined use of BPMN for MRSs. 5. Concluding Remarks This paper proposes an approach based on a disciplined use of the BPMN notation for developing MRSs, with a specific reference to their implementation in ROS2 and DDS. We defined a selection of BPMN elements suitable for the specification of MRS missions. The subset of elements we selected has been turned out to be expressive enough for conveniently representing smart agriculture, smart warehousing and smart surveillance scenarios. Moreover, we have defined a set of guidelines for driving the modeling of MRS scenarios. As future work, we plan to propose a model-driven framework for automatically generating ROS code from models specified via our approach. In addition, we aim at integrating our modeling approach with automated reasoning tools, in order to develop reliable MRSs. References [1] T. Arai, E. Pagello, L. E. Parker, Guest editorial advances in multirobot systems, IEEE Transactions on Robotics and Automation 18 (2002) 655–661. [2] C. W. de Silva, Some issues and applications of multi-robot cooperation, in: Computer Supported Cooperative Work in Design, IEEE, 2016, pp. 2–2. [3] C. Crick, G. Jay, S. Osentoski, B. Pitzer, O. C. Jenkins, Rosbridge: ROS for Non-ROS Users, volume 100 of STAR, Springer, 2017, pp. 493–504. [4] A. Nordmann, N. Hochgeschwender, S. Wrede, A survey on domain-specific languages in robotics, in: SIMPAR, LNCS 8810, Springer, 2014, pp. 195–206. 9 [5] E. de Araújo Silva, E. Valentin, J. R. H. Carvalho, R. da Silva Barreto, A survey of Model Driven Engineering in robotics, Computer Languages 62 (2021) 101021. [6] OMG, Business Process Model and Notation (BPMN) v. 2.0, 2011. [7] Compagnucci et al., Modelling notations for IoT-aware business processes: A systematic literature review, in: BP-Meet-IoT, LNCS 397, Springer, 2020, pp. 108–121. [8] F. Corradini, C. Muzi, B. Re, L. Rossi, F. Tiezzi, Formalising and animating multiple instances in BPMN collaborations, Information Systems 101459 (2019). [9] F. Corradini, C. Muzi, B. Re, F. Tiezzi, L. Rossi, MIDA: multiple instances and data animator, in: BPM Demos, volume 2196, CEUR-WS.org, 2018, pp. 86–90. [10] Corradini et al., A formal approach to modeling and verification of business process collaborations, SCP 166 (2018) 35–70. [11] Bubeck et al., BRIDE - A toolchain for framework-independent development of industrial service robot applications, in: ISR, VDE, 2014, pp. 137–142. [12] D. Brugali, L. Gherardi, Hyperflex: A model driven toolchain for designing and configuring software control systems for autonomous robots, in: ROS, Springer, 2016, pp. 509–534. [13] Y. Hua, S. Zander, M. Bordignon, B. Hein, From AutomationML to ROS: A model-driven approach for software engineering of industrial robotics using ontological reasoning, in: ETFA, IEEE, 2016, pp. 1–8. [14] Bardaro et al., From Models to Software Through Automatic Transformations: An AADL to ROS End-to-End Toolchain, in: Robotic Comp., IEEE, 2019, pp. 580–585. [15] Winiarski et al., EARLl—embodied agent-based robot control systems modelling language, Electronics 9 (2020) 379. [16] D. S. Losvik, A. Rutle, A domain-specific language for the development of heterogeneous multi-robot systems, in: MODELS-C, IEEE, 2019, pp. 549–558. [17] K. Sharovarskyi, Software for safe mobile robots with ROS 2 and REBECA, Master’s thesis, Mälardalen University, 2020. [18] Sorin et al., Towards rule-based dynamic safety monitoring for mobile robots, in: SIMPAR, LNCS 8810, Springer, 2014, pp. 207–218. [19] L. Bettini, K. Bourr, R. Pugliese, F. Tiezzi, Writing Robotics Applications with X-Klaim, in: ISoLA, volume 12477 of LNCS, Springer, 2020, pp. 361–379. [20] Bozhinoski et al., FLYAQ: Enabling non-expert users to specify and generate missions of autonomous multicopters, in: ASE, 2015, pp. 801–806. [21] Ciccozzi et al., Adopting mde for specifying and executing civilian missions of mobile multi-robot systems, IEEE Access 4 (2016) 6451–6466. [22] J.-P. de la Croix, G. Lim, Event-driven modeling and execution of robotic activities and contingencies in the Europa lander mission concept using BPMN, in: i-SAIRAS, ESA, 2020. [23] Otsu et al., Supervised Autonomy for Communication-degraded Subterranean Exploration by a Robot Team, in: AeroConf, IEEE, 2020, pp. 1–9. [24] R. Rey, M. Corzetto, J. A. Cobano, L. Merino, F. Caballero, Human-robot co-working system for warehouse automation, in: ETFA, IEEE, 2019, pp. 578–585. [25] J. López, P. Sánchez-Vilariño, R. Sanz, E. Paz, Implementing autonomous driving behaviors using a message driven petri-net framework, Sensors 20 (2020) 449. [26] M. Figat, C. Zielinski, Robotic system specification methodology based on hierarchical petri nets, IEEE Access 8 (2020) 71617–71627. 10