Beyond IoT: Digital Twins and Cyber-Physical Systems

Summary Digital twins may be the buzz-phrase du jour, yet they first appeared, long before the current hype, as a highly specialized tool for aerospatial engineering or product lifecycle management: within these confines, they were…


Digital twins may be the buzz-phrase du jour, yet they first appeared, long before the current hype, as a highly specialized tool for aerospatial engineering or product lifecycle management: within these confines, they were understood as full-fledged numerical-simulation replicas of some physical contraption. They are now often understood, in a weaker sense, as digital proxies to the things they “twin”.

Full-blown digital twins are not merely CAD-originating or CGI-like representations of factory prototypes of things: they aim to be actionable simulations of actual instances of these things, in their real-world setting, mirroring their complete lifecycle evolution. In their more lightweight incarnations, digital twins are content to be just some kind of “digital one-stop shop”, providing unified and contextualized high-level interfaces for digital applications that need to interact, in all possible ways, with a physical thing, system, or system of systems. They may forsake the mirror-image & multi-physics simulation objectives of heavyweight industrial twins, yet they should, crucially, retain some of their instantiated and historicized representation features. This “digital-twin-lite” concept is the one we elicit and elaborate on, relating it to our Thing’in graph-based platform

Full Article

Digital twins originated from the special requirements of a few operation-critical systems in industrial manufacturing and automation. They aim at providing a comprehensive and accurate informational/numerical replica of some advanced apparatus, to optimize its operation and maintenance, especially when the original physical is not available for direct monitoring and physical inspection, like a satellite. From its origin in the aerospace industry, the digital twin concept has evolved and widened, to integrate remote sensing and actuation capabilities through the IoT.

A distinction is classically made between digital twin prototypes (DTP) and digital twin instances (DTI). DTP may evolve from a digital blueprint or CAD model, to make up a complete numerical replica of a physical product, used for simulations and possible fine tuning before it is manufactured. We are more interested here in DTIs as digital twins of actual instances of physical products, which may be embedded in larger systems that make up their environment, and evolve in parallel to their unique physical counterpart. Ideally, any information that could be obtained from inspecting a real product should be obtainable from its twin. Even though they may start from a DTP of a generic product, DTIs get uniquely identified as the twin of a single product instance and get differentiated through the accumulated history of contingent interactions of this product with its environment and its users. A key feature of DTIs is thus that they are not static descriptions or representations. They should evolve along all phases of the life cycle of their counterpart, design, manufacturing, operation, and disposal. They should also, crucially, be actionable in a way that mimics their physical counterpart, accounting for its environment and the systems it interacts with. A “Turing test” variant[i] has been proposed to gauge the fidelity of such a full-fledged DTI : this “imitation game” amounts for the twin to be indistinguishable, by inspection under multiple sensorial modalities, from its physical counterpart, and to provide, under controlled conditions, responses to input stimuli and observations of instantaneous state that would also be indistinguishable from responses originating from the physical product it stands for.

“Lite” Twins as proxies

In the minimal view of a digital twin, stripped of all the more advanced trappings of a “genuine” industrial digital twin as presented before, it can be seen as a mere informational proxy, maintaining key information about the physical thing  it stands for and serving as a monitoring/actuation interface to this system. The original phrase is often retained even if the corresponding model is strictly minimal or even non-existent.

Device Twins (DT)

This downgraded acceptation has implicitly been taken up in the IoT world, where the IoT/WoT interface to a connected device provided by a platform, however low-level, is often touted as a (bare-bones) digital twin of this device. This is a bit of a malapropism when this interface does nothing but forward from the device a stream of raw data, which may even be encrypted! It is more relevant when the device is not just a dumb sensor and encapsulates both sensors and actuators (like, e.g. a connected home appliance). In this case, an IoT-style twin may correspond to what a smartphone app for this device enables, encapsulating at least a simple state-machine-like model, conditioning potential actions on the current state of the appliance.

Thing Twins (TT)

Networked IoT devices, as exposed by the current IoT/WoT networks and platforms, are but the core set of physical entities to be “twinned”. The description of physical environments grows orders-of-magnitude richer by linking, through these primary nodes, all kinds of non-directly-connected “things”, be they pieces of furniture in a building, trees in a park or water pipes in a city. The only requirement is that these things are individually monitored by networked sensors, and/or possibly controlled by networked actuators, both of which are “twinned” connected devices as explained before. This is what we proposed to call a “phenotropic” or “stigmergic” link, making up an extended internet of Things, beyond connected devices. Both these non-connected things and devices may be seen as atomic or black-box physical systems, represented by one digital twin that captures their interfaces, their properties, and possibly their state, as part of a self-contained piece of software that maintains this digital representation. We propose to use the phrase “Thing Twins” (TT for short) to capture the nature of these representatives of things that are captured as “atomic”, meaning their component subsystems are not represented in turn as full-fledged twins.

System Twins (ST)

The classical and extended IoT viewpoints presented before, focused on atomic devices and “things”, are insufficient to capture the relevant system-level structure of IoT environments, encompassing all nested and intertwined subsystems of the overall referent system, such as e.g. security or HVAC systems within a building, water distribution, lighting or traffic management systems within a city. We need to match each of these systems to a different species of twins, which we propose to define as “System Twins” (ST for short).

Just as for device twins and thing twins, these “system twins” are not fully-fledged digital twins (in the original sense of the phrase) of the systems they stand for. They capture only a few key structural features of these systems as the inter-relationships and properties of their components, together with, crucially, their own inter-relationships with peer systems at the upper level of nesting.

This level of description does broadly match the notion of Cyber-Physical Systems (CPS), which were originally defined as the evolution of traditional (closed) industrial control systems in the era of open networks. They started from classical industrial systems that were not only closed, but also designed in a 100% top-down fashion, with every component and subsystem exactly fitted as a part of the overall tightly-coupled system they made up. The integration of CPS with open networks and platforms inherited form the IoT is the stage we are in now, which will also widen the narrow range of present-day IoT as it started from consumer devices and mostly upwards (sensor-originating) data collection, towards more integration with actuators and real-time control.

System of System Twins (SoST)

A graph comprising nested “System Twins” and underlying “Thing Twins” could be seen, at its own level and scale, as an overarching “System of Systems” twin. Unlike the digital twin of a top-down-manufactured system, it cannot start its life as one instance of a common blueprint, because there does not exist, by definition, any such blueprint for a system of systems. The system of systems twin graph has to evolve incrementally and organically, from the bottom-up, as the aggregation and interconnection of partial information from its “Thing Twin” and “System Twin” nodes.

IoT environments (e.g. buildings, industrial, cities) bring together multiple data sources (e.g. sensors) and data users (IoT/CPS applications), for which this environment is both a physical anchor and a common denominator. A comprehensive model of this environment is indispensable to support the sharing, consolidation and enrichment of this data and to avoid that each of these applications remain custom-designed and vertically integrated, within its own silo, using its own exclusive data sources.

The evolution of CPS towards systems of systems (which we may venture to call CPSS) is just as crucial as the preceding evolution from closed control systems to open CPS: moving from traditional top-down-designed systems to bottom-up-assembled, open and loosely coupled “systems of systems”. In a proper sense, systems of systems such as cities or large buildings are the engineering counterpart of “complex systems” that have emerged since the 1980s as a far-reaching transdisciplinary concept from physical, biological and social sciences.

And this is where the graph idea is creeping in again! Graphs have been, since the consolidation of the “Network Science” domain in the 1990s, a foundational model for the analysis of complex systems. They should also become a pivotal model for the analysis and operation of systems of systems. These models are not, by any means, intended to replicate the whole system in a digital twin fashion: they only capture relevant interdependencies between subsystems to support the analysis of potentially unforeseen emergent phenomena that may result from the interworking of systems that had not been designed to operate jointly.

Conjoining “Thing Twins” (TT) and “System Twins” (ST) in a multiscale Graph

The example from Figure 1 shows how “TT” nodes that stand for individual physical entities, i.e. things and devices (black rectangles) are captured in a graph, together with their mutual relationships (black diamonds) and their properties (black ovals for the predicate/key of the property, hexagon for the target value).

Subgraphs of the overall TT (black) graph corresponding to relevant sub-systems are matched to “ST” nodes of the overlay red graph through the “isNodeOfGraph” special relationship (red diamond). This relationship applies to all nodes in the corresponding subgraph, yet is shown only once to avoid cluttering the diagram. ST nodes are themselves caught in graph relationships, such as the relationship expressing that the city traffic management system may impose constraints on the traffic-light management system, or the inclusion of these (distributed) systems into the overarching graph capturing the Smart City as a system of system through the “isSubGraphOf” relationship.

Figure 1: Smart City Graph example

Graph models of choice for capturing system twins

An adequate graph model for the representation of IoT/WoT environments at large as Cyber-Physical Systems of Systems should have a sufficient level of expressivity to match the structure of these environments. CPS graphs have a kind of similarity-based semantics when they are meant to mirror the structure of a physical network such as e.g. a transportation network. These semantics apply to the graphs as a whole and are not reducible to the kind of “per-resource” semantics, which RDF is meant to describe. The choice made by the Thing’in project , endorsed by the ETSI CIM group for the NGSI-LD Context information management data model, is that property graphs are the best existing meta-model for capturing these CPS graphs. Property Graphs are a class of directed, labeled & attributed multigraphs, informally defined as the common denominator model of graph databases. Until the definition of the NGSI-LD meta-model by ETSI, they lacked a standardized formal grounding, having emerged from the use of database practitioners as a compromise to retain familiar key-value or object primitives within a graph. Property Graphs make it possible, crucially, to single out as relationships (and thus first class citizens of the meta-model) those arcs that represent actual physical linkages between physical entities, themselves represented as nodes. Mere properties (corresponding to OWL “datatype properties”) are directly attached to both entities and relationships as attributes would be in an object-based model. Paradoxical as it may seem, in a property graph, properties are usually not represented as arcs of the graph proper! This keeps the graph uncluttered and “clean” to feature saliently what matters the most: relationships as representations of physical connections between entities that make up the structural scaffolding of a system. This makes it possible to run graph-theoretical algorithms that rely on this structure: these can be extremely classical algorithms like maximal flow computation or complexity analysis tools such as evaluations of average path-lengths or degree distributions, or more sophisticated tools from spectral graph theory.


It has by now been widely understood and accepted that most physical systems are due to evolve towards becoming cyber-physical, at different scales and levels. Our view is that most cyber-physical systems are also evolving towards becoming systems of systems, at different scales and levels. The proposed multiscale digital-twin-graph-based representation is intended to account for this key evolution. Comprehensive as it may be for what concerns the physical environment, this system-structure description does not include persons, their roles or legal entities. This would obviously be useful, if only for technical reasons (associating administrative roles to various stakeholders or contractors operating the corresponding subsystems), but this is not included so far in the public part of the Thing’in graph. A coupling to regular social graphs (with e.g. links to passers-by in the streets) would raise daunting privacy issues and is, for these reasons, not considered, even if the hybrid triplicate graph resulting from the combination of cyber-physical graphs, knowledge graphs and social graphs could be an even more far-reaching incarnation of the “Giant Global Graph” contemplated by Tim Berners-Lee.


We acknowledge the invaluable contributions of all our colleagues from the Thing’in Orange Labs integrative platform project who have implemented in a graph-database-enabled platform the multilevel twin concepts presented here and their accompanying enablers. We acknowledge as well the contributions of the partners of the ETSI CIM (Context Information Management) Industry Specification Group with whom we have evolved the NGSI-LD property graph information model used for this project.

[i] called “Grieves Virtuality Test” (GVT) by Michael Grieves, one of the originators of the Digital Twin concept.

Read also on Hello Future

Thingin scan and scale

Scanning and scalability are the two challenges facing a global directory of things


The future of smart buildings with Thing’in


“Transition techs”, a new kind of commitment


The Internet of Things: beyond the hype