Patent Description:
Furthermore, the subject matter disclosed herein relates to a computer program and to a computer-readable medium carrying the computer program.

Edge computing enriches automation control with digital industrial applications close to the shop floor, in particular at the shop floor. This means close to industrial machines, actuators and other equipment. While adding new functionalities such as increased production transparency and optimization, predictive maintenance, condition monitoring and visual awareness, it also - by definition - represents a man-in-the-middle between operational and information technologies that must be carefully protected for platform stability, data privacy and other IT-security reasons. This aspect becomes even more important in case of open application ecosystems that allow OEMs, customers and <NUM>rd parties to deploy and run own applications on the edge and/or IIoT (Industrial Internet of Things) devices close to production-critical assets analyzing data and feeding back information to the operational equipment influencing production-related control flows. On the one hand both valid application scenarios, production control and data privacy must not be negatively affected while at the same time the scope and flexibility of Edge application scenarios shall not be reduced without explicit transparency and control.

In such Edge ecosystems the problem to be solved is to allow for flexible extension of traditional shop floor functions by applications from third parties, and - at the same time - protecting the operator's production processes, hardware assets, data privacy and additionally stability of Edge platform and Edge applications even in case of presence of erroneous or malicious applications or external malicious threats.

One aspect of this problem is a need for means for data and data traffic control, which can enable the required protection in open application ecosystem approaches for Edge computing.

Regarding the data traffic control, it is necessary to correctly assess and distinguish between different types of network traffic, so that both the protection of operator's production processes, hardware assets, data privacy and the stability of Edge platform and Edge applications even in case of presence of erroneous or malicious applications or external malicious threats.

One possible approach is to apply a network bandwidth throttling approach. There, a quota-oriented transfer buffer that controls network link bandwidth over time allowing for time-limited traffic bursts, limiting traffic to a restricted upper bound network bandwidth and refilling the burst buffer over time if traffic bandwidth is not fully utilized. This strategy allows to continuously run traffic related to e.g. high frequency data while at the same time allowing bandwidth-limited continuous or time-bounded bursts for other traffic with several limitations.

The strategy shows a multitude of drawbacks and limitations. It cannot strictly distinguish between different continuous and burst traffics on the same network channels but assesses the union of all kinds of traffic over each channel at the same time. The control mechanism's boundary properties and thresholds are not dynamic as the real usage scenarios cannot be understood in an automated manner in form of a combined scenario formed by the individual traffic contributions.

Using this tradition approach it is not possible to distinguish between different types of traffic in case the traffic characteristics are resembling. In dynamic network link scenarios valid type-<NUM> traffic may even be analyzed as a false-positive (type-<NUM> / malicious traffic) and throttled down as the required intelligence for situation understanding is missing. The same refers to type-<NUM> traffic scenarios, whereat these are more error-prone in this aspect as they often occur in dynamic situations when Edge applications initiate ad-hoc type-<NUM> network communication such as a best-effort download of a very big image or of report not fitting into the burst bandwidth quota and thus throttled down leading to customer dissatisfaction about improper platform networking qualities.

Another solution approach is known from the digital right management (DRM) context (e.g. https://www. com/<NUM>/<NUM>/drm-for-things-managing-rights-and-permissions-for-iot, https://link. com/article/<NUM>/s11042-<NUM>-<NUM>-<NUM>). Here, critical data is protected by applying digital cryptography in combination with a usage license. Though the approach can protect from unauthorized data access it cannot solve the problem of correctly handling mixed type-<NUM> and type-<NUM> traffic situations in case the protected data cannot be classified properly. DRM systems are also hard to integrate and maintain (DRM license management on customer premises), and lead to increased costs for development, testing and necessary licensing of a DRM runtime. The document <CIT> (<NUM>/<NUM>/<NUM>), discloses an edge computing platform having a software layer that is connected to a local-area network.

Therefore, a sustainable and reliable solution for the above problem is needed.

Further embodiments are described by the dependent claims. The description is taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:.

The computing system <NUM> of <FIG> comprises one or more IIoT (Industrial Internet of Things) or edge devices <NUM>, an OT (Operational Technology) network <NUM>, an IT network <NUM> and a network traffic control system <NUM>.

For the sake of simplicity and where it is appropriate, the one or more IIoT or edge devices are referred to below as device <NUM>. The device <NUM> resides between the OT network <NUM> and the IT network <NUM>.

The OT network <NUM> may comprise one or more OT devices <NUM> such as industrial sensors and automation controllers. Each OT device <NUM> can be designed to communicate with other devices in the OT network <NUM> and with one or more of the IIoT / Edge Devices <NUM>. Some of the OT devices can be designed as and serve as OT data sources <NUM> providing data (e.g. automation data and/or sensor signals) or OT data sinks <NUM> receiving data (e.g. automation control input and sensor and/or automation configuration data) or a combination thereof. Data sources can be referred to as data providers, data sinks can be referred to as data consumers and a combination thereof can be referred to as data prosumers.

The IT network <NUM> can comprise IT equipment such as Manufacturing Execution Systems (MES), Enterprise Resource Planning (ERP) systems, Computerized Maintenance Management Systems (CMMS), databases or data lakes on premises or in a cloud. Each element <NUM> in the IT network <NUM> can be designed to communicate with other devices in the IT network <NUM> and with one or more of the IIoT / Edge Devices <NUM>. The elements can be designed as and serve as IT data sources <NUM> providing data (e.g. MES and ERP data or maintenance tasks from a CMMS) or IT data sinks <NUM> receiving data (e.g. motor and workpiece quality data, predictive maintenance-related information or detected process anomalies) or a combination thereof (IT data prosumers).

The device <NUM> is configured to establish connection between the OT <NUM> and IT networks <NUM> and to process data from both networks and/or data on the device <NUM> itself by routing between the networks and optionally to and from applications running on the device <NUM> (e.g. in the field of data analytics) close to the industrial equipment (e.g. a motor or a machine tool).

Each of the IIoT / edge devices <NUM> comprises an application runtime space <NUM> that can host and run one or more applications <NUM> (e.g. data analytics applications). The application runtime space <NUM> can be designed as runtime environment for the applications <NUM>. Some of the applications <NUM> can be designed and serve as data sinks <NUM> and/or data sources <NUM>.

The data sinks <NUM> can be configured to receive data inbound to the device <NUM> and data from the applications <NUM> running on the device <NUM>.

The network traffic control system <NUM> comprises a policy definition authority component <NUM>, a network traffic analyzer component <NUM>, and a network traffic controller component <NUM>. The network traffic analyzer component <NUM> and the network traffic controller component <NUM> can correspond to the network traffic analyze-control-component according to the invention.

Each of the components can be realized as a software and / or hardware component. For example, some of the components can be realized in form of ASICs (application-specific integrated circuits) integrated with a one or more of the IIoT / edge devices <NUM>. In an embodiment some of the network traffic control system's components can be incorporated into a system-on-a-chip (SoC) which can be integrated with a one or more of the IIoT / edge devices <NUM>.

In an embodiment each of the IIoT / edge devices <NUM> comprises a network traffic analyzer component <NUM> and a network traffic controller component <NUM> so that different network traffic analyzer components <NUM> and network traffic controller components <NUM> reside on different IIoT / edge devices <NUM>.

The policy definition authority component <NUM> can reside on the device <NUM> (not shown) or on a server, for example on a backend-server, e.g. on an on-prem backend server or on a cloud backend server.

The policy definition authority component <NUM> can be configured to receive data <NUM> based on a network traffic data associated with one or more of the IIoT/edge devices <NUM> (device-specific network traffic data). This also can be a historical or a real-time data. The policy definition authority component <NUM> can also be configured to retrieve data from a data lake that contains historical network traffic data associated with one or more of the IIoT/edge devices <NUM>. The data can be the device-specific network traffic data or, if requested for IT security reasons, pre-processed, anonymized / pseudonymized data characteristics about related network traffic properties. The data <NUM> is representative for different network traffic control scenarios or situations.

Furthermore, the policy definition authority component is configured to generate (or provide) at least one first and at least one second data analytics model <NUM>, <NUM> based on the received data <NUM>.

In an embodiment, the data <NUM> comprises device-specific network traffic data from different IIoT / edge devices <NUM> and the policy definition authority component <NUM> generates different first and second data analytics models <NUM>, <NUM> for the different IIoT / edge devices <NUM>.

The first data analytics model <NUM> and/or the second data analytics model <NUM> can be based on one or more neural networks. In this case the data <NUM> can serve as a training data for the neural networks.

The first and second data analytics models <NUM>, <NUM> are designed or configured to be used to analyze and control device-specific network traffic in dependence on inbound network traffic to this device.

In an embodiment the first data analytics model <NUM> and/or second data analytics model <NUM> are/is based on or comprise a rule engine, complex event processing engine, constraint reasoner, temporal logic reasoner, description logics reasoner, simulation-based analyzer, statistical reasoner, mathematical optimizer, neural network classifier or on a combination of one or multiple thereof.

In an embodiment the first data analytics model <NUM> comprises a simulation-based analyzer and a neural network classifier. Int this case it is possible to classify network traffic situations based on anticipated / predicted network traffic.

In an embodiment, the policy definition authority component <NUM> can be configured to allow a manual, e.g. by a human being, definition of rules, constraints or other kind of policies, so that the first data analytics model <NUM> and/or the second data analytics model <NUM> can be designed as a manually definable set of rules.

In an embodiment, the policy definition authority component <NUM> can be configured to provide a computer-aided support for facilitating one or multiple tasks of manual definitions, e. supervised machine learning. In this case the first data analytics model <NUM> and/or the second data analytics model <NUM> can be designed as models based on a machine learning algorithm, e.g. on a neural network.

In an embodiment, the policy definition authority component <NUM> can be configured to generate the first data analytics model <NUM> and/or the second data analytics model <NUM> fully automatically, i.e. without human interaction, e.g. by utilizing unsupervised training. After generating the first data analytics model <NUM> and/or the second data analytics model <NUM> the policy definition authority component <NUM> may present the result to a user for acceptance.

The at least one first data analytics model <NUM> is transferred to the network traffic analyzer component <NUM> of a corresponding IIoT / edge device.

The at least one second data analytics model <NUM> is transferred to the network traffic controller component <NUM> of a corresponding IIoT / edge device.

The network traffic analyzer component <NUM> can reside at a IIoT / edge device or at one of the IIoT / edge devices <NUM> and is configured to receive an input data representative of the network traffic and to utilize the at least one first data analytics model <NUM> in order to identify at least one network traffic situation. In an embodiment the network traffic analyzer component <NUM> produces a description of the at least one network traffic situation.

The network traffic associated with the device <NUM> is network traffic inbound to, network traffic on and network traffic outbound from the device <NUM>.

In an embodiment the input data comprises a network traffic data and a network traffic context data representative of a context within which the network traffic occurs. In this case the at least one first data analytics model <NUM> performs a context-based identification of the at least one network traffic situation.

Examples of the network traffic data comprise at least one of but not restricted to bandwidth, jitter, frequencies of data loss, latencies, network protocol etc..

Examples of the network traffic context data comprise at least one of but not restricted to identification of a user that initiates the network traffic, license information associated with the network traffic (e.g. whether the requesting party is allowed to use the network traffic), information associated with system environment (production or test), outside temperature.

Especially when the first and/or second data analytics model are based on a neural network or a machine learning algorithm the received input data can be used for training of new or for a further training of already existing models by the policy definition authority component <NUM>. In this case it is transferred to the policy definition authority component <NUM> as the data <NUM>.

To derive a network traffic situation the first data analytics model <NUM> is designed to apply statistical, stochastic and / or temporal correlations of the network traffic, i.e. the traffic inbound to and/or outbound from the one or more of the IIoT / edge devices <NUM> and/or the traffic on the one or more of the IIoT / edge devices <NUM> (on-device traffic).

The temporal correlations can be analyzed at a pre-determined point in time or over (a pre-determined period of) time.

In an embodiment the network traffic analyzer component <NUM> can be configured to receive the input data continuously in an input data stream and/or in form of batches of input data, for example, each microsecond, millisecond, second or minute. While receiving the input data, the network traffic analyzer component <NUM> can run the at least one first data analytics model <NUM> on the input data. During the runtime the least one first data analytics model <NUM> determines correlations between the network traffic and a past and / or a current and/or an anticipated / predicted network traffic. For example, the network traffic analyzer component <NUM> can be configured to store the input data at the beginning of the time period, for which the correlations will be analyzed, so that the past traffic can refer here to the traffic received within the said pre-determined period of time. In general, it is not to confuse with the historical network traffic. The anticipated network traffic can be produced for example by one of the above-mentioned machine-learning based algorithm, e.g. by a simulation-based analyzer.

The output of the first data analytics model <NUM> can for example, be a continuous high-frequency sensor data streaming over the OT network <NUM> to the device <NUM> and/or an inbound request for a batch-based download of a large file from the <NUM>rd party app by a Web client <NUM> in the IT network <NUM> (<FIG>).

A further example of the at least one network traffic situation is a high-frequency (e.g. data point per <NUM>) streaming of high-quality data from a specific device in the OT network <NUM> before receiving a request for downloading high-frequency-granular data exports to the IT network <NUM>. In an embodiment the high-frequency streaming of high-quality data can be buffered, e.g. for several hours or for a day, on one of the IIoT / edge devices <NUM>, before it will be transferred to the IT network <NUM> (<FIG>).

Furthermore, the first data analytics model <NUM> can be used to assess incipient overload, system stability criticality and / or data privacy threats (e.g. if a receiver is not authorized to access a certain quality of industrial IoT data).

The network traffic analyzer component <NUM> is configured to transfer the identified network traffic situation(s) to the network traffic controller component <NUM>. This can be done periodically or continuously. In particular, the information is transferred in form of a computer-readable representation. For example, the network traffic analyzer component <NUM> may produce a JSON or XML-based output.

In other words, the network traffic analyzer component <NUM> (periodically or continuously) sends the results of the analysis performed with the aid of the one or more first data analytics models <NUM> on the derived network traffic situation to the network traffic controller component <NUM>.

In an embodiment, the network traffic controller component <NUM> can be based on or comprise a rule engine, complex event processing engine, constraint reasoner, temporal logic reasoner, description logics reasoner, simulation-based analyzer, statistical reasoner, mathematical optimizer, neural network classifier or on a combination of one or multiple thereof.

In an embodiment, the network traffic controller component <NUM> resides at a IIoT / edge device or at one of the IIoT / edge devices and is configured to use the at least one second data analytics model <NUM> to control the network traffic inbound to and/or outbound from the one or more of the IIoT / edge devices <NUM> and/or the traffic on the one or more of the IIoT / edge devices <NUM> (on-device traffic).

<FIG>, <FIG> and <FIG> illustrate the network traffic controller component <NUM> comprising three interfaces 203a, 203b, 203c, wherein each interface can be used to allow data transfer without any restrictions, to block data transfer entirely or to transform the data in some way before transferring it. The interface 203a is an interface to the OT network <NUM>, in particular to the OT data sink <NUM>; the interface 203b is an interface to the applications <NUM> within the device <NUM>; the interface 203c is an interface to the IT network <NUM>, in particular to the OT data sink <NUM>.

In an embodiment, the communication links between the OT network <NUM>, the device <NUM> and the IT network <NUM> can be protected by cryptographic means. the information flow can be encoded by way of public-key cryptography or some similar method.

The network traffic controller component <NUM> uses the data received from the network traffic analyzer component <NUM> (identified network traffic situation) as an input data to the one or more second data analytics models <NUM> which output one or more rules or instructions on how to proceed with the network traffic within the scope of the identified network traffic situation. These instructions can comprise instructions associated with actions to be performed on the network traffic. Furthermore, the network traffic controller component <NUM> is configured to control the network traffic according to the one or more instructions / rules.

In other words, based on the data / information associated with the classification of the at least one network traffic situation received from the network traffic analyzer component <NUM>, the network traffic controller component <NUM> controls the network traffic in the corresponding network traffic situations according to the output of the one or more second data analytics models <NUM>.

As mentioned above, the network traffic controller component <NUM> can receive the input from the network traffic analyzer component <NUM> periodically or continuously. This may improve the functionality and quality of control of the network traffic. The functionality and quality depend on the analysis of past, current and / or predicted future network traffic situation(s) and optionally on correlations between multiple network traffic situation(s).

Sending (periodically or continuously) the data associated with the identified network traffic situations from the network traffic analyzer component <NUM> allows to configure the network traffic controller component <NUM> and to improve the control of the network traffic.

The result of this configuration process is the network traffic controller component <NUM> that executes the one or more second data analytics models <NUM>, which define one or multiple control policies, once / periodically / continuously for each new / existing network traffic. A control policy (set of rules, weights for a neural network) can allow to dynamically transform traffic by removing parts of the transferred Industrial IoT data or by reducing the quality of Industrial IoT data (e.g. reduce data resolution in data streams such as video camera image streams, timeseries data streams, event data streams, and set an optional data quality field to the new resolution value and an optional reason field containing the reason for quality reduction for transparency reasons) or block / postpone selected traffic.

In summary, the network traffic control system <NUM> allows to perform a proper identification and control of different classes (situations) of network transfers to correctly assess and distinguish between different types of network traffic.

In an embodiment, there are two types of the network traffic. Type-<NUM> traffic is a type is of potentially time-critical (w. shopfloor functionality) importance for the functionality of the system including critical IIoT / edge applications based on must-have network traffic scenarios (e.g. edge device inbound traffic with high frequency, high quality motion control or drive train data) as basis for operations. Improper context-awareness of a networking situation and inadequate controllability may negatively affect data security and / or stability of the edge computing platform and applications in terms of network-load characterized by data frequency and bandwidth, jitter and latency.

Type-<NUM> traffic regards to all other network traffic that is not time-critical for edge computing functions such as best-effort data imports from customer systems (e.g. maintenance tasks), best-effort imports of background information for improving data analysis (e.g. external CAD/CAM models), or best-effort Web-based access for accessing data from Ecosystem applications running on the Siemens IIoT / Edge computing platforms (e.g. downloads of 2D / 3D graphs and PDF reports). As the combination of multiple type-<NUM> traffic requests may lead to a type-<NUM> traffic situation it is desirable to correctly understand and assess the contribution of each single traffic to an overall network traffic situation including erroneous and potentially malicious network traffic.

To be able to classify the Type-<NUM> traffic is important, e.g. in order to be able to distinguish between a valid high frequency machine tool data transfer and an invalid overload situation such as an erroneous IIoT/edge device application running high frequency traffic congesting I/O resources and leading to a potential unavailability of critical functions.

The following description is essentially limited to the differences from the exemplary embodiment in <FIG>, reference being made to the description of the exemplary embodiment in <FIG> with regard to system that remain the same.

<FIG> shows the system <NUM> of <FIG>, wherein the policy definition authority component <NUM> provides the same set of rules <NUM>, <NUM> to the network traffic analyzer component <NUM> and to the network traffic controller component <NUM>. The set comprises two rules:.

The OT network <NUM> is designed as a machine network and the IT network <NUM> is designed as a factory network. The OT device <NUM> can be designed as a machine tool that can comprise a control unit and a connector device for high-frequency machine data transfer. The web client <NUM> in the factory network <NUM> may continuously request monitoring reports.

The machine data source <NUM> provides Type-<NUM> traffic, i.e. high-frequency machine tool data (streaming) to the network traffic analyzer component <NUM>. This data is further requested by an application <NUM> running on the device <NUM>. It will be appreciated that requesting and streaming the data goes through the network traffic analyzer component <NUM> and the network traffic controller component <NUM>. the data stream to the app <NUM> goes through the interface 203b of the network traffic controller component <NUM>.

The application <NUM> running on the device <NUM> can be a <NUM>rd party app (i.e. an app developed by neither of the entities governing machine and/or factory networks nor the entity governing the device). The application <NUM> can be a 3rd party high-frequency machine data monitoring app. The app <NUM> can comprise a webserver for downloading monitoring reports from the machine network <NUM>.

After analyzing the network traffic according to the rules provided by the policy definition authority component <NUM> the network traffic analyzer component <NUM> identifies the following network traffic situation "3rd Party Edge application <NUM> is continuously receiving high quality data from a machine <NUM> on the OT network <NUM>; There is request for a batch-based download of a large file from the 3rd party app <NUM> by a Web client <NUM> in the IT (factory) network <NUM>" and passes this information to the network traffic controller component <NUM>. The first data analytics model <NUM> and the second data analytics model <NUM> can be based on a rule engine in this case.

Under the conditions set out by the policy definition authority component <NUM> and based on the identified network traffic situation the network traffic controller component <NUM> can perform following actions on the network traffic.

Turning to <FIG> the policy definition authority component <NUM> defines the following rules:.

The OT network <NUM> can be designed as a machine network and the IT network <NUM> can be designed as a factory network. The OT device <NUM> can be designed as a machine tool that can comprise a control unit and a connector device for high-frequency machine data transfer. The web client <NUM> in the factory network <NUM> may continuously request high frequency and/or high quality data.

The analysis of the network traffic by the network traffic analyzer component <NUM> provides the following network traffic situation "3rd Party machine data monitoring application <NUM> is continuously receiving high quality data from a machine <NUM> on the OT network <NUM>; There is request for high frequency transfer of high-quality data from the 3rd party app <NUM> by a Web client <NUM> in the IT (factory) network <NUM> that will lead to a network overload scenario or system instability".

Based on the above rules and the identified network traffic situation the network traffic controller component <NUM> controls the network traffic accordingly:.

It will be appreciated that the quality of the analysis and control of the network traffic can be improved, if the data associated with the network data is used for improving the first data analytics model <NUM> and the second data analytics model <NUM> that are provided by the policy definition authority component <NUM>. When available the improved models can be uploaded to the network traffic analyzer component <NUM> and/or to the network traffic controller component <NUM> and deployed there to replace the old models.

In an embodiment the network traffic analyzer includes or accesses a data repository (e. a file or database) for storing historic network traffic metrics / statistics that are used for improving the classification quality of the component based on historical information.

In an embodiment the network channels and / or the transferred data and / or the network statistics / metrics and / or the analytical models and/ or the Network Traffic Controller <NUM> configuration by the Network Traffic Analyzer <NUM> component is protected for confidentiality reasons by cryptographic symmetric or asymmetric encryption for inbound, outbound and / or on-device data transfers.

<FIG> shows a flow diagram of a method that can be carried out by a network traffic control system, e.g. by the network traffic control system <NUM> of <FIG>.

The method comprises - Step S1 - providing, by the policy definition authority component <NUM>, at least one first data analytics model <NUM> and at least one second data analytics model <NUM> to a network traffic analyze-control-component, that can comprise the network traffic analyzer component <NUM> and the network traffic controller component <NUM>,.

<FIG> shows computer-readable medium <NUM> with a computer program <NUM>. The computer program <NUM> comprises instructions which, when executed by the network traffic control system <NUM>, cause the network traffic control system <NUM> to carry out the steps of the above-mentioned method.

Claim 1:
A system for analyzing and controlling network traffic associated with at least one device (<NUM>) that resides between a first network (<NUM>) and a second network (<NUM>), said system (<NUM>) comprising:
a memory that stores machine-executable components (<NUM>, <NUM>, <NUM>),
a processor that is operatively coupled to the memory, and is configured to execute the machine-executable components (<NUM>, <NUM>, <NUM>), wherein the machine-executable components (<NUM>, <NUM>, <NUM>) comprise a policy definition authority component (<NUM>) and a network traffic analyze-control-component (<NUM>, <NUM>), wherein
the policy definition authority component (<NUM>) is configured to
- provide, to the network traffic analyze-control-component (<NUM>, <NUM>), at least one first data analytics model (<NUM>) and at least one second data analytics model (<NUM>),
the network traffic analyze-control-component (<NUM>, <NUM>) is configured to
- receive an input data comprising a network traffic data and a network traffic context data representative of a context within which the network traffic occurs,
- apply the at least one first data analytics model (<NUM>) to the input data, wherein the at least one first data analytics model (<NUM>) performs a context-based identification of at least one network traffic situation,
- apply the at least one second data analytics model (<NUM>) to the at least one network traffic situation, wherein the at least one second data analytics model (<NUM>) generates at least one rule according to which the network traffic can be controlled,
- control the network traffic according to the at least one rule.