Digital Transformation of Legacy Manufacturing Using Industry 4.0 Tools ^†

Abstract

This study contributes to the design of a bidirectional communication architecture based on the ISA-95 standard, which is integrated with an IoT gateway network to digitize plant-floor data, a manufacturing execution system (MES) with local backup and automatic inventory updates using YOLOv5-based computer vision, and a cloud instance for product order management. According to interoperability metrics, the results demonstrate the feasibility of developing digital scalability in an architecture composed of heterogeneous devices, maintaining interconnectivity throughout the entire value chain.

1. Introduction

Currently, due to the digital revolution, the manufacturing industry requires efficient, flexible processes that enable interaction between consumers and suppliers to remain competitive in the global market [1,2]. To achieve these goals, it is essential to leverage the pillars of the fourth industrial revolution (I4.0) [3]. However, this digital transition faces challenges in relating information technology (IT) to operational technology (OT) [4], because manufacturing processes have cyber–physical systems (CPSs) and, in order to be controlled, require an architecture that stores information, makes decisions, avoids errors, allows communication between different heterogeneous devices, etc. [5,6]. Despite this, several studies are based on different standards to support current manufacturing requirements, such as ISA 95 [7], ISA 88 [8], and IEC 61499 [9].

Furthermore, due to the absence of Industry 4.0 architecture standards, various models have emerged, such as those proposed in [10], which present an industrial cyber–physical system (ICPS) composed of three layers. The first layer is a network of nodes that enables information collection from a shipyard workshop by deploying a wireless network spanning multiple sensor networks and communication protocols. The second layer provides an independent bidirectional communication channel for each sensor network, allowing the fog service to interpret the location of the pipes in the process. Consequently, Orange Pi cards with RAM, CPU, and clock rate characteristics were acquired to enable real-time processing, which is essential for avoiding errors in pipe location. Finally, a layer responsible for data administration and visualization in an enterprise resource planning (ERP) system. Continuing this study and aiming to improve product traceability within the plant [11], the same architecture as in the previous study is proposed, with modifications to the node layer that use Bluetooth 5 devices. Similarly, ref. [12] implemented technologies such as digital twins and cloud computing to develop a manufacturing process system planner that can be executed from a digital twin within a manufacturing execution system (MES). In addition to supporting multiple instances for execution, its architecture is primarily based on communication among the production plant (OPC UA), digital twin (HTTP/REST), and ERP (HTTP/REST) with the MES. As a complement to this study [13], a new decision-making model was incorporated to automate MES planning using machine learning (ML). On the other hand, simulated studies related to the research topic serve as a guide rather than an actual implementation, such as [14].

The aforementioned studies employ several pillars of I4.0. However, the task is broad and complex, as it involves integrating all technologies to achieve a fully intelligent factory. This means that, after a systematic review, no subsystem is identified that prevents production stoppages when network infrastructure collapses or that enables inventory updates via sensors or an AI model. That is why this article implemented an MES for production process control in a modular production system (MPS 500) from FESTO, thereby avoiding the loss of production lines due to periodic mini-batch updates. It will also provide the user with an update on the stock of products in the warehouse through artificial vision. Other technologies that are included in this architecture are cloud computing and IoT. In this way, the architecture offers flexibility for future studies on the incorporation of fog computing at the plant and management level.

Following its introduction, this document is structured as follows: Section 2 presents the materials and methods used in the study, Section 3 presents the results, Section 4 presents the discussion and Section 5 presents the main conclusions.

2. Materials and Methods

The industrial architecture I3.0, scaled to I4.0, comprises four levels. The first level has four FESTO MPS 500 modular production stations connected by AS-interface protocol. The elements communicate using IEEE802. 11/b/g/n/e/i with the MES located in the third layer through MCU intermediary agents. At this point, the mini-batch production line from layer 3 in the cloud is managed via the MQTT protocol, with a user requesting an order via a dashboard according to their requirements. The MES also backs up the orders hosted in layer 4 to the plant in case of a connection loss. Finally, the AS-RS station has a camera that captures frames of the products in stock, outputs information from the AI that is sent to layer 3 for storage and visualization, as shown in Figure 1.

The development of this architecture is based on understanding the current pillars required by I4.0; however, implementing them in their entirety requires IT and OT skills. In this context, the methodology follows from the flexibility, heterogeneity, and scalability these provide. Consequently, the structure of this architecture comprises four layers and the technological subsystems implemented within them.

2.1. Manufacturing Production Line

The manufacturing process begins at the AS-RS station, where the product type is selected, and then the product is dispatched to the sorting station. Once the product has been selected, the production process begins at the machining station from the distribution station, maintaining the product stock. The synchronization process for the aforementioned stations starts at the master conveyor station via the AS-i protocol.

To scale the manufacturing process described above, it was decided to develop an MES architecture that would benefit from cloud services. As a result, the S7-300 PLCs located at each station are equipped with an ESP32 that operates on Wi-Fi 802.11 b/g/n/e/i. This device enables wireless communication with the MES via the ESP devices’ WLAN master, as shown in Figure 2.

2.2. Secure Communication and Data Certification

The transition to smart manufacturing environments requires not only the integration of IoT technologies but also the implementation of digital security mechanisms that guarantee the confidentiality, integrity, and availability of information. In the developed system, TLS (Transport Layer Security) certificate processes were implemented to establish secure communication channels between the local MES and the cloud-deployed services.

To this end, manually signed digital certificates were generated for both the server and the client under a mutual authentication scheme. This practice ensures that communication between the MQTT modules—responsible for data exchange between the edge and the cloud—cannot be intercepted or manipulated by external agents. The certificates were issued by a local certification authority (CA), which generated the required public and private keys using 2048-bit RSA.

The MQTT broker Eclipse Mosquitto MQTT broker (version 2.0.18, Eclipse Foundation, Ottawa, ON, Canada) was configured in “TLS-only” mode, disabling any unencrypted connection attempts. This approach was adopted as an industrial security policy to prevent man-in-the-middle attacks and unauthorized interception of production data in transit. Firewall rules were also established at the Raspberry Pi network layer and in the cloud service infrastructure to restrict traffic to secure ports (8883/TCP) and specific IP addresses.

The security certification also enabled the implementation of an audit log for access to the MES, allowing tracking of any unauthorized connection attempts. This established an additional layer of digital traceability that extends the traditional concept of product tracking to information integrity.

As a result, the proposed architecture not only complies with the ISA-95 [15] and ISA-88 [16] industrial standards at the functional level, but also aligns with industrial cybersecurity best practices (IEC 62443) [17], which recommend the application of encryption, authentication, and network segmentation in connected production environments.

2.3. Process Management

Figure 3 shows an active production system with several features that maintain a sustainable supply chain. To achieve this, an MES was implemented on a Raspberry Pi card with a 1.5 GHz quad-core processor, 4 GB RAM, and 802.11ac Wi-Fi. This allows cloud requests to be managed and processed on-site. This is done through the ESP32 master located at the edge of the plant, which manages the start and end of the production process. Communication with the cloud, on the other hand, performs two actions. The first step involves acquiring images from a 720p HD webcam on the AS-RS station and using the YOLO v5 artificial intelligence model, which offers real-time object detection capabilities, making it ideal for smart manufacturing environments where low-latency industrial inspection is required [18]. Consequently, the different types of products in stock are processed and identified. To detect the position of the products within a specific space, a segmentation algorithm was implemented, resulting in a 3 × 5 matrix, as shown in Figure 4. Based on this, a vector is generated, encoded, and sent to the cloud Node-RED (version 3.1.0, OpenJS Foundation, San Francisco, CA, USA) for reading and storage in a database MySQL database (version 8.0.33, Oracle Corporation, Austin, TX, USA).

Considering that the manufacturing system architecture is operating normally under the quality of service (QoS) conditions of the internet service provider (ISP), customer orders are stored in the cloud and automatically downloaded to a local MES database as a backup of order batches. This triggers the second action to provide a redundant MES, ensuring the supply chain remains operational in the event of QoS service errors.

2.3.1. MES Backups

Under stable connection conditions, the MES automatically records new orders (see Figure 5) in a local database (MySQL). This information is suitable for managing the batch process, and once dispatched, its record is deleted to maintain stable memory space.

The manufacturing process delivers three different products; therefore, the structure of the table in Figure 5 is composed of individual information for each product type, as well as the locations of the products to be shipped in each batch.

To avoid stockouts, replenish products at the AS-RS station. This is how the MES manages the information in the table in Figure 6 to the distribution station to continue with the production line, and returns the number of pallets as information to complete a new record and thus execute the storage action in the AS-RS station. Once this entire operation is complete, the data is deleted from the tables in the aforementioned figures.

2.3.2. Concurrency in Management Processes

In order for the architecture to be stable at all levels of integration, and knowing that the MES is a fundamental part of communication between the plant and cloud services, in this case study the MES meets several requirements that must be executed concurrently, such as: ensuring the system connection in the event of a network failure (Check connection), exchanging data with the server (Client–broker connection), and executing AI models (AI system). Additionally, a dedicated thread responsible for communication with the plant remains continuously active to ensure stable process communication and process data handling (see Figure 7).

2.4. Production Planning

An Amazon EC2 instance (Amazon Web Services Inc., Seattle, WA, USA instance was deployed to support the dynamic nature of modern manufacturing environments and the need for remote interaction between users and production systems. The cloud infrastructure enables centralized production order management, remote access, and scalable communication between plant devices and cloud services within an Industry 4.0 environment. This instance also hosts a MySQL database, an Apache HTTP Server (version 2.4.57, Apache Software Foundation, Wilmington, DE, USA), the Node-RED data flow platform, and the Eclipse Mosquitto MQTT broker (see Figure 8). MQTT was selected for its lightweight publish/subscribe communication model, ideal for efficient data exchange between machines and the cloud in distributed industrial systems. With this architecture, users can remotely place production orders and monitor stock availability in the MPS 500 modular manufacturing system, while the MES exchanges information with the cloud-based management planner via the MQTT broker.

3. Results

Once the flexible architecture had been developed and an MES implemented to scale the MPS 500 from I3.0 to I4.0, several tests were carried out to validate its operation, such as: requesting several mini-batch orders from the cloud, updating stock before placing the order, the response of the MES when the network provider service is active and there are failures between the MES connection and the cloud database, and finally the production line process.

From the aforementioned tests, temporal metrics were collected and used for analysis of possible critical and non-critical systems with the architecture developed in this study. In this context, we begin with the time it takes for the architecture to reconnect after the internet connection fails, and identify the event using MES. In this way, it takes action as a condition when internet connectivity returns, sending a notification to the cloud to download the orders stored during the outage. To measure reconnection times, the internet service was manually interrupted, yielding an average reconnection time of 1 min and 15 s across 10 attempts (see

Table 1. Reconnection times for order downloads.

Test Number	Reconnection Time	Test Number	Reconnection Time
1	00:01:16	6	00:01:23
2	00:01:10	7	00:01:19
3	00:01:14	8	00:01:20
4	00:01:19	9	00:01:17
5	00:01:24	10	00:01:15
Average Reconnection Time         00:01:17

).

When the MES starts up, it takes approximately 24 s due to the concurrent instructions mentioned in Section 2.3.2, where it was identified that the AI system instruction to keep stock up to date captures and processes the image each time a batch has been dispatched. This process involves identifying the averages of the metrics shown in

Table 2. AI processing time and resource consumption.

AI Model
Computational resource consumption	CPU 100% MEMORY 27%
Processing time	00:17:00

after 10 tests were performed.

In addition to functional validation, tests were carried out to evaluate the performance of the security certification and encrypted communication mechanisms implemented in the system. To guarantee the integrity of information transmitted among the plant level, the MES, and the cloud, a mutual authentication scheme using digital certificates was adopted in accordance with the TLS protocol. This procedure the MQTT nodes deployed on the ESP32 devices, the Raspberry Pi, and the remote server, ensuring that only authorized equipment could exchange production data. The certificates were issued by a local certification authority, which generated 2048-bit RSA keys and signed them individually for each participating entity, thereby involving the MQTT nodes deployed on the ESP32 devices, the Raspberry Pi, and the remote server, ensuring that only authorized equipment can strengthen traceability and authentication within the test environment.

The experimental tests focused on measuring the latency introduced by encryption, the stability of the secure connection, and resilience to link interruptions. Under controlled conditions, the average TLS handshake establishment time was approximately 52 milliseconds, while the latency of encrypted message transmission was around 3.4 milliseconds, values considered negligible compared to the total production cycle time. When evaluating the system’s reconnection after deliberate network service interruptions, the process of reestablishing the secure channel-including certificate validation and session reinitialization-took an average of 1.21 s, with no loss of information or data corruption. These metrics show that the use of encrypted channels does not significantly impact overall performance, demonstrating the feasibility of incorporating cybersecurity mechanisms into smart manufacturing systems without compromising operational efficiency.

During load testing, system resource consumption was monitored to determine the impact of encryption on the hardware. A 4.8% increase in processor usage and a 1.9% increase in RAM usage were observed, reflecting a minimal load resulting from packet encryption and maintaining the active TLS channel. This behavior confirms that the security implementation does not interfere with critical MES operations or degrade its concurrent processing capacity. Likewise, the audit logs generated during the test sessions enabled verification of the complete traceability of each connection, documenting authentication, session closure, and reconnection events with millisecond precision.

On the other hand, the YOLO v5 model used for object detection showed 100% accuracy and sensitivity due to the existence of a single class. However, the model’s accuracy after 30 detections, similar to the one shown in Figure 4a, is 85%. Continuing the process, the segmentation algorithm achieved 100% accuracy as long as there was no physical disturbance to the camera positioning. Finally, a CNN AI model was used to detect the colors of the parts, achieving 100% precision and 85% accuracy. The training parameters for object and color detection are shown in

Table 3. Training parameters for AI models.

Parameters	Object Detection	Color Detection
Epochs	50	60
Batch	8	16
Learning rate	0.01	0.0001
Training rate	898	297 each color
Validation rate	189	53 each color
Total data	1087	1050

.

The current state of technological development has made artificial intelligence models for object recognition widely available. As a result, the attributes of two AI models were modified to determine the cloud stock of products stored in the AS-RS station, as explained in Section 2.2. However, this methodology could be simplified into a single model with three classes, thereby reducing the number of threads in the MES algorithm and consequently improving the performance of the development board.

With the idea that the MES should maintain communication between the plant and the cloud under stable conditions or in the event of a network failure, it was initially proposed that the MES execute a request/response instruction within a specified time (1 min). However, in tests carried out, the performance of the development card decreased, registering high resource consumption and, as a result, the execution times for communication and the manufacturing process slowed down, drastically increasing latency in the architecture, as shown in

Table 4. Process execution time.

Process	Normal Operation (mm:ss:ms)	Operation Requests Per Minute (mm:ss:ms)
System startup	00:24:370	04:37:680
AI model processing	00:14:050	00:51:330
Data transmission CLOUD–MONTH	00:01:250	00:04:250
Data transmission for shipped product	00:00:940	00:01:340

, which compares execution times when the architecture has and does not have a request/response instruction within a specified time.

In both cases above, it is essential for designers of Industry 4.0 manufacturing architecture to understand the resources involved in incorporating I4.0 pillars as the factory evolves into an intelligent factory.

4. Discussion

Modern manufacturing environments require interoperable, scalable Industry 4.0 architectures that integrate information technology (IT) and operational technology (OT) across the entire value chain. Several studies have proposed architectures based on standards such as ISA-88, ISA-95, and IEC 61499 [19], incorporating technologies including fog computing, digital twins, cloud computing, ERP-MES communication, and machine learning for production management and decision-making. However, most of these studies are conceptual or simulation-based and primarily oriented toward large-scale industries, while limited information is available on integrated digital transformation methodologies for micro and small manufacturing enterprises. In addition, many reported approaches to technological integration rely on proprietary industrial devices and platforms, significantly increasing implementation costs and limiting access for small and medium-sized companies. Furthermore, existing approaches still have limitations regarding continuous plant/cloud interconnection, fault tolerance during network failures, and real-time inventory updates via AI-based inspection systems. To address these challenges, this work proposes a Plant/MES/Cloud architecture based on ISA-88 and ISA-95 standards that integrates heterogeneous low-cost devices, cloud services, MQTT communication, and YOLOv5-based artificial vision to enable interoperable communication, real-time production management, inventory monitoring, and digital scalability. In this way, the proposed methodology provides an accessible and viable path for companies of different sizes to progressively scale toward Industry 4.0 environments.

One of the aspects identified for improvement is the computational performance analysis of the implemented digital enablers, since low-performance embedded devices may introduce latency, lag, or instability due to resource saturation and overheating during continuous operation. Consequently, future implementations should consider using optimized object recognition models with lower computational consumption, lightweight AI algorithms, or cloud/edge computational instances with machine learning acceleration capabilities to support the processing tasks performed by embedded development boards.

On the other hand, the current architecture does not yet account for large-scale production expansion scenarios. In such cases, it would be necessary to integrate an additional hierarchical layer at the edge of the plant to manage production processes more efficiently. Under this approach, the MES would not communicate directly with the cloud infrastructure but would instead do so through an intermediate Fog Computing layer positioned closer to the industrial environment. This would reduce communication latency and improve the response time of distributed industrial processes. These aspects represent an open research opportunity for future work on industrial scalability and the evolution of Industry 4.0 architectures.

The developed architecture could support production planning through minor modifications to the digital enablers and programmable logic controllers at the plant level. This would enable real-time transmission of data from sensors and actuators to the cloud database infrastructure. However, at the cloud level, enterprise management software with native database communication capabilities would need to be integrated to efficiently manage industrial information and coordinate production planning. Furthermore, this integration would enable the generation of functional reports for various company departments, including production, maintenance, finance, sales, and marketing, substantially increasing the interoperability and value chain capabilities of the proposed Industry 4.0 architecture.

5. Conclusions

Currently, there are standards that govern processes in the industry, such as ISA-88, which establishes models and terminology for batch process control, such as product analysis (process model), location and equipment where it is produced (physical model), and product development (process control model), all of which have been implemented in the plant. On the other hand, the ISA-95 standards enabled the development of a hierarchical architecture with five levels of integration.

The development card that housed the MES enabled concurrent processes. However, as the complexity and execution period of these tasks increased, instability and performance deficiencies arose, especially when delays were used, since these are part of the memory space. Therefore, for process management with I4.0 technologies, it is recommended to use higher-performance development cards than those used in this article.

Considering the results shown in Table 4, it is evident that, between levels 3 and 4 of the developed architecture, the time for bidirectional information exchange between the cloud and the plant is not critical, as it is much shorter than that obtained in level 1 of the process, representing only 0.72%. This means that while batches are being manufactured and dispatched at the plant, orders requested at level 4 have already been stored in the MES backup, and inventory stock is being viewed in real time.

To scale the MPS from I3.0 to I4.0, some pillars were added to the architecture developed in this project. Thus, artificial vision was added to the AS-RS station in the plant to keep inventory available to the user, achieving 85% accuracy in the two implemented models for position and color, which we consider acceptable.

The architecture in question was based on ISA-88 standards at the plant level for the batch process and the hierarchy between the integration levels described in ISA-95, highlighting the effectiveness of the operational process at all levels of integration, so much so that in just 0.72% of the time it takes the plant to develop an order, the backup was already available in the plant, ready to be executed from the MES. Even during the reconnection of the architecture in the event of infrastructure failure, it accounts for 65% of the production process period, equivalent to 77 s.

The proposed architecture was designed to digitally transform a legacy industrial system by integrating Industry 4.0 technologies aligned with the ISA-88 and ISA-95 standards. The results demonstrate the feasibility of digital scalability by enabling interoperable communication among heterogeneous low-cost devices, cloud services, MES, embedded systems, and AI-based inspection modules across the entire value chain. Furthermore, the architecture maintained continuous information exchange across integration levels, demonstrating its suitability for scalable industrial environments.