## 3 Results
### Architecture  
The proposed architecture consists in five main elements that will communicate with each other, namely the cloud middleware, the supply chain, the smart factory, the customer, and the product, as shown in Figure 10. The middleware hosted in the cloud will be the mutual point of interaction. Thus, all the other elements need to reach the cloud to share and exchange data, information, orders, and so on. Figure 9: Interaction between execution system and other systems. In this way, each component needs to expose its functionalities to the others to be reachable. Thus, this architecture will follow a service-based approach, which means that all the components of the architecture will expose its functionalities as services, making them available for the other components, and then be able to establish communication with the different components and systems. These services will be exposed through standard interfaces that are the point of interconnection between two systems or sub-systems in a transparent way. The main components of the system, as well as their inner components, will interact with each other through the system's cloud middleware (Figure 11), where all the data and information will be stored, available, and updated continuously or periodically, depending on the type of data. The elements will not interact directly with each other, rather they will interact with the common middleware to reach the other elements. The cloud system will ensure that even if an element is down, its latest information will still be available to the remaining elements. Both vertical, i.e., integration and interoperation of all software tools and hardware inside the factory, and horizontal, i.e., capacity to interoperate all the actors that contribute to the value chain, such as suppliers, factories, and the product itself, communication should be supported by the cloud middleware. The middleware works as a system or software component that is used to connect different applications or systems. The objective is to create communication between applications without them having to know about each other's state and with minimum knowledge about the network connection [39]. Middleware systems have been more adopted lately since vast quantities of systems with different responsibilities are involved and must work  
Figure 11: Detail on cloud middleware. Figure 10: Proposed Cloud-based Architecture. cooperatively to keep the production in the good direction, from sensors and actuators on the shop floors to management systems for ERP. This architecture presents two middleware systems, the one in the cloud and the one in the factory, that will provide a service registry, Yellow Page structure, that stores the diverse services available in the system. The distributed and cloud approach that handles the interconnection of the elements by following service-oriented principles will avoid limitations for scalability, as well as problems related to single points of failure. Both middleware systems, the one on the cloud and the one internal to the factory, will work with a publish-subscribe model. This model enables an application to announce events to multiple consumers by asynchronously broadcasting messages to different parts of the system. Our approach considers that each component that sends data to the cloud or to be consumed by other entities is a publisher. A component that reads messages from a specific topic is a subscriber. The same entity or software can be a publisher and a subscriber at the same time. Typically, a publisher translates changes in the system or action into event messages, using a generic message format. Those messages are then published into specific topics in the middleware through a standard interface. The subscribers are notified that a new message is available on the topics that they are subscribed to. Figure 12 exemplifies this pattern. A publish/subscribe model is an effective way to decouple sub-systems and manage communications between them, independently.