Patent Description:
In systems based on cloud computing technology, a large number of devices is connected to a cloud computing system via the Internet. The devices may be located in a remote facility connected to the cloud computing system. For example, the devices can comprise, or consist of, equipments, sensors, actuators, robots, and/or machinery in an industrial setup(s). The devices can be medical devices and equipments in a healthcare unit. The devices can be home appliances or office appliances in a residential/commercial establishment.

The cloud computing system may enable remote configuring, monitoring, controlling, and maintaining connected devices (also commonly known as 'assets'). Also, the cloud computing system may facilitate storing large amounts of data periodically gathered from the devices, analyzing the large amounts of data, and providing insights (e.g., Key Performance Indicators, Outliers) and alerts to operators, field engineers or owners of the devices via a graphical user interface (e.g., of web applications). The insights and alerts may enable controlling and maintaining the devices, leading to efficient and fail-safe operation of the devices. The cloud computing system may also enable modifying parameters associated with the devices and issues control commands via the graphical user interface based on the insights and alerts.

The cloud computing system may comprise a plurality of servers or processors (also known as 'cloud infrastructure'), which are geographical distributed, connected with each other via a network. A dedicated platform (hereinafter referred to as 'cloud computing platform') is installed on the servers/ processors for providing above functionality as a service (hereinafter referred to as 'cloud service'). The cloud computing platform may comprise a plurality of software programs executed on one or more servers or processors of the cloud computing system to enable delivery of the requested service to the devices and its users.

One or more application programming interfaces (APIs) are deployed in the cloud computing system to deliver various cloud services, e.g. to one or more users.

There is an increasing trend of industrial automation systems, assets, machines, sensors, mobile devices etc. in all fields of the industrial production, energy, transportation and in other areas as banking, retail, hospitality and medical health care systems being connected via network connections to the Industrial Internet of Things (IIoT) directly or via cloud gateways. Data analytics (data mining, deep learning, artificial intelligence) is a core aspect in this whole area of connected things and generates a new level of knowledge and usability.

The analytics of collected data could be performed on the one hand at the edge of the IIoT devices or the IIoT gateways or the cloud computing platform as the central computing infrastructure. If data analytics is performed at the edge of the local IIoT devices itself, it enables real-time analytical operations. Since the data are performed or processed at the local device, it avoids sending raw-data to the cloud and thus preserves network bandwidth and is resilient to network issues. Especially, it is not necessary to provide a permanent, uninterrupted connection to the Internet in order to be able to use a cloud application, which requires high demands on availability, e.g., in case of devices in the automotive or mobile sector.

If data analytics is performed in the cloud computing platform, it allows the IIoT platform provider(s) to better protect and secure the know-how and intellectual property for their analytical algorithms as it is not necessary to disclose these algorithms to the environment outside of the cloud. As the analytical algorithms are executed centrally in the cloud computing platform, they need not be deployed on the local edge devices, which are typically not owned by the IIoT platform providers. Furthermore, other types of algorithms and software applications which need higher calculating speed and more memory space, for example image recognition and analysis in the automotive sphere or in the scientific or medical area (scanning microscopy, diagnostic radiology, magnetic resonance imaging), can be used at the IIoT platform so that the quality of the data analytics is higher and faster.

This means that there are advantages and disadvantages of performing data analytics on the edge of a local device or on the cloud computing platform.

Patent application <CIT> provides an example of such an implementation wherein a wearable sensing device can be configured to operate in one or more modes of operation, for example, each mode can be configured to use one or more sensors to collect and process sensor signals and produce sensor signal data that can be processed by the wearable sensing device or transmitted to the smartphone or hub for processing or subsequently transmitted to the cloud platform for processing, depending on the mode of operation.

In view of the foregoing it is thus an object of the present invention to provide techniques that assist in improving data analytics using both the corresponding edge of a local device and the cloud computing platform and ensuring the highest possible use of the whole network.

According to a first aspect, the invention is defined by claims <NUM> and <NUM>.

In some advantageous embodiments, at least one of the at least two sub-algorithms takes a result of at least one other of the at least two sub-algorithms as an input. In other words, at least one of the at least two sub-algorithms may depend on a result of at least one other of the at least two sub-algorithms.

In other advantageous embodiments the sub-algorithms function independently from one another, i.e. do not need any result from any of the other sub-algorithms for performing their intended function. In that case, advantageously all of the sub-algorithms may be performed simultaneously (or, in other words, in parallel).

In any case, the (overall) analytical algorithm comprises or consists of at least two sub-algorithms. The (overall) analytical algorithm may be divided into those two or more sub-algorithms. For example, a user or administrator may divide the (overall) analytical algorithm into two or more sub-algorithms. Thus, thereby the sub-algorithms serve the same purpose or, to put it in another way, generate the same result as the (overall) analytical algorithm, e.g., produce the same result. By dividing the analytical algorithm into two or more sub-algorithms the (overall) analytical algorithm is modularized. The sub-algorithms may be realized by one or more software modules, i.e. computer-implemented, which realize a self-contained task. The overall task of the (overall) analytical algorithm may be achieved by the combination of the two or more sub-algorithms.

Embodiments of the invention can be used, by way of example, for the analytics and evaluation of e.g. vibration and other data in industrial plants, image data in the scientific and medical area, data for drug development and clinical trials using medical devices in the pharmaceutical sphere, data for route computations in the navigation field, data for image recognition in the automobile area and computer games, etc..

By breaking down the analytical algorithms into sub-algorithms a hybrid and distributed analytical approach is provided, which can be executed on the edge of a local device for real-time characteristics and edge advantages and on the cloud computing platform for cloud advantages.

With such a hybrid approach for breaking down analytical algorithms into sub-algorithms a serial and/or parallel execution sequence for the sub-algorithms can be defined. In particular, at least a first of the plurality of sub-algorithms may be assigned to be executed on the edge, e.g. the local device or a gateway, whereas at least a second of the plurality of sub-algorithms may be assigned to be executed on the cloud computing platform. Subsequently, the plurality of sub-algorithms may be distributed to their place of execution in accordance with their assignment, i.e. deployed. The division of the (overall) analytical algorithm can be based on the specific application the (overall) analytical algorithm will be used. For example, the resources available on the local device and/or the gateway can be taken into account when dividing the (overall) analytical algorithm into a plurality of sub-algorithms. Additionally or alternatively, an affinity indicator may be determined or assigned to the (overall) analytical algorithm and/or to one or more sub-algorithms of the plurality of sub-algorithms, as will be described in the following.

Furthermore, the analytical algorithm may comprise at least one affinity indicator (or: preference indicator), wherein the affinity indicator indicates for at least one sub-algorithm of the analytical algorithm, or for the analytical algorithm itself, where the sub-algorithm should be ideally executed, i.e. on the cloud computing platform, the gateway, and/or the local device(s). This information is also designated as affinity/preference of the analytical algorithm, or of any of the sub-algorithms, respectively.

In some embodiments, the affinity indicator for the analytical algorithm and/or for at least one of the sub-algorithms may indicate that a particular sub-algorithm may be executed on a specific device or location. In some embodiments, the affinity indicator for the analytical algorithm and/or for at least one of the sub-algorithms may indicate that a particular sub-algorithm must be executed on a specific device or location.

Preferably, the analytical algorithm comprises data indicating into which sub-algorithms the analytical algorithm may be sub-divided (or: split up). More preferably, for each such sub-algorithm indicated, an affinity indicator is provided.

In some advantageous embodiments, the sub-algorithms are able to dynamically move, or be moved, between the cloud, the gateway(s), and/or the local device(s) based on considerations such as affinity/preference (i.e. on an affinity indicator), available resources and computer performance, etc. Whether or not a specific sub-algorithm is movable or not may be indicated by a corresponding movability indicator of the sub-algorithm or of the analytical algorithm itself.

Additionally, a workflow engine can be created for defining the sub-algorithms, assigning their execution sequence, and assigning affinity/preference to certain types of IIoT devices.

In further advantageous embodiments, the sub-algorithm designated for execution on the local device can be shifted to the gateway.

According to other advantageous embodiments, the sub-algorithms are executed in a serial and/or parallel sequence.

The system may also comprise a software application which controls a workflow regarding the sequence and the location of the execution of the sub-algorithms.

This software application may be stored advantageously in an analytics runtime module, ARM, of the local device(s) and/or the gateway(s) and/or the cloud computing platform.

According to other advantageous embodiments, an affinity/preference is defined regarding the location of execution and the run-time for each sub-algorithm, e.g. in an affinity indicator.

The definition of the affinity/preference (or in other words, the affinity indicator) may be based on computer performance and resources and/or availability of the cloud computing platform and/or data structure of the processed data.

According to other advantageous embodiments, the analytical algorithm is configured as a clustering and/or a neural network and/or a Support Vector Machine and/or a blockchain which is subdivided into sub-algorithms.

In some advantageous embodiments, the processed data are collected from vibration sensors and/or acoustical sensors and/or optical sensors and/or temperature sensors and/or pressure sensors and/or chemical and/or piezoelectric sensors.

In other advantageous embodiments, a plurality of local devices is connected in the network. The affinity indicator may be configured to indicate not only that a sub-algorithm is to be executed on and by an unspecified local device but may also indicate by which particular local device of the plurality of local devices the sub-algorithm is to be executed. The one or more local device may be configured as an industrial pump, a medical device, an image device, mobile device, an automotive device and/or an analytical scientific instrument.

According to a second aspect, the invention provides a method for data analytics in a network between one or more local device(s) and a cloud computing platform, in which data collected and/or stored on the local device(s) and/or stored on the cloud computing platform are processed by an analytical algorithm (A) which is subdivided into at least two sub-algorithms (SA1, SA2), wherein at least one sub-algorithm (SA1) is executed on the local device(s) and at least one other sub-algorithm (SA2) is executed on the cloud computing platform.

Additionally, the invention provides, according to a third aspect, a local device configured for a system according to the first aspect of the invention. In particular, the local device may be configured as an industrial pump, a medical device, an image device, mobile device, an automotive device and/or an analytical scientific instrument.

According to a fourth aspect, the invention provides a cloud computing platform configured for use in a system according to the first aspect of the invention.

According to a fifth aspect, the invention provides a computer program product comprising executable program code configured to, when executed, perform the method according to the second aspect.

According to a sixth aspect, the invention provides a non-transient computer-readable data storage medium comprising executable program code configured to, when executed, perform the method according to the second aspect. The non-transient computer-readable data storage medium may comprise, or consist of any type of computer memory, in particular a semiconductor memory.

According to a seventh aspect, the invention provides a data stream representing, or configured to provide, program code configured to, when executed, perform the method according to the second aspect.

Additional features, aspects and advantages of the invention or of its embodiments will become apparent on reading the detailed description in conjunction with the following figures:.

In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art that the present invention may be practiced in other implementations that depart from these specific details.

<FIG> provides a general overview of a system <NUM> for data analytics in a network of an industrial plant <NUM> and a cloud computing platform <NUM>. The industrial plant <NUM> in this embodiment comprises, as a local device <NUM>, an industrial pump. However, additional local devices <NUM> can be added to the system <NUM>. Acceleration sensors <NUM> (accelerometers) are placed on the pump <NUM> as an example of a mechanical component to capture rotational and vibration data, which helps in early detection of various failure modes encountered in rotation mechanical equipment.

In a simplified view, the industrial pump <NUM> has a mechanical system <NUM> and a controller <NUM>. In the illustrated example four accelerometers <NUM> are mounted on the mechanical rotating part <NUM> of the pump <NUM> to capture acceleration/ vibration measurement data. The sensors <NUM> are connected to the pump controller <NUM>. The pump controller <NUM> comprises an IIoT agent <NUM> and is connected to an IIoT gateway <NUM>, which in turn is connected by a network <NUM> to the IIoT cloud <NUM>.

The IIoT gateway <NUM> can comprise several IIoT gateway modules <NUM>. The collected and generated data can be stored and processed at the pump controller <NUM> and/or the IIoT gateway <NUM> and/or further data storage(s) and/or the IIoT cloud computing platform <NUM>. The stored data may include reconstructed data, compressed data, segmented data, and other data related to the local device <NUM>. The network <NUM> may include one or more wide area networks (WAN), such as Internet, local area networks (LAN), or other networks that may facilitate data communication.

The network <NUM> may be divided into sub-networks that allow access to all the other components connected to the network <NUM>. The network <NUM> may include an encryption scheme that may be employed over the public Internet. The network <NUM> can be configured in a wired and/or wireless configuration that supports data transfer.

The displayed representation is intended to illustrate one possible configuration of the system <NUM>. Other configurations can include fewer components, and in other configurations additional assets <NUM> may be utilized. These changes in configurations and components can increase or alter the capabilities of the system <NUM>. Especially in the field of medical imaging devices for capturing high-resolution medical images of a patient such as magnetic resonance imaging (MRI) machines, computer tomography, x-ray, positron emission tomography, scanning microscopy, ultrasound imaging systems the sensors are configured to capture image data, e.g. sensors such as charged-coupled devices (CCD). Also other types of sensors such as acoustical, optical, piezoelectric, pressure, temperature, chemical sensors can be used to collect additional data for a specific local device <NUM>.

<FIG> is a diagram representing a workflow <NUM> of data processing and analysis that is executed both on the local device <NUM> and the cloud computing platform <NUM> of the system <NUM>. The workflow <NUM> may also be performed as part of a method according to an embodiment of the second aspect of the invention.

For the vibration case as illustrated in <FIG>, as an example, the analytical algorithm(s) A are broken down into the following sub-algorithms:
A first sub-algorithm <NUM> (SA1. <NUM> and SA1. <NUM>) is generated for up-sampling or down-sampling the time-series vibration data and normalization the data in a standardized format.

A second sub-algorithm <NUM> (SA2) is generated for the calculation of a frequency domain transformation or frequency spectrum. An example for such an algorithm is a Fast Fourier Transformation (FFT).

A third sub-algorithm <NUM> (SA <NUM>) is generated for the analytics of frequency components in the vibration spectrum to determine failure modes in the mechanical equipment.

These three sub-algorithms SA1. <NUM>, SA2, SA3 can be executed on separate computing units. However, more than three sub-algorithms SAn may be provided for other analytical algorithms A or other data structures. Several analytical algorithms A such as clustering, neural networks, Support Vector Machines and/or blockchain can be used in the framework of the invention. Furthermore, it is possible to create, for the workflow <NUM> of processing the sub-algorithms SA1, SA2, SA3,. San, a network or a tree-like structure with several affinity levels which can be executed in a dynamic way.

In this illustrated example, it is necessary that SA1 is performed in real-time, but the sub-algorithm SA1 is computationally not very complicated nor does it require a lot of computer performance/resources. Furthermore, the sub-algorithm SA1 does not contain specific knowledge or intellectual property from the perspective of a provider of an analytical algorithm A. Thus, its affinity indicator may indicate that sub-algorithm SA1 could (and should) be executed on the local device <NUM> or the pump-controller <NUM>.

However, further in the illustrated example, SA2 needs much more computer performance, but does not comprise any specific know-how or intellectual property. Therefore, its affinity indicator may indicate that sub-algorithm SA2 could (and should) be executed on the IIoT gateway <NUM> which has more computing resources compared to the local device <NUM>.

Further in the illustrated example, SA3 involves the analytics of frequency components which requires specific domain knowledge which is the know-how and/or intellectual property of the analytical provider(s). It might also involve bench-marking or comparison of the frequency components of other similar industrial assets. Therefore, its affinity indicator may indicate that sub-algorithm SA3 could (and should) this step should be executed in the IIoT cloud computing platform <NUM>.

The workflow <NUM> starts with incoming raw data <NUM> and ends with a result <NUM> of the analytic algorithm(s) A. The first row <NUM> lists the various sub-algorithms (SA1, SA2,. SAn) of the overall analytical algorithm(s) A and the execution sequence of the sub-algorithms. For example, in the illustrated example, SA2 cannot be executed before SA1. <NUM> has finished execution, as it requires, as an input, an output of SA1.

It should be understood that in other realizations of the system <NUM>, the sub-algorithms SA1, SA2,. SAn may also be executed in a parallel sequence and that also the sequence can be changed in a dynamic way according to the application case. Furthermore, in the illustrated example only one local device <NUM> is used. However, there may be a network of several local devices <NUM> connected with the cloud computing platform <NUM> and/or the local devices <NUM> may have connections between themselves.

The second row <NUM> in <FIG> defines the affinity/preference (i.e. the contents of the respective affinity indicator) for the execution of a particular SA on a specific device <NUM> and/or a gateway <NUM> and/or the cloud <NUM>. Affinity towards the local device <NUM> means that the specific SA has a preference to be executed on the industrial pump itself (e.g. the controller <NUM> of the pump <NUM>). Similarly, a SA can have a preference to be executed on the IIoT gateway <NUM> or the IIoT cloud computing platform <NUM>.

Furthermore, it is possible that the execution of the SA can be changed in a dynamic way due to capacities or availability of the IIoT cloud computing platform <NUM> or other criteria such as runtime or data structure of the processed data.

The third row <NUM> in <FIG> represents the feature "moveable" defining if a particular SA can move, or be moved, to another possible computing unit, i.e. the content of an optional movability indicator. If the respective SA is moveable, this is indicated by a "+" sign in <FIG>; if the respective SA is not moveable, this is indicated by a "-" sign in <FIG>. For example, if the local device <NUM> is overburdened or does not have enough computing resources, the sub-algorithm SA1. <NUM> may move, or may be moved, to the IIoT gateway <NUM>. Similarly, if the IIoT gateway <NUM> is overburdened, the SA2 could move, or be moved, to the cloud computing platform <NUM> for execution.

<FIG> shows a schematic diagram of the entire system <NUM> with modules configured to implement the distributed analytics approach.

Each part of the IIoT system <NUM> - the cloud <NUM>, the IIoT gateway(s) <NUM> and the local device(s) <NUM> - comprises an analytics runtime module (ARM) <NUM>. That is to say, a runtime environment in which the one or more of the different sub-algorithms run is provided. This ARM <NUM> executes the different sub-algorithms SA1, SA2, SA3. In the local device <NUM>, the ARM <NUM> could be also part of the IIoT agent <NUM>. However, further configurations are possible. The industrial plant <NUM> and the cloud computing platform <NUM> may be separated by a firewall <NUM>. As the case may be, the two or more sub-algorithms may be executed in the runtime environment in the local device, the gateway or the cloud computing platform. This may be the case because the runtime environments are architecturally the same or similar and thus allow for the sub-algorithms to be deployed at the respective location. Now, if the availability of resources for example at the local device and/or the gateway change, e.g., are reduced due to other tasks performed by the local device, one or more of sub-algorithms deployed at the local device and/or the gateway may re-assigned to be executed in the cloud, i.e. moved to the cloud. The same is true for the other way around, i.e. when resources at the local device and/or the gateway are freed, one or more sub-algorithms may be moved from the cloud to the local device or the gateway.

The cloud computing platform <NUM> additionally contains an analytics workflow module (AWM) <NUM> and an analytics scheduler <NUM>. The AWM <NUM> manages the SAs and provides user interfaces for defining the SAs as illustrated in <FIG>. The scheduler <NUM>, in another embodiment, could also be a part of the IIoT gateway <NUM> to provide local scheduling capabilities. Furthermore, the cloud computing platforms <NUM> comprises a data base <NUM>, an analytics configuration database <NUM>, a communication module <NUM> and other IIoT modules <NUM>.

In the following the steps are described how the system can be used: An administrator or a data scientist may use a user interface provided by the AWM <NUM> to provide, in particular define, an analytics algorithm A together with the different SAs, their execution sequence, their affinity to IIoT devices, etc. Criteria such as computer performance, relevance to know-how and intellectual property, etc. are preferably used to define the SAs and their affinities (affinity indicators) to the cloud <NUM> or the local devices <NUM> and/or their movability indicators.

The AWM <NUM> saves this configuration in the analytics configuration database <NUM>. However, it is possible that a further software application is implemented in the AWM <NUM> which can dynamically adjust the execution sequence of the sub-algorithms according to criteria such as availability of the cloud computing platform <NUM>. This is especially of interest in the case of mobile local devices <NUM> which have limited access to the cloud <NUM>.

After the generation of the analytical algorithm A and the SAs the administrator triggers the deployment of the algorithm A along with the SAs. This could also be triggered automatically based on some other analytics results or criteria.

The analytics scheduler <NUM> reads the analytics configuration from the analytics configuration database <NUM>. It determines other criteria, such as resource availability on the IIoT gateway <NUM> and local device <NUM>, by querying these entities. Based on the configuration rules and the resource availability, the analytics scheduler <NUM> generates the scheduling plan for the SAs.

According to the scheduling plan, the analytics scheduler <NUM> provides the SA definitions to the analytics runtime module ARM <NUM> on the cloud computing platform <NUM>, the IIoT gateway <NUM> or the local device(s) <NUM> for the execution of the SAs. By defining several sub-algorithms SA1, SA2,. SAn a distributed analytics framework can be created. By splitting an analytical algorithm A into sub-algorithms SA1, SA2,. SAn an analytical data execution in the cloud computing platform <NUM> and/or on local device(s) <NUM> can be performed based on business and/or performance requirements.

With this approach, an analytics provider can better preserve her/his domain know-how or intellectual property as the domain specific part of the analytic algorithm A is executed in the cloud computing platform <NUM> under her/his control. This also allows an enhanced data security of the analytical models in the IIoT approach.

Additionally, since the sub-algorithms SA1, SA2,. SAn may be dynamically shifted between different local IIoT devices based on resources availability, this enhances the performance and minimizes bottlenecks in an IIoT system.

Especially, the distributed analytics approach may be used in open IIoT operating systems like MindSphere®.

The above embodiment regarding vibration data shows how an analytical algorithm A can be broken down into sub-algorithms SA1, SA2,. SAn and may then be executed on different devices in an IIoT context. Similarly, other analytical algorithms (clustering, neural networks, Support Vector Machines, blockchain, etc.) could be used and broken down into sub-algorithms SA1, SA2,.

<FIG> shows a schematic flow diagram illustrating a method according to an embodiment of the second aspect of the present invention. The method of <FIG> will be described partially using reference signs of <FIG>, although the method of <FIG> is not restricted to the embodiments described in <FIG>. On the other hand, the method of <FIG> may be executed using any of the embodiments described with respect to <FIG> and may, accordingly, be adapted and modified according to any variations and modifications described in the foregoing.

In a step S10, an analytical algorithm A is provided, e.g. defined, received or stored, in a network between one or more local device(s) <NUM> and a cloud computing platform <NUM>, the analytical algorithm being configured to process data collected and/or stored on the local device(s) <NUM> and/or stored on the cloud computing platform <NUM>.

In a step S20, the analytical algorithm A is sub-divided (or: split up) into at least two sub-algorithms SA1, SA2. Step S20 may be performed simultaneously with step S10. For example, when the analytical algorithm is being defined, it could be defined together with the sub-algorithms.

In a step S30, at least one of the at least two sub-algorithms SA1, SA2 is executed on (or by) the local device(s) <NUM>. A local device <NUM> according to the third aspect of the invention may be provided to perform the step S30 in particular.

In a step S40, at least one other of the at least two sub-algorithms SA2 is executed on (or by) the cloud computing platform <NUM>. Preferably, all of the sub-algorithms SA2 which are not executed on the local device <NUM> are executed on the cloud computing platform <NUM>. A cloud computing platform <NUM> according to the fourth aspect of the invention may be provided to perform the step S40 in particular.

<FIG> schematically illustrates a computer program product <NUM> comprising executable program code <NUM> configured to, when executed, perform the method according to the second aspect of the present invention, in particular as has been described with respect to <FIG> and/or <FIG>.

Claim 1:
A system for data analytics in a network between one or more local device(s) (<NUM>) and a cloud computing platform (<NUM>), the system comprising:
a processor configured to process data collected and/or stored on the local device(s) (<NUM>) and/or stored on the cloud computing platform (<NUM>) by an analytical algorithm (A) which is subdivided into at least two sub-algorithms (SA1, SA2), wherein at least one sub-algorithm (SA1) is executed on the local device(s) (<NUM>) and at least one other sub-algorithm (SA2) is executed on the cloud computing platform (<NUM>) based on an affinity/preference indicator, characterized wherein the affinity/preference indicator is defined regarding the location of execution and the run-time for each sub-algorithm, and based on data structure of the processed data, wherein location of execution is regarding distribution of the sub-algorithms (SA1, SA2) to their place of execution in accordance with the deployment.