Digital Twin Model is a digital representation of a real device, the model describes Properties, Commands and Telemetry device has. https://learn.microsoft.com/en-us/azure/iot-develop/concepts-modeling-guide
That being said, Digital Twin Model, for all intents and purposes, is just a JSON document that advertises/describes particular set of capabilities device has. If I'm not wrong - it doesn't really do anything on it's own besides that.
Say I create a DTDL model for thermostat. I have defined a writable property targetTemperature with schema of double.
"@id": "dtmi:com:example:Thermostat;1",
...
{
"@type": ["Property", "Temperature"],
"name": "targetTemperature",
"displayName": "Target Temperature",
"description": "Allows to remotely specify the desired target temperature.",
"unit": "degreeCelsius",
"writable": true,
"schema": "double"
},
My device establishes connection to IoT Hub with the given modelId. As far as I can understand, there's nothing is really stopping me from ignoring this Digital Twin Model and going to Azure Portal and manually editing targetTemperature, ignoring schema and setting the value as string or boolean. Same applies to my backend services.
Question/clarification - it is my responsibility as developer/service provider to ensure the integrity of Digital Twin Model. When update on property is requested, I must read the Digital Twin Model and make sure that the update doesn't break the model, Azure doesn't do it for me.
The pipeline would look something like this:
- Client sends property update request.
- Back end service gets Digital Twin for the device to be updated.
- Back end service verifies that Digital Twin can be updated with the given client parameters.
- Back end service commits update.
For test purposes of the IoT Plug and Play Devices can be used my Azure IoT Hub Tester (desktop version) or Azure IoT Central Tester (Android version), see the following screen snippets:
Note, that both versions have built-in a DTDL v2 parser for creating a virtual IoT PnP device with a device model simulation (telemetry, properties, standard and long running commands, etc.).