Method for synchronizing a digital twin with a physical system, and associated electronic device

Abstract

Method for synchronizing a digital twin with a physical system, and associated electronic device. The invention relates to a method for synchronizing at least one first digital twin 310 with a physical system 100 comprising: a plurality of synchronizations of the first digital twin 310 with the physical system 100, implemented according to a variable synchronization frequency; in response to receiving a data retrieval request from the physical system 100 at a current time, a synchronization of at least a portion of the first digital twin with the physical system; and a reset of the synchronization frequency of at least a portion of the first digital twin to a value greater than a current value of said synchronization frequency. Figure for the abstract: Fig. 1.

Description

Title of the invention: Method for synchronizing a digital twin with a physical system, and associated electronic device technical field

[0001] The present invention falls within the general field of the Internet of Things. More particularly, it relates to a method for synchronizing a digital twin with a physical system. It also relates to a digital twin management device configured to implement such a method. Previous technique

[0002] A digital twin can be defined as a digital representation of a physical (or "real") system, which has the particularity of evolving according to the transformations of the system to which it is attached. The particularity of a digital twin is that it relies on a physical model that is continuously fed by data, for example, collected by sensors placed on, in, or near the system, or obtained from an inspection of this system at a certain time.

[0003] Thus, unlike a classic numerical model, a digital twin is generally configured to provide, in real time, information on the current state of operation of the physical system to which it is connected, but also to simulate a scenario or anticipate certain situations with regard to the past operation of this system.

[0004] Digital twins are a rapidly developing technology and are increasingly used for monitoring complex systems - such as cities, industrial complexes, buildings, offshore platforms, wind turbines, aircraft engines, etc. - since they allow the processing of large amounts of heterogeneous data, the identification of the root cause of problems and the improvement of the productivity of these complex systems.

[0005] However, a digital twin of a complex system can be composed of several thousand variables that reflect the dynamics of that complex system. In other words, at any given time, this digital twin represents thousands of variables whose values ​​can change to reflect an evolution of the complex system. Thus, the more complex the system becomes, the more difficult it becomes to obtain a digital twin that reflects all the changes in the system, and a fortiori, the more difficult it becomes to use the digital twin to predict the future performance or situations of the complex system.

[0006] Indeed, synchronizing these thousands of variables, using the synchronized data to make new predictions, and using these new predictions to make decisions are costly operations in terms of time, bandwidth, and storage and / or processing resources. Furthermore, failing to synchronize a digital twin with the physical system it represents can lead to inaccurate predictions, particularly in highly dynamic environments. Description of the invention

[0007] The present invention aims to remedy all or part of the disadvantages of the prior art, in particular those set out above, by proposing a solution which considers both the costs associated with the synchronization of a (potentially large) quantity of data and the processing of this data, while ensuring that the quality of the predictions provided by the digital twin is maintained.

[0008] To this end, and according to a first aspect, the invention relates to a method for synchronizing a digital twin representing at least a part of a physical system, the method being implemented by a digital twin management device and comprising:

[0009] - a plurality of synchronizations of the first digital twin with the system physical, implemented according to at least one variable synchronization frequency;

[0010] - in response to receiving a request to obtain data from the system physical at a current time, a synchronization of at least a part of the first digital twin with the physical system; and a reset of the synchronization frequency of at least a part of the first digital twin synchronized to a value, called the "reset value", greater than a current value of said synchronization frequency.

[0011] This method according to the invention is advantageous since it helps on the one hand to reduce the frequency of synchronizations - and therefore a fortiori to limit the amount of data exchanged between the physical system and its twin (e.g., the first twin), then processed by this twin - and on the other hand to increase the frequency of synchronizations of parts of the twin which are for example required by a user of the management device, and which are therefore of some interest to this user.

[0012] As mentioned previously, a digital twin is a dynamic, digital representation of a physical system. A digital twin relies on a physical model that is continuously updated with real-time data and offers a multitude of applications and benefits, including operational optimization, cost reduction, productivity improvement, and / or increased safety.

[0013] In certain implementations, this physical model is formalized as a graph whose nodes represent elements of the physical system, and whose arcs represent the semantic (e.g., topological, spatial) relationships between these elements. This model also includes properties associated with the physical model itself, the nodes, and / or the arcs.

[0014] By "physical system" is meant any object or element, set of objects or elements and / or environment composed of objects or elements. This includes, for example, a city, an industrial complex, a building, an offshore platform, a wind turbine, an aircraft engine, a part of the human body, etc.

[0015] It is important to note that all or part of this physical system is represented by this first digital twin. In other words, this physical system is represented at least partially by the first digital twin.

[0016] The retrieval request is, for example, issued by a user of the digital twin management device. Alternatively, this retrieval request is issued automatically by the digital twin management device, for example in response to the detection of an unusual event or in response to a certain prediction.

[0017] As mentioned previously, the synchronization of the first digital twin with the physical system in response to receiving the retrieval request may correspond to the synchronization of all or part of the digital twin. When this synchronization is only partial, it relates, for example:

[0018] - to the synchronization of a part of the first representative digital twin of a portion of the physical system. Thus, if the physical system corresponds to an automobile manufacturing plant, and if the retrieval request targets only a specific production line in that plant, only the portion of the twin representing that specific production line is synchronized; or,

[0019] - to the synchronization of one or more properties (or attributes) of the first twin numeric or the elements that compose it. Thus, if the retrieval request only concerns the values ​​of the "ambient temperature" property, only the values ​​of this property are then synchronized.

[0020] - or to a synchronization of one or more properties of a part of the twin digital, the latter case corresponding to the combination of the two previously mentioned cases. Thus, if the retrieval request only concerns the values ​​of the "ambient temperature" property of robots located within a specific production line, only these are synchronized.

[0021] In general, it is considered that the steps of a process should not be interpreted as being linked to a notion of temporal succession.

[0022] In certain embodiments, the synchronization method may further include one or more of the following characteristics, taken individually or in all technically possible combinations.

[0023] In certain embodiments, the plurality of synchronizations of the first digital twin with the physical system is implemented by progressively reducing an initial value of the synchronization frequency.

[0024] In some embodiments, the synchronization frequency is reset to a reset value distinct from the initial value. Alternatively, the reset value and the initial value correspond to the same and unique value.

[0025] In certain embodiments, the synchronization frequency is progressively reduced by applying a decay function.

[0026] In some embodiments, the first digital twin includes a prediction model, and the synchronization frequency is progressively reduced as a function of the effective accuracy of the prediction model.

[0027] In certain embodiments, the synchronization frequency is progressively reduced as the effective accuracy of the prediction model is adjusted.

[0028] By "adapted", we mean, for example, that this effective accuracy is greater than a threshold value. Thus, as long as the effective accuracy of the prediction model is greater than this threshold value to be reached, then the synchronization frequency is reduced.

[0029] In certain embodiments, where only a Psync portion of the first digital twin is synchronized in response to receiving the data retrieval request, the method further includes a reset of the synchronization frequency for the Psync portion (based on the reset frequency F) and the synchronization frequency of the digital twin, excluding the Psync portion, not being reset and continuing to vary as indicated above, based on the current value of the synchronization frequency.

[0030] In certain embodiments, the first digital twin includes a prediction model, and the method further comprises:

[0031] - a generation of a history of states of the physical system, each state of the history being associated with a time t and including values ​​of different dynamic variables of the physical system at said time t; and,

[0032] - training the prediction model using the state history as training data.

[0033] In certain embodiments, the synchronization process includes:

[0034] - upon receipt of a request to obtain data from the physical system relating to a moment prior to the current moment,

[0035] - a prediction, by the prediction model, of data associated with the instant previous based on at least one state in the history when the state history does not include a state associated with the previous time.

[0036] In certain embodiments, the synchronization method further includes recording the predicted data from the previous time in the state history of the physical system.

[0037] In certain embodiments, the method further includes a determination of said at least at least a part of the first digital twin to be synchronized with the physical system, according to the data retrieval request.

[0038] In certain embodiments, the synchronization method further includes storing, in the state history, the data resulting from the synchronization of at least a part of the first digital twin with the physical system in association with the current time.

[0039] In certain embodiments, the synchronization process further includes access, by a rendering module, to the data resulting from the synchronization of at least a part of the first digital twin with the physical system.

[0040] In certain embodiments, the synchronization process further includes filtering the data resulting from the synchronization of at least a part of the first digital twin with the physical system.

[0041] In some embodiments, the plurality of synchronizations is performed directly between the first digital twin and the physical system. Alternatively, the plurality of synchronizations is performed via a second digital twin representing at least partially the physical system.

[0042] As mentioned previously, the characteristics mentioned above can be considered in isolation or according to all technically possible combinations.

[0043] According to a second aspect, the invention relates to a digital twin management device configured to implement a synchronization method according to the invention in any of its implementation modes.

[0044] According to a third aspect, the invention relates to a computer program comprising instructions for implementing a synchronization method, in any of its implementation modes, when said program is executed by a processor.

[0045] This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code. object, such as in a partially compiled form, or in any other desirable form.

[0046] According to a fourth aspect, the invention relates to a computer-readable recording medium on which the computer program according to the invention is recorded in any of its embodiments.

[0047] The information or recording medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard disk drive.

[0048] On the other hand, the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be downloaded onto an Internet-type network.

[0049] Alternatively, the information or recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question. Brief description of the drawings

[0050] Other features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings, which illustrate an example of an embodiment without being limiting in any way. In the figures:

[0051] [Fig-1] [Fig. 1] is a representation of an example of an environment in which the invention is implemented;

[0052] [Fig.2] [Fig.2] represents modules embedded in a management device digital twins, according to an example of implementation of the invention;

[0053] [Fig.3] [Fig.3] schematically represents an example of the hardware architecture of a digital twin management device;

[0054] [Fig.4] [Fig.4] represents, in the form of a flowchart, certain modes of implementation implementing a synchronization process, for example executed by the digital twin management device in Figures 2 and 3; and,

[0055] [Fig.5] [Fig.5] is a representation of an example of an environment in which the invention is implemented. Description of the implementation methods

[0056] The terms "first(s)", "second(s)", etc., are used in this document by arbitrary convention to allow for the identification and distinction of different elements (such as messages, devices, digital twins, etc.) considered in the embodiments described below, and do not involve any particular sequencing, except where explicitly stated.

[0057] Fig. 1 is a representation of an example of environment 1000, in which the invention is implemented.

[0058] As illustrated in [Fig. 1], this environment 1000 comprises a physical system. In this example, this system corresponds to a vehicle manufacturing plant 100 and includes a production line (e.g., assembly line) 10. This production line comprises a set of specialized workstations consisting of industrial robots 20 arranged in a predetermined order corresponding to the sequence of operations for assembling the components of a vehicle. Each robot 20 is itself equipped with one or more sensors 30. These sensors correspond, for example, to:

[0059] - a 2D vision sensor, for example to enable the detection of objects in movement or searching for items on a conveyor belt. The robot can then adjust its movement appropriately, based on the information received;

[0060] - a 3D vision sensor;

[0061] - a positioning sensor, such as a global positioning system (or "Global Positioning System", GPS, according to Anglo-Saxon terminology);

[0062] - a gyroscopic sensor, for example to allow the robot to maintain a certain orientation;

[0063] - a sound sensor, for example configured to evaluate the amplitude of sounds in the robot's environment in relation to a threshold value;

[0064] - a proximity sensor configured to detect a nearby object without contact physical interaction with this object, so as to allow the robot to avoid a collision;

[0065] - a touch sensor (or "contact sensor");

[0066] - a force sensor, configured to evaluate a physical force (e.g., a weight, a tension, compression or pressure); and / or

[0067] - a temperature sensor.

[0068] The production line 10 and / or the factory 100 can also be equipped with 30 sensor(s), such as motion detection sensors, cameras, temperature sensors, smoke detection sensors, etc.

[0069] In this example, and for the sake of simplicity, the factory 100 is considered to comprise only one production line 10. It should be noted, however, that there are no limitations on the number of production lines, the number of robots comprising this or these production lines 10, and / or the types of sensors considered. The following developments can indeed be easily generalized by a person skilled in the art.

[0070] This vehicle manufacturing plant 100 is connected to a digital twin management device 300 via a telecommunications network 200. It should be noted that no assumption is made as to the nature of this network. It could be, for example, a local area network (e.g., "Local Area Network", LAN or "Wireless LAN", WLAN), a wide area network such as the Internet, a mobile telephone network (e.g., a fifth-generation (5G) or higher-generation (B5G, acronym for "Beyond fifth Generation") network), or a combination of these different types of networks.

[0071] This manufacturing plant 100 also includes a local network 40. No assumption is made as to the nature of this network.

[0072] A "digital twin management platform" is installed on this digital twin management device 300, which hosts one or more digital twins 310.

[0073] The detailed embodiments are subsequently described, by way of example, considering the presence of a single digital twin. It should be noted, however, that the number of digital twins does not constitute a limitation of the invention, and nothing precludes considering a number of digital twins greater than one, for example when several physical systems are considered and / or when several elements of the same physical system are represented by several digital twins.

[0074] This digital twin management platform, used for example in the organization or optimization of this vehicle manufacturing plant, is configured for example to:

[0075] - analyze, in real time, the data from sensors associated with one or more physical systems (for example, detecting an abnormal situation such as a defect in a part from images captured by 2D or 3D vision sensors);

[0076] - predict the behavior of the vehicle manufacturing plant 100 in its globality or one or more elements of this factory 100 (for example, predicting the behavior of a robot 20, and / or predicting the wear of a part in order to improve maintenance planning);

[0077] - simulate a pre-established scenario (for example, simulate a breakdown in this factory manufacturing 100 vehicles and its consequences, or simulating a new manufacturing process);

[0078] - to evaluate the causes of specific (unusual, for example) behavior of a or several elements of the vehicle manufacturing plant 100, or of plant 100 as a whole, for example from the analysis of a state history of the physical system; and / or

[0079] - to offer a user a synthetic representation of the manufacturing plant 100 of vehicles as a whole and / or of one or more elements of this factory 100.

[0080] To do this, a digital twin management platform hosts a digital twin attached to all or part of the physical system 100. In other words, the physical system 100 is represented at least partially by a digital twin.

[0081] The 300 digital twin management device can, for example, be associated with a database (local or remote) in which the data relating to the hosted digital twin are stored. This database is, for example, configured to store:

[0082] - a data model associated with the digital twin;

[0083] - data collected continuously by the sensors 30 equipping the factory 100 (and / or the elements that compose it) and received by the twin management device 300, this data being used to update the previously mentioned data model;

[0084] - metadata associated with the twin. This metadata includes, for example the creation date of this twin, the date of the last update, the expiry date, the owner or manager of this twin, a visibility and / or confidentiality indicator;

[0085] - and possibly, when the platform hosts several digital twins 310, representative data of the relationships between these digital twins.

[0086] Fig. 2 represents modules embedded in a 300 digital twin management device, according to an example of an implementation of the invention.

[0087] As illustrated in [Fig. 2], the 300 digital twin management device comprises:

[0088] - a MOD_REQ module for receiving a request to obtain data from physical system at a current instant tcuR;

[0089] - a M0D_SYN synchronization module configured to synchronize the twin digital 310 with physical system 100;

[0090] - a MOD_SCD scheduling module configured to adjust the frequency of synchronization of the digital twin 310 with the physical system 100. As discussed in more detail below, in some implementation modes, this MOD_SCD scheduling module is configured to gradually reduce a synchronization frequency of said digital twin 310 with said physical system 100, but also to reset the synchronization frequency to a reset value, in response to an instruction received from the MOD_REQ request reception module.

[0091] Their functionalities are described in more detail below with reference to different modes of implementation.

[0092] Fig. 3 schematically represents an example of the hardware architecture of a device 300 for managing digital twins 310.

[0093] As illustrated in [Fig. 3], the digital twin management device 300 has the hardware architecture of a computer. Thus, the digital twin management device 300 includes, in particular, a processor 1, random access memory 2, read-only memory 3 and non-volatile memory 4. It also has communication means 5.

[0094] The read-only memory 3 of the digital twin management device 300 constitutes a storage medium according to the invention, readable by the processor 1, on which a computer program PROG according to the invention is stored, comprising instructions for executing steps of the synchronization process according to the invention. The PROG program defines functional modules of the digital twin management device 300, which rely on or control the hardware elements 1 to 5 of the digital twin management device 300 mentioned above. These functional modules are illustrated in [Fig. 2] by way of no limitation, and are described in more detail below with reference to different implementation methods.

[0095] In the implementation modes described below, the communication means 5 enable the digital twin management device 300 to obtain data generated by sensors connected to the physical system 100. For this purpose, the communication means 5 include a communication interface, wired or wireless, capable of implementing any suitable communication protocol.

[0096] In certain embodiments, the digital twin management device 300 includes, and / or is further connected to, a human-machine interface (HMI) that provides a user with a synthetic representation of all or part of the physical system to be controlled. This HMI may also allow a user to request a prediction of the physical system's behavior; to run a simulation of a pre-established scenario; and / or to initiate an evaluation of the causes of a specific behavior of the physical system.

[0097] In some embodiments, the digital twin 310 includes a prediction model which is for example stored in non-volatile memory 4 of the digital twin management device 300.

[0098] Figure 4 represents, in the form of a flowchart, certain modes of implementation of a synchronization process, for example executed by the 300 device for managing digital twins of Figures 2 and 3.

[0099] As illustrated in Figure 4, the synchronization process includes a first step S100 of obtaining a state history $$J of the system physical 100. According to some implementation modes, the state history is generated by the digital twin management device 300 itself, and this step S100 of obtaining a state history then corresponds to a state history generation step H of the physical system 100. Alternatively, the history is generated by a device separate from the digital twin management device 300, and this step S100 of obtaining a state history corresponds to a reception of the state history H. Each state of the history H corresponds to a synchronization between the digital twin and all or part of the physical system, or to the result of a prediction of the state of all or part of the physical system at a time prior to the current time.

[0100] Each state of the history is notably composed of properties whose values ​​are dynamic and which reflect the evolution of the behavior and / or state of the physical system 100 over time. These values ​​are typically transmitted by various sensors installed in, on, or near the physical system, such as the sensors 30 previously mentioned with reference to [Fig. 1].

[0101] According to some embodiments, during synchronization, the entire physical system 100 is synchronized. Alternatively, only a part of the physical system 100 is synchronized.

[0102] According to some implementation modes, all properties are synchronized. Alternatively, only certain properties are synchronized. In other words, during the generation of this history H, the properties P? P^ and Pt, can be synchronized during the instant and the properties P\, Py P« and P$ during the instant ^2-

[0103] Each state can also be composed of metadata that characterizes this physical system or certain elements of this physical system. This metadata corresponds, for example, to a name, an identifier, a brand, a manufacturer, an address and / or a location.

[0104] Each state is recorded with a timestamp representing when the data was synchronized. Both the timestamp and the state data can be "serialized," that is, converted into a semi-structured format (such as JSON). The timestamp can be serialized, for example, using a Unix timestamp or following the ISO 8601 standard, while the state data can, for example, be serialized as one or more JSON values, following the RFC8259 standard. In this case, each state Sp S2, ..., St consists of one of the basic JSON value types: "object, array, number, string," or one of the values ​​"false, true, null."

[0105] In the following example, we consider the digital twin of a robot 20 with a gripper. The history H consists of two states S2 and the state is expressed as follows:

[0106] {

[0107] “id”: “90363aff-7eba-4b97-8al7-527907c939ca”,

[0108] “timestamp”: “2024-02-26T14:26:57.101Z”,

[0109] “temperature”: 24.0,

[0110] “force”: 45.2, [YES] “distance”: 0.8

[0112] }

[0113] or "force" corresponds to the force exerted by the gripper in Newtons, and "distance" to a distance from the nearest object to robot 20. State S2 is expressed as follows:

[0114] {

[0115] “id”: “90363aff-7eba-4b97-8al7-527907c939ca”,

[0116] “timestamp”: “2024-02-26T15:26:57.101Z”,

[0117] “temperature”: 24.8,

[0118] “force”: 47.9,

[0119] “distance”: 0.7

[0120] }

[0121] Of course, other structured or semi-structured formats can be considered for serializing these states, such as XML (acronym for "Extensible Markup Language") or CVS (acronym for "Comma-Separated Values").

[0122] The synchronization method further includes a step S200 of training a prediction model of the digital twin 310, using the history H of states obtained during the step S100.

[0123] In some implementation modes, this model is configured to predict missing data at a previous time tpASS at the current time tcuR- Alternatively or in addition, this model is configured for example to predict the behavior of the physical system 100 and / or to simulate a pre-established scenario.

[0124] In some implementation modes, the prediction model is, for example, implemented in the form of neural networks (convolution, perceptron, autoencoder, recurrent, etc.). According to some implementations, the neural networks considered are, for example, recurrent neural networks of the "long short-term memory" (LSTM) type.

[0125] Furthermore, it is important to note that there are no limitations attached to the type of training technique used to obtain this predictive model. Any technique implementing a learning algorithm (or "machine learning" in Anglo-Saxon terminology) and providing, as output, missing data from a previous time and / or a prediction according to the embodiment considered, Given a history of states H corresponding to input data, it can be considered in the context of the invention (e.g., support vector machine, logistic regression, etc.). In other words, the prediction model is independent of the training method considered to train this model.

[0126] Furthermore, the training criteria may vary depending on the implementation methods used during the training phase of this predictive model. For example, a training criterion such as the least squares method or cross-entropy minimization may be used.

[0127] This S200 training is optional in certain embodiments, for example when the process uses a model that has been previously trained or does not require training.

[0128] The synchronization process further includes an S300 step of synchronizing the digital twin with the physical system, during which all or part of the digital twin is synchronized with the physical system by adapting a variable synchronization frequency. This S300 step of synchronizing the digital twin with the physical system is, for example, implemented by the MOD_SYN module of the digital twin management device 300, in response to an instruction received from the MOD_SCD module of that device.

[0129] In certain embodiments, this synchronization is achieved by progressively reducing the synchronization frequency of said digital twin with said physical system.

[0130] The synchronization frequency value used when starting the process (the "initial" frequency / 0) is either predetermined (for example, predetermined by an administrator of the digital twin management platform, or configured according to user preferences and / or the intended application), or chosen dynamically, automatically or manually, when starting the process. Thus, in some implementations, if the digital twin is used to monitor, in real time, the production of an industrial system, an initial value / 0 of 2 to 8 Hz is possible.

[0131] According to at least some implementation modes of the S300 step of synchronizing the digital twin with the physical system, the synchronization frequency is progressively reduced. The variation can be automatic, for example by applying a decay function fDEC (or "decay function" in Anglo-Saxon terminology).

[0132] According to another implementation of the S300 step of synchronizing the digital twin with the physical system, the synchronization frequency can vary iteratively, depending on the result of a comparison between a precision effective of the prediction model and a first accuracy value (used as a threshold).

[0133] For example, at each synchronization (or alternatively after a constant number of synchronizations), the effective accuracy of the prediction model can be evaluated, for example, using the mean squared error (MSE) or the root mean squared error (RMSE). The effective accuracy is then compared to the first accuracy value (the "threshold"): if the effective accuracy is greater than this first accuracy value, then the applied synchronization frequency is reduced by a first value (such as 0.0015 Hz in the example above) or by a first percentage. Conversely, if the effective accuracy is less than the first accuracy value, then the applied synchronization frequency is increased by a second value (such as 0.002 Hz in the example above) or by a second percentage..

[0134] The synchronization process further includes an S400 step for receiving a request to obtain data representative of the state of the physical system at a time tREQ. This can be a past or future time, or the current time. This step is implemented, for example, by the MOD_REQ module of the 300 digital twin management device. In some implementations, this data request is issued by a user of the digital twin management device. Alternatively, this data request is issued automatically by the digital twin management device, for example, in response to the detection of an unusual event, in response to a certain prediction, and / or in response to a simulation of a pre-established scenario.

[0135] During an S500 step, the digital twin management device 300 compares the time îreq specified in the received request with the current time tcuR- More precisely, it determines whether the time ^req specified in the received request during the S400 step of receiving a data retrieval request corresponds to the current time tcVR, to a past time tpASS (earlier than the current time), or to a future time (later than the current time).

[0136] As discussed in more detail below, different steps are implemented depending on whether the time ^req specified in the query corresponds to the current time tcuR or not. If the time ^req corresponds to the current time tcuR (choice "^req = tcuR"), the steps referenced S610, S620, S630, S640 and S650 (described below) are implemented.

[0137] During step S610 of identifying at least one part of the twin to be synchronized, at least one part of the twin to be synchronized is identified based on the content of the request received during step S400.

[0138] According to some implementation modes, the entire digital twin is identified as needing to be synchronized.

[0139] According to other implementations, only a portion of the digital twin, for example identified in the query by an identifier ("ID"), a class, or an application domain, is identified as needing to be synchronized. Thus, if the query aims, for example, to obtain only the data relating to a specific production line in that plant, only the portion of the twin representing that specific production line is synchronized.

[0140] According to certain embodiments, a physical system is represented by several digital twins that can be linked together by semantic relations. Thus, with reference to the example illustrated by [Fig. 1], each industrial robot 20 is for example represented by a digital twin (called the "third twin"), the production line is itself represented by a digital twin (called the "fourth twin", the third twins being linked to the fourth twin by the topological relation "is a part of"), the local network 40 within this factory is represented by a digital twin (called the "fifth twin" linked to the third and fourth twins) and the manufacturing plant 100 is itself represented by a digital twin including the third, fourth, fifth digital twins.

[0141] In the example mentioned above, since the request only aims to obtain data relating to a specific production line in that factory, only the fourth digital twin representing that production line is synchronized. In contrast, the twin representing the local network 40 within the factory is not resynchronized.

[0142] According to another embodiment, only the properties of a digital twin or the elements that compose it are synchronized.

[0143] The method further includes a step S620 during which at least one part of the twin to be synchronized identified during the identification step S610 is synchronized with the physical system 100. This step is implemented for example by the MOD_SYN module of the digital twin management device 300.

[0144] The synchronization method further includes a step S630 of resetting the synchronization frequency to a reset value higher than the current synchronization frequency value. This reset value corresponds, for example—but not necessarily—to the initial value fQ mentioned earlier.

[0145] In other words, in implementation modes where the twin synchronization frequency has been gradually reduced during the various synchronizations of step S300, this synchronization frequency is increased again. This step S630 resets the synchronization frequency This is advantageous because it allows for increasing the synchronization frequency of parts of the twin that are required, for example, by a user of the management device (or by the management device itself), and which are therefore of interest to that user (or to the management device itself). The S630 step for resetting the synchronization frequency is, for example, initiated and / or controlled by the MOD_SCD module of this device.

[0146] It is noted that if only part of the digital twin was synchronized during the S620 synchronization step, the result is a digital twin, such as the representative digital twin of manufacturing plant 100, having parts synchronized at different synchronization frequencies.

[0147] The method further includes a step S640 of storing the synchronized data in the history H in association with the current time ^cur-

[0148] Finally, an S650 processing step is implemented in which the synchronized data is processed. In some implementations, this processing includes "rendering" (i.e., displaying or playing back audio, for example) all or part of the synchronized data. In cases where the rendering is visual, the digital twin management device is, for example, connected to a graphical interface that displays the generated data. The use of a graphical interface for displaying the data is, of course, only one example of implementation, and any interface associated with the digital twin management device that allows a user to access the generated data—regardless of the access method—can be considered.

[0149] According to certain embodiments, this processing includes an analysis of the generated data, for example in order to predict the behavior of the represented physical system, to simulate a pre-established scenario or to evaluate the causes of a specific behavior of the physical system.

[0150] During the S500 step of comparing the instant tREQ with the current instant ^cur, if the instant tREQ corresponds to a past instant tpASS (step S500, choice "tREQ < ^cur"Y steps S710 and S720 or steps S710, S730, S740 and S750 are implemented.

[0151] Step S710, which determines the presence of a state associated with this instant tREQ in the state history H, is implemented. During this step, it is determined whether a state associated with this instant tREQ is recorded in the state history H. If so (step S710, selection "Y"), a step S720, which processes the data of this state in the state history H, is implemented. According to certain implementation modes, the processing carried out during this step S720 is similar to that described with reference to step S650, which processes synchronized data.

[0152] On the other hand, if the state history H does not include a state associated with the time tREQ (step S710, choice "N"), a data generation step S730 in An association with the tREQ time is implemented whereby the data required at time tREQ are generated by the previously mentioned prediction model, based on at least one of the historical states for at least one time close to time tREQ. In some implementations, the historical state at the time immediately preceding time tREQ and / or the state immediately following time tREQ is taken into account to generate the required data. In some implementations, the historical states at the n times immediately preceding time tREQ and / or immediately following time tREQ are taken into account to generate the required data.

[0153] In certain embodiments, the synchronization process further includes an S740 step for storing, in the history H, the data generated during the S730 data generation step in association with the tREQ time. Such storage can prevent the prediction model from being called upon again if this data relating to the tREQ time is required again in the future.

[0154] Note that this step may be optional in certain embodiments (for example, to limit the memory usage of the history).

[0155] Finally, in some embodiments, the process includes a step S750 of processing of data generated during the S730 data generation step in association with the tREQ instant, According to certain implementation modes, the processing carried out during this S750 step is similar to that described in reference to the S650 step of processing of synchronized data.

[0156] If, during step S500 of comparing time tREQ with the current time tCUR, time tREQ corresponds to a future time (step S500, choice "tREQ > tCUR"), an error message, intended for the user who issued the request received during step S400 of receiving a data retrieval request, is issued in certain implementation modes. In other implementation modes, a prediction from the history can be performed (step S810) and a step S820 for processing the data from this prediction is implemented. According to some implementation modes, the processing implemented during this step S820 is similar to that described with reference to step S650 for processing synchronized data.

[0157] In some embodiments, a filtering step (not shown in [Fig.4]) is implemented prior to the processing steps S650, S750, S720 and / or S820.

[0158] The term "filtering" (or "selection") is used in the context of database access queries. It is, in fact, an analysis of the user query to identify the digital twins involved in the synchronization (or the relevant parts of a digital twin). Two illustrative examples are described below: the first example ("Example #1") deals with a simple query targeting a Synchronization of an entire digital twin: the second example (Example #2) relates to a query concerning the elements of a twin where one attribute ("temperature") is in a particular state (>19°C). In this case, we can:

[0159] - either synchronize all elements having the relevant attribute ("temperature"), then retrieve information only for elements having an attribute in the particular state (">19°C") (hence the term filtering) before a rendering step described below.

[0160] - either identify, via the history, the elements whose attribute ("temperature") has this particular state (>19°C") (for example during step S610, or before / during step S730 and / or step S810, i.e., step 500) and then synchronize these twins.

[0161] Synchronizing and then filtering can offer advantages in terms of reliability since the current state of the attribute is systematically ensured. Filtering and then synchronizing can offer advantages in terms of speed (since only a subset of the twins will be synchronized). For example, one can choose one or the other of these approaches depending on the time elapsed since the last synchronization of the twins in question.

[0162] When filtering is based on missing past or future data (i.e., when applied prior to steps S750, S720 and / or S820), synchronization with the physical system is not possible during the processing of the user request.

[0163] For a future state, it is therefore necessary to use essentially states predicted by the predictive model to determine the elements corresponding to the filter and to respond to the query. To avoid over-relying on data generation, the query may include one or more identifying elements of the system(s) for which it is necessary to predict values. Examples

[0164] i) a query carrying a twin (or part of a twin representing an element) identified by its identifier and one or more attributes in their future state. In this case, the generation of the missing data can be carried out immediately and then the result of the query is returned to the user;

[0165] ii) a query relating to a set of twins (representative of several elements of the physical system) identified by their respective identifiers and one or more attributes in their future state;

[0166] iii) a query relating to an indeterminate set of twins (representative of several elements of the physical system), and one or more attributes in their future state.

[0167] In cases ii) and iii), a predetermined limit max_n of the number of twins (or elements) can be envisaged, for example by following the following procedure:

[0168] -a user request concerning an unknown number of twins is received;

[0169] - a number of twins (or elements) n corresponding to the filter is determined;

[0170] - if n < max_n, the missing state prediction step is implemented;

[0171] - and if n > max_n, the process stops and / or an error message is sent to user destination.

[0172] For a past state, if no data corresponding to the filter and the requested past time is stored, new data can be generated by the predictive model. In this case, the elements described above for future states are used.

[0173] Examples of user requests

[0174] The following examples are based on the SQL language, as well as on the query language of a MongoDB database. It is important to note, however, that other languages ​​could be considered.

[0175] Example #1: query to retrieve data at time "2024-02-26T 16:00:57.101Z" from a twin identified by its ID

[0176] As mentioned previously, this first example ("Example #1") deals with a query concerning the entirety of a digital twin.

[0177] The corresponding SQL query can be expressed as follows:

[0178] SELECT * FROM DigitalTwin WHERE id == “90363aff-7eba-4b97-8al7- 527907c939ca” and timestamp == “2024-02-26T16:00:57.101Z”

[0179] And using the MongoDB query language:

[0180] {

[0181] “id”: “90363aff-7eba-4b97-8al7-527907c939ca”,

[0182] “timestamp”: “2024-02-26T16:00:57.101Z”

[0183] }

[0184] In this example, all properties of the twin with the identifier "90363aff-7eba-4b97-8al7-527907c939ca" are synchronized.

[0185] Example # 2: query to get data at time "2024-02-26T 16: 00:57.101Z" with filtering of an e _ property £ temperature > 19 °C ) :

[0186] As mentioned previously, this second example (Example #2) relates to a query which concerns one or more elements of which an attribute ("temperature") is in a particular state (>19°C).

[0187] The corresponding SQL query can be expressed as follows:

[0188] SELECT * FROM DigitalTwin WHERE temperature > 19 and timestamp == “2024- 02-26T16:00:57.101Z”

[0189] And using the MongoDB query language:

[0190] {

[0191] “temperature”: { $gte: 19},

[0192] “timestamp”: “2024-02-26T16:00:57.101Z”

[0193] }

[0194] According to some implementation modes, the MOD_SYN synchronization module can start synchronization, but without limitation to a temperature above 19°C. Indeed, the initially received request can be decomposed, and in a first step, initially, all twins having a "temperature" property are synchronized.

[0195] This first step is then equivalent to the following SQL query:

[0196] SELECT * FROM DigitalTwin WHERE temperature IS NOT NULL and timestamp == “2024-02-26T16:00:57.101Z”

[0197] And using the MongoDB query language:

[0198] {

[0199] “temperature”: { $ne: null},

[0200] “timestamp”: “2024-02-26T16:00:57.101Z”

[0201] }

[0202] In this case, all twins with a "temperature" property are synchronized, even if the "temperature" property has a value less than or equal to 19°C. In this implementation mode, the second filtering step will then be implemented, for example, during the S900 data access step.

[0203] Fig. 5 is a representation of an example of an environment in which the invention is implemented.

[0204] This Figure 5 differs from Figure 1 in that the digital twin management device 300 is connected to another digital twin management device 500 via the telecommunications network 400. This other digital twin management device 500 includes a replica 310' of the digital twin 310 from the vehicle manufacturing plant 100. In other words, the digital twin 310 is distributed among several digital twin management devices, thus allowing a user to interact with the nearest device, for example, to reduce data access time caused by the physical distance between the user and the digital twin management device.

[0205] In certain embodiments, the twin 310 of the device 300 closest to the physical system 100 is regularly synchronized with the physical system 100, for example at the initial frequency / 0, and the method according to the invention is then implemented by the device 500 in charge of the digital twin 310'. In this particular case, the digital twin 310' corresponds to a replica of the digital twin 310, but the two twins 310 and 310' are not synchronized with the physical system 100 using the same synchronization frequency.

[0206] More specifically, the 500 digital twin management system implements the following steps:

[0207] - a plurality of synchronizations of at least a portion of the digital twin 310' with the digital twin 310 implemented according to at least one variable synchronization frequency. In some implementation modes, this step includes a progressive reduction of the synchronization frequency of the digital twin 310' with the digital twin 310 as long as the effective accuracy of the prediction model of the digital twin 310' is adapted;

[0208] - in response to receiving a request to obtain data from the system physical at a current time, a synchronization of at least a portion of the digital twin 310' with the digital twin 310, and a reset of the synchronization frequency of at least a portion of the digital twin 310' with the digital twin 310 to a value greater than a current value of said synchronization frequency.

Claims

Demands

1. A method for synchronizing a first digital twin (310) representing at least a part of a physical system (100), the method being implemented by a digital twin management device (300) and comprising: • a plurality of synchronizations (S300) of the first digital twin (310) with the physical system (100), implemented according to at least one variable synchronization frequency; • in response to receiving a request to obtain data from the physical system at a current time (^cur\ a synchronization (S620) of at least a part of the first digital twin (310) with the physical system (100); and a reset (S630) of the synchronization frequency of at least a part of the first digital twin (310) to a value greater than a current value of said synchronization frequency.

2. Synchronization method according to claim 1, the first digital twin (310) comprising a prediction model, and the synchronization frequency being progressively reduced as a function of an effective accuracy of the prediction model.

3. Synchronization method according to claim 2, the synchronization frequency being progressively reduced as long as the effective accuracy of the prediction model is adjusted.

4. A synchronization method according to any one of claims 1 to 3, wherein only a Psync portion of the first digital twin is synchronized in response to receiving the data retrieval request, the method further comprising, synchronizing the Psync portion according to the reset frequency Finit, and synchronizing the digital twin excluding the Psync portion according to the current value of the synchronization frequency.

5. A synchronization method according to any one of claims 1 to 4, the first digital twin (310) comprising a prediction model, the method further comprising: • a generation (S 100) of a history (H) of states of the physical system (100), each state of the history being associated with a time * and including values ​​of different dynamic variables of the physical system (100) at said time*; and, • a training (S200) of the prediction model using the history of states as training data.

6. A synchronization method according to claim 5, comprising: • upon receiving a request to obtain data from the physical system (100) relating to a time prior (^pass) to the current time (tcuKh) • a prediction (S730), by the prediction model, of data associated with the prior time (tpA$s) as a function of at least one state in the history (H) when the history (H) of states does not include a state associated with the prior time (tpASS)-

7. Synchronization method according to claim 6, further comprising recording the predicted data at the earlier time tpASS in the history (H) of states of the physical system (100).

8. Synchronization method according to any one of claims 1 to 7, further comprising a determination (S610) of said at least a part of the first digital twin (310) to be synchronized with the physical system (100), according to the data retrieval request.

9. A synchronization method according to any one of claims 1 to 8, further comprising a storage (S640), in the state history (H), of data resulting from the synchronization of at least a part of the first digital twin (310) with the physical system (100) in association with the current time tcuR-

10. Synchronization method according to any one of claims 1 to 9, further comprising access (S650, S750, S720), by a rendering module, to the data resulting from the synchronization of at least a part of the first digital twin (310) with the physical system (100).

11. A synchronization method according to any one of claims 1 to 10, further comprising filtering the data from the synchronization of at least a part of the first digital twin (310) with the physical system (100).

12. Synchronization method according to any one of claims 1 to 11, the plurality of synchronizations being carried out directly between the first digital twin and the physical system (100), or via a second digital twin representing at least partially the physical system (100).

13. Digital twin management device (300) configured to implement a synchronization method according to any one of claims 1 to 12.

14. Computer program (PROG) comprising instructions for implementing a synchronization method according to any one of claims 1 to 12, when said program is executed by a processor.

15. Computer-readable recording medium on which a computer program according to claim 14 is recorded.

Images