A Hybrid and Modular Integration Concept for Anomaly Detection in Industrial Control Systems

Abstract

Effective anomaly detection is essential for realizing modern and secure industrial control systems. However, the direct integration of anomaly detection within such a system is complex due to the wide variety of hardware used, different communication protocols, and given industrial requirements. Many components of an industrial control system allow direct integration, while others are designed as closed systems or do not have the required performance. At the same time, the effective usage of available resources and the sustainable use of energy are more important than ever for modern industry. Therefore, in this paper, we present a modular and hybrid concept that enables the integration of efficient and effective anomaly detection while optimising the use of available resources under consideration of industrial requirements. Because of the modular and hybrid properties, many functionalities can be outsourced to the respective devices, and at the same time, additional hardware can be integrated where required. The resulting flexibility allows the seamless integration of complete anomaly detection into existing and legacy systems without the need for expensive centralised or cloud-based solutions. Through a detailed evaluation within an industrial unit, we demonstrate the performance and versatility of our concept.

1. Introduction

An industrial control system (ICS) can be described as a combination of hardware and software connected by different networks, focusing on controlling an underlying industrial physical process [1]. In an ICS, various control systems, such as supervisory control and data acquisition (SCADA) systems, remote terminal units, and programmable logic controllers (PLCs), are combined with sensors and actuators [2].

In order to meet the growing requirements and to realize the complex processes of modern industry, the integration of industrial Internet of Things (IOT) and cyber–physical systems (CPSs) within an ICS is also increasing [3]. These usually high-performing and highly networked devices enable an extensive exchange of data within the system [4]. The ongoing development of individual subcomponents of the ICS enhances the potential for integrating advanced functionality, including comprehensive anomaly detection (AD), data collection in real-time, an independent adaptation of the process, or rapid reaction to changing requirements and environmental parameters [5].

As processes become increasingly complex and the dependency of the entire production on individual sub-processes rises, implementing effective error detection mechanisms becomes important [6]. Individual errors can impact the entire system, leading to faulty processes, a breakdown of the entire system, or potential risks to people. One possibility to identify such errors and enable early response is through AD in the physical process of the ICS [7]. In an ICS, anomalies can be defined as all deviations from a predefined, intended normal process [8]. Integrating effective AD allows for monitoring of the entire system, detecting anomalies, and ideally responding immediately to potential errors to prevent or mitigate them. Therefore, integrating an effective AD is crucial for achieving modern and secure ICSs [9].

At the same time, integrating AD in an ICS poses enormous challenges. While the underlying physical process is highly complex, each ICS differs in structure and has a high variance of used hardware and software. Furthermore, individual components of the system are usually limited in terms of memory capacity and processing performance [10].

Considering these aspects, a centralized integration approach for AD is usually chosen. All available data are transmitted to a centralized processing unit, such as a cloud server, where the data are processed, and the results are then sent back to the devices. Although this approach addresses the previously mentioned challenges, it also presents several significant drawbacks. These include the additional costs associated with establishing a centralized high-performance computing unit, difficulties in transmitting the large volumes of data generated by the various devices in the ICS [11], concerns about data security during the collection, transmission, and external storage of process data [12], and increased response times due to communication delays during transmission [13].

Due to the current global situation, the shortage of resources, and rising energy prices, as well as advancing developments within ICSs, decentralized approaches are becoming increasingly important [14]. In a decentralized concept, all necessary functionalities are distributed across the available subcomponents. This structure offers several advantages, including reduced cost and energy consumption, as it eliminates the need for a central computing unit and minimizes the required infrastructure. Processing data directly on the respective device helps lower data transmission, latency, and response time [15]. Data security and knowledge protection can be ensured since all generated data are processed and stored within the system rather than transferred to a central or external location.

Although decentralized integration offers several benefits, it requires more implementation effort. For example, AD techniques must be adapted to the performance capabilities of individual devices, communication between sub-devices must be established, and structural limitations must be considered [16]. Additionally, realizing the direct integration of AD for every device within an ICS is often impossible. In particular, legacy systems tend to include a higher number of devices that are either designed as closed systems or lack the resources necessary for direct integration.

In order to ensure the optimum utilization of all available resources and enable complete and effective AD, even for older or closed systems, we present a hybrid and modular integration concept. We organize the various functionalities required for implementing AD into separate modules, establish unified communication, and integrate them into the different devices available in the ICS. While our primary focus is on achieving decentralization, if this is not feasible, functions can be outsourced to adjacent devices, or additional high-performance, cost-effective single-board computers (SBCs) can be implemented. Therefore, in this concept, the term "hybrid" refers to the ability of the integration to enable both decentralized and centralized implementation options. For instance, certain functionalities can be combined and executed at a central location, while others can be simultaneously distributed across multiple devices.

The contributions of this article can be summarized as follows:

• We provide a detailed specification of the real-world challenges and resulting requirements that arise from integrating a hybrid anomaly detection in an ICS.
• We introduce a novel hybrid and modular integration concept for AD in ICSs and outline the individual modules, their functionalities, and the integration process.
• We demonstrate the effectiveness of our approach through a comprehensive evaluation of a proof-of-concept implementation against the predefined requirements.
• We show that achieving high-performing, secure, and efficient anomaly detection is feasible even for resource-constrained legacy ICSs while maximizing the utilization of all available resources.

In this work, we focus on the modular and hybrid concept, its realization, and its integration into an ICS. To remain within the scope of the work, we briefly discuss the AD method but do not describe detailed tests and analyses of the detection performance. A comprehensive evaluation of the various methods for AD, including detailed tests and comparisons, can be found in our previous work in [8].

The remainder of this paper is structured as follows: Section 2 provides an analysis and discussion of related work. Requirements and challenges are outlined in Section 3. Section 4 includes a detailed description of the concept and the individual modules. The prototypical implementation is explained in Section 5. In Section 6, the evaluation based on an experimental integration is described. Finally, Section 7 offers a summary and an outlook for future work.

2. Related Work

Surveys of different AD technologies for ICSs can be found in [17,18,19]. AD methods for ICSs can be distinguished into two areas based on the information used to detect anomalies. The first area uses network-level data, such as network data packets, whereas the second area identifies anomalies based on the underlying physical process of the ICS. While the former is mainly designed to detect external intrusions like cyber-attacks [20], the latter identifies all deviations from the regular intended system operation, which can be caused by a cyber-attack, production process errors, or changes in system characteristics, like the wear of mechanical components [21]. Based on this and the attempted direct integration within the individual devices of the ICS, the subsequent focus will be on identifying anomalies based on the underlying physical process of the ICS.

The literature contains various promising AD implementations for ICSs. In [22], 1D convolutional neural networks (CNNs) are used to detect cyber-attacks on a water treatment plant. The authors emphasize that 1D CNNs are structurally simpler, smaller, and faster than comparable recurrent neural networks (RNNs) when used for time series data, which enables integration into low-power devices. The authors of [23] propose an AD method for ICSs based on a long short-term memory (LSTM) autoencoder. They achieve high detection performance on an ICS dataset by reconstructing current data and predicting future values simultaneously. Ref. [24] introduces a dual attention network in which temporal causality is used to learn the causal relationships between device components to detect anomalies in multivariate time series data of the ICS.

Several studies about hybrid and decentralized approaches for AD in ICSs can be found. In [25], an AD method for ICSs based on a variational autoencoder (VAE) is presented. The individual models are trained by combining all sub-devices and a higher-level cloud server. The method is characterized by its low hardware requirements, fast training time, and high detection rate. A study on detecting anomalies in underground mining was conducted in [26], where the AD algorithm was distributed among the different edge devices to address the issue of insufficient available computing power. The experimental results show that the presented algorithm outperforms comparable algorithms, such as K-means and C-means, even with more devices. The authors of [27] demonstrate that performing distributed AD on individual edge devices can achieve results similar to centralized AD while significantly reducing data traffic. A similar approach based on sensing time series data from IoT edge devices is presented in [28], where the authors also show that distributed AD on individual edge devices can perform just as well as centralized AD.

Resource-efficient approaches and engines are required to effectively process the data streams produced by individual devices. In [29], the authors compare three data streaming engines for performance in resource-constrained devices. Apache Spark (https://spark.apache.org/, accessed 24 November 2024) and Apache Flink (https://flink.apache.org/, accessed 24 November 2024) emerged as the top performers for such applications. Another popular open-source distributed streaming platform is Apache Kafka (https://kafka.apache.org/, accessed 24 November 2024), which offers high scalability, fault tolerance, and real-time data exchange [30,31]. In [32], the authors conduct a comprehensive study of Apache Kafka and demonstrate its ability to handle large amounts of data, while being scalable and high-performing.

Different available studies about hybrid and decentralized frameworks and integration concepts in industrial systems can be found. In [33], a framework for detecting anomalies in the hypertext transfer protocol (HTTP) is presented. For this purpose, the AD process is distributed to the various nodes in the system instead of using a central server. The framework significantly increases detection speed and accuracy compared to centralized models. An agent-based approach for decentralized data analysis in industrial CPSs is shown in [34]. Different agent modules are distributed over cloud, fog, and edge devices in the concept to realize effective and continuous data analysis. In [35], a decentralized IoT architecture is introduced, where part of the services are moved from the cloud to the edge. Therefore, the key component is an IoT gateway, which includes several advanced functionalities and connects the devices to the cloud. Another implementation of an industrial cloud-edge computing platform can be found in [36], where various devices are connected via different communication protocols to a cloud platform. By collecting data in a cloud DB, models can be trained over an interface and transferred back to edge devices.

In summary, only limited references to hybrid and decentralized integration concepts are available. Even fewer are designed to be fully decentralized without needing a central unit, such as a cloud server, or are capable of being completely executed on low-performance devices. Overall, no existing work addresses a modular and hybrid anomaly detection integration concept that can be fully decentralized, considers the various challenges present in an industrial environment, and provides detailed measurements of latency, resource consumption, and energy usage.

Based on the identified limitations of existing methods, our work can be summarized as follows:

• In comparison to other work, we consider in detail a whole range of real-world challenges that arise from a hybrid and modular integration of anomaly detection in an ICS. These include handling high-dynamic systems, limited resource availability, the complexity of the underlying process, data security and knowledge protection, increasing volume of data, risk management, and effective anomaly detection. After analyzing all these challenges, we define the respective requirements and consider all within the developed concept.
• We present a hybrid and modular integration concept that, compared to other concepts, can be fully decentralized and centrally integrated. Within the concept, both approaches can be flexibly and efficiently combined to optimize resource utilization. The complete modular design facilitates easy expansion, enabling the system to adapt to changes, modifications, and diverse hardware within the ICS.
• In contrast to other work, we implement the described concept prototypically within a real ICS and utilize existing devices to maximize decentralization and resource efficiency. We demonstrate the effectiveness of the approach through a comprehensive evaluation against the previously defined requirements and present a detailed analysis of the required memory and CPU power, the energy consumption, and the achieved latency.
• We demonstrate that the integration we present enables effective, secure, and efficient anomaly detection in resource-limited ICSs without relying on a central high-performance unit, which is often necessary in many other approaches. Additionally, the introduced concept can be easily expanded and adapted, allowing the implementation in existing and legacy systems with minimal effort.

3. Challenges

In this section, we outline the challenges and the resulting requirements for developing and integrating such a concept in an industrial environment.

• Highly dynamic systems: ICSs are highly dynamic, with varying system structures and hardware. Devices from different manufacturers are connected via various communication protocols to realize an underlying physical process [37]. During the lifespan of a system, processes can change, and hardware components may be added, removed, or replaced. This presents a significant challenge, as the continuous and repeated development of one AD for the entire system is associated with time, effort, and increasing costs [38]. Consequently, the concept should enable the integration of a wide variety of hardware while remaining flexible and adapting to system changes.
• Limited available resources: Due to the varying hardware used in such systems, the resources available for a possible integration are also changing [39]. This presents an important challenge, especially in decentralized integration, as not all devices can integrate additional functionality directly. Furthermore, adding hardware is associated with costs and labor [40]. Therefore, a practical and effective integration must adapt to the existing system, address limited capacities, optimize available resource usage, and allow flexible expansion through additional software and hardware when necessary.
• The complexity of the underlying process: ICSs realize complex industrial processes that often focus on productivity and speed to achieve maximum efficiency. These physical processes naturally exhibit noisy behaviour, which affects the recorded data [41]. This poses a specific challenge in identifying anomalies, particularly for the AD models, which can be influenced by poor data quality and varying recording rates [42]. Thus, any possible integration must handle various data types and qualities, differentiating sampling rates while also considering the natural behaviour of industrial data.
• Data security and knowledge protection: Another essential criterion is data security. Knowledge about the system and the realized process can be found in the sampled data from the ICS [43,44]. This is a crucial factor, especially for small- and medium-sized companies, as knowledge and expertise are key factors for competing against larger competitors. Consequently, companies often do not want to record, store, or transport their data outside their system to mitigate such risks, which can be challenging, as large numbers of data and increased performance are often required, especially when creating and training AD models [45]. Therefore, the resulting integration should process all data internally while simultaneously utilizing the system’s resources to realize all functionalities.
• Volume of data: The overall volume of data produced in industry is increasing, driven by modern complex processes and new industrial hardware and software [46]. For instance, some field devices are already achieving sample rates in the microsecond ranges. By utilizing these rapidly recorded data for anomaly detection, it is possible to better identify specific anomalies, such as short collisions, while simultaneously improving reaction times [47,48]. However, this poses a distinct challenge for integration, as it must handle large volumes of data and high sample rates within limited available resources [49]. Consequently, integration needs to be both efficient and flexible to effectively process the resulting data stream, even under resource constraints, thereby enabling rapid reaction times.
• Risk management: In an ICS, the correct and safe execution of the physical process must always be ensured. This is especially challenging in decentralized integration, where different devices, such as control units, can be actively influenced by the integration of additional software [50,51]. Such integration can lead to an overload or breakdown of the device, which may impact production or, in the worst-case scenario, endanger workers [52]. Therefore, when integrating AD into a system or device, it is crucial to prevent any negative effects on the safety or functionality of the system.
• Effective anomaly detection: Prompt detection, quick access to results, and reasonable reactions are essential for effective and reliable anomaly detection [53,54]. This is especially critical in cases like collisions or in rapid processes. Immediate detection enables a quick response, which can prevent faults from occurring or propagating through the entire production line [55]. The system should efficiently identify anomalies, provide real-time information, assist users in finding solutions, and respond appropriately when necessary.

Based on these challenges, a hybrid and modular concept was developed to meet all requirements.

4. Hybrid and Modular Integration Concept

Achieving purely decentralized integration is nearly impossible because many devices do not meet the necessary hardware and software requirements or are generally designed as closed systems, which allow no direct interference. Therefore, hybrid and modular integration is proposed. The required functionalities for the AD are divided into modules, which can be integrated into the individual devices of the ICS based on the available computational resources. Each module can be seen as a small independent service, collectively forming a complete AD. Assuming that the computational resources of a device are insufficient or that integration is impossible, this modularization allows the corresponding modules to be outsourced to an adjacent device. If no appropriate device is available within the system, the hybrid concept enables the incorporation of additional hardware, such as an SBC, to ensure integration.

Figure 1 shows an exemplary implementation of the concept. For each ICS device, one data collection module (DCM) and one production module (PM) are connected to perform AD. A communication module (COM) enables real-time data exchange and unified communication among all modules. The reaction module (RM) records all detected anomalies, generates visualizations, and provides the user with additional information about the anomaly. In the following section, the functionality and structure of each module is described.

4.1. Data Collection Module

Each DCM consists of a collector, transformer, and producer (Figure 2a). By adapting the collector to the specific communication protocol of each device, data can be collected, processed (such as cleaned, combined, and formatted by the transformer), and then transmitted to the COM by the producer. Therefore, the DCM enables a unified connection and acts as an interface between the device and the COM.

4.2. Production Module

The PM (Figure 2b) executes one AD pipeline for one device in the ICS. It comprises one collector, an executor, and a producer. The collector is directly connected to the COM and receives the discrete data stream collected by a DCM. In the executor, the AD is performed. Detected anomalies can be sent back to the COM via the producer and then written to the event database (DB).

4.3. Development Module

The development module (DEV) (Figure 2d) creates separate AD-Pipelines for each PM, where each pipeline consists of a streamer, preprocessor, and AD model. Therefore, each training cycle consists of data analysis, model initialization, training, evaluation, and finally, the export of the AD-Pipeline. The required training data and essential development parameters are imported from the DBs of the COM. A tracking server monitors the complete process and stores the results in the tracking DB of the COM for later analysis and distribution to the PMs.

4.4. Reaction Module

In the RM (Figure 2c), monitoring and analyzing of the event DB are established. The collector constantly scans all incoming events. If an anomaly is detected, further time series data from the time-series database of the COM are obtained, and the analyzer evaluates the anomaly. All collected information is then linked to the corresponding event and saved through the producer as a log in the event/log DB. Based on the extended observation period and the additional information gathered, a better reaction, even from non-expert users, can be reached.

4.5. Communication Module

The COM, shown in Figure 3, enables real-time data exchange and unified communication among all modules. It includes a data exchange server where each data-producing device is connected via a DCM. In contrast, data-consuming devices are connected via PM. Additionally, the module comprises several databases (DBs).

• A time-series DB that facilitates the storage of short-term data from various devices, enabling the development of AD models.
• A integration DB for storing essential information and structural knowledge about the system, modules, and the development process.
• An event/log DB for collecting detected anomalies, which can be later retrieved for in-depth analysis by the RM.
• A tracking DB that records the development results and stores the generated AD model for later distribution to the PMs.

4.6. Process Cycle

To establish the hybrid concept, at least one DCM and PM, as well as in the initial phase one COM and DEV, must be available. At the same time, a single device can include multiple modules. The simplified UML sequence diagram [56] in Figure 4 illustrates a possible chronological process and the interactions between the modules. In the initial stage, data are collected from the device by the DCM and stored in the TS-DB of the COM. Once enough data have been gathered, the complete data package is transferred to the DEV, where the AD-Pipeline is created and subsequently deployed to the respective PM. During the production stage, a continuous data stream from the DCM is transmitted via the COM to the PM, where the AD-Pipeline is executed. All detections are sent back to the COM, where they are saved in the event/log DB. The RM monitors all incoming events, analyzes the detections, and provides a reaction to the specific device.

5. Prototype Implementation

All modules have been implemented prototypically as containerized microservices. Each module can be customized and adjusted to available hardware, for example, by selecting the appropriate base image. All information needed to execute the module is predefined and stored in the integration DB of the COM, which gets imported when the service starts up. Important parameters can be, e.g., the communication protocol of the device, the hyperparameters of the AD model, or the transformation used in the DCM. A GUI was developed to support the setup process, even for users with limited domain knowledge.

Communication Module: Apache Kafka, an open-source event streaming platform, was selected to achieve efficient and fast communication between the modules. Apache Kafka is a distributed system based on servers and clients connected by a high-performance TCP network protocol. A Kafka server is integrated into the COM, enabling the definition of various data topics. Each DCM can send data to a specific topic, from which the PM can retrieve that data. MongoDB (https://www.mongodb.com, accessed 24 November 2024) was used for the time-series DB, integration DB, and event/log DB. The time-series DB acts as a sink to store the data from individual topics of the Kafka server. All structural information about the system and the integration are stored in the integration dB. Detected anomalies and analysis from the RM are collected in the event/log DB. The tracking DB was realized as a MySQL (https://www.mysql.com/, accessed 24 November 2024) DB to enable tracking of the development process and storage of the models.

Development Module: For universal integration of different AD models and techniques, ONNX (https://onnx.ai/, accessed 24 November 2024), an open standard for machine learning interoperability, was chosen. Therefore, nearly every machine learning development framework within the DEV can be selected to generate the AD, e.g., PyTorch (https://pytorch.org, accessed 24 November 2024), TensorFlow (https://www.tensorflow.org, accessed 24 November 2024), or Scikit-learn (https://scikit-learn.org, accessed 24 November 2024), as long as the resulting model can be transformed into an ONNX model. This method enables a high degree of flexibility and significantly reduces the effort to adapt the PMs to different ML frameworks. For the prototype, TensorFlow was chosen to enable fast and effective development of the required models. Using the tf2onnx library, the resulting model can be converted to the corresponding ONNX model. A Tracking Server based on MLFlow (https://mlflow.org/, accessed 24 November 2024) was utilized to track the development and enable an easy export of the models.

Data Collection Module: Several individual collectors were developed to enable communication between the DCMs and devices using various industrial communication protocols, such as OPC UA, Modbus/Memobus, or remote system calls (RSCs). Additional communication protocols can easily be integrated as further collectors at a later stage to be adaptable to different industrial systems. The transformer was created as an open concept to be flexible to the respective data from the device. An Apache Kafka Producer was implemented to connect the DCM to the COM.

Production Module: ONNX Runtime was chosen as a cross-platform inference machine learning accelerator for the universal integration of different AD models in the PM. A Kafka collector was established to receive a discrete data stream from the corresponding topic in the COM provided by a DCM. The AD-Pipeline, including the developed ONNX model, runs in the executor, and a MongoDB producer sends any detected anomaly to the event DB in the COM.

Reaction Module: The reaction module is used to monitor the event DB of the COM. Any input, e.g., a detected anomaly from one PM, is registered, and corresponding information is gathered. Additionally, data from the specific PM topic of the Kafka server is gathered to reconstruct the time-series data at the precise moment when the anomalies occurred. All data are later saved as a Log in the Log-DB to visualize the anomaly for the user.

5.1. GUI

A GUI was developed to facilitate a quick and straightforward setup of the concept, even for complex systems. This involves defining the integration structure, specifying each module, and assigning them to the appropriate hardware. Also, specific parameters for each module can be selected, such as the communication interface for the DCMs or the appropriate AD model for a PM. Furthermore, the detected anomalies were visualized by using the data stored in the Log-DB.

5.2. Anomaly Detection

Devices within an ICS often have limited capacity and processing power, making not all AD models suitable for direct integration. Therefore, a sliding window approach with different types of autoencoders as reconstruction AD models was chosen. As demonstrated in our previous work [8] and by the authors in [22], these models achieve excellent detection results while utilizing minimal resources, making them an ideal choice for integration into low-performance devices in the ICS. Different scalers were implemented to preprocess the data stream from the DCM, such as scaling them into an equal numerical range. The user can select the model and scaler for each PM through the implemented GUI, along with crucial parameters such as the number of layers, layer dimensions, and the loss function. In the initial phase, the DEV imports all the parameters, generates the AD-Pipeline, and automatically defines the threshold.

5.3. Cybersecurity

As modern ICSs are becoming increasingly interconnected with corporate networks and the internet, they are also becoming more vulnerable to cyberattacks [57]. Vulnerabilities can occur at various levels of the ICS architecture [58]. Since the structure, devices, and communication protocols vary in each ICS, potential vulnerabilities at the hardware, firmware, and network levels must be considered individually for each system [59]. At the software level, where the integration of the presented concept occurs, measures can be taken to reduce potential vulnerabilities. By implementing the modules as microservices and subsequently containerizing them, partial isolation from the operating system of the respective device can be achieved. Dividing the entire AD into smaller, independent modules lowers complexity and the amount of programming code in each module. This simplification eases the management of the modules and reduces the likelihood of code errors. Further advantages of containerization include the unique adaptation and restrictions of each microservice, such as limited network access and data access, as well as the straightforward updating and patching of identified vulnerabilities without disrupting the industrial process of the ICS. By tailoring the desired response in the RM, unexpected influences at the process level can be prevented.

6. Evaluation

6.1. Experimental Setup

The rotary table dispenser demonstration system ‘Totaru’ from Yaskawa (see Figure 5 was selected to evaluate and test the prototype. The system consists of three robots, two of which are six-axis systems and the remaining one a three-axis system. Furthermore, four individual drives are integrated and connected to one or multiple mechanical axes. The system realizes multiple industrial production processes, including transporting components, picking and placing objects in moving containers, and packing and sorting products.

In order to effectively realize these processes, an ICS is utilized within the system, incorporating multiple control elements. These include a robot controller for each six-axis robot, a central motion controller that generates the control commands for the three-axis robot and the individual axes, and two further control units for monitoring and controlling external processes. Additionally, an HMI is used for user input of control commands, and an SCADA system for process monitoring. The system is well suited for experimental integration because of its unrestricted access to the unit, allowing for structural changes without risking production breakdowns and economic losses while facilitating complex industrial processes.

6.2. Experimental Integration

Several modules were integrated into the devices of the experimental system, focusing on incorporating these modules into the existing hardware already used for the production process. For devices without integration capabilities, the modules were shifted to adjacent devices or additional hardware, such as a cheap single-board computer. To demonstrate the flexibility and adaptability of the concept, a Raspberry Pi 5 was integrated as a communication unit (ComUnit). The Raspberry Pi is well suited for prototyping due to its cost efficiency, flexibility, and available interfaces. Furthermore, to generate and train the AD models, a Dell laptop as an external removable computing device was utilized. A comprehensive list of all motion devices, the responsible modules, and the respective hardware identifier can be found in

Table 1. Motion devices of the ICS with responsible integrated modules and the respective hardware identifier.

Motion Device	Modules	Hardware Identifier
SliderRobot	PM0	Control Unit 1
	DCM0	Control Unit 2
RobotLogistics	PM1	SCADA Unit
	DCM1	Communication Unit
SliderLogisticsTray	PM2	Control Unit 1
	DCM2	Control Unit 2
RobotProduction	PM3	SCADA Unit
	DCM3	Communication Unit
CircularConveyorBelt	PM4	SCADA Unit
	DCM4	Communication Unit
RobotPPU (U Axis of RobotPP)	PM5	SCADA Unit
	DCM5	Communication Unit
RobotPPL (L Axis of RobotPP)	PM6	SCADA Unit
	DCM6	Communication Unit
RobotPPS (S Axis of RobotPP)	PM7	SCADA Unit
	DCM7	Communication Unit
RotatingTable	PM8	SCADA Unit
	DCM8	Communication Unit
	COM	Communication Unit
	DEV	Development Unit
	RM	SCADA Unit
	GUI	SCADA Unit

. Detailed specifications of the hardware used can be found in

Table 2. Detailed specification of used hardware for model integration.

Hardware Identifier	Hardware	Specification
Development Unit	Dell Latitude 7490	Intel i7-8650U 1.90 GHz/32 GB RAM
Communication Unit	Raspberry Pi 5	ARM Cortex-A76/8 GB RAM
SCADA Unit	Intel NUC7i7DNB	Intel i7-8650U 1.90 GHz/16 GB RAM
Control Unit 1	Yaskawa iC9212-EC	ARM Cortex-A17 1.26 GHz/2 GB RAM
Control Unit 2	Yaskawa iC9226-EC	ARM Cortex-A17 1.26 GHz/2 GB RAM

. The experimental integration of the prototype with modules and motion devices is visualized in Figure 6.

A COM and a DEV were established to ensure the basic functionalities of the concept. In addition, a DCM and a PM per motion device were integrated and distributed over the available hardware. The RM tracks and records all identified anomalies from each PM, including details about process steps, detection time, and impact. A GUI was used to easily integrate the concept and visualize all detected anomalies provided by the RM. To establish fast data collection, OPC Data Access was utilized for the DCMs integrated into the ComUnit, and remote service calls (RSCs) were implemented for the DCMs in the Control Units to receive the current motion data (speed, torque, position) of the respective motion device. Therefore, a unique buffer publish routine for each device was developed, allowing a sample rate of 8 ms with a buffer size of 30 for each variable. Consequently, 120–210 data points were collected by each DCM at each publish interval and transmitted over the COM to the corresponding PM. In the DEV, an AD-Pipeline for each PM, based on the normal process of the system, was generated. As previously mentioned, a sliding window approach was used as a streamer to split the discrete data stream into sliding windows. By setting the step size of the streamer to a small number, e.g., one, detection can be carried out, even if the received data packages are less than the input size of the AD model. A MinMax Scaler was used as a preprocessor to bring the different features of the respective data package into a uniform numerical range. A multi-layer perception autoencoder (MLP-AE) and a 1D-convolutional autoencoder (1D-CAE) were chosen as AD models. To generate valid and, in other scenarios, transferable CPU and memory consumption results, default parameter sets (

Table 3. Default AD-Pipeline parameters.

Parameter Set	Set 1	Set 2
Model	1D-CAE	MLP-AE
Window size	64	64
Step size	1	1
Number of layer	5	5
Dimensions of layer	64/32/16/32/64 (MaxPooling)	64/32/16/32/64
Loss function	MAE	MAE
Optimizer	Adam	Adam

) for implementing the AD-Pipeline were defined. Based on the training results in the initial stage of the development phase, the best-performing AD-Pipeline was exported to the corresponding PM.

6.3. Experimental Results

Every specified module was successfully integrated within the available devices of the experimental setup. All structural details regarding the integration and generated AD-Pipelines were defined exclusively through the GUI. The DEV automatically generates the AD models during the initial phase from the data of the normal process of the experimental unit. The selected models were exported to the respective previously defined PMs. In order to demonstrate the effectiveness and performance of the prototype, in the following section, the integration is validated against the previously defined industrial requirements. Additional detailed latency, resource consumption, and energy usage measurements can be found in the Appendix A, Appendix B and Appendix C.

• Highly dynamic systems: Based on the flexible concept and the customization of the DCMs, multiple devices from different manufacturers could be integrated with various communication protocols (e.g., OPCDA, OPCUA, Modbus, and RSC). By designing the modules as adaptable microservices, seamless integration into the existing devices of the experimental ICS was possible. In addition to the devices used in the experimental setup, the integration of modules into controllers from other manufacturers (e.g., PxC AXC F2152), other SBCs (e.g., Raspberry Pi4, Nvidia Jetson TX2), and those in various edge PCs could already be realized. In order to adapt to structural changes in the system, the concept enhances the flexible addition, removal, or modification of modules. For example, existing AD-Pipelines can be exchanged during continuous production, ensuring that the ongoing monitoring of the remaining system is not affected. Therefore, the concepts consider the highly dynamic nature of modern ICSs, enabling the integration of a wide variety of hardware while remaining flexible and adaptable to system changes.
• Limited available resources: With the creation of lightweight modules, the possibility of integration in a wide range of hardware, and the option to outsource functionalities to adjacent devices, the optimal utilization of the existing system resources can be ensured. Various modules could be incorporated into existing devices within the experimental setup, such as directly into the control units or the SCADA system. By incorporating a low-cost SBC as an additional hardware component, the system’s expandability can be effectively demonstrated. Through the interconnection of multiple COM units, the concept can be further extended to monitor entire production lines. An extended analysis of used resources and energy consumption can be found in Appendix A and Appendix C. Thus, the concept enables practical and effective integration even in resource-constrained environments, optimizes available resource usage, and allows flexible expansion through additional hardware when necessary.
• Complexity of the underlying process: By individually adapting the models and AD pipelines, different types of devices and the unique physical characteristics of the industrial processes could be considered. For instance, it was possible to integrate various motion devices of the experimental unit, including robots and linear and rotary axes from the experimental unit (Section 5), while simultaneously addressing the noise and jitter of each device separately by customizing the transformers in the DCMs. Given the individual connections of the DCMs and PMs, asynchronous and varying recording rates of the devices can be considered. Consequently, a broad range of devices and processes can be incorporated while taking into account their unique characteristics, data quality, sample rates, and the natural behavior of the industrial process.
• Data security and knowledge protection: The lightweight and hybrid integration of all necessary modules and functionalities directly within the system ensures that no data need to be recorded, stored, or transported to external locations. Depending on the required resources, additional devices (e.g., a laptop within the experimental setup) can be flexibly incorporated into the integration. Even during the resource-intensive training of the AD models, an external device can be temporarily added and subsequently removed. Consequently, no external connection to a data centre or cloud is necessary, resulting in enhanced data security and knowledge protection.
• Volume of data: With the flexible and hybrid integration of the modules, such as the direct integration within the control units or the possibility of outsourcing functionalities to adjacent devices, the large volume of data generated from high sampling rates can be processed effectively. At the same time, this reduces cost and energy consumption related to transmitting data to an external central location while minimizing latency. In the experimental unit, the data generated could be processed directly on the respective device, resulting in a reduced data stream and achieving high sampling rates, e.g., 8 ms, even with limited computing resources.
• Risk management: Through the implementation of the modules as microservices and thus the partial decoupling of the functionality from the device’s operating system, the associated risk can be mitigated, even when direct integration within the devices is employed. Furthermore, the maximum CPU and memory consumption of individual services can be defined, which minimizes the effects on the device and the respective process, even in the event of an error within a module. By separating the individual functions, if one module fails, the rest of the system remains stable, allowing all other devices to be continuously monitored. The error-prone module can then be reported, and once rectified, the service can be restarted, allowing full functionality of the AD to resume. It is also possible to implement redundancy, as can be seen in Appendix A, whereby multiple modules can monitor the same device. As a result, the concept reduces risks and minimizes the interference of devices and processes within the ICS, even in direct integration.
• Anomaly detection: Fast response times can be achieved through directly integrating functionalities within adjacent devices and the individual adaptation of DCMs and PMs. As a result, latency times of 300 ms were achieved with a model execution time of 200 ms within the experimental concept, even on resource-limited devices. A detailed analysis and discussion of the response times achieved with various integration concepts can be found in Appendix B. This also facilitates the early detection of critical anomalies, allowing for rapid responses. Simultaneously, the immediate localization of anomalies can be realized through the separate monitoring of individual devices, which can subsequently assist the user in resolving the anomalies.

7. Conclusions and Future Work

Complete decentralized integration of AD within an ICS is nearly impossible due to the significant variance among different devices. While some devices allow direct integration, others are designed as closed systems or lack the necessary performance. Therefore, in this paper, we introduce a hybrid and modular concept that enables the separation, modularisation, and implementation of required functionalities based on the available performance capabilities of the system. To establish AD, even for devices without direct integration possibilities, corresponding functions can be flexibly outsourced to adjacent devices, or additional hardware can be easily integrated. As a result, complete coverage of all devices in the ICS can be achieved. Furthermore, data processing directly in each device ensures high data security, low latency, and reduced data traffic. By customizing each module for the respective devices, risks can be minimized even during direct implementation. Based on the prototypical implementation within an industrial unit and the validation against all previously defined industrial requirements, we were able to demonstrate the effectiveness and efficiency of our concept. Thus, the concept facilitates the development of a effective, secure, and efficient AD even for resource-constrained legacy ICS while maximizing the utilization of all available resources.

Despite the promising results of the concept, there are several directions for future research. Until now, the concept has only been tested in one industrial system. By integrating the concept into a complete production line, more tests can be made, and the concept can be further improved. Furthermore, by incorporating additional AD models such as LSTMs, RNNs, VAEs, and OC-SVMs, along with communication protocols like EtherCAT, EtherNet/IP, and Mechatrolink, even greater flexibility and universal integrability can be achieved. Moreover, despite the possibilities already described to minimize the implementation risks of individual modules within ICS devices, specific strategies for security, authentication, and redundancy could further enhance the overall cybersecurity of the concept. Finally, by constantly improving the hybrid integration concept to make it more accessible, easier to implement, and simpler to manage, we are focusing on realizing the concept as a framework to enable its use even for non-domain experts.