Tech Talk: „Digital Twins“ mit Maximilian Mayr von Tributech

Tech Talk: „Digital Twins“ mit Maximilian Mayr von Tributech

Welcome everybody. Thanks for tuning in to my presentation about digital twins and before jumping into the topic let's first explore the term of a twin in our context. And for this I would like to use the example of the Apollo 13 mission. The Apollo 13 mission was a mission from the NASA to the moon. On the way there they encountered a problem but they couldn't identify the issue. So basically they sent the message to Earth where they said “Houston, we have had a problem”.

And then they couldn't do anything more than that because they couldn't just exit the spacecraft.

So how do you identify such an issue?

In this example what they did is they used some help from the sensors or from the simulator's that they used to train the astronauts. This simulator's used to train the astronauts and they adapted them in a way to reproduce the problem that the astronauts had in space. On the picture here you can see the two simulators that were used and basically they used the same hardware inside of the simulators as the real spacecraft had. They were hooked up to some computers so they could try out certain things. Basically they adapted them, then they tried to figure out a solution and then they once they modified the devices they sent back the solution to space.

So what about the digital part?

As we saw with this simulator example we had a kind of real twin and now we take this real twin and digitalize it basically. This copy or this digital twin can then be used to communicate with the real twin to basically gather data about the real twin, to communicate with it, send some commands to it, and to organize certain twins together in groups and to deal with the real example in a digital context.

So what are some sectors where we use this?

Basically everything that has some kind of interference context has or can use twins. So for example we can use it in manufacturing purposes where we have some kind of machines and that has some sensors.

And we can use it in healthcare to represent data in a standardized way. For example I want to have a digital representation of the heart and I want to measure the heart rate. So I could model the heart as the digital twin and then have access to the heart rate by this twin.

And then I have the context for example, of a smart city where each building could be a twin and that twin could then consist of every room and every room would have like sensors or it would have light. And then I could theoretically group them together. I could say this is this district. And then I could have streets with entities like cars and persons that also could be digital twins again. As this example shows, you can model basically everything with this digital twins.

Also in data economies you want to have a standardized way that you can use to exchange data. For example I have a temperature sensor and I want to share that data of the temperature sensor with other people they should know what sensor it is or how they can access that data stream. So that's also a way where you can use a digital twin and the digital representation so it is kind of like standardized.

Like with every standard there are multiple competing standards. So in this presentation I will focus on the dtdl standard and that's a description language that was created by Microsoft in partnership with multiple industries. It's basically based on json ld. So it's using chase link data. A lot of the Web developers might know json ld from websites where you can basically optimize the website for Google or something like that and by setting some kind of meta tags. That's also basically using json ld in the background. Like I said it's an open source standard.

We said that it's a modeling language so we need some kind of building blocks that allow us to basically create our models and this building blocks really make it a lot simpler and to create this digital twin models than some other standards because some restrictions are always better than no restrictions. When it comes to modeling you don't want to have too much freedom and that's why with the dtdl standard we have the six building blocks and we have an interface where we can basically group together other building blocks. So for example we have a telemetry block where we can say we want to access some kind of data from a device. Like we take the example of the temperature sensor from before we want to access the core temperature. Then we have properties like a setting like do we want to continue like measurement? Do we want to switch the device on or off? Something like that.

These properties can have multiple types. So we can have a string property, an integer property, a duration and we can have a map. Basically everything can be a property of another shamer or interface can be a property.

Then we have some kinds of commands where we can communicate with the device so we can say “ oh please give me the current temperature value again”. But not as a stream but as a response. I just ask for one value and not for a stream. I can switch the device on or off. I can tell the device to do a measurement every 10 minutes or something like that. Just give the device any command. It's like a function basically our method and then you have some relationship. So when we go back to our Smart City example we have a district and in the district there are multiple buildings. So the district has some buildings and the building belongs to the district. So we can model relationships between them. Or a house has multiple rooms for example. And then we also have the building blocks of a component and a component is basically a small unit. So we want to have a device but we don't want to have it consist of multiple interfaces. But instead we say this device is the smallest possible unit and then we basically say and that's one component.

Once we have created one of these models we also want to have a unique identifier for the whole thing and generating a udi would be way too simple and it would not be really human readable. So for that we have dtmi, a digital twin model identifier. This model identifier basically consists of three parts. The first part is the machine. So in this case it´s dtmi always. Then the next part is like namespace or path and there usually you just take the fully quantified domain name of your company, turn it around. So for example drivertech.io would be io”drivertech and then you basically can define anything you want. The reason for that is that this way you have a lot less collisions when it comes to the domain names. And if there are collisions they are usually in the same geographical area. So for example if you would have a domain name with AT for Austria you would have a collision within Austria and it would be much simpler to resolve that collision or to even know about that collision.

In this example we have a device and the device is of the type edge in our case. So that's basically the part and then you have a versioning number because every time when you model something you want you want to have the possibility to have multiple versions of the whole thing. For this you have this version number here.

Here we have one example of a twin file. On the left side you can see basically the model of the twin. We can see that we have some inheritance there with the extents and in the content you have your smaller building blocks. On the right side you have a finalized instance of that model where we can see the properties. We have the reference back to the original model by this method data tech that references back using the dtmi identifier to the defined model.

On the left side you can also see that each property or each building block has some fields where you can set some meta data, for example description comments, display names, if the property is writable or not and also what kind of shima is used for that property.

So what are the advantages now for developers using this digital twin model standard?

It allows you to basically represent any kind of Iot device in an abstract way. You don't need to know about every device that's out there. You just need to know about the building blocks and the possible combinations and then you can work with this iot device. You can make the data responses, you can make cell responses because you always know what is the allowed communication. So it's basically like an open API standard just for iot devices. You can generate generic user interface based on these twin models because you only have to represent each building block and then you can just stick it together and you have a final UI. Then you have this consistent representation of data from the device to the backend and to the frontend because the twin file itself is kind of like a single source of truth for the state of the device. You can just pass that through all your layers.

The standard allows you to basically have some kind of domain driven design or domain specific model language where you can model your model files for your specific application. So it doesn't depend what sector you are in. You can use this building blocks and adapt them for your needs. And also the traceability is greatly enhanced because if you change something you immediately get the response if something goes wrong via this telemetry data. So if it's all hooked up together each change will immediately trigger an error at the telemetry data and then you immediately know something went wrong. And even afterwards it's much easier to basically know about what happened due to these changes.

If you're interested in the topic there are two major platforms out there currently that support the teaching of twins. One is the Eclipse ditto project that's completely open source and where you can basically talk with twins, creat twins and managed twins.

And the second example is the Asia platform for Microsoft where they also have a digital twin service that allows you to manage twins.

I hope this presentation taught you a bit about digital twins. It's a really interesting topic and I think that will come up a lot more in the future. Thank you very much.