Weeknotes project image

By Rachel Wilson, Senior Software Developer at the ODI

Weeknotes: personal reflections from the ODI research team. Keeping you informed about our projects, research and decision-making processes.

This week's activities and questions

  • What is the Internet of Things, the Web of Things, and how are they relevant to - or different from - digital twins?
  • Continuing to comprehend the Samsung Open Source Group's existing work on connected sensors

This week's observations

  • Digital twins can use IoT technology/principles but it's not necessary
  • "There is no unique and universal communication protocol that can work across the many networking interfaces available" [3]
  • Compared to IoT, digital twins emphasise the virtualisation of assets for the purpose of surfacing insights, over the hardware interactions

Apologies for a long weeknote this week; it's been a week of research that I hope will be useful to summarise.

Continuing to unpick Samsung's great work

In weeknote #1 I described how Samsung's Open Source Group (SOSG) - in particular Philippe Coval and Ziran Sun - have produced a working prototype of a digital twin of lighting, temperature and humidity sensors in a house using open source technology.  The code is all open source, and their efforts have been openly documented.

Because of SOSG's relationship with open source it's not surprising that the prototype is centred around Mozilla's WebThings Gateway and their WebThings API.  To recap, Mozilla Gateway is like a control centre crossed with a visualisation, it can be used to:

  • Control hardware 'Things' remotely
  • Visualise the hardware network of Things
  • Read and store sensor data
  • Visualise sensor data

Samsung's prototype uses a lot of IoT technology, which I (perhaps too narrowly) associate with home automation, and I wonder how relevant the concepts and technologies will be to "industrial" digital twins.

What is IoT vs Web of Things vs Digital Twins

Looking back at our exploration of what comprises a complete digital twin, all this talk of assets and sensors and "interventions".  It also sounds very IoT, could a digital twin be just IoT for industry?

The easiest to understand description of IoT I found is taken from this explainer about the Web of Things vs Internet of Things (emphasis mine)

A "Thing" is a physical object that is digitally augmented with one or more of the following: Sensors (temperature, light, motion, etc.); Actuators (displays, sound, motors, etc.); Computation (can run programs and logic); Communication interfaces (wired or wireless).

The "IoT" is a network of Things, which can be connected in some form to the Internet. From a box of oranges with an RFID tag, to a smart city, and to every Thing in between. All these digitally augmented objects make up the IoT.

The Internet part simply means that the Thing (its services or data about/from it) can be accessed and processed by other applications through the existing Internet infrastructure. This does not imply that the thing must be physically connected to the Internet. The communication network used can be an Auto-ID technology, short-range radio (e.g., Bluetooth, ZigBee, etc.) or a local Wi-Fi network in a building.

Similarly in digital twins connection to the wider internet is not necessary, and in some circumstances even undesirable.

The Web of Things (WoT) is a specific TimBL-gladdening developing standard for IoT that "reuses readily available Web protocols, standards and blueprints to make data and services offered by objects more accessible to a larger pool of (Web) developers".

IoT and WoT seem to me to focus on device definitions and communication, whereas definitions of digital twins I've come across (And there are many) have a different emphasis. For example, "A digital twin is a virtual replica of an object, system, process, product or service that is digitalized and put on a simulation platform" [1]. And "A Digital Twin refers to the virtual replication of a physical product or asset" [2]

The difference in technologies used (sensor types, communication protocols etc) don't seem to be important differentiators between digital twins and IoT. What does seem to matter is that digital twins seem to emphasise the virtualisation for the purpose of surfacing insights, over the hardware interactions.

I am sure I will return to this question.  But for now I'm satisfied that while there is great deal of overlap - enough to be confusing - there is different emphasis - enough to justify a new term.

Difficulties with IoT relevant to DTs

The WoT's developers state the need for a standard because: "Unfortunately, building a single global ecosystem of Things communicating with each other seamlessly is virtually impossible today. There is no unique and universal application protocol for the Internet of Things that can work across the many networking interfaces available today. To put it bluntly, the IoT of today is essentially a collection of 'isolatedIntranets of Things' that can’t really interact with each other." [3]

I suspect we might find the same situation in an industrial context.

Lots of data infrastructure inspiration

Research into the origins of the WebThings project [4] and IoT uncovered some inspiration for framing any exploration into communication technologies and data infrastructure.  Such as in these two images:

table showing IOT technologies
Web of Things technologies

The ODI thinks about data infrastructure beyond data assets and encompasses the support of people, organisations, processes and technology.  Digital twin systems will operate in a similar ecosystem of standards developers and technology providers.

Back to Mozilla WebThings Gateway

SOSG chose to use Mozilla's WebThing Gateway (Gateway) as their IoT control centre, which implements the Web of Things standards.  Gateway is one way to monitor and control "smart" home devices using open source technologies and open standards.

It is a good choice for SOSG's prototype digital twin because it seems Gateway's concepts mirror those of digital twins:  Smart devices (assets) will produce data usually from sensors which - by connecting them to Gateway - a householder can monitor via logs and visualisations.  By studying the visualisations they could determine insights ("it is more humid when we cook") and make decisions and interventions ("we should start the smart extractor fan at 7pm").  The outcomes of the decision can be observed in future sensor readings and visualisations.  The data can be shared via APIs, which would be one way to connect this system to another.

But how does gateway connect all these devices to the visualisation?

How Gateway interacts with smart devices

Apologies, this is going to get technical, but it took some effort to figure this out so I'm sharing in case it helps someone.

For a device to be discovered and registered with Gateway it must be exposed via a web-server and implement a WebThing Adapter API. You can install libraries that implement the Adapter API on wifi-enabled micro-controllers, such as the ESP8266 or Arduino, eg. webthing-esp8266 or webthing-arduino.  In code you will register your devices with an WebThingAdapter class (which also handles the web-server bit for you) so that starting your micro-controller will "pair" them with Gateway when they share a wifi network. Gateway then sets up listeners for updates from that device.  Micro-controller code that takes readings from sensors will update these listeners. [5] [6] [7] [8]

Put another way "The WebThingAdapter [class in the webthing-8266 library] knows how to speak the Web of Things API with our Gateway and handles all the translation necessary for the Gateway to discover and interact with the ThingDevice" [8]

Gateway also includes a user interface and database. Once a device has been discovered by Gateway we can add it to the user interface with an icon and properties relevant to its type. Gateway updates and visualises the device's virtualised properties by querying the adapter listeners. A database stores a history of values retrieved from the adapters, which we can use in the user interface to plot graphs.

Putting Gateway to one side, for now

If I want to prototype a digital twin of my own, Gateway could be a good place to start. Philippe's generic sensor adapter may well be helpful - depending on what we choose to build. But for now the Gateway software combines so many functions that it's difficult to follow the data flow and demonstrate choices at each layer.  So I'm going to put it aside for now, grateful for what I learned in trying to understand how it works. I may revisit its functionality when I come to explore visualisation and control.

Reading List

[1] Comparing the internet of things vs digital twin

[2] Digital Twin Explained – The Next Thing After IoT

[3] Web of Things vs Internet of Things: 1/2

[4] Building the Web of Things & Web of Things' Wikipedia page

[5] Creating an Add-on for the Project Things Gateway

[6] Adapter API

[7] Github: mozilla-iot-generic-sensors-adapter & Github: Adding the generic sensor adapter to Mozilla IOT project  & Github: webthing-node

[8] Making a Web Thing on the ESP8266

[9] How to build your own private smart home with a Raspberry Pi and Mozilla’s Things Gateway

Reflections

  • I still wonder how different is the technology between IoT systems and industrial systems
  • Most of the examples I've come across are based on smart homes. It's curious how there are so few twin integration case studies, but perhaps this is because it's (a) nascent, and/or (b) hard (c) few win-wins therefore little motivation?
  • Mozilla's Gateway is very useful, but at this stage it combines so many functions that it becomes difficult to discern the components and data flow within a digital twin. I want to demystify digital twin technologies, so i think I will put Gateway to one side, for now.

This week I am powered by: Github README files

Thank you to: Anyone who takes the time to explain how things work and publishes it on the internet (actually, i think this nearly every day).  In particular this week Philippe Coval, Ziran Sun from Samsung Open Source Group and the Mozilla Gateway developers.