1. Introduction

2. Materials and Methods

2.2. RTMN 2.0 – Extension of RTMN

In this section we will explain the RTMN 2.0 in detail.

2.2.1. The RTMN Elements

RTMN originally contained eleven basic notations that are differentiated by shapes, colors, and icons [2]. These notations are developed based on the well-known business process modeling notation (BPMN) [45]. The goal is to develop a modelling language that covers the robotics domain with familiar notations, rather than completely new ones. These notations adopt color, icon, and shapes in their design, aiming to make the modelling more intuitive. Four BPMN standard notations - “sequence flow”, “event” (start, end) and “gate way” (exclusive) are reused in RTMN (see BPMN specification [45]).

There are five new robotics specific notations: robot task, robot skill, robot primitive, HRC (human robot collaboration) task, and one slightly changed notation - human task, similar to a user task in BPMN, however, here it has a human icon and a color assigned to it. A “task” in BPMN is at the lowest level of the process and it cannot be broken down into finer details. It is considered an atomic activity within a process [46]. However, the term “task” in the robotics area is rather a subprocess in relation to BPMN. With the different usage, a picking task for example - it is not an atomic activity, it consists of detailed steps such as to move to the right place, locate the gripper and grasp etc. Therefore, we differentiate a robot task from a typical BPMN task. We define it as an activity consisting of a set of activities which corresponds to a special type of BPMN sub-process that deals with robot activities. The activities within the robot task are defined as skills and primitives. Primitives are atomic activities that compose robotic skills, and skills form robot tasks.

2.2.2. The RTMN 2.0 Elements

RTMN 2.0 in comparison to the first version of RTMN has the following extensions:

• Adding HRC modeling elements, including safety in combination with collaboration modes and task types of humans and robots. This has significantly enriched the former RTMN model and enabled it to be applied to HRC application areas.

• Adding requirements, KPI as basic elements

• Adding the link from requirements/KPI to robot control

• Adding decision making elements

RTMN 2.0 is designed especially for modeling human robot collaboration processes. Together with version 1.0 it is capable of modeling light-out automated robotic processes as well as human robot collaboration robotic processes. The model contains two sets of elements: the RTMN elements and the extended elements. The complete overview is presented in Figure 1, Figure 2 and Figure 3. It consists of all the elements of RTMN 2.0 with the newest improvements and extensions.

2.2.3. The RTMN 2.0 Sequence Flow Connection Rules

Figure 4 displays the rules regarding how to connect the elements in a sequence flow. The basic rules are: Start can only start a process, and cannot have any element flow into it; End is the opposite, it ends the process and cannot have any elements flow out of it; Sequence Flow connects the other elements and points out the direction of the process flow; Requirements are normally defined on the process level, but it can also be assigned to tasks, skills and primitives if needed; KPIs are usually used to measure achievement of requirements for the process, but can also be assigned to tasks, skills and primitives if needed; Tasks can be connected to any other task, condition, decision or sequence flow; Skills and primitives can be connected to skills and primitives as well as conditions, decisions and sequence flows.

2.2.4. The HRC Model

We have developed an HRC model that covers the following aspects of HRC: HRC task types, HRC modes, HRC tasks, workspace and decision making. We address every aspect one by one in the next section.

2.2.4.1. Combining Collaboration Task Types and HRC Modes

Based on the literature [10,11,12,13,14,15,16,17,18,19,20,21,22] we consolidated the different classifications of the HRC task types and HRC modes. In literature, five HRC modes (fence, SMS, HG, SSM, PFL) and five HRC task types (cell, coexistence, synchronized, cooperation and collaboration) are commonly defined. The HRC modes can ensure the safety of people even when unexpected human intrusions occur. However, the HRC task types do not by definition ensure the safety of people. This classification focuses on how closely humans and robots work together and only the people planned for the task are considered. In reality, no matter how we define the task type, humans can act differently than expected, and human intrusions can occur. Therefore, to ensure safety each task type must have a minimum safety mode enabled. For this reason, we present a new classification that integrates the HRC task types, HRC modes, and safety levels. Safety level 0 indicates no risk for the human from the robot. It has the lowest safety requirements, as the robot is in a physical fence. Safety levels go up to level 4, which requires the highest safety requirements not only from hardware, but also from software. We also distinguish the collaboration levels (0-5): the higher, the more collaboration between human and robot.

For each task we have defined general safety requirements. Solution design on the hardware and software level are proposed for each HRC task type. This makes it easier for process engineers to ensure safety when implementing HRC processes. The overall approach is presented in Figure 5.

In our new classification we have five categories: Coexistence Fence (CF), Sequential Cooperation SMS (SS), Teaching HG (TH), Parallel Cooperation SSM (PS), and Collaboration PFL (CP). The human robot task type “cell” refers to robot working autonomously surrounded by physical fences without human involvement, so we only need to model the robot tasks and no human tasks need to be modeled. In this case we do not need to create a separate HR task type for it as it has only robot tasks. We have added a new task type “Teaching”, this is when a human takes control of the robot and demonstrates what the robot should do, then the robot learns and repeats it. The reason for adding it is to cover this missing collaboration task type and then to be able to map it to the collaboration mode HG.

• Coexistance Fence (CF)

This type (Figure 6) combines the task type “Coexistence” and collaboration mode “Fence”. This task has the lowest HRC level 0 and should activate at least safety level 0 (Fence) in the background. We recommend using an industrial robot, since the human and robot do not work together in the same workplace. The fence for the robot can be in the form of physical barriers or certified hardware like a light curtain/2D scanner. As long as Fence mode is insured, this task is safe. No additional software functionalities are needed.

• Sequential Cooperation SMS (SS)

This type (Figure 7) combines the task type “Synchronized” and collaboration mode “Safety-rated monitored stop”. “Safety-rated monitored stop” means “condition where the robot is stopped with drive power active, while a monitoring system with a specified sufficient safety performance ensures that the robot does not move” as described in [47].

This task has collaboration level 1 and should activate at least safety level 1 (SMS) in the background. We recommend using either an industrial robot or a collaborative robot with safety certified hardware like light curtain/2D scanner to ensure SMS (robot stops when human enters the robot working area). As long as SMS mode is insured, this task is safe. No additional software functionalities are needed.

• Teaching HG (TH)

This type (Figure 8) combines the task type “Teaching” and collaboration mode “Hand Guiding”. This task has collaboration level 2 and should activate at least safety level 2 (HG) in the background. We recommend using a collaborative robot with safety certified hardware that allows the robot state to switch to safety-rated monitored speed functionality to allow direct movement of robot. e.g., hand guiding device. If a minimum safety HG mode is insured, this task is safe. Safety-rated monitored speed functionalities need to be programmed at the software level. In ISO 10218-1 safety-rated monitored speed is written as “safety-rated function that causes a protective stop when either the Cartesian speed of a point relative to the robot flange (e.g. the TCP), or the speed of one or more axes exceeds a specified limit value” [47].

• Parallel Cooperation SSM (PS)

This type (Figure 9) combines the task type “Parallel Cooperation” and collaboration mode “Speed and Separation Monitoring”. This task has collaboration level 3 and should activate at least safety level 3 (SSM) in the background and put in place the hardware that insures the SSM mode. We recommend using a collaborative robot with safety certified hardware that has zone/position control capabilities, e.g., 2D scanner, pressure pads/floors, 3D safety vision scanner. Speed/position control functionalities need to be programmed at the software level. The work area should be divided into three zones: green zone (robot runs at full speed), yellow zone (robot runs at reduced speed), red zone (robot stops). As long as SSM mode is insured, this task is safe.

• Collaboration PFL (CP)

This type (Figure 10) combines the task type “Collaboration” and collaboration mode “Power and Force Limiting”. This task has collaboration level 4 and should activate the safety level 4 (Power and Force Limiting) at the background. This type is the most collaborative task type, requires the highest safety controls and demands the most software engineering effort. We recommend using a collaborative robot with safety certified hardware that can control the limitation of motor power and force, e.g., a 3D safety vision scanner or a vision system. For force control and limitation force-torque sensors in end-effectors and/or in the joints of the robot are required. At the software level, functionalities need to be developed for collision handling, distance monitoring, force control, velocity tracking, and power of robot limitation. For example, a simple calculation for the maximum separation distance can be defined by multiplying the Trs (time for robot to stop) and Sr (robot speed). Therefore, Drh (Distance between robot and human), Max Drh = Trs * Sr. As long as PFL mode is insured, this task is safe. In the property of this notation, one must assign an HRC mode and task type to it.

2.2.4.2. Workspace

To align the modeling with the realistic robotic cell, we introduced the workspace notation. This notation is similar to the BPMN pool/lane (see Figure 11). In BPMN, pools represent companies, departments, or roles. Lanes represent sub-entities within these organizations and appear as swim lanes inside the pool [3]. In robotic processes, there are usually only limited humans involved in the process. In the robotic cell the focus is not the different entities like roles or departments, but the different areas in the cell. Therefore, we propose to use pools/lanes as workspaces for separating the different areas in the robotic cell.

One can use workspace when tasks in the process are carried out in multiple workspaces. When tasks switch from one workspace to another, there will be a pop-up window or voice reminder of a workspace change. A workspace can have input and output, precondition and postcondition assigned to it. With these properties one can set up specific requirements for the workspace. Figure 12 shows an example of using the workspace notation.

2.2.4.3. Decision Making

We model decision making with two different notations. We call one “Condition” (See Figure 13) which is rule-based decision making and the other “Decision” (See Figure 14) which refers to human decision making.

Rule-based decision making is enabled by a rule table where users can specify their decision logic. Table 2 shows how the rule table looks, with some examples to demonstrate the usage of it.

The rule table checks whether the conditions are met. Depending on whether the conditions are met or not, a corresponding action will be followed. Often there is only one parameter that is being checked, for example “quality check”. But there are also cases where multiple parameters are checked. In this case we need to define the sequence of the condition check. We use a sequence column to indicate that the parameters are checked sequentially one by one. When the rule table is defined, this sequential execution must be followed.

Human decision making allows operators/users to specify a question that will be answered at run time. At this step, a question will pop up and ask the operator/user to give an input (commonly a yes or no answer). Based on what the operator chooses (yes or no) a different branch of the process flow will be executed. Figure 15 gives an example of using the decision notation.

2.2.5. Other Extensions and Modifications

In RTMN 2.0 there are other extensions. We also made some modifications to the notations in RTMN first version.

2.2.5.1. Requirements and KPI

Key Performance Indicators (KPIs) form a specialized set of metrics steering management activities towards improving company performance, representing quantitative measures of critical success factors (CSFs) in enterprises [48]. They serve as variables reflecting progress toward goals while aligning with the company's vision and strategies [48]. Displaying KPIs is essential for supervisors and employees to seek improvements and reaching for higher performance [48]. In an HRC environment, safety and ergonomics are widely acknowledged as crucial pillars, while in a business context, Productivity, encompassing both Effectiveness and Efficiency, and Economics must be considered [48].

Therefore, after analysing numerous research papers Caiazzo et al. divided the various KPIs related to HRC to the following four areas: ‘Productivity’, ‘Economics’, ‘Safety’, and ‘Ergonomics’ [48]. We adopt their systematic approach and categorise the requirements and KPIs into these four categories.

The requirement notation (see Figure 16) and KPI notation (see Figure 17) are added to RTMN 2.0 to visualize the business requirements and KPIs on the process level. We can also assign requirements and KPIs at the task level if needed.

The requirement notation (see Figure 16) represents business requirements of a robotic process/task. It has the following properties: name, formula, KPI, input, output, precondition, and postcondition. One can set constraints using preconditions and postconditions. For example, one can add a postcondition - the sum of net machine utilization and net operator actuation is 100%. The KPI notation defines the key performance indicators linked to the requirements (see Figure 17). Table 3 illustrates the general KPIs for the HRC robotic processes, among which a few are related to human: Accident Rate, Net Operator Actuation, Human Exposure to Chemical.

2.2.5.2. Traceability of Requirements and KPIs

The inputs for calculating the KPIs come from ROS - the robot control level. From primitives and skills, we can get the input values and use them for calculating the KPIs and validate the requirements. Through this, the traceability of requirements and KPIs are achieved.

To be more specific, KPIs are calculated automatically based on the values created in the different layers of the robot system. For example, for a pick skill, whether the pick is successful or not is tracked. The success rate of picking is calculated by the number of success picks / total pick attempts. Another example – the robotic task Scrap Product – quality inspection of the number of accepted products and not accepted products is tracked. If the product is within the error tolerance, it will be accepted and vice versa. The system can add up the number of accepted products and the number of not accepted products, and then Product quality is calculated by dividing the number of products not accepted by the number of total products.

2.2.5.3. Robotic Process

A robotic process involves robots in the process. We have added this notation (see Figure 18) because we want to visually show the relationship between business requirement and the overall process. A process can contain human tasks, robot tasks and HRC tasks.

The robotic process has data properties: name, owner, and organization. Requirement/Objective and KPIs are no longer just properties of the process. They have their own notations as described earlier.

Figure 19 provides an example of modelling KPIs and requirements for a process. The dashed arrows indicate data association.

2.2.5.4. Skill and Primitive

We modified the icons of the skill and primitive notation in order to easily distinguish the robot task and robot skill visually, whilst bringing skill and primitive closer. Now both skill and primitive have a robot body icon (See Figure 20 and 21). Robot task has a robot arm icon.

2.2.6. The Implementation

As described in the former RTMN paper [2], the modelling language RTMN is used in the graphical user interface (GUI) of the ACROBA platform. The notations from RTMN 2.0 are defined as drag and drop elements in the GUI. The GUI is developed on the Flutter framework [49]. Flutter uses Dart as its programming language. The special package Dartros [50] enables Flutter to communicate with ROS [51] by implementing the ROS client library. The overall architecture is shown in Figure 22 (taken from the former paper).

The GUI using RTMN 2.0 serves as a modelling tool. The users can create a process model in the GUI. The process sequence is then sent from the GUI to the task planner through Datros. The task planner takes the sequence and “translates” it to a behaviour tree which is connected to ROS. Task planner also provides feedback and status of the tasks to the GUI. The population of the available modelling elements such as skills and primitives are managed through an ontology where the domain knowledge such as tasks, skills and primitives are defined. The characteristics of ontology ease the sharing of knowledge, provide clear structure of data, and enable accurate reasoning of data[52]. Therefore, we also adopt the benefits of ontology for knowledge-sharing among heterogeneous systems and human-machine interaction.

Figure 1. RTMN 2.0 Framework [2]

Figure 1. RTMN 2.0 Framework [2]

Demonstration

Figure 22 shows the design of the Graphical User Interface (GUI) for RTMN 2.0. The left side is divided into different abstraction levels: processes, tasks, skills and primitives. At the bottom left conner, the connecting notations are shown. One can simply drag and drop the notations on the left to model an HRC process.

Figure 23. HRC Process Example - PCB Assembly.

Figure 23. HRC Process Example - PCB Assembly.

We illustrated one example of an HRC process. This example is a modification of a use case process due to confidentiality. A Printed Circuit Board (PCB) assembly process is a process to assemble a PCB. The assembly works by putting different kinds of Pin through Hole (PTH) components on the PCB. This process consists of three tasks: Move PTH to Pick Station, Assemble PCB, Inspect PCB. Move PTH to Pick Station and Assemble PCB are two HRC tasks, while Inspect PCB is a robot task.

For the HRC task Move PTH to Pick Station, safety mode SMS should be ensured because it is a sequential HRC task with human and robot working one after another. It has a human task, Fill Up Bin, followed by a robot skill Move to Bin, then a primitive, Grasp PTH, robot skill Move to Pick Station, and primitive, Release PTH.

For the HRC task Assemble PCB, safety mode SSM should be ensured as human and robot work in parallel in this task. They work side by side on the same PCB, but not at the same time. When a PTH is wrongly positioned, the human needs to correct it. As the human approaches the robot and enters the “red” zone, the robot stops. This task consists of a simple robot skill – match PCB (this skill scans PCB, then, based on the scanned image loads the CAD model of the PCB) and two parallel tasks (combination of skills)- Correct Position Error by human and Pick&Place by robot. The join/split notation is used here to split the sequence to two, then merge the two back to one again.

The robot task Inspect PCB does not involve any human. It is purely done by a robot. In this task a condition notation is used to decide where the PCB goes after inspection. If it is accepted, it is moved to the next station. If it is rejected, the PCB is scrapped.

3. Results

4. Discussion

5. Conclusions

References

1. Project - Acroba Project. Available online: https://acrobaproject.eu/project-acroba/ (accessed on 28 February 2022).
2. Sprenger, C.Z.; Ribeaud, T. Robotic Process Automation with Ontology-Enabled Skill-Based Robot Task Model and Notation (RTMN). 2022 2nd International Conference on Robotics, Automation and Artificial Intelligence (RAAI) 2022, 15–20. [CrossRef]
3. BPMN Specification - Business Process Model and Notation. Available online: https://www.bpmn.org/ (accessed on 27 February 2022).
4. Li, Y.; Ge, S.S. Human-Robot Collaboration Based on Motion Intention Estimation. IEEE/ASME Transactions on Mechatronics 2014, 19, 1007–1014. [Google Scholar] [CrossRef]
5. Weiss, A.; Wortmeier, A.K.; Kubicek, B. Cobots in Industry 4.0: A Roadmap for Future Practice Studies on Human-Robot Collaboration. IEEE Trans Hum Mach Syst 2021, 51, 335–345. [Google Scholar] [CrossRef]
6. SIGCHI (Group : U.S.); SIGART; IEEE Robotics and Automation Society; Institute of Electrical and Electronics Engineers. HRI’16 : The Eleventh ACM/IEEE International Conference on Human Robot Interation : March 7-10, 2016, Christchurch, NZ, ISBN 9781467383707.
7. Institute of Electrical and Electronics Engineers.; Institute of Electrical and Electronics Engineers. Region 3. IEEE SoutheastCon 2015 : April 9-12, Fort Lauderdale, Florida, Hilton Fort Lauderdale Marina. ISBN 9781467373005.
8. Freedy, A.; DeVisser Gershon Weltman, E. Measurement of Trust in Human-Robot Collaboration; [CrossRef]
9. IEEE Staff; IEEE Staff 2010 IEEE/RSJ International Conference on Intelligent Robots and Systems. ISBN 9781424466764.
10. Kumar, S.; Savur, C.; Sahin, F. Survey of Human-Robot Collaboration in Industrial Settings: Awareness, Intelligence, and Compliance. IEEE Trans Syst Man Cybern Syst 2021, 51, 280–297. [Google Scholar] [CrossRef]
11. 2011 IEEE International Symposium on Assembly and Manufacturing.; IEEE, 2011. ISBN 9781612843438.
12. Matheson, E.; Minto, R.; Zampieri, E.G.G.; Faccio, M.; Rosati, G. Human–Robot Collaboration in Manufacturing Applications: A Review. Robotics 2019, 8, 100. [Google Scholar] [CrossRef]
13. Villani, V.; Pini, F.; Leali, F.; Secchi, C. Survey on Human-Robot Collaboration in Industrial Settings: Safety, Intuitive Interfaces and Applications. [CrossRef]
14. Kim, A. A Shortage of Skilled Workers Threatens Manufacturing’s Rebound.
15. Vysocky, A.; Novak, P. Human - Robot Collaboration in Industry. MM Science Journal 2016, 2016-June, 903–906. [Google Scholar] [CrossRef]
16. International Federation of Robotics. Available online: https://ifr.org/ (accessed on 18 July 2023).
17. Müller, R.; Vette, M.; Geenen, A. Skill-Based Dynamic Task Allocation in Human-Robot-Cooperation with the Example of Welding Application. Procedia Manuf 2017, 11, 13–21. [Google Scholar] [CrossRef]
18. Wang, L.; Gao, R.; Váncza, J.; Krüger, J.; Wang, X. V; Makris, S.; Chryssolouris, G. Symbiotic Human-Robot Collaborative Assembly. 2019. [Google Scholar] [CrossRef]
19. Maschinenbau, F.; Thiemermann Aus Gernlinden, Dipl.-I.S. Direkte Mensch-Roboter-Kooperation in Der Kleinteilemontage Mit Einem SCARA-Roboter. 2004.
20. Müller, R.; Vette, M.; Mailahn, O. Process-Oriented Task Assignment for Assembly Processes with Human-Robot Interaction. Procedia CIRP 2016, 44, 210–215. [Google Scholar] [CrossRef]
21. Vincent Wang, X.; Kemény, Z.; Váncza, J.; Wang, L. Human-Robot Collaborative Assembly in Cyber-Physical Production: Classification Framework and Implementation. 2017. [Google Scholar] [CrossRef]
22. Krü, J.; Lien, T.K.; Verl, A. Cooperation of Human and Machines in Assembly Lines. [CrossRef]
23. White, S.A. Introduction to BPMN; 2004.
24. 2018 IEEE 16th International Conference on Industrial Informatics (INDIN).; IEEE, 2018. ISBN 9781538648292.
25. Pantano, M.; Pavlovskyi, Y.; Schulenburg, E.; Traganos, K.; Ahmadi, S.; Regulin, D.; Lee, D.; Saenz, J. Novel Approach Using Risk Analysis Component to Continuously Update Collaborative Robotics Applications in the Smart, Connected Factory Model. Applied Sciences (Switzerland) 2022, 12. [Google Scholar] [CrossRef]
26. Universidad de Zaragoza; Institute of Electrical and Electronics Engineers; IEEE Industrial Electronics Society; Universidad de Zaragoza. Aragón Institute for Engineering Research Proceedings, 2019 24th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA) : Paraninfo Building, University of Zaragoza, Zaragoza, Spain, 10-13 September, 2019. ISBN 9781728103037.
27. Schmidbauer, C.; Schlund, S.; Ionescu, T.B.; Hader, B. Adaptive Task Sharing in Human-Robot Interaction in Assembly. In Proceedings of the IEEE International Conference on Industrial Engineering and Engineering Management; IEEE Computer Society, December 14 2020; Vol. 2020-December. pp. 546–550.
28. Guiochet, J. Hazard Analysis of Human-Robot Interactions with HAZOP-UML. Saf Sci 2016, 84, 225–237. [Google Scholar] [CrossRef]
29. Martin-Guillerez, D.; Guiochet, J.; Powell, D.; Zanon, C. A UML-Based Method for Risk Analysis of Human-Robot Interactions. In Proceedings of the Proceedings of the 2nd International Workshop on Software Engineering for Resilient Systems; Association for Computing Machinery: New York, NY, USA, 2010; pp. 32–41. [Google Scholar]
30. Guiochet, J.; Motet, G.; Baron, C.; Boy, G. TOWARD A HUMAN-CENTERED UML FOR RISK ANALYSIS Application to a Medical Robot. [CrossRef]
31. Annual IEEE Computer Conference; IEEE International Conference on Rehabilitation Robotics 13 2013.06.24-26 Seattle, Wash.; ICORR 13 2013.06.24-26 Seattle, Wash. 2013 IEEE International Conference on Rehabilitation Robotics (ICORR) 24-26 June 2013, Seattle, Washington, USA. ISBN 9781467360241.
32. Von Borstel, F.D.; Villa-Medina, J.F.; Gutiérrez, J. Development of Mobile Robots Based on Wireless Robotic Components Using UML and Hierarchical Colored Petri Nets. Journal of Intelligent and Robotic Systems: Theory and Applications 2022, 104. [Google Scholar] [CrossRef]
33. Carroll, L.; Tondu, B.; Baron, C.; Geffroy, J.C. UML Framework for the Design of Real-Time Robot Controllers. [CrossRef]
34. Verband der Elektrotechnik, E.; Institute of Electrical and Electronics Engineers. German Conference on Robotics (8th : 2014 : Munich, G. ISR/Robotik 2014 ; 41st International Symposium on Robotics ; Proceedings of : Date 2-3 June 2014. ISBN 9783800736010.
35. Ohara, K.; Takubo, T.; Mae, Y.; Arai, T. SysML-Based Robot System Design for Manipulation Tasks.
36. Candell, R.; Kashef, M.; Liu, Y.; Foufou, S. A SysML Representation of the Wireless Factory Work Cell: Enabling Real-Time Observation and Control by Modeling Significant Architecture, Components, and Information Flows. International Journal of Advanced Manufacturing Technology 2019, 104, 119–140. [Google Scholar] [CrossRef] [PubMed]
37. Avram, O.; Baraldo, S.; Valente, A. Generalized Behavior Framework for Mobile Robots Teaming With Humans in Harsh Environments. Front Robot AI 2022, 9. [Google Scholar] [CrossRef] [PubMed]
38. Peterson, J.L. Petri Nets*; 1977.
39. Casalino, A.; Zanchettin, A.M.; Piroddi, L.; Rocco, P. Optimal Scheduling of Human-Robot Collaborative Assembly Operations With Time Petri Nets. IEEE Transactions on Automation Science and Engineering 2019. [Google Scholar] [CrossRef]
40. Chao, C.; Thomaz, A. Timed Petri Nets for Fluent Turn-Taking over Multimodal Interaction Resources in Human-Robot Collaboration. Int J Rob Res 2016, 35, 1330–1353. [Google Scholar] [CrossRef]
41. Chao, C.; Thomaz, A. Timing in Multimodal Turn-Taking Interactions: Control and Analysis Using Timed Petri Nets. J Hum Robot Interact 2012, 4–25. [Google Scholar] [CrossRef]
42. Institute of Electrical and Electronics Engineers. Robotics and Automation (ICRA), 2014 IEEE International Conference on : May 31 2014-June 7 2014 : [Hong Kong, China]. ISBN 9781479936854.
43. Yagoda, R.E.; Coovert, M.D. How to Work and Play with Robots: An Approach to Modeling Human-Robot Interaction. Comput Human Behav 2012, 28, 60–68. [Google Scholar] [CrossRef]
44. Casalino, A.; Cividini, F.; Zanchettin, A.M.; Piroddi, L.; Rocco, P. Human-Robot Collaborative Assembly: A Use-Case Application.; Elsevier B.V., January 1 2018; Vol. 51, pp. 194–199.
45. Völzer, H. An Overview of BPMN 2.0 and Its Potential Use. Lecture Notes in Business Information Processing 2010, 67 LNBIP, 14–15. [Google Scholar] [CrossRef]
46. Business Process Model and Notation (BPMN), Version 2.0. 2010.
47. ISO - International Organization for Standardization. Available online: https://www.iso.org/obp/ui/en/#iso:std:iso:10218:-1:ed-2:v1:en (accessed on 7 November 2023).
48. Caiazzo, C.; Nestić, S.; Savković, M. A Systematic Classification of Key Performance Indicators in Human-Robot Collaboration. Lecture Notes in Networks and Systems 2023, 562 LNNS, 479–489. [Google Scholar] [CrossRef]
49. Flutter. Available online: https://flutter.dev/ (accessed on 15 August 2022).
50. Dartros | Dart Package. Available online: https://pub.dev/packages/dartros (accessed on 15 August 2022).
51. ROS: Home. Available online: https://www.ros.org/ (accessed on 28 February 2022).
52. Pang, W.; Gu, W.; Li, H. Ontology-Based Task Planning for Autonomous Unmanned System: Framework and Principle. In Proceedings of the Journal of Physics: Conference Series; IOP Publishing Ltd, April 19 2022; Vol. 2253.
53. Davis, F.D.; Venkatesh, V. Toward Preprototype User Acceptance Testing of New Information Systems: Implications for Software Project Management. IEEE Trans Eng Manag 2004, 51. [Google Scholar] [CrossRef]