‍

Digital Twins are the talk of the town when it comes to optimizing analytics, automation and AI in an industrial environment. However, there is confusion on how the concept is defined vs. how it is deployed. Veselin Pizurica, Founder & CTO of Waylay, untangles the head scratching ambivalence and explains the different angles of approach.

‍

IoT device and Digital Twin concept

An IoT device is a piece of hardware, typically a sensor, that transmits data from one place to another over the internet. Types of IoT devices include simple (often wireless) sensors, actuators, as well as more sophisticated computerized devices.
‍

A Digital Twin (DT) is the software representation of a physical object. As a bare minimum, a DT must include the unique identifier of the physical object it represents. However, it only starts fulfilling its purpose once additional information – such as sensory information (position, temperature, humidity, etc.) and/or its actuation capabilities (turn lamp on/off etc.) – is added. The DT will often include additional auxiliary data, such as the device’s firmware version, configuration, calibration and setpoint data.
‍

When it comes to the actuation, we often talk about the DT as a “shadow” of its physical representation, in order to highlight the fact that actuations are always transactional. For instance, the DT’s intent to change its device state (turn it off or on) requires a particular command to be sent to the device, which after successful completion of that actuation needs be communicated back to the caller (the DT).  
‍

A Digital Twin is sometimes referred to as the representation of an IoT device, which is not exactly the same. Hence let us take a closer look at the two categories, as the difference between them is actually bigger than one might think.

‍

Does an IoT device and Digital Twin represent the same thing?

When things are more or less the same…

Smart utilities, which typically comprise energy (electricity, gas) and water, deploy connected devices across the utility network and collect data that help deliver services more efficiently and reliably and enables the creation of new services and business models. Let us take a look at one of our customers, where Waylay played an important integration role in delivering their solution. In this example a utility company decided to provide a customer portal where users can check their consumption and set usage alerts & alarms.
‍

In this example, the utilities company provides water and connects smart meters with an LPWAN IoT sensor to measure water consumption. The creation of automation rules, the customer portal with a view of the physical object based on the IoT device data is rather trivial, as there is a 1-to-1-to-1 relation between the IoT device, the physical object and its Digital Twin.
‍

When the relation between a physical object, an IoT device and a Digital Twin is broken

But it gets more complicated. Let’s take a look at another example and imagine that we want to place several physical IoT sensors on a single piece of equipment. Each IoT device can give us information such as air pressure, temperature, energy consumption etc. In this case, we cannot define a single IoT device that represents the piece of equipment. We have to consider the combined input of all linked IoT sensors/devices to get a complete view of its related object. As we place IoT devices in different parts of a more complex piece of equipment, we are not only interested in what each of these IoT devices measure individually, but also what they reveal about the underlying object as a whole. In this case, the Digital Twin, becomes a virtual representation of the physical object,  in the environment where it is located. It  reflects data from the IoT sensors in combination with the environmental conditions that have an impact on the performance of the equipment.
‍

In the following example, ENGIE has designed a solution for smart cabinets using Waylay’s automation technology. The ENGIE Smart Cabin solution monitors the power supply and critical parameters of high voltage cabinets based on a set of sensors installed on the voltage cells. The solution also monitors the cabinet’s temperature, humidity and door access. The sensor data is first transmitted via the IoT Sigfox network, then data is collected and processed by the Waylay platform to detect anomalies or power interruptions, generate alerts, and escalate alarms for quick interventions. In addition, customers get real-time status views via the Smart Cabin dashboard.
‍

In this use case, multiple IoT devices (sensors) have been placed in an electricity cabinet, transforming it into a Smart Cabinet. These devices transmit sensor readings over the Sigfox Network to the Waylay platform. The voltage scheme of the high voltage cabinet and the position of its IoT devices is shown below.

‍

‍

In this project, Waylay addressed the following challenges:

• Data from different IoT sensors have to be merged from asynchrone time frames ranging from minutes to hours
• Automation rules are composed on a combination of readings from different sensors
• Every sensor has its own role (in relation to others, not just in a simple “composite/aggregation” relation)
• Every cabinet has multiple automation rules
• In case of incidents, different people or personas need to be notified, for different cabinets
• Each cabinet has to  be provisioned,  with a its set of sensors, the logic has to be automatically instantiated
• All provisioning must be available over API and run from a no-code portal. The solution should allow rules to be applied as soon as devices are provisioned, without sending data upfront.
• Dynamic discovery scenarios should allow rule creation based on the detected number of sensors. In case some of the sensors should not be deployed (every cabinet has its own specific requirements or limitations), the automation rules have to automatically adapt depending on the ‘completeness’ of the Digital Twin.

‍

Provisioning of Digital Twins – zero touch provisioning

When we talk about IoT application scalability, we often think in terms of storage capacity, query time, stream ingestion rate, etc. One often overlooked, but indeed very important matter, is the scalability of the provisioning process. Waylay’s Provisioning API partially provides the solution, but there is more. At Waylay, the Digital Twin concept is based on JSON schemas that can be extended for any particular vertical. Waylay’s Digital Twin concept is similar to the Class/Object relation in the object-oriented programming (OOP) world. It enables Digital Twins to make use of inheritance and relational modelling.
‍

Another unique feature of Waylay’s platform is the ability to  associate automation rules to a class of Digital Twins rather than to a single instance of the Digital Twin. That makes Waylay’s provisioning process and the implementation of new use cases extremely fast, efficient and scalable – also often referred to as zero touch provisioning.
‍

On top of that, automation rules can access all Digital Twin configurations at runtime, which allows platform users (who set up the provisioning flow) to also define customer specific settings such as custom threshold settings, SMS notification numbers, email addresses etc.
‍

7 requirements for Digital Twins in the transition to Industry 4.0

The use of the Digital Twin concept in the transition to Industry 4.0 comes with specific challenges. When selecting an appropriate Digital Twin technology and a corresponding automation platform, these 7 important requirements need to be considered:
‍

1. The Digital Twin representation is not only about IoT devices. Digital Twins must also cover much broader abstraction capabilities.
2. A Digital Twin solution must allow to model relations between IoT devices. Customers should be able to create new Digital Twin models specific for their vertical or use case.
3. A platform must provide a provisioning infrastructure that enables the creation of Digital Twins and associates them with different IoT devices (including modelling relations).
4. Creating automation scenarios (rules) on these “composite” objects should be seamless – that is to say, automation templates should be assignable to these objects and not just to an IoT device. Any particular relation between IoT devices should be resolved automatically and already during the provisioning process. For example, a fault or a maintenance task should be applicable to an HVAC entity and not to a particular sensor/sensory measurement of that HVAC entity.
5. In general, IoT devices should be able to send data at different times, hence the seamless merging of streaming data must be possible.
6. Automation rules must have access to the configuration data (e.g. threshold crossings at runtime). These configurations can change over time. At runtime, any automation rule must be aware of these changes.
7. IoT platforms should allow end users to create automation rules on  asset families of Digital Twins, which should be done at the provisioning time. This imposes that  different e.g. HVAC families require different rules, which should be configured only once, rather than on  individual assets.
   ‍

What to expect next

In this blog post we have covered a concept where the Digital Twin and its physical representation are not so far apart, where the DT exists as a reflection of real-world IoT devices.
More recently, we have started discussing scenarios in which Digital Twins live within the realm of a virtual world. In that world, the Digital Twin is used to simulate reality and allow operators to model different “what if” scenarios, which later can be applied in the real world by physical representatives of the DT. The idea of simulations is not novel: for decades engineers have used these techniques in flight simulations, to model dynamic flows when designing turbines or city planners when modeling crowd flow. The novelty level that the Digital Twin adds is the plasticity of implementation scenarios with a wide range of applications that make use of the latest advances in the IoT world. The Digital Twin has just started its exciting journey and we can expect to see more simulation applications soon.

Conclusion

Waylay’s automation platform provides the answer to the requirements of the Digital Twin concept in Industry 4.0 deployments. Its versatile rule designer combined with the powerful and flexible low-code automation platform and the provisioning portal allow the creation of new scenarios and new business cases, based on the Digital Twin concept, in just weeks.

If you want to know more about how Waylay addresses the challenges of the Digital Twin concept, please get in touch with us and ask for a demo.