A computer-implemented method for providing diagnostic data of component

Abstract

The invention relates to a computer-implemented method for providing diagnostic data for a component in an industrial plant, the component comprising an OPC UA server. The method comprises the following steps: providing diagnosis metadata on an OPC UA server, wherein the diagnosis metadata describes diagnosis data of a component; discovering, by the diagnostic unit, an OPC UA server of the component; the diagnosis unit creates a corresponding data collection unit for the component, wherein the data collection unit comprises an OPC UA client; generating, by the diagnostic unit, a configuration file for the data collection unit using the diagnostic metadata; transmitting the configuration file to a data collection unit by the diagnosis unit; modifying, by the diagnostic unit, a configuration file of the time series database by adding a URI of the data collection unit; the data collection unit is connected to a time sequence database; delivering diagnostic data of the component to a time series database via the data collection unit; and storing the diagnostic data of the component to a diagnostic data repository of the time series database.

Description

Technical Field

[0001] The invention relates to a computer-implemented method for providing diagnostic data of components in an industrial plant. The invention also relates to a diagnostic unit, a use, a program element, and a computer-readable storage medium. Background Art

[0002] Industrial plants may comprise a large number of components (e.g. components like sensors or actuators) and / or one or more control units. Consequently, the components generate not only a large amount of measurement data, but also a large amount of diagnostic data, such as information about processor and / or communication load, safety issues, error and event logs, and / or many other information. At least for some plants, in particular those with distributed control systems, this information may be useful, for example, for planning and / or dimensioning components. In order to process the data, it may be helpful to store the diagnostic data in a database. However, setting up the collection of diagnostic and / or monitoring data in an appropriate database (in particular for distributed control systems) may require a lot of manual configuration work and may be error-prone and costly. Therefore, it is desirable to reduce the time and effort in setting up the collection of diagnostic and / or monitoring data. Summary of the Invention

[0003] The present disclosure provides a method for establishing a method for collecting diagnostic and / or monitoring data of plant components. This object is achieved by a computer-implemented method for providing diagnostic data of components in an industrial plant. Further embodiments will become apparent from the following description.

[0004] One aspect relates to a computer-implemented method for providing diagnostic data of a component in an industrial plant, the component including an OPC UA server, the method comprising:

[0005] On the OPC UA server, diagnostic metadata is provided, which describes the diagnostic data of the component;

[0006] The OPC UA server of the component discovered by the diagnostic unit;

[0007] The diagnostic unit creates a corresponding data collection unit for the component, and the data collection unit includes an OPC UA client;

[0008] generating, by the diagnosis unit, a configuration file for the data collection unit using the diagnosis metadata;

[0009] The diagnosis unit transmits the configuration file to the data collection unit;

[0010] The diagnosis unit modifies the configuration file of the time series database by adding the URI of the data collection unit;

[0011] Connected to the time series database by the data collection unit;

[0012] delivering diagnostic data of the component to a time series database via a data collection unit; and

[0013] A diagnostic data repository that stores component diagnostic data in a time series database.

[0014] An industrial plant can be configured to produce and / or manufacture substances, such as materials and / or compounds. An industrial plant can include one or more subsystems. Each subsystem can include components (e.g., components of sensors and / or actuators) and / or control units. Examples of sensors can include inductors, capacitors, resistors, and / or optical components, and sensors can be configured to, for example, sense pressure, flow, temperature, distance, and / or changes in these measurements (e.g., speed, acceleration, etc.). Examples of actuators can include pumps, compressors, containers or pressure vessels, storage tanks, heat exchangers, furnaces, fans, cooling towers, valves, etc. Examples of control units can include one or more programmable logic controllers (PLCs).

[0015] Storing diagnostic data in so-called time series databases can be effective because such databases are well optimized for this type of data (i.e., large amounts of data that are typically generated more or less regularly). Examples of time series databases include databases such as InfluxDB, Prometheus, TimeScaleDB, and / or other names or trademarks for time series databases. Unfortunately, these time series databases, in most cases, originate from IT-related fields and are therefore often not well suited for communication with protocols from the production and / or manufacturing world. Therefore, communication between plant components and the time series database often requires many manual steps. However, this approach leverages the fact that newer components in industrial plants support the OPC UA (Open Platform Communications (OPC) Unified Architecture (UA)) protocol and outlines a strategy for automatically configuring the communication paths between components and the time series database.

[0016] Specifically, a component may include an OPC UA server. For example, when a communication path from a temperature sensor is to be established, an OPC UA server may be deployed on a Kubernetes worker node for reading temperature values from the sensor. Diagnostic metadata describing the diagnostic data of the component may then be provided on the OPC UA server. The purpose of the metadata is to identify diagnostic data that an OPC UA client may query, for example, by executing an OPC UA browse command. For example, the metadata may be defined according to one of the OPC UA companion specifications, such as: OPC10000-5: UA Part 5: Information Model,

[0017] https: / / reference.opcfoundation.org / Core / Part5 / v104 / docs / 12.9, or OPC10000-100: Devices

[0018] https: / / reference.opcfoundation.org / DI / v104 / docs / 4.5.4

[0019] https: / / reference.opcfoundation.org / DI / v104 / docs / 4.12

[0020] An example metadata file (in XML format) specifying a (simple) batch of diagnostic data of interest might look like this:

[0021] <UAObject NodeId="ns=1;i=5003"BrowseName="1:MonitoringData">

[0022] <displayname>MonitoringData< / displayname>

[0023] <references>

[0024] <Reference

[0025] ReferenceType="HasTypeDefinition">i=61

[0026] <Reference

[0027] ReferenceType="Organizes">ns=1;i=5006

[0028] ...

[0029] <UAObject SymbolicName="BaseObject"NodeId="ns=1;i=5006"

[0030] BrowseName="1:CPU Usage">

[0031] <displayname> CPU Usage< / displayname>

[0032] <description> Monitoring Item< / description>

[0033] <references> ...< / references>

[0034]

[0035] <UAVariableDataType="String"ParentNodeId="ns=1;i=5001"

[0036] NodeId="ns=1;i=6003"BrowseName="NamespaceUri">

[0037] <displayname> NamespaceUri< / displayname>

[0038] <references> ...< / references>

[0039] <value>

[0040] <uax:string> http: / / yourURI.org / Test1 / < / uax:string>

[0041] < / value>

[0042]

[0043] <UAVariableDataType="IdType"ParentNodeId="ns=1;i=5001"

[0044] ValueRank="1"NodeId="ns=1;i=6005"ArrayDimensions="0"

[0045] BrowseName="StaticNodeIdTypes">

[0046] <displayname> StaticNodeIdTypes< / displayname>

[0047] <references> ...< / references>

[0048]

[0049] From this example it is clear what the structure of the metadata file looks like, how the diagnostic data of interest is defined, and / or how links (URIs) to other entities are defined. In the example shown above, the OPC UA address space could look like this:

[0050] Folder:"MonitoringData"

[0051] MonitoringItem:"CPU Usage"

[0052] MonitoringItem:"Interactions per second"(not shown above)

[0053] MonitoringItem:"Mem Usage"(not shown above)

[0054] The diagnostic unit can then discover the OPC UA server of the component. This can be done periodically, for example, once a day, once per shift, etc. Additionally or alternatively, this can be done when a new component is deployed to an industrial plant or subsystem of interest, in this way enabling automatic discovery of the component's OPC UA server to retrieve its diagnostic data. This discovery process for new OPC UA servers can use OPC UA local or global discovery services, for example, using multicast DNS messages (mDNS). As an example, an OPC UA server can announce its presence in a Kubernetes cluster using mDNS, which is received by the diagnostic unit, which is configured to listen for such messages. The diagnostic unit can include an OPC UA client; for example, this can be implemented using the Open62531 OPC UA SDK.

[0055] The diagnostic unit can then create a corresponding data collection unit for the component. For example, for the component "Field Device #1," a data collection unit "Diagnostic Collector #1" can be created. The data collection unit can include an OPC UA client for communicating with the component's corresponding OPC UA server. This creation can include generating, installing, and starting a corresponding data collection unit for each newly discovered OPC UA server. In other words, after discovering a new OPC UA server, the diagnostic unit can use the newly created OPC UA client to connect to the component's OPC UA server. This connection can include appropriate authentication and authorization procedures.

[0056] This creation can be achieved, for example, by creating a configuration file for each data collection unit, which includes the specific OPC UA endpoint and the remembered OPC UA server node address. The server node address can be included in the configuration file. An OPC UA browse command can then be executed to navigate to the diagnostic data metadata and read the node ID for each node of the component (i.e., effectively, for each OPC UA server). Using the list of node IDs, the diagnostic unit can then generate a configuration file for the data collection unit, which contains the endpoint URL (i.e., the address of the OPC UA server) and the list of node IDs. The diagnostic metadata can be used, for example, to generate the configuration file for the data collection unit. This can include browsing all node IDs of the OPC UA servers, collecting their addresses, and including them in a configuration file that specifies which nodes are subscribed to updates. "Updating" can refer to obtaining the new value of a node. For example, if the diagnostic data for a node refers to the number of logged-in OPC UA clients, then the current value of that node can be requested based on a predefined subscription rate (e.g., 1000 milliseconds) (e.g., to detect that there are now 5 clients connected to the server instead of 4). The diagnostic unit may then transmit the configuration file to the data collection unit, or to each of the data collection units individually.

[0057] Afterwards (or in a variant, in parallel with at least one of the preceding steps), the configuration file of the "crawler" of the time series database (Time Series DB Crawler) needs to be modified. For this purpose, at least the URI of the data collection unit (also called "OPC UA Exporter" for this purpose) is added to said configuration file, for example, to the Kubernetes ConfigMap of the time series database. For example, the URI of the data collection unit can be a REST (Representational State Transfer) endpoint. In other words, the reconfiguration of the Time Series Database Crawler (in order to include the OPC UA server of the new component) is therefore done in reaction to the addition of the new component. Note that this step can be performed at runtime when all components are already running. Note also that the reconfiguration of the crawler may not require a restart of the time series database.

[0058] An example of a configuration file for a time series database "scraper" might look like this, for example, written in YAML (another markup language):

[0059] apiVersion:monitoring.coreos.com / v1

[0060] kind:Prometheus

[0061] metadata:

[0062] name:prometheus

[0063] labels:

[0064] prometheus:prometheus

[0065] spec:

[0066] replicas:2

[0067] serviceAccountName:prometheus

[0068] serviceMonitorSelector:

[0069] matchLabels:

[0070] team:frontend

[0071] additionalScrapeConfigs:

[0072] name:additional-scrape-configs

[0073] key:prometheus-additional.yaml

[0074] The data collection unit can then be prepared to connect to the time series database. In implementation, the OPC UA exporter can be started by Kubernetes as a container. After it is started, the OPC UA exporter can immediately try to connect to the configured OPC UA endpoint (e.g., the component's OPC UA server) using its included OPC UA client. A single OPC UA server can expose several endpoints on different ports, thereby exposing different parts of the address space. By connecting to the endpoint, a connection to the OPC UA server can be established. The time series database has a "custom crawler" (Time Series DB Crawler) that can be read via the OPC UA exporter's REST interface, but cannot read the OPC UA server directly.

[0075] After completing the preceding steps, the component's diagnostic data can be delivered to the time series database via a data collection unit or OPC UA exporter. For example, the data collection unit "Diagnostic Collector #1" can obtain diagnostic data for the component "Field Device #1" every 10 seconds. This data is exposed via a REST endpoint, from which a regularly running time series database crawler can retrieve the data. The component's diagnostic data can then be stored in the time series database's diagnostic data repository. The time series database's diagnostic data repository can serve as the basis for further processing and / or other uses of this data. The diagnostic data repository can include optimizations for fast data access, such as creating indexes for fast queries.

[0076] By using this method, the collection of diagnostic and / or monitoring data for plant components can be automatically established. This method makes the diagnostic data of a component's OPC UA server available to time-series databases that are not aware of the OPC UA communication standard. This not only significantly reduces the effort required to connect and / or transfer the component's diagnostic data to the database, but also ensures that this connection is well-defined, thus avoiding potential configuration errors, particularly in complex systems such as industrial plants. Furthermore, advantageously, only the diagnostic unit's OPC UA client needs to be modified, while the component's OPC UA server can remain unchanged (i.e., no modifications are required).

[0077] In various embodiments, the method further comprises the step of processing data of the diagnostic data repository, wherein processing the data comprises one of:

[0078] Data is displayed using visualization units. The displayed data can be analyzed for outliers and anomalies. Multiple time series can be compared and common events and anomalies can be detected, which supports root cause analysis of failures.

[0079] When at least one of the data in the diagnostic data repository exceeds a predefined threshold,

[0080] Output an alert. For example, this output could include sending a message to a control center. Alternatively, in addition to displaying the data, an alert function could be attached to the data display, allowing the user to be notified when a critical threshold violation occurs. This could be connected to an alert function attached to the data to notify the user of an anomaly.

[0081] Correlate the data of the diagnostic data repository with the data of the measurement data repository. For example,

[0082] This can be used to perform root cause analysis in the event of a failure, or to e.g.

[0083] Optimize by knowing the typical maximum load (e.g. of a processor or communication path)

[0084] system and / or its components.

[0085] • Storing the important associations in another database. The important associations can be determined by a post-processing ANN, which can be trained to recognize which associations should be considered important.

[0086] When a new component is added to the industrial subsystem, at least some of the steps of the method are performed.

[0087] In various embodiments, the diagnostic data includes one of the following:

[0088] Server diagnostics. This can include:

[0089] Server Status: Information about the current status of the server, including the start time, current time, and status (running, stopped, etc.).

[0090] Server Capabilities: Details about the server's capabilities, such as supported protocols and data types.

[0091] Session diagnostics: Information about current and past client sessions, including session ID, client details, and session duration.

[0092] Subscription Diagnostics: Details about data subscriptions, including subscription ID, monitored items, and update rates.

[0093] Session Security Diagnostics: Information about the security settings for each session, including encryption and authentication details.

[0094] Communication diagnostics. This can include:

[0095] Network statistics: Information about network usage, including bandwidth, error rates, and packet loss.

[0096] Transport Diagnostics: Details about the transport protocol used for communications, including any errors or problems.

[0097] Message Count: The number of sent and received messages categorized by message type.

[0098] Security Token Diagnostics: Information about the security tokens used for session authentication and encryption.

[0099] Performance diagnostics. This can include:

[0100] CPU Usage: The CPU usage percentage of the OPC UA server.

[0101] Memory usage: The amount of memory used by the server.

[0102] Thread Count: The number of threads the server is using.

[0103] Latency statistics: Latency information for read / write operations and data updates.

[0104] Data diagnostics. This can include:

[0105] Variable Diagnostics: Information about server variables, including data type, value, and quality.

[0106] Data change count: Data change count of monitored variables.

[0107] Event Count: Count of events triggered and processed by the server.

[0108] Security diagnostics. This can include:

[0109] Security audit log: A log of security-related events, such as login attempts, configuration changes, and security token issues.

[0110] Active Sessions: A list of currently active sessions, including their security settings.

[0111] Rejected Session Count: The count of session creation attempts that were rejected due to security policy.

[0112] Error and event logs. This can include:

[0113] System Errors: Logs of system-level errors and exceptions.

[0114] Application Errors: Logs of application-level errors and exceptions.

[0115] Audit events: Logs of important events and operations for auditing purposes.

[0116] Diagnostic data used to control the logic execution engine:

[0117] In various embodiments, the metadata includes an address space folder with a predefined name, an address space with a predefined name, and / or a dedicated OPC UA endpoint on the OPC UA server. Examples of address space folders with predefined names may include specially named address space folders (e.g., "Device Health," "Server Diagnostics"). Examples of address spaces with predefined names may include specially named address space nodes (e.g., prefixed with "diag" or suffixed with "health"). A dedicated OPC UA endpoint on the OPC UA server may be dedicated to diagnostic data. For example, a specially named folder "Diagnostic Metrics" may be used as diagnostic metadata. A configuration file is then generated that includes all node IDs in this folder (and also recursively in subfolders).

[0118] In various embodiments, generating the corresponding data collection unit is performed by creating a configuration file that includes the specific OPC UA endpoint of the data collection unit and the node address of the data collection unit. Additionally or alternatively, other methods can be used to provide the endpoint, such as command line parameters. The configuration file can be written in YAML (another markup language) and can look like this:

[0119] -nodeName:ns=1;s=Voltmeter

[0120] metricName:circuit_input_volts

[0121] -nodeName:ns=1;s=Ampmeter

[0122] metricName:circuit_input_amps

[0123] -nodeName:ns=1;s=CircuitBreakerStates

[0124] extractBit:3#means:pull just bit 3from a bit-vector channel

[0125] metricName:circuit_breaker_three_tripped

[0126] The expression "nodeName" can define an OPC UA node ID, "ns=1" can define an OPC UA namespace ID (i.e., "namespace=1"), and "s=Voltmeter" can be an example of a node identifier in the OPC UA server address space. Based on the constraints on metric names in the time series DB, the expression "metricName" can be a metric name in the time series DB, and "circuit_input_volts" can be a string generated as the metric name for this node ID.

[0127] In various embodiments, the OPC UA endpoint of the data collection unit is a REST (Representational State Transfer) endpoint and / or a SOAP (Simple Object Access Protocol) endpoint.

[0128] In various embodiments, the transfer of the configuration file to the data collection unit is performed by injecting a sidecar into the Kubernetes pod, which modifies the pod configuration of the component's OPC UA server. The so-called sidecar injection can modify the pod configuration of the OPC UA server by querying the kubeapi server on port 6443. Specifically, it can add another container to the pod configuration, in this case an instance of the open-strateos OPC UA exporter packaged as a Docker container, and configure it according to the previously created configuration file. This sidecar container serves as the data collection unit, for example, "Diagnostic Collector #1" in the example scenario. After saving this configuration, Kubernetes can start the OPC UA exporter container.

[0129] In various embodiments, delivering diagnostic data is done on demand or periodically. The time interval for sending data can be configurable. For example, open-strateos / OPC UA_exporter has a command line parameter called "-summary-interval" for this purpose. In addition, the scraping interval of a time series database is also configurable, for example, "scraping_interval" for a Prometheus database. The time interval can be one of the following: 1 second, 2 seconds, 5 seconds, 10 seconds, 60 seconds, and / or other time intervals. With OPC UA, on-demand delivery is generally not possible because an OPC UA client registers a session with an OPC UA server and the update rate is the same for each subscription. However, it is possible to set a shorter update rate to oversample the actual values from the server, which can then be treated as a "virtual" on-demand delivery to the user because the time interval for the updates is very short.

[0130] In some embodiments, the diagnostics collector may need to map OPC UA address space node names to a naming format supported by the time series database. For example, some time series databases do not support spaces or special characters in their metric names, which are permitted in OPC UA. Furthermore, the diagnostics unit can prefix the metric names with a unique identifier, allowing diagnostic data from multiple OPC UA servers with identical address space structures to be integrated into the time series database and still be uniquely identified.

[0131] In various embodiments, the components are sensors, actuators, and / or control units. In at least some plants, programmable logic controllers (PLCs) may also serve as components and / or subsystems.

[0132] One aspect relates to a diagnostic unit configured to provide, collect, store, and / or analyze diagnostic data of a plurality of components according to any of the aforementioned aspects.

[0133] One aspect relates to a method for using the diagnostic unit described above and / or below to collect, store, and / or diagnose data of multiple components for supporting fault analysis of an industrial subsystem, for predicting maintenance of at least one component, and / or for optimizing a logging strategy for diagnostic data.

[0134] One aspect relates to a computer program product comprising instructions which, when executed by a computer and / or a controller in the above-mentioned and / or below-mentioned diagnostic unit, cause the computer and / or the controller to perform the above-mentioned and / or below-mentioned method.

[0135] One aspect relates to a computer-readable storage medium in which the above-mentioned computer program or computer program product is stored.

[0136] For further explanation, the present disclosure is described with reference to the embodiments shown in the accompanying drawings. These embodiments are to be regarded as examples only and not as limitations. BRIEF DESCRIPTION OF THE DRAWINGS

[0137] The accompanying drawings depict:

[0138] Figure 1 Schematically illustrates a scenario in which the method according to the embodiment is performed in an industrial plant;

[0139] Figure 2 Schematically shows a flow chart according to an embodiment;

[0140] Figure 3 Schematically illustrates an example of deploying system components into containers and pods;

[0141] Figure 4 Schematically illustrates a high-level view of a Kubernetes cluster according to an embodiment;

[0142] Figure 5 An example of visualization is schematically shown. DETAILED DESCRIPTION

[0143] Figure 1 A scenario for executing a method according to an embodiment in an industrial plant is schematically shown. The industrial plant includes at least a plurality of components 200.1, 200.2, 200.3. Components 200.1, 200.2, 200.3 may be one or more sensors, actuators, and / or control units. For example, component 200.1 is a temperature sensor, referred to as "field device #1." Each of components 200.1, 200.2, 200.3 has a corresponding OPC UA server 202.1, 202.2, 202.3. Each of components 200.1, 200.2, 200.3 may deliver diagnostic data 240.1, 240.2, 240.3.

[0144] The scenario also includes a diagnostic unit 100. The diagnostic unit 100 may include a diagnostic collector installer 110. The diagnostic collector installer 110 may include a processor, a memory, etc. (not shown), which are configured to perform at least a portion of the above-mentioned and / or below-mentioned methods. The diagnostic unit 100 may also include multiple data collection units, such as "Diagnostic Collector #1" 120.1, "Diagnostic Collector #2" 120.2, "Diagnostic Collector #3" 120.3, and / or other data collection units. The data collection units include corresponding OPC UA clients 122.1, 122.2, 122.3 and corresponding configuration files 124.1, 124.2, 124.3.

[0145] Furthermore, the scenario includes a time series database 300. The time series database 300 has a diagnostic data repository 340 and (at least optionally) a measurement data repository 360. The time series database 300 also has a time series database "crawler" (time series DB crawler 310), which can serve as an entry point for data to be stored in one of the repositories 340, 360. The time series DB crawler 310 is configurable via a configuration file (ConfigMap 320). The data from the diagnostic data repository 340 can be further processed by a processing unit 400, which can include a visualization unit 420.

[0146] Figure 2 A flowchart 500 is shown that describes a process according to an embodiment. Figure 1 How entities can interact. Flowchart 500 outlines a computer-implemented method for providing diagnostic data 240.1 of a component 200.1 in an industrial plant, the component 200.1 including an OPC UA server 202.1. In step 502, diagnostic metadata is provided on the OPC UA server 202.1 of the component 200.1. The following steps are performed each time a component 200.1 is added to the industrial plant. The diagnostic metadata describes the diagnostic data 240.1 of the component 200.1. In step 504, the diagnostic unit 110 discovers the OPC UA server 202.1 of the component 200.1, for example by using mDNS (multicast DNS messages). In step 506, the diagnostic unit 110 creates a corresponding data collection unit 120.1 for the component 200.1. The data collection unit 120.1 includes an OPC UA client 122.1. In step 508, the diagnostic unit 110 generates a configuration file 124.1 for the data collection unit 120.1. This generation is performed using diagnostic metadata. In step 510, the diagnostic unit 110 transmits the configuration file 124.1 to the data collection unit 120.1. In step 512, the diagnostic unit 110 modifies the configuration file 320 of the time series database 300 by adding the URI of the data collection unit 120.1. Steps 504–512 can be repeated when a new component 200.x is inserted into the plant (and / or triggered by another event). In step 514, the data collection unit 120.1 connects to the time series database 300. In step 516, the diagnostic data 240.1 of the component 200.1 is delivered to the time series database 300 via the data collection unit 120.1. In step 518, the diagnostic data 240.1 of the component 200.1 is stored in the diagnostic data repository 340 of the time series database 300. In optional step 520 , the data in the diagnostic data repository 340 is processed (eg, visualized).

[0147] Figure 3 Schematically illustrates an example of deploying system components into containers and pods. Figure 3 Several host nodes are shown for each of the participating entities (such as the diagnostic unit, the time series database, etc.). An operating system (e.g., Linux Ubuntu) is running on all host nodes. On top of it, a container runtime is installed, i.e., a middleware (sometimes called an "orchestrator") that serves as the basis for the container. The program parts specific to the entity each run in a so-called "pod" (i.e., K8spod). Specifically, the diagnostic unit 100 includes two containers: an "OPC UA container" 122.1 and a "diagnostic collector" 120.1. The "diagnostic collector" 120.1 is implemented as a sidecar of the "OPC UA container" or a "sidecar injection of the Kubernetes pod." The sidecar injection can modify the pod configuration of the component's OPC UA server. The advantage of being implemented as a sidecar is that it is a fairly small program part and therefore only requires a small amount of memory. In addition, the installation of the sidecar is simple and quick.

[0148] Figure 4 A high-level view of a Kubernetes cluster according to an embodiment is schematically shown. To set up the Kubernetes cluster, three Linux machines (one as a control plane node and two as worker nodes) are set up by installing the Ubuntu operating system and an SSH server for remote access. All machines are connected via a network and reside in the same subnet, allowing them to communicate with each other via TCP / IP.

[0149] Figure 5 This diagram schematically illustrates an example visualization. The straight line labeled "Metric 1" represents a metric value over time (e.g., approximately 30 minutes in this case). In this diagram, it could represent a diagnostic value, such as a server node's CPU utilization or the number of logins to an OPC UA server. The dashed line labeled "Metric 2" could represent another metric value. Using this visualization alongside the straight lines, experts can identify correlations between the two diagnostic data lines.

[0150] List of reference numerals

[0151] 100 diagnostic units

[0152] 110 Diagnostic Collector Installer

[0153] 114 configuration files

[0154] 120.i Data Collection Unit

[0155] 122.i OPC UA Client for Data Collection Unit

[0156] 124.i Configuration file of data collection unit

[0157] 200.i component

[0158] OPC UA server for 202.i components

[0159] 240.i component diagnostic data

[0160] 300 time series database

[0161] 310 Time Series Database Crawler

[0162] 320 Configuration file ConfigMap

[0163] 340 diagnostic data repository

[0164] 360 measurement data repository

[0165] 400 processing units

[0166] 420 visualization units

[0167] 500 Flowchart

[0168] Steps 502–520< / references>

Claims

1. A computer-implemented method for providing diagnostic data (240.1) of a component (200.1) in an industrial plant, the component (200.1) comprising an OPC UA server (202.1), the method comprising the following steps: providing diagnostic metadata on the OPC UA server (202.1), the diagnostic metadata describing the diagnostic data (240.1) of the component (200.1); When the component (200.1) is added to the industrial plant: discovering the OPC UA server (202.1) of the component (200.1) by the diagnostic unit (110); The diagnostic unit (110) creates a corresponding data collection unit (120.1) for the component (200.1), wherein the data collection unit (120.1) includes an OPC UA client (122.1); The creation includes generating, installing, and starting a corresponding data collection unit (120.1) for each newly found OPC UA server (202.1); The diagnostic unit (110) uses the newly created OPC UA client (122.1) to connect to the OPC UA server (202.1) of the component; generating a configuration file (124.1) for the data collection unit (120.1) by the diagnostic unit (110) using the diagnostic metadata, the configuration file (124.1) including a specific OPC UA endpoint and a remembered OPC UA server node address; The configuration file (124.1) is transmitted by the diagnosis unit (110) to the data collection unit (120.1); The diagnosis unit (110) modifies a configuration file (320) of a time series database (300) by adding a URI of the data collection unit (120.1); The data collection unit (120.1) is connected to the time series database (300); delivering the diagnostic data (240.1) of the component (200.1) to the time series database (300) via the data collection unit (120.1); and The diagnostic data (240.1) of the component (200.1) is stored in a diagnostic data repository (340) of the time series database (300).

2. The method according to claim 1, further comprising the steps of: Processing the data of the diagnostic data repository (340), wherein processing the data comprises at least one of: displaying said data by a visualization unit (400), outputting an alarm when at least one of the data in the diagnostic data repository (340) exceeds a predefined threshold; correlating said data of said diagnostic data repository (340) with data of a measurement data repository (360); and / or Store important associations in another database.

3. The method according to claim 1, The diagnostic data includes at least one of the following: Server diagnostic data; Communication diagnostic data; performance diagnostic data; diagnostic data details; Security diagnostic data; Data from error and event logs; and / or Diagnostic data used to control the logic execution engine.

4. The method according to claim 1, The metadata includes an address space folder with a predefined name, an address space with a predefined name, and / or a dedicated OPC UA endpoint on the OPC UA server.

5. The method according to claim 1, The generation of the corresponding data collection unit (120.1) is performed by creating a configuration file (114), wherein the configuration file (114) includes a specific OPC UA endpoint of the data collection unit (120.1) and a node address of the data collection unit (120.1).

6. The method according to claim 5, The OPC UA endpoint of the data collection unit (120.1) is a REST endpoint and / or a SOAP endpoint.

7. The method according to claim 1, The transmission of the configuration file to the data collection unit (120.1) is performed by a sidecar injection into a Kubernetes pod, which modifies the pod configuration of the OPC UA server (202.1) of the component (200.1).

8. The method according to claim 1, Wherein delivering diagnostic data (240.1) is done on demand or periodically.

9. The method according to claim 1, The component (200.1) is a sensor or an actuator.

10. A diagnostic unit (100) configured for providing, collecting, storing, and / or analyzing diagnostic data (240.1, 240.2) of a plurality of components (200.1, 200.2) according to any one of the preceding claims.

11. Use of a diagnostic unit (100) according to claim 10 for collecting, storing, and / or diagnosing data (240.1, 240.2) of a plurality of components (200.1, 200.2), for supporting fault analysis of industrial subsystems, for predicting maintenance of at least one of the components (200.1, 200.2), and / or for optimizing a logging strategy for the diagnostic data.

12. A computer program product comprising instructions which, when executed by a computer and / or a controller in a diagnostic unit (100) according to claim 11, cause the computer and / or the controller to perform the method according to any one of claims 1-9.

13. A computer-readable storage medium having stored thereon the computer program product according to claim 12.

Images