## 3 Results
### Architecture
Thus, this model avoids blocking subsystems to wait for responses and quickly return to their main processing responsibilities, increasing the scalability and responsiveness of the overall system. Moreover, this model offers improved reliability under increased loads, handles recurrent failures more effectively, and provides a straightforward integration between systems using different platforms, programming languages, or communication protocols, as well as between factory systems and cloud applications. By design, publish/subscribe methods can guarantee some security features such as only delivering messages to registered and authenticated clients and can also retain some messages in case of any failure of the clients. The resilience of the communication channel can also be ensured with load distribution between the server nodes and high availability methods implemented by the publish/subscribe mechanism that ensures, besides availability, scalability. The publish/subscribe methods that the middleware is implemented with are agnostic to the programming languages that send or receive the messages. This enables interoperability between stack holders by design. Figure 12: A pattern of a message path through publish/subscribe middleware, based on [40]. In our work, we present the use of two middleware systems, independent from each other because, at the shop floor, it is usually common to have legacy elements such as machines, working stations, and some sensors that may not be able to communicate directly to the cloud, either by their constraints or because of internal policies from the manufacturing companies. Human operators can input data to the cloud using a Human Machine Interface (HMI) that can write to this middleware, and then the message is translated into the cloud middleware. Machines can use their actual MES system with their actual metrics or use a specific gateway to translate the messages to the middleware on the shop floor, and the messages are forwarded to the cloud gateway. Figure 13 shows these approaches. Both middleware systems, the one in the cloud and the one in the factory, will then communicate through a standard communication protocol to update and access each other's information. In the same way that some shop-floor machines can require a gateway to translate messages to the shop-floor middleware, other stakeholders may also need a gateway to translate their information to the cloud middleware, to send and receive messages that will be used in a standard way. Figure 14 shows an example of a supply chain element that uses this approach. \"Smart Transport\" and \"Legacy Transport\" can be routed from raw material suppliers or routes of sub-assemblies between factories or even final products. This example from Figure 14 can also be applied to other elements such as products. In this example only standard communication is used. A legacy product can need a gateway to convert the legacy data to the standard communication from this platform. A legacy product is a product that was not designed to use these functionalities and/or does not have ways to communicate in a standard way. For instance, a brand-new car can be considered legacy if its configuration does not have a module to automatically connect to the platform. If the final user wants to use the functionalities from the platform, they can afterward acquire a gateway to send and receive the information from and to the platform. Figure 14: Detail on the connections to the cloud middleware by transport operators and suppliers. Figure 13: FOG middleware in detail.