Digital Twins - just what are they again?
Digital Twin is possibly one of the most overused and confused terms used in the world of “Digital”. It seems to get applied to almost anything and everything. In my personal view a Digital Twin needs to have the following properties:
- A real world physical asset, such as a building, vehicle or machine tool.
- The asset acquires data about itself through sensors such as acceleration, temperature and so on.
- One or more synthetic models for the asset and/or it’s subsystems have been developed. These models are typically used to predict and simulate the behaviour of the asset and it’s subsystems.
- The asset has communications connectivity to allow data acquired from sensors to be sent back to the synthetic models.
- The synthetic models can make use of the real-world sensor data to improve the performance and operation of the asset as well as improve the models themselves. For example support fault diagnostics, predictive maintenance / prognostics, inform a proposed design modification or new product design and so on.
An expanded definition can be found in the text Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems by Michael Grieves and John Vickers of NASA. They subcategorise Digital Twins into a digital twin prototype (DTP), digital twin instance (DTI) and digital twin aggregate (DTA). The DTP is the collection of synthetic models produced during the concept / design phase of a system before any such system is physically realised. The DTI is when there is a physical real-world asset available and capable of capturing and transmitting data about itself, even if it’s a prototype. The DTA refers the case where there are often fleets of assets of the same design or family. For example a fleet of vehicles of a manufacturer and model. If you are looking for a definitive and comprehensive definition of Digital Twins, in my view the Grieves & Vickers text is the best source on the subject.
Bringing the Synthetic and Real Worlds together
When you start to translate the theory of Digital Twins into practice there are numerous challenges, including:
- There is unlikely to be just a single synthetic Digtial Twin model, but dozens if not hundreds. In particular with large scale complex systems such as aircraft. There will be models for different perspectives and disciplines, such as concept of operations, aerodynamics, structural, behavioural, as well as across the product lifecycle of design, manufacture and support. These models will likely be built in different tools and technologies, use different data formats, interfaces and protocols. Example modelling tools include CFD, Cyber-Physical Modelling, Architecture and so on.
- The asset itself will contain multiple technologies. In particular data acquisiiton and sensing. These may comprise of different industrial control databuses and protocols such as Modbus, Profinet, CANBus and AFDX.
The core technical challenge of Digital Twins is integrating all these synthetic and real-world systems together. This is not only from a technical protocol and communications perspective, but also from an information architecture perspective. For the Digital Twin concept to truly work, multiple models and assets need to not only exchange information, but also have a level of common semantic understanding.
Web of Things (WoT) - the answer?
The W3C standards body has been working on this challenge with an emerging standard called WoT. Incepted in 2015 with representation from a number of industrial participants including Intel, Microsoft, Siemens, Bosch, Fujitsu, Mitsubishi and others, the standard is begining to mature. WoT membership participation is now running at around 470 members across a wide range of sectors and industries. WoT is broken down into five sub components covering architecture, Thing description, discovery, security and scripting.
WoT leverages a number of core principles, including:
- Web technology, e.g. HTTP REST, is the core of technical interoperability.
- All Things shall have core functional capabilities including status, receiving and subscription to information and events and invoking functions.
- Things and Thing clients can dynamically discover each other and their capabilities through semantic search
The heart of WoT is the Thing Description (TD). This defines core semantics and vocabulary for a Thing. Here’s an example description for a smart lamp.
{
"@context": [
"https://www.w3.org/2019/wot/td/v1",
{ "saref": "https://w3id.org/saref#" }
],
"id": "urn:dev:ops:32473-WoTLamp-1234",
"title": "MyLampThing",
"@type": "saref:LightSwitch",
"securityDefinitions": {"basic_sc": {
"scheme": "basic",
"in": "header"
}},
"security": ["basic_sc"],
"properties": {
"status": {
"@type": "saref:OnOffState",
"type": "string",
"forms": [{
"href": "https://mylamp.example.com/status"
}]
}
},
"actions": {
"toggle": {
"@type": "saref:ToggleCommand",
"forms": [{
"href": "https://mylamp.example.com/toggle"
}]
}
},
"events": {
"overheating": {
"data": {"type": "string"},
"forms": [{
"href": "https://mylamp.example.com/oh"
}]
}
}
}
The Thing Description protocol leverages JSON-LD thus providing a basis for linked data and semantic search. This example illustrates the core elements of Thing Description including:
- Unique identification via a URN id.
- Security mechanisms applied to device access
- Properties of the device. In this case a status property with the URI on which this can be found.
- Actions that can be taken on the device. In this case toggle the light switch.
- Events that the device can produce
Semantic annotations are also supported. In the above example semantics are described for the type of device, a LightSwitch and the types for the Status and Toggle functions. These semantics follow the JSON-LD standard and provide support for Resource Description Framework (RDF) document processing.
The Thing Description is agnostic to the technical transport for communication, e.g. HTTP, CoAP, MQTT etc. The process from taking the abstract Thing Description to realising and deploying it into an operational architecture is through WoT Binding Templates. These templates provide the transformation to executable protocols and software instantiation. This is illustrated in the figure below.
So where do Digital Twins fit in?
WoT has a concept of an Intermediary that sits between the Thing and a Consumer who wishes to connect to the Thing.
One proposed concept architecture for a Digital Twin component in WoT is that it acts in the form as this intermediary orchestrating between the device and the consumer. This intermediary could contain elements of a model, physics or AI based, that may adapt the interaction. Such a concept supports components of a Digital Twin system being deployed to the edge, as well in the Enterprise / Cloud as shown below.
So when can I get going with WoT?
WoT has been baselined as a W3C recommendation since April 2020. So it is still young in standards terms. There is a growing set of tooling and SDKs for WoT across multiple platforms. My personal recommendation is WoTPy, in my view one of the more easier SDK’s to get to grips with in the Python ecosystem.
There has been a level of controversy with WoT in terms of Microsoft branching off with their Digital Twin Definiton Language (DTDL), the foundation for their Azure Digital Twin Platform. DTDL uses a lot of the same architectural principles and foundations as WoT, including Web architectures and JSON-LD, however is proprietary to Microsoft. To be fair to Microsoft, I believe their justification for this was WoT as just not moving and getting adopted fast enough for their commercial plans for the Azure Digital Twin Platform. Therefore, they felt they needed to develop something to meet their needs. Microsoft may pivot to WoT as it matures, particularly if it starts getting adopted by industrial companies such as Siemens, Bosch, GE etc.
WoT the Digital Twin saviour?
My personal view is that a standard such as WoT is needed if the vision and benefits of Digital Twins are to be realised. Without such an open standard, Digital Twins are likely to prove complex and expensive to implement, lacking the technical and semantic integration resulting in heavily bespoke solutions. WoT is certainly adopting the right kinds of architctural principles, particularly around leveraging Semantic Web, JSON-LD, and service discovery. The tooling is begining to mature and it’s got a large number of major global industrial organisations supporting it.
I for one believe WoT is worth experimenting in and tracking. It’s going to be interesting to see how it develops.