## 3 Results
### Use Cases
#### 3.4.2. Welding Stations for the Automotive Industry  
Just like the previous use case, in this scenario, the idea is to demonstrate an end-to-end interaction between all the actors, using the same architecture but highlighting the flexibility to have more stakeholders. For simplicity, we will maintain the ERP software (demonstrated by Figures 25-28), which will send the information to another partner to produce a different part. This use-case manufacturer is represented by two different industrial robotic cells, designed to perform spot welding processes (the two robotic cells  
Figure 31: Production result.  
Figure 32: Blockchain interface with consumption data.  
can be seen on Figure 33). This scenario is implemented in an R&D facility and respects all current industry standards, in terms of safety, hardware, and ISOs; however, they are not included in any active production system or value chain. This means that these cells can provide industrial representative cells, without the major drawbacks of using cells integrated with active production systems.  
This use case uses a more traditional approach in which the machines and MES are connected to an \"Enterprise Information BUS\". The topology is depicted in Figure 34 and allows one, with few modifications, to use any cloud system on top of it.  
This system uses OPC UA as a medium of communication between the components, since it is the most widely accepted communication protocol in most industries, especially when considering the realities of the automotive sector and all the safety and internal policies of the different constructors.  
Figure 34: Welding use-case architecture.  
Figure 33: R&D facilities with two different welding stations.  
The \"Station Server\" is responsible for providing communication middleware between hardware devices and the system in a bi-directional way. The \"Device Adapter\" is responsible for collecting the raw sensor data provided in the station server and processing it into relevant KPIs for the production process being performed and deconstructs complex orders to be produced by the unit. The \"Enterprise Information Bus\" is mainly responsible for creating bi-directional communications between components and providing features, such as the following: (i) allowing connection to potential cloud services, for which it provides an easy-to-use and integrated exporter that can be adapted to the most commonly used communication mediums seen in cloud services such as Kafka Apache and REST Servers; (ii) collecting production orders from one or multiple ERPs, in order to create instances of products that need to be produced; and (iii) managing the production and distribution of products according to the stations available in the network.  
In this use case, MES has the task of assigning products (to be produced) to the available stations. To do so, data from various factors need to be validated such as production deadlines, sustainability, product quality requirements, and station usage, among many others. It is important to mention that the MES can access and use information from other components in the network and external cloud systems, like the orders from the ERP allowing for a more data-driven decision production optimization in the MES process.  
This use case highlights the flexibility of the architecture and platform since the only requirement was the inclusion of the publish/subscribe mechanism and the agreed information to exchange, namely the spots and materials to weld as inputs and the energy consumption as an output. The architecture and implemented platform are agnostic to the actors that connect to it. The I4.0 paradigms represented here are the use of cloud infrastructure, horizontal integration, and IoT. In this scenario, we could also easily connect tools that enable augmented reality on the shop floor (and enhance the vertical integration inside the company) and simulation tools that could enhance the performance of the welding robots.