Digital Twin is not a new idea.
Already in 2002, talks began about creating digital representations of physical systems that had their own entity.
Currently, in Industry 4.0, the concept of Digital Twin is already a part of the strategy of companies dedicated to innovation and product design.
Digital Twin as Technology Trends
If we pay attention to Gartner, Digital Twin is one of the ten technological trends for 2018:
G2 Digital Trends consider Digital Twin a trend too, outside the industrial scope.
Others are more cautious: Atos, on his Look Out 2020 + Tech Trends Radar, considers that the technology is in a teenage state, although they also consider it transformational.
In any case, they all agree that the concept of Digital Twin is not confined to the industrial sphere (as it was a few years ago) and that it is a transformational technology to be taken into account.
Being aware of this, we will see how the onesait Platform completely supports the Digital Twin concept, allowing for modeling, deployment, simulation and orchestration in a simple and powerful way.
Digital Twin Definition
There are many definitions about Digital Twin:
"A digital twin is a digital representation of a real-world entity or system. In the context of IoT, digital twins are linked to real-world objects and offer information on the state of the counterparts, respond to changes, improve operations and add value. With an estimated 21 billion connected sensors and endpoints by 2020, digital twins will exist for billions of things in the near future. Potentially billions of dollars of savings in maintenance repair and operation (MRO) and optimized IoT asset performance are on the table"
"A digital twin is simply a digital replica of a physical asset, process, system or service across its lifecycle. This virtual representation of the physical world is, in essence, a simulation much akin to the 3D renderings of computer-aided design (CAD) models, asset models and process simulations used by engineers for decades. It uses real-time data to promote understanding, identify problems, develop new opportunities and plan for the future."
"A digital twin is an exact digital replica of a product, process or service. This living model creates a thread between the physical and digital world. Internet of things (IoT)-connected objects are replicated digitally, enabling simulations, testing, modeling and monitoring based on the data collected by IoT sensors. Like everything in the realm of IoT, data is the primary driver, and most invaluable output, of digital twins. The sharing and analysis of digital twin data empowers companies to make decisions, which directly impact their key performance indicators.
We could simplify by saying:
A Digital Twin is a digital representation of a real world entity or system that does not act as a replacement for the physical object of the system it represents, but as a replica of it, allowing the communication (testing, monitoring, control) of this physical device without having to be stuck to it.
We believe that Digital Twin concept makes sense both within the IoT where these "digital twins" are linked to real-world objects and offer information about the state of the Thing, respond to changes, ... and outside IoT, where there is a great potential to link them to entities that are not simply "things", so that in the future digital representations of all aspects of our world will be dynamically connected, and using artificial intelligence-based capabilities will allow advanced simulation, operation and analysis.
Using Digital Twins in a Smart City
A key issue, still to be resolved in the Smart City area, is how to break the silos and build bridges:
A smart and sustainable city that works well requires an orchestration of people, processes, municipal departments, public and private organizations, policies and technologies that work together throughout the smart city ecosystem.
And what if all these entities were represented as Digital Twins? What if the City platform allowed orchestrating these Digital Twins regardless of how their physical representation works?
That is our vision!
On a practical level, using the city platform to model and orchestrate Digital Twins has numerous advantages, including these:
It provides a high-level abstraction on the behavior of a real system: allowing to know its status (how it is currently working), how it interacts with its environment (events that it generates autonomously) and how its environment affects it (actions that the environment can request to the system).
It allows treating each solution homogeneously in a heterogeneous environment of vertical applications.
It allows pooling and giving meaning to the information (state, actions, events ...) of the different Digital Twins (Vertical systems), throughout the joint analysis of the information that they generate separately.
Orchestrate different systems: Having a real-time representation of the different verticals on a platform allows you to compose rules that add information from different sources to trigger actions in the different vertical systems affected.
Simulate scenarios: It is not necessary to have the physical system underlying one or several Digital Twins, to check the general behavior under certain circumstances. If one or more systems are simulated respecting in their Digital Twin the interface that the real physical system has, you can check how it responds integrated with the other systems in the city.
Incremental implementation of vertical systems: The integration of verticals is a complex task both in the development phase and in the implementation. By modeling with Digital Twins, the interface of each system is known by the other systems from the beginning and it is not necessary to integrate systems in a P2P mode, but rather each system is integrated with the platform, and the platform performs the orchestration.
How does the platform support the Digital Twin concept?
The platform offers a complete support to the concept of Digital Twins, this is:
Modeling of a Digital Twin from the ControlPanel of the Platform: a user can define with precision the interface (inputs, outputs and status) of a Digital Twin. Modeling allows for the use of the semantics included in the platform (inputs, outputs and status can also be ontologies).
Simulation of the Digital Twin: so that it can test the DT's behavior, allowing for the use of the platform's IA modules.
Implementation of the Digital Twin: once the DT is modeled, the platform is able to generate code in different languages to implement the functionality required for the use of the DT in operation.
State of the Digital Twin: our Digital Twins are connected to the Platform in a secure way, and the platform has a Shadow of its state.
Digital Twins Orchestration: once modeled, implemented and running, the platform allows you to visually build an orchestration of Digital Twins, so that the output of one Digital Twin can be mapped with the input of another so that one reacts to changes in status of the other.
Example of Digital Twins application in the Smart City Field
Now we will see how to use the capabilities of the platform to build a complete city system where each vertical is modeled as a Digital Twin and the UI aggregator of all the information generated by the verticals is in turn a Digital Twin.
Vertical Environment Digital Twin Modeling
Let's see, for example, how to model the Vertical Environment with the capabilities of the platform. This way, having a clear interface with inputs, outputs and status in the future could replace my Digital Twin with another from a different company as long as it meets this interface or even simulate a vertical with a DT Simulation.
From the DIGITAL TWIN menu select Digital Twin Definitions:
I will model my Vertical Environment this way:
To model my Digital Twin I will define:
- Properties of the Digital Twin (in the example air quality, noise, allergen level and meteorological information).
Actions that I can perform on my Digital Twin (simulate poor air quality, receive meteorological information, allergen information, air quality).
Events generated by the Digital Twin, in this case simply update the status of the DT (shadow).
In this example, as seen in the following steps, the DT receives this information from other external systems and therefore an entry of air information, allergens...
Digital Twin simulation
The platform allows me to:
Indicate that the logic of my Digital Twin is solved by a Notebook that has been trained via an AI algorithm (for example the LRU of an engine life).
Digital Twin implementation
From the menu option
I will create an instance of the definition (modeling) of my Digital Twin. As I said before, I can have different instances in execution of a Digital Twin depending on the use we want to give it, either by simulation, or because we want to test a new vertical of another company.
The platform guides me in the instantiation of a Digital Twin, indicating the connection parameters (including Token) of the Digital Twin instance with the platform:
Finally, I will select Generate the Digital Twin code. In my case, I will select the Spring Boot Project with Maven:
This generated code already includes a structure of the necessary code including the connection to the platform, so that you only have to fill in a set of methods to operate the Digital Twin.
Digital Twin status
As we said, the platform maintains the Shadow (mirror state) of each Digital Twin connected to it.
This status is represented as an ontology, meaning that the owner of a Digital Twin can build rules as the DT Status is updated on the platform. The owner can also represent this information in a dashboard.
Digital Twin Orchestration
In addition to all that, the platform allows for visual orchestration of the interaction between different DTs.
To achieve this, the Digital Twins of the platform will send all the events that propagate to the platform automatically so that the platform is able to route the outputs of one Digital Twin to the inputs of another and establish rules between the DTs.
To be able to orchestrate my Digital Twins, just open the My Flows option and enter my domain.
In this diagram we see:
The components of the platform to manage Digital Twins.
A basic flow that sends meteorological data every 24 hours (from an OpenData source) to the Digital Twin.
An instantiation of DigitalTwin on the platform.
If I click on the DT component, I will see the properties of the DT:
Let's see an example of more interesting orchestration:
The figure shows how the output of the environment DT generates a status event that is sent to a node
, which in itself is a subnode and that decomposes in:
This flow evaluates whether the quality of the air is in correct limits or, alternatively, an alert must be generated.
If the rules indicate that an alert should be generated, the Digital Twin CLM will be notified. It will represent the alert in its UI and will generate an alarm. The component
is again a subflow that is decomposed in:
and inserts the alert data into an Alert ontology.
Finally we can see how the aggregation UI, in our case the CityLandScape Manager, which in turn is another Digital Twin, represents this information:
Standards in the Digital Twin field
As we saw at the beginning, the extension of the Digital Twins to the IT world (outside of the Industry) is still in an embryonic stage, therefore, logically, there are no accurate standards in this area. However, there is a set of initiatives that strive to become the standard in this area.
On the platform we opted for Web Thing API (https://iot.mozilla.org/wot),
W3C Web Thing is a new proposal (in this case from Mozilla) to describe a common data model and an API for the "Web of Things".
Web Thing Description provides a vocabulary to describe physical devices connected to the Internet in a readable format based on JSON.
Additionally the Web Thing REST API and Web Thing WebSocket API allow a web client to access the device's properties, execute actions on it and subscribe to events that represent a change in its status.
The specification includes:
· Web Thing Types as additional types that can be defined using semantic extensions on JSON-LD.
· A Web Thing API Protocol Bindings to write bindings to the Web Thing API for other IoT protocols.
· The Web of Things Integration Patterns document describes patterns for integrating devices with the Web Thing API.
With an example, we can see how the definition completely matches the concepts handled with the Digital Twin of the Platform:
where we can see that the device (DigitalTwin) has a property temperature of type Number, and properties humidity and LED, as well as an action (that someone can execute on the device) and an event (which is published when it is triggered) reboot, and links to access properties, actions, events, …
We have selected this initiative as the basis for our implementation because it is one of the best known initiatives due to its ease in adopting technology standards: easy-to-read JSON data structures, independence of the data exchange protocol and providing an implementation for two of the more extended interface standards, which are REST and WebSockets.