WO2023214910A1

WO2023214910A1 - Machine for device verification and anomaly checking

Info

Publication number: WO2023214910A1
Application number: PCT/SE2023/050331
Authority: WO
Inventors: Bin Xiao; Toni MASTELIC; Darko Huljenic; Peter VON WRYCZA
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-05-03
Filing date: 2023-04-11
Publication date: 2023-11-09

Abstract

A method, system, and apparatus are disclosed. A DT emulator (6) is configured to communicate with a plurality of IoT devices (22). The DT emulator (6) includes processing circuitry (36). The processing circuitry (36) is configured to receive data from the plurality of IoT device (22), the received data being associated with a plurality of parameters; select a subset of received data corresponding to a subset of the plurality of parameters; generate time series data based on the selected subset of received data; generate a graphical model based on the time series data and Gaussian noise, the graphical model defining relations between the subset of the plurality of parameters; generate emulated data different from the received subset of received data based on the graphical model, the emulated data having a same structuralized schema as the received subset of received data; and perform at least one action based on the emulated data.

Description

MACHINE FOR DEVICE VERIFICATION AND ANOMALY CHECKING

TECHNICAL FIELD

The present disclosure relates to machine learning, and in particular, to an interpretable digital twin (DT) emulator for device verification and anomaly checking.

BACKGROUND loT Device Platform

Internet of Things (loT) is widely regarded as an 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 components of digital transformation. Continuously monitoring is achieved by employing a large variety of sensors in the environment or any other physical conditions. loT has a massive amount of physical devices and data, which provides all the needed input for the digital twin. Data collected by these loT sensors are used to create digital models for simulating equipment, a system, and even the surroundings. Such digital twin models can show punctual and individual problems, as well as utilize those data to precisely predict the probability of any issues that could happen in near future. During this process, the models need to be generated automatically and take into consideration all the possibilities in different conditions and for different purposes.

One use case of loT-related industrial applications is to emulate the surroundings and/or the system itself for verification of the physical assets and check for anomalies before any deployment changes affect the existing physical assets in the loT platform.

Digital Twin based on loT

Digital Twin indicates a process of mapping physical entities to a digital representation by involving loT to enable continuous communication between physical and digital twins.

Besides the physical twins and digital twins, a part of the DT is data collected from the physical entities. The data provides the ability to describe the physical entity as realistically as required by the use case using the DT model built as its digital representation. This is where the communication between physical and digital twins comes into focus, as well as the role of loT that can enrich and automatize that data collection and additionally improve decision-making for the operation of physical entities. Using these interconnections, the identified elements of physical entities can be addressable and stored to enable immediate usage or historical usage of received information (the historical data is used in some future simulations).

Digital Twin relies on an loT platform to manage the operations by sharing and reusing resources (data, devices, models, etc.) across different use cases. loT based DT (as shown in FIG. 1) is created on top of loT, which at the same time provides intelligent capabilities (such as emulation) for various industrial applications, so that the resources (hardware resources, data resources, etc.) can be efficiently managed/reused/shared across various use cases. This further implies:

• The models (e.g., emulator and models for other functionalities) are reusable to serve various industrial applications and should be easy to adapt for various use cases; and

• The model management is conducted by DT operations, including both the processes, running loops, and components.

The models are based on knowledge representation, which can support reasoning (e.g., to answer “what-if’).

• Models for DT should be reusable and flexible as much as so that the operation and creation of the framework can have minimal dependency on human expertise.

Device Checking

Device verification and anomaly checking are one of the use cases served by running the models providing certain functionalities, namely an emulator.

Device verification and anomaly checking before the physical assets are hard-settled play roles in the domains such as automotive, smart manufacturing, as well as in the communication networks serving them (e.g., radio access network). That is because once the changes on hardware deployment are settled it can be highly costly to adjust the existing deployment. For example, frequently turning the system offline for error correction brings negative effects on customers’ experiences.

In the many industrial applications, such as networking, automotive, and manufacturing, a powerful emulator helps in better management of the vehicles by enabling verification and anomaly checking, so that security risks can be avoided before real-life driving tests. Similarly, in the smart manufacturing domain large, data gathered by industrial loT equipment can be consumed by an emulator for predictive maintenance of the production line so that anomaly checking and verification can happen in a very early stage, so it can lower the downtime and increase production quality after deployment of physical assets are done.

Use case RAN: In Radio Access Networks (RAN), hybrid historical data and live data collected from physical assets can be used to emulate specific KPI’s that reflect the behavior and performance of the network. Using the emulator, device verification and anomaly detection help in identifying potential problems under different conditions which can affect latency, throughput, and cause packet loss.

Use case smart manufacturing: in manufacturing lines, detecting anomalies in the early phase and having risk control on hardware changes may be important. Learning the patterns and emulating the pattern for early anomaly detection can minimize the loss caused by hardware mistakes. Moreover, learning and discovering potential risks of hardware changes may be important, which support operators to understand the possible consequences of each change in detail to avoid bad decisions on hardware change.

Thus, in all these domains, there are needs for emulation tools to generate models in a dynamic way for the verification of physical assets and detect potential anomalies in various conditions.

Interpretable (white-box) emulator without Domain Expertise

Different from many other systems, loT-based device platforms generate data by capturing environment status via devices together with the status data of hardware of the platform. Some of the captured parameters together makes a strong impact on the output, while some parameters are not impacting the outcome or having weak impacts on the results. Moreover, some parameters may mutually impact each other, while some are independent. In many industrial applications, the models are not only supposed to answer “what”, but also need to answer “how” and “why”. Therefore, it may be important to make the relations between different parameters interpretable in some use cases, especially for debugging purpose.

Therefore, being interpretable is one of the functionalities/ features for the DT emulator machine to have, which can be applied to some use cases. When the DT emulator generates datasets for emulating the physical systems, this should be based on clear topology (with identified relations between parameters and outputs).

The emulator machine should not rely on domain expertise for interpretability so that it is reusable for various industrial applications, while the domain expertise can be still taken as an optional input.

Known methods for generating digital twin models from loT for emulation show common features:

(1) different digital twin modeling applies based on different domain knowledge to solve a diversity of needs only relating to the specific asset (such as the production line of certain products), which are under the challenge of condition changes;

(2) different digital twin modeling solutions are proprietary for specific use cases, which are created based on the proprietary knowledge previously gain from the specific scenario and use cases; and

(3) the knowledge used to model the digital solutions is usually pre-existing and relies on the knowledge of domain experts.

Unlike other approaches, conducting emulation (based on which one can do device verification and anomaly checking) using heterogeneous loT devices/modules online, the emulators should fulfill the following features:

• Device verification and anomaly checking must be conducted online without physical impact on the existing physical assets;

• Prior domain knowledge (training labels, useful data models) regarding collected data is sparse due to various combinations of devices and changes in processes (limited domain expertise); therefore the solution should have minimized dependency on prior domain expertise’

• The solution should be replicable and reusable for different use cases, which means the whole solution (including the algorithms and other components) should be applicable to different use cases (with different data set, different requirements) without introducing significant changes;

• Data processing algorithms should be diverse enough so that the majority of potential conditions and environment assumptions that have not happened before can be included in the model;

• Interpretability is needed so that the emulator can generate data for emulating the physical systems in a “white-box” manner, knowing “how” and “why”, which may be important for some industrial applications; and/or

• The model should be light-weighted for edge devices and reduce computation costs (e.g., energy and time).

There are no known solutions that cover all the requirements stated above. Particularly, there are no known solutions that include structure learning for interpretable digital twin emulator which serves various industrial applications. That causes clear limitations. Some problems (limitations) of existing solutions may be summarized as follows:

(1) The created models are highly domain-specific: one solution for one case; hard to be reused;

(2) Models need manual interferences to be adapted using domain knowledge;

(3) Limited conditions and situations are included;

(4) They are either black-box models without requirements on domain expertise or white-box models with requirements on domain expertise; and/or

(5) They may not work sufficiently in the situation that not much data is collected for training.

In US 20210141870 Al, automatic creation of 3D digital twin models of some mechanical parts that can be imported into a simulation platform and be simulated are provided to create an exact model of the real thing, while different variations of the model states may be automatically created and simulated. The focus is on a 3D model that can be used in a simulator, but it cannot provide “what if’ scenarios for that model. In US 20210138651 Al, there is a direct connection between the robot program and a simulation platform so that the simulation can be performed on a 3D model with the real robot logic to simulate the exact behavior. A limitation is the inability to simulate “what if’ scenarios that are similar but not the same as the historical situations. Rather, the proposal only emulates the behavior of real things in the current situation.

In US 20190266295 Al, a digital twin based solution for preventive maintenance of vehicles by simulating the future trips and predicting car component failures during those trips, as well as suggesting car mechanic stops along the way. The proposed solution utilizes historical data for simulation. A limitation of the proposed solution is that it utilizes historical journeys as is, without expanding the parametrization space, and thus not accounting for different but very similar scenarios. The proposal uses expert models for simulating component failures.

In US 20210397945 Al, a technique includes inputting a training dataset into a variational autoencoder (VAE) comprising an encoder network, a prior network, and a decoder network. The technique also includes training the VAE by updating one or more parameters of the VAE based on one or more outputs produced by the VAE from the training dataset. The technique further includes producing generative output that reflects a first distribution of the training dataset by applying the decoder network to one or more values sampled from the second distribution of latent variables generated by the prior network.

However, these existing system as note with issues as describe above.

SUMMARY

An object of the invention is to enable improved device verification and anomaly detection.

Some embodiments advantageously provide methods, systems and devices for an interpretable digital twin (DT) emulator machine for device verification and anomaly checking.

— interpretable, white-box, high-dimensional time series

In some embodiments, a selective and interpretable DT emulator (also referred to as emulator or emulator device) is provided that uses Dynamic Bayesian Networks (DBNs) with integration with concrete autoencoder for device verification and anomaly detection based in loT. The emulator may be built upon loT-based Digital Twin setup using a Feature-selective Interpreter for High-dimensional Time Series (FIHT) by inheriting features from CAE, and Dynamic Bayesian Networks. In some embodiments, the emulator may be continuously trained based on the collected device (e.g., loT device) data in high-dimensional with localized concrete (CONtinuous relaxations of disCRETE random variables) feature selections on the edge, which then conducts a global process to continuously train a graphical structure in form of Directed Acyclic Graphs (DAGs). This may be performed using Dynamic Bayesian Networks, that describes the input data set with variations (collected from the physical devices) by identifying relations between different parameters. The mechanism of such emulator may be to first conduct localized feature selection (e.g., on edge devices), and then find out an optimized DAG which describes the collected device data with Gaussian variations. Both a graphical structure and data sets generated from the graphical structure are provided following the same pattern/structure as the input data by intaking the contributive features to emulate input samples with no or only limited domain expertise and no human intervention.

- online, minimum dependency on domain expertise, replicability

In some embodiments, a method in a DT emulator includes continuously taking data from physical devices (e..g, loT devices) with feature selection and without disturbing the running physical sets. It trains a graphical model whose structure describes the relations between the intaken parameters and then generates sets of data that may be different from the original ones but obeys the same patterns with the inputs based on contributive features. Such a feature-selective and interpretable method are driven by data that does not require domain knowledge; therefore, it may be highly replicable under different conditions (physical environments, heterogeneous devices, etc.)

Some embodiments include an emulator which uses FIHT as the core algorithm to reproduce data highly similar to the data generated by the physical entities. Some embodiments use machine learning techniques for the DT emulator, which has one or more of the following advantages: 1. The emulation may be variational, therefore it may be diverse in that the majority of potential conditions and environment assumptions that have not happened before can be included in the model.

2. The selective and interpretable model FIHT may be applied to the emulator. The FIHT may be a “white-box” learning model which inherits the core functionality of CAE and Dynamic Bayesian Networks. Compared to other “black-box” model which only answers “what” this model answers “how” and “why” as well.

3. Works well in the data-sparse situation. The emulator does not require a massive amount of data to work effectively.

4. Creating emulations from the data flow in an online manner using batch-based algorithms, where the batch-based algorithms are usually conducted in an offline manner. The online manner provides faster results than the offline manner, and the batch-based algorithms enable to handle advanced analysis.

5. Some embodiments emulate data sets from high-dimensional time-series data flows using sliding windows concrete autoencoder; concrete autoencoder plays the functionality to condense the high-dimensional data using feature selection;

6. Some embodiments do not require pre-existing domain expertise to create models for the performance evaluation or to train/evaluate the models which are performed autonomously from the data flow.

7. Some embodiments are reusable and replicable for different scenarios due to the fact of flexible, scalable, and does not require pre-existing domain expertise.

8. Some embodiments conduct feature selection (CAE) on the edge (e.g., edge of the network/environment) side before feeding data into the variational generation learning process, which hence removes irrelevant and redundant information for training the emulator.

9. Some embodiments are light-weight to fit the devices on the edge to process high-dimensional data close to the data resources. According to one aspect of the present disclosure, a digital twin emulator is provided. The digital twin emulator is configured to communicate with a plurality of internet-of-things, loT, devices. The digital twin emulator includes processing circuitry. The processing circuitry is configured to: receive data from the plurality of loT device, where the received data is associated with a plurality of parameters; select a subset of received data corresponding to a subset of the plurality of parameters; generate time series data based on the selected subset of received data; generate a graphical model based on the time series data and Gaussian noise, where the graphical model defines relations between the subset of the plurality of parameters; generate emulated data different from the received subset of received data based on the graphical model, where the emulated data has a same structuralized schema as the received subset of received data; and perform at least one action based on the emulated data.

According to one or more embodiments of this aspect, the selection of the subset of received data is performed in a parameter dimension by a concrete autoencoder, CAE.

According to one or more embodiments of this aspect, the selection of the subset of received data is configured to reduce irrelevant and redundant parameters included in the subset of received data.

According to one or more embodiments of this aspect, the received data corresponds to at least one of sensor data and actuator data associated with a first scenario occurring in an environment; and the emulated data is associated with a plurality of emulated scenarios in the environment different from the first scenario.

According to one or more embodiments of this aspect, the Gaussian noise is configured to generate variations in the subset of received data.

According to one or more embodiments of this aspect, the generation of the graphical model includes: generating at least one node structure for the subset of the received data based on a dynamic Bayesian network, where each node of the at least one node structure is associated with at least one value of the subset of received data; determining a plurality of root nodes in the at least one node structure; modifying the respective values of the plurality root nodes by adding Gaussian noise to the respective values; inputting the modified values of the plurality of root nodes into the node structure to form a directed acyclic graph, DAG, model, where the emulated data is the output of the DAG model.

According to one or more embodiments of this aspect, the plurality of parameters includes at least one of: temperature; distance between loT devices; power level; speed; position; wireless connectivity; and lack of sensor data communication.

According to one or more embodiments of this aspect, the plurality of loT devices includes at least one of: a sensor; and an actuator.

According to one or more embodiments of this aspect, the at least one action includes: performing analysis of the emulated data; modifying at least one of a configuration and state of one of the plurality of loT devices based on the analysis of the emulated data.

According to one or more embodiments of this aspect, the analysis of emulated data includes at least one of anomaly detection and data verification.

According to another aspect of the present disclosure, a method performed on a digital twin emulator configured to communicate with a plurality of internet-of- things, loT, devices, is provided. The method includes: receiving data from the plurality of loT device, where the received data is associated with a plurality of parameters; selecting a subset of received data corresponding to a subset of the plurality of parameters; generating time series data based on the selected subset of received data; generating a graphical model based on the time series data and Gaussian noise, where the graphical model defines relations between the subset of the plurality of parameters; generating emulated data different from the received subset of received data based on the graphical model, where the emulated data has a same structuralized schema as the received subset of received data; and performing at least one action based on the emulated data.

According to one or more embodiments of this aspect, the selection of the subset of received data is configured to reduce irrelevant and redundant parameters included in the subset of received data. According to one or more embodiments of this aspect, the received data corresponds to at least one of sensor data and actuator data associated with a first scenario occurring in an environment; and the emulated data is associated with a plurality of emulated scenarios in the environment different from the first scenario.

According to another aspect of the present disclosure, a non-transitory computer readable storage medium having a computer program stored thereon is provided. The computer program, when executed by a processor of a digital twin emulator configured to communicate with a plurality of internet-of-things, loT, devices, causes the digital twin emulator to: receive data from the plurality of loT device, where the received data is associated with a plurality of parameters; select a subset of received data corresponding to a subset of the plurality of parameters; generate time series data based on the selected subset of received data; generate a graphical model based on the time series data and Gaussian noise, where the graphical model defines relations between the subset of the plurality of parameters; generate emulated data different from the received subset of received data based on the graphical model, where the emulated data has a same structuralized schema as the received subset of received data; and perform at least one action based on the emulated data.

Advantages of various embodiments described herein include the ability to provide “what if’ scenarios for a model, ability to simulate “what if’ scenarios that are similar but not the same as a historical situation, and the ability to use historical journeys with an expanded parametrization space to account for different but very similar scenarios.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

FIG. l is a block diagram of an emulator in an loT based DT platform;

FIG. 2 is a block diagram of according to some embodiments of the present disclosure;

FIG. 3 is a flowchart of an example process in DT emulator according to some embodiments of the present disclosure;

FIG. 4 is a flowchart of an example process in DT emulator according to some embodiments of the present disclosure;

FIG. 5 is a general view of an example of how emulators may be applied within an loT based DT platform according to the principles in the present disclosure;

FIG. 6 is a full view of an FIHT model according to the principles in the present disclosure;

FIG. 7 is a component view of selection features of an FIHT according to the principles in the present disclosure; FIG. 8 is a component view of a graphical model-based generator of the FIHT according to the principles in the present disclosure;

FIG. 9 is an illustration of example steps using an DT emulator according to the principles in the present disclosure;

FIG. 10 is an illustration of an example DT emulator according to the principles in the present disclosure;

FIG. 11 is an illustration of another example DT emulator according to the principles in the present disclosure according to the principles in the present disclosure;

FIG. 12 is a flowchart of another example process of an DT emulator according to the principles in the present disclosure;

FIG. 13 is an illustration of an orchestration of an DT emulator according to the principles in the present disclosure; and

FIG. 14 is a schematic diagram of an example communication system according to the principles in the present disclosure.

DETAILED DESCRIPTION

Before describing in detail example embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to an interpretable digital twin (DT) emulator machine for device verification and anomaly checking. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Like numbers refer to like elements throughout the description.

As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and/or wireless connections.

Note further, that functions described herein as being performed by a DT emulator may be distributed over a one or more physical and/or logical elements described herein. In other words, it is contemplated that the functions of the DT emulator described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

In some embodiments, the general description elements in the form of “one of A and B” corresponds to A or B. In some embodiments, at least one of A and B corresponds to A, B or AB, or to one or more of A and B. In some embodiments, at least one of A, B and C corresponds to one or more of A, B and C, and/or A, B, C or a combination thereof.

In some embodiments described herein, the term “loT” device can refer to: temperature sensor, humidity sensor, vibration sensor, PH sensor, oxygen level sensor, etc. Those devices generate and send the measure content to a digital twin.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Some embodiments provide an interpretable digital twin (DT) emulator (e.g., DT emulator machine) for device verification and anomaly checking.

Example implementations, in accordance with an embodiment, of the internet of things (loT) device 22 and DT emulator 6 are described with reference to FIG. 2.

The system 10 includes DT emulator 6 including hardware 28. The hardware 28 may include communication interface 30 configured to communicate with one or more elements in system 10 such as with one or more loT devices 22. loT device 22 may be a device for use in one or more application domains, these domains comprising, but not limited to, home, city, wearable technology, extended reality, industrial application, and healthcare.

By way of example, the loT device 22 for a home, an office, a building or an infrastructure may be a baking scale, a coffee machine, a grill, a fridge, a refrigerator, a freezer, a microwave oven, an oven, a toaster, a water tap, a water heater, a water geyser, a sauna, a vacuum cleaner, a washer, a dryer, a dishwasher, a door, a window, a curtain, a blind, a furniture, a light bulb, a fan, an air-conditioner, a cooler, an air purifier, a humidifier, a speaker, a television, a laptop, a personal computer, a gaming console, a remote control, a vent, an iron, a steamer, a pressure cooker, a stove, an electric stove, a hair dryer, a hair styler, a mirror, a printer, a scanner, a photocopier, a projector, a hologram projector, a 3D printer, a drill, a hand-dryer, an alarm clock, a clock, a security camera, a smoke alarm, a fire alarm, a connected doorbell, an electronic door lock, a lawnmower, a thermostat, a plug, an irrigation control device, a flood sensor, a moisture sensor, a motion detector, a weather station, an electricity meter, a water meter, and a gas meter.

By further ways of example, the loT device 22 for use in a city, urban, or rural areas may be connected street lighting, a connected traffic light, a traffic camera, a connected road sign, an air control/monitor, a noise level detector, a transport congestion monitoring device, a transport controlling device, an automated toll payment device, a parking payment device, a sensor for monitoring parking usage, a traffic management device, a digital kiosk, a bin, an air quality monitoring sensor, a bridge condition monitoring sensor, a fire hydrant, a manhole sensor, a tarmac sensor, a water fountain sensor, a connected closed circuit television, a scooter, a hoverboard, a ticketing machine, a ticket barrier, a metro rail, a metro station device, a passenger information panel, an onboard camera, and other connected device on a public transport vehicle.

As further way of example, the communication loT device 22 may be a wearable device, or a device related to extended reality, wherein the device related to extended reality may be a device related to augmented reality, virtual reality, merged reality, or mixed reality. Examples of such loT devices may be a smart-band, a tracker, a haptic glove, a haptic suit, a smartwatch, clothes, eyeglasses, a head mounted display, an ear pod, an activity monitor, a fitness monitor, a heart rate monitor, a ring, a key tracker, a blood glucose meter, and a pressure meter.

As further ways of example, the loT device 22 may be an industrial application device wherein an industrial application device may be an industrial unmanned aerial vehicle, an intelligent industrial robot, a vehicle assembly robot, and an automated guided vehicle.

As further ways of example, the loT device 22 may be a transportation vehicle, wherein a transportation vehicle may be a bicycle, a motor bike, a scooter, a moped, an auto rickshaw, a rail transport, a train, a tram, a bus, a car, a truck, an airplane, a boat, a ship, a ski board, a snowboard, a snow mobile, a hoverboard, a skateboard, roller-skates, a vehicle for freight transportation, a drone, a robot, a stratospheric aircraft, an aircraft, a helicopter and a hovercraft.

As further ways of example, the loT device 22 may be a health or fitness device, wherein a health or fitness device may be a surgical robot, an implantable medical device, a non-invasive medical device, and a stationary medical device which may be: an in-vitro diagnostic device, a radiology device, a diagnostic imaging device, and an x-ray device.

In the embodiment shown, the hardware 28 of emulator 6 further includes processing circuitry 36. The processing circuitry 36 may include a processor 38 and a memory 40. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 36 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 38 may be configured to access (e.g., write to and/or read from) the memory 40, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the DT emulator further has software 42 stored internally in, for example, memory 40, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by DT emulator 6 via an external connection. The software 42 may be executable by the processing circuitry 36. The processing circuitry 36 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by DT emulator 6. Processor 38 corresponds to one or more processors 38 for performing DT emulator 6 functions described herein. The memory 40 is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 42 may include instructions that, when executed by the processor 38 and/or processing circuitry 36, causes the processor 38 and/or processing circuitry 36 to perform the processes described herein with respect to DT emulator 6. For example, processing circuitry 36 of the DT emulator 6 may include a DT emulator unit 24 which is configured to perform one or more DT emulator 6 functions as described herein such as to, for example, emulate a digital twin, DT, platform using a feature-selective interpreter for high-dimensional time series, FIHT, based at least in part on at least one of a concrete autoencoder, CAE, and a dynamic Bayesian network. In some embodiments, the DT emulator unit 24 implements the DT emulators 6.

The system 10 further includes the loT device 22 already referred to. The loT device 22 may have hardware 44 that may include a communication interface 46 the is configured to communicate with one or more elements in system 10 such as with loT device 22, DT emulator 6, etc. loT device 22 may include one or more sensors 47 for generating data (e.g., sensor data) that may be communicated to DT emulator 6 via communication interface 46. The hardware 44 of the loT device 22 further includes processing circuitry 50. The processing circuitry 50 may include a processor 52 and memory 54. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 50 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 52 may be configured to access (e.g., write to and/or read from) memory 54, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the loT device 14 may further comprise software 56, which is stored in, for example, memory 54 at the loT device 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the loT device 14. The software 56 may be executable by the processing circuitry 50.

The processing circuitry 50 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by loT device 22. The processor 52 corresponds to one or more processors 52 for performing loT device 22 functions described herein. The loT device 22 includes memory 54 that is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 56 and/or the client application 58 may include instructions that, when executed by the processor 52 and/or processing circuitry 50, causes the processor 52 and/or processing circuitry 50 to perform the processes described herein with respect to loT device 22.

In some embodiments, the inner workings of the DT emulator 6 and loT device 22 may be as shown in FIG. 2 and independently, the surrounding network topology.

Although FIG. 2 shows a DT emulator unit 24 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry. That is, in one or more embodiments, DT emulator 6 functions may be distributed across one or more physical and/or logical deices.

FIG. 3 is a flowchart of an example process implemented in DT emulator 6 for device verification and anomaly checking. One or more blocks described herein may be performed by one or more elements of DT emulator 6 such as by one or more of processing circuitry 36 (including the DT emulator unit 24), processor 38, and/or communication interface 30. DT emulator 6 is configured to emulate a digital twin, DT, platform using a feature-selective interpreter for high-dimensional time series, FH4T, based at least in part on at least one of a concrete autoencoder, CAE, and a dynamic Bayesian network (Block SI 00).

In some embodiments, the emulating includes conducting localized feature selections. In some embodiments, the dynamic Bayesian network describes an input data set by identifying relationships between different parameters of the input data set. In some embodiments, the emulating includes finding an optimized directed acyclic graph, DAG, that describes the input data set. In some embodiments, the DAG are configured to have a structure corresponding to the input data set.

FIG. 4 is a flowchart of an example process implemented in DT emulator 6 configured to communicate with a plurality of internet-of-things, loT, devices. One or more blocks described herein may be performed by one or more elements of DT emulator 6 such as by one or more of processing circuitry 36 (including the DT emulator unit 24), processor 38, and/or communication interface 30. DT emulator 6 includes processing circuitry 36, which is configured to receive data from the plurality of loT device. The processing circuitry 36 is configured to the received data being associated with a plurality of parameters (Block S102). The processing circuitry 36 is configured to select a subset of received data corresponding to a subset of the plurality of parameters (Block S104). The processing circuitry 36 is configured to generate time series data based on the selected subset of received data (Block SI 06). The processing circuitry 36 is configured to generate a graphical model based on the time series data and Gaussian noise, the graphical model defining relations between the subset of the plurality of parameters (Block S108). The processing circuitry 36 is configured to generate emulated data different from the received subset of received data based on the graphical model, the emulated data having a same structuralized schema as the received subset of received data (Block SI 10). The processing circuitry 36 is configured to perform at least one action based on the emulated data (Block S112).

In at least one embodiment, the selection of the subset of received data is performed in a parameter dimension by a concrete autoencoder, CAE.

In at least one embodiment, the selection of the subset of received data is configured to reduce irrelevant and redundant parameters included in the subset of received data.

In at least one embodiment, the received data corresponds to at least one of sensor data and actuator data associated with a first scenario occurring in an environment; and the emulated data is associated with a plurality of emulated scenarios in the environment different from the first scenario.

In at least one embodiment, the Gaussian noise is configured to generate variations in the subset of received data.

In at least one embodiment, the generation of the graphical model includes: generating at least one node structure for the subset of the received data based on a dynamic Bayesian network, where each node of the at least one node structure is associated with at least one value of the subset of received data; determining a plurality of root nodes in the at least one node structure; modifying the respective values of the plurality root nodes by adding Gaussian noise to the respective values; inputting the modified values of the plurality of root nodes into the node structure to form a directed acyclic graph, DAG, model, where the emulated data is the output of the DAG model.

In at least one embodiment, the plurality of parameters includes at least one of: temperature; distance between loT devices; power level; speed; position; wireless connectivity; and lack of sensor data communication.

In at least one embodiment, the plurality of loT devices includes at least one of: a sensor; and an actuator.

In at least one embodiment, the at least one action includes: performing analysis of the emulated data; modifying at least one of a configuration and state of one of the plurality of loT devices based on the analysis of the emulated data. In at least one embodiment, the analysis of emulated data includes at least one of anomaly detection and data verification.

Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for DT emulator based device verification and anomaly checking.

By way of a non-limiting example of data according to at least some of the embodiments described herein, data may include telemetry data (i.e., measuring content) corresponding to measurement readings (e.g., 37 C for temperature, 17% for humidity, 3% for oxygen) of the environment. The measurement may reflect the use of different units (e.g., C for temperature, % for oxygen and humidity). However, one or more embodiments described herien are not limited by a particular type of telemetry data, and probabilistic features of the data frame composed by those data may be more relevant. As a non-limiting example, for n samples collected from temperature sensor, this data set can be marked as vector X0. Likewise, p different sensors (regardless of whether they share the same device type), can be marked as matrix Z = [XO,X1 Xp], Z is the dataframe. For each X in Z, it is a parameter. Further, “actuator data” is similar, however the receiver is an actuator.

Some embodiments provide DT emulator based device verification and anomaly checking. One or more functions described below may be performed by one or more elements of DT emulator 6 such as by one or more of processing circuitry 36 (including the DT emulator unit 24), processor 38, and/or communication interface 30.

System overview

There is shown in FIG. 5 a block diagram illustrating an loT device platform 2 in communication with a digital twin (DT) platform 4 which includes DT emulators 6.

A DT emulator 6 may be configured to work by interacting with other components of the digital twin platform 4. The digital twin platform 4 may use two concurrent emulators 6 (e.g., 6a, 6b); one emulates the behaviors of physical entities and another emulates the decisions to make in responding to the current status of the physical entities. In one or more DT emulators may be collectively referred to as DT emulator 6. Physical entity may correspond to an loT device that includes and/or is associated with one or more sensors and/or one or more actuators.

The system as illustrated in FIG. 5 includes different models, where each model is supported by relevant components. At least one embodiment may use, for example, the emulator described in FIG. 1.

Basic units include:

• One or many devices (e.g., loT devices 22) where each device includes: o A processing unit (e.g., processing circuitry 50) to process the sensor data and send out the result via a communication unit (e.g., communication interface 46)

■ Optionally, the loT devices 22 could only run some parts of the method described below, due to the presented method includes computations in a distributed manner; o A communication unit (e.g., communication interface 46) to send the sensor data provided by the sensor unit (e.g., sensor 47):

■ Optionally, the loT devices 22 could send the output from certain processing composition unit (e.g., processing circuitry 36); o sensors and a certain sensor unit (e.g., collectively sensor 47) to collect information from the physical environment. For example, regular environment sensors (e.g., temperature, humidity, air pollution, acoustic, sound, vibration), sensors for navigation (e.g., altimeters, gyroscopes, internal navigators, magnetic compasses), optical items (e.g., light sensor, thermographic cameras, photodetectors), and many other sensor types;

• One or more computing units (DT emulator 6), such as devices (could be one or many), gateways, various types of apparatus, and/or computing cloud, which may include: o A processing unit (e.g., processing circuitry 36) with storage/memory: ■ to implement either the whole method at once or to only implement specific steps of the method;

■ to interact with the communication units;

■ to temporarily store the data; o One or more communication units (e.g., communication interface 30):

■ to collect data from heterogeneous radio nodes and devices (e.g., loT devices 22) via different protocols;

■ to exchange information between intelligence processor units;

■ to expose the data and/or insights to other external systems or other internal modules.

The devices and computing units are combined to include sub-components of the DT emulator 6, including the Emulator itself and other external supportive components.

The DT emulators are running with support from some external components:

• Device platform (loT) 2 includes physical entities with their sensors 47 and actuators. Former represent devices providing data in proprietary format about a physical entity, e.g., temperature sensor, while latter represent devices enforcing instructions in the proper format to a physical entity, e.g., on/off switch. The loT device platform 2 may include multiple loT devices 22.

Devices are located on-premises and are implemented as hardware devices in a regular loT environment (e.g., a temperature sensor and of/off switch), or as a piece of software that runs on physical entities (e.g., Java code that collects CPU usage on a Raspberry Pi and can restart it).

• The data model in the device platform represents the raw data collected from devices in a formalized and structuralized schema so that behavior and decision models with their relevant emulators can use the device data smoothly. The data model may include or be implemented by one or more computing units (e.g., processing circuitry 36, DT emulator unit 24). • Knowledge representations (semantic models) may be used to represent logic and knowledge for a certain use case, which ensures the emulator can be based on logical reasoning and then answers questions such as “what-if’. The knowledge representations may be implemented by one or more computing units (e.g., processing circuitry 36, DT emulator unit 24).

• Data models are run by data pre-processing components, which conduct pre-data processing to convert raw data into structured data which can be consumed by the emulator. The data models may include or be implemented by one or more devices and one or more computing units (e.g., processing circuitry 36, DT emulator unit 24). o Such preprocessing first intakes raw data and then forms a data model. The data model receives data in a standardized or proprietary format from sensors and outputs uniformly structured data, e.g., JSON format. Data model commonly runs on-premises as well, and requires a communication channel that is physically near sensors and actuators in order to communicate with them (e.g., Zigbee, Z- Wave and WiFi modules). For software sensors and actuators, it can run further on Cloud, while being connected through the Internet with network-enabled physical devices. o After that, it generates knowledge representations from the data model. The semantic model receives uniformly formatted data from the data model and provides a context for it, using schema such as RDF, OWL, NGSLLD, etc..

• Digital Twin models 7a and 7b includes a behavior model emulator and a decision model emulator. For time-critical use cases, the behavior and decision models can run on the edge, to make the round-trip time to be short; otherwise, they can also run on the Cloud. The DT models 7a and 7B are based on a digital twin platform 4. On the southbound interface, the digital twin platform 4 connects to the loT device platform 2, which may be used to obtain and store both contextual and semantical data, respectively, as well as forwarding actions to actuators. On the northbound interface of the digital twin platform, user sends its user-specific ontology/semantics, along with desired intentions on how the system should behave. o The behavior model 7a takes contextually enhanced observations and gives back semantically enhanced insights, e.g., it takes multiple temperature readings from a robot arm and informs that a robot arm is overheating. This way, outcomes of certain actions observed as insights can thus be extrapolated, simulated, and in general planned for future goals. The behavior model emulator 7a may be implemented by one or more computing units (e.g., processing circuitry 36, DT emulator unit 24) o Those actions are executed by the decision model (emulator) 7b based on semantically enhanced insights, as well as “intents” from a user, e.g., due to a robot overheating and a user intent to keep a safe environment it decides to switch off the robot arm. The action may be sent through a semantic model that knows what actuator needs to be switched off. The decision model 7b may be implemented by one or more computing units.

Emulated data may include a set of data that follows the same probabilistic features as another, non-emulated (i.e., “original”) dataset, but that has different value from the original dataset. Both the emulated and non-emulated datasets have same number of parameters. For example Y= [Yl,Y2,Y3...Yn] where Y is sampled from population P (infinite set). For data set X, exists all element x in X has:

This makes F(x) belong to P. Thus, X is an emulation set for Y. As population P is infinite, this results in a potential infinite number of X. To emulate X may refer to sampling data from a probabilistic distribution that X obeys.

Sample data from a certain population may include variances (i.e., variations), (e.g., in a sample of five apples from ten thousand apples, the five apples are all apples, but there may be variance in terms of one or more of size, shape, color, etc.).

From the procedural perspective, previously described components may implement at least one of three feedback loops, namely:

Procedure 1 — Learning Loop: The DT emulator 6 (e.g., models 7a, 7b) take data input from the device platform to train the emulator. It retrieves observations and insights from the device platform to get conclusions regarding what is happening and then decides to take “Actions” to optimize the system. During this process, the DT emulator 6 also takes business logic as input from the users, the business logic describes reaction/decision policies using “if’ and “then” schema.

Procedure 2 — Emulating Loop: based on the learned model (in step 1) the DT emulator 6 generate data for emulation. It creates emulated “Insights” within the “Behavior Model” 7a and sends to “Decision Model” 7b to take decisions of actions. After that, the decisions are sent as emulated “Actions” to the “Behavior model” 7a to emulate their outcome in form of newly created simulated Insights. Those simulated Insights are used for selecting “Actions” to be executed.

Procedure 3 — Updating Loop: The DT emulator 6 (e.g., models 7a, 7b) are updated by comparing the result of actions to the given “Intent” to optimize the emulators. It utilizes recorded “performance” (e.g., error rates, etc.) in both the “Leaning loop” and “Emulating loop” to update the “Behavior Model Emulator” and “Decision Model Emulator”.

The DT emulator 6 may include an emulator model and a set of computing units running the emulator model. The DT emulator 6 may be running together with other external components, namely other components in the digital twin platform. However, the DT emulator 6 itself does not have specific requirements on the DT components, and just sending data to the emulator may be enough.

The Sliding windows

The input of the DT Emulator 6 are exposed to this step to be accumulated; Each sliding window accumulates data frames for a certain amount of time, or for a certain amount of samples.

The computational tasks progress as the sliding windows move while working on data accumulated during the sliding windows. For example, the DT emulator 6 handles data generated within 2 hours, where 2 hours is the size of the sliding window. Consequently, the data feed into each training step may be a time-series data accumulated within 2 hours. After handing data in the current sliding window, the sliding window may move to take data generated in another 2 hours after the current one. Such data accumulation lays the basis for concentrating information in the time dimension.

The Model of Emulator:

The emulator model contains two parts, namely the feature-selector-based Dynamic Bayesian Network generator in form of a Directed Acyclic Graph. The feature selector may be preferred to reside on the edge-side (close to the data source) while the DBN generator may be preferred to reside on the cloud or central units which can collectively intake all the output of distributed feature selectors. FIG. 6 shows the full view of the emulator model, which runs upon several computing units and devices. FIG. 6 is not limited to a ML graph aseach unit inside the graph may be a processing circuitry and/or a computational unit, which can be realized using software and hardware as described herein.

• FIHT may be conducting feature selections on the data generated by physical twins so that the emulation may primarily be based on contributive/impactive parameters. Moreover, when irrelevant and redundant data are avoided to some extent, it both saves computation resources (such as energy) and light-weighs the computation burden on edge devices.

• FIHT may be a variational graphical modeling based generator. It inherits the Dynamic Bayesian Network typology so that data sets generated based on the trained DAG have the same structure and pattern as the data set to be emulated can be then generated; • FIHT may be designed to process time-series data with sliding windows. It handles the continuously generated data from the physical twins. This feature may be important for the digital twin emulator 6, as the timely relations between different batches of data sets should be reflected during the training in some embodiments.

The DT emulator 6 takes datasets with any of the following features as input:

• Both online and historical high-dimensional time series data, which have no obviously detected relations between each dimension of the data sets. Those data can be the ones generated by both the physical and digital entities in the digital twin framework.

• Both online and historical high-dimensional time-series data, which have detected relations between each dimension of the data sets. Those data can be the ones generated by both the physical and digital entities in the digital twin framework.

The high-dimensional data frame:

• The data collected from physical devices can be in a highdimensional situation, namely a feature may have several sub-features under it. For example, the feature “temperature” can be collected from several temperature sensors deployed in the same room or within highly close distance ranges that even though the data series are different the meaning they carry may be highly similar. The feature selector just filters out some of the redundant sub-features. All the features (including sub-features) in the time series are organized in a “feature selected data frame” as shown in FIG. 6. The DT emulator 6 may deliver datasets as output by demands with the following features:

• A Graphical model with Gaussian variations that makes the mechanism interpretable based on contributive/impactive information (parameters);

• Generates data sets by sampling from the Graphical model to demanded amounts, while each portion of the generated data set may never be the same in actual value; and/or • The generated data contains variational information learned from contributive/impactive information so that potential/undetectable design faults and anomalies can be detected when the demanded amounts of data are large enough.

(1) The Feature selection units of the model

In DT emulator 6, processing on the input data may be performed in two dimensions, namely the feature dimensions and the time dimension. As explained in the section “the high-dimensional data frame”, the feature selectors are a set of components to select contributive/impactive features from raw datasets, which hence can decrease the dimension of features by avoiding duplicated or irrelevant features. For example, the sub-set of features belonging to certain features can be filtered to avoid the redundant ones or irrelevant ones as shown in FIG. 7 (taking feature X as an example). Concrete autoencoder (CAE) may be the algorithm used for feature selections. In the CAE units, data are processed in the feature dimension. The feature selection units aim to inherit architecture from the CAE which aims to avoid feeding redundant and irrelevant parameters to the variational generator. These units take input from sliding windows. Different from other autoencoders, the CAE introduces feature selection layers, where Concrete random variables can be sampled to produce continuous relaxation of the one-hot vectors. CAE selects discrete features using an embedded method but without regularizations. It uses a relaxation of the discrete random variables over the Concrete distribution, which enables a low-variance estimate of the gradient through discrete stochastic nodes. As the output of these units, the feature-selected data may be fed to the time series generator. Good to mention both the input and output of these units fulfill time series structures. This may be useful to implement Minimum L2 loss in the CAE training, which may be to force the decoded CAE series highly close to the input time series.

This part of computations can be conducted on the edge if needed with the composition of various computing units and devices. The loss introduced in this part can be also used as regulations for the variational time series generation in a global sense. The graphical structure of the model for generating emulated data

The FIHT always resolves a probabilistic distribution that may be infinitely approaching to the objective data sets which are multivariable time series data after conducting feature selections on the high-dimensional data collected from DT physical devices. In the case of Digital Twin, such data are the ones generated by physical twin counterparts. It may be a unique neural network typology that inherits functionalities from Dynamic Bayesian Networks. The graph generator of FIHT (as shown in FIG. 8) works in such way:

(1) Input data may be the output of feature selectors which includes several time-series impactive/contributive features (e.g., temperature, humidity, etc.), which may be used for building a structure model namely an acyclic graph that represents causal relationships between data sources (e.g., temperature affects humidity). (Step 1 A).

(2) Once the structure is built, root nodes are identified, i.e., the nodes which do not depend on other data sources. (Step 2A).

(3) The root nodes are fed with modified telemetry data. The modification may be done by including variations in the original telemetry data using Gaussian noise (GN). GN represents a signal noise that has a probability density function equal to that of the normal distribution, i.e., it creates different but similar values to the original telemetry data. (Step 3 A).

(4) Those modified values are fed to the structure model in form of DAG. (Step 4 A).

(5) The structure model outputs emulated values for the rest of the nodes, which reflect the causal dependence with the root nodes. Obtained output is the emulated data of the original data sources, i.e., they represent ‘what if scenarios that are similar to the currently observed situation in the real world. (Step 5 A).

The time-series units of the DT emulator 6

In DT emulator 6, the time series are handled using Recurrent neural networks (RNN) which are based on GRU, which is to keep the structure of time series with consistent connections. LSTM units can fit the structure as if needed. The time series RNN may be applied on the output of CAE-Decode, as shown in FIG. 7 and FIG. 8. In the time-series units, data are processed in the time dimension comparing to the CAE structure processing data in parameter dimensions. The RNN in CAE-Decoder may be also impacted by the size of sliding windows. For example, the deployed sensor transmits data in every 10 milliseconds; based on the descriptions of sliding windows above, the sliding windows will accumulate 1000 data items if the time length for the sliding window may be defined as 10 seconds. Such time series units support the neural network to conduct training on the input data with continuations on different time slots; moreover, the output of a unit X^₊₂ can be used as input for another sliding window so that all the sliding windows are chained. The RNN in CAE-decoder enhances a time series structure during training which may be enforced to have minimum L2 loss compared to the original time series. In this RNN layer, the outputs from the RNN Neuron are delivered to the feature selector using a time sequence structure.

The Steps to use the DT Emulator 6

As presented above, some methods (including a set of different steps) provide a unique integration of some known technologies and evolving technologies. A method can be implemented at one or more computing units (e.g., processing circuitry 36, DT emulator unit 24, etc.), which may include one or more of the steps as shown in FIG. 9. At least one embodiment according to the present disclosure can be implemented and/or deployed as part of a distributed system.

Step 0: In order to trigger the feature reduction and build the models, a specific size of the time window should be defined, using which to accumulate the data. This step groups mini-batches to data. The size of the windows may be specific depending on the use case and may be configurable according to different requirements. Each sliding window outputs a data frame in temporal order with a certain defined interval. It could be accumulated on memory or persistent storage depending on the requirements.

Step 1 : This step includes the collection of available data from all the devices (e.g., loT devices 22). It integrates all the heterogeneous devices (e.g., loT devices 22) which usually have one or multiple different communication protocols. It collects the data generated by physical twins and feeds the data into the DT emulator 6. Once enough amount of data is accumulated according to the size of the sliding window, step 2 may be triggered; keep this step ongoing/continuing unless the DT emulator 6 needs to be shut down;

Step 2: continuously train the DT emulator 6 (e.g., model(s) 7a and/or 7b) for feature selection on the edge (e.g., physical and/or logical edge of the network, environment, etc.) (if the edge is needed); keep this step ongoing unless the DT emulator 6 needs to be shut down;

Step 3 : continuously feed feature-selected data to the non-edge part of the emulator and then handles any backpropagation from the non-edge part; keep this step ongoing unless the emulator needs to be shut down;

Step 4: continuously train the interpretable learner for generating time series and do backpropagation with the edge part; keep this step ongoing unless the DT emulator 6 needs to be shut down; and/or

Step 5: provide demands (the amount of data) to the DT emulator 6, then the emulating data may be delivered. The amount of demanded data may not be larger than the total amount of training data fed into the emulator since the emulator starts, in some embodiments.

Theory support of the FH4T model:

Moreover, the following lists some theoretical supports for the proposed FIHT:

• For edge devices GRU is a better choice comparing to long short term memory (LSTM), especially relating to the context of the disclosed loT-based digital Twin;

• CAE has approved good performance on feature selections that output authentic parameters rather than the reconstructed ones. It has been applied in natural sciences which needs to explain “how” and “why” together with “what”.

• A dynamic Bayesian network is an effective structure learning tool that can be used for learning causal relationships between input features and generating interpretable DAGs.

• Gaussian Noise is a lightweight tool for device-related emulations. Expose the emulation data

This process may be implemented and based on external storage. In this step, the emulator 6 (e.g., models 7a and/or 7b) may expose data to other components which allow some embodiments to be integrated into an loT-based Digital twin Platform 4. For example, the analyzed results can be exposed to the simulation and automation loops. So that, besides the supports for simulation analysis, the solution can also be used for predictions.

Moreover, by integrating with the process component, the DT emulator 6 can conduct performance/results evaluations for assumed conditions based on the data collected from physical twins, so that the DT platform 4 can provide feedback of the decisions to be tested to the users.

Implementation Scenario

Conducting emulation for predictive maintenance in Smart manufacturing may be one of the typical use cases, where devices/equipment are geographically distributed.

In manufacturing, it may be important to emulate the production line and automatically determine out any impact of possible changes. However, the domain expert cannot always provide enough knowledge supports by understanding the data, especially when the production line is newly introduced or assembled. In mordent plants, the categories of deployed equipment/sensor devices can be very complex (high-dimensional data); the speed of generating data can be very quick (data streams come in high-density); the equipment/sensor devices are serving different production units in different geographical locations (heterogeneity of devices and distributed topology); the production can be scale up and down for serving different environments; the data should be ingested in fresh and provide online results quickly. To address such a situation, a DT-based emulator machine (e.g., DT emulator 6) may be needed.

In some cases, embodiments disclosed herein may be used to provide online emulation of the physical deployment of the online data with architecture as shown in FIG. 10. That is, FIG. 10 depicts an example embodiment of how different units can be deployed with interactions between the units — however, other implementations are possible. Each component may respond to a computing unit in the provided solution, which can be distributed or reside on one. In one or more embodiments, DT emulator 6 provides one or more DT processing units functions.

DT communication unit 0 (also referred to as DT communication unit 60): This unit works as a data receiver, which takes data from physical entities (e.g., loT devices 22).

DT processing unit 1 (also referred to as DT processing unit 62): This unit works as a data parser, which transforms different raw data into a data frame.

DT processing unit (2 to n) (also referred to as DT processing unit 64): The total number of generator units may be equivalent to the size of sliding windows. Each unit may be equivalent to a multi-variable input X in the time period t. Each of the units handles the CAE computations to generate data. It interacts with the timeseries units for backpropagation during the training and inferencing.

DT processing unit (n+1 to 2n) (also referred to as DT processing unit 66): The total number of generator units may be equivalent to the size of sliding windows. Each unit may be equivalent to a multi-variable input X in the time period t. Each of the units handles data from physical entities generated in a certain period of time. It interacts with the CAE-DE units and CIPL units for backpropagation during the training and inferencing.

DT processing unit (2n+l) (also referred to as DT processing unit 68): This unit works only for Interpretable Graphical Learner (IGL) which first takes input from the outcome of a generated time-series data frame from the GRU layer, and then trains a graphical model to describe the pattern.

DT processing unit (2n+2) (also referred to as DT processing unit 70): This unit works as a data exposer, which transmits the results to relevant components and/or end-users.

Use Cases and Examples

The digital twin platform 4 disclosed herein may be considered enablers for various industrial applications, providing reusability (for various use cases and industrial applications).

Adding to the detailed descriptions above, the following features may be included in some embodiments: • 1 : DT emulator 6 take device data from any loT environment (e.g., loT devices 22) as an input, i.e., various time-series sensor data; the DT emulator provides diverse and variational data as an output, i.e., data that looks like the input sensor data.

• 2: The DT emulator 6 generate outputs by first training a FIHT model to learn the pattern of input data and then generating a graphical model from the trained model where variations are added. The trained pattern may be presented in a graphical model so that the connections/ relations between different features are visible and interpretable.

• 3 : Device data flows into the DT emulator 6 as a live stream, while the DT emulator 6 take the sliding windows to process the incoming data. The content of each sliding window may be fed into the FIHT and the DT emulator 6 runs continuously and takes input from the sliding windows continuously.

• 3 : the FIHT may provide both feature selection functionality to avoid irrelevant/redundant data and provides a mechanism that the interpretable graphical model generates data for emulations.

Here are the online device verification and anomaly detection that may be implemented for some use cases.

• Online Device verification:

In many use-cases, complex hardware may be deployed and needs to be upgraded/changed based on different requirements. To avoid the situation, that the running hardware systems have to be stopped for testing the results (which may cost quite some time to test all the possibilities), the DT emulator 6 enables engineers to do online device verifications. The DT emulator 6 may be used to learn a pattern from all the collected hardware data, and then generate data emulating the hardware systems (with possible environment conditions) with variations. So that the emulation data sets enable tests on the hardware systems without shutting down anything. Once data is emulated, it can be used for verifying the physical device state, not only by observing its current state but by observing all possible states that might occur. Moreover, by applying an interpretable emulator one can find a root cause of the potential problem.

• Sustainable Smart urban:

Assume there is a smart urban area with different deployed sensors (temperature sensors) and actuators (heater with several power levels). The DT emulator 6 learn a pattern that when the heater is turned on the temperature of houses in the district can logarithmically go up depending on the power level. Consequently, DT emulator 6 can go through different conditions and verify states. If the desired temperature is set to 35 degrees and DT emulators 6 did not find any set of conditions that would achieve that temperature, they can alarm the user that the desired temperature is unreachable. Moreover, when any changes to the heating system are needed, the data output by the DT emulators 6 can be used to test the change proposal before making any physical impact on the existing physical entities.

• Smart Manufacturing:

Assume there is a robotic arm and a conveyor belt on a factory floor, as well as camera detecting items on a conveyor belt being placed by the robotic arm. DT emulator 6 can take camera outputs, robotic arm axes, and the conveyor belt speed and learn their correlation and continuously update them as new data arrives. By creating variations of those conditions, it can check if any device can reach an undesirable state during its operation. For instance, it can determine out that the minimum speed of the conveyor belt would cause the robotic arm to place items one on top of the other if the robotic arm itself were to be set to its maximum speed. In case any changes are needed for the running physical setup, the data generated by the DT emulator 6 can be used to verify the proposed changes before any impacts are made on the physical system. Moreover, by having an interpretable structure model of the factory floor one can detect the root cause of the potential problem, i.e., the speed of the specific robotic arm and the conveyor belt. Mobile Network:

Assume there are 200 LTE base stations (e.g., network node) covering an area, all being digitally twinned. Input data includes base station load and a number of mobile devices connected to it. DT emulator 6 begin to emulate mobile device (e.g., wireless device or UE) positions and connections and finds a condition where one base station fails due to overload. Mobile devices that were connected to that base station switch to other base stations, which also gets overloaded as it now has to handle new connections along with the existing ones, making it fail as well. This can create a chain reaction that knocks off all 200 base stations. In this way, the DT emulator 6 are capable of verifying the setup/configuration of the entire LTE network in the area, as well as provide the exact root cause (i.e., a specific LTE base station) of the potential problem. Such verification may be particularly helpful when any changes need to be done on the hardware setup because the running hardware system does not need to be stopped to test potential consequences of the planned changes.

• Anomaly detection:

The emulator generates data emulating the hardware system, which can be also used to detect anomalies in the existing hardware system because the DT emulator 6 are also aware of various environment's acceptable states because of the variations in emulated data.

• Sustainable Smart urban:

Assume that the temperature starts going up while the heater is turned off. This could happen in a case of fire in the room for instance. This data can be used as an input to the learning unit of the DT emulator 6 along with other data representing various acceptable situations. That being performed, the DT emulator 6 would be able to identify the fire situation as an anomaly amongst other conditions. Moreover, using the emulating data with variations, it is possible to test whether the current hardware setup can work as the expected way under different (with variations) circumstances/assumptions (can the system respond to anomalies correctly under different circumstances/assumptions).

• Smart Manufacturing:

Assume that the conveyor belt stops operating due to malfunction, while the robotic arm continues its operation. DT emulator 6 would be able to detect this as an anomaly as these conditions would not resemble any other previously emulated working conditions. Moreover, using the emulating data with variations, it is possible to test whether the current hardware setup can work as the expected way under different (with variations) circumstances/assumptions (can the system respond to anomalies correctly under different circumstances/assumptions). Finally, having a interpretable causal relationship structure one could identify the source of this anomaly.

• Mobile Network:

Assume that one base station stops sending sensor data due to an internal error, while continuing to operate, i.e., while mobile devices are still connected to it. DT would be able to emulate these conditions and realize that if the base station has actually failed some of the neighboring base stations would receive new connections, while they didn’t. Hence, by observing the causal relationship between input data, one would be able to detect these conditions as the anomaly. Moreover, using the emulating data with variations, it is possible to test whether the current hardware setup can work as the expected way under different (with variations) circumstances/assumptions (can the system respond to anomalies correctly under different circumstances/assumptions).

A DT emulator 6 may include one or more processing units 76a, 76b and two communication units 72, 74 as described herein where the functionality of DT emulator 6 may be distributed or performed by one or more physical and/or logical entities. The processing units 76a, 76b and communication units 72, 74 are in communication with a data bus 78. Data exchanges between units, such as the processing units 76a, 76b, and communication unit 74 occur within the DT emulator 6 in the data bus, as shown (a) in the FIG. 11. Data exchange happens between any external components and the DT emulators 6 are conducted between the communication units 72, 74, as shown (b) in FIG. 11. One or more communication brokers 76 may also be in communication with the data bus 78.

FIG. 12 is a flowchart of an example process in DT emulator 6. One or more blocks described herein may be performed by one or more elements of DT emulator 6 such as by one or more of processing circuitry 36 (including the DT emulator unit 24), processor 38, and/or communication interface 30. The processing circuitry is configured to collect data generated by the physical entities (Block SI 14). The processing circuitry is configured to transform and formalize the data to feed in the streams (Block SI 16). The processing circuitry is configured to accumulate data to create a sliding window (Block SI 18). The processing circuitry is configured to perform data concentration in feature selection units (Edge) (Block S120). The processing circuitry is configured to perform time-series computation in GRU Units (CAE-DE) (Block S122). The processing circuitry is configured to continuously train in graphical model units (Global) with Gaussian variations (Block S124). Blocks S120 through S124 may be part of an iterative loop. The processing circuitry is configured to generate emulation data from graphical model units (Block S126). The processing circuitry is configured to expose to other DT components or end users (Block S128).

In at least one embodiment, the GRU unit performing a generating step may refer to the GRU unit ensuring the output of previous units can stay in a time series structure where the impact from previous time units and the current one are reflected.

Some of the units in the DT emulator 6 could be implemented in a different location in a distributed way, as shown in FIG. 13. Therefore, instead of relating to cloud implementation only, the whole loT landscape that includes devices, edge gateways, base stations, network infrastructure, fog nodes, or cloud may be implemented. The FS Units 80, Time-series Units 66, and IGL units 82 could be implemented in the cloud which can be benefited by the computation power of the cloud. Other units, such as data receiver, exposer, and data parser can be located in the edge, depending on the needs of the scenario. In some embodiments, the loT platform 2 and the DT platform 4 may be implemented in, or as part of, a wireless communication system providing wireless connectivity to a plurality of wireless devices which, in the context of the loT, may typically be machine-type devices, as illustrated in FIG. 14.

There is shown in FIG. 14 a schematic diagram of a communication system

11, according to an embodiment, such as a 3 GPP -type cellular network that may support standards such as LTE and/or NR (5G), which comprises an access network

12, such as a radio access network, and a core network 14. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 14 over a wired or wireless connection 20. A first wireless device (WD) 23a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second WD 23b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of WDs 23a, 23b (collectively referred to as wireless devices 23) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole WD is in the coverage area or where a sole WD is connecting to the corresponding network node 16. Note that although only two WDs 23 and three network nodes 16 are shown for convenience, the communication system may include many more WDs 23 and network nodes 16. Network node 16 may include DT emulator unit 24 for performing one or more DT emulator 6 functions where WD 23 may perform functions described herein such as those performed by loT device 22.

Also, it is contemplated that a WD 23 can be in simultaneous communication and/or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a WD 23 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, WD 23 can be in communication with an eNB for LTE/E-UTRAN and a gNB for NR/NG-RAN.

In particular, A network node 16 (eNB or gNB) is configured to include a DT emulator unit 24 which is configured to emulate a digital twin, DT, platform using a feature-selective interpreter for high-dimensional time series, FIHT, based at least in part on at least one of a concrete autoencoder, CAE, and a dynamic Bayesian network. In some embodiments, the DT emulator unit 24 implements the DT emulator 6 (including, for example, model 7a, 7b).

The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multi-standard radio (MSR) radio node such as MSR BS, multi-cell/multicast coordination entity (MCE), integrated access and backhaul (IAB) node, relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a wireless device (WD) such as a wireless device (WD) or a radio network node.

In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The WD herein can be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as wireless device (WD). The WD may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and/or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device, etc.

Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and/or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

Thus, some embodiments include a digital twin based platform 4 having DT emulator 6 using a machine learning model (i.e., FIHT ) to conduct feature selection and generate high-dimensional time-series data sets which can emulate the input high-dimensional time series data sets with Gaussian variations. The DT emulator 6 have minimum dependency on domain expertise, which is hence highly replicable and reusable for various industrial applications; the DT emulator 6 conduct feature selections on the edge side, so the parameters taken into the generation process are all contributive/impactive parameters.

The DT emulator 6 use a model by inheriting and integrating one or more advantages and core features of CAE, GRU, and Dynamic Bayesian network, with clear synergy effects. This provides an emulator gain that a single parent model cannot provide.

• Some embodiments include learning and generating data in a mechanism interpretable way. After training, each data generation is a process of sampling data from the learned graph where all the relations between different features are described. Each generated set is different (with Gaussian Variations) but obeys (infinitely approaching to) the graph pattern learn from input data. Therefore, it is diverse that the majority of potential conditions and environment assumptions that have not happened before can be included in the model.

• Feature selections are introduced on the edge side of physical system, so that the emulation machine can in some extent to avoid irrelevant and redundant data. • Some embodiments apply a model which hesitates and integrates one or more advantages from CAE, Dynamic Bayesian Network, and GRU respectively with clear synergy effects, which can learn a probabilistic pattern based on feature selection for expressing highdimensional time series based on the data sets collected from physical entities.

• Some embodiments apply online batch-based machine learning: continuously applying batch-based machine learning algorithms on time series to generate data sets for simulating the data collected from the physical entities, which can concentrate information in both KPI dimension using feature selection and concentrate the time dimension using VAE.

• Some embodiments do not require domain expertise for providing data labels for either training the model or creating the model; the solution is automated without human intervention.

• Some embodiments are reusable and replicable: since the solution may be semi-supervised reinforcement learning without the requirement on either training labels or domain expertise, some embodiments are replicable and reusable in different industrial applications.

• Compared to many other digital twin emulators, a “whitebox” method is provided that trains graphical models where the relations between different features are described and therefore visible and can answer not only “what” but “how” and “why” as well.

Some Examples:

Example Al . A DT emulator 6 configured to communicate with an loT device 22, the DT emulator 6 configured to, and/or comprising a communication interface 30 and/or comprising processing circuitry 36 configured to: emulate a digital twin, DT, platform 4 using a feature-selective interpreter for high-dimensional time series, FH4T, based at least in part on at least one of a concrete autoencoder, CAE, and a dynamic Bayesian network.

Example A2. The DT emulator 6 of Example Al, wherein the emulating includes conducting localized feature selections. Example A3. The DT emulator 6 of any of Examples Al and A2, wherein the dynamic Bayesian network describes an input data set by identifying relationships between different parameters of the input data set.

Example A4. The DT emulator 6 of any of Examples A2 and A3, wherein the emulating includes finding an optimized directed acyclic graph, DAG, that describes the input data set.

Example A5. The DT emulator 6 of Example A4, wherein the DAG are configured to have a structure corresponding to the input data set.

Example Bl. A method implemented in a DT emulator, the method comprising: emulating a digital twin, DT, platform 4 using a feature-selective interpreter for high-dimensional time series, FH4T, based at least in part on at least one of a concrete autoencoder, CAE, and a dynamic Bayesian network.

Example B2. The method of Example Bl, wherein the emulating includes conducting localized feature selections.

Example B3. The method of any of Examples Bl and B2, wherein the dynamic Bayesian network describes an input data set by identifying relationships between different parameters of the input data set.

Example B4. The method of any of Examples B2 and B3, wherein the emulating includes finding an optimized directed acyclic graph, DAG, that describes the input data set.

Example B5. The method of Example B4, wherein the DAG are configured to have a structure corresponding to the input data set.

As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and/or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and/or functionality described herein may be performed by, and/or associated to, a corresponding module, which may be implemented in software and/or firmware and/or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

Some embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

It is to be understood that the functions/acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and/or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

Abbreviations that may be used in the preceding description include:

CAE concrete autoencoder;

DT digital twin;

DAG Directed acyclic graphs

GRU gated recurrent unit; loT internet of things;

IGL Interpretable Graphical Learner;

FS Feature Selector;

FIHT Feature-selective Interpreter for High-dimensional Time Series It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings without departing from the scope of the following claims.

Claims

CLAIMS What is claimed is:

1. A digital twin emulator (6) configured to communicate with a plurality of internet-of-things, loT, devices (22), the digital twin emulator (6) comprising: processing circuitry (36) configured to: receive data from the plurality of loT devices (22), the received data being associated with a plurality of parameters; select a subset of received data corresponding to a subset of the plurality of parameters; generate time series data based on the selected subset of received data; generate a graphical model based on the time series data and Gaussian noise, the graphical model defining relations between the subset of the plurality of parameters; generate emulated data different from the received subset of received data based on the graphical model, the emulated data having a same structuralized schema as the received subset of received data; and perform at least one action based on the emulated data.

2. The digital twin emulator (6) of Claim 1, wherein the selection of the subset of received data is performed in a parameter dimension by a concrete autoencoder, CAE.

3. The digital twin emulator (6) of any one of Claims 1-2, wherein the selection of the subset of received data is configured to reduce irrelevant and redundant parameters included in the subset of received data.

4. The digital twin emulator (6) of any one of Claims 1-4, wherein the received data corresponds to at least one of sensor data and actuator data associated with a first scenario occurring in an environment; and the emulated data being associated with a plurality of emulated scenarios in the environment different from the first scenario.

5. The digital twin emulator (6) of any one of Claims 1-3, wherein the Gaussian noise is configured to generate variations in the subset of received data.

6. The digital twin emulator (6) of any one of Claims 1-4, wherein the generation of the graphical model includes: generating at least one node structure for the subset of the received data based on a dynamic Bayesian network, each node of the at least one node structure being associated with at least one value of the subset of received data; determining a plurality of root nodes in the at least one node structure; modifying the respective values of the plurality root nodes by adding Gaussian noise to the respective values; inputting the modified values of the plurality of root nodes into the node structure to form a directed acyclic graph, DAG, model; and the emulated data being the output of the DAG model.

7. The digital twin emulator (6) of any one of Claims 1-6, wherein the plurality of parameters includes at least one of: temperature; distance between loT devices; power level; speed; position; wireless connectivity; and lack of sensor data communication.

8. The digital twin emulator (6) of any one of Claims 1-7, wherein the plurality of loT devices includes at least one of: a sensor; and an actuator.

9. The digital twin emulator (6) of any one of Claims 1-8, wherein the at least one action includes: performing analysis of the emulated data; modifying at least one of a configuration and state of one of the plurality of loT devices based on the analysis of the emulated data.

10. The digital twin emulator (6) of any one of Claims 1-9, wherein the analysis of emulated data includes at least one of anomaly detection and data verification.

11. A method performed on a digital twin emulator (6) configured to communicate with a plurality of internet-of-things, loT, devices (22), method comprising: receiving (Block SI 02) data from the plurality of loT devices (22), the received data being associated with a plurality of parameters; selecting (Block SI 04) a subset of received data corresponding to a subset of the plurality of parameters; generating (Block SI 06) time series data based on the selected subset of received data; generating (Block SI 08) a graphical model based on the time series data and Gaussian noise, the graphical model defining relations between the subset of the plurality of parameters; generating (Block SI 10) emulated data different from the received subset of received data based on the graphical model, the emulated data having a same structuralized schema as the received subset of received data; and performing (Block SI 12) at least one action based on the emulated data.

12. The method of Claim 11, wherein the selection of the subset of received data is performed in a parameter dimension by a concrete autoencoder, CAE.

13. The method of any one of Claims 11-12, wherein the selection of the subset of received data is configured to reduce irrelevant and redundant parameters included in the subset of received data.

14. The method of any one of Claims 11-14, wherein the received data corresponds to at least one of sensor data and actuator data associated with a first scenario occurring in an environment; and the emulated data being associated with a plurality of emulated scenarios in the environment different from the first scenario.

15. The method of any one of Claims 11-13, wherein the Gaussian noise is configured to generate variations in the subset of received data.

16. The method of any one of Claims 11-14, wherein the generation of the graphical model includes: generating at least one node structure for the subset of the received data based on a dynamic Bayesian network, each node of the at least one node structure being associated with at least one value of the subset of received data; determining a plurality of root nodes in the at least one node structure; modifying the respective values of the plurality root nodes by adding Gaussian noise to the respective values; inputting the modified values of the plurality of root nodes into the node structure to form a directed acyclic graph, DAG, model; and the emulated data being the output of the DAG model.

17. The method of any one of Claims 11-16, wherein the plurality of parameters includes at least one of: temperature; distance between loT devices; power level; speed; position; wireless connectivity; and lack of sensor data communication.

18. The method of any one of Claims 11-17, wherein the plurality of loT devices includes at least one of: a sensor; and an actuator.

19. The method of any one of Claims 11-18, wherein the at least one action includes: performing analysis of the emulated data; modifying at least one of a configuration and state of one of the plurality of loT devices based on the analysis of the emulated data.

20. The method of any one of Claims 11-19, wherein the analysis of emulated data includes at least one of anomaly detection and data verification.

21. A non-transitory computer readable storage medium having a computer program stored thereon, the computer program which, when executed by a processor (38) of a digital twin emulator (6) configured to communicate with a plurality of internet-of-things, loT, devices (22), cause the digital twin emulator (6) to: receive data from the plurality of loT devices (22), the received data being associated with a plurality of parameters; select a subset of received data corresponding to a subset of the plurality of parameters; generate time series data based on the selected subset of received data; generate a graphical model based on the time series data and Gaussian noise, the graphical model defining relations between the subset of the plurality of parameters; generate emulated data different from the received subset of received data based on the graphical model, the emulated data having a same structuralized schema as the received subset of received data; and perform at least one action based on the emulated data.