In essence digital twin is the virtual representation of a physical asset. This simply means creating virtual models that is the exact counterpart (or twin) of a physical thing.
Most industrial contexts are a complex reality of assets connected in various different ways.
Use your own vocabulary and build your twin graph in the self-defined terms of your business.
How we get computers understand relations between data?
Data format: web pages, images, videos, etc.
Easiest way: property-value mechanism
name: 'John Lennon'
birthday: '1995-01-01'
mood: 'peaceful'
spouse: "http://dbpedia.org/resource/Cynthia_Lennon"
JSON-LD is a method of encoding linked data using JSON.
JSON-LD is a W3C recommendation: Web of Things (WoT) Thing Description
The Digital Twins Definition Language is a language for describing models and interfaces for IoT digital twins. Using DTDL to describe any digital twin’s abilities enables the IoT platform and IoT solutions to leverage the semantics of each digital twin.
{
"@id": “dtmi:example:Station;1",
"@type": "Interface",
"extends": “dtmi:example:Room;1",
"contents": [
{
"@type": "Property",
"name": “isOccupied",
"schema": "boolean“
},
{
"@type": “Property",
"name": “hasAVSystem",
"schema": “boolean“
},
{
"@type": "Property",
"name": “capacity",
"schema": “integer“
}
],
"@context": "dtmi:dtdl:context;2"
}
Azure Digital Twins Definition Language conforms with the JSON and JSON-LD 1.1 specification
Azure IoT Central is an IoT application platform for building enterprise-grade IoT solutions.
Device capaility model = Interfaces + Device Identity + View + Cloud properties
Digital twin != IoT device: IoT devices implement interfaces that capture data from real world assets.
Digital twin identity != IoT device identity: devices installed on fixed locations can observe several moving assets (eg. eRDM)
An Interface describes the contents (Properties, Telemetries, Commands, Relationships, or Components) of any digital twin. Interfaces are reusable and can be reused as the schema for Components in another Interface.
{
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"displayName": "Thermostat",
"contents": [
{
"@type": "Telemetry",
"name": "temp",
"schema": "double"
},
{
"@type": "Property",
"name": "setPointTemp",
"writable": true,
"schema": "double"
}
],
"@context": "dtmi:dtdl:context;2"
}
Telemetry fields represent measurements or events, and are often used to describe device sensor readings. Telemetry is not stored on a digital twin; it is more like a stream of data events ready to be sent somewhere.
Example: sensor data batches sent every 5 minutes.
{
"@type": ["Telemetry", "Temperature"],
"name": "temp",
"schema": "double",
"unit": "degreeCelsius"
}
Properties are data fields that represent the state of an entity (like the properties in many object-oriented programming languages). Unlike telemetry, which is a time-bound data event, properties have backing storage and can be read at any time.
Example: Available capabilities and conditions. For example, the current device connectivity mode such as cellular or WiFi. Synchronizing long-running workflows, such as configuration and software updates.
{
"@type": "Property",
"name": "setPointTemp",
"schema": "double",
"writable": true
}
A Command describes a function or operation that can be performed on any digital twin.
{
"@type": "Command",
"name": "reboot",
"request": {
"name": "rebootTime",
"displayName": "Reboot Time",
"description": "Requested time to reboot the device.",
"schema": "dateTime"
},
"response": {
"name": "scheduledTime",
"schema": "dateTime"
}
}
Relationships let you represent how a digital twin can be involved with other digital twins. Relationships can represent different semantic meanings, such as contains (“floor contains room”), cools (“hvac cools room”), isBilledTo (“compressor is billed to user”), etc. Relationships allow the solution to provide a graph of interrelated entities.
{
"@type": "Relationship",
"name": "floor",
"minMultiplicity": 1,
"maxMultiplicity": 1,
"target": "dtmi:com:example:Floor;1"
}