From Internet of Things to a Web of Sources

Whilst the founders of IOTICS were working together in a mobile IoT network company they realised that a common implementation pattern was emerging in the Internet of Things: “I have a sensor, I connect it to the cloud, I store the data in a database and I provide and API so people can get that data”. The owners of these sensors and providers of the API never once thought outside their box and wondered what if someone wanted to use their data and mix it with other data from different sources?

IOTICS’ original goal was to solve this problem. How could you find an individual sensor? How could you connect to it securely? How could you find other interesting sources of data and bring them into your app, too? How could you write an application that did this programmatically without developers having to read documentation, get API keys, work out the different formats for data?

This was the birth of the concept of “IOTICSpace”, IOTICS’ interoperability technology – a space where digital twins could interact.

Why digital twins?

By virtualising the real-world things you gain these advantages:

• Mitigation of cyber attacks
  You can only attack the virtual, abstracted twin of the real world, not the real-world equipment
• Decoration with descriptive metadata
  Real-world things can register with their location and description of their capabilities using semantic web technologies
• Abstraction of the real world
  Abstract models of the real world can be made so that different sensors can be used to provide the same data with no changes to the upstream
• Move the execution to the cloud
  Running code in the cloud the code that would be difficult or impossible to run on the edge
• Move the interactions to the cloud
  Twins can broker interactions with each other in the virtual space. Data then flows along the interaction at the pace set by the sender. Either end can terminate the connection at will.

What’s a “Brokered Interaction”?

In some ways, you can think of IOTICS’ approach as a publish subscribe model, but this is only part of the truth. One part of the “special sauce” is that any subscription is brokered with the publisher of the data. This means that the owner of a data feed is always in control of what twins can “follow” it (i.e. subscribe) at a granular level. The publisher is also protected from denial of service attacks as the follow requests go through the infrastructure, not directly to the publishing twin. This brokered approach also applies to control interfaces. As a potential controller of a twin, you have to request access to the control interface of the other twin in a similar way.

What are the design principles?

IOTICS’ operating environment was designed from the onset with these following principles. The security model was baked in from the start.

• The twin is in control of its own destiny
  It can choose what data to share, with what other twins and on what schedule it chooses. Same goes for control interfaces: twins can choose what to offer and who can bind to the interface.
• Metadata describes the API
  The API paradigm is very simple. Create twins and feeds of data and share them, create twins and request to follow. The metadata describes the twins and their data.
• Store as little data as possible
• Everything is asynchronous
  All APIs are push, try to avoid polling. Event streams are the way forward.
• Symmetry
  Everything in IOTICS is mirrored. If you want to follow a producer twin, first you must create a consumer twin and request to follow.

Why Semantics?

The Semantic Web was designed and built in the early part of the century, but has not had the traction the designers had hoped. We think this is because people understand semantics at a fundamental level, but “things” do not. The combination of the IoT and the semantic web opens up the possibility of Autonomous Interoperability – where programs can find sources of data and understand them unambiguously. In the world of Digital Twins, the possibility opens up even further. Twins can search for other twins and discover their capabilities. They can broker data and control interactions between themselves and adapt to changing conditions autonomously.

Why Twins?

There are many definitions of “digital twin” in the technology industry. Some think of them as 3D models, others think about hierarchies of objects. At IOTICS we see the twin as the central focus of the ecosystem. Each real-world asset has a virtual counterpart where you can find out details about the twin and receive updates when its data changes. You can find them individually and, with their permissions, form an interaction with them to receive those updates. It’s a natural focus on the asset that the company’s customers share. You buy an insurance policy from an insurer, you think of the policy, not the 10s of systems that provide the data for that policy in the background.

What’s the “British Museum Moment”?

One of the co-founders of IOTICS, Paul Green, was studying theology at an evening class. He was researching for an essay about early polytheistic religions and was walking around the British Museum when he chanced upon 2 sculptures: one of a king and one of a god. It looked to Paul as if they were in conversation.

In ancient times, sculptures were used as proxies. A king would show that they ruled a city by placing a statue of themselves in the main square. Religious allegiance was shown in a similar way, by placing statues of the gods in prominent places. The people at the time didn’t see them as statues, they saw them as embodiments of the king or god, imbued with all their authority and power.

Paul had been working in the IoT for a while, seeing how the same old solutions were trotted out saying they had solved the problem when all they had done was to solve the connectivity part. They hadn’t solved the problem of cross-domain integrations. Paul’s epiphany was to look at the sculptures and ask the question:

“if the sculpture of the king is not the king, and the sculpture of the god is not the god, but the two sculptures are in the same room together… Could we build a space where a virtual version of a thing and a virtual version of another thing could meet and interact.”

…and the originating concept of IOTICS was born…

What’s the “Zumba Moment”?

Hard though it might be to believe, the then-51-year-old co-founder of IOTICS, Mark Wharton, was a Zumba enthusiast. Living in the country, he attended a Zumba class in the local village hall, some half a mile walk from his house. Exercise is good for the mind, and it certainly proved to be on 10th May 2013 when Mark had an epiphany half-way home from that morning’s class.

How could things interact safely without one thing being able to affect the other? Via a request mechanism using push APIs. It goes something like this.

1. Twin 1 and Twin 2 both register their existence and capabilities independently with a registrar, using semantic metadata to describe themselves.
2. Twin 1 searches the registry for things like Twin 2 
3. Twin 1 asks a trusted 3rd party (the registrar) if it can follow Twin 2’s data
4. Twin 2 has rules that allow or disallow the connection
5. If the connection is authorised, the next time Twin 2 publishes data, Twin 1 gets it directly without the data going through the registrar.

Tada! One moment on a rural footpath Suffolk, a lot of input from others and a lot of hard thinking with patent lawyers and a suite of  patents granted in the EU and US years later…