## 3 Materials and Methods
### OpenFog-Compliant Architecture
However, they provide infrastructure services (i.e., message buses, storage volumes, operation management) to the workloads that do achieve business goals and applications. In our platform, Application Support services are covered by the Infrastructure Components, which are subdivided into Support Infrastructure Components and Supervision Infrastructure Components. * Support Infrastructure Components offer common services that are deployed once per cluster and assist in operations such as component communication. They are represented during runtime as infrastructure microservices, providing an API for each one of the services they offer. * Supervision Infrastructure Components offer services for the management of the resources related to the HAMS. These components are responsible for creating the required resources and managing their relationships and their lifecycles. Therefore, the Software Backplane acts as a control plane (e.g., making global decisions about the cluster, such as starting new Pods or assigning Pods to Nodes), while the Application Support acts as the management plane (e.g., in the manufacturing domain, enabling tasks closer to the applications, such as launching all the DAGs related to a station at boot, or stopping all DAGs related to a line when it stops as production needs decrease). The uppermost level of the Software viewpoint of OpenFog's architecture is composed of Application Services. These fulfill business goals and requirements and are dependent on the services provided by the lower layers. Therefore, applications make use of Application Services and Application Support services to pursue their goals. In our platform, Application Services are covered by Application Components, represented at runtime by application microservices. According to their persistence on the platform, application components are separated into Ephemeral and Permanent components. Ephemeral application components have their lifecycle tied to the application to which they belong. They start running at the same time the application deployment is requested and are decommissioned from the platform  
Figure 3: Comparison of OpenFog’s Software View (**Left**) and our Software Stack (**Right**). at the same time as the application. Permanent components, on the other hand, exist on the system and their deployment can be requested by the users or by the applications themselves. However, their lifecycle is not tied to any application. Thus, permanent application components may exist prior to the deployment of any application and may persist once the application is no longer running. The services provided by these permanent application components may be used at the same time by many applications, resulting in a multitenancy of these components and optimizing the performance of the platform. Applications deployed on the platform are also categorized according to their lifecycle. Permanent applications pursue the realization of stream processing tasks, where incoming data are constant and some kind of data treatment is required; for example, IoT sensors in continuous processes. Ephemeral applications pursue the realization of batch processing, where data comes in batches or packages, are processed on demand and, upon completion, the application is no longer required. Thus, ephemeral applications are deployed to process some data and decommissioned once the data has been processed. This behavior is inherent to manufacturing processes where production requests come in batches as opposed to a constant manner. Lastly, the deployment of every concept previously explained in this section is performed leveraging the advantages the container virtualization offers. In our platform, containers encapsulate both application microservices and infrastructure microservices so that these containers can be deployed on the diverse Fog Nodes that form the platform. These nodes are hierarchically structured and their management, as well as the management of the container execution, is delegated to the container orchestrator.