# Enabling End-Users in Designing and Executing of Complex, Collaborative Robotic Processes
## 3 Use Cases
### Message-Flow Paths  
Later both industrial use cases were also tested successfully by usage of the simulation system twin ([[https://www.digifai.com/twin](https://www.digifai.com/twin)]([https://www.digifai.com/twin](https://www.digifai.com/twin)), accessed on 8 May 2023) which was provided by our project partner Eberle Automatische Systeme GmbH & Co KG. twin is a physic based tool for the virtual commissioning of special purpose machines. In the project, e.g., a simulation model was built that works together with our robotic OPC UA servers for UCI (see Figure 18).  
A video of the running simulation in twin that also shows the usage of the monitoring application is given in [61].  
In the further progress of the project the scenario was then developed and tested using real hardware (see Figure 19). However, except for configuration changes, this did not mean any changes for the agents or the already developed code, since the OPC UA interface remained the same.  
The simulation model developed in twin can also support task designers to test their robotic programs without a need for concrete hardware (see Section 4.3). Thus, within our project task designers can develop and test robotic workflows which are then transferable to run on real hardware.  
Figure 17: ROBxTASK monitor webview ’Paths’ - displays parts of a sequence diagram for the use case industry scenario UCI2 of Figure 16.  
Discussions Concerning the UCI Scenarios  
Although at first glance these scenarios seem simple. However, a closer look at the details raises some questions:  
* UCI1: What if there are not enough parts in the box to fill the slides?  
Figure 19: Hardware Setting for UCI.  
Figure 18: twin Setting for UCI.  
* UCII: How must the program be changed if we want to work with 4 slides, for example?
* UCI2: What happens if there are not enough cubes or cylinders on the slides to pick them?
* UCI2: What if there is not enough space to put cubes or cylinders on the MiR100 trays?
* UCI2: What if MiR100 never sends a message?
* UCI2: What if the number of parts should be configurable?
* UCI2: Who starts the robotic workflow?
* UCI2: Shall the UR10 code end after servicing the Mir100, or wait for additional messages?
* UCII, UCI2: What about error-handling?  
Although error handling was not in the focus of this research project, we want to give some suggestions:  
* Since we use code generators to generate the agent types, we can, for example, automatically add logging statements or exception handling if needed.
* Since each OPC UA skill is a state machine, the skill can be set to 'Halt' mode in case of errors and a robot co-worker can be informed to correct the problem. For any skill a 'StatusMessage' is available which holds the last problem text and can help the co-worker to solve the problem. For example, if skills can be \"resumed correctly\", the workflow can then continue. So, in this case, throwing an exception would not be a good idea, as this would then interrupt the entire workflow.
* We currently only use simple messages for coordination in the scenario UCI2. The RxRTE has some additional choreographic features which can be used if tasks shall run as autonomous services [19], but at the time of writing these features are not implemented as Blockly blocks for the platform.
* If configurability across multiple agents is required, some parameters can be sent between devices agents using message arguments. A second feature we evaluate at the RxRTE is to integrate the key-values data store solution REDIS [62] and then use scenario global variables instead. Setting global variables may be easier to understand for task engineers.