## 5 Discussion  
This section illustrates how to utilize the platform developed and how to deploy the designed applications on the platform built on top of Kubernetes. The applicability of this method is not fixed to this example and can be adapted to a user-defined HAMS in any domain. To help visualize the deployment of the platform over a vanilla Kubernetes cluster, we utilize screenshots from the Kubernetes dashboard. First, the application structure is defined (explained in Section 3.4.2), based on the structural needs of the user: a two-level HAMS, where assembly lines represent asset groups and DAGs are defined for each asset. Then, the Application Structure Generator provided by the operator is used to create all the YAML files relative to each of the levels. With the YAML files developed, the application structure is deployed on the cluster (i.e., the controllers, the CRDs and their respective RBAC files, enabling the management of said resources). Figure 15 shows, as seen from the Kubernetes dashboard, that the CRDs related to our application structure are present and deployed and that there is a running Deployment for every controller related to each level. Figure 14: Sequence diagram of the high-level interactions of the complete application structure and the Kubernetes Control Plane. The creation of resources is highlighted in the blue section, the conciliation of the desired spec and the current status is highlighted in green and the deletion of resources is highlighted in red. The right side represents the addition (in blue and with a ‘+’ sign) and subtraction (in red and with a ‘\(-\)’ sign) of resources that dynamically occur over the etch. When the Applications are designed and the Components are developed (Section 3.4.4), the construction of the YAML file containing all of the Assembly Line's information is started. This custom resource must follow the CRD definition of the Assembly Line resources, as structured in Figure A5. In this case, the Assembly Line contains two Assets, while each of the Assets contains two Applications (see Figure 10). The Support Infrastructure Components are identified (see Figure 8) and deployed in the cluster. Once constructed, the AssemblyLine.yaml file is posted in Kubernetes through the kubectl CLI. According to Figure 14, this action starts the deployment process for the subsequent resources. Once the AssemblyLine resource is created, two Asset resources are created and four application resources are created. Lastly, nine component resources are created, one of which is a permanent component while the rest are ephemeral components. Figure 16 shows these elements as seen from the dashboard, where the user can interact with them and with the Pods through which they are deployed, analyze resource consumption, check logs, etc. As an example, Figure 17 shows the events related to the Asset Assembly Robot_1. It should be noted how, first, the Asset is detected as successfully created and then, as the Applications are instantiated and transitioned to the Running state, the Asset itself is tagged as Running. Figure 16: Resources deployed on the cluster as seen from the Kubernetes dashboard. Figure 15: CRDs and Deployments related to the deployment of the platform. Figure 18 reflects the events relative to the Process permanent component. It should be noted that the permanent component's ConfigMap is created with the first application that instantiates the component. Afterward, the second application that uses the permanent component modifies the existing ConfigMap adding its information, thus, making it available to the component. To reflect the operation of the applications as they process the OEE of the two Assets, Figure 19 shows how the OEE is calculated through time. To that end, the Grafana Support Infrastructure Component is used. It ingests the data left by the Processing applications at the InfluxDB Support Infrastructure Component.