EP3987719A1 - Détermination d'un événement dans un flux de données - Google Patents

Détermination d'un événement dans un flux de données

Info

Publication number
EP3987719A1
EP3987719A1 EP19734323.9A EP19734323A EP3987719A1 EP 3987719 A1 EP3987719 A1 EP 3987719A1 EP 19734323 A EP19734323 A EP 19734323A EP 3987719 A1 EP3987719 A1 EP 3987719A1
Authority
EP
European Patent Office
Prior art keywords
data
autoencoder
data stream
event
stacked
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19734323.9A
Other languages
German (de)
English (en)
Inventor
Bin Xiao
Valentin TUDOR
Aitor Hernandez Herranz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP3987719A1 publication Critical patent/EP3987719A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation

Definitions

  • This disclosure relates to methods, nodes and systems connected by a communications network. More particularly but non-exclusively, the disclosure relates to determining an event in a data stream.
  • the Internet of Things is widely regarded as the enabler for the digital transformation of consumers and industries.
  • Monitoring facility status e.g., various equipment, manufacture, logistics, autonomous vehicle, etc.,
  • environments, and industrial processes are one of the most essential components of the digital transformation.
  • Continuous monitoring may be achieved by employing a large variety of sensors to monitor, for example, physical conditions.
  • Data collected by such sensors often needs to be processed in a real-time fashion and transformed into information about the monitored environment that may be used as a source for triggering actuation.
  • Data from individual loT sensors may highlight individual problems.
  • processing data from many sensors e.g. high- dimensional data
  • concurrently can highlight system behaviors that may not be apparent in individual readings or even for someone possessing expert knowledge.
  • a condition monitor system may improve the management of the vehicles by enabling predictive maintenance, re-routing and expediting delivery for perishable goods and optimizing transportation routes based on contract requirements.
  • Radio Access Networks data collected from devices and sensors may be used to compute specific key performance indicators (KPIs) that reflect the current state and performance of the network.
  • KPIs key performance indicators
  • Fast processing of data originating from Radio Access Network (RAN) sensors helps in identifying problems which affect latency, throughput and cause packet loss.
  • high-dimensional data may offer additional valuable insights, but they require fast, online processing techniques that can complement traditional expert-led systems.
  • Event detection (e.g. for performance evaluation) in this environment has particular technical requirements.
  • any event detection system should i) be able to handle large volumes of different types of high-dimensional data from distributed sources, ii) be able to handle high density data flows: data may be generated at high speeds (i.e. milliseconds), plus the information carried by some data frames retrieved from such a data stream may be extremely sparse (and thus difficult to use directly for analysis), and iii) analysis must be conducted online for fast event detection and fast prediction.
  • prior domain knowledge (training labels, useful data models) regarding collected data may be sparse due to the various combinations of devices and changes in processes (e.g. limited domain expertise). Thus any systems should have minimized dependency on prior domain expertise.
  • systems should be replicable and reusable for different use cases, which means the whole solution (including the algorithms and other components) should be able to be applied onto different cases (with different data sets and different requirements) without significant additional bespoke code.
  • the data processing algorithm should also be dynamic such that the input size and model shape can be adjusted according to specific requirements.
  • Scalable solutions based on the number of data processing nodes are also desirable.
  • High comparability for loT ecosystems should be provided so that it can be applied into large scale distributed data-intensive scenarios, such as smart manufacturing, RAN, and intelligent vehicle systems, etc.
  • Autoencoders are a type of machine learning algorithm able to concentrate the information in high dimensionality data. Concentrating or reducing the dimensionality of high dimensional data makes it easier to analyze and determine events or anomalies in the data.
  • a data stream may be split into portions and different key performance indicators (KPIs) may be calculated for each portion.
  • KPIs key performance indicators
  • Such solutions may therefore be suboptimal for loT data processing, due to their relative weakness at processing high dimensional data.
  • each model e.g. each autoencoder
  • shape and size e.g. the number of neurons in each layer of each autoencoder, the number of layers of neurons in each autoencoder, or the number of levels of autoencoders in the stacked hierarchy may be fixed
  • Such solutions may have limited efficacy on data processing of dynamic environments and for different use cases, due to the static features.
  • Some available solutions may also lack the required scalability. Although many available Al solutions have been claimed as scalable in the sense of system deployment, the algorithms themselves may not be scalable. For example, in autoencoder solutions, the number of autoencoders may not easily be scaled up or down according to the increasing amount of data sources, once the model is loaded.
  • Both data and system components may be geographically distributed; but the solutions to integrate information from distributed heterogeneous streams are still relying on static models, which may not flexible enough for changes in the process. That further makes it difficult to be reused and replicable for different use cases. This brings limits on and reusability.
  • a computer implemented method of determining an event in a data stream comprising data from a plurality of devices connected by a communications network.
  • the method comprises using a distributed stacked autoencoder to concentrate information in the data stream, and determining the event from the concentrated data.
  • the solution may be distributed across multiple nodes (e.g. different devices, edge, fog, network infrastructure, and/or the cloud).
  • nodes e.g. different devices, edge, fog, network infrastructure, and/or the cloud.
  • a system for determining an event in a data stream comprising data from a plurality of devices connected by a communications network.
  • the system is configured to use a distributed stacked autoencoder to concentrate information in the data stream, and determine the event from the concentrated data.
  • the method comprises receiving a first data stream, the first data stream comprising data from a plurality of devices in a communications network, and using a first autoencoder to concentrate the information in the first data stream, wherein the autoencoder forms part of a distributed stacked autoencoder.
  • a node of a communications network comprising a processor.
  • the processor is configured to receive a first data stream, the first data stream comprising data from a plurality of devices in a
  • the node is further configured to use a first autoencoder to concentrate the information in the first data stream, wherein the autoencoder forms part of a distributed stacked autoencoder.
  • a computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method as described in the first and third aspects.
  • Fig. 1 shows an example method according to some embodiments herein
  • Fig. 2 shows an example architecture of a stacked autoencoder according to some embodiments herein;
  • Fig. 3 shows an example cosine distance matrix according to some embodiments herein;
  • Fig. 4 shows three example output visualisations according to some
  • Fig. 5 shows an example method according to some embodiments herein
  • Fig. 6 shows an example graphical user interface according to some
  • Fig. 7 shows an example system according to some embodiments herein
  • Fig. 8 shows an example system according to some embodiments herein;
  • Fig. 9 shows an example method according to some embodiments herein.
  • Fig. 10 shows an example node according to some embodiments herein;
  • Fig. 1 1 shows an example system according to some embodiments herein;
  • Fig. 12 shows an example computer program product according to some embodiments herein.
  • loT data presents technical challenges for event detection and performance evaluation of the loT environment.
  • Figure 1 illustrates a computer implemented method 100 of determining an event in a data stream, the data stream comprising data from a plurality of devices connected by a communications network, according to some embodiments herein.
  • the method comprises using a distributed stacked autoencoder to concentrate information in the data stream.
  • the method then comprises determining the event from the concentrated data.
  • the solution may be distributed across many different nodes (e.g. different devices, edge, fog, network infrastructure, and/or the cloud).
  • Such distributed resource orchestration benefits the usage and optimization of all the nodes in the system. This provides a high level of scalability, as the solution may be scaled according to the number of devices and nodes in the loT system.
  • the distributed nature may provide another advantage by enabling parts of the data stream to be processed in nodes close to the data source (e.g. source devices), reducing latency.
  • such a solution may advantageously provide reusability and replicability and may quickly be adapted and applied to different use cases where high-dimensional data in high-density is produced.
  • the data stream may comprise data from a plurality of devices.
  • Such devices include but are not limited to, devices for environment monitoring, devices for facilitating smart manufacture, devices for facilitating smart automotives, and/or devices in, or connected to a Communications Network (e.g. such as a Radio Access Network, RAN, network).
  • the data stream may comprise data from network nodes, or comprise software and/or hardware collected data. Examples of specific devices, include but are not limited to, temperature sensors, audio visual equipment such as cameras, video equipment or microphones, proximity sensors and equipment monitoring sensors.
  • the data in the data stream may comprise real time, or near-real time data.
  • the method 100 may be performed in real time, e.g. such that there is minimal or little delay between collection of and processing of the data.
  • the method 100 herein may be performed at a rate comparable to a rate of data production of the data stream (e.g. the method 100 may be performed such that an appreciable back-log of data does not begin to accumulate).
  • the plurality of devices are connected by a communications network. Examples of communications networks include, but are not limited to, radio access networks (RAN), wireless local area network (WLAN or WIFI), and wired networks.
  • the devices may form part of the communications network, for example part of a radio access network (RAN), part of a WLAN or WIFI network.
  • the devices may communicate across the communications network (e.g. smart manufacturing or smart automotive embodiments).
  • the event may comprise any data readings of interest. For example, statistically outlying data points.
  • the event may relate to an anomaly.
  • the event may relate to a performance indicator of a system (e.g. unusual or undesirable system behaviour).
  • autoencoders are a type of machine learning algorithm that may be used to concentrate data.
  • Autoencoders are trained to take a set of input features and reduce the dimensionality of the input features, with minimal information loss.
  • Training an autoencoder is generally an unsupervised process, as the autoencoder is divided into two parts, an encoding part and a decoding part.
  • the encoder and decoder may comprise, for example, deep neural networks comprising layers of neurons.
  • An encoder successfully encodes or compresses the data if the decoder is able to restore the original data stream e.g. within a tolerable loss of data.
  • Training may comprise reducing a loss function describing the difference between the input (raw) and output (decoded) data. Training an encoder thus involves optimising the data loss of the encoder process.
  • An autoencoder may be considered to concentrate the data (e.g. as opposed to merely reducing the dimensionality) because essential or prominent features in the data are not lost.
  • a stacked autoencoder comprises two or more individual autoencoders that are arranged such that the output of one is provided as the input to the other autoencoder. In this way, autoencoders may be used to sequentially concentrate a data stream, the dimensionality of the data stream being reduced in each autoencoder operation.
  • a stacked autoencoder provides a dilatative way to concentrate information along the whole intelligence data pipeline. Also, due to the fact that each autoencoder residing in each node (or processing unit) is mutually chained, it may provide the advantage that the stacked autoencoder can grow according to the information complexity of the inputted data dimensions.
  • the stacked autoencoder herein may be distributed such that different constituent autoencoders reside on different nodes (e.g. different servers, equipment or devices of the communications network). One or more of the constituent autoencoders of the stacked autoencoder may, for example, be cloud-based or otherwise be accessible via the internet. A distributed system may avoid computation bottlenecks.
  • the stacked autoencoder may comprise a stacked deep autoencoder (e.g. each constituent autoencoder may comprise multiple, e.g. four or more, hidden layers of neurons). Generally performance may be improved with increasing numbers of hidden layers (e.g. increasing model depth).
  • the use of deep autoencoders may provide the advantage of ensuring that each individual autoencoder can handle high-dimensional data and is thus more generative.
  • the distributed nature may also provide the advantage of a working balance of nodes that may run anywhere. In particular, the nodes may be located closer to the place where data is generated.
  • FIG. 2 illustrates a stacked deep autoencoder arrangement 200 according to some embodiments herein whereby deep autoencoders 202, 204,
  • Each autoencoder comprises an encoder and decoder, as is illustrated for the autoencoder 202 by reference numerals 218 and 220 respectively.
  • the encoders and decoders each comprise a plurality of layers of neurons, as indicated for encoder 218 by the reference numeral 222.
  • the autoencoders are arranged into hierarchical levels of the stacked autoencoder 200.
  • the output of autoencoders 202 and 204 are fed as inputs to autoencoder 206.
  • the outputs of autoencoders 206 and 208 are provided as inputs to autoencoder 210.
  • autoencoders 202 and 204 are comprised in one level
  • autoencoders 206 and 208 are comprised in the next level
  • autoencoder 210 is comprised in a last level of stacked autoencoder 200.
  • this arrangement is merely an example and that the stacked
  • autoencoders in other embodiments herein may be comprised of any number of autoencoders in any hierarchical arrangement of levels.
  • using a distributed stacked autoencoder may comprise dividing the data stream into one or more sub-streams of data, using a different autoencoder of the distributed stacked autoencoder to concentrate the information in each respective sub-stream, and providing the concentrated sub-streams to another autoencoder in another level of the hierarchy of the stacked autoencoder.
  • a data stream may be divided into sub-streams and processed by different autoencoders of the stacked autoencoder, for example, based on geographic location or processing constraints of the different nodes on which the autoencoders reside.
  • feature extraction may be chained and can be iteratively conducted close to the data resources in quick time.
  • the different autoencoders may be comprised in the same level of the hierarchy of the stacked autoencoder. For example, there may be a level of autoencoders in the stacked autoencoder that may take (as input) unconcentrated data and perform a first concentration of the data sub-streams. Another level may then take the concentrated sub-streams and combine and concentrate them further.
  • the different autoencoders may be comprised in different levels of the hierarchy of the stacked autoencoder.
  • different levels of the stacked autoencoder may take (as input) different combinations of unconcentrated and partially concentrated sub-streams of data.
  • the unconcentrated (or “raw”) data sub-streams may enter the stacked autoencoder in different levels of the autoencoder hierarchy.
  • the method 100 may further comprise accumulating data in the data stream, and dividing the accumulated data stream into a plurality of consecutive windows, each window corresponding to a different time interval. Using the distributed stacked autoencoder may then comprise concentrating the information in the windowed data.
  • Partitioning the data stream (or sub-streams) into windows essentially groups mini-batches of data for processing. Concentrating each window may enable a near- continuous stream of data be concentrated (or summarised) into a single set of feature values for each window. These feature values may then be compared between windows in order to determine windows (e.g. time periods) in which an event is taking place.
  • the size (e.g. duration) of the window may determine the granularity or minimum time interval in which an event may be determined.
  • the size of the windows may depend on the use case and may thus be configurable according to different requirements.
  • the method may further comprise training the stacked autoencoder, using the windowed data. The skilled person will be familiar with methods for training a stacked autoencoder, which may be performed in an unsupervised manner, autonomously from the data flow.
  • each autoencoder of the stacked autoencoder comprises layers of neurons.
  • the numbers of layers of neurons in any constituent autoencoder of the stacked autoencoder may be determined based on the window size (e.g. duration or time interval corresponding to one window).
  • the method 100 may further comprise determining a number of layers in the stacked autoencoder (e.g. in constituent autoencoders of the stacked autoencoder) based on: a window size, a data transmission frequency associated with the data stream, and/or a dimensionality associated with the data stream.
  • determining the number of layers in the stacked autoencoder may further comprise optimising the number of layers with respect to a latency associated with the stacked autoencoder. For example, whilst increasing the number of layers may increase the concentration of the data (and thus facilitate improved event detection), too many layers may increase the latency beyond acceptable limits. Put another way, too many layers may introduce unnecessary computation burdens and create more latency for the computation, while too few layers may risk weakening the expressive ability of the model and might impact on the performance. Thus a compromise may need to be reached.
  • t window comprises a time interval associated with a window
  • f comprises a data transmission frequency associated with the data stream
  • c comprises a scale factor
  • D comprises a dimensionality associated with the data stream.
  • t window may comprise, for example, the time interval (or duration) of each window.
  • D may comprise, for example, the number of dimensions of the data.
  • Each dimension may comprise, for example, data from a different device or sensor).
  • the scale factor, c may comprise a configurable parameter that describes, in general, how an autoencoder in the stacked autoencoder may be shaped. For example, c may determine whether an autoencoder has a relatively small number of layers, but a lot of neurons in each layer (short-wide configuration) or a relatively large number of layers, but a small number of neurons in each layer (long-narrow configuration).
  • the method may further comprise determining a number of neurons in a layer (e.g. a layer of an individual autoencoder) of the stacked autoencoder.
  • each subsequent hidden layer may be labelled L0,
  • the layer after layer n may be marked as layer n+1 , and thus the number of neurons for layer n+1 may be marked as Ni ay er N+i ; where N is a variable from 0 to M.
  • the autoencoders proposed herein may be symmetric in structure.
  • the method may further comprise determining a number of neurons in a layer (e.g. a layer of an individual autoencoder) of the stacked autoencoder according to the following formula:
  • Niayer N+1 int (Niayer N ( 1”C))
  • Ni ayer comprises the number of neurons in a n th layer of the stacked autoencoder
  • Ni ayer N+i comprises the number of neurons in the n+1 th layer
  • C comprises a constant
  • the constant C may be described as a layer decreasing rate. It may be a constant defined by the system hyperparameter. Generally, in some embodiments, C may be a number between (0,1 ). In some embodiments C is less than 0.25.
  • the method may comprise accumulating the concentrated data over time, and determining 104 the event from the concentrated data by comparing different portions of the accumulated concentrated data.
  • the method may comprise accumulating the concentrated data (e.g. output features of the stacked autoencoder) for a certain amount of time, or for a certain number of windows.
  • the concentrated data e.g. output features of the stacked autoencoder
  • the computation tasks associated with the method 100 progress by the moving of the windows.
  • the extracted features are accumulated with the moving of the windows (e.g. sliding windows).
  • the feature extraction described in previous steps may be performed every 10 seconds over the course of an hour.
  • the time range for buffering samples may be set as 60 seconds and will accumulate 360 data by monitoring and extract the features from the data generated in each 10 milliseconds.
  • the method may then comprise comparing the accumulated concentrated data comprised in different windows in order to determine the event.
  • the method may further comprise determining an event based on statistically outlying windows.
  • determining the event may comprise using a cosine difference to compare the different portions of the accumulated concentrated data.
  • Fig. 3 shows a cosine matrix 300 that may be used to determine the events.
  • Each output feature, F 0 to F n-i of the distributed stacked autoencoder is compared to the other output features using the cosine difference.
  • An average difference may be defined for each feature as illustrated in row 302 of matrix 300.
  • Events may correspond to values that deviate in a statistically significant manner from the determined average values.
  • the accumulated reduced feature values may be analysed and compared in order to determine time windows in which an event (e.g. anomaly) has occurred.
  • a window with a statistically significant (e.g. high) cosine distance compared to other windows may be labelled as an event with respect to the other accumulated windows.
  • a window may comprise an event if the cosine difference is above a threshold.
  • the event determination may be conducted in two phases: the first phase detects windows with significantly large distances from the rest of the populations based on the previous computations; the second phase conducts supervised learning on the accumulated output features of the distributed stacked autoencoder and determined labels from the first (unsupervised) learning phase.
  • cosine distance measuring may be utilized to calculate the pairwise distances between the elements in the accumulated output of feature extraction, which may accordingly form a cosine distance matrix as described above with respect to Fig. 3.
  • calculating a cosine distance may be more advantageous compared to, for example, a Euclidean distance calculation. This is because in some
  • extracted features may be reconstructed using, for example, a Markov Chain Monte Carlo (MCMC) method.
  • MCMC Markov Chain Monte Carlo
  • the output is randomly generated which keeps the same probabilistic distribution features.
  • the distribution is also unknown.
  • the Euclidean distance may thus not produce as meaningful results.
  • the calculated results may be written into storage from the buffering, and can therefore be subsequently used in data analysis processes, e.g. visualization.
  • a supervised learning based event detection may be carried out.
  • this may comprise training a classification machine learning model (such as a deep neural network) to determine events directly from the output features of the distributed stacked autoencoder (e.g. without needing to compute the cosine distance matrix).
  • a machine learning model may be trained using the labelled data produced during the unsupervised learning phase (e.g. from the labels produced by computing the cosine matrices). This is based on a condition that the previous unsupervised event detection phase has accumulated enough labelled events in the knowledge repo to support such label-based training.
  • Figs 4a, 4b and 4c Example plots of output data are shown in Figs 4a, 4b and 4c.
  • Fig. 4a is a plot showing the mean distance compared to other time periods (e.g. the“raw” output data).
  • Fig. 4(b) shows a plot of normalised scalars of each KPI derived from the distances and
  • Fig. 4c shows a plot of features derived from the KPIs.
  • the skilled person will appreciate that these are example plots and that other outputs and/or data
  • Data visualization in this manner may be implemented based on the output feature data being stored.
  • the method 100 may also expose data to other components which allows the method 100 to be integrated into an loT ecosystem.
  • the analyzed results may be exposed to a database for visualization purposes.
  • the output data of method 100 may be used to enrich human knowledge for decision support.
  • the data may be exposed to other systems, like management or Enterprise Resource Planning (ERP) systems.
  • ERP Enterprise Resource Planning
  • the data may further be made available to actuation or visualization systems (e.g. screens/monitors/dashboards etc) or any other means of providing feedback to a user.
  • FIG. 5 shows a computer implemented method 500 of determining an event in a data stream according to some embodiments herein.
  • the method 500 comprises collecting and preprocessing raw data comprised in the data stream. This may comprise, for example, receiving and collecting raw data (e.g. relevant information) from which events (e.g. intelligence) should be extracted.
  • raw data e.g. relevant information
  • events e.g. intelligence
  • Different nodes may each collect a sub-stream of the raw data in the data stream. For example, in some embodiments, each node may collect raw data from devices in its geographic vicinity. As such, collecting and preprocessing may be performed in a distributed or parallel manner.
  • Different devices may have one or multiple different communication protocols, one or multiple different data models, and/or one or multiple different serialization mechanisms.
  • the user e.g. system administrator or integrator
  • the user may be aware of the data payload (data models and serialization), and thus be able to configure an autoencoder to collect and unify different data formats.
  • a user may, during the deployment of an autoencoder of the stacked autoencoder, configure where and/or how data should be collected.
  • the raw data comprised in the data stream may be converted (changed formats) in order to provide a consistent and homogenous data set.
  • the“Data input” defines how the data are retrieved. Depending on the steps the data could vary among sensor data, monitoring data, aggregated data, features matrices, reduced features, distances matrices, etc.,
  • The“Data output” (data sink): defines how the data are sent. Depending on the steps the data could vary among sensor data, monitoring data, aggregated data, features matrices, reduced features, distances matrices, etc.,
  • loT devices“X” send raw data in a specific format
  • loT devices ⁇ send JavaScript object notation (JSON) data.
  • collecting and preprocessing 502 the raw data may comprise conversion of data from devices“X” to the JSON data format.
  • the way that a certain node (or unit) forwards data to the next unit is defined in the“sink”.
  • the“sink” could be specified, for example, to make the output be provided in JSON format.
  • the method 500 comprises accumulating the (pre- processed) data in the data stream, and dividing the accumulated data stream into a plurality of consecutive windows. Accumulating data in a data stream and dividing the accumulated data stream into a plurality of consecutive windows was described above with respect to the method 100 and the details therein will be understood to apply equally to block 504 of method 500.
  • the method comprises establishing a distributed stacked autoencoder.
  • a first phase may comprise building (e.g. deploying) the distributed stacked autoencoder.
  • the deployed distributed stacked autoencoder may then be trained on the (or a subset of the) accumulated pre- processed data. Training the distributed stacked autoencoder was described above with respect to the method 100 and the details therein will be understood to apply equally to block 506 of method 500.
  • the method 500 may then comprise using the distributed stacked autoencoder to concentrate information in the data stream.
  • the distributed stacked autoencoder to concentrate information in a data stream was described above with respect to block 102 of the method 100 and the details therein will be understood to apply equally to block 508 of the method 500.
  • using 102, 508 the distributed stacked autoencoder to concentrate the information in the data stream may comprise conducting feature extraction on the information in the data stream.
  • Feature extraction may be conducted, by applying the distributed stacked autoencoder models onto the accumulated data windows. As described above with respect to method 100, Each sliding window outputs a data frame in temporal order with a certain defined interval.
  • feature extraction may be performed in two dimensions. For example, feature extraction (e.g. compression) may be formed in a time dimension and/or a feature dimension.
  • each sliding window will accumulate 1000 data items if the time length for the sliding window is defined as 10 seconds.
  • Concentration of the data may help to summarize the information of the data frame and provide comprehensive information by decreasing the temporal length of the data frame.
  • Sensor data collected from loT can be very complex due to its high-dimensional features; in many cases, it is almost impossible to understand the running status of the whole system by looking on the collected sensor data sets (not even for the domain expertise). Therefore, the high-dimensional data may be processed to extract the most significant features to decrease the unnecessary information complexity and to identify the most significant features from the data frame.
  • the extracted feature from one or a group of deep autoencoders can be the input of another deep autoencoder.
  • the deep autoencoders may be orchestrated among distributed nodes which forms a data pipeline.
  • this step concentrates and extracts the received information carried by the collected data, then the refined data (as features) may be sent to the coming execution units.
  • the refined data as features
  • large volumes of high-dimensional data may be much more easily processed and transmitted in an efficient way.
  • the method 500 comprises accumulating the concentrated data over time, and in a block 512, the method 500 then comprises determining the event by comparing different portions of the accumulated concentrated data. Accumulating the concentrated data and determining the event were described in detail above with respect to the method 100 and the details therein are to be understood to apply equally to blocks 510 and 512 of the method 500.
  • the raw data pertaining to the event may be obtained by comparing the time stamps of the window in which the event was determined, with the time stamp(s) of the original raw data.
  • the method 500 may further comprise performing logic verification. This block may bring domain expertise to verify the events determined in block 512. For example, if an event is determined automatically (e.g. based on statistically outlying data) then the event may be verified based on rule-based reasoning (which may comprise, for example,“common sense” event criteria). In some embodiments if an event goes against the rule-base, then it may be excluded. More generally in block 514, the method may comprise linking a determined event back to the underlying raw data (e.g. according to time stamps) and inputting the raw data for the event to a logic verifier.
  • rule-based reasoning which may comprise, for example,“common sense” event criteria.
  • the method may comprise linking a determined event back to the underlying raw data (e.g. according to time stamps) and inputting the raw data for the event to a logic verifier.
  • This block may use second-order logic to verify whether the detected event has any logic confliction with the existing common-sense knowledge in the domain.
  • the detected conclusion from the previous stage may be streamed to the current processor in a form of an assertion.
  • the knowledge base includes two parts: the fact base and the rule base.
  • a schema provided for the knowledge base may be based on a close-space assumption, which means the logic verification is conducted using the currently available rule-set.
  • the user may be guided through a knowledge provision process using a graphical user interface, GUI, such as that illustrated in Fig. 6.
  • GUI graphical user interface
  • the GUI of Fig. 6 provides input fields 602, 604 and 606 that enable a user to input a rule in three different formats (subject, verb, object; subject copula, predictive; and an if-then statement respectively).
  • Existing facts and rules may be shown to the user, for example, in boxes 608 and 610.
  • the method 500 may comprise providing (e.g. displaying) event data to a user.
  • the method may comprise displaying information pertaining to a detected event to a user. Examples of graphs illustrating detected events were shown in Figs. 4a, 4b and 4c and the details described above with respect to Figs 4a, 4b and 4c will be understood to apply equally to block 516 of method 500.
  • a system 700 for determining an event in a data stream comprising data from a plurality of devices connected by a communications network.
  • the system 700 is configured to use a distributed stacked autoencoder to concentrate information in the data stream, and determine the event from the concentrated data.
  • system 700 may be configured to perform any embodiments of the method 100 or the method 500 as described above and the details of the methods 100 and 500 will be understood to apply equally to the configuration of the system 700.
  • the system 700 may comprise a plurality of concentrating nodes 702. Each concentrating node of the plurality of concentrating nodes may comprise an autoencoder of the distributed stacked autoencoder.
  • the system 700 may further comprise an event detection node 704, configured to receive concentrated data from the distributed stacked autoencoder and determine the event from the concentrated data.
  • a concentrating node may comprise any node suitable for storing and operating an autoencoder forming part of a stacked autoencoder.
  • Examples of concentrating nodes include, but are not limited to devices, user devices, processors, servers, sensors, mechanical equipment, monitoring equipment, cloud platforms or any other device forming part of an loT system.
  • a concentrating node may comprise an interface for receiving data (such as the data stream or a sub-stream of the data stream as described above) and an interface for sending (e.g. transmitting) data (e.g. such as the output of an autoencoder) to another concentrating node of the plurality of concentrating nodes, or to the event detection node.
  • the event detection node may comprise any node suitable for receiving concentrated data from the distributed stacked autoencoder and determining the event from the concentrated data.
  • the event detection node may be distributed or cloud-based.
  • the event detection node may comprise a receiving interface for receiving the concentrated data.
  • the event detection node may further comprise a processor and a memory.
  • the memory may store a set of instructions that when executed by the processor may cause the processor to determine the event from the concentrated data.
  • the event detection node may further comprise one or more user interfaces (e.g. a display screen, a mouse, a keyboard etc) for example, for displaying event data to a user or for receiving user input.
  • each concentrating node in the plurality of concentrating nodes may be further configured to accumulate data in the data stream, divide the accumulated data stream into a plurality of consecutive windows, each window corresponding to a different time interval, and use a respective autoencoder of the distributed stacked autoencoder to concentrate the information in the windowed data.
  • the event detection node may be further configured to accumulate the concentrated data over time, and determine the event by comparing different portions of the accumulated concentrated data. Accumulating the
  • Fig. 8 illustrates a system 800 according to some embodiments herein.
  • the system relates to smart manufacturing and the events relate to performance evaluation and anomaly detection of the smart manufacturing process.
  • heterogeneous devices and/or equipment 802 are geographically distributed. In manufacturing, it is important to understand the performance of the automated production line and determine any anomalies. However, a domain expert may not have enough knowledge to provide insights into the data produced, particularly if the smart manufacturing production line is newly introduced or assembled.
  • the categories of deployed equipment/sensor devices can be very complex (high-dimensional data); the speed of data generation can be very high (data streams come in high-density); the equipment/sensor devices may serve different production units in different geographical locations (heterogeneity of devices and distributed topology); the production may be scaled up and down for different environments; and the data should be processed in a real time manner such that the results may quickly be determined.
  • Such use cases further require a technical solution which should: handle high-dimensional data streams in high-density, be fully scalable, highly reusable, and highly replicable.
  • System 800 addressed these issues by providing online event (anomaly) analysis for the online data through an intelligence data pipeline which conducts raw-data-in and intelligence-out, as shown in Figure 8.
  • Each block shown in Fig. 8 corresponds to a computing unit, which may be centralised into units or distributed across different units.
  • the constructed intelligence data pipeline accepts raw data (e.g. JSON objects) data from all the devices and sensors 802 which may be geographically distributed across factory sites.
  • the collected data represents information from different production components (and may include data about the production environments).
  • the data may be transmitted by a data transmission block 804 for collection by a raw data parser block 806 and preprocessing by a data washing block 810.
  • the preprocessed data may then be concentrated using distributed stacked autoencoder 812 to concentrate the information in the data stream.
  • Feature extractions are conducted in different levels of distributed stacked autoencoder 812. Using a distributed stacked autoencoder to concentrate information in the data stream was described above with respect to methods 100 and 500 and the details therein will be understood to apply equally to system 800.
  • the data concentration e.g. feature extraction
  • the output of the distributed stacked autoencoder 812 is fed into an distance calculator 814 which determines event(s) from the concentrated data e.g. by calculating cosine distances in an unsupervised manner as described above.
  • the results may be passed to a conclusion summarizer 816 and/or a
  • the visualisation module 818 for visualising the concentrated data.
  • the visualisation module 818 may produce graphical output such as that illustrated in Figs. 4a, b and c.
  • Rules or criteria for determining or verifying an event may be input via logic verification module 822. Performing logic verification was described above with respect to method 500 and the details therein will be understood to apply equally to logic verification module 822.
  • Logic verification module 822 may interact with a database 824 for storing, for example, event criteria and/or rules.
  • a supervised learner 820 may then be trained to detect events from (e.g. directly from) the data stream, using the labelled events determined using the distance calculator 814 and corresponding raw data as training data for the unsupervised learner 820.
  • the output 826 of the system 800 comprises information relating to a determined event.
  • the method 900 comprises receiving a first data stream, the first data stream comprising data from a plurality of devices in a communications network.
  • the method then comprises using a first autoencoder to concentrate the information in the first data stream, wherein the autoencoder forms part of a distributed stacked autoencoder.
  • the node 900 may comprise, for example, one of the plurality of concentrating nodes 702 as described above with respect to the system 700 and the details described therein will be understood to apply equally to the node 900.
  • the first autoencoder comprises part of a stacked autoencoder.
  • the first data stream may further comprise output features of a second autoencoder in the distributed stacked autoencoder.
  • the second autoencoder may reside on a second node.
  • the autoencoder on the node 900 may take as input raw data and/or output features of another (e.g. second) autoencoder of the stacked autoencoder.
  • the method 900 may further comprise sending the concentrated first data stream to a third node in the communications network, wherein the third node comprises a third autoencoder in the distributed stacked autoencoder.
  • the outputs of the first second and third autoencoders on the first second and third nodes may be chained to form the stacked autoencoder.
  • a node 1000 connected to a communications network.
  • the node comprises a processor 1002.
  • the processor 1002 is configured to receive a first data stream, the first data stream comprising data from a plurality of devices in a communications network.
  • the processor 1002 is further configured to use a first autoencoder to concentrate the information in the first data stream, wherein the autoencoder forms part of a distributed stacked autoencoder.
  • the first data stream further comprises output features of a second autoencoder in the distributed stacked autoencoder. This was described above with respect to the method 900 and the details therein will be understood to apply equally to this embodiment.
  • the processor may be further configured to send the concentrated first data stream to a third node in the communications network.
  • the third node comprises a third autoencoder in the distributed stacked autoencoder. This was described above with respect to the method 900 and the details therein will be understood to apply equally to the configuration of the processor 1002.
  • Fig. 1 1 shows an example system according to some embodiments herein.
  • a plurality of devices 1 102 which may comprise any one or any combination of devices in the manufacturing, smart city, automotive, agricultural and/or transportation domains.
  • the plurality of devices 1 102 produce a data stream comprising for example, sensor/equipment readings as well as, for example, system updates.
  • the plurality of devices are connected by a
  • the communications network comprises one or more nodes such as a Local loT gateway 1 104, an Indoor/Outdoor Small cell 1 106 and/or a Radio site 1 108.
  • Gateways 1 104, 1 106 and 1 108 may be connected, for example, to a baseband network 1 1 12 and/or a Fog network 1 1 10.
  • a Fog network is a decentralized computing infrastructure which stores data, runs applications and performs communications at locations between the source of the data source and the cloud. As such, Fog may allow data to be processed and/or stored closer to where it is produced.
  • the communications network may further comprise network infrastructure 1 1 14 and a data center/cloud 1 1 16.
  • a distributed stacked autoencoder may be deployed across one or more of the nodes 1 104, 1 106, 1 108, 1 1 10, 1 1 12, 1 1 14 and 1 1 16.
  • the system is configured to use the distributed stacked autoencoder to concentrate information in the data stream produced by the plurality of devices 1 102 and determine an event from the
  • a computer program product 1200 comprising a computer readable medium, the computer readable medium having computer readable code 1202 embodied therein.
  • the computer readable code may be configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform any of the embodiments of the methods 100, 500 and 900 as described above.
  • a computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Medical Informatics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Artificial Intelligence (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Dans un procédé, mis en œuvre par ordinateur, de détermination d'un événement dans un flux de données, le flux de données comprenant des données provenant d'une pluralité de dispositifs connectés par un réseau de communication, un autocodeur empilé distribué est utilisé (102) pour concentrer des informations dans le flux de données. Un événement est ensuite déterminé (104) à partir des données concentrées.
EP19734323.9A 2019-06-20 2019-06-20 Détermination d'un événement dans un flux de données Pending EP3987719A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/066395 WO2020253963A1 (fr) 2019-06-20 2019-06-20 Détermination d'un événement dans un flux de données

Publications (1)

Publication Number Publication Date
EP3987719A1 true EP3987719A1 (fr) 2022-04-27

Family

ID=67107404

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19734323.9A Pending EP3987719A1 (fr) 2019-06-20 2019-06-20 Détermination d'un événement dans un flux de données

Country Status (2)

Country Link
EP (1) EP3987719A1 (fr)
WO (1) WO2020253963A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018224669A1 (fr) * 2017-06-09 2018-12-13 British Telecommunications Public Limited Company Détection d'anomalie dans des réseaux informatiques
US10999247B2 (en) * 2017-10-24 2021-05-04 Nec Corporation Density estimation network for unsupervised anomaly detection
GB2567850B (en) * 2017-10-26 2020-11-04 Gb Gas Holdings Ltd Determining operating state from complex sensor data

Also Published As

Publication number Publication date
WO2020253963A1 (fr) 2020-12-24

Similar Documents

Publication Publication Date Title
US11150974B2 (en) Anomaly detection using circumstance-specific detectors
US20230316112A1 (en) Computer-based systems configured for detecting, classifying, and visualizing events in large-scale, multivariate and multidimensional datasets and methods of use thereof
US20210326128A1 (en) Edge Computing Platform
CN110865929B (zh) 异常检测预警方法及系统
US10007513B2 (en) Edge intelligence platform, and internet of things sensor streams system
Hayes et al. Contextual anomaly detection in big sensor data
Yang et al. A time efficient approach for detecting errors in big sensor data on cloud
Soni et al. Machine learning techniques in emerging cloud computing integrated paradigms: A survey and taxonomy
Nguyen et al. Deep learning for proactive network monitoring and security protection
Guan et al. Ensemble of Bayesian predictors and decision trees for proactive failure management in cloud computing systems.
US11409962B2 (en) System and method for automated insight curation and alerting
Nguyen et al. A resource usage prediction system using functional-link and genetic algorithm neural network for multivariate cloud metrics
WO2019025944A1 (fr) Procédé intégré pour automatiser la mise en œuvre d'accords de niveau de service pour des services en nuage
Yang et al. Netflow monitoring and cyberattack detection using deep learning with ceph
US20230133541A1 (en) Alert correlating using sequence model with topology reinforcement systems and methods
Solmaz et al. ALACA: A platform for dynamic alarm collection and alert notification in network management systems
Alkasem et al. Cloud computing: a model construct of real-time monitoring for big dataset analytics using apache spark
Shi et al. Machine Learning‐Based Time‐Series Data Analysis in Edge‐Cloud‐Assisted Oil Industrial IoT System
Zhu et al. Learning spatial graph structure for multivariate KPI anomaly detection in large-scale cyber-physical systems
Shahid et al. SLMAD: statistical learning-based metric anomaly detection
EP3987719A1 (fr) Détermination d'un événement dans un flux de données
US20220385545A1 (en) Event Detection in a Data Stream
Streiffer et al. Learning to simplify distributed systems management
Abdellah et al. Artificial intelligence driven 5g and beyond networks
Sharma et al. Two-tier analyzed content filtering based data management architecture in industry 4.0

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211214

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230515