Category: Digital Twins

Posted on

ZEDEDA: Digital Twin and AR/VR

At the ZEDEDA Transform 2020 event, I was joined by Richard Soley from OMG, Edward Wood from Dispersive Networks, Inc., and Mike Pantaleano from Rockwell Automation where we discussed key #DigitalTwin considerations and use cases ranging from #IIoT to #AR to #VR.

Important insights that we’re happy to share with everyone. What made it even better was that I was connected into this virtual event from my happy place, Moab, Utah.

Register for free and watch the video on demand at the link below:

https://info.zededa.com/zededa-transform-access-page-edge-security-0

Posted on

IoT Day 2020: Fighting COVID-19 with Digital Twins

Covid Twins

With #COVID19 sweeping the globe, knowledge is our best weapon in fighting this pandemic and associated economic collapse. #DigitalTwin technology is perfectly suited to represent people who have symptoms, are infected, or have recovered.

This capability can also aid in identifying people an infected person came in contact with via contact tracing using mobile apps and Bluetooth. Lastly, “green zones” can be identified where people can go back to work. Join Rob to learn how this powerful technology can be put to work in overcoming the Coronavirus threat.

Posted on

Digital Twin Models and Process Properties

DigitalWindfarms

A process is a series of actions, tasks or steps taken in a linear or sometimes a branching, non-linear sequence in order to achieve a desired outcome.

These process steps could be manual activities undertaken by a person, purely digital steps taken by software across computers, electromechanical actions between digital messages and mechanical actuators as well as advanced cyber-physical tasks performed by industrial robots.

Let’s walk through a few examples:

  • A farmer checks the weather forecast everyday then drives their truck to appropriate orchards or fields to perform irrigation for a certain amount of time based on previous rainfall totals and the needs of the crops.
  • A digital scheduling system for doctor appointments retrieves appointment time and location preferences of the patient and combines it with their insurance information and the doctor’s current schedule to deliver a range of appointment times.
  • An electromechanical system uses motion sensors to notice a person has entered a meeting room and carries out steps to turn on lights, adjust room temperature, and turn on the projector to show a presentation.
  • Cyber-physical industrial robots perform individual tasks but also have awareness of the current state of other robots on the assembly line to better work together in building a car.

Rather than just using digital twins to provide visibility to ongoing operations or to improve future product development via simulation, why not use digital twins to orchestrate processes?

Let’s dive into the simple electromechanical scenario shown above:

Imagine the familiar IoT process where you need to turn on the lights, adjust room temperature and turn on the projector when a person enters a meeting room. You’ve got a Digital Twin that represents the meeting room which acts like a group or container for a collection of digital twins that represent motion sensors, HVAC, the lighting system and the projector.

All you need now is an process automated by bots to bring this to life.

The motion sensor detects a person walking-in which triggers a software bot on the associated microcontroller to send a message to an IoT platform or building management system. Upon receiving the message, a bot identifies the particular meeting room and sends a command to activate the overhead lights. Concurrently, a bot sends a command to the HVAC system to adjust the room to a comfortable temperature. Last but not least, a bot sends a command to turn on the overhead projector so the person can deliver a presentation.

How do you orchestrate this process?

Since this is a simple process, you could probably do this with a series of rules via the event processor in your IoT platform. Knowing that processes can become more complex with many variables and different forks in the road, you could instead choose to define the orchestration in a Digital Twin Model. With it’s available process properties, this twin defines the steps needed to guide software bots in taking the actions needed to achieve the desired outcome. Each step is represented by a process property. Each process property defines the digital twins involved, the APIs needed to connect, security requirements for calling those APIs, data to be sent, return values to expect and other details needed to successfully complete the step and move on to the next one.

This doesn’t have to be a 100% digital process.

In another scenario, the prescriptive analytics from an IoT platform might alert a technician to fix a broken component. The orchestrating digital twin model would still have its process properties except this time, each step would guide a person instead of a bot to complete the required activities. In this form of guided repair, the process properties would use descriptive text to tell the technician what tools to bring, where to go, and step by step instructions to fix the component. These text based steps could be displayed on a mobile app or take a more digital form via augmented reality (AR) glasses. Once the repair was completed, a tap of a button on a mobile app might make the API call needed to let the orchestrating twin know the job is done.

Posted on

Digital Twins and Groups

Assembly Line

It’s easy to think of #DigitalTwins as representing discrete systems & subsystems, like an industrial #robot that builds a car in a factory. The reality is that physical entities like humans, machines & environmental systems don’t live in a vacuum. #IoT #IIoT

They often operate in larger systems of systems with relationships & interactions with other entities. If I were to collect a number of industrial robots that work together, I might create a “group” called “assembly line.” Unfortunately, using a simple group construct would do this collection of robots a disservice. The assembly line group should actually be a digital twin itself where its telemetry, virtual, static, and command properties have defined causal relationships with all the robots that comprise this assembly line.

There’s a parent/child relationship between the assembly line twin and all the robot twins. Furthermore, there are peer relationships between all the child robots. This literally brings the assembly line to life allowing you to monitor it via your IoT platform and analytics.

Collections of assembly line digital twins can then come together to create a “composite digital twin” called a factory.

Posted on

Digital Twins & Subsystems

Engine

If you’ve ever worked with an #IoT platform, you might have noticed it typically has you define a simple schema or #DigitalTwin Model for an entire person, machine or environmental system. #IIoT

If the system you intend to monitor is simple enough, then a single digital twin instance may suffice. On the other hand, if what you’re monitoring is comprised of multiple, complex subsystems, you may have to go a bit further.

For instance, an automobile is actually a system made up of many subsystems including the engine, braking, transmission, electrical, & fuel subsystems just to name a few. Depending on complexity, it stands to reason that some of those subsystems deserve to be digital twins with telemetry, virtual, static & command properties of their own. Not only would these subsystem digital twins have a parent/child relationship with the overall car, they would have causal relationships with each other. If the engine doesn’t run when you start your car, the cause could be the battery, starter or alternator in the electrical subsystem.

Defined causal relationships between the engine & properties of the electrical subsystem would alert you to the correct cause. This helps you get prescriptive analytics.

Posted on

The Digital Thread

Thread Spools

To create an historical record of what happens to an instance of a #DigitalTwin throughout its entire lifecycle, you represent this with something called a #DigitalThread. #IoT #IIoT

Beyond the IoT telemetry the digital twin captures from the physical entity, other significant events are captured via an ever-growing digital thread.

I’ll use an automobile to illustrate how this works. While it’s critical to have a car’s current and historical telemetry data captured & analyzed, there are other events that occur throughout the car’s life that result in a digital thread adding those events to the twin’s permanent record. Taking a car to the shop for an oil change, an accident report and repair, and performing routine service on the car all represent events that are manually added to the digital thread. You could also add pictures, 3D CAD models and other important information via this mechanism. Just imagine capturing a digital thread event where a particular type of car suffered a water pump failure at 60,000 miles. Sharing this information with all other cars of the same type would be invaluable.

In the end, this is how we tell the birth-to-retirement story of the physical entity represented by it’s digital twin.

Posted on

The Digital Twin Instance

Twin Buildings

It’s time to create a #DigitalTwin Instance of a physical entity that is derived from a Digital Twin Model. #IoT #IIoT

If you’ve worked with any of the Internet of Things platforms, you probably registered an IoT endpoint or device to make its identity known to the system. In the smallest way possible, this is what it means to create an instance of your digital twin that is entangled with a physical entity.

Like most things in the digital world, you start with Identity. You give your digital twin a name & perhaps a brief description. The IoT platform you’re working with will assign a unique identifier used to access & identify the digital twin and its physical counterpart throughout its life cycle. Next, some type of security token or X.509 certificate will be bound to the unique identifier of the digital twin in order to facilitate authentication & authorization. It’s possible that you might assign a date in the future when the security token or certificate is no longer valid. You should also have the option to enable or disable the twin if you need to blacklist incoming data from a compromised physical entity. Lastly, you bind it to the digital twin model that it’s derived from.

Posted on

Digital Twin Models and Rules

Twin Buildings

As part of my series on #DigitalTwins, I’ve discussed the creation of a Digital Twin Model which defines a type, or class of physical entity from which instances of digital twins are derived. #IoT #IIoT

Once you’ve added telemetry, virtual, static, or command properties, it’s time to make use of this #metadata with rules.

The first steps in deriving value from streaming telemetry data revolves around pattern matching, key performance indicators (KPIs), & filtering. You therefore need to specify one or more rules to be associated with each “telemetry property” you’ve defined in your digital twin model. This is accomplished through the use of simple operators such as equals, not equals, greater than, greater than or equal to, less than, & less than or equal to.

Let’s say you’ve defined a “telemetry property” for the “left front tire pressure” of a car digital twin model with an “integer” data type and “PSI” unit of measure. To create a “green” KPI between 30 & 35 PSI, you would define a rule looking for values that are >= 30 & <= 35. Using simple IFTTT algorithms, the event processing engine of your Edge or Core IoT platform would apply those rules to incoming data & trigger an action for values outside that range.

Posted on

Digital Twin Models and Command Properties

Twin Buildings

In the event your #IoT platform needs to work with industrial control systems where it’s necessary to send messages to trigger actuators, you’ll define one or more “command properties” in your #DigitalTwin model. #IIoT

Actuators can typically be electric, hydraulic, pneumatic, or mechanical. You’re basically turning a control signal or command into an action on a machine. The “command properties” you define can include parameters such as names, data types, and units of measurement to assist a command and control signal in properly triggering the actuator.

For instance, an electric motor may allow you to remotely set its revolutions per minute (RPM) to control the speed. You would need to define the name of this actuation command as specified by the manufacturer of the motor. It might be “speed.” You’ll also need the data type of the value to send, which in this case might be an “integer.” Lastly, you can guess that the unit of measurement is “RPM.”

All these Digital Twin command properties defined in the model for a particular class of device are here to help your Internet of Things platform do its job to provide value.

Posted on

Digital Twin Models and Static Properties

The static properties enumerated by a #DigitalTwin model represents #IoT #data that typically doesn’t change. #IIoT

In my last two posts about defining Digital Twin models for your IoT system, I described “telemetry properties” that map 1:1 with device sensors and their associated data types and units of measure. I also described “virtual properties” that are a sort of “soft sensor” whose value is derived through a calculation from sensor values and other data sources.

Today I’m adding “static properties” to your Digital Twin model which are values that typically don’t change. If I use a car as an example, static properties could be things like the length of the car, the number of cylinders, displacement of the engine, and the volume of room in the trunk. Static properties are necessary to have a more complete view of the actual entity (car in this case) and to be used as reference data for analytics when defining the Digital Twin model that instances of Digital Twins will be derived from.