Method and system for predicting the evolution of simulation results for internet of things networks

Abstract

To provide a method for predicting the evolution of simulation results for Internet of Things (IoT) networks.SOLUTION: A method includes: performing a source digital twin, any clone digital twin, and an exploratory digital twin; and providing an evolved modified state of one or more of objects at an additional incremental time as an output of the exploratory digital twin.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates to the simulation (modeling) of networks of objects in the Internet of Things (IoT). IoT refers to the interconnection of computing devices embedded in everyday objects via the Internet (and potentially other networks), allowing them to send and receive data. This application uses the concept of a digital twin (DT). A digital twin is a virtual (mathematical) model that reflects the current state of the object being modeled using data inputs to the corresponding object. The digital twin updates and changes as the corresponding object is updated and altered to reflect new states (variable results of inputs that describe its status), e.g., working conditions and / or location. [Background technology]

[0002] One example of the use of digital twins is in transport management, such as in smart cities, but there are many other applications, for example in power networks to ensure balanced power supply over large areas.

[0003] Taking transportation as an example, smart transportation systems (or Intelligent Transportation Systems (ITS)), which are used to control traffic by linking data from sensors and traffic signals, promise to make transportation better (more reliable, more efficient, safer, and faster) by optimizing the operation of the entire system, including roads, roadside infrastructure, vehicles, pedestrians, etc. These systems combine data generated by sensors (located at suitable positions in the system, such as on vehicles, travelers, and infrastructure) with data from other sources (e.g., weather and / or social data) using big data techniques and machine learning (ML). Summary of the Invention

[0004] To offer better transportation prospects, smart transportation systems must provide a wide range of services to diverse users at scale (potentially thousands of users or more) in real time (fast enough to take effective action).

[0005] This proposal relates to the concept of Pipelined Digital Twin Sequences, which form the subject matter of related European Patent Application No. 20202133.3. Considering the execution of a pipelined digital twin sequence, for example through a management interface, a (potential) problem may be identified and it may be decided to intervene in the system to reduce the impact of the problem.

[0006] For example, if the system being monitored is a public transport bus network, there may be an incident where a road is blocked on one of the bus routes. The public transport system manager wants to ensure continuity of service by rerouting buses around the blocked road. There may be many options for rerouting, with different impacts on changes to journey times and missed stops (which leave some passengers stranded).

[0007] The requirement is to manage incidents occurring in large-scale, evolving systems such as transportation systems, smart cities, or power networks, which generate large amounts of sensor data either streaming from sources on the system or from real-time sensed data streaming from services providing the system. The response to the incident needs to be made in "real-time," that is, fast enough for users of the service to take immediate action. There are diverse data sources, generating different types of data at different rates.

[0008] For example, a large city's transportation authority may create a system digital twin of its public transportation infrastructure that provides a real-time virtual model of people flows throughout the city, driven by data generated in real time from a wide range of diverse sources. Vehicle movements from in-vehicle GPS, roadside sensors, CCTV analysis, routing requests, and live public transport dispatch The status and operation of infrastructure such as traffic lights Mobile GPS, ticketing activity, and people movement from CCTV.

[0009] The National Traffic Information Service, responsible for traffic management on England's trunk road network, obtains data from approximately 1 million vehicles on the road network, 1,000 license plate cameras, and over 10,000 roadside monitoring units. Transport for London, responsible for London's public transport system and road network, operates over 9,000 buses and 900 trains, controls 6,300 traffic lights, manages vehicle traffic of over 100,000,000 km per day, and manages the journeys of over 5,000,000 public transport passengers per day.

[0010] A system digital twin (a virtual model of a system) integrates these data sources and provides a real-time understanding of the state of traffic flow. Synchronization services may be added to the digital twin, such as by using anomaly detection methods to identify incidents (accidents, congestion, etc.). However, there is also a need to manage these incidents, for example by diverting traffic around the accident, deploying emergency services, and / or rerouting public transport. A system digital twin can provide and assist with this if it has predictive capabilities that advance the model's virtual state in time (faster than real time or at a fixed offset from real time).

[0011] In other words, a requirement of smart transportation systems and other complex systems is to predict the state of the system, thereby enabling services such as collision detection, accurate journey time prediction, determining the impact of an incident on the system, showing when public transport will arrive, selecting an individual taxi, etc. Each of these services is based directly or indirectly, primarily in terms of positioning, on the state of the modeled infrastructure / objects within the infrastructure.

[0012] The same requirements are evident in other application areas, for example in power networks.

[0013] According to an embodiment of a first aspect of the present invention, there is provided a method for predicting the evolution of simulation results for an Internet of Things (IoT) network, comprising: creating a source digital twin for the IoT network driven by real-time sensory data from objects fed into models of the objects, the source digital twin outputting states of one or more objects of the objects in real time; additionally creating one or more additional clone digital twins, each comprising the same model and interconnections as the source digital twin; connecting the input of a first clone digital twin with the output of the source digital twin via a data stream composer node, the data stream composer node adding time increments to the output of the source digital twin so that the source digital twin drives the first clone digital twin at the incremented time; and connecting the input of a further clone digital twin with the output of a preceding clone digital twin in the sequence via further data stream composer nodes. connecting the output of the exploratory digital twin with the output of the source digital twin, where the further data stream composer node adds further time increments to the output of the preceding clone digital twin to cause the preceding clone digital twin to drive the further clone digital twin at the further incremental time, forming a primary digital twin sequence; creating an exploratory digital twin that includes the same model and interconnections as the source digital twin; connecting the input of the exploratory digital twin with the output of any of the source digital twin, the first clone digital twin, and any further clone digital twins to initialize the exploratory digital twin; modifying aspects of the exploratory digital twin to simulate actions taken in the exploratory digital twin; connecting the output of the exploratory digital twin with the input of the exploratory digital twin through the further data stream composer node, where the further data stream composer node adds further time increments to the output of the exploratory digital twin to drive the exploratory digital twin at the further incremental time;and executing the source digital twin, any clone digital twin, and the exploratory digital twin to provide an evolved modified state of one or more of the objects at additional incremental times as an output of the exploratory digital twin.

[0014] Exploratory digital twins allow system managers to formulate responses to situations such as problems (e.g., road construction) in the modeled system in the form of actions (e.g., diversions) and check the impact of these actions on the system.

[0015] In this sense, each digital twin (source, clone, exploratory) is a system digital twin, and each individual model (node) is an object digital twin.

[0016] Of course, the source digital twin may also be performing modeling (in the first clone digital twin) of the evolution of the system over time increments (without actions), and similarly, any further clone digital twins may also be performing modeling (in the further clone digital twins) of the evolution of the system over further time increments (without actions).

[0017] An exploratory digital twin is cloned from a source digital twin (or any clone digital twin) and modified to reflect actions taken on a physical object (or system). For example, to apply an action, a method may make appropriate changes to the state (or values) of the relevant objects rather than (or in addition to) evolving them in the usual way via a data stream synthesizer.

[0018] The additional data stream synthesizer uses the same exploratory digital twin outputs to emulate data inputs to the exploratory digital twin, providing time-incremented synthetic values ​​(e.g., by incrementing position from the original state of the exploratory digital twin using the vehicle's output position and velocity to determine the position at a selected time). Thus, instead of an actual detected position, based on known data, the exploratory digital twin is provided with a synthetic position for a given additional time increment that simulates how the effect of actions would modify the exploratory digital twin's state. The term "additional" here is to distinguish it from the data stream synthesizer and the time increments associated with the primary digital twin sequence.

[0019] This allows an exploratory digital twin (which, at least initially, has the same modeling as the source digital twin, optionally a clone digital twin, and then, for example, starts from the same state as the source digital twin) to generate an evolved state (of itself) at a future-projected state. Thus, the exploratory digital twin effectively drives itself incrementally in time. One or more clone digital twins cloned from a source digital twin may be provided in a sequence (after a single-source digital twin), which is extrapolated into the future, as described in more detail below. Thus, an exploratory digital twin created from a digital twin may be created from either the source digital twin or a clone digital twin.

[0020] An exploratory digital twin may be run in parallel with the digital twin (source or clone) from which it is created, i.e., it may start in the same state and at the same (modeling) time as the twin from which it was created. In deployment, an exploratory digital twin may be run in parallel with the digital twin, but at a faster rate, so that the evolving state of objects in the exploratory digital twin may be calculated faster than real time, allowing the future effects of actions to be understood quickly and decisions regarding the network to be implemented at the earliest possible stage.

[0021] Preferably, the time increment used for later digital twins in the sequence (i.e., clone digital twins or exploratory digital twins that appear later in the digital twin sequence than the source digital twin or earlier clone digital twins or earlier exploratory digital twins) has a larger value because the simulation precision for the distant future is smaller than that for the near future (relative to actual events). In this way, unnecessary computational costs incurred by running at fine time resolution are reduced.

[0022] Models of objects in a source digital twin may be interconnected as object nodes in a directed acyclic graph, DAG, where the interconnections represent the flow of data.

[0023] Nodes in a simulation are not limited to nodes representing objects. Any suitable type of node may be added depending on the situation. Nodes in the source digital twin (and therefore in the exploratory and clone digital twins) may include event nodes that model events that affect the IoT network, such as incidents that affect the state of an object.

[0024] In one arrangement, the digital twin that is cloned to create the exploratory digital twin is the source digital twin, i.e., a virtual model of a physical object or system that reflects the current state of the physical system / object and is driven by events and sensor readings from the real world. In this way, the exploratory digital twin may explore the effects of actions taken on the initial state of the modeled physical object or system. In another arrangement, the digital twin that is cloned to create the exploratory digital twin is the clone digital twin, i.e., a virtual model of a physical object or system that reflects the state of the physical system / object at a future point in time, the state of which is determined by driving one or more other digital twins (the source digital twin or other clone digital twins).

[0025] Additionally or alternatively, nodes in the source digital twin (and therefore in the exploratory digital twin and any clone digital twins) may also include system information nodes that model information about the IoT network.

[0026] The method may further include creating a service node (as part of the overall DAG) with the output of the source digital twin, the output of the exploratory digital twin, or the output of any digital twin, or any combination thereof. The service node may generate a data service, for example, based on the state of objects in the IoT network. More preferably, both the output and the service are based on the state of all nodes in the network, either in real time (the output of the source digital twin) or in the future (the output of the clone digital twin or the exploratory digital twin). Of course, the service may use the state of multiple objects, or the predicted evolved state of other services or objects in a chain of clones.

[0027] Such "services" can be seen as functions (in the mathematical sense) of state. For example, the predicted location of a vehicle is a state, but the system can output a collision warning, which is a service / function that depends on the locations of all vehicles (part of the state).

[0028] In a preferred configuration, a service node is provided in parallel (at the same modeling time) with a data stream combiner for the digital twin and / or an additional data stream combiner for the exploratory digital twin. In this arrangement, the method may further include providing an output of the source digital twin to both the service node and the data stream combiner. The method may additionally or alternatively include providing an output of the exploratory digital twin to both the service node and the additional data stream combiner. It will be understood that a data combiner is not required at the output of the last clone digital twin in the sequence or at the output of the last iteration of any exploratory digital twin in the sequence.

[0029] In embodiments, multiple exploratory digital twins may be used to explore, for example, the effects of different actions taken on a physical object (or system) and / or the effects of the same action taken on a physical object (or system) at different times. More specifically, the method may further include creating an exploratory digital twin (second, third, etc.) that includes the same model and interconnections as the source digital twin. The method may further include connecting inputs of the further exploratory digital twins to outputs of either the source digital twin and, if created, the clone digital twin. Similar to the (initial) exploratory digital twin, this initializes the further exploratory digital twin. The method may further include modifying aspects of the further exploratory digital twin to simulate actions taken in the further exploratory digital twin. The actions taken in the further exploratory digital twin may be the same or different from the actions taken in the (initial) exploratory digital twin.

[0030] The method may further include connecting the output of the further exploratory digital twin with the input of the same further exploratory digital twin. As described above, to enable time augmentation, this connection may be through another additional data stream combiner node that adds another additional time increment to the output of the further exploratory digital twin, causing the further exploratory digital twin to drive (i.e., drive) the further exploratory digital twin at the another additional increment of time. Note that the term “another additional” is used here to distinguish it from the “additional” time increment and data stream combiner used for the (first) exploratory digital twin and from the “further” time increment and data stream combiner used for the further clone digital twin. The another additional time increment and the additional time increment may be the same value or different values.

[0031] The method may further include executing a further exploratory digital twin to provide an evolved state of one or more of the objects at another additional incremental time as an output of the further exploratory digital twin. The method may further include comparing the output of the exploratory digital twin with the output of the further exploratory digital twin. Because both actions are implemented simultaneously (in the same state), the comparison allows a user to determine the effects of both actions and determine the optimal action to take.

[0032] The time increments for further exploratory digital twins (further additional time increments) may be the same as or different from the (initial) additional time increments used for the (initial) exploratory digital twin. If the same time increments are used, the method may compare the results with the effects of actions taken at equivalent time intervals in the future (after application of any actions).

[0033] In embodiments with multiple exploratory digital twins, the inputs of the additional exploratory digital twins may be connected to the same inputs that are connected to the inputs of the (initial) exploratory digital twin. Actions taken (simulated) in the (initial) exploratory digital twin may be different from actions taken in the additional exploratory digital twins. In this way, the effects of different actions taken simultaneously on the same physical object (or system) may be explored.

[0034] In embodiments where there are multiple exploratory digital twins and multiple digital twins in a digital twin sequence (e.g., a source digital twin and clone digital twins, or a source digital twin and many clone digital twins), it is possible to explore the effects of actions taken at different times. More specifically, the inputs of the further exploratory digital twins may be connected to different outputs than the outputs connected to the inputs of the (first) exploratory digital twin (e.g., the (first) exploratory digital twin may be connected to the source digital twin, and the further exploratory digital twin may be connected to a clone digital twin that is itself connected to the source digital twin). Actions taken (simulated) in the (first) exploratory digital twin may be the same actions taken in this further exploratory digital twin.

[0035] Of course, embodiments allow for the creation of many exploratory digital twins, some capable of exploring the effects of actions taken at different times, others capable of exploring the effects of different actions taken simultaneously.

[0036] Inputs to the simulation are not limited to real-time sensor data or IoT data. Preferably, contextual information from external data sources is additionally input to the source digital twin and / or any exploratory digital twins and / or any clone digital twins.

[0037] For any exploratory digital twin (first, second, further, etc.), embodiments may enable iterative processing of the initial state. That is, the exploratory digital twin is run repeatedly (iterations), with each iteration providing an evolved state at the next incremental time. This process may be repeated indefinitely by feeding back the evolved state from the output of the exploratory digital twin to the input of the exploratory digital twin. In this manner, the method may provide, as the output of the exploratory digital twin, multiple evolved, modified states of one or more of the objects at repeated incremental time intervals.

[0038] In embodiments, the execution of any source digital twin or any clone digital twin may be real-time (following or tracking real-time). That is, the system simulated by the source or clone digital twin may evolve in real time, for example, using sensor data acquired in real time. For example, for a source digital twin, executing in real time may involve acquiring sensor data in real time. Similarly, for a clone digital twin, executing in real time may involve processing the next clone digital twin in the sequence at a rate that matches the rate at which a real-life object (e.g., a car) moves or any sensor data updates. Any exploratory digital twin may be executed at a faster rate, so that any evolving state reflecting any impact of any action is quickly obtained. In this way, decisions regarding the implementation of actions can be made quickly.

[0039] Creating an exploratory or clone digital twin may not necessarily involve creating a complete replica of the underlying code (e.g., of the source digital twin). In embodiments, creating a digital twin may involve using the same code as the source digital twin (so that only one code copy is needed for the entire sequence). The twin's state is input into the code (at the twin's current time) and the code is executed one or more times. The method may further include replacing the current state of the digital twin or exploratory digital twin with the resulting state after execution. In this way, for example, a state from multiple states corresponding to each digital twin (e.g., multiple states stored in a database) may be selected for loading into a "shell" of code common to all digital twins and connected to a data stream synthesizer. For example, each state may be stored as a collection of values, which may be loaded when needed. This method of creating digital twins avoids the computational burden of replicating a large system (both the code and associated data).

[0040] Turning to a preferred particular application, the IoT network may be a transportation network, where the object nodes may include vehicle nodes and / or one or more infrastructure nodes, and one or more event nodes, such as a traffic incident node.

[0041] The state of one or more of the objects may include one or more of the object's position and the object's velocity.

[0042] In one scenario, the transportation network is a public transit network, and the nodes in the source digital twin and any exploratory digital twin(s), as well as the optional clone digital twin(s), include vehicle nodes, incident nodes representing events that may affect the public transit network, stop nodes representing sections of the public transit network infrastructure, and system information nodes representing vehicle routes. In this case, the order of the DAG may be Incident, Stop, Run, and Bus nodes (each type of node is parallel in each digital twin of the system).

[0043] According to one embodiment of a further aspect of the present invention, a method for predicting the evolution of simulation results for an Internet of Things (IoT) network includes generating a source digital twin for the IoT network driven by real-time sensory data from objects fed into a model of the objects interconnected as object nodes in a directed acyclic graph, DAG, with interconnections representing data flow, the source digital twin outputting real-time states of one or more of the objects; creating an exploratory digital twin including the same model and interconnections as the source digital twin; and configuring the source digital twin to initialize the exploratory digital twin. modifying aspects of the exploratory digital twin to simulate actions taken in the exploratory digital twin; connecting the inputs of the exploratory digital twin and the outputs of the source digital twin through a data stream combiner node, where the data stream combiner node adds time increments to the outputs of the exploratory digital twin such that the exploratory digital twin drives the exploratory digital twin at the increments of time; and running the source digital twin and the exploratory digital twin to provide evolved modified states of one or more objects at the same increments of time as the outputs of the exploratory digital twin.

[0044] According to an embodiment of a further aspect of the present invention there is provided a computer program having instructions which, when the program is run by a computer, cause the computer to perform any of the methods described above.

[0045] The program may be executed locally, in the cloud, or both, to provide a computer-implemented method on a local device. For example, a digital twin may be built and executed on a server (on the cloud), and the output may be provided to a local device to provide a specific service.

[0046] According to an embodiment of a further aspect of the present invention, there is provided a computer (data processing device) including a processor and memory and a network interface configured to perform the method of any of the preceding claims, wherein the processor and memory may be linked to a display (e.g., for displaying digital twin sequences (including any exploratory digital twins)) and / or an input device (for developers to input data and parameters to build models or for end users to interact with a service).

[0047] A corresponding computer system may include the computer defined above, a display, an input device, and any other required components.

[0048] An apparatus (computer or computer system) or computer program according to preferred embodiments of the present invention may include any combination of method aspects. Methods or computer programs according to further embodiments may be described as computer-implemented in that they require processing and memory capabilities.

[0049] Apparatus according to preferred embodiments may be configured or arranged to perform certain functions, or may simply be described as performing such functions. This configuration or arrangement may be done using hardware or middleware, or any other suitable system. In preferred embodiments, the configuration or arrangement is by software.

[0050] The invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can also be implemented as a computer program or computer program product, i.e., a computer program having instructions tangibly embodied in a non-transitory information carrier, for example a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, one or more hardware modules.

[0051] The computer program may be in the form of a stand-alone program, a computer program portion, or multiple computer programs, may be written in any type of programming language, including compiled or interpreted languages, and may be deployed in any form, either as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a data processing environment. A computer program may be deployed to run on one module or on multiple modules at one site or distributed across multiple sites and interconnected by a communication network.

[0052] The method steps of the present invention may be performed by one or more programmable processors executing computer programs that perform the functions of the present invention by operating on input data and generating output. Apparatus of the present invention may be implemented as programmed hardware or as special purpose logic circuitry including, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0053] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor receives instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for executing instructions coupled to one or more memory devices for storing instructions and data.

[0054] The present invention is described with reference to specific embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the present invention may be performed in a different order and still achieve desirable results. Multiple test script versions may be edited and invoked as a unit without using object-oriented programming techniques. For example, the elements of a script object may be organized within a structured database or file system, and the actions described as being performed by the script object may be performed by a test control program.

[0055] Elements of the present invention may be described using terms such as "processor," "input device," etc. Those skilled in the art will understand that such functional terms and their equivalents may refer to parts of a system that are spatially separate but combine to perform a defined function. Similarly, the same physical part of a system may provide two or more of the defined functions.

[0056] For example, any separately defined means may be implemented using the same memory and / or processor, where appropriate. [Brief explanation of the drawings]

[0057] Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:

[0058] [Figure 1] 1 is a schematic diagram of a simple processing DAG. [Figure 2] FIG. 1 is a schematic diagram of a simple processing DAG with data flow for predictive capabilities. [Figure 3] A schematic diagram of the source digital twin and two clone digital twins. [Figure 4] A schematic diagram of the source digital twin and seven clone digital twins. [Figure 5] Schematic diagram of the digital twin sequence. [Figure 6] Schematic diagram of digital twin cloning. [Figure 7] FIG. 1 is a flow diagram illustrating a method for predicting the evolution of simulation results for an IoT network. [Figure 8] FIG. 1 is a schematic diagram of an exploratory digital twin branching from a source digital twin, according to an embodiment. [Figure 9] FIG. 1 is a schematic diagram of an exploratory digital twin branching from a clone digital twin, according to an embodiment. [Figure 10] FIG. 1 is a schematic diagram of multiple exploratory digital twins branching from a digital twin sequence, according to an embodiment. [Figure 11] FIG. 1 is a schematic diagram of an exploratory digital twin, according to an embodiment. [Figure 12] Schematic diagram of the exploratory digital twin lifecycle. [Figure 13] Schematic diagram of digital twin cloning using twin model code and state. [Figure 14] A second schematic diagram of cloning a digital twin using twin model code and state. [Figure 15] FIG. 1 is a diagram of an example of public transportation. [Figure 16] This is an example of a public transport connected digital twin. [Figure 17] FIG. 1 is a diagram of suitable hardware for implementing an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0059] Processing large-scale streaming data and providing real-time insights is used in many web-scale applications, such as clickstream processing to deliver advertisements, online fraud detection, and video media consumption. It also has applications in smart transportation, for example, ride-hailing services. In ride-hailing services, location data is used to provide arrival estimates, pricing, driver assignment, and ride monitoring. The latter application typically requires merging two or more data streams, for example, to match passengers with drivers and vehicles. However, the design of stream data processing systems makes this difficult. Complex processing can only be applied at the level of a single data stream; merging different data streams requires a lot of effort. This is particularly problematic when processing relies on object history, because prior art lacks a mechanism for maintaining correlated histories of multiple data streams. This limits the number and sophistication of services that can be built on real-time data streams. As a result, real-time services are often naive, and more complex processing is performed offline.

[0060] One useful concept used to develop more sophisticated services is the digital twin introduced above. In a digital twin, an actual entity in the real world, for example a vehicle, is replicated in the digital world and its behavior is modeled in code, but driven by values ​​from input streams of sensor data. One advantage of digital twins is that they decouple services from acting directly on data streams; services can act on the state and outputs of the digital twin.

[0061] When modeling complex systems, designers distinguish between the digital twin of the entire system (system digital twin, e.g., a smart city) and the digital twins of its components (object digital twins, e.g., vehicles, passengers, traffic lights). Object digital twins automatically handle the collection of all data streams related to their real-world counterparts (e.g., vehicle telemetry and location data from the current occupants), remember all relevant history (state), and perform complex processing to model the object's behavior or state, which is then output.

[0062] Such digital twins can be built on top of large-scale, high-volume streaming data using platforms such as Fujitsu's Stream Data Utiliser (also known as Dracena: https: / / www.fujitsu.com / global / about / resources / news / press-releases / 2019 / 1008-01.html), Flink's Stateful Functions (https: / / flink.apache.org / stateful-functions.html) or Azure's Durable Functions (https: / / docs.microsoft.com / en-us / azure / azure-functions / durable / durable-functions-overview?tabs=cshar).

[0063] Platforms that process streaming data achieve high performance, in part, by constraining the types of computations that can be performed with a general constraint that requires processing to be structured as a directed acyclic graph (DAG). A processing graph consists of nodes where computations occur (which correspond to object digital twins or services that use their output) and edges that connect those nodes and represent the flow of data or events. When a graph is a DAG, events always flow forward; there are no cycles that allow reprocessing of data already processed by a node. In other words, nodes can be grouped into sets that form stages, with no communication from one stage to a previous stage or "backward" or "sideways" communication between nodes within a stage.

[0064] Some platforms, such as Flink's Stateful Functions, may tolerate such cycles in processing, but at a significant performance penalty.

[0065] There are techniques to overcome these limitations, for example by introducing nodes that aggregate events or by splitting the digital twin across multiple stages.

[0066] Digital twins implemented using these technologies can provide services based on current or recent past states, but they struggle when asked to provide services that require predicting future state evolution. With conventional technologies, time dependency is incorporated into a system digital twin by modifying the behavior equations of each individual object twin. Time dependency in interactions between object twins then requires messages to be passed between object twins (nodes) that share the same computational stage. As mentioned above, this becomes impossible with streaming platforms, which require computations structured as DAGs.

[0067] Figure 1 shows a very simple processing DAG. The lettered circles (A, B, C) are processing nodes, and the connecting edges represent data flow (arrows indicate direction). This DAG can be used to predict travel time along a section of road, where node A is the object digital twin of a vehicle and node B is the object digital twin of the section of road. Node C provides a travel time estimation service. In practice, there will be many instances of node A and node B types and fewer instances of node C, but the data flow will be strictly left to right. Node A supplies the vehicle's location(s) and route(s) to node B, which accumulates that data and calculates traffic density on those segments. Node C uses that traffic density to calculate travel time.

[0068] The configuration in Figure 1 gives a view of the current travel time, but not the future state of the road. An estimate of where the vehicle will be at a future time depends on the travel time of the road segment computed at node C. Figure 2 shows the data flow required to achieve this. The movement of data from node C to node A means that the graph is no longer a DAG and cannot be processed (or cannot be processed efficiently) using current stream data processing systems.

[0069] Pipeline Digital Twin

[0070] The method allows estimating the future state of a system modeled by a digital twin by duplicating the digital twin to create a clone digital twin. The clone digital twin has the same mathematical modeling as the original (or source) digital twin, but different inputs and therefore different outputs. Thus, although the modeling is the same, the twin's state is different (due to ML learning and / or time differences).

[0071] As used herein, a source digital twin (sDT) is a virtual model of a physical object or system (e.g., system digital twins of smart cities, transportation networks, power networks, etc.) that reflects the current state of the physical system / object and is driven by events and sensor measurements from the real world.

[0072] As used herein, a clone digital twin (cDT) is a virtual model of a physical object or system that reflects the state of the physical system at some point in the future, upon which some action may be performed. The cDT is driven by the output of one or more other digital twins in a collection.

[0073] As used herein, the term "driven" defines the primary source of data used to set the state, and therefore the modeled behavior, of a digital twin. In traditional digital twins, this is the real world, but in this methodology, digital twins can be driven by the output of other digital twins.

[0074] As used herein, a digital twin collection is a collection of one or more digital twins (typically system digital twins).

[0075] As used herein, a physical system or object is the part of the real world that is modeled by a digital twin as described in this paper.

[0076] As used herein, a digital twin sequence (DTS) is an ordered collection of system digital twins offset from one another by some time interval (not necessarily constant) and intended to model the future evolution of a physical system. The sequence begins with an sDT followed by several cDTs, each driven by the previous digital twin in the sequence. Because DTS runs in real time, the digital twins in the sequence always reflect the state of the physical system at the same offset from the current time.

[0077] As explained in more detail below, these clones can be run in parallel with the original digital twin, but by advancing their system time (the time they model) by small increments to estimate future states. A series of clones can be run in parallel, advancing time incrementally until the desired predicted offset is reached. Alternatively, a single clone can be provided.

[0078] As used herein, an exploratory digital twin (eDT) is a cDT used to explore the effects of actions on a physical object or system. An eDT can be initialized by cloning the state of a digital twin (either source or clone) on the main (pipeline) DTS with the necessary modifications to reflect the actions. The state of the eDT may be used at one time to drive the eDT the next time; that is, the eDT is driven by its own output at the previous time in the simulation time sequence.

[0079] Furthermore, as used herein, a pipeline DTS is a DTS in the absence of any eDT. This is also referred to as the "main DTS." In this manner, an eDT may be thought of as an exploratory "branch" derived from a pipeline DTS.

[0080] Figure 3 is a schematic diagram of nodes and data flows, illustrating the new flow of data and the structure of computation. Note that data flow is strictly unidirectional (left to right) through the graph, and the graph is maintained as a DAG. The system source digital twin (containing object twins A and B) is shown at the bottom layer. Future states of the system are shown as higher layers, and each of these layers also maintains a DAG. These future states are given by the clone digital twin cDT at present + Δt1 (containing object twins A' and B') and present + Δt2 (containing object twins A' and B'), where Δt n is the offset from the real time (now) of cDT. Here, now + Δt2 can be seen as the first clone time plus a further time increment. All digital twins export the same data / services as before (data goes out the right side). Of course, more clone digital twins may be provided, or just a single clone digital twin may be provided.

[0081] Figure 3 introduces a new type of processing node, the "Data Stream Synthesizer," labeled DS (301, 302). This is responsible for effectively providing a modified "synthesized" data stream for the subsequent cDT and advancing the simulation time. The Data Stream Synthesizer receives the state of all object twins in a system twin (sDT or cDT) and models the time evolution of each twin, advancing the simulation time to the time of the subsequent clone. For example, the Data Stream Synthesizer uses vehicle speed and position data to advance the vehicle's position to its estimated position at the incremented time. Other examples are: using traffic light sequencing to determine the traffic light setting at the incremented time; using passenger pick-up / drop-off counts to determine whether a bus is leaving the stop at the incremented time; or using downstream traffic density and flow to calculate upstream traffic density at the incremented time. Any or all of these examples and other suitable algorithms may be used in combination depending on the available data, required accuracy, and available computing power. In a power generation and transmission scenario, an example of time evolution modeling is the use of weather forecast (context) data to set the magnitude of power generated at incremental times.

[0082] The data stream synthesizer uses that time-forward state to generate a prediction of the data that the real-world sensors will produce at the next clone's simulation time.

[0083] Using this structure, the inputs of a future clone may be derived from the outputs of the previous clone in the sequence. The "current" digital twin is driven by external events and data (coming in from the left), while the future clone digital twins (times, now+Δt1 and now+Δt2) are driven by the combined results of the previous digital twins ("now" drives now+Δt1, now+Δt1 drives now+Δt2, etc.).

[0084] These services are not shown here (nor in Figure 4), but they may be Node Bs, so there is a single object digital twin, or they may be provided as additional nodes for each digital twin (or any digital twins for which they provide that service), for example, in series before the data stream combiner or in parallel with the data stream combiner.

[0085] Cloning a digital twin can increase computational load and resource consumption in direct proportion to the number of clones (see below for further strategies to mitigate this possible effect). Note that each clone covers its time range, maintaining a constant offset from the base simulation, as set by the data stream synthesizer. As real time progresses, the sDT follows, and the cDT maintains their offset (e.g., Δt1 and Δt2 in Figure 3). However, because this is a simulation of the evolution of a real system, the further into the future the clones become less accurate. Simulation errors from modeling inaccuracies and lack of current values ​​for some data propagate to the next stage. Furthermore, the further into the future the time predicted, the longer the time scale over which values ​​are required. For both of these reasons, the time range covered by each clone is not necessarily constant, and can increase the further ahead of time modeled. See Figure 4 for an illustration of this, where each digital twin is shown as including exemplary nodes A and B, followed by a data stream synthesizer DS. The first digital twin on the left side of the diagram is the source digital twin, the other digital twins are clones, and Δt can increase from Δt1 to Δt7.

[0086] As present time progresses, the "now" source digital twin uses incoming data to keep up with present time. Output from "now" drives "now+Δt1" and "now+Δt2" via a data stream synthesizer, meaning these clones maintain an offset from present time. In this way, services that rely on a simple evolution of the current state (e.g., routing based on traffic conditions one hour after the start of a trip) can be provided.

[0087] Figure 5 is a schematic diagram in which the representation of individual nodes (object digital twins) in each system digital twin is replaced by a single block representing the system digital twin, illustrating the key processes in a DTS implementation.

[0088] A digital twin system, known from the prior art, maintaining an evolving mirror of the state of a physical system is formed from items 501, 502, 503, and 504. Real-world sensors 501 and / or other real-world data sources provide real-world data streams that are fed into a source digital twin (sDT) 503 (of the system). The output of the source digital twin (sDT) is passed to both a service 504 and a data stream composer 506. The sDT 503, which models the physical system, is driven not only by a real-time data stream 501 but also, potentially, by a further stream of data 502 that provides information about the physical system's context (e.g., weather conditions, events, month of the year, etc.). The information about the context can be real-time or, for example, from a database query. The system uses data from the sDT to provide a service 504 (such as a simple routing service) to clients. The next component of the DTS is formed by cloning the sDT 503 to form a first cDT 505. This cDT 505 is driven by a synthesized data stream created from a data stream synthesizer 506 and possibly context information (e.g., offset by ΔT by reference to later weather forecasts or data applicable at the incremented time if there are changes in the context data over time). This cDT provides a service 507 for clients derived from data estimating the state of the physical system at t0 + ΔT1. The DTS is further extended into the future by cloning the first cDT to form a cDT 508 at t0 + ΔT2 (this cDT 508 is driven by the synthesized data stream 509 and possibly context data offset by ΔT2). In this way, the second cDT 508 has the same state as the first clone, which is then adjusted for ΔT2.

[0089] Clones can be constructed in one of two ways: Through full replication, where each clone acts as an independent entity that holds copies of the dynamic and static state. This has the advantage of being simple to code and allows for changes to the configuration over time (e.g., adding and / or removing processing nodes that represent individual objects). Clones may be created as additional processes / services within the base digital twin. This has additional coding complexity as incoming data must be processed by the correct time-advanced instance and dynamic state must be isolated. This technique can be more resource-efficient as static state can be shared among all instances (clones). See below for further discussion of this cloning method.

[0090] Most streaming systems have mechanisms to preserve non-volatile state in case of computer failure, or for some platforms to facilitate upgrades. State recovery is designed to be efficient. Cloning to create a new sequence may begin by copying the saved state of the sDT to initialize the first cDT. The output from this can be used to initialize the next clone in the time sequence, and so on.

[0091] Figure 6 illustrates this process. 601 is a digital twin as part of a DTS. As part of good management practice, the continuous execution of the computer program that runs the digital twin is ensured by taking periodic copies of the program's state and saving those copies in some form of non-volatile storage. For a system like Dracena, the program state consists of all of the state values ​​of all objects in the digital twin and the computer code used to model the system (602). In the event of a failure, the execution of the digital twin can be resumed by restoring the saved state to the execution hardware (603). The same mechanism is available for all digital twins in the sequence (604, 605, 606).

[0092] Execution capacity (hardware and supporting software, e.g., Flink) is allocated for the new clone to extend the DTS by ΔT. Execution of the new clone begins by restoring (607) a saved copy of the state at t onto the newly allocated hardware and software. This initializes both the computational and object states of the digital twin (604) at t + ΔT to those of 603, i.e., those at time t. In parallel with the initialization of 604, a new data stream composer (608) is created and attached to the output of 603. This allows the data streams in 604 to move the clone from time t to time t + ΔT as needed.

[0093] It should be noted that the program state save and restore mechanism can use a variety of techniques.

[0094] Exploratory Digital Twin

[0095] Pipeline digital twins, introduced above and constituting the subject matter of related European Patent Application No. 20202133.3, follow the expected path of development of their physical systems. Interventions are often required to ensure the best possible development path is followed, and the consequences of actions must be evaluated before they are implemented. The enhancements to pipeline digital twins described herein enable this by creating exploratory digital twins (eDTs) from the pipeline. eDTs simulate the pipeline digital twin sequence and different physical system states depending on the results of actions, potentially evolving much faster than real time.

[0096] As mentioned above, an advantage of pipeline digital twin techniques is that they can be easily adapted to provide new types of services. Proactively managing transportation systems requires responding to unusual incidents (e.g., traffic accidents) that require operators to develop responses that will have the most impact (or least harm) on the broader system. While digital twins of systems evolve to predict the impact of incidents, the inventors recognized that it would be advantageous if they could also predict the impact of one or more actions that can be taken in response to an incident (e.g., rerouting traffic, closing roads, rephasing signals, etc.).

[0097] Figure 7 is a flow diagram of a method for predicting the evolution of simulation results for an Internet of Things (IoT) network, according to a general embodiment. Step S2 creates a source digital twin for the IoT network. The source digital twin is driven by real-time sensory data from objects, which feeds into models of the objects. The objects are interconnected as object nodes in a DAG. In the DAG, the interconnections represent the flow of data. The source digital twin outputs the state of one or more of the objects in real time.

[0098] Optionally, if the eDT "branches" from the cDT rather than from the sDT, a main DTS (or, equivalently, a pipeline DTS) is formed before creating the eDT. Step S4 creates one or more cDTs from the sDT (or previous cDT). Each cDT contains the same model and interconnections as the sDT. Step S6 connects the input of the first cDT to the output of the sDT. This connection is through a data stream combiner node, which adds a time increment to the output of the sDT. In this way, the sDT drives the first cDT of the DTS at future increments of time. If there are multiple cDTs in the DTS, step S8 connects the input of any further cDT to the output of the preceding cDT in the sequence. This connection is through another data stream combiner node (i.e., a separate data stream combiner to the data stream combiner from S6), which adds another time increment to the output of the preceding cDT. In this way, the preceding cDT drives further cDTs at further increments of time, thereby "evolving" the DTS.

[0099] Step S10 creates an eDT, which contains the same models and interconnections as the sDT (and therefore any cDT).

[0100] Step S12 connects the inputs of the eDT to the outputs of the digital twin that hold the state where it is desired to investigate the potential effects of actions, i.e., the inputs of the eDT are connected to the outputs of the sDT or, if present, to any cDT. In this way, the eDT is initialized.

[0101] S14 modifies aspects of the eDT to simulate actions to be taken in one or more states of one or more objects of the digital twin from which the eDT is created.

[0102] S16 connects the output of the eDT to the input of the eDT. This connection loop is via an additional data stream combiner node (i.e., in addition to the data stream combiner used in S6), which adds additional time increments to the output (and corresponding input) of the eDT. In this way, the eDT drives itself with additional increments of time.

[0103] S18 executes the digital twin. The sDT and, if created, any cDT are executed. The eDT executes outputting the evolved modified state of one or more of the objects at additional time increments. Of course, executing the sDT models the evolution of the system over time increments (in the absence of actions).

[0104] It is advantageous to know the impact of an action as early as possible. For example, it is advantageous to know that a road closure will have the desired impact 30 minutes in the future. Therefore, exploratory simulations can be run faster than real time (each eDT clone maintains a constant simulated time offset relative to its base sDT or cDT) rather than running the cDT at a constant offset relative to actual time (as is done in pipelined DTS). This also means that there is no need to maintain multiple instances of the eDT for a particular action.

[0105] Figure 8 shows an example eDT cloned from an sDT. The sDT may be a digital twin at the beginning of a pipeline DTS 801 (note that the cDT, interconnects, and data stream synthesizers of such a pipeline DTS are not shown here). The sDT state is cloned, and the eDT resulting from the cloning process contains the same models and interconnects as the sDT at the initial time (t0) before the addition of any time increments. In this way, the eDT may be said to require a starting state, which may also be the sDT.

[0106] Actions 802 are applied to the cloned sDT to simulate and explore the effects of the actions. For example, applying action 802 may be realized by modifying the nodes and / or interconnections underlying the cloned sDT at time t0, or by modifying the state values ​​of one or more objects in the cloned sDT. The resulting digital twin (after cloning and applying the action) is the eDT 803. For example, in the context of a transportation system, action 802 could be to reroute a bus around a road block. Typically, a data stream synthesizer moves the bus along its scheduled route. To apply the "reroute action," the bus route may be updated directly in the eDT (only) along with the diversion.

[0107] The eDT 803 is driven by context data (not shown) and a data stream synthesizer 804, which uses the output of the eDT to generate a synthetic data stream. The output of the data stream synthesizer 804 is fed back into the eDT 803. In this way, the eDT 803 can evolve and the effects of actions on the state of the sDT can be explored. Data from the physical world, including the effects of actions, drives the eDT model of the real system and its evolution.

[0108] Note that the pipeline DTS may continue to run normally (in parallel) while the eDT is running. The eDT, which is running a simulation in response to an action, may use a different time offset than that used by the pipeline DTS.

[0109] Figure 9 shows another example of an eDT. This eDT is cloned from the (initial) cDT in the pipeline DTS 901, where cDT1 is cloned, and the resulting eDT from the cloning process contains the same models and interconnections as cDT1 at time t1. Actions 902 are applied to the cloned cDT1, and the resulting digital twin (after cloning and application of actions) is eDT 903, driven by a data stream synthesizer 904.

[0110] Of course, this illustrated example is similar to the example shown in FIG. 8 and described above, except that the eDT is cloned from the cDT rather than from the sDT. As noted above, the eDT is said to require a starting state, which in this case may be the cDT relative to the time the action is applied. That is, if the action is to be implemented in 10 minutes, the method starts the eDT from the cDT, which will be executed in the nearest 10 minutes in the future.

[0111] In this illustrated example, a comparison may be made of how the state of the pipeline DTS would later evolve if no action was taken (e.g., using cDT2) and how the implied pipeline DTS would evolve if action was taken (e.g., using eDT).

[0112] The effects of multiple actions may be explored simultaneously by creating multiple eDTs initialized with different action data and / or at different times. For example, Figure 10 shows how multiple eDTs extend a pipeline DTS (the main DTS, "mDTS"). The pipeline DTS 1001 continues to run normally while simultaneously maintaining many cDTs so that it can provide the necessary update services. The effects of actions 1002 and 1003 may be explored by creating new clones from the DTS at the time the actions are intended to be applied (e.g., the time when knowledge of the action's effect is desired). In this example, this results in two independently executing clones (eDT and eDT'; 1004 and 1005).

[0113] Note the difference between the source of the driving event stream between the pipeline DTS 1001 and the eDTs 1004, 1005. In the former case, it is a different cDT instance, while in the eDT case, it is the same eDT.

[0114] Figure 11 shows an example eDT. The eDT may include a single cDT 1101 initialized (cloned) from the state of a pipeline DTS at the time of action 1102. The eDT may be driven by context data 1103 and a synthetic data stream 1104, as in a pipeline digital twin. The synthetic data stream may be created by a previous iteration of the cDT / eDT; this is in contrast to a pipeline DTS, where the synthetic data stream may be created by an independently executed / executed cDT (or sDT, e.g., see Figure 3).

[0115] Figure 12 shows the "lifecycle" of an eDT within a DTS, which is different from a cDT within a (pipeline) DTS. An eDT is created and initialized by taking a copy of the state of the DTS (cDT or sDT) (1201). Execution of the eDT may begin by modifying the copy of the state to reflect the effects of proposed actions (1202).

[0116] The eDT can then enter a cycle state, where the rate is driven by the speed of processing. For example, the eDT can cycle through state evolution at a rate much faster than the actual evolution of the simulated system, limited only by available processing power. This contrasts with a pipelined DTS, which typically keeps pace with real time. The cycle involves two types of processing: analytical services (1203) at time t and synthetic services (1204) at times t to t + Δt. For example, analytical services can be services derived from the digital twin state and provided to users (as opposed to synthetic services that advance time steps). The exact services provided by analytical services depend on the application, but by way of example, analytical services may assess service quality (e.g., bus punctuality, occupancy levels) or detect problems (e.g., a bus off route). These analytical services provide business value and are the reason for running the system.

[0117] Once the results of the actions have been analyzed, the execution of eDT is terminated (1205). Termination may occur, for example, when a system operator determines that the simulation has progressed sufficiently to evaluate the effects of the actions. This depends on the situation in question; eDT may also be stopped by an external action (an operator terminating eDT).

[0118] The eDT advances in time, for example, from a time labeled "t" to a time labeled "t+Δt." It uses the state of the eDT at "t" to drive a data stream synthesizer whose output is sent back to the eDT in the same stream as the actual sensor data arrives (the sDT input is the data stream generated by the actual sensors, and the cDT and eDT inputs come from computations that are presented to them as synthetic data, just as they come from the actual sensors). For the duration of the eDT, there is only one copy of the eDT's state (this contrasts with a cDT or sDT from a pipelined DTS, where multiple copies of the state may exist simultaneously). Also, the eDT has (or may be represented as) a single copy of the model (computer code) and occupies a single instance of computational resources; this simplifies the complexity of maintaining a digital twin (single instance) and may also reduce its resource consumption and cost.

[0119] Multiple eDTs may run during the life of a DTS. An eDT runs concurrently with each / associated DTS, and multiple eDTs may run simultaneously. Each eDT instance incurs startup overhead, which impacts computational cost (as initialization can take processing time) and response time. The overhead includes obtaining and allocating computational resources and network time to copy the initial state from the DTS to the new eDT instance.

[0120] cDT and eDT cloning

[0121] As mentioned above, clones (DTs) may be created as additional processes / services within the underlying digital twin.

[0122] Note that the computer code (Twin Model Code, or TMC) that models the physical system may be identical for all cDTs, including those on a pipeline DTS and those created for eDTs. The difference between these two instances (cDTs and eDTs) is the state in which the code operates. A naive way to implement a DTS is to run each DT on a different resource (computer). This has the cost disadvantage and the time it takes to copy state between computers (as well as the overhead of obtaining and allocating resources). To reduce the impact of initialization overhead, a single instance of the model computer code can be run and switched between different states, for example, according to an identification tag in the input synthetic data stream. The identification tag can indicate the time of the input data and the digital twin (e.g., sDT, cDT, or eDT on a pipeline DTS) to which it applies. This approach overcomes the cost and time disadvantages of naive cloning methods by running the entire sequence on a single resource (or set of resources). This is because the computer code may be the same for all DTs in the sequence.

[0123] At a low level, switching between states is nothing more than an address into computer memory, which is the source of efficiency. As a higher level example, consider the number of people on a bus. For example, in the sDT case, the number of people might be 25 and stored in location A. In the initial cDT case, some passengers get off and the number of people stored in location B is 20. The service that evaluates the load will provide values ​​for sDT times with reference to location A and values ​​for cDT times with reference to location B, but the computer code remains the same.

[0124] Data synthesizers are typically stateless, i.e., they can operate purely on their input data and do not need to reference data stored elsewhere to be preserved between execution times.

[0125] Figure 13 shows an example of this cloning process, reducing the impact of initialization overhead. In this example, there are many different versions of modeled states (1301-1306), including four states of the cDT (1301-1304) and two states of the eDT (1305-1306) on the DTS. The eDT state in the state collection (database) is copied from the DT used to initialize the eDT and may be modified by any applied actions. For the sDT and cDT states in the collection, there may be special processing to calculate values ​​(e.g., to account for time advancement).

[0126] The TMC (1307) receives a tagged message (1308) for a portion of the pipeline DTS (either from the actual sensor or the data stream synthesizer). In this example, the message indicates that the state of interest is a sensor in cDT2 within the DTS. The message is processed, and the TMC interacts with (gets from) the tagged state (1302). The result of this processing (1310) is passed to all external consumers of the (analytic) service, including the synthesizer (1309) in this example. The synthesizer then advances and tags the next digital twin of interest for the next stage of the DTS. In this example, the next state of interest is the state of cDT3. In this case, the consumer (synthesizer) moves the state from time t1 to time t2 and synthesizes the inputs of the cDT operating at t2. The tag can be a value attached to the data, for example, a name that can be "cDT3" and "cDT4" as shown in Figures 13 and 14.

[0127] Figure 14 illustrates the next stage in this cloning process, reducing the impact of initialization overhead. The combiner (1409) advances input data, which is tagged to cDT3 (1408) (as described above). The TMC now interacts with the (tagged) state of cDT3 (1403). Similar to what was described above for Figure 13, the combiner receives the results of cDT3 and tags cDT4 as the next digital twin of interest. In this way, the TMC may selectively switch between (pre-stored) states of the digital twin. There is no need to create a new TMC instance for each individual state of the pipeline DTS and / or any eDT; instead, a single TMC instance selectively "pull" the state information needed for processing into the TMC instance.

[0128] In these examples, state messaging and synthetic data can be performed by a message broker service, e.g., Apache Kafka. Of course, alternatives such as RabbitMQ may also be used. Such message broker systems are often built around a "Pub / Sub" model, in which message producers send (submit) data to named topics, and message consumers receive messages related to them by subscribing to the appropriate topics (see, e.g., https: / / cloud.google.com / pubsub / docs).

[0129] Here, a "topic" may refer to a named resource to which messages are sent by publishers. A "subscription" may refer to a named resource representing a stream of messages from a single specific topic that is made available to subscribing applications. A "message" may refer to a combination of data and (optional) attributes that a publisher sends to a topic and that is ultimately made available to a subscriber.

[0130] In these examples, data streams may be tagged using the concept of topics. The TMC may subscribe to all synthesized data stream topics and use the topic names to process the correct state. If the state is on a pipeline DTS, the TMC sends that (processed) state to the topic named after the next cDT in the sequence. If the processed state is for an eDT, the TMC sends the state on the eDT's topic. The data synthesizer listens to all topics and sends on the topic related to the topic of the input data and the source of the data.

[0131] Example

[0132] Public transport networks for buses (and rail, tram, and water vehicles) are currently managed rigidly, with buses operating on fixed routes and according to fixed timetables. Fluctuations in real-world conditions (traffic volume, boarding and alighting rates) mean that the service provided can be irregular, and vehicles throughout the system can vary from empty to overloaded. Some public transport authorities are able to manage some aspects dynamically, for example by adjusting the spacing between buses in real time. A better level of service can be provided by allocating resources fully dynamically and anticipating service problems before they occur.

[0133] The pipeline DTS described herein forms the basis of a dynamic bus management system, providing a source of truth regarding the current status of buses and the quality of service they provide. Buses are equipped with real-time status reporting systems, such as location and speed. These data are combined with other data sources, such as road traffic conditions. The same scenario applies to trams, railroads, ferries, and other public transportation networks.

[0134] The sDT and all cDTs contain the following individual twin types (or nodes such as A, B and C in Figures 1 and 2):

[0135] Incident: These nodes reflect things that can happen in the wider environment that can affect the provision of bus services. One type of incident is the blocking of a section of road due to reasons such as a traffic accident, road works, or utility problems. A blocked road incident notification is generated depending on the actual management application and the location of the blocked area and the expected clearing time. Another type of incident could be the narrowing of a section of road due to the same problem. Alternatively, an incident could be the end of an event (concert), which means many people are trying to go home from the same bus stop at the same time.

[0136] An event from the real world triggers an incident to become active. In sDT, an incident becomes inactive when it is notified by the actual management application, and in cDT, an incident becomes inactive when the expected resolution time has passed or by cascaded resolution notification.

[0137] An incident notifies potentially affected stops of any changes in their state (such as the start, end, and location of the incident).

[0138] To minimize the number of messages passed between incidents and stops, stops have bounding boxes computed. The stop route position is converted to coordinates and the maximum and minimum of these are computed to form a bounding box, which is sent to the incident when it starts. The use of false easting and northing for this purpose is known (see https: / / en.wikipedia.org / wiki / Easting_and_northing), but of course any coordinate system such as latitude and longitude will suffice. Bounding boxes may overlap, especially if the stop route is winding. An incident only propagates state changes to stops whose bounding boxes contain it.

[0139] Stop: A stop represents a bus stop and the part of the road network that connects it to the next stop on the route. A stop maintains a view of the state of the actual road network that it represents, especially when the network is blocked. A stop also maintains a view of the operations that use it, if an incident affecting the stop (i.e., an incident that is within its bounding box) notifies the operation of the incident.

[0140] Run: A bus route has several runs. A run is the actual track that the buses are scheduled to follow. Runs can be different directions of a route. The run twin object maintains the actual path that the buses on the run should follow and updates the buses on the run with any changes. Input data arrives from the appropriate data stream (501 or 506, 509) and signals the actual bus start and bus exit points on the run (the data is a bus identifier initially generated by the (actual) bus). Changes to the run are received from the stop twin. These changes are stop names, end stop names, and directions (GPS position and instructions) that the bus must follow to reach the end stop. The run twin distributes these changes to the bus twins that are registered as being on the run. The run twin also receives notifications of changes to incidents (as positions) and generates reroute requests for buses to route appropriately around incidents.

[0141] Bus: A twin of a vehicle on the road operating on a journey. This twin receives position (meters, false easting, false northing) and speed data (meters per second) from the appropriate data stream (501 or 506, 509). This twin also maintains the current route of the bus (the route, e.g., created by a route discovery application, and the directions and list of stops that the driver must follow). The route can be dynamically updated by other twins in the sDT or cDT, such as the journey twin, in response to incidents. The reported position is matched with the current route to ensure the driver is following the correct route. Changes to the route are sent to the actual bus using an interface to the Kafka messaging service in Dracena to enable dynamic routing.

[0142] The digital twins within the DTS pipeline are linked by data flows.

[0143] Routes (Paths): When a bus route changes in response to an incident-induced rerouting generated in the cDT, the bus route is propagated to the CDT later in the chain without modification by the data stream combiner. Planned incidents such as road works can be inserted into the cDT or sDT.

[0144] Bus position: Each bus digital twin holds the instantaneous value of the bus's position at the (simulation) time of that digital twin. The data stream synthesizer advances this position by a time increment for subsequent cDTs using the traffic-condition-dependent speed sent via the context source and the bus's current route (received from the previous digital twin).

[0145] Incident development: State changes proceed along the DTS and the state of the incident in the cDT depends on the simulation time of the cDT.

[0146] The structure of the DTS, built from the above-mentioned sDT and cDT, depends on the operator's requirements and the expected accuracy of the predictions embedded in the chain (this accuracy depends on the accuracy of input data such as passenger and traffic predictions). The time increment between cDTs is related to the variability of these external data sources; typically, the interval is 5 minutes when three cDTs are run in parallel.

[0147] Figures 15 and 16 show a simplified structure for this system. Figure 15 shows instantiations of some of the object types mentioned above, as well as some of the data flow. Note that the message flow is directional and the connections form a DAG with no cycles. The order of the nodes is "incident", "stop", "trip", and "bus". Three incidents affect three different stops. Two of the stops have blocked roads, which leads to rerouting on two trips, with three buses on each of those two trips following new routes.

[0148] Figure 16 shows the additional flows needed to connect digital twins into a sequence (the data flows from Figure 15 are still valid, but not all are shown). Here, the clone receives the position from the previous synthesizer, the new route from the previous digital twin (source or clone), and the incident state from the previous digital twin. Thus, the modeling effect can be a predicted change in the routing of public transport vehicles. This may have the further consequence of providing an alert to the system operator or user, for example, using a display on the GUI (or app) or simply using an audible alert.

[0149] eDT may be used to investigate the impact of actions that may be taken in response to an incident, for example in a public transport DTS.

[0150] As can be seen in Figure 9, the eDT is similar to the cDT component of the Pipeline DTS, albeit running in a different environment. Therefore, the internal structure of the eDT is the same as that discussed in related European Patent Application No. 20202133.3 and discussed above. Below we describe how the eDT fits into a high-level example application.

[0151] A pipeline DTS may be created to monitor the provision of bus services for a public transport system. Services in the cDT may include evaluation of bus operation key performance indicators such as waiting times at stops.

[0152] A service running on the cDT may notify the operator that road traffic conditions may lead to road closures that affect the operation of the service.

[0153] The operator may decide that the solution is to divert buses on the service and prepare multiple possible diversions on different routes.

[0154] The eDT can be executed to evaluate the implications of each detour. A new cDT state is created for each detour as a copy of the pipeline DTS cDT that is closest to the expected time of the detour's application. The tagged data stream can then be sent to the synthesizer to initiate eDT execution.

[0155] eDT evaluates KPIs included in Pipelined DTS operations over time.

[0156] Based on a comparison of KPIs for implementing multiple eDTs (i.e., various eDTs performed at different times and / or different actions (e.g., different possible detours on different routes)), the best detour is implemented.

[0157] In this way, eDT can flexibly adapt to problems in public transport systems such as overcrowding, non-operating services, road blockages, etc. eDT may be used to dynamically reallocate resources to alleviate these problems by identifying and evaluating the optimal choice of actions to take.

[0158] Other uses Other areas of application include: Highway traffic management. Keeping traffic flowing well is important for driver experience, delivery reliability, and increased capacity on the network. Operators may have many management strategies to mitigate the impact of an incident on the network, such as setting variable speed limits, diverting traffic, closing one or more lanes, or controlling participating traffic. Each of these options has a different impact on the incident and the wider road network, which is assessed using eDT. Smart cities manage the flow of people and goods through a city by monitoring conditions, dynamically allocating transportation resources, and adjusting priorities (traffic signals). DTS is used to proactively anticipate problems such as congestion and irregular service. eDT may be used to assess the impact of various different actions taken in response to these problems. An electricity network that ensures a balanced power supply over a wide area, where electricity generation includes contributions from many distributed small units (such as domestic solar panels or wind turbines). The time evolution of renewable electricity generation is driven by external data sources (context 502 - weather forecast, day / night cycle). The overall network state is also determined by the availability of storage facilities, batteries, hydroelectric power, etc., and its evolution is modeled by a data stream synthesizer. eDT may be used, for example, to manage and assess the impact of unexpected power source outages.

[0159] overview

[0160] This methodology enhances the power and utility of digital twins of Smart IoT-driven systems, which can be characterized as complex networks of dynamically interacting objects. eDT offers the ability to provide insight into the future evolution of a simulated modeled system after the application of any action to the system.

[0161] Complementing eDT, DTS enables the active management of the corresponding physical systems, resulting in, for example, more efficient and less polluting transport networks.

[0162] eDT enables fast and flexible scenario testing: many explorations can be run simultaneously across different scenarios, allowing for example to identify the optimal action to take in response to an incident in the system.

[0163] By providing prognosis of the effects of actions on physical systems, the use of eDT provides better control of complex systems.

[0164] The benefits of eDT are seen in the area of ​​managing systems, where digital twins are an avatar. DTS without eDT allows for early detection of problems in the underlying system by continuously updating twins of current and near-future states. However, if problems are detected in these future states, system managers must develop responses to mitigate the impact of the problem. The techniques discussed herein allow for testing options before implementation, faster than real time, by reusing continuously updating twin implementations to create exploratory simulations.

[0165] The techniques discussed herein extend previous methods, enabling faster than real-time exploratory simulation of the consequences of management actions by reusing infrastructure for continuous monitoring through a pipeline digital twin.

[0166] Techniques were discussed that extend current digital twin cloning methods to include alternative implementation methods. These techniques can be used to create a model of the system's future state by cloning the current-state model and drive the evolution of the clone by replacing the actual data stream with a synthesized data stream. An extended cloning technique was identified that minimizes the impact of initialization overhead; that is, only a single instance of the model computer code (running either the cDT or eDT) is required by selectively switching between stored states.

[0167] 10 is a block diagram of a computing device, such as a data storage server, that may be used to implement the method of modeling with a source digital twin, an exploratory digital twin, and optionally one or more clone digital twins (DTs) embodying the present invention. The computing device includes a processor 993 and memory 994. Optionally, the computing device also includes a network interface 997 for communication with other computing devices, such as other computing devices of the invention embodiments. The computing device may implement one of the aforementioned platforms, such as Dracena.

[0168] For example, an embodiment may consist of a network of such computing devices. Optionally, the computing devices also include one or more input mechanisms, such as a keyboard and mouse 996, and one or more display units, such as a monitor 995. The components may be connected to one another via a bus 992.

[0169] The memory 994 may include a computer-readable medium. Computer-readable medium is a term that may refer to a single medium or multiple media (e.g., centralized or distributed databases and / or associated caches and servers) configured to carry computer-executable instructions or store data structures. Computer-executable instructions may include, for example, instructions and data that can be accessed by a general-purpose computer, a special-purpose computer, or a special-purpose processing device (e.g., one or more processors) to cause the device to perform one or more functions or operations. Thus, the term "computer-readable storage medium" may include any medium that can store, encode, or carry a set of instructions for execution by a machine, causing the machine to perform any one or more of the methods disclosed herein. Thus, the term "computer-readable storage medium" includes, but is not limited to, solid-state memory, optical media, and magnetic media. By way of example and not limitation, such computer-readable media may include non-transitory computer-readable storage media including random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid-state memory devices).

[0170] The processor 993 is configured to control the computing device and execute processing operations, such as executable code stored in memory, to implement various different functions described herein. For example, the processor may perform steps to execute models of digital twins and exploratory digital twins. Additionally or alternatively, the processor may perform steps to create an exploratory digital twin or add incidents, as described in the examples.

[0171] The memory 994 stores data read and written by the processor 993 and may include, for example, any databases mentioned herein or may simply store parameters for a model, such as the position and velocity of an object being modeled. As referred to herein, a processor may include one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. The processor may include a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or combinations of instruction sets. The processor may also include one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. In one or more embodiments, the processor is configured to execute instructions to perform the operations and steps discussed herein.

[0172] The display unit 995 may display representations of data stored by the computing device and may also display cursors and dialog boxes and screens that enable interaction between a user and programs and data stored on the computing device. The input mechanism 996 may allow a user to input data and instructions into the computing device. In one example, the display may be used to show a representation of the DTS (e.g., in graphical form) or a representation of individual eDTs (e.g., as a table of status and / or as inputs and outputs). In another example, the display may show generated vehicle alerts, such as warnings of impending collisions or traffic or bus delays, and the impact of actions determined by the eDTs, such as KPIs for potential diversions.

[0173] The network interface (network I / F) 997 may be connected to a network such as the Internet and can be connected to other such computing devices via the network, allowing the computing device to access a database as needed and obtain real-time data for building / updating a digital twin. The network I / F 997 can control data input and output with other devices via the network. Other peripheral devices such as a microphone, speaker, printer, power supply unit, fan, case, etc. may also be included in the computing device.

[0174] Methods embodying the present invention may be performed on a computing device such as that shown in Figure 17. Such a computing device need not have all of the components shown in Figure 10, but may consist of a subset of those components. Methods embodying the present invention may be performed by a single computing device in communication with one or more data storage servers over a network. The computing device may also be the data storage device itself, which stores the modeling data.

[0175] Methods embodying the present invention may be performed by a plurality of computing devices and / or IoT objects operating in cooperation with one another, wherein one or more of the computing devices may be a data storage server that stores at least a portion of the modeling data for a digital twin.

[0176] The present disclosure includes the following inventions. (Appendix 1) 1. A method for predicting the evolution of simulation results for an Internet of Things (IoT) network, comprising: creating a source digital twin for the IoT network driven by real-time sensory data from the objects fed into a model of the objects, the source digital twin outputting object states of one or more of the objects in real time; Optionally, creating one or more additional clone digital twins, each containing the same models and interconnections as the source digital twin; connecting the input of a first clone digital twin with the output of the source digital twin through a data stream combiner node, the data stream combiner node adding a time increment to the output of the source digital twin so that the source digital twin drives the first clone digital twin at the incremented time; connecting the input of the further clone digital twin with the output of the preceding clone digital twin in the sequence via a further data stream combiner node, the further data stream combiner node adding a further time increment to the output of the preceding clone digital twin, such that the preceding clone digital twin drives the further clone digital twin at the further time increment, forming a master digital twin sequence; creating an exploratory digital twin that contains the same models and interconnections as the source digital twin; initializing the exploratory digital twin by connecting inputs of the exploratory digital twin with outputs of the source digital twin, the first clone digital twin, and any further clone digital twins; Modifying aspects of the exploratory digital twin to simulate actions taken in the exploratory digital twin; connecting an output of the exploratory digital twin with an input of the exploratory digital twin through an additional data stream combiner node, the additional data stream combiner node adding additional time increments to the output of the exploratory digital twin to drive the exploratory digital twin at the additional time increments; executing the source digital twin, any clone digital twin, and the exploratory digital twin to provide an evolved modified state of one or more of the objects at the additional incremental times as an output of the exploratory digital twin. (Appendix 2) The models of objects in the source digital twin are interconnected as object nodes in a directed acyclic graph (DAG), where the interconnections represent the flow of data; The source digital twin also includes event nodes that model events that affect the IoT network, such as incidents that affect the state of the object; and / or 2. The method of claim 1, wherein the source digital twin also includes a system information node that models information about the IoT network. (Appendix 3) models of objects in the source digital twin are interconnected as object nodes in a directed acyclic graph (DAG) with interconnections representing data flow, the method further comprising generating a service node as part of the overall DAG with an output of the source digital twin and / or an output of the exploratory digital twin and / or an output of any clone digital twin, the service node generating a data service based on the state of objects in the IoT network; Optionally, the service node is provided in parallel with the data stream combiner in the source digital twin and / or the additional data stream combiner in the exploratory digital twin, and further comprises providing an output of the source digital twin to both the service node and the data stream combiner, and / or providing an output of the exploratory digital twin to both the service node and the additional data stream combiner. (Appendix 4) creating a further exploratory digital twin that contains the same models and interconnections as said source digital twin; and initializing the further exploratory digital twin by connecting inputs of the further exploratory digital twin with outputs of the source digital twin, the first clone digital twin, and any further clone digital twins; Modifying aspects of the further exploratory digital twin to simulate actions taken in the second exploratory digital twin; connecting an output of the further exploratory digital twin to an input of the further exploratory digital twin via another additional data stream combiner node, the another additional data stream combiner node adding another additional time increment to the output of the further exploratory digital twin, such that the further exploratory digital twin drives the further exploratory digital twin at the another additional time increment; executing the further exploratory digital twin to provide, as an output of the further exploratory digital twin, an evolved state of one or more of the objects at the further additional incremental time; Comparing an output of the exploratory digital twin with an output of the further exploratory digital twin. (Appendix 5) the inputs of the further exploratory digital twin are connected to the same outputs as the inputs of the exploratory digital twin; 5. The method of claim 4, wherein the actions taken in the further exploratory digital twin are different from the actions taken in the exploratory digital twin. (Appendix 6) The inputs of the further exploratory digital twin are connected to different outputs than the inputs of the exploratory digital twin, preferably 5. The method of claim 4, wherein the actions on the further exploratory digital twin are the same as the actions taken on the exploratory digital twin. (Appendix 7) 7. The method of any one of clauses 1 to 6, wherein contextual information from an external data source is additionally input into the source digital twin and / or any exploratory digital twins and / or any clone digital twins. (Appendix 8) 8. The method of any one of clauses 1 to 7, wherein executing any exploratory digital twin includes repeatedly executing to provide, as output of the exploratory digital twin, multiple evolved modified states of one or more of the objects at repeated increments of time. (Appendix 9) 9. The method of any one of clauses 1 to 8, wherein executing the source digital twin and any clone digital twins occurs subsequently in real time, and executing any exploratory digital twins occurs sooner than real time. (Appendix 10) creating said exploratory digital twin and, optionally, any clone digital twin; Use of the same code as the source digital twin; and entering a state into the code that corresponds to a current state of the digital twin; Executing said digital twin; and and replacing the current state of the digital twin with a resulting state after execution. (Appendix 11) 11. The method of any one of claims 1 to 10, wherein the IoT network is a transportation network and the object nodes include vehicle nodes and / or one or more infrastructure nodes, including one or more event nodes, such as a traffic incident node. (Appendix 12) 12. The method of any one of claims 1 to 11, wherein the state of one or more of the objects comprises one or more of a position of the object and a velocity of the object. (Appendix 13) 13. The method of claim 11 or 12, wherein the transportation network is a public transport network, and the nodes in the source digital twin and any exploratory digital twin, and optional clone digital twin, include vehicle nodes, incident nodes representing events that may impact the public transport network, stop nodes representing sections of the public transport network infrastructure, and system information nodes representing routes of the vehicles. (Appendix 14) 14. A computer program having instructions which, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 13. (Appendix 15) A computer including a processor and memory and a network interface configured to perform the method of any one of claims 1 to 13. [Explanation of symbols]

[0177] 993 processor 994 memory 995 Display 996 inputs 997 Network I / F

Claims

1. 1. A computer-implemented method for predicting the evolution of simulation results for an Internet of Things (IoT) network, comprising: creating a source digital twin for the IoT network driven by real-time sensory data from objects fed into a model of the objects, the source digital twin relating to a current state of the objects and outputting one or more object states of the objects in real time; creating one or more additional clone digital twins, each associated with a corresponding future state of the object and containing the same model and interconnections as the source digital twin; connecting an input of a first clone digital twin with an output of the source digital twin through a data stream combiner node, the data stream combiner node adding a time increment to the output of the source digital twin so that the source digital twin drives the first clone digital twin at the incremented time; connecting the input of the further clone digital twin with the output of the preceding clone digital twin in the sequence via a further data stream combiner node, the further data stream combiner node adding a further time increment to the output of the preceding clone digital twin, such that the preceding clone digital twin drives the further clone digital twin at the further increment of time, forming a master digital twin sequence; creating an exploratory digital twin that is a clone digital twin that includes the same model and interconnections as the source digital twin and is used to explore the effects of actions on the object; initializing the exploratory digital twin by connecting inputs of the exploratory digital twin with outputs of the source digital twin, the first clone digital twin, and any further clone digital twins; Modifying aspects of the exploratory digital twin to simulate actions taken in the exploratory digital twin; connecting an output of the exploratory digital twin with an input of the exploratory digital twin through an additional data stream combiner node, the additional data stream combiner node adding an additional time increment to the output of the exploratory digital twin to drive the exploratory digital twin at the additional time increment; executing the source digital twin, any clone digital twin, and the exploratory digital twin to provide an evolved modified state of one or more of the objects at the additional incremental times as an output of the exploratory digital twin.

2. models of objects in the source digital twin are interconnected as object nodes in a directed acyclic graph (DAG), the interconnections representing the flow of data; The source digital twin also includes event nodes that model events that affect the IoT network, such as incidents that affect the state of the object; and / or The method of claim 1 , wherein the source digital twin also includes a system information node that models information about the IoT network.

3. models of objects in the source digital twin are interconnected as object nodes in a directed acyclic graph (DAG) with interconnections representing data flow, the method further comprising generating a service node as part of the overall DAG at the output of the source digital twin and / or the output of the exploratory digital twin and / or the output of any clone digital twin, the service node generating a data service based on the state of objects in the IoT network; 3. The method of claim 1, wherein the service node is provided in parallel with the data stream combiner node in the source digital twin and / or the additional data stream combiner node in the exploratory digital twin, and further comprising providing an output of the source digital twin to both the service node and the data stream combiner node, and / or providing an output of the exploratory digital twin to both the service node and the additional data stream combiner node.

4. creating a further exploratory digital twin that includes the same models and interconnections as the source digital twin; initializing the further exploratory digital twin by connecting inputs of the further exploratory digital twin with outputs of the source digital twin, the first clone digital twin, and any further clone digital twins; Modifying aspects of the further exploratory digital twin to simulate actions taken in the further exploratory digital twin; connecting an output of the further exploratory digital twin to an input of the further exploratory digital twin via another additional data stream combiner node, the another additional data stream combiner node adding another additional time increment to the output of the further exploratory digital twin, such that the further exploratory digital twin drives the further exploratory digital twin at the another additional time increment; executing the further exploratory digital twin to provide, as an output of the further exploratory digital twin, an evolved state of one or more of the objects at the further additional increment of time; and comparing an output of the exploratory digital twin with an output of the further exploratory digital twin.

5. the inputs of the further exploratory digital twin are connected to the same outputs as the inputs of the exploratory digital twin; The method of claim 4 , wherein actions taken in the further exploratory digital twin are different from actions taken in the exploratory digital twin.

6. The inputs of the further exploratory digital twin are connected to different outputs than the inputs of the exploratory digital twin, preferably The method of claim 4 , wherein the actions on the further exploratory digital twin are the same as the actions taken on the exploratory digital twin.

7. 7. The method of claim 1, wherein contextual information from external data sources is additionally input to the source digital twin and / or any exploratory digital twins and / or any clone digital twins.

8. 8. The method of any one of claims 1 to 7, wherein executing any exploratory digital twin comprises iteratively executing to provide, as output of the exploratory digital twin, multiple evolving modified states of one or more of the objects at iterative increments of time.

9. 9. The method of claim 1, wherein executing the source digital twin and any clone digital twins occurs subsequently in real time, and executing any exploratory digital twins occurs sooner than real time.

10. Creating the exploratory digital twin and any clone digital twins includes: using the same code as the source digital twin; Entering a state into the code that corresponds to a current state of the digital twin; executing the digital twin; and replacing the current state of the digital twin with a resulting state after execution.

11. The method of claim 2 or 3, wherein the IoT network is a traffic network, and the object nodes include vehicle nodes and / or one or more infrastructure nodes, including one or more event nodes, such as traffic incident nodes.

12. A method according to any preceding claim, wherein the state of one or more of the objects comprises one or more of the position of the object and the velocity of the object.

13. 12. The method of claim 11 , wherein the transportation network is a public transit network, and the nodes in the source digital twin and any exploratory digital twins, and any clone digital twins, include vehicle nodes, incident nodes representing events that may impact the public transit network, stop nodes representing sections of the public transit network, and system information nodes representing vehicle routes.

14. A computer program comprising instructions which, when the computer program is executed by a computer, cause the computer to carry out a method according to any one of claims 1 to 13.

15. A computer comprising a processor and memory and a network interface configured to carry out the method of any one of claims 1 to 13.

Images