## 4 Implementation  
For the implementation of the methods described in this paper, as mentioned before, the Robot Operating System (ROS) was used [54]. The ROS is an open-source set of software libraries and tools that are used to build robot applications. It has drivers for many devices, such as the cameras used in this work, state-of-the-art algorithms and powerful developer tools. The programming language C++ was used in the creation of the nodes responsible for process and shopfloor perception. A first implementation of the following was done in a simulation to ensure the validity of the undertaking, using the Gazebo simulator [55]. The simulation was used to test the software architecture described below and to define the requirements for the proper execution of the use case described in Section 5, regarding all fields, localization and detection included. The simulated shopfloor is shown in Figure 9.  
For the communication of all the modules of the robotic system, such as navigation, localization and object detection, as well as the execution and monitoring of the execution of the necessary tasks, a station controller was used. The station controller implemented the execution coordinator, which was responsible for enforcing the required sequence of tasks execution and keeping track of the new, pending and active tasks within the station controller. The station controller execution process was interactive and dynamic. In this sense, the station controller could respond to unexpected events in a coherent way that minimized the impact on the orchestrated tasks. The station controller was developed with a service-oriented approach. In this architecture, every action that is to be executed, such as the navigation action, has an action actor. For each actor, a key element for its implementation is the ROS Lib Action Client, which is capable of communicating with the  
Figure 8: (**a**) Contour method; (**b**) surface-matching method. Figure 9: Gazebo simulation. related ROS Lib Action Server. The server and the client communicate via a \"ROS Action Protocol\" built on top of ROS messages. The architecture of the station controller regarding the localization and detection aspects is shown in Figure 10.  
The station controller used input from a task planner, which informed the controller which tasks should be executed next. The implementation of the task planner was mainly based on information about each task saved in a database. In addition, feedback from the mobile resources motion and path planners was used, given that the final goal was to minimize the time required and the distance traveled for each task execution, with a target of maintaining sustainable cycle times. As such, when the detection and localization tasks were to be executed was determined by the task planner. The digital twin module explained in the previous section provided the infrastructure for integrating all the hardware components involved in the assembly and synthesizing all the data coming from the shopfloor under a unified common environment [41]. The digital twin provided simplified control integration and sensor data sharing, virtual representation of the shopfloor, a unified semantic data model and real-time robot behavior adaption. As mentioned above, for each action, an action message was sent from the action client to the server. A visualization of this approach for the navigation is shown in Figure 11.  
The main services for the navigation were: the executeOperation service, which initiated the execution of an operation and accepted as input a Boolean that confirmed if the execution had been initiated or not. The navigateCartPose service triggered the navigation node, which returned a Boolean variable on whether the mobile robot had reached the required position.