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.

RepresentationPublishes feedsFollows feedsSends inputsReceives inputsWhen to use it
Publisher A Twin with one or more feeds publishing data.YesNoMay sendMay receiveTo 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.
NoYesMay sendMay receiveTo 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 oneYes, at least oneMay sendMay receiveTo 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 publishMay followMay sendMay receiveTo 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

2240
Click to see a Follower Twin representation

2483
Click to see a Synthesiser Twin representation

2275
Click to see a Shadow Twin representation

2533

Twin Structure

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

RepresentationWhen to use it
The CombThe 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 BrushThe 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 BypassA 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.

RepresentationWhen to use it
Find&BindThe 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 codeExtracting 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

1910

Application Architecture

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

RepresentationWhen to use it
Hub&SpokeTwins 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.
MeshEach 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 MarketplaceAn 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

1649
Click to see a Data Marketplace representation

1640

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.