## 3 Materials and Methods
### OpenFog-Compliant Architecture  
This section is devoted to presenting the system architecture and its working principles. Figure 2 shows the architecture, based on the three-layer design proposed by OpenFog. The lowest level is composed of IoT devices, that is, sensors and actuators that interact with the physical world. The second layer, or Fog, comprises the devices that receive, process and send data produced by the IoT devices to both the Cloud and back to the IoT layer. The uppermost layer, or Cloud Computing, is composed of a set of centralized data centers, which provide permanent storage capabilities and store container images in the Container Image Registry (CIR) for their use in the Fog layer. The interaction between the layers is as follows: the IoT device layer utilizes a Fog-IoT Message Hub to send messages to and receive messages in an asynchronous manner from the Fog; the Cloud layer, on the other hand, utilizes a Fog-Cloud Interface to send and receive data from the Fog in a direct and synchronized manner. At the Fog layer, the architecture is based on a Fog Node acting as a Master Node that manages the cluster, and a set of Worker Nodes that perform the necessary processing. The Master Node enables the centralized access to the cluster for external users, manages the dynamic addition of Worker Nodes to the cluster and assigns the workloads to be deployed on each Worker Node. Moreover, the Resource Storage at the Fog layer is centrally accessible through the Master Node. To run containers, both the Master Node and the Worker Nodes need an adequate container runtime engine that enables an environment for container execution. An agent runs on each Worker Node to locally manage the workloads assigned and provides the necessary network infrastructure for workload communication. The workloads assigned to the Worker Nodes are the microservices that compose an application. In fact, Kubernetes defines workloads as \"_an application running on Kubernetes_\" [34]. Each microservice runs inside of a container and, to support the decoupling of the microservices, they make use of the Intra-Fog Message Hub to communicate by using a data-oriented protocol. On the other hand, the Master Nodes and the Worker Nodes directly communicate through a request-response protocol, such as HTTP, and can talk to the Cloud and the IoT Devices layers via the Fog-Cloud interface and the Fog-IoT Message Hub, respectively. The platform resulting from the implementation of this architecture is designed following the principle of Platform as a Service (PaaS). Therefore, the resulting platform, as OpenFog states, \"_allows customers to develop, run and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an application_\" [7] (p. 14). The platform is composed of applications that represent the workloads deployed on the Fog Nodes. The application logic can be subdivided into application components that work together to accomplish the business objectives of the  
Figure 2: Proposed system architecture. application. These components are selected when designing the application and, following OpenFog's philosophy, are considered Application Microservices during runtime. In summary, business logic is designed as functionalities offered by application components and provided as services offered/required by Application Microservices. To be compliant with OpenFog, the authors propose a software architecture that relies on the Software viewpoint of OpenFog's architecture. This is based on a three-layer model that describes the software that runs on a Fog platform. Figure 3 compares OpenFog's stack to our software architecture stack. The bottom layer of Figure 3 brings together the aspects related to the hardware on top of which the Software Backplane (the platform itself) is built. The Application Support services lay on the Software Backplane. These services do not satisfy any business-specific need on their own.