## 6 Conclusions  
Fog Computing presents a suitable environment for offering Cloud-like services closer to the sources of data. However, to the authors' knowledge, container orchestrators are not aware of the collective representation of their components as applications, nor do they support their logical grouping in a hierarchy based on the operating model of a system or organization. This work contributes with an application-aware platform that enables the design of a HAMS the elements of which have applications designed as DAGs associated. This approach enables the consideration of abstract concepts from the organizational or business structure at runtime. Thus, the deployment of microservice-based Fog Applications may include these abstract representations utilized in the HAMS definition. The approach described in this work implements the presented architecture over Kubernetes, utilizing its standardized extension methods. The Supervision Infrastructure Services deployed as Kubernetes controllers enable the separation of concerns between the different phases and actors found when designing, developing and deploying Fog Applications. It abstracts the application designer from the usage of the container orchestration tool and from the development of Support Infrastructure Components and Application Components. Furthermore, the usage of an extended Kubernetes platform itself allows users to decouple the deployment of the application structure elements from the runtime management. The intelligence of the controllers makes it possible to provide scalability during runtime to consider additional assets or applications in the platform or to include additional abstractions as levels in the HAMS. Being implemented based on standard Kubernetes extension methods, the platform could be extended with other available tools or operators to cover some requirements that the proposal might not cover. However, the proposal has some disadvantages, as in its current state it only allows the communication of the microservices through a publish-subscribe mechanism that requires the programmers of the components to implement that functionality and make it parameterizable with the information provided in the component resource. Furthermore, the proposal requires users to develop quite complex YAML files that could be automated in further work using MDE. Additionally, although the HAMS provides some flexibility, it cannot be modified during runtime and only one Application Structure might be deployed at a time. Figure 19: OEE calculation of the two Assets through time. The Vertical axis represents the OEE value and the horizontal axis represents its calculation time. The green and yellow points represent the computed OEE for Assembly Robot_1 and Assembly Robot_2, respectively. The orange points depict the OEE threshold under which the machine performance is not acceptable. Future work is also aimed at exploring the performance limitations of the proposal through quantitative analysis and stress tests, searching for the limits of the controllers developed and the application structure as a whole. In those cases, the autoscaling feature of Kubernetes could be explored to scale controllers as needed. Scalability should also be introduced in Application Components as the current approach only considers static scalability or replicas. Future work might also consider other different routes. The inclusion of more complex DAGs and the coexistence of several simultaneous HAMS in the system should be explored. It should be considered that every component might offer more than one service to different entities. Support for direct synchronous communication between components could be introduced as an alternative to the presented topic-based publish-subscribe communication paradigm. The design and development of the HAMS and its elements could be performed through a more user-friendly editor. Node restrictions and awareness could be improved when deploying Fog Components.