Digital Twin Patterns (DTPs)

What are Digital Twin Patterns (DTPs)?

Patterns offer guidance and a common language when designing or architecting software solutions. They don’t necessarily map the executable code exactly, they are not exclusive, and a real solution is often a combination of one or more patterns that may evolve over time.
The tables with the patterns below offer guidance on how to design and architect applications that leverage IOTICS’ unique capabilities. We have included in this guide the most common DTPs and we invite you to check out the whole list here.

Definitions

We distinguish 4 categories of DTPs, according to what they describe, as you'll see below.

Twin Role

These patterns describe the role Twins may play in applications.

	Representation	Publishes feeds	Follows feeds	Sends inputs	Receives inputs	When to use it
Publisher	A Twin with one or more feeds publishing data.	Yes	No	May send	May receive	To publish data periodically or per event.
Follower	A Twin that subscribes to one or more feeds for the purpose of receiving data. It may also have inputs to receive data.	No	Yes	May send	May receive	To receive data.
Synthesiser	A Twin that publishes one or more feeds with synthesised data. You can say it’s a Twin that combines the Publisher and Follower functionalities.	Yes, at least one	Yes, at least one	May send	May receive	To provide an asset with extra functionality, such as new feeds that work as an aggregation of existing feeds. To simulate the status or status changes of the asset.
Shadow	A Twin that replicates the Metadata and/or Data of another Twin. In other words, a Shadow is a Twin whose asset is another Twin.	May publish	May follow	May send	May receive	To provide a stub or a simulation of an existing Twin. To throttle or anonymise the data published. To partition security and access control to feeds and Metadata selectively.

Click to see a Publisher Twin representation

Click to see a Follower Twin representation

Click to see a Synthesiser Twin representation

Click to see a Shadow Twin representation

Twin Structure

These patterns describe how Twins can be structured to fulfil certain roles.

	Representation	When to use it
The Comb	The Comb is a Twin with lots of feeds, where each feed has a single value.	To structure Twins with many feeds, where each feed has a single value.
The Brush	The Brush is a Twin with a single feed having many values.	To encapsulate into a single payload asset data that is highly cohesive and with the same structural properties.
Data Bypass	A Twin's metadata contains a URL or link to a data set or data source external to IOTICS. A Twin that exposes an input where another Twin can send a request for an authentication token. This token will be used by the caller to retrieve the data out of band using a custom authentication mechanism.	To provide access to data out-of-band in those situations where an in-band transfer is not appropriate for performance or security reasons.

Click to see a representation of The Comb structure

Click to see a representation of The Brush structure

Click to see a representation of a Data Bypass structure (unauthenticated data access)

Utilisation

These patterns describe the Digital Twins’ basic functionalities.

	Representation	When to use it
Find&Bind	The basic data access pattern that a Follower Twin implements to discover one or more twins of interest.	To find and access other Twins’ Metadata and Data.
Share code	Extracting information from other Twins when data sharing isn’t possible.	To allow exposure of private data to algorithms and logic that extract information, minimising the risk of exposing or transferring sensitive data.

Click to see a Find&Bind representation

Click to see a Share code representation

Application Architecture

These patterns show how ecosystem applications across multiple IOTICSpaces can be architected.

	Representation	When to use it
Hub&Spoke	Twins representing the Hub use the Find&Bind Utilisation category, dynamically, to discover useful data over time and space.	To discover useful data over time and space.
Mesh	Each Twin is accessible to other Twins based on the brokered interaction mechanism provided by IOTICS.	Each agent/application implements its use cases or, when multiple agents/twins cooperate they behave akin to multi-agent systems.
Data Marketplace	An online place where data can be found and accessed under predefined conditions. Data can be bought, sold and exchanged under predefined governance rules. Access to the Data Marketplace can also be controlled.	To be able to control who can see, access and exchange data with the Twins.

Click to see a Hub&Spoke representation

Click to see a Mesh representation

Click to see a Data Marketplace representation

Use Cases

Hub&Spoke application model using a Find&Bind approach

An Electric Vehicle (EV) is going on a journey from London to Birmingham and will need to recharge at the beginning of the trip.

Once the vehicle’s battery is empty, the vehicle, as a Follower Twin, will dynamically search for and follow Feeds from several EV Chargers. The EV Chargers are Publisher Twins modelled as Combs, providing location and type as metadata as well as multiple data feeds with information such as availability and price.

The car, in this scenario, finds all the available Type 2 EV chargers in a radius of 32 km and by following (“binding to”) their feed, the vehicle receives data about their current availability and price.
Additional logic can then be implemented on the Electric Vehicle Twin to decide the best EV Charger based on its location, availability, and price.

Office Building Pattern - A Mesh application model

An office building in the city centre wants to control the temperature of each of its 3 floors using Radiators.
It has Temperature Sensors and Motion Sensors installed to monitor the environment in real-time and act accordingly. For this purpose, Publisher Twins of each Temperature Sensor and Motion Sensor were created.

The Temperature Sensors continuously publish their temperature reading in Celsius as a Feed. The Motion Sensors detect the occupancy of the floors and publish the occupancy as true/false as a Feed.
The Thermostat - a Synthesiser Twin - follows the feeds of the Temperature Sensors and the Motion Sensors. Its objective is to keep the floors at no less than 20°C if occupancy has been detected. It, therefore, sends an input message to the specific Radiator to turn itself ON or OFF, accordingly.

The Radiators are modelled as Follower Twins with an input to turn themselves ON or OFF. As soon as they receive the input message from the Thermostat Twin, they switch the real asset - the real radiator - on or off accordingly.