Chief architect Fabrizio explores the parallels between IOTICS and multiplayer video games.

In this series of posts I want to briefly discuss the principles underlying IOTICS, why each one is important to allow applications to autonomously interoperate, and, in turn, why they enable the creation of data ecosystems.

IOTICS believes that data ecosystems and its technology enables them: parties in the ecosystem collaborate and cooperate securely and at scale by sharing and exchanging data and events.

The ecosystem is, essentially, a decentralised network where each party can share and exchange data with each other still retaining full control of their respective access control and governance policies.

IOTICS’ tech implements the middleware and the mechanics of joining the network, but the conceptual architecture of the solution is underpinned by three main ideas:

1. Virtualisation: Every real asset is virtualised in IOTICS as Digital Twins.

2. Symmetry: Interactions between real assets occur ONLY between digital twins

3. Secure interactions: an interaction – or exchange of data – from a twin to another twin must be allowed by the receiving twin. IOTICS provides the brokering framework.

I’ll try to keep the discussion to a high level but provide concrete examples of how these concepts are implemented in practice.

But, before I delve into it, I’d like to start with a simple analogy. We’ll carry on the analogy throughout.

Gamifying IOTICS

I often draw parallels between IOTICS and multiplayer video game environments. This analogy only stretches so far but generally works to introduce the concepts and it’s suitable to be extended.

If you think about it, a multiplayer game is an ecosystem of parties cooperating or collaborating for a common purpose: no matter what game they play, everybody shares the common goal of being entertained. Everybody needs to cooperate by playing according to the ecosystem rules, for the whole ecosystem to work and for every player to benefit from.

Fun fact, before I carry on: our founders imagined IOTICS as the “Second life for things” (IOTICS vision was born when Second Life was popular). This very idea has evolved and it’s further explored by our colleague Phil who’s discussing how IOTICS is a metaverse for things.

Currently, multiplayer arenas require a network of consoles or PCs connected with each other and users connected to the respective console. Knowledge of what players exist in the network and what state they’re in is “in” the network.

Granted, most of these products need “servers” for all consoles to coordinate but that’s a digression for now.

If – for argument’s sake – we limit the example to two consoles, we can imagine two players connected to the respective consoles playing with each other in the game.

The element of virtualisation exists because each player has an avatar replicating the actions of the user or transmitting the interactions with the other player via the hardware.

The environment is symmetrical, because players can only interact with each other by means of their respective avatar.

And interactions between avatars are “brokered” and secured in the sense that a player can choose who to play with, how and when.

Finally, it’s worth highlighting a parallel on scaling strategies: IOTICS enables ecosystems to expand. One can start with only a few “players” and then as their objectives and networks evolve, so do the ecosystems. Popular multiplayer games such as Fortnite didn’t start as massively popular games. They started with a few and then grew because more players could enter without disrupting what exists.

Virtualisation, I have heard it before!

Virtualisation is the idea that a real asset is represented by one or more virtual presence in IOTICS. These virtual entities are called Digital Twins. In practice, everything can be “twinned”: a person, any physical object, a system, a software process.

Why does it matter

Whether the real asset is a physical object, a concept or a data source, it doesn’t matter. Virtualisation matters because it decouples real from virtual giving the opportunity to the owner of the asset to enhance how the asset is presented and consumed. The virtual replica of the real asset can normalise and secure access to the asset as such providing an added level of security, can compensate for the deficiency of the asset and act on behalf of when necessary.

Once the virtual asset’s data is available and understood it then can be consumed for a variety of purposes, including analytics, visualisation, machine learning, etc.

The IOTICS Digital Twin

A twin has the following features

Unique identity
1. Metadata
2. Streaming Data and Controls
3. Behaviour

Unique identity

IOTICS leverages W3C Decentralised Identifier spec to provide a framework for self sovereign identity, as such, allowing every twin to control its own identity. Twins implement a mechanism of authentication and control delegation to allow twins to act on behalf of users or software to control the twin’s behaviour and presence in IOTICS.

In practice, twins’ identity is managed in IOTICS using the Identity Library. It can be programmed in a variety of languages (Golang, Python, Java, Rust, Javascript)

An IOTICS DiD ID:

did:iotics:76a3b24b02d34f20b675257624b0e001

Metadata

Metadata is “data” about the real asset this twin is a virtual representation of. Asset metadata is modelled using Semantic Web technologies. Metadata consists of:

a set of properties expressed as “triples” like: “car 123, has manufacturer, Ford”.
a set of feeds representing what kind of data this twin is publishing. For example, “car 123, publishes, current speed”
a set of controls representing what kind of commands this twin is responding to. For example “car 123, receives, start/stop command”

Furthermore, feeds and controls also have properties describing metadata and properties describing the values published or received.

Metadata management is entirely handled within IOTICS.

The structure of the metadata is decided during the twin modelling phase and has very close overlap with Domain Driven Design and Semantic Data modelling.

Why Semantic Web: Modelling assets metadata using semantic web technology enables autonomous interoperability between twins. Twins can describe other twins and understand the “meaning” of the underlying asset. This happens if the modeller uses an ontology to underpin the definition of the twin metadata and that ontology is available and shared with other twins.

In practice, a twin’s metadata is stored in IOTICS using a triple store. In this example, the metadata refers to a wind sensor with a single feed emitting the measured wind speed in meters per second.

The value “did:iotics:76a3b24b-02d3-4f20-b675-257624b0e001” is the twin DiD. The name and description of the asset have been mapped to the twin’s label and comment.

The twin’s geo-location properties store the lat/lon of the location of the asset.

The twin is defined as being described as a weather station according to this ontology: https://www.w3.org/2005/Incubator/ssn/ssnx/meteo/aws#WindSensor and with a single feed (urn:uuid:fb1a4a4d-bb26-42ab-9f83-6892da93f101).

This feed is defined as measuring velocity or speed, according to this ontology: https://purl.oclc.org/NET/ssnx/qu/dim#VelocityOrSpeed and it’s emitting data every minute (PT1M). The feed also emits a single value whose metadata is also expressed as triples.

The value emitted by this twin is a decimal with unit in meters per second as defined by https://www.ontobee.org/ontology/UO?iri=http://purl.obolibrary.org/obo/UO_0000094

This, in practice, means that over the feed, a single decimal value is published whose interpretation is driven by the value’s metadata.

Streaming data and controls

Streaming data and controls are the mechanisms twins use to communicate with each other.

Streaming data is used to broadcast to other twins both the asset’s status or new synthesised data that the twin generates..

Assets’ status data can be modelled either as “change event” or on a regular heartbeat.

On the other hand, controls allow a twin to send requests to another twin. These controls can be used to trigger specific behaviour of the twin or as actuators on the real asset for the purpose of changing the asset internal status.

Separation between data plane and metadata planes

Twins manage their own metadata and data separately.

Metadata about an asset may exist independently from the asset itself so it can be created before the asset or outlive the asset itself. Moreover, metadata makes the twin findable and interoperable: other twins search for metadata attributes.

Data represents the status of the asset and exists with the asset. Access to data is controlled differently from access to metadata.

Behaviour and autonomous interoperability

Behaviour is the custom logic implemented by the twin to:

Manage metadata in IOTICS
Synchronise the assets’ with its digital counterpart.
Follow other twins’ data and process it
Handle commands sent by other twins

In IOTICS behaviour is implemented in an “agent”: a software program that can connect on one end to the real world and to the other end to IOTICS. Agents have an identity also implemented using decentralised IDs.

In fact, when talking about autonomous interoperability between twins, we refer to the ability to program an agent to be entirely (meta)data driven: finding other twins, understanding -via semantics- the meaning of what data they publish and being able to process such data.

In game analogies

We can now expand our game analogy to map these concepts to our practical example.

Let’s start from the agent being the software running in the console – controlled by the player. Clearly the analogy may look a stretch (but maybe not) The agent (software/player) has its own identity in the network which is separate from that of the twin/avatar itself. In fact it may well be possible to imagine multiple twins/avatars managed by the same player/software or multiple players/agents connected to the same console and into the network.

The manifestation of the avatar in the game is entirely controlled by the agent running in the console

Each entity involved has its own unique identity resolvable within the network for parties to interoperate.

Metadata and data have obvious parallels with the player/avatar profile and current status of the player. Worth noticing that once a player is “registered” within the network, their metadata is accessible irrespective of the actual player being connected or not. This provides a parallel with the separation of data and metadata.

The model/analogy works even scaling to multiple players connected to the same console or to the same network.

Conclusion

IOTICS offers a novel approach to data sharing based on virtualisation, symmetry and secure interactions.

All three of these concepts contribute to making IOTICS a secure platform for data sharing and exchange that fosters the creation of ecosystems across enterprise boundaries.

In this part we explored Virtualisation, specifically how, in IOTICS, assets are represented as Digital Twins: virtual representations of the asset: a digital twin references metadata semantically describing the asset, it contains feeds for the asset’s data and controls for changing the asset’s status.

In the next part we’ll explore Symmetry and how it simplifies secure and reliable interoperability.