CN111742271A - Signal and event processing engine - Google Patents

Abstract

A signal and event processing, SEP, engine (SEPE) deployed on a Target Device (TD) of an industrial system (1), the SEP engine comprising: a subscriber node (SUBN) adapted to receive a signal and/or event SE data stream from a source of the industrial system (1); a Processing Node (PN) adapted to perform Signal and Event Processing Language (SEPL) function operations on a received SE data stream according to a SEPL script of the SEP engine, wherein the SEPL script includes predefined stateful events or data pattern matching operations to generate a resultant SE data stream; and a publisher node (PUBN) adapted to forward the generated result SE data stream to a sink of the industrial system (1).

Description

Signal and event processing engine

The present invention relates to a signal and event processing engine that can be deployed and executed on a target device of an industrial system.

Industrial systems may include multiple machines and/or machine components that may be monitored based on signal or event data streams. An industrial system can include a number of different industrial assets. For example, for oil and gas platforms, industrial systems may include: gas turbines and other components, such as bearing equipment, gear equipment, or pumps, where sensor signal sources generate sensor data streams that can be collected by distributed applications to generate observation events time series. Sensors or field instruments (such as programmable logic controllers) can generate data that can be processed and analyzed in an online mode (ie, near real-time processing) or in an offline mode (ie, batch processing).

In the field of PLC programming, it is common to write programs in special applications on personal computers using, for example, function block diagrams FBD, ladder logic diagrams LD, structured text ST, instruction lists IL or sequential function charts SFC. Field engineers, operators, and maintenance engineers of industrial assets most familiar with industrial systems may have some knowledge of PLC programming languages. However, PLC programming languages are not suitable for solving most condition monitoring tasks via stream processing because they do not include features available in the field of analysis. Data processing tools in the field of data analysis are more suitable for data flow analysis. The field of data analysis consists of a wide variety of technologies and can be implemented as application programming interface APIs using general-purpose programming and query languages such as Structured Query Language (SQL), Scala, Python, Java, C++. Because application programming interface APIs are designed to solve standard stream processing tasks, they provide generic events, basic event operations, temporal event operations, and/or event processing networks.

In order to perform condition-based maintenance and condition monitoring of industrial systems, and in order to perform diagnostic tasks, it is necessary to detect patterns in the data or event streams provided by signal sources within the industrial system. Conventional pattern making tools or matching procedures are written using tools familiar to experts in the field of data analysis, but unfamiliar to field engineers, operators, or maintenance engineers with specific asset knowledge of the industrial system. For example, field engineers are often unfamiliar with processing languages such as Python, Scala, and Java, or the structured query language SQL. On the other hand, data analysis experts usually have little knowledge of the industrial assets of the corresponding industrial system. As a result, the development of pattern recognition procedures is tedious, complex and time-consuming, requiring intensive interaction between field engineers, operators and data analysis experts. Furthermore, the resulting analysis programs that can be used for data and/or event pattern matching include a large footprint and cannot be easily deployed on target devices with limited resources. The resulting data analysis program does not include optimal performance due to the relatively poor knowledge of the data analysis experts regarding the assets of the industrial system.

Accordingly, it is an object of the present invention to provide an apparatus and method for processing signal and/or event data streams that simplifies pattern matching and improves the performance of pattern matching within signal and/or event data streams of industrial systems.

This object is achieved according to a first aspect of the invention by a signal and event processing SEP engine comprising the features of claim 1 .

According to a first aspect, the present invention provides a signal and event processing SEP engine deployed on a target device of an industrial system,

The SEP engine includes:

a subscriber node adapted to receive a signal and/or event SE data stream from a source of said industrial system,

a processing node adapted to perform signal and event processing language SEPL function operations on the received SE data stream according to a SEPL script of the SEP engine, wherein the SEPL script includes predefined stateful events or data pattern matching operations, to generate the resulting SE data stream; and

A publisher node, which is adapted to forward the generated resulting SE data stream to a sink of the industrial system.

In a possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, each node of the SEP engine deployed on said target device is adapted to execute an associated function forming part of a SEPL script operation, wherein the function operation includes a stateless function SEPL operation or a stateful function SEPL operation.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, each processing node of the deployed SEP engine is adapted to respond to data received by at least one subscriber node, or received by at least one The SE data stream output by the previous processing node applies the predefined SEPL function operation, and the resulting SE data stream is delivered to the subsequent processing node and/or publisher node of the deployed SEP engine.

In still further possible embodiments of the signal and event processing SEP engine according to the first aspect of the invention, the SE data stream comprises a signal data stream generated by a signal generating source of an industrial system, and/or generated by an event of an industrial system A stream of event data generated by the source.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the event data stream comprises a time series of events containing features represented as key-value pairs.

In still further possible embodiments of the signal and event processing SEP engine according to the first aspect of the invention, the signal data stream comprises a sensor data stream provided by sensors forming the source of the industrial system.

In a still further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the nodes of the deployed SEP engine form a SEP network comprising a directed acyclic graph DAG.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the deployed SEP engine is implemented as a software component or as a hardware component and is deployed in forming part of said industrial system or connected to the target device of the industrial system.

In still further possible embodiments of the signal and event processing SEP engine according to the first aspect of the invention, the target device on which the SEP engine is deployed comprises a programmable logic controller PLC, a computer, a computer cluster, Client, server, control unit, or cloud unit connected to the network cloud of the industrial system.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, a source adapted to provide SE data streams to subscriber nodes of the deployed SEP engine and/or adapted to receive The sinks of the resulting SE data stream generated from the publisher node of the SEP engine include entities containing other SEP engines, servers, clients, computers and/or databases of the industrial system.

In a still further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the SEP engine deployed on the target device is configured to communicate with others deployed in the industrial system by means of an event message broker communicate with other SEP engines on the target entity or device.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the SEPL script of the SEP engine is loaded from a SEPL script library stored in a domain-specific or cross-domain knowledge database, and A corresponding target device for the industrial system is instantiated.

In still further possible embodiments of the signal and event processing SEP engine according to the first aspect of the invention, the deployed SEPL script of the SEP engine comprises: one or more predefined stateful function SEPL window event pattern matching operations, Each operation is adapted to validate an event pattern for recorded and stored SE data within a stream of SE data received from subscriber nodes of the batch SEP engine for a sliding time window with a configurable time window length The historical data of the stream is mined to generate matching results to form the resulting SE data stream output by the publisher node of the deployed batch SEP engine.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the deployed SEPL script of the SEP engine comprises: one or more predefined stateful function SEPL delay operations, each operation being adapted to delay the SE data stream received by the subscriber node of the SEP engine by a configurable delay period to provide a delayed SE data stream, which is served by the deployed SEP engine publisher node as a result SE Data stream output.

In another possible embodiment of the signal and event processing SEP engine according to the first aspect of the present invention, the SEPL script includes stateless function SEPL operations in addition to stateful function events or data pattern matching or delayed SEPL operations, so The stateless function SEPL operations include: subscriber SEPL operations, constant definition SEPL operations, conversion SEPL operations, SE data stream merging SEPL operations, arithmetic function operations with one or more arguments, selection SEPL for selecting features from SE data streams Operations, String Processing SEPL Operations, Data Time SEPL Operations, and Post SEPL Operations.

In a further possible embodiment of the signal and event processing SEP engine according to the first aspect of the invention, the predefined SEP engines provided for different language types including C++, C#, Java are stored together with the associated SEPL script library in Knowledge database, where the appropriate SEPL engine is loaded, instantiated and deployed on the target device of the industrial system.

According to a further second aspect, the present invention further provides a system condition monitoring SCM and/or condition-based maintenance CBM platform, the platform comprising: one or more SEP engines according to the first aspect of the present invention, wherein said The SCM/CBM rules of the platform are written as SEPL scripts of the SEP engine deployed on the target device of the industrial system.

According to a third aspect, the invention further provides a target system comprising the features of claim 18 .

According to a third aspect, the present invention provides a target device for an industrial system, comprising: at least one SEP engine according to the first aspect of the present invention, instantiated and deployed on the target device, wherein the deployed The SEP engine may be executable to perform on-line and/or off-line processing of SE data streams received from the sources of the industrial system to generate the resulting SE data streams, which are forwarded to the sinks of the industrial system.

According to a fourth aspect, the invention further provides a method for processing a signal and/or event SE data stream of an industrial system, the method comprising the features of claim 19 .

According to a fourth aspect, the present invention provides a method for on-line and/or off-line processing of signal and/or event SE data streams of an industrial system,

The method includes the following steps:

Receive SE data streams from sources in industrial systems,

According to the SEPL script of the signal and event SEP engine deployed on at least one target device of the industrial system, the signal and event processing language SEPL function operation is performed on the received SE data stream,

where the SEPL script includes predefined stateful events or data pattern matching operations to generate the resulting SE data stream, and

The resulting SE data stream is forwarded to the sink of the industrial system.

In the following, possible embodiments of the different aspects of the invention are described in more detail with reference to the accompanying drawings.

Figure 1 illustrates an exemplary industrial system in which one or more SEP engines in accordance with the present invention may be deployed;

Figure 2 shows a schematic diagram of a possible exemplary embodiment of a signal and event processing SEP engine according to an aspect of the present invention;

Figure 3 shows a flowchart of a possible exemplary embodiment of a method for processing signal and event data streams of an industrial system according to a further aspect of the present invention;

4 shows a schematic diagram illustrating possible exemplary windowing operations that may be performed by a signal and event processing SEP engine according to an aspect of the present invention;

5 shows additional schematic diagrams illustrating possible exemplary windowing operations that may be performed by a signal and event processing SEP engine according to an aspect of the present invention;

6 shows additional schematic diagrams for illustrating possible exemplary embodiments of windowing operations that may be performed by a signal and event processing SEP engine according to an aspect of the present invention;

7 shows a further schematic diagram illustrating possible exemplary windowing operations that may be performed by a signal and event processing SEP engine according to an aspect of the present invention;

8 shows additional schematic diagrams illustrating possible exemplary windowing operations that may be performed by a signal and event processing SEP engine according to an aspect of the present invention;

9 shows a further schematic diagram illustrating possible exemplary delay operations that may be performed by a signal and event processing SEP engine according to an aspect of the present invention;

10 shows a further schematic diagram illustrating possible exemplary delay operations that may be performed by a signal and time processing SEP engine according to an aspect of the present invention;

Figures 11, 12 illustrate simple examples of SEPL scripts that can be implemented by a SEP engine according to the present invention.

As can be seen in the schematic diagram of FIG. 1 , the illustrated exemplary industrial system 1 shown in FIG. 1 may include a number of components, including hardware components and/or software components. The industrial system 1 may include machines and machine components that interact with each other. In the illustrated exemplary industrial system 1, a drive train is provided that includes a drive 1-1, a gear assembly 1-2, a bearing 1-3, and a pump 1-4. Each component of the industrial system 1, such as the illustrated drive train, may include one or several signal sources. The signal sources may include sensors that generate sensor data for the system during operation of the industrial system 1 . As illustrated in FIG. 1 , the different sensors may provide analog signals or digital sensor data to the control unit of the industrial system 1 . In the example shown in Fig. 1, two sensor signal sources 2A-1, 2B-1 provided at the drive unit 1-1 of the industrial system 1 provide sensor signals to a controller 3, such as a SIMATIC S7 control unit. In addition, the signal sources 2A-2, 2B-2 provided at the gear unit 1-2 of the industrial system 1 provide the data stream to the controller 3 of the industrial system 1 . In the illustrated example, the local controller 3 of the industrial system 1 further receives sensor signals from sensors 2-4 provided at the pump units 1-4 of the industrial system 1 . The type of sensor or signal source can vary depending on the use case. For example, sensors may include vibration sensors, temperature or pressure sensors that provide analog sensor signals, which are converted into signal data streams by an analog-to-digital converter ADC. Additionally, a local programmable logic controller PLC may be provided that aggregates observations into events that are provided to the local controller 3 of the industrial system 1 . A local controller 3, such as a SIMATIC S7, can be connected via the bus 4 to a platform 5 comprising CMS tools for carrying out data analysis. Additionally, a computer or SCADA entity 6 may be connected to the common bus 4 of the industrial system 1 . The SCADA entity 6 may have access to the database. Additionally, as illustrated in Figure 1, the local bus 4 of the industrial system 1 may provide remote access to the background cloud 7, eg via the Internet. The bus 4 of the industrial system 1 may comprise, for example, a PROFINET bus or an Ethernet bus. A local controller or PLC 3 of industrial system 1 may receive event data streams from event data sources of industrial system 1 (eg, from other distributed programmable logic control units PLCs). Additionally, events may be provided to the local controller 3 from entities or units within the cloud 7 , within the SCADA unit 6 or within the analytical processing unit 5 . The industrial system 1 may include one or more signal and event processing SEP engines according to the first aspect of the invention. In a possible embodiment, several signal event processing SEP engines according to the first aspect of the invention are distributed in the industrial system 1 to perform different tasks. In a possible embodiment, the signal and event processing SEP engine is deployed on the target device of the industrial system 1, in particular on a programmable logic controller PLC located close to the machine components 1-i, to process local sensor data, which Can be aggregated into event data streams that are provided to other PLCs of the subsystems of the industrial system 1 . Additionally, as shown in FIG. 1 , one or more signal and event processing SEP engines according to the first aspect of the invention may be implemented in the controller 3 of the industrial system 1 . Other signal and event processing SEP engines may further be deployed on the analytical processing unit 5 , the SCADA device 6 and/or on the entities of the system cloud 7 . Different SEP engines deployed on the same or different target devices of the industrial system 1 are configured to communicate with each other. In a possible embodiment, the SEP engines communicate with each other by means of event message brokers.

FIG. 2 schematically illustrates a possible exemplary embodiment of a signal and event processing SEP engine SEPE deployed on a target device TD of the industrial system 1 . The SEP engine can be deployed on different kinds of target devices TD of Industrial System 1, including Programmable Logic Controllers, PLCs, computers, computer clusters, client devices, server devices, control units of Industrial System 1, or connected to Industrial System 1 1 The cloud unit of the system network cloud. On each target device TD of the industrial system 1, one or more SEP engines may be deployed to perform different tasks. As can be seen in the schematic diagram of Figure 2, the signal and event processing SEP engine SEPE deployed on the target device TD of the industrial system 1 comprises in the illustrated embodiment one or more subscriber nodes SUBN, processing nodes PN and One or more publisher node PUBNs. The number of nodes can vary depending on the use case. As illustrated in FIG. 2 , the signal and event processing SEP engine SEPE comprises several subscriber nodes SUBN adapted to receive signal and/or event SE data streams from sources of the industrial system 1 . The received signal and/or event SE data streams include signal data streams generated by signal generating sources (in particular signal sensors) of the industrial system 1 , and/or event data streams generated by event generating sources of the industrial system 1 . Each SE data stream includes time series data applied to the subscriber node SUBN of the signal and event processing SEP engine. The SEP engine further includes a processing node PN adapted to perform signal and event processing language SEPL function operations on the received SE data stream according to the SEPL script of the SEP engine. SEPL scripts include predefined stateful events or data pattern matching operations to generate the resulting SE data stream. The signal and event processing SEP engine further comprises a publisher node PUBN adapted to forward the generated resulting SE data stream to the sink of the industrial system 1 . Each node of the SEP engine SEPE deployed on the respective target device TD is adapted to perform associated functional operations forming part of the SEPL script. The function operation is a stateless function SEP operation or a stateful function SEP operation, especially an event or data pattern matching function operation. Each processing node PN of the deployed SEP engine is adapted to apply a predefined SEPL function operation to SE data streams received by at least one subscriber node SUBN or output by at least one previous processing node PN, and the resulting The SE data stream is delivered to the subsequent processing node PN and/or the publisher node PUBN of the deployed SEP engine SEPE, as also illustrated in the exemplary embodiment of FIG. 2 . The subscriber node SUBN interprets and verifies the data from the external source and delivers the result to the external sink via the publisher node PUBN. Each node of the SEP network SEP-NET of nodes applies SEP operations to incoming data received from a previous or previous SEPL node or subscriber node SUBN. The result of the processing is delivered to the following SEPL node or publisher node PUBN of the SEPL network. Each node can implement one and only one function SEPL operation. The nodes of the deployed SEP engine form a SEP network SEP-NET comprising a directed acyclic graph DAG, as also shown in the example of FIG. 2 . The SEP engine SEPE illustrated in FIG. 2 may be implemented as a software component or as a hardware component and deployed on the target device TD of the industrial system 1 . The target device TD may form part of the industrial system 1 or may be connected to the industrial system 1 . A source adapted to provide a stream of SE data to a subscriber node SUBN of a deployed SEP engine as shown in Figure 2, and/or adapted to receive the resulting SE data from a publisher node PUBN of the SEP engine The sinks of the flow may include different entities or devices including other SEP engines, servers, clients, computers and/or databases of the industrial system 1 deployed on other target devices. In a possible embodiment, the SEPL script of the SEP engine may be loaded from a SEPL script library stored in a domain-specific or cross-domain knowledge base, and instantiated for the corresponding target device TD of the industrial system 1 . The SEP engine is adapted to execute SEPL scripts. The SEP engine parses the SEPL script and creates a SEP network therefrom. Then, the SEP engine can be started to operate on the incoming SE data stream.

The SEPL script of the deployed SEP engine may include one or more predefined stateful function SEPL window event pattern matching operations, each of which is adapted to verify the event pattern for a sliding time window, from batch processing The records within the received SE data stream received by one or more subscriber nodes SUBN of the SEP engine are mined from the historical data of the stored SE data stream. The sliding time window may include a configurable time window length TWL. Matching is performed to generate matching results that form the resulting SE data stream output by the publisher node PUBN of the deployed batch SEP engine. Deriving some characteristic patterns from historical data, ie, mining. These patterns are formulated as SEPL scripts and verified using a batch SEP engine. The SEPL script can then be deployed for execution in online mode on the target device.

The deployed SEP engine's SEPL script may also include one or more predefined stateful function SEPL delay operations. The SEPL delay operation is adapted to delay the SE data stream received by the subscriber node SUBN of the SEP engine by a configurable delay period to generate a delayed SE data stream, which is the result of the publisher node PUBN of the deployed SEP engine SE data stream output.

In addition to stateful function events or data pattern matching or delayed SEPL operations, the SEPL scripts of the deployed SEP engine SEPE may also include stateless function SEPL operations. These stateless function SEPL operations may include subscriber SEPL operations, constant determination SEPL operations, transform SEPL operations, SE data stream merge SEPL operations, arithmetic function operations with one or more arguments, select SEPL operations to select features from SE data streams Operations, String Processing SEPL Operations, Data Time SEPL Operations, Filter SEPL Operations, and/or Post SEPL Operations. SEPL operations are useful for performing analysis of the received SE data stream. They are easily understood by operators and field engineers with a working knowledge of PLC programming languages. SEP Engine SEPE can be deployed on a running SEP network on different hardware platform classes including, for example, smartphones, servers or clusters. The SEP network SEP-NET may contain multiple processing nodes. Each node of the SEP network can apply a single operation on the data from the previous input node and deliver the result to the output node. In a possible embodiment, predefined SEP engines provided for different language types including C++, C#, Java may be stored in an associated SEPL script library in the knowledge database of system 1, where the appropriate SEP The engine is loaded, instantiated and deployed on the target device TD of the industrial system 1 . To support SEP operations across different hardware platforms, different versions of SEP engines, ie, C++, C#.NET, Java EE, and Apache FLINK-based clustered SEP engines can be provided. Apache FLINK is a processing platform that exposes specialized APIs written in Java for implementing stream processing tasks. The SEP engine can be implemented using APIs on the FLINK platform. Each specific engine can be delivered as a specialized library that implements a standardized API with a set of basic functions required for integration in any software development project. Additionally, each SEP engine can come with a so-called SEP worker application, which is adapted to wrap the library API into a collection of REST services. Using REST services for SEP worker applications is just one possible implementation. Other possibilities include using sockets, a communication bus or any other protocol. The latter feature can form a standardized REST API for all versions of SEP working applications. Libraries, engines and workers are provided to allow rapid integration in almost any condition monitoring application.

The system may include a graphical user interface for creating different kinds of SEP networks implemented in the SEP engine as illustrated in FIG. 2 . Additionally, this interface can be used to configure SEPL operations performed by nodes of the created SEP network. This interface can also be used to test and deploy the created SEP network. The SEP lab application implementing this interface facilitates the rapid development, testing and deployment of the SEP network within the SEP engine. In a possible embodiment, each SEP network can be configured by adding SEPL operations one by one. For each added SEPL operation, it is possible to define an input stream for the previous operation. This operation can be implemented to avoid loops in the SEP network, ensuring that it always includes a directed acyclic graph DAG. Once a working SEP network is ready, the user can load a collection of .csv files with event information. Any type of historical data source can be used without having to use a .csv file. To start the testing process, it is possible to select one of the available SEP worker applications and start the simulation of the event flow from the corresponding .csv file. In a possible embodiment, the SEP lab application can deploy the created SEP network on the SEP worker application via the provided REST service, and can then forward all incoming data streams to it. In a possible embodiment, the SEP lab application can separately collect and visualize all data streams returned from the worker application. The process of developing, testing, and deploying a SEP network using the SEP Lab app is fairly intuitive and seamless. It is possible to form a collection of SEP networks that address the most common condition monitoring tasks, eg for transducers, valves, vanes, pressure pipes, motors, etc. implemented in industrial system 1 . The application of the signal and event processing SEP engine with the implemented SEP network does not require any specific programming knowledge of the field engineer, but only the knowledge of the deficient assets of the industrial system 1 .

Figure 3 shows a flowchart of a possible exemplary embodiment of a method for processing a signal and/or event SE data stream of an industrial system 1 according to a further aspect of the present invention. The illustrated method is adapted to carry out on-line and/or off-line processing of SE data streams of the industrial system 1 . In the illustrated exemplary embodiment, the method includes three main steps.

In a first step S1 , the SEPE receives the SE data stream from the source of the industrial system 1 .

In another step S2, according to the SEPL script of the signal and event SEP engine SEPE deployed on at least one target device TD of the industrial system 1, the signal and event processing language SEPL function operation is performed on the received SE data stream. In a possible embodiment, the SEPL script includes predefined stateful events and/or pattern matching operations, in particular window event pattern matching operations, to generate the resulting SE data stream.

In a further step S3, the resulting SE data stream generated is forwarded by the SEPE to the sink of the industrial system 1 .

According to a further aspect, the present invention provides a system condition monitoring SCM and/or condition-based maintenance CBM platform comprising one or more SEP engines according to the first aspect of the present invention and adapted to implement FIG. 3 method shown in . In the SCM and/or CBM system, the SCM/CBM rules of the platform are written as SEPL scripts of the SEP engine deployed on the target device TD of the industrial system 1 . Improving system performance and reducing system maintenance costs are always important. Therefore, Industrial IoT use cases focus on Condition Monitoring SCM and Condition Based Maintenance SBM, where in-depth domain-specific knowledge is required. The use of a signal and event processing SEP engine according to the present invention allows to provide a powerful SCM/CBM platform that can be configured and run in almost any industrial environment. For example, it is possible to easily retrofit and enhance any existing SCM/CBM solution. In addition, the use of the SEPL tools provided by the signal and event processing SEP engine according to the present invention can provide a comfortable environment for developing and propagating SCM/CBM rules written as SEPL scripts. These SEPL scripts can consume industrial IoT data streams, in particular sensor signals and system logs, and can infer a stream of conclusions about the system status of the industrial system 1, in particular status indications, fault indications and/or failure modes, estimated failure probability , possible root cases, required operational actions and maintenance activities. Such SCM/CBM scripts can be categorized and stored in domain-specific or cross-domain knowledge databases. The present invention provides the possibility of cross-platform deployment. For example, a C++ SEP engine may be used primarily for constrained devices, while a Java/C# SEP engine may be used for commodity computers and servers and corresponding SEP cluster engines in distributed environments. The SEP engine according to the present invention can be easily used by field engineers. In a possible embodiment, a SEP engine according to the present invention may provide a graphical user interface application for creating, testing and deploying SEP networks implemented in the SEP engine. It is possible to use SEP worker applications in the SEP network execution environment. The SEP library is provided to facilitate integration with existing systems. The SEPL language, including the signal and event processing language SEPL function operations, is suitable for numerical and categorical time series processing. The set of SEPL function operations can contain all the operations that field engineers need to develop most condition monitoring tasks in industrial systems. The SEPL language, including SEPL functional operations and SEP tools, can be used to rapidly develop condition monitoring applications in any kind of industrial system 1, such as oil and gas platforms, gas turbines, or production lines.

To optimize data traffic for future industrial IoT applications for condition monitoring tasks, SE data streams can be processed by the signal and event processing SEP engine at the local edge device without sending any unwanted information or data to the system cloud. For example, the processed data stream may include high frequency data from an accelerometer of the industrial system 1 . To provide timely responses to critical condition monitoring and monitoring tasks, SEP worker applications can process events in a streaming fashion and very close to the streaming source of the industrial system. Therefore, the operator does not have to wait for a response from the analyzer in the system cloud. This is important for some real life use cases where internet bandwidth may be limited (eg for offshore platforms).

On each signal and event processing SEP engine, one or several SEPL scripts can be provided, each script including a series of SEPL operations. These SEPL operations include: stateful function event or data pattern matching SEPL operations, and stateless function SEPL operations. The SEPL script includes a predefined stateful function SEPL pattern matching operation adapted to perform pattern matching between historical existing patterns and patterns within the received SE data stream from the source of the industrial system 1 . Pattern matching SEPL operations may include configurable time windows, in particular sliding time windows with configurable time window lengths. Observation windows can be used to collect consecutive sequences of observations. Each function or operation can be used to aggregate a selected feature from observations. Different types of windows can be used, in particular time windows, time batch windows, length windows, length batch windows or custom windows. Aggregators can be applied to selected features of observations. The SEPL window event pattern matching operation can be implemented similarly to the SEPL window aggregation operation. An example of a SEPL window event pattern matching operation is to perform matching of patterns where event A (eg, "shutdown") and another event B (eg, "oil temperature too high") occur within a 5 minute window. Events or features A, B can be in different streams.

A time window may include its time window length TWL as the main parameter. When a new observation or event is received in the data stream, the specified aggregator can be applied using all observations received in the last time window length TWL interval. The possible modes of operation of the time window are illustrated in FIG. 4 . As illustrated in Figure 4, an input SE stream comprising events A, B, C, D, H is processed to generate an output SE stream.

A SEPL node adapted to provide time windowing operations may include the following structure:

The following parameters must be filled in:

• _input_stream_name: the name of the stream that must be used as input;

• _output_stream_name: a string value representing the name of the output stream;

• _operation: A string value representing the name of the operation. For the time window operator, should be "TimeWindow";

• _comment: Contains a string description of the operator. mented is to be used by the field engineer and does not affect processing. This field is optional;

• _time_window_length_in_seconds: the length of the time window;

• _feature_1_name, _feature_2_name, ..., ":" _feature_N_name: the features of the input stream that will be aggregated;

• _aggregator_1, _aggregator_2, ..., _aggregator_N: Aggregators that must be applied to the selected features (see Table 25);

• _result_feature_name_1, _result_feature_name_2, ..., _result_feature_name_N: Observations published on the window output stream will contain these features.

The main configuration parameters for time batch windowing operations are: time window length TWL, which represents the time period during which events are collected into the window; and time window step size TWS, which represents the time period between the start of two consecutive time windows. time distance.

Figure 5 illustrates a temporal batch window SEPL operation.

In a possible embodiment, a SEPL processing node adapted to perform a time windowed SEPL operation may comprise the following structure:

The following parameters must be filled in:

• _input_stream_name: the name of the stream that must be used as input;

• _output_stream_name: a string value representing the name of the output stream;

• _operation: A string value representing the name of the operation. For the time window operator, should be "TimeWindow";

• _comment: Contains a string description of the operator. Indicated to be used by the field engineer and it does not affect handling. This field is optional;

• _time_window_length_in_seconds: the length of the time window;

• _feature_1_name, _feature_2_name, ..., ":" _feature_N_name: the features of the input stream that will be aggregated;

• _aggregator_1, _aggregator_2, ..., _aggregator_N: Aggregators that must be applied to the selected features (see Table 25);

• _result_feature_name_1, _result_feature_name_2, ..., _result_feature_name_N: Observations published on the window output stream will contain these features.

The point window applies the aggregator to the last observation received from the data stream, regardless of the moment at which it received the data stream. The number of observations considered can be limited by the point window length parameter. If the point window is strict, it will only generate values if it contains exactly the point window length observations.

Figure 6 illustrates a point window SEPL operation. For the strict point window, the first two aggregated results illustrated in Figure 6 were not delivered. Figure 6 schematically shows a point window SEPL operation that may be performed by a SEP engine according to the present invention. As illustrated in Figure 6, an input SE stream containing a series of events A to F is processed to generate an output SE stream. A SEPL node adapted to perform a SEPL point window operation may include the following structure:

The following parameters must be filled in:

• _input_stream_name: the name of the stream that must be used as input;

• _output_stream_name: a string value representing the name of the output stream;

• _operation: A string value representing the name of the operation. For the point window operator, should be "PointsWindow";

• _comment: Contains a string description of the operator. Indicated to be used by the field engineer and it does not affect handling. This field is optional;

• _points_window_length: the number of observations to include in the points window;

• _strict_points_window: Boolean parameter specifying whether the point window is strict;

• _feature_1_name, _feature_2_name, ..., ":" _feature_N_name: the features of the input stream that will be aggregated;

• _aggregator_1, _aggregator_2, ..., _aggregator_N: Aggregators that must be applied to the selected features (see Table 25);

• _result_feature_name_1, _result_feature_name_2, ..., _result_feature_name_N: Observations published on the window output stream will contain these features.

For point window operations, the following parameters are available. Parameters may include: a dot window length, which indicates the number of observations that the window must store, and a dot window step size, which specifies the number of observations that must be skipped between the start of two windows.

Figure 7 schematically illustrates a point window SEPL operation mode that can be implemented by a SEP engine according to the present invention. A SEPL processing node adapted to perform point window operations may include the following structure:

The following parameters must be filled in:

• _input_stream_name: the name of the stream that must be used as input;

• _output_stream_name: a string value representing the name of the output stream;

• _operation: A string value representing the name of the operation. For the point window operator, should be "PointsWindow";

• _comment: Contains a string description of the operator. Indicated to be used by the field engineer and it does not affect handling. This field is optional;

• _points_window_length: the number of observations to include in the points window;

• _points_window_step: the number of observations that must be skipped between the start of two windows;

• _feature_1_name, _feature_2_name, ..., ":" _feature_N_name: the features of the input stream that will be aggregated;

• _aggregator_1, _aggregator_2, ..., _aggregator_N: Aggregators that must be applied to the selected features;

• _result_feature_name_1, _result_feature_name_2, ..., _result_feature_name_N: Observations published on the window output stream will contain these features.

The custom window operation consumes two input SE streams. The incoming SE stream can contain observations that must be aggregated. The input trigger stream can contain at least one boolean characteristic (selected by the user) that can be used to trigger the start and stop of the custom window. A boolean value change from false to true can trigger the start of a custom window, or a corresponding change from true to false can stop the custom window computation. After the custom window is stopped, the aggregated results can be computed and published on the output SE stream.

Figure 8 schematically illustrates a custom window SEPL operation that can be performed by a SEP engine in accordance with the present invention. In a possible implementation, a SEPL processing node adapted to perform a self-defined window SEPL operation on the input signal and event data stream SE and input trigger SE may include the following structure:

The following parameters must be filled in:

• _input_stream_name: the name of the stream that must be used as input;

• _input_trigger_stream_name: must be used as the name of the stream triggered by the window;

• _trigger_feature: boolean value from _input_trigger_stream_name, which is used to start and stop the window;

• _output_stream_name: a string value representing the name of the output stream;

• _operation: A string value representing the name of the operation. For the point window operator, should be "PointsWindow";

• _comment: Contains a string description of the operator. Indicated to be used by the field engineer and it does not affect handling. This field is optional;

• _feature_1_name, _feature_2_name, ..., ":" _feature_N_name: the features of the input stream that will be aggregated;

• _aggregator_1, _aggregator_2, ..., _aggregator_N: Aggregators that must be applied to the selected features;

• _result_feature_name_1, _result_feature_name_2, ..., _result_feature_name_N: Observations published on the window output stream will contain these features.

In a possible embodiment, the deployed SEP engine's SEPL script may include: one or more predefined stateful function SEPL delay operations that are used to delay by a SEP engine's subscriber nodes by a configurable delay period Received SE data stream. SEPL delay operations perform delay operations on events sent on the SE stream. An operation produces a new stream in which events from the input stream are published with a given time delay without changing their payload. The processing nodes of a SEPL script or SEP network can operate in two modes based on the definition of delay.

If the delay is based on a given number of events, the input events are only forwarded to the output stream after the defined number of events have been received on the input stream. For example, if the number of delayed events is one in the input stream, and an event has been received in the input stream, this event will be forwarded after another event has been received in the input stream, as also illustrated in FIG. 9 . The number of events can contain any integer value. Figure 9 illustrates delay operations based on a defined number of events.

In an alternative mode, the definition of the delay may be based on a given period of time. In this mode, the input event is forwarded to the output SE stream only after the input event has passed the delay period DTP specified for the operation, as also illustrated in FIG. 10 . FIG. 10 illustrates delay based on time periods.

A SEPL processing node adapted to perform delayed operations may include the following structures:

The following parameters must be filled in:

• _input_stream_name: the name of the stream that must be used as input;

• _output_stream_name: a string value representing the name of the output stream;

• _operation: A string value representing the name of the operation. For delay operators, should be "Delay";

• _comment: Contains a string description of the operator. Indicated to be used by the field engineer and it does not affect handling. This field is optional;

• _mode: A string value representing the operation mode of the operator. The parameter can be "NumberEvents" or "TimePeriod";

• _delayEvents: A numeric value representing the number of delayed events. it is optional;

• _delaylnSeconds: A numeric value representing the number of seconds. It is optional.

In addition to stateful function event or data pattern matching and/or delayed SEPL operations, the set of SEPL operations may include stateless function SEPL operations.

The set of stateless functional SEPL operations may include subscriber SEPL operations, where subscriber nodes of the SEP network are used to push observations into the SEP engine for processing. At runtime, the subscriber node SUBN can transform each observation or event received according to the feature set description. The transformed observations can be published on the internal SEPL engine stream.

The set of SEPL operations may further include: Null processing SEPL operations, wherein a node is used to process features that contain null values.

The set of SEPL operations may further include a merge SEPL operation, which may be used to merge two SE data streams into a new SE stream. The output stream contains the union of the features from the input stream plus the timestamp field, depending on the mode of the merge operation.

The set of SEPL operations may further include a transform SEPL operation adapted to perform the transform operation using a characteristic of the data stream. Transforming SEPL operations produces a new stream, where the result of the calculation can replace the value of the transformed feature.

In a possible embodiment, the set of SEPL operations may further comprise arithmetic functions, in particular arithmetic operations using one or both characteristics of the data stream. Arithmetic operations may include, for example, addition, subtraction, multiplication, division, comparison or logical operations.

Unary arithmetic SEPL operations may also be provided to perform arithmetic operations using only one feature of the data stream. These operations may include, for example, operations that generate absolute values of numerical values, or operations that generate logarithms of numerical values. Other functions include, for example, cosine or sine functions that provide the cosine or sine value of a numerical value. SEPL operations may further include arithmetic functions and operations with more than one argument, such as providing a minimum or maximum value of a plurality of numerical values. Additionally, SEPL operations with more than one argument may include operations that generate an average or median or sum value of a plurality of numerical values.

The set of SEPL operations used by the SEP engine according to the present invention may further comprise a selection SEPL operation adapted to select a feature list of the data stream. This operation produces a new data stream in which the selected features are published.

The set of SEPL operations may further include: unary string processing operations that generate new streams, where the results of the computations may expand the feature list or may replace the value of an existing feature.

The SEPL operation set may further include: unary data time processing operations. This operation produces a new stream, where the result of the computation can expand the feature list, or can replace the value of an existing feature. For example, an operation can convert the value of the current datetime object to local time. Also, it can for example check if the date-time is on a weekend or a weekday.

The SEPL set of operations may further include: data time processing with more than one argument. The operation may, for example, return a new date-time that adds the specified number of years, months, days, or hours, minutes, seconds, or milliseconds to the received value of the data stream.

The set of SEPL operations may further include filter operations that may filter events received in the SE stream based on selected Boolean characteristics. This operation will result in a new SE stream where only events with the selected boolean value equal to "true" are published.

A SEPL script used by a SEP engine according to the present invention may include a series of different SEPL operations, which may be loaded from a SEPL script library stored in the system's database. The loaded SEPL script can easily be instantiated for the corresponding target device TD and/or industrial system 1 . This can easily be done by a field engineer with expertise in the different assets of the respective industrial system 1 .

Figure 11 shows a simple example of a SEPL script that can be implemented in a SEP engine according to the first aspect of the invention. In the simple example illustrated in Figure 11, the SEPL script includes five different SEPL operations, which may belong to a predetermined set of SEPL operations stored in memory or in a database. Different SEPL operations can be loaded from the SEP library and customized for the corresponding use case. Figure 12 illustrates two received data streams A, B which are processed by the SEP engine according to the SEPL script illustrated in Figure 11 . The first signal and event data stream SEA is compared to a threshold TH _A , and the second signal and event data stream SEB is compared to a second threshold TH _B. Both the signal and event data streams are then filtered through SEPL filtering operations and then processed through SEPL windowing and pattern matching operations to generate output signal and event data streams for further processing. For example, output signal and event data streams may include alarm event streams. If in the industrial system 1 or machine, a signal and event pattern as illustrated in Figure 12 occurs within a time window of time window length TWL, the SEP engine automatically generates an alarm event or alarm observation. The event may be streamed to another entity or target device, which in a possible implementation may include another SEP engine adapted to process received signals and events Data flow, including alert events generated by the SEPL script illustrated in Figure 11. In a possible embodiment, the SEPL script as illustrated in Figure 11 may be visualized to the user in edit mode. A SEPL script as illustrated in Figure 11 can be generated by a field engineer without any specific programming skills, but with knowledge of the industrial assets of Industrial System 1. For example, a field engineer can set thresholds and compare SEPL operations according to their expertise about the machine or industrial system 1 . Moreover, the time window length TWL can be set by the field engineer, thereby creating a simple SEPL script, as shown in Figure 11.

Claims (19)

1. A signal and event processing SEP engine (SEPE) deployed on a Target Device (TD) of an industrial system (1),

the SEP engine comprises:

-a subscriber node (SUBN) adapted to receive a signal and/or event SE data stream from a source of the industrial system (1);

-a Processing Node (PN) adapted to perform signal and event processing language SEPL function operations on a received SE data stream according to an SEPL script of the SEP engine, wherein the SEPL script comprises predefined stateful events or data pattern matching operations to generate a resulting SE data stream; and

-a publisher node (PUBN) adapted to forward the generated result SE data stream to a sink of the industrial system (1).

2. The signal and event processing SEP engine of claim 1, wherein each node of the SEP engine deployed on the Target Device (TD) is adapted to carry out an associated function operation forming part of a SEPL script,

the function operation comprises a stateless function SEPL operation or a stateful function SEPL operation.

3. The signal and event processing SEP engine of claim 1 or 2, wherein each Processing Node (PN) of a deployed SEP engine is adapted to apply a predefined SEPL function operation to SE data streams received by at least one subscriber node (SUBN) or output by at least one previous Processing Node (PN) and to deliver the resulting SE data streams to subsequent processing nodes and/or publisher nodes (PUBN) of the deployed SEP engine.

4. The signal and event processing SEP engine of claims 1 to 3,

wherein the SE data stream comprises

A signal data stream generated by a signal generation source of the industrial system (1), and/or

Event data stream generated by an event generation source of an industrial system (1).

5. The signal and event processing SEP engine according to any of the preceding claims 1 to 4, wherein the event data stream comprises a time series of events containing features represented as key-value pairs.

6. The signal and event processing SEP engine according to any of the preceding claims 1 to 5, wherein the signal data stream comprises a sensor data stream provided by a sensor (2) forming a source of the industrial system (1).

7. The signal and event processing SEP engine according to any of the preceding claims 1 to 6, wherein the nodes of the deployed SEP engine form a SEP network (SEP-NET) comprising a directed acyclic graph DAG.

8. The signal and event processing SEP engine according to any of the preceding claims 1 to 7, wherein the deployed SEP engine is implemented as a software component or as a hardware component and is deployed on a Target Device (TD) forming part of or connected to the industrial system (1).

9. The signal and event processing SEP engine according to any of the preceding claims 1 to 8, wherein the Target Device (TD) on which the SEP engine is deployed comprises a Programmable Logic Controller (PLC) of the industrial system (1),

the computer is used for controlling the operation of the computer,

a computer cluster, a client, a server, a control unit, or a cloud unit connected to a network cloud (7) of the industrial system (1).

10. The signal and event processing SEP engine according to any of preceding claims 1 to 9, wherein the source adapted to provide SE data streams to subscriber nodes (SUBN) of deployed SEP engines and/or the sink adapted to receive generated result SE data streams from publisher nodes (PUBN) of said SEP engine comprises an entity containing other SEP engines, clients, servers and/or databases of industrial systems (1).

11. The signal and event processing SEP engine according to any of the preceding claims 1 to 10, wherein SEP engine is configured to communicate with other SEP engines deployed on other target devices or target entities of the industrial system (1) by means of an event message broker.

12. The signal and event processing SEP engine of any of the preceding claims 1 to 11, wherein SEPL scripts of an SEP engine are loaded from a SEPL script library stored in a domain-specific or cross-domain knowledge database and instantiated for respective target devices of the industrial system (1).

13. The signal and event processing SEP engine of any preceding claim 1 to 12, wherein the SEPL script of the deployed SEP engine comprises: one or more predefined stateful function SEPL window event pattern matching operations, each operation adapted to validate an event pattern mined from records within SE data streams received by subscriber nodes (SUBNs) of batch SEP engines and stored historical data of SE data streams for a sliding time window having a configurable time window length to generate matching results to form a result SE data stream that is output by a publisher node (PUBN) of a deployed batch SEP engine.

14. The signal and event processing SEP engine of any preceding claim 1 to 13, wherein the SEPL script of the deployed SEP engine comprises: one or more predefined stateful function SEPL delay operations, each operation adapted to delay a SE data stream received by a subscriber node (SUBN) of the SEP engine by a configurable delay period to generate a delayed SE data stream that is output as a resulting SE data stream by a publisher node (PUBN) of a deployed SEP engine.

15. The signal and event processing SEP engine of any of the preceding claims 1 to 14, wherein the SEPL script comprises stateless function SEPL operations in addition to stateful function events or data pattern matching or delaying SEPL operations, the stateless function SEPL operations comprising:

subscriber SEPL operations, constant determination SEPL operations, conversion SEPL operations, SE stream merging SEPL operations, arithmetic function operations with one or more arguments, selection SEPL operations to select features from SE streams, string processing SEPL operations, data time SEPL operations, filtering SEPL operations, and issuing SEPL operations.

16. The signal and event processing SEP engine according to any of the preceding claims 1 to 15, wherein predefined SEP engines provided for different language types including C + +, C-Sharp, Java are stored in a knowledge database together with an associated SEPL script library,

wherein the appropriate SEPL engine is loaded, instantiated and deployed on a Target Device (TD) of the industrial system (1).

17. A system condition monitoring SCM and/or condition based maintenance CBM platform comprising one or more SEP engines according to any of the preceding claims 1 to 16,

wherein the SCM/CBM rules of the platform are written as SEPL scripts of a SEP engine deployed on a Target Device (TD) of an industrial system (1).

18. Target device of an industrial system comprising at least one SEP engine according to any of the preceding claims 1 to 16 instantiated and deployed on the Target Device (TD),

wherein the deployed SEP engine is executable to perform online and/or offline processing of SE data streams received from sources of the industrial system (1) to generate a resultant SE data stream that is forwarded to a sink of the industrial system (1).

19. A method for online and/or offline processing of a signal and/or event SE data stream of an industrial system (1),

the method comprises the following steps:

(a) receiving (S1) an SE data stream from a source of the industrial system (1);

(b) performing (S2) Signal and Event Processing Language (SEPL) function operations on the received SE data stream according to SEPL scripts of a signal and event SEP engine deployed on at least one target device of the industrial system (1),

wherein the SEPL script comprises predefined stateful events or data pattern matching operations to generate a resultant SE data stream; and

(c) forwarding (S3) the generated result SE data stream to a sink of the industrial system (1).

Images