The term Digital Twin is becoming increasingly important in IoT. Originally used to refer to a complex computer model of e.g. a machine in a factory, the term is now evolving into a lighter-weight, simpler concept which is more generally useful. Azure's Head of IoT, Sam George, defines a Digital Twin simply as a digital replica of a physical thing in this podcast.
A Digital Twin is a model of a real-world thing, kept up-to-date via an IoT feed. Digital Twins are a way to map technology onto business need. For this reason, a Digital Twin is often not simply a 1:1 virtual model of a physical IoT device - the "physical thing" it represents is often a higher-level business concept.
Hierarchies
Consider a typical IoT deployment in a building, with individual IoT devices sensing occupancy, temperature and energy. The people who want to interact with that building - the owners, tenants, facilities managers, energy managers etc. - won't generally want to engage with the individual devices, they'll naturally think at a higher level such as Seat, Room, Floor or Building. To answer the simple real-time question "is the Ground Floor of the building currently occupied?" an analytics tool needs to examine whether any occupancy sensor on that floor has detected motion within the last 15 minutes.
Digital Twins often include the concept of hierarchy, and there can be multiple hierarchies. Building/Floor/Room is a physical hierarchy, and we might also be interested in logical hierarchies such as connection topology (which devices are connected to which gateways?).
Lifting the data up into the twin
In the above example, how does the analytics tool know that it can turn occupancy sensor readings into room occupancy? We certainly don't want the everyday user to be troubled about this, or even aware of it. They care about rooms, they don't even need to know that sensors exist. So before they can ask the question, we need a way to define how the analytics tool should turn sensor data into a usable model of the building. This might include selecting sensors by their properties (which room are they in? are they an occupancy sensor?), and also aggregating sensor data to produce digital twin properties (e.g. averaging 4 temperature sensors to produce average room temperature).
Now that we have created digital twins for "room" and "building", we can ask questions like "what is the difference between the internal temperature and the external temperature?". Internal temperature is a property of the room, and external temperature a property of the building that houses that room. We can now integrate that value over time to calculate "degree-days" - a standard measure proportional to energy used for heating and cooling.
Schemas
A related concept is the Schema which defines the properties that we expect an object of a particular type to have, whether it's a device or a room. The old "IT" way of dealing with data required that before you could ingest any data, you needed to define in a schema at least the property names and types.
DevicePilot intentionally does not force you to define a schema beforehand, so that you can ingest data and start making queries immediately (it is "schemaless"). However, as your number of devices grows (and perhaps the number of types of device that you have), and you start to want to model higher-level concepts of the world such as Room and Building, then schemas have a function in defining the Digital Twins.
Coming soon
Under the project name "Models" we've been working to craft a way for DevicePilot customers to take advantage of these concepts, as a natural and simple extension of today's experience ... so expect an announcement from us soon.
