DIGITAL TWINS
WWW.MADEIN.IE « JANUARY 2021 « 33
series databases, and so on.
You can think of the data
digital twin as an evolution of
database technology. A twin is
the focus of the data for that
asset, be it metadata about the twin
itself, static data for the twin, real-time
data or an event stream. A twin is like a
row in a super-table, in a yet-to-beinvented
database which mashes all the
data for a real-world asset into a useable
form for the consumers of that data.
The need for semantics
Twins aren’t designed to be used by
individuals: their proliferation, power and
complexity of interrelations open up the
possibility of autonomous
interoperability, meaningful interactions
between systems and processes,
leveraging the power of event analytics,
AI and machine learning. Twins are
designed for a machine-readable world.
The semantic web was developed by
Tim Berners-Lee and others in the early
part of the 21st century. It’s not been a
huge hit in the internet of people, because
people actually understand semantics
intuitively - people don’t need to know
that this photograph is of a dog and dogs
are furry, it is to their eyes self-evident.
For machines, it’s another story, because
semantics have made a big diff erence to
web-crawlers. For example, in the case of
opening hours, mark-up from https://
schema.org/openingHours allows a
web-crawler to accurately interpret the
times in a website as the opening hours
for a restaurant, not as their phone
number.
This type of machine-readable
interoperability is important for twins in
a digital ecosystem. Twins need to
understand what the other twins are
saying about themselves in an
unambiguous way. The semantics that
describe a twin so that it can interact with
others progress from simple to complex
along this path:
a. What am I? What type of thing am I?
Am I a person, an engine or a
transport hub?
b. What can I do? What data can I
provide? What control interfaces can
you actuate?
c. Where am I? Geo-location, domain,
district, etc.
d. How do I fi t in?
This last one is the root of the Russian
Nesting Doll problem. Where does this
twin fi t into the digital ecosystem of other
twins? What is its context? What are its
relationships to those twins are they
simple or complex? Is there one
relationship or many?
Let’s consider a simple hierarchy. Cars
abstract away the complexity of
heterogeneous systems, APIs and data
formats and create a homogenous view of
the underlying world. With the correct
access control rights in place, interactions
can be brokered between the twins,
applications and sources of data and
allow control interfaces to orchestrate
change across the digital ecosystem.
But the complexity goes beyond twins
nested inside one another. A
simple hierarchy of twins
is not going to be
suffi cient to model
the real world. The
Russian Nesting
Doll analogy is
limited and not
everything is the
same ‘shape’. For
example, a train is
not a carriage, an
engine, or turbocharger
and they almost defi nitely
won’t be made by the same
company or be registered on the same
systems. Furthermore, not everything
nests one-to-one. A train might have
many carriages and there might be more
than one dimension to nesting.
Manufacturers make trains and operators
run trains, but manufacturers lease trains
to more than one operator and operators
run trains from more than one
manufacturer.
If we are to avoid the complexity that
comes from moving beyond parent and
child nested twins, we need to consider
how else we can map the interactions and
relationships without strict hierarchies.
Where have we seen the challenges and
solutions to these hierarchies before? In a
word: databases.
Evolution of databases
Originally, there were hierarchical and
network databases which required the
programmer to understand the structure
of the database and write the traversal
code to get to the data. This is
reminiscent of the emergence of
hierarchical twins, where the relationship
between twins requires an intelligent
understanding of the relationship
between the assets they are coupled with.
In early databases, paper-chasing code
polluted the business logic and led to the
development of the relational database
and SQL where the database code is not
part of the business logic - a ‘declarative’
approach. Now we have no-SQL
databases, graph databases and semantic
triple-stores alongside specialist time-
The twin-based
digital ecosystems
abstract away
the complexity of
heterogeneous systems,
APIs and data formats
and create a
homogenous view of
the underlying
world
/WWW.MADEIN.IE
/openingHours