# Fog Computing Architecture for Load Balancing in Parallel Production with a Distributed MES
## 3 Materials and Methods
### Fog Computing as an Intelligent Intermediary Between MESs and Cloud  
Due to the horizontal scaling mentioned in the previous subsections, it is necessary to have an additional layer located at the edge that acts as an intermediary between the MESs and cloud systems and also has order request orchestration capabilities. This will meet the requirements involved in the productive expansion of an SME, thus creating an integrated technological situation that maintains the flexibility of the architecture, improving local management, reducing dependence on the cloud, and reducing decision times for task distribution. Below, in a summarized context, the operational functionalities of the cloud computing platform and MESs are mentioned as the basis for the initial study. In the case of the Amazon Elastic Compute Cloud (EC2), different software tools (Node-RED, MySQL, phpMyAdmin, and Apache) were installed, allowing a user to remotely generate their order and have it stored in a database. When the FC node requests the download of stored orders, the MQTT/TLS mosquito broker (Node-Red) publishes this information and stores it locally. As this is a two-way communication, the stock levels of the parts stored in the warehouses are displayed in real-time for users. This datum is published by MQTT clients (MES) to the MQTT broker (FC node), which in turn publishes it to the cloud, thus maintaining the cycle of distributed interoperability between heterogeneous devices (MESs--FC node--Cloud), as shown in Figure 4.  
Figure 3: Fundamentals of the current study and technological deployment in expandable architecture. The process just shown is made possible by a Python v3.9.16 script developed for the FC node, which concurrently executes multitasking using the multithreading library to perform the following: downloading orders from the cloud, storing them in a local database (port 3306 enabled); orchestrating tasks decided by a hybrid algorithm based on integer linear programming (ILP); monitoring information from MESs (stock, energy consumption, and production time); and the use of a Node Exporter tool (port 9100 enabled) to measure FC node performance metrics and MQTT/TLS communication (port 8883 enabled) between MESs, FC nodes, and the cloud, in a manner consistent with IEC 62443 industrial automation system network security [32]. It is also mentioned that interoperability with the cloud is possible due to the endpoints available, such as Node-RED, Prometheus, and Grafana, where the first is part of the extended architecture. The other two are not as they are used exclusively to visualize the metrics of the FC node targets (ports 9090 and 3000 enabled) and thus analyze their performance. Functional Architecture of the FC Node with Multi-Objective Optimization  
Task orchestration begins when the FC node processes the data published from the MESs (the number of parts still to be processed from the order). It is a cumulative calculation of the remaining total of the vector arrangement explained in Section 3.2, thus achieving a dynamic load balance based on the production status. Although this logic is an intelligent orchestration, it is a rigid method in the face of current needs; i.e., it does not consider production variables as strategic decision factors typical of highly dynamic markets. For this situation, a hybrid algorithm based on integer linear programming (ILP) and heuristic rules was developed to optimize task management decisions and streamline load balancing. Accordingly, the values shown in Table 1 are now relevant to this document. The implemented algorithm is considered hybrid because it estimates production time and energy consumption weights, as well as project costs and adaptive rules. That is, the production cost \(Cost_{m}\) for any MPS\({}_{m}\) is equal to the sum of the time and energy weights (Equation (1)).