Method for obtaining diagnostic data in a distributed control system

Abstract

Embodiments of the present disclosure relate to a method for obtaining diagnostic data in a distributed control system, the method comprising: - (S102) obtaining problem data, wherein the problem data is indicative of a system anomaly or failure; - (S104) processing the obtained problem data to determine diagnostic requirements; - (S106) based on the determined diagnostic requirements, identifying kernel instrumentation bytecode data (kiBD) (41); - (S108) loading and activating the identified kiBD (41), wherein activating comprises linking the kiBD (41) to system hooks; and - (S110) using the activated kiBD (41) to obtain diagnostic data.

Description

Technical Field

[0001] The present invention relates to a method for obtaining diagnostic data in a distributed control system (DCS), one or more computer program products, and a data processing system. Background Technology

[0002] Distributed control systems (DCS) are an integral part of modern industrial automation and typically comprise multiple interconnected services responsible for process control, supervision, and data acquisition. In these environments, diagnosing system anomalies or failures presents significant challenges. Traditional diagnostic methods, such as logging CPU events or container logs, often fail to capture the fine-grained diagnostic data needed for accurate analysis of complex problems.

[0003] In many cases, simply obtaining problem data indicating system anomalies or malfunctions may not be sufficient for effective troubleshooting. For example, an ideal comprehensive diagnostic process includes not only acquiring such problem data but also processing it to determine precise diagnostic requirements. This diagnostic data can provide detailed insights into the underlying behavior of the system. For instance, to gain a comprehensive understanding of the fault, it may be necessary to capture specific events such as network communications, file system activity, and user authentication events.

[0004] Achieving this level of detail typically requires instrumentation at the kernel level. However, continuously activating fine-grained diagnostics for monitoring purposes can impose significant overhead on the system. For example, continuous instrumentation (if implemented without restraint) can lead to excessive consumption of CPU and memory resources, adversely affecting the performance and stability of production systems. Therefore, there is an inherent trade-off between the need for detailed diagnostic data and the necessity of protecting system resources.

[0005] Therefore, obtaining detailed, fine-grained diagnostic data for effective fault analysis in a DCS while ensuring that system performance is not affected by excessive resource consumption is a major challenge in this field. Summary of the Invention

[0006] The independent claims of this disclosure at least partially address or alleviate the aforementioned problems or needs, with further examples incorporated in the dependent claims.

[0007] According to one aspect of this disclosure, a method for obtaining diagnostic data in a distributed control system (DCS) is provided, the method comprising: - Obtain problem data, which indicates system anomalies or malfunctions; - Process the obtained problem data to determine diagnostic requirements; - Identify kernel instrumentation bytecode data (kiBD) based on the identified diagnostic requirements. - Load and activate the identified kiBD, where activation includes linking the kiBD to a system hook; and - Use the activated kiBD to obtain diagnostic data.

[0008] Diagnostic data in a DCS can refer to detailed, granular information collected from various components and processes within the system, for example, to facilitate effective troubleshooting and fault analysis.

[0009] The term "kernel instrumentation bytecode data" (kiBD) can refer to any form of kernel-level code, for example, that can be introduced into the operating system kernel to capture, manipulate, or monitor system events. In the context of this invention, kiBD broadly encompasses mechanisms such as eBPF (Extended Berkeley Group Filter) code or similar methods that enable fine-grained diagnostics without modifying the kernel itself. Therefore, kiBD can represent code that can be loaded into the kernel execution environment in bytecode form.

[0010] kiBD can comprise a two-part architecture: a kernel space component and a user space component. The kernel space component is responsible for directly collecting system events (e.g., monitoring network events, file system operations, or user authentication activity). The user space component can handle analysis tasks, filtering or visualizing the collected diagnostic data. Communication between these two components is achieved through a mechanism such as an eBPF mapping, which acts as a data exchange buffer between kernel space and user space.

[0011] The example kiBD programs described in this article are designed specifically for industrial automation domains and distributed control systems (DCS). Although these programs are designed with DCS-specific diagnostics in mind, they are not limited to any single production facility. Instead, they can be adopted in any DCS that incorporates relevant technologies such as OPC UA or IEC 61131-3.

[0012] The method of the first aspect can in particular be a method implemented at least partially or entirely by a computer. This means that at least one, several, or all steps of the method can be performed by a data processing system, which may include one or more data processing devices, which may be in the form of a computer or computing unit, and the computer or computing unit may include one or more processors and data storage or memory. Different steps may be performed by the same or different data processing devices in the data processing system.

[0013] Obtaining fault data can refer to the process of collecting information or signals from a distributed control system (DCS) that suggest the presence of an anomaly or fault. This fault data can originate from various sources, such as system logs (e.g., automated logs generated by system components that record errors, warnings, or unexpected behavior), alarms or notifications (e.g., signals triggered by monitoring tools or the DCS itself when specific thresholds or conditions are reached), or telemetry data and metrics (such as performance data and statistics that deviate from expected values, indicating potential faults). For example, fault data can also be in the form of direct input from system operators or administrators who observe irregularities or performance problems.

[0014] Fault data indicating system anomalies or malfunctions can be processed to establish specific diagnostic parameters and requirements for effective troubleshooting. This can include data analysis and correlation, where acquired fault data is examined to identify patterns, inconsistencies, or deviations from normal system behavior. Such analysis may involve processes such as, but not limited to, filtering noise and correlating data from various sources (e.g., logs, telemetry data, alarms) to gain a comprehensive understanding of the anomaly. For example, by processing fault data, it is possible to identify which specific components (such as network modules, file systems, or authentication services) exhibit anomalous behavior. This identification is crucial for narrowing diagnostic focus to the areas most likely to cause the fault. Based on the analysis, diagnostic requirements are defined. For example, this might mean determining which types of system events need to be captured (e.g., network traffic details, file access patterns, or user authentication events), or determining the level of granularity required to capture these events to adequately isolate and understand the fault.

[0015] The processed fault data can be used to select appropriate diagnostic tools; in this example, it refers to a specific kernel instrumentation bytecode data (kiBD) that can capture the necessary detailed information. This mapping ensures that subsequent diagnostic actions are precisely tailored to the nature of the detected anomaly.

[0016] A kiBD (kibble engine diagnostic tool) in the form of diagnostic code (e.g., eBPF code or a similar bytecode mechanism) is loaded into the operating system kernel. This can, for example, be done at runtime without modifying the kernel's source code. Activation may involve linking the loaded kiBD to a specific system hook. System hooks are points in the kernel where predefined events, such as network events, file system operations, or user authentication processes occur. The linking process can be implemented, for example, using a kernel-level mount mechanism. This mechanism ensures that when a specific event occurs at the mount point, the kiBD is triggered to capture or manipulate event data. By linking the kiBD to a specific system hook, the diagnostic system can ensure that only relevant events (determined by diagnostic requirements) are monitored. This targeted approach avoids unnecessary performance overhead and ensures that the collected diagnostic data is accurate and relevant to the detected anomalies or faults.

[0017] When a mount event occurs, kiBD is triggered, allowing it to directly capture detailed, low-level information about these events within kernel space. For example, the collected diagnostic data can serve as the basis for subsequent steps in the diagnostic process, such as filtering, visualization, and anomaly detection, thereby enabling effective troubleshooting and fault analysis.

[0018] In the example, loading and activating the identified kiBD may include verifying the integrity and compatibility of the kiBD. This verification can be achieved by employing security measures, such as cryptographic signature verification, to ensure the kiBD has not been tampered with or altered, thus confirming that the diagnostic code maintains its original intended state. Additionally, its compatibility with the target operating system kernel can be assessed by checking its compatibility with the specific kernel version and configuration. Additional measures may include evaluating memory usage, performance overhead, and other resource-related parameters to ensure that the kiBD, once activated, will not adversely affect system stability or performance. These measures not only prevent the execution of potentially corrupted or malicious code but also ensure that the activation of the kiBD does not impair the stability or performance of the distributed control system, thereby contributing to a safe and reliable diagnostic process.

[0019] In the example, kiBD can be just-in-time (JIT) compiled before being linked to system hooks. Kernel instrumentation code, such as eBPF programs or other bytecode forms, can be executed by interpretation within the kernel, or, if supported, by being translated into native machine code. JIT compilation transforms bytecode into native code, allowing it to run directly on the processor instead of through an interpreter loop. This direct execution optimizes performance, ensuring diagnostic operations are performed with minimal latency and maximum efficiency. Furthermore, because kiBD was originally developed in bytecode form, it maintains a high degree of flexibility. Bytecode is largely independent of any specific system configuration, meaning it can be deployed in various DCS environments. Adaptation to specific target architectures or kernel versions can occur during load-time JIT compilation. This dynamic adaptation facilitates the distribution and deployment of diagnostic tools in heterogeneous environments without maintaining multiple code versions for different systems. JIT compilation can be performed after the verification phase but before execution. Only after passing these verification checks can kiBD be JIT compiled and linked to the appropriate system hooks, ensuring that only safe and verified code is executed in the kernel. The JIT compilation process can further reduce the latency between on-demand loading of diagnostic tools and their activation and deployment. The rapid compilation and immediate execution of native code shortens the activation window, which is particularly critical in real-time or high-availability industrial automation environments. This ensures that any system anomalies or failures are resolved as quickly as possible, facilitating timely and effective troubleshooting.

[0020] In the example, kiBD can be selectively linked to system hooks relevant to identified diagnostic requirements or needs. Identified diagnostic needs can refer to specific types of diagnostic data required for effectively analyzing and troubleshooting system anomalies or failures. These needs are determined by processing acquired fault data that highlights deviations from normal system behavior. Based on these identified diagnostic needs, kiBD can be selectively linked to system hooks directly related to the required diagnostic information. For example, kiBD can be linked to network event hooks to capture detailed information about network traffic; linked to file system hooks to monitor file access and modification; or linked to user authentication hooks to track login activity and potential security vulnerabilities. Beyond these general hooks, diagnostic needs in industrial automation environments may necessitate capturing domain-specific data. For instance, binding kiBD to hooks monitoring OPC UA communications can enable the capture of fine-grained network events related to operational data exchange, ensuring timely identification of any anomalies in these communications. Similarly, linking kiBD to hooks associated with PLC functions (such as those monitoring the execution of controls compliant with IEC 61131-3) can allow for precise tracking of function call timing, state changes, and performance metrics. This targeted instrumentation ensures that only relevant diagnostic data is collected, which is crucial for rapid and accurate fault analysis in distributed control systems.

[0021] In the example, the method may also include storing the acquired diagnostic data in a kiBD map. This kiBD map can serve as a centralized repository within the kernel environment to organize and store detailed diagnostic information captured by the activated kiBD. For example, when kiBD is loaded and attached to a specific system hook, it can intercept relevant system events (such as network packets, file operations, or user authentication events) and write the associated diagnostic data to this kiBD map. The kiBD map can be maintained within the kernel, thus allowing for fast, low-latency access to the captured data. Once the diagnostic data is stored in the kiBD map, other components of the diagnostic assistant, such as the event monitor, can retrieve and process this information. For example, the event monitor can receive diagnostic data pushed to it in real time or periodically poll the kiBD map for new events.

[0022] In the example, the kiBD mapping can be keyed using one or more identifiers. These identifiers can include at least one or more of process IDs, thread IDs, timestamps, or network connection IDs. For example, a process ID or thread ID can help identify which specific process or thread generated a particular diagnostic event. A timestamp can record the exact time an event occurred, allowing for temporal correlation of events. Additionally, a network connection ID can be used to associate diagnostic data with specific network sessions or communications. By keying the kiBD mapping with these identifiers, the system can efficiently store, retrieve, and analyze collected diagnostic data, ensuring that each piece of data is linked to a corresponding system event within its context. This facilitates rapid fault identification and targeted troubleshooting within a distributed control system.

[0023] In the example, predefined algorithms can be used to further analyze the obtained diagnostic data. These predefined algorithms can be applied to the diagnostic data stored in the kiBD map to detect any deviations from normal behavior. These algorithms may use threshold comparisons, statistical analysis, pattern recognition, or even machine learning techniques to identify specific signs of system anomalies, performance degradation, or potential security vulnerabilities. For example, these algorithms can use threshold comparisons, statistical analysis, pattern recognition, or machine learning techniques to identify specific signs of system anomalies, performance degradation, or potential security vulnerabilities. For example, these algorithms can flag unusual network traffic patterns that may indicate security threats, identify timing irregularities in process execution that suggest performance problems, or detect unexpected behavior in system logs that hints at potential anomalies.

[0024] In the example, this method can be automatically initiated in response to the detection of a system anomaly or upon receiving a system-generated alert. This means that, instead of requiring manual intervention to begin the diagnostic process, the system continuously monitors for irregularities or predefined alert conditions. When such anomalies are detected (such as unusual performance metrics, error conditions, or safety-related events), the system automatically triggers the diagnostic process. Similarly, if a system-generated alert is issued (e.g., via automated monitoring tools), that alert can serve as a signal to begin collecting and analyzing diagnostic data. This automatic initiation mechanism ensures a rapid response to potential problems, minimizing the delay between failure occurrence and the start of the diagnostic procedure.

[0025] In the example, the method could also include deactivating and unloading kiBD after obtaining diagnostic data. This step is crucial as it ensures that diagnostic instrumentation does not continue to unnecessarily consume system resources once the necessary information has been collected. Essentially, deactivation and unloading restores the system to a normal operating state, thus reserving CPU and memory resources for ongoing and future processes. For example, kiBD can be deactivated once sufficient diagnostic data has been obtained. This deactivation can involve separating kiBD from its associated system hooks, which could be monitoring network events, file system operations, user authentication, or even domain-specific functions such as OPC UA and PLC operations. By doing so, kiBD can stop collecting further diagnostic data. In environments such as distributed control systems (DCS), where resources are often limited and time-critical automation processes need to be supported, targeted instrumentation shutdown can be beneficial. After deactivation, kiBD can be unloaded from the kernel execution environment. This removal clears the loaded bytecode from memory, freeing up all resources allocated to it. Unloading ensures that the diagnostic tool does not incur any residual overhead that could otherwise negatively impact system performance. In summary, disabling and uninstalling kiBD after obtaining diagnostic data can stop further unnecessary data collection and free up system resources.

[0026] In the example, kiBD deactivation and uninstallation can be triggered automatically after a predetermined period, after the diagnostic process is completed, or upon receiving a manual request from the user. For example, a separate thread or timer mechanism can be used to track the duration for which diagnostic instrumentation has been active. Predefined periods can be set to ensure that kiBD is only active for extended periods when capturing necessary diagnostic data, without overloading the system. In addition to fixed periods or as an alternative, detection can also occur when the diagnostic process has achieved its objectives. For example, this process might be triggered when sufficient diagnostic data has been successfully stored in the kiBD map and processed. Once the required diagnostic information is identified as complete, the deactivation and uninstallation process can be triggered automatically. These diagnostics can be loaded and unloaded at specific intervals, such as during off-peak hours or maintenance windows, further optimizing resource utilization.

[0027] In the example, a machine learning model can be used to identify kiBDs. Instead of relying on predefined rules or manual operator input, machine learning models, such as neural networks or large language models, can interpret incoming fault or anomalous data, such as error logs, operator reports, or automatically generated alerts, enabling automated and more precise determination of which kiBD procedure should be activated. For example, once the model identifies a relevant category of system anomaly (e.g., network latency issues, memory leaks, or security vulnerabilities), it can automatically suggest the specific kiBD procedure that will most effectively gather the necessary data. For instance, if a distributed control system receives frequent error logs mentioning unstable OPC UA connections, the machine learning model can parse the text descriptions and classification metrics to identify possible causes involving network congestion or protocol-specific issues. For example, in a response, the model can suggest a dedicated network monitoring kiBD targeting OPC UA-related sockets and tracking appropriate TCP / UDP events in the kernel. The machine learning model can be trained on historical data or simulated scenarios reflecting a range of fault types, such as CPU bottlenecks, memory leaks, or unauthorized file access. This reduces the risk of human error, improves response time to critical issues, and allows operators to focus on interpreting diagnostic results rather than sifting through potential solutions. Ultimately, this approach leverages data-driven insights to optimize the on-demand selection of kiBD, thereby improving the accuracy and efficiency of diagnosing anomalies in large distributed control systems.

[0028] In the example, the method may also include linking a user-space component of kiBD to at least one user application in the DCS. In some embodiments, not only kernel-level instrumentation can be employed via kernel instrumentation bytecode data (kiBD), but also user-space components of kiBD can be implemented. For example, this user-space component can be linked to at least one user application or service in a distributed control system (DCS). For example, the DCS may include human-machine interface (HMI) software, asset management services, or dedicated control applications for executing IEC 61131-3 logic. Through the user-space kiBD component, these applications can be mounted at predefined functional boundaries (e.g., library calls, service entry points, or communication APIs), thereby capturing detailed contextual information that might not appear in pure kernel-level tracing. Relevant diagnostic or security-related information can then be correlated with kernel events, which is particularly useful where application-level errors or misconfigurations trigger OS-level anomalous behavior. Furthermore, linking user-space components ensures detailed monitoring of domain-specific logic, such as OPC UA protocol handlers or high-level application-level operations. User-space hooks can detect anomalous function parameters, unauthorized configuration changes, or performance bottlenecks manifested in applications rather than within the kernel. By aggregating these user-space observations with kernel-level data (e.g., in shared maps or via inter-process communication), a holistic view of the runtime state can be provided.

[0029] In the example, the method may also include enforcing one or more security policies derived from the IEC 62443 guideline using the activated kiBD. This means that kiBD hooks not only collect diagnostic data, but they can also enforce security policies. For example, kiBD can monitor kernel-level events such as network packets, system calls, or file access operations. kiBD can then compare each monitored event with a set of predefined security rules derived from IEC 62443 and selectively allow, block, or alert on events that violate the security rules, thereby preventing unauthorized operations or anomalous system behavior in the distributed control system.

[0030] According to a second aspect of this disclosure, one or more computer program products are provided, comprising instructions that, when executed by one or more data processing devices, cause the one or more data processing devices to perform the methods of the first aspect of this disclosure. The computer program product may be one or more computer programs themselves, meaning a computer program consisting of program code executed by a data processing device (particularly a computer).

[0031] Alternatively, the computer program product may be one or more products, such as data storage, particularly computer-readable data storage media, in which the computer program may be stored temporarily or permanently.

[0032] According to a third aspect of this disclosure, a data processing system is provided, configured to perform the method according to a first aspect of this disclosure. The processing system may include a diagnostic assistant, which may include a loader and an event monitor. The loader may be configured to receive problem data indicating a system anomaly or malfunction. This may occur when an operator or user enters a problem report through a user interface, or when the system itself generates an automatic alarm (e.g., upon detecting abnormal network latency or unexpected process termination). Upon receiving the problem data, the loader may be configured to process the problem data to determine corresponding diagnostic requirements. After establishing these diagnostic requirements, the loader may also be configured to identify appropriate kernel instrumentation bytecode data (kiBD). The loader may also be configured to select the most suitable kiBD based on the nature of the reported problem. Once the loader has identified the kiBD, it may be configured to load and activate it using a kernel-level hook mechanism that links the kiBD to a system hook. The event monitor may be configured to obtain diagnostic data generated by the activated kiBD. In practice, the kiBD module can be configured to store collected kernel events (such as network traffic information, file system calls, or system timestamps) or stream them to an accessible data structure (often referred to as a map or buffer). The event monitor can be configured to poll, subscribe to, or otherwise retrieve these events at predetermined intervals. Once the event monitor has collected diagnostic information, it can store the data or forward it to higher-level components (e.g., monitoring dashboards or analytics modules) for further processing or visualization. In some embodiments, the event monitor can also handle preprocessing steps such as filtering out noise, aggregating duplicate events, or tagging data for subsequent anomaly detection routines.

[0033] The processing system may also include kiBD mappings and monitoring dashboards. KiBD mappings are configured to store diagnostic data obtained from activated kiBDs. For example, if a kernel-level mount mechanism (such as a kiBD program) collects information about network packets, file accesses, or system calls, it can store these data points in a dedicated data structure (e.g., a hash map or array map). The kiBD mapping can then organize this diagnostic data based on predefined identifiers such as process IDs, thread IDs, timestamps, or network connection IDs. By assigning unique keys, the processing system can efficiently retrieve specific records for detailed analysis or correlation with other event logs. Furthermore, this mapping architecture facilitates fine-grained data segmentation, allowing operators or automation tools to filter, aggregate, or archive relevant datasets on demand. Monitoring dashboards provide intuitive graphical or tabular interfaces for viewing diagnostic data retrieved from kiBD mappings. By leveraging visualization techniques such as charts, timelines, and heatmaps, monitoring dashboards can transform raw system information into actionable insights, enabling users to more quickly identify trends and anomalies. In addition, the monitoring dashboard supports more analytical functions, including statistical evaluation, anomaly detection algorithms, and time series analysis. Beyond simple visualization, the dashboard also supports user interaction for configuring diagnostic parameters or filtering the displayed data. For example, users can set thresholds to trigger additional instrumentation, define time windows for historical event retrieval, or select specific system hooks for detailed investigation.

[0034] It should be noted that the above aspects, examples, and features can be combined with each other, regardless of the specific aspects involved.

[0035] The foregoing and other aspects of this disclosure will become apparent and be illustrated by reference to the examples described below. Attached Figure Description

[0036] Exemplary embodiments will now be further described with reference to the accompanying drawings, in which:

[0037] Figure 1 This demonstrates a method for obtaining diagnostic data in a distributed control system;

[0038] Figure 2 A system for obtaining diagnostic data in a distributed control system is shown.

[0039] The accompanying drawings are schematic only and are not drawn to scale. In principle, the same or similar parts, elements and / or steps in the drawings are provided with the same or similar reference figures. Detailed Implementation

[0040] Figure 1This schematically illustrates a method for obtaining diagnostic data in a distributed control system.

[0041] In the first step 102, problem data is obtained, indicating an anomaly or failure in system 10 within the distributed control system (DCS). This problem data can originate from various sources, including system logs, real-time performance telemetry data, security alarms, or manual reports, such as those from user 1 or system operators. Problem data can describe events such as unexpected network behavior, process latency, high CPU utilization, unauthorized file access, or unusual system log entries. By collecting this initial data, it can be determined whether a targeted diagnostic process is necessary.

[0042] In step 104, the acquired problem data is processed to determine specific diagnostic requirements. For example, this might involve analyzing the nature of detected anomalies and identifying which system components are involved. Analysis may include pattern recognition, correlation with historical failure data, or rule-based filtering to distinguish significant anomalies from normal fluctuations. The result of this step may be a set of diagnostic parameters, defining, for example, what types of information need to be collected. For instance, if the problem involves network communication failures, diagnostic requirements might include monitoring OPC UA traffic and packet latency. If the anomaly is related to unexpected system restarts, the focus might shift to process execution timing and memory allocation patterns. This step ensures that only relevant diagnostic requirements are captured, preventing unnecessary resource consumption.

[0043] In step 106, kernel instrumentation bytecode data (kiBD) is identified based on the determined diagnostic requirements. A predefined kiBD 41 repository 40 can be queried, containing multiple diagnostic programs or kiBD 41s specifically designed to monitor different behaviors of system 10. Each kiBD 41 may include kernel-level instrumentation code, for example, implemented using eBPF (Extended Berkeley Grouping Filter), thus enabling efficient system monitoring without modifying the operating system. The selection of an appropriate kiBD 41 can be based on a predefined mapping between fault types and diagnostic tools, or in a high-level implementation, it can be driven by a machine learning model that analyzes the problem data and suggests the most relevant kiBD 41. For example, if system 10 detects a large number of authentication attempt failures, the selected kiBD 41 could focus on monitoring user login events and access permissions. For example, if the problem is related to latency in the control loop, the kiBD 41 could track the real-time execution timing of PLC (Programmable Logic Controller) tasks.

[0044] In step 108, the identified kiBD 41 is loaded and activated, enabling it to collect diagnostic data. For example, a loader module or loader 31 can dynamically load kiBD 41 into the kernel execution environment 50 via a system call. Before execution, kiBD may undergo a security verification process to ensure it is compatible with the running kernel and has not been altered or corrupted. Furthermore, the kiBD bytecode can be translated into native machine code via Just-In-Time (JIT) compilation to optimize execution performance. After loading, kiBD is linked to specific system hooks corresponding to the desired diagnostics. These system hooks can define which system-level events trigger data collection. For example, network-related kiBD 41 can be attached to TCP / IP protocol stack hooks to monitor network traffic. Process execution kiBD 41 can trace CPU scheduling hooks to measure execution timing. Security-focused kiBD 41 can be mounted to filesystem events to detect unauthorized modifications. By attaching kiBD 41 to relevant system hooks, system 10 can ensure that only relevant diagnostic events are logged, thus preventing unnecessary performance overhead.

[0045] In step 510, the activated kiBD 41 collects diagnostic data based on system events. This diagnostic data can be temporarily stored in a kiBD map 51. This kiBD map 51 can be part of the kernel 50. For example, the event monitoring component 32 can continuously retrieve this data and process it into a structured log or statistical summary. For example, the diagnostic data may include information such as network packet metrics, CPU usage trends, memory allocation patterns, or security-related file access attempts. The event monitor 32 can then forward the collected data to a monitoring dashboard 33, where users or system operators can visualize and analyze the data. Depending on the implementation, the monitoring dashboard 33 may, for example, apply automatic filtering, anomaly detection algorithms, or machine learning-based classification to highlight potential root causes of problems. In some cases, the system 10 can automatically trigger predefined response actions, such as sending alerts, suggesting configuration changes, or temporarily blocking unauthorized processes.

[0046] In the optional final step 110, kiBD can be deactivated and unloaded to free up system resources. For example, once sufficient diagnostic data has been collected, the loader module 31 can initiate a deactivation process to unlink kiBD 41 from system hooks. The diagnostic program can be removed from the kernel, ensuring it no longer consumes CPU, memory, or storage resources. Deactivation can occur in several ways. For example, it can be deactivated automatically after a predefined duration (e.g., 60 seconds of collecting diagnostic data), or when diagnostic completion is detected (e.g., sufficient data has been collected to clearly identify the problem), or manually deactivated by an operator (e.g., after reviewing the diagnostic results). By unloading kiBD 41 after diagnostic completion, system 10 can ensure minimal impact on ongoing operations while still providing detailed insights into system anomalies.

[0047] Figure 2 A system 10 for obtaining diagnostic data in a distributed control system (DCS) is illustrated schematically. System 10 includes several components, including system management 20 / user 1, diagnostic assistant 30, and kernel environment 50.

[0048] System Management 20 / User 1 can represent the operator, administrator, or automated monitoring service responsible for initiating the diagnostic procedure. This process can begin when an anomaly or fault is detected in the DCS. This issue may originate from system logs, performance deviations, security alerts, or user-reported faults. Upon detection of the problem, System Management 20 / User 1 can trigger a diagnostic request, which is forwarded to Diagnostic Assistant 30 for further processing.

[0049] The diagnostic assistant is responsible for handling diagnostic requests and performing appropriate kernel-level instrumentation. It can include several components. For example, the loader 31 can receive diagnostic requests and process the reported problems to determine the necessary diagnostic requirements. Based on this analysis, the loader 31 can query the kiBD repository 40—a repository of predefined kernel instrumentation bytecode data (kiBD) programs 41. The loader 31 can then select the most appropriate kiBD 41 to diagnose the reported problem. For example, if the anomaly is related to network performance, the loader 31 can select the kiBD 41 used for monitoring OPC UA traffic. Once the selection is complete, the loader 31 can dynamically load the kiBD 41 into the kernel 50 via a system call.

[0050] The kiBD repository 40 can include predefined diagnostic programs tailored for different types of system anomalies in a DCS environment. kiBD 41 programs can be configured to monitor specific system behaviors such as CPU load, memory usage, network traffic, process execution, or security events. These kiBD 41 programs can be built with a two-part architecture, including a kernel space component (which collects raw system data) and a user space component (which processes and visualizes the data).

[0051] Once kiBD 41 is activated, it can be linked to the system hook in kernel 50 and begin collecting diagnostic data. Event monitor 32 can continuously retrieve and process the recorded system events, which can be temporarily stored in kiBD map 51 (a diagnostic data buffer managed by the kernel). Event monitor 32 ensures that only relevant events are captured, thus reducing unnecessary overhead.

[0052] The data from the kiBD mapping 51 can then be transmitted to the monitoring dashboard 33 for further analysis. The monitoring dashboard 33 can serve as a visualization and analysis interface. For example, it can present the collected diagnostic data in the form of charts, tables, logs, and alerts, allowing user 1 to examine system behavior and identify potential problems. For example, the monitoring dashboard 51 can also apply predefined algorithms (e.g., statistical analysis, anomaly detection, or machine learning-based event correlation) to automatically filter and highlight key diagnostic patterns.

[0053] Kernel 50 is the execution environment in which the kiBD 41 program runs. Once kiBD 41 is loaded, it can be linked to specific system hooks, such as: - Network hooks (used to monitor OPC UA traffic and TCP / IP activity) - File system hooks (used to track unauthorized file access) - Process execution hooks (used to monitor CPU-intensive tasks)

[0054] The kiBD map can be a kernel-managed data buffer where recorded diagnostic data is temporarily stored before being processed by the event monitor. Data can be stored using identifiers such as process IDs, thread IDs, timestamps, or network session IDs. The event monitor can periodically retrieve data from the kiBD map 51, process it, and forward it to the monitoring dashboard 33.

[0055] Once sufficient diagnostic data has been collected, the diagnostic assistant 30 can initiate a shutdown process. The loader 31 can remove the active kiBD 41 program from the kernel 50, ensuring that the system 10 returns to normal operation. Therefore, the diagnostic assistant 30 can be configured to dynamically activate and deactivate kiBD 41 to collect detailed diagnostic data while minimizing system overhead. This prevents unnecessary resource consumption, ensuring that CPU, memory, and storage are not overburdened by prolonged diagnostics.

[0056] The data processing system 70 may include one or more data processing devices 60, such as a computer. The data processing system 70 (particularly the data processing device 60, and especially its processor 32) can be used to perform the method 100 of obtaining diagnostic data in a distributed control system. An exemplary data processing device 60 includes at least one processing unit or processor 32 (e.g., a CPU) and at least one computer program product, for example, in the form of a computer-readable storage medium. The computer program is stored on the computer program product.

[0057] Although the invention has been illustrated and described in detail in the accompanying drawings and the foregoing description, such illustrations and descriptions should be considered illustrative rather than restrictive. The invention is not limited to the disclosed embodiments. Other variations to the disclosed embodiments can be understood and implemented by those skilled in the art and those who practice the invention after studying the drawings, this disclosure, and the claims.

[0058] As used herein, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The fact that certain measures are recited in mutually different dependent claims does not imply that combinations of these measures cannot be used advantageously. Furthermore, as used herein, the phrase “at least one” or similar phrases (e.g., “one or more”) referring to a list of one or more entities should be understood to mean at least one entity selected from any one or more entities in that list, but not necessarily including at least one of every entity specifically listed in that list, nor excluding any combination of entities in that list. This definition also allows for the optional presence of entities other than those specifically identified in the list of entities referred to by the phrase “at least one” or similar phrases, regardless of whether such entities are related to the specifically identified entities. Therefore, as a non-restrictive example, "at least one of A and B" (or equivalently "at least one of A or B", or equivalently "at least one of A and / or B", or equivalently "one or more of A and B", "one or more of A or B", or "one or more of A and / or B") in one example can refer to at least one (and optionally more than one) A, without B (and optionally other entities besides B); in another example, it can refer to at least one (and optionally more than one) B, without A (and optionally other entities besides A). In yet another example, it can refer to at least one (and optionally more than one) A, and at least one (and optionally more than one) B (and optionally other entities). In other words, the phrases "at least one", "one or more", and "and / or" are open-ended expressions that are operationally both conjunction and disjunctive. For example, each of the expressions “at least one of A, B and C”, “at least one of A, B or C”, “one or more of A, B and C”, “one or more of A, B or C”, and “A, B and / or C” can mean a single A, a single B, a single C, a combination of A and B, a combination of A and C, a combination of B and C, a combination of A, B and C, and optionally, any of the above combinations with at least one other entity.

[0059] As used herein, the phrase “indicate” can mean, for example, “reflect” and / or “include”. Therefore, the entities, elements, and / or steps referred to herein as “indicate [...]” can be used synonymously or interchangeably with one, two, or all of “include [...]” and “reflect [...]”. Furthermore, as used herein, unless otherwise stated, phrases such as “based on,” “related,” “associated,” or “related to” should not be limited to the entities, elements, and / or steps they refer to. Rather, unless otherwise stated, these phrases should be understood to be inclusive; for example, when an entity, element, or step refers to another entity, element, or step by these phrases or similar phrases (e.g., “based on”), this does not preclude that the entity, element, or step may further or also be “based on” any other entity, element, or step besides those mentioned.

[0060] The designation of methods and steps as first, second, etc., herein is merely intended to make these methods and their steps referable and distinguishable from one another. Such designation of methods and steps does not constitute a limitation on the scope of this disclosure. For example, when this disclosure describes a third step of a method, the first or second step of the method need not exist, much less be performed before the third step, unless explicitly stated otherwise. Furthermore, the presentation of methods or steps in a particular order is merely an example intended to facilitate this disclosure and does not constitute a limitation on the scope of this disclosure. Generally, methods and steps may be performed in any feasible order unless explicitly stated otherwise. Specifically, the terms “first,” “second,” “third,” or “(a),” “(b),” “(c)”, etc., used in the specification and claims are used to distinguish similar elements and are not necessarily used to describe an order or chronological sequence. It should be understood that these terms may be used interchangeably where appropriate, and embodiments of the invention described herein may operate in an order other than that described or illustrated herein.

[0061] In the context of this invention, any indicated numerical value is generally associated with a certain range of accuracy, which those skilled in the art will understand still ensures the technical effect of the feature. As used herein, the deviation from the indicated numerical value is within ±10%, preferably ±5%. The aforementioned deviation of ±10% (preferably ±5%) from the indicated numerical value is also indicated by terms such as “approximately” and “about” as used herein with respect to numerical values.

[0062] Any reference numerals in the claims should not be construed as limiting the scope.

Claims

1. A method (100) for obtaining diagnostic data in a distributed control system (DCS), the method comprising: - (S102) Obtain problem data, wherein the problem data indicates a system abnormality or malfunction; - (S104) Process the obtained problem data to determine diagnostic requirements; - (S106) Based on the determined diagnostic requirements, identify the kernel instrumentation bytecode data (kiBD) (41). - (S108) Load and activate the identified kiBD (41), wherein activation includes: linking the kiBD (41) to a system hook; as well as - (S110) Use the activated kiBD (41) to obtain diagnostic data.

2. The method (100) of claim 1, wherein loading and activating the identified kiBD (41) comprises: Verify the integrity and compatibility of the kiBD (41).

3. The method (100) according to claim 1 or 2, wherein the kiBD (41) is just-in-time (JIT) compiled before being linked to the system hook.

4. The method (100) according to any one of the preceding claims, wherein the kiBD (41) is selectively linked to a system hook associated with the identified diagnostic requirement.

5. The method (100) according to any one of the preceding claims further includes: The obtained diagnostic data is stored in the kiBD mapping (51).

6. The method (100) of claim 5, wherein the kiBD mapping (51) is keyed by one or more identifiers, wherein the identifiers are at least one or more of process ID, thread ID, timestamp or network connection ID.

7. The method (100) according to claim 5, further comprising: The obtained diagnostic data is analyzed using a predefined algorithm.

8. The method (100) according to any one of the preceding claims, wherein the method (100) is initiated automatically in response to detecting a system anomaly or after receiving an alarm generated by the system.

9. The method (100) according to any one of the preceding claims further includes: After obtaining the diagnostic data, the kiBD is deactivated and uninstalled (41).

10. The method (100) of claim 9, wherein the kiBD (41) is automatically deactivated and uninstalled after a predetermined period of time, or after the diagnostic process is completed, or after a manual request from the user is received.

11. The method (100) according to any one of the preceding claims, wherein identifying the kiBD (41) based on the diagnostic requirements is performed using a machine learning model.

12. The method (100) according to any one of the preceding claims further includes: Link the user space component of the kiBD (41) to at least one user application in the DCS.

13. The method (100) according to any one of the preceding claims further comprises: One or more security policies derived from the IEC 62443 guideline are implemented by means of the activated kiBD (41).

14. One or more computer program products (62), the one or more computer program products comprising instructions that, when executed by one or more data processing devices (60), cause the one or more data processing devices (60) to perform the method (100) according to any one of the preceding claims.

15. A data processing system (70) configured to perform the method (100) according to any one of claims 1 to 13.

Images