Challenges of Creating Digital Twins in the Transition to Industry 4.0
Digital twins are popular when it comes to an industrial environment, and it's important to learn how the concept is defined versus how it is deployed.
Join the DZone community and get the full member experience.Join For Free
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. At 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 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 the actuation needs to 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. Let us take a closer look at the two categories, as the difference between them is actually bigger than one might think.
Do 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 they enable 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 utility 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
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 measures 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 electrical 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 asynchronous time frames ranging from minutes to hours
- Automation rules are composed of 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, and with 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 modeling.
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.
Seven 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 seven important requirements need to be considered:
- The digital twin representation is not only about IoT devices. digital twins must also cover much broader abstraction capabilities.
- A digital twin solution must be allowed to model relations between IoT devices. Customers should be able to create new digital twin models specific to their vertical or use case.
- A platform must provide a provisioning infrastructure that enables the creation of digital twins and associates them with different IoT devices (including modeling relations).
- 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 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.
- In general, IoT devices should be able to send data at different times, hence the seamless merging of streaming data must be possible.
- Automation rules must have access to the configuration data (e.g. threshold crossings at runtime). These configurations can change over time. At runtime, all automation rules must be aware of these changes.
- 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 enforces that different 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, and 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 for 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.
Opinions expressed by DZone contributors are their own.