RAMI 4.0 Architecture for Industrial Traceability with Artificial Intelligence and Integrated Security

Abstract

The demands of competitiveness in global markets require the integration of Industry 4.0 (I4.0) digital technologies for any manufacturing company, regardless of size. Industrial operations require complete supply chain visibility to ensure data protection and authenticity throughout the process. This document presents a distributed architecture based on RAMI 4.0, designed for product traceability in industrial environments. It integrates automation tools, IIoT communication, cloud storage, artificial intelligence, and secure data transmission using encrypted communication protocols. The system consists of a hybrid architecture; only the first, lower-level layer corresponds to a simulated manufacturing plant with deterministic and stochastic dynamics within the production line. In the second part, the middle and upper layers are implemented, where plant data is transmitted to a cloud instance, stored in a PostgreSQL database, and subsequently analyzed using automated scripts. Reporting capabilities are incorporated with ChatGPT-3.5 Turbo, and visualization is provided through Odoo. Experimental tests demonstrated an average end-to-end communication latency of less than 200 ms, a packet loss rate of 2.67%, and 100% reliability in verifying requested reports when using the cognitive computing service. Furthermore, the results of the systematic vulnerability identification process for the architecture show a significant reduction in overall risk for most assets, with a predominant shift from high or moderate to low or moderate. The proposed architecture is validated in a simulated industrial environment under controlled conditions, demonstrating its viability as a prototype rather than as a fully implemented industrial solution.

1. Introduction

The contemporary manufacturing industry, particularly small and medium-sized enterprises (SMEs), faces significant challenges associated with the growing demand for customized products, the increasing complexity of industrial process management, and the need to optimize limited resources to remain competitive in highly dynamic global markets [1]. In response to this scenario, adopting advanced technologies is essential for enhancing operational efficiency, reducing costs, improving process quality, and enabling rapid adaptation to market changes [2].

Within this context, several architectural frameworks have been proposed to support digital transformation in industrial environments. Models such as ISA-95, CIM, and RAMI 4.0 provide structured representations of functional and information layers within production systems [3]. Among these, RAMI 4.0 is distinguished by its three-dimensional approach, which integrates automation hierarchy levels, product life cycle stages, and functional layers [4]. This architecture facilitates interoperability and the progressive integration of technologies into existing industrial environments, enabling modular and flexible implementation strategies [5].

Against this backdrop, Industry 4.0 has emerged as a consolidated technological paradigm that integrates advanced and emerging technologies such as the Internet of Things (IoT), cloud computing, artificial intelligence (AI), and cyber-physical systems (CPS). Together, these technologies enable real-time monitoring and control of industrial assets and processes [5,6]. Their adoption supports effective and transparent product and process traceability [7], leading to more efficient and accurate management of production operations, an especially valuable advantage for SMEs seeking cost-effective and practical solutions [8].

One of the most critical challenges in smart manufacturing is achieving effective real-time traceability that supports timely decision-making based on analysis of data generated by production systems [9]. The integration of technologies such as RFID, IoT, blockchain, AI, and cloud computing has been proposed as a potential solution to these challenges [10]. Furthermore, cyber-physical digitalization approaches have demonstrated the ability to develop predictive models for pilot production lines, thereby improving process understanding and optimization [11].

Despite these advances, existing proposals still face significant limitations in terms of scalability and adaptability. Interoperability among heterogeneous systems and the practical complexity of implementation remain major obstacles, particularly for SMEs [12]. Many solutions require robust infrastructure that is not always available in small- or medium-sized industrial settings. In contrast, others focus exclusively on high-level system components without integration with execution-level systems [13].

Several authors have proposed partial solutions to mitigate these challenges. In [4], a flexible architecture is presented to modernize existing systems through modular components; however, this approach relies on a well-established prior infrastructure. The work in [1] proposes an adapted ERP-based approach that enhances process agility, although its integration with shop-floor devices is limited. In contrast, ref. [14] focuses on dynamic simulation to optimize production management and improve internal efficiency, but does not incorporate emerging technologies such as AI or digital traceability. Similarly, ref. [2] explores the use of open-source ERP systems, demonstrating economic feasibility but revealing limitations in analytical capabilities and adaptability to industrial data flows. Specific proposals addressing Manufacturing Execution Systems (MES), such as [15], acknowledge their convergent role but do not address direct integration with AI. In [16], a maturity model is presented as a diagnostic tool, yet without a defined technological roadmap. Meanwhile, ref. [17] proposes process reconstruction using MES and PLC data for simulation purposes, although it lacks an automated decision-making component. The ERP maturity model introduced in [18] enables the identification of implementation levels but does not provide practical automation tools. Additionally, ref. [19] proposes a creative environment for control simulation that is effective in testing scenarios but limited in integration with real systems. Finally, ref. [20] focuses on open automation platforms that are primarily centered on industrial robotics rather than on data-driven decision-making.

In response to these limitations, this study proposes developing an integrated technological model that combines industrial simulation with Factory I/O and control programming in TIA Portal. The control logic is executed via PLCSim and transmitted unidirectionally through NetToPlcSim to Node-RED, where the data are integrated and stored in a PostgreSQL database. On top of this architecture, artificial intelligence techniques are used to analyze collected data in real time, identify patterns, and support decision-making [21,22]. The proposed solution is designed to be modular, cost-effective, and scalable, facilitating its adaptation to real industrial contexts with limited resources.

It is important to note that the primary focus of this study is the processing, storage, and analysis of data specifically related to production-line product traceability, inventory management, replenishment, and order preparation once the data have been transmitted to the cloud. This approach enables the generation of actionable knowledge for both strategic and operational decision-making in distributed ERP systems. Furthermore, this study is conducted within a simulated production environment, a choice driven by methodological and architectural considerations. Industrial simulation is employed as a controlled data-generation layer, as this work forms part of a broader architecture primarily oriented toward information processing, analysis, and exploitation at the cloud and enterprise levels. Consequently, this study emphasizes not the physical behavior of the production process itself, but rather the secure acquisition, transmission, storage, intelligent analysis, and visualization of data to support decision-making in distributed ERP environments.

2. Methodology

This study is structured around two upper functional layers positioned above the production floor and aligned with the RAMI 4.0 reference model criteria. From the intermediate layer, which acts as a bridge between the production environment and the cloud, data are securely routed toward the upper layer (cloud), where production process events are systematically stored and organized.

Leveraging cloud computing, a service-oriented architecture is implemented on the Microsoft Azure (Microsoft Corporation, Redmond, WA, USA) platform, comprising PostgreSQL (PostgreSQL Global Development Group, worldwide community project) for data storage, ChatGPT (OpenAI, San Francisco, CA, USA) for data analytics, and Odoo (Odoo S.A., Brussels, Belgium) as the enterprise resource planning (ERP) system, with a primary focus on traceability and data visualization. Figure 1 provides an overview of the proposed architecture, highlighting key Industry 4.0 technologies that enable scalability and support the digital transformation of a production system from an Industry 3.0 paradigm to an Industry 4.0 framework.

It should also be noted that only the lower layer was designed using software that simulates an industrial production process, and that random events are intentionally generated to ensure the data follow a probabilistic distribution. The information is transmitted via a NetToPLCSim communication driver to the intermediate layer, as shown in Figure 2. Therefore, this study focuses on tracking product movement throughout the supply chain (distribution, machining, storage, and sorting), applying AI-driven data analytics, and analyzing secure interoperability in the proposed architecture.

For a more detailed understanding of the above, this section is divided into five methodological subsections that detail secure industrial data communication in the cloud, industrial data management in a database, the automation of industrial reporting using AI, business management (traceability and visualization) of industrial data in Odoo, and the assessment of cybersecurity risks in the proposed architecture.

2.1. Secure Industrial Data Communication in the Cloud

The next methodological step involved establishing a communication tunnel to transmit data generated in the local environment to a remote cloud-hosted database. In this phase, a set of technological components was implemented from the lower to the upper layers of the architecture: specifically, the flexible information-flow tool Node-RED, the MQTT communication protocol based on publisher/subscriber messaging, and the Mosquitto middleware/broker for message management were integrated. Initially, real-time data from sensors and actuators in the production plant is acquired from the middle layer via the S7comm protocol; using Node-RED and the MQTT protocol, the information is then sent to the Microsoft Azure Node-RED endpoint. To ensure secure information exchange between the endpoints, digital certificates were generated for the broker and clients, and the communication port 8883 was configured in both Mosquitto and Node-RED; thus, data transmission uses the Transport Layer Security (TLS) 1.2 protocol.

Once security has been established for the connection between the middle and upper layers, data is transmitted from the local environment to the virtual machine (VM) in Microsoft Azure. In this way, the endpoint nodes handle the publishing/subscribing and transport of each event captured along the production line (part transport time between stations and processing at each station).

This messaging solution was chosen for its lightweight nature, simplicity, low bandwidth consumption, and ability to operate in environments with distributed and resource-constrained devices. It is worth noting that although MQTT does not provide native semantics, in this case study, Mosquitto successfully structures messages in real time and maintains interoperability suitable for the developed IIoT architecture. In this way, manufacturing time data is stored in the cloud to provide a secure and reliable traceability system.

2.2. Traceability Recording and Data Storage

Once the data was successfully transmitted to the cloud environment, the next step was to organize the information for reliable, efficient future retrieval. Since the production data transmitted to the cloud comes from multiple sensors, it is identified by its structure in MQTT topics, which enables the orderly publication and subscription of the data. Additionally, a PostgreSQL database was configured as a storage service within the same VM. This centralized implementation strategy facilitated system access, administration, and maintenance, as illustrated in Figure 3.

In PostgreSQL, the traceability records were organized into a table named “factory_io_event,” designed specifically to capture events generated throughout the parts manufacturing process. Each row in the table stores and normalizes MQTT structure information such as the sensor ID, the type of production plant station, the color of the detected part, the date and time of detection, the time it takes for a part to be transported from station to station, and the time a part spends at each station. This method of structuring the information facilitates the extraction and querying of organized data for integration with other services such as ChatGPT and Odoo. In this context, the PostgreSQL graphical management tool pgAdmin4 is used to visualize and verify the stored data, enabling the systematic monitoring and inspection of production process variables.

This stage established the core of the traceability system by ensuring that all production events were stored persistently in a structured and accessible format. This setup enables subsequent automated data analysis and seamless integration with external tools, including artificial intelligence scripts for advanced data processing and decision-making support.

2.3. Automatic Report Generation Using Artificial Intelligence

Once the data has been stored in the cloud instance, it is a priority for corporate administrative departments to conduct a critical, comprehensive analysis of historical data recorded as production variables, which will serve as a dataset for decision-making in maintenance, production, and management processes. To this end, an automated workflow was designed using artificial intelligence techniques to retrieve specific information and generate different types of reports tailored to each business area. Meanwhile, on a server located on the company’s local network, a Python 3.13.2 script runs, acting as a bridge between the database and the AI model; that is, from an HTML server, a user logs in as a maintenance manager, production manager, or CEO, allowing instructions to be executed sequentially to access PostgreSQL, extract all the information stored in a variable in text format, and then send it along with a specific prompt to an OpenAI language model. ChatGPT, thereby generating a .pdf report; using a ChatGPT API and the Python script, this report is sent to an email address specific to the recipient’s role. Figure 4 shows a diagram of the workflow that encompasses the interaction between two services integrated into the Microsoft Azure instance, as well as an example prompt for the maintenance manager role.

This type of query for AI-assisted reporting enables more useful, accurate, and role-specific responses, allowing for data selection based on specific time frames or a predefined number of recorded events.

This methodology allows supervisors or managers to obtain a concise yet detailed overview of production status without directly accessing the system or manually inspecting the database. Additionally, a lightweight HTML interface was developed to serve as a control panel. The goal is to streamline information sharing and facilitate timely, data-driven decision-making.

To ensure the process runs automatically, a third script was developed to sequentially coordinate the aforementioned tasks.

This AI-driven process effectively closes the loop between industrial data collection and the generation of actionable insights, as shown in Figure 5: The Production Report, in which ChatGPT provides details such as an executive summary, a count of processed parts, an efficiency analysis, and recommendations. Through the proposed automated workflow, technical production data is transformed into comprehensive, structured reports, which are sent directly to decision-makers who need quick, well-founded information to support their operational and strategic actions.

2.4. Integration with the ERP System Using Odoo

Once the traceability system and the automated reporting workflow are established, the next step is to connect this information to an ERP platform that centralizes data and provides a more structured view for business management. To this end, Odoo was chosen for its open-source nature, intuitive user interface, and support for PostgreSQL as the backend. This means that when new data is stored, Odoo automatically generates queries to PostgreSQL via a pull connection and manages these transactions securely through rollback in the event of a failed operation. In this way, and for this case study, the proposed architecture is completed by transmitting information from a production plant to a remote instance, storing it, organizing it, and linking it with artificial intelligence and business intelligence services for decision-making. These aspects undoubtedly serve as the foundation for the digital transformation of MSMEs’ business development.

The ERP modules were configured to display relevant information, including inventory, product quality control, and production. Within these modules, dashboards were developed to show the number of parts recorded, the operational status of each production station, and comparative analyses between stored inventory and production demands. To improve the user experience, a custom HTML interface was implemented to display visualizations generated from ERP data. These visual elements were integrated directly into the Odoo dashboard, providing a more accessible presentation layer for users without advanced technical knowledge of database management.

Figure 6 shows an example of this integration and the visualization of traceability indicators, presenting the dashboard developed for system monitoring and analysis. This approach allows executive-level users to directly access key performance indicators, which facilitates agile, data-driven decision-making.

2.5. System Security Evaluation

Given that the proposed architecture integrates multiple industrial and information technology components, including process simulation, industrial communication, cloud services, databases, ERP systems, and automatic report generation using artificial intelligence, a systematic evaluation of the cybersecurity risks associated with the developed system was conducted. This evaluation followed a qualitative–quantitative risk analysis approach based on a matrix model, considering core information security principles applicable to distributed industrial environments, namely confidentiality, integrity, and availability (CIA).

The selection of this approach was motivated by the need for a structured yet scalable assessment framework that integrates measurable factors such as likelihood and impact with contextual asset criticality, enabling effective risk prioritization in complex distributed systems. Compared to fully quantitative probabilistic models or formal penetration testing methodologies, the adopted approach offers a more practical and reproducible evaluation strategy under controlled experimental conditions, without requiring a fully deployed physical infrastructure or extensive testing resources.

The analysis addressed both technical and operational threats, including configuration errors, service exposure, vulnerabilities in industrial communication protocols, and risks arising from the use of external services. Although controlled testing scenarios were conducted to emulate representative threat conditions, it is important to acknowledge that the cybersecurity assessment remains partially grounded in a theoretical risk-modeling framework rather than in exhaustive penetration testing. Therefore, the results should be interpreted as a structured evaluation of system exposure and mitigation effectiveness within the defined experimental scope.

For each critical system asset such as the NetToPLCSim communication bridge, the Node-RED environment, the MQTT broker, the Azure cloud infrastructure, the PostgreSQL database, the Odoo ERP system, and the artificial intelligence modules key threats, associated vulnerabilities, and their potential impact on system operations were systematically identified and assessed.

Risk levels were calculated using a risk matrix based on the weighted evaluation of three factors: asset criticality, likelihood of occurrence, and impact severity. This process resulted in an inherent risk value, enabling classification into low-, moderate-, or high-risk categories. Subsequently, appropriate technical and organizational security controls were defined and implemented to estimate the residual risk after mitigating the identified vulnerabilities. This evaluation not only facilitated the identification of critical security points within the system but also validated the robustness of the proposed architecture against realistic attack scenarios, ensuring alignment with cybersecurity best practices in Industry 4.0 environments.

3. Results

The results presented in this section focused on the developed architecture, which encompasses communication between the lower, middle, and upper layers. Therefore, the metrics presented should be interpreted as indicative of the feasibility and operational consistency of the proposed solution within the defined experimental framework. It is important to note that only the lower layer, corresponding to the production plant, was simulated; however, the production line parameters were intentionally modified, including decreasing and increasing conveyor belt speeds, forcibly activating sensors and actuators, and randomizing the production parts (good and defective). This preserved information regarding the non-ideal production processes. To meet the aforementioned parameters, a Dell G15 5530 laptop, equipped with a 13th-generation Intel Core i7-13652HX processor, 16 GB of RAM, and an NVIDIA GeForce RTX 4060 graphics card, was used as the local workstation.

To evaluate the performance of the implemented traceability system, a series of experimental tests was designed to quantify the data transmission time from each station in the simulated production process to the remote database hosted on the virtual machine. These measurements were performed over 70 consecutive runs per station, accounting for both input and output events generated by the virtual sensors. All experiments were conducted on a 5 GHz Wi-Fi network with a download speed of 198.67 Mbps, an upload speed of 187.13 Mbps, an idle ping of 15 ms, a download ping of 58 ms, and an upload ping of 60 ms. These connectivity conditions serve as a reference for recording results from experimental latency tests across the different layers of the architecture.

Because the lower and middle layers are located on the same local server, fast acyclic communication is observed. Meanwhile, transmission latencies between the middle and upper layers are recorded by taking timestamps at two stages of the communication process. The first timestamp is recorded when the local Node-RED instance captures the event generated at the production facility, and the second timestamp is recorded when the event is successfully stored in the PostgreSQL database in the cloud environment. The transmission latency between the production facility and the cloud is calculated as the difference between these two timestamps. The results obtained indicate that the average latency in information transmission remains approximately below 200 ms, which is within the acceptable limits defined by the IEC61784 industrial communication protocols used for non-deterministic monitoring times.

Figure 7 presents the average latency results for data transmission from the production-line workstations to the cloud instance, calculated over 150 test iterations. Additionally, network behavior is shown by illustrating lost packets during transmission, allowing evaluation of both system efficiency and reliability.

The results indicate that, on average, the distribution station had a data transmission time of 194.59 ms, followed by the machining station at 208.97 ms, the sorting station at 197.6 ms, and the storage station at 198 ms. These values confirm the system’s ability to maintain latency levels below 200 ms, a threshold generally considered acceptable for real-time monitoring control panels in non-critical industrial environments. This tolerance is supported by studies such as [23], which demonstrate that IIoT architectures based on MQTT and low-cost industrial devices can achieve round-trip latencies of 300 ms or less, with a standard deviation of approximately 20 ms, while maintaining functionality under real-world operating conditions.

According to the analysis of the interconnections between the different layers that make up the architecture, during experimental testing, transmission data losses were observed, with 1.3% of the total PostgreSQL transmissions for the storage station and 0.66% for the distribution and machining stations. While this percentage does not compromise the overall operation of the system, it reveals opportunities to improve the reliability of the communication link between the middle and upper layers. However, no data loss was recorded between the lower and middle layers.

As mentioned in previous sections, to develop the experimental tests, a Python script was used to create three roles representing different business management areas. In this case, the interoperability of the proposed architecture was verified by generating corporate reports for maintenance, production, and executive roles. For this test, 10 request attempts were made to generate reports for each role, and responses were verified via email. The tests performed reflected internet quality of service (QoS), verifying that the operating parameters, such as latency, jitter, packet loss, and bandwidth, were within the normal values provided by the internet service provider.

Table 1. Latency and verification of the Python/PostgreSQL/Python/ChatGPT/Python/Email communication architecture.

Average Latency	4–6 [s]
Roles	Request Report	Verification via Email
Maintenance Manager	10	10
Production Manager	10	10
Chief Executive Officer	10	10

shows the average latency during the experimental tests, the number of report request attempts by role, and the validation of the responses.

In a cognitive computing application, latency results in seconds are acceptable because the requests fall within the scope of monitoring and analytics applications. Extra time is considered in the communication architecture due to AI processing, but this does not compromise the production line process. Furthermore, the proposed architecture demonstrates reliability with 100% verifiable reports in emails sent to all three roles.

Because the local workstation runs several concurrent processes, it enables real-time monitoring of the production process and multi-layered client/server communication via middleware (Python ↔ PostgreSQL ↔ Python ↔ ChatGPT ↔ Python ↔ email). Figure 8 shows the average utilization values of the main local workstation resources during the execution of these processes. The results indicate that the processor load remained at an average of close to 23%, demonstrating that the control, communication, and modeling tasks did not saturate the available processing capacity.

Given that the communication latency between the lower layer and PostgreSQL is less than 200 ms, experimental tests also assume that communication between Odoo and PostgreSQL is deterministic and low-latency. That response time depends on query complexity and data volume. However, for this case study, latency is typically maintained between 1 and 100 ms.

In addition to performance and latency evaluation, a security assessment was conducted to identify and analyze the risks associated with the proposed distributed architecture, considering the different layers of industrial communication, local processing, and cloud services involved in the solution. A systematic risk and vulnerability identification process was carried out, and the results are summarized in

Table 2. Identification of system risks, vulnerabilities, and potential impact.

Risk Name	Risk Description	Vulnerability	Potential Impact
Exposure of the NetToPLCSim Communication Bridge	Interception or Manipulation of S7 Industrial Variables	The S7comm protocol lacks native encryption mechanisms	Process manipulation, data injection, and man-in-the-middle (MITM) attacks
Security Vulnerabilities in the Local Node-RED Environment	Execution of Unauthorized Automation Flows	Node-RED does not enforce authentication by default	Malware injection, unauthorized data access, and compromise of TLS keys
Exposure of MQTT/S7 Ports to the Local Network	Local attackers may subscribe to or publish malicious MQTT messages	MQTT traffic can be intercepted without TLS encryption	Traceability data corruption and loss of data integrity
Insecure Firewall Configuration in Azure Infrastructure	Unrestricted port exposure (e.g., 0.0.0.0/0)	Any external IP address may attempt to establish a connection	Brute-force attacks, denial-of-service, and system intrusion
Improperly Configured TLS Certificates	Failure in server–client authentication mechanisms	Improper generation or management of self-signed certificates	MQTT data leakage via MITM attacks
MQTT Broker Saturation in the Cloud Environment	Denial-of-Service (DoS) or topic-spamming attacks	_______	Interruption of industrial data flows.
Unauthorized Access to the PostgreSQL Database	Theft or deletion of traceability data	SQL credentials stored in plaintext within scripts	Complete loss of historical traceability information
Privilege Escalation Due to Misconfigured Access Roles	Unauthorized data access by ERP users	_______	Compromise of system integrity and trustworthiness
Unrestricted Use of the OpenAI API	Accidental leakage of sensitive data or API tokens	API keys exposed directly in source code	Unauthorized consumption or exposure of generated reports
Email-Based Report Delivery—Phishing or Spoofing Risk	Impersonation attacks and delivery of fraudulent reports	SMTP services configured with weak authentication	Manipulation of strategic and operational information
Prompt Manipulation Attacks	Prompt injection is affecting automated report generation.	_______	Generation of falsified or malicious reports
Vulnerabilities in the PostgreSQL Connection Module	Unauthorized data access via database connectors	Credentials stored in unsecured configuration files	Leakage of traceability-related data
Service Interruption Due to Azure Credit Limitations	Complete system downtime	_______	Operational breakdown resulting in loss of traceability
Service Outage of the OpenAI Platform	Disruption of automated report generation	_______	Degraded decision-making capability
Misconfiguration Errors in Node-RED/MQTT Services	Data routing toward incorrect MQTT topics	_______	Database corruption
Poor Certificate and Credential Management	Use of weak, shared, or compromised credentials	_______	Unauthorized access to cloud infrastructure
Physical Damage to the Host Machine (Single Point of Failure)	Total system loss due to reliance on a single host machine	_______	Absence of redundancy or local backup mechanisms

. This analysis examined the main components of the system including the NetToPLCSim communication bridge, Node-RED workflows, the MQTT broker, the Azure cloud infrastructure, the PostgreSQL database, the Odoo ERP system, and the artificial intelligence–based automatic report generation modules identifying potential threats such as data interception, manipulation of industrial variables, unauthorized access, configuration errors, denial-of-service attacks, and credential exposure. Furthermore, the potential impact of each risk on the integrity of traceability, operational continuity, and managerial decision-making was assessed.

Following the identification of system risks, each scenario outlined in Table 2 was systematically evaluated through controlled testing procedures to assess its impact on the integrity, availability, and operational stability of the proposed architecture. These evaluations were conducted by emulating representative threat conditions for each identified risk, thereby characterizing their criticality within the system context.

Subsequently, a set of security controls aligned with the identified vulnerabilities was implemented across the different architectural layers, including communication hardening, access control enforcement, secure configuration practices, and credential management mechanisms. After deploying these controls, the testing procedures were repeated under equivalent conditions to assess the effectiveness of the mitigation strategies.

The outcomes of this process are reflected in the transition from inherent to residual risk levels, as presented in

Table 3. Inherent risk assessment of system assets.

Asset	Threat/Vulnerability	Asset Criticality	Likelihood of Occurrence	Impact Severity	Inherent Risk	Risk Level
NetToPLCSim Communication Bridge	Unencrypted S7 Communication Interception	10	3	3	90	High
Local Node-RED Runtime Environment	Execution of Unauthorized Automation Flows	10	2	3	60	High
Local MQTT Communication Layer	MQTT Traffic Sniffing/Injection of Malicious Messages	10	3	3	90	High
Cloud-Based MQTT Broker (Azure)	Denial-of-Service (DoS) Attacks via Topic Saturation	5	2	2	20	Moderate
PostgreSQL Database Management System	Unauthorized Access to Traceability Data	10	2	3	60	High
SQL Injection Attack Surface	Malicious Data Manipulation or Tampering	10	1	3	30	Moderate
Python-Based AI Processing Scripts	Exposure of API Keys or Authentication Tokens	10	2	3	60	High
Automated Email Delivery Service	Identity Spoofing Attacks	5	2	2	20	Moderate
Odoo Enterprise Resource Planning (ERP) System	Unauthorized Web Interface Access	10	2	3	60	High
Embedded HTML-Based Dashboard Interface	Cross-Site Scripting (XSS) Attacks	5	2	2	20	Moderate
Azure Cloud Infrastructure	Cloud Credit Exhaustion	5	3	2	30	Moderate
OpenAI API Service	Service Interruption or Outage	5	2	1	10	Low
TLS Certificates and Key Management	Use of Weak or Shared Credentials	10	2	3	60	High
Central Host Machine (System Core/Single Point of Failure)	Physical Damage or Theft of System Hardware	5	1	3	15	Moderate

and

Table 4. Residual risk assessment following the implementation of security controls.

Asset	Threat/Vulnerability	Implemented Security Controls	Asset Criticality	Likelihood of Occurrence	Impact Severity	Inherent Risk	Risk Level
NetToPLCSim Communication Bridge	Unencrypted S7 Communication Interception	Site-to-Site VPN Architecture with VLAN Segmentation and Stateful Firewall Enforcement	10	1	1	10	Moderate
Local Node-RED Runtime Environment	Execution of Unauthorized Automation Flows	Strong User Authentication Combined with Port Hardening and Service Lockdown	10	1	2	20	Moderate
Local MQTT Communication Layer	MQTT Traffic Sniffing/Injection of Malicious Messages	Transport Layer Security (TLS) Encryption with Certificate-Based Mutual Authentication	10	1	2	20	Moderate
Cloud-Based MQTT Broker (Azure)	Denial-of-Service (DoS) Attacks via Topic Saturation	Anti-Spam Filtering, Rate Limiting, and Continuous Traffic Monitoring	5	1	2	10	Low
PostgreSQL Database Management System	Unauthorized Access to Traceability Data	Strong Authentication, Role-Based SQL Access, and Encrypted Data Storage	10	1	2	20	Moderate
SQL Injection Attack Surface	Malicious Data Manipulation or Tampering	Prepared Statements and Robust Input Validation to Prevent Injection Attacks	10	1	2	20	Moderate
Python-Based AI Processing Scripts	Exposure of API Keys or Authentication Tokens	Centralized Secrets Vault with Encrypted Environment Variables	10	1	2	20	Moderate
Automated Email Delivery Service	Identity Spoofing Attacks	OAuth 2.0 Authentication with Email Security Policies (SPF, DKIM, and DMARC Records)	5	1	1	5	Low
Odoo Enterprise Resource Planning (ERP) System	Unauthorized Web Interface Access	HTTPS-Based Secure Access with Multifactor Authentication (2FA) and RBAC Policies	10	1	2	20	Moderate
Embedded HTML-Based Dashboard Interface	Cross-Site Scripting (XSS) Attacks	Content Security Policy (CSP) Enforcement and CSRF Token Protection	5	1	1	5	Low
Azure Cloud Infrastructure	Cloud Credit Exhaustion	Consumption Alerts and Elastic Autoscaling Strategies in Cloud Infrastructure	5	1	1	5	Low
OpenAI API Service	Service Interruption or Outage	Manual and Automated Backup Strategies	5	1	1	5	Low
TLS Certificates and Key Management	Use of Weak or Shared Credentials	Enterprise-Grade PKI with Automated Certificate Rotation	10	1	2	20	Moderate
Central Host Machine (System Core/Single Point of Failure)	Physical Damage or Theft of System Hardware	Redundant Backup Systems, Uninterruptible Power Supply (UPS), and Remote Replication	5	1	2	10	Low

, providing a comparative assessment of the system’s security posture before and after the implementation of the proposed controls.

Based on the previously identified risks, the system’s inherent risk was subsequently assessed. In this context, inherent risk is defined as the level of risk present before the implementation of any security controls, establishing a baseline that enables accurate assessment of each asset’s actual criticality within the proposed architecture. This evaluation, summarized in Table 3, was conducted using a quantitative risk analysis model based on three fundamental factors: asset criticality, the likelihood of a threat occurring, and the potential impact. These factors were weighted using predefined discrete scales.

Asset criticality was categorized into three levels. A value of 10 was assigned to assets of very high importance, corresponding to components whose compromise or unavailability would directly and critically affect the overall system operation. A value of 5 represented medium importance, associated with assets that influence key processes without causing a complete system collapse. A value of 1 indicated low importance, corresponding to assets whose impact is localized and readily manageable.

Similarly, the likelihood of threat occurrence was estimated based on the system’s operational context. A value of 3 was assigned to highly probable scenarios, in which the threat occurs frequently or has already been observed; a value of 2 to probable scenarios, where occurrence is feasible; and a value of 1 to unlikely scenarios, characterized by low frequency and exceptional conditions.

Complementarily, impact severity was classified according to its operational consequences, assigning a value of 3 to high-impact scenarios capable of halting operations or generating critical losses, a value of 2 to medium-impact scenarios that degrade system performance, and a value of 1 to low-impact scenarios associated with minor effects that can be easily mitigated.

The inherent risk was calculated as the product of asset criticality, likelihood, and impact, a methodology widely adopted in risk assessment for its ability to reflect the relative criticality of each evaluated scenario. Based on the resulting score, risks were classified into three levels: low risk for scores between 1 and 10, medium risk for scores between 11 and 30, and high risk for scores between 31 and 90, thereby enabling objective prioritization of the most exposed assets.

The results reveal that components associated with industrial communication and data exchange such as the NetToPLCSim communication bridge, the MQTT broker, and access to the PostgreSQL database exhibit the highest inherent risk levels. This behavior is primarily attributed to the use of industrial protocols that lack native encryption, the exposure of critical services in networked environments, and the sensitivity of the managed traceability data. These findings justify applying specific security controls to these elements in subsequent stages of the analysis.

Subsequently, a set of technical and organizational security controls was implemented with the objective of systematically mitigating the risks identified during the inherent risk assessment. These measures included the adoption of transport-layer cryptographic mechanisms using TLS, strong authentication schemes based on digital certificates, logical network segmentation, role-based access control (RBAC) policies, service hardening procedures for exposed components, secure credential protection and management mechanisms, as well as application-level validations aimed at preventing malicious data manipulation.

As a direct consequence of applying these controls, a subsequent system evaluation was conducted to determine the residual risk. The results of this assessment are presented in Table 4, enabling quantitative measurement of the effectiveness of the implemented security controls and clearly demonstrating the reduction in the system’s overall exposure level.

The obtained results demonstrate a significant reduction in the overall risk level for the majority of the analyzed assets, with a predominant transition from high or moderate risk levels to low or controlled moderate levels. This reduction confirms the effectiveness of the implemented security measures and demonstrates that the proposed architecture exhibits robust behavior when exposed to realistic threat scenarios, even within a distributed environment that integrates industrial technologies, cloud services, and artificial intelligence modules. Taken as a whole, the security assessment complements the system performance results by providing a comprehensive perspective that considers not only efficiency and latency but also reliability, resilience, and feasibility for future deployment in real industrial environments, where cybersecurity is a critical factor in the adoption of Industry 4.0-based solutions.

Overall, these results demonstrate that the proposed architecture is not only functional and stable, but also efficient in terms of computational resource consumption. Its ability to operate under distributed workloads without processing collapses or memory and network saturation reinforces its viability for real-time traceability applications. This provides solid guarantees for subsequent scaling and integration into physical production environments, where operational continuity is critical.

4. Discussion

In the cited literature, product traceability and data transmission security are addressed as relevant topics, although they are generally treated as separate issues. Some studies focus exclusively on tracking mechanisms throughout the product lifecycle, while others prioritize the secure transmission of information using encrypted communication protocols. In contrast, this work integrates both approaches in a unified, real-time manner, from a production plant to a cloud instance hosted on Microsoft Azure and equipped with various services such as a database, ERP, and cognitive computing. This integration guarantees data confidentiality and integrity throughout the traceability process.

One of the most significant challenges during system development was establishing a secure and stable communication channel between the local environment and the cloud infrastructure. While the MQTT protocol is highly efficient for data transmission, its secure configuration using TLS introduces stringent authentication requirements. In this context, the use of generic certificates proved insufficient, as the Mosquitto broker requires valid and properly signed certificates. This necessitated generating certificates on both the server and client sides, including their corresponding private keys. These challenges highlight the critical importance of cybersecurity considerations in IIoT systems.

Furthermore, PostgreSQL was selected due to its robustness and compatibility with the proposed architecture, and it demonstrated adequate performance in experimental tests. Measured data transmission times remained within acceptable limits per the IEC61784 communication protocol for monitoring and analytics processes, with latency below 300 ms.

The delivery of emails generated by the integrated artificial intelligence module was also limited by email service providers’ security policies, which require advanced authentication mechanisms to prevent unauthorized message transmission. The service implements a two-layer security verification process that requires generating an application-specific key to authorize access by automated or third-party systems. Furthermore, it was verified that the proposed communication architecture, Python ↔ PostgreSQL ↔ Python ↔ ChatGPT ↔ Python ↔ email, is reliable and achieves its expected response times when cognitive computing is integrated. However, the computational performance of Python scripts is low; consequently, it is possible to run lightweight algorithms on microprocessors, which is suitable for companies with limited resources seeking digital transformation.

Regarding data transmission security, additional difficulties arose from the configuration of the Microsoft Azure virtual machine, particularly concerning inbound and outbound firewall rules. These rules regulate network traffic based on source and destination IP addresses, which can complicate communication configuration. While allowing connections from any IP address (0.0.0.0/0) simplifies connectivity, it represents a significant security vulnerability. Consequently, it is essential to ensure that MQTT traffic is allowed only through the appropriate ports without compromising system integrity. Complexity increased due to the permissions required for Odoo to establish a proper connection to the PostgreSQL database, which required precise definitions of roles, credentials, and access privileges at the database level. However, for the level of system criticality addressed in this work, PostgreSQL provides a suitable solution for data storage and management. Furthermore, it offers native communication with Odoo, facilitating efficient query execution.

From a continuous improvement perspective, it is essential to strengthen the cybersecurity architecture through advanced monitoring, detection, and response mechanisms. Although current controls mitigate residual risk, integrating IDS/IPS systems and log correlation would enhance protection against persistent threats. Likewise, identity and trust management must evolve toward scalability through centralized services, automated credential rotation, and strict application of the principle of least privilege. Finally, adopting a Zero Trust model would consolidate security between nodes by eliminating any presumption of implicit trust within the internal network.

The results validate interoperability across multiple layers and the integration of different services to digitally transform an industry from Industry 3.0 to Industry 4.0. However, the communication protocol between the middle and upper layers is MQTT over a Mosquitto broker, where the structure of the transmitted data depends primarily on the programmer, which is inefficient and causes delays in implementation. The proposed solution is to make the implemented IIoT system more robust and efficient in data transmission, that is, to align it even more closely with the RAMI reference, by replacing the Mosquitto broker with one that guarantees the semantic integrity of transmission packets, as Sparkplug does.

5. Conclusions

The three-layer distributed architecture, based on the RAMI 4.0 framework and integrated with current technological tools, proved to be a viable and efficient solution for scaling from Industry 3.0 to Industry 4.0, while also integrating a product traceability system on the production line. The implemented architecture demonstrated reliable interoperability in tests involving multi-layer communication and with cloud services such as the database, Odoo, and cognitive computing.

Given the confidential nature of the information, establishing an MQTT communication protocol between the middle and upper layers was necessary and, in accordance with the framework’s IIoT infrastructure security criteria, required implementing a security system for data transmission and authentication in cloud computing services. In this case study, the system was certified to the TLS 1.2 standard, and usernames and passwords were generated for Odoo and for report requests. The implemented architecture ensured data protection and system integrity by incorporating encryption mechanisms for data transmission, access control, and authentication for cloud services. The results demonstrate that these controls effectively mitigate the risks associated with service exposure, inter-layer communication, and data management in IIoT environments. Although the validation was performed in a controlled environment, the proposed solution exhibits robust behavior against common threat scenarios, providing a reliable foundation for implementation in real-world industrial environments.

According to international standards for industrial communication in monitoring and analytics systems, latency should be less than 300 ms. The developed architecture achieved a remarkable average latency of 200 ms between the lower and upper communication layers. Furthermore, the importance of using native services like PostgreSQL and Odoo for low-latency communication is highlighted.

Similarly, the reliability of the report request system is emphasized. This system features a Python ↔ PostgreSQL ↔ Python ↔ ChatGPT ↔ Python ↔ email communication architecture, demonstrating 100% report validation via email. While the latency is between 4 and 6 s, this is not due to the architecture itself, but rather to cognitive computing as a service. It is also noted that the computational performance of this process was reduced, enabling the potential implementation of this system on microcontrollers with lightweight algorithms.

It is important to clarify that only the lower layer was modeled; the middle and upper layers were implemented, as mentioned in previous sections. To have a production plant with variable data, acceleration parameters in conveyors were intentionally modified, parts were randomly arranged, and different characteristics of the production batch were established to identify parts in good and bad condition.