0% found this document useful (0 votes)
133 views32 pages

A Flexible and Modular Architecture For Edge Digital Twin

Uploaded by

chethanar2023
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
133 views32 pages

A Flexible and Modular Architecture For Edge Digital Twin

Uploaded by

chethanar2023
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

A Flexible and Modular Architecture for Edge Digital Twin:

Implementation and Evaluation

MARCO PICONE, MARCO MAMEI, and FRANCO ZAMBONELLI, Department of Sciences


and Methods for Engineering (DISMI), University of Modena and Reggio Emilia, Italy, IT

IoT systems based on Digital Twins (DTs) — virtual copies of physical objects and systems — can be very
effective to enable data-driven services and promote better control and decisions, in particular by exploiting
distributed approaches where cloud and edge computing cooperate effectively. In this context, digital twins
deployed on the edge represents a new strategic element to design a new wave of distributed cyber-physical
applications. Existing approaches are generally focused on fragmented and domain-specific monolithic so-
lutions and are mainly associated to model-driven, simulative or descriptive visions. The idea of extending
the DTs role to support last-mile digitalization and interoperability through a set of general purpose and
well-defined properties and capabilities is still underinvestigated. In this paper, we present the novel Edge
Digital Twins (EDT) architectural model and its implementation, enabling the lightweight replication of
physical devices providing an efficient digital abstraction layer to support the autonomous and standard col-
laboration of things and services. We model the core capabilities with respect to the recent definition of the
state of the art, present the software architecture and a prototype implementation. Extensive experimental
analysis shows the obtained performance in multiple IoT application contexts and compares them with that
of state-of-the-art approaches.
CCS Concepts: • Computer systems organization → Distributed architectures; Embedded and cyber-
physical systems; • Software and its engineering → Designing software;
Additional Key Words and Phrases: Digital Twin, Internet of Things, edge computing
ACM Reference format:
Marco Picone, Marco Mamei, and Franco Zambonelli. 2023. A Flexible and Modular Architecture for Edge
Digital Twin: Implementation and Evaluation. ACM Trans. Internet Things 4, 1, Article 8 (February 2023),
32 pages.
https://doi.org/10.1145/3573206

1 INTRODUCTION
During the last decade, due to the dynamic and quick Internet of Things (IoT) technological
evolution, several applications opened to the possibility of merging in real-time the physical and
the digital worlds. This scenario became attractive both for the Academia and the Industry, revital-
izing the concept of Digital Twin (DT) originally introduced between 1999 and 2002 [75]. A DT
provides a virtual copy of a physical object mirroring all its sensors, actuators, data, and behaviours

Authors’ address: M. Picone, M. Mamei, and F. Zambonelli, Department of Sciences and Methods for Engineering (DISMI),
University of Modena and Reggio Emilia, Italy, Via G. Amendola 2, Pad. Morselli, Reggio Emilia, Italy, IT, 42122; emails:
marco.picone@unimore.it, marco.mamei@unimore.it, franco.zambonelli@unimore.it.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee
provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and
the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored.
Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires
prior specific permission and/or a fee. Request permissions from permissions@acm.org.
© 2023 Association for Computing Machinery.
2577-6207/2023/02-ART8 $15.00
https://doi.org/10.1145/3573206

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8
8:2 M. Picone et al.

in real-time through an efficient bidirectional communication. DTs enable device simulation, ana-
lytic, and intelligent functionalities augmenting the features associated with the original physical
device. As reported in [14] DTs have been also classified as one of the top 10 strategic trends of
the last years and the forecast previews that their market will reach 35 billion USD by 2025 [44].
The combination of IoT and digital twins has been traditionally approached through cloud-
driven and domain specific architectures with a reduced interoperability and modularity. On the
one hand, this generates some isolated interesting applications in disparate fields but, on the other
hand, it limits the real potential of DTs and IoT by creating an unnecessary substrate of heteroge-
neous implementations [74]. Latency and reliability issues may also introduce disruption to DTs
since the linkage between the physical and the logical object is effective only if the refresh time is
lower than the average access time of applications using the twin. DTs cannot be delegated only
to the cloud but should instead be handled as close as possible to the physical devices in order to
maximize their efficiency.
Fog and Edge Computing [9, 12] paradigms allow overcoming these limitations enabling to op-
erate with ultra-responsive and ultra-reliable connectivity in multiple operational contexts. Edge
processing has already shown its fundamental role to handle the IoT heterogeneity through the
introduction on intermediate proxies and hubs responsible for handling objects and data streams
with a one-to-many relationship [20, 73].
The adoption of distributed DTs deployed on the edge recently started representing a funda-
mental pillar for cyber-physical applications [28] and already showed some interesting results in
the area of networking [15, 40], industrial deployments [10], intelligence [3], and simulations [37].
Despite these advancements, existing systems for deploying DTs on the edge are still mainly as-
sociated to a model-driven, simulative, or descriptive vision while their interoperability potential
is still underexplored and represents a relevant research’s area looking for a general approach for
achieving the integration of data and services in heterogeneous IoT edge deployments.
The contribution of this paper is to present and evaluate a new approach to model and imple-
ment digital twins on the edge – denoted as Edge Digital Twin (EDT) – and aimed at enhanc-
ing IoT digitalization and interoperability. The EDT architectural blueprint targets enriching the
current state of the art by exploiting the possibility of effectively operating side-by-side with a
Physical Asset (PA) in order to provide the following advantages:
• Define EDT as an active component in charge of encapsulating the responsibility to talk
with its physical counterpart and of modelling and defining how to digitalize and represent
it according to the target application’s goal and context;
• Provide an effective one-to-one digitalization where each EDT is responsible for managing
one PA by simplifying the underlying physical complexity by enabling a native and seamless
synchronization and observability of resources, properties, and functionalities;
• Augment PA’s capabilities with improved features or new behaviours that might otherwise
be difficult or inefficient to update on the physical entity due to processing constraints, soft-
ware limitations, security, and ownership. This capability is strategic to enable a flexible
heterogeneity management, to support interoperability and to extend the longevity without
the limitations to operate directly on the PA;
• Support composition through a uniformed abstraction layer allowing linking different EDTs
(and consequently PAs) into a new unified entity responsible for simplifying the representa-
tion of complex physical deployments and the interaction between external applications and
sub-components. The composition supports also the reuse of functionalities and together
with the augmentation capability enables the creation of new aggregated features;
• Overcome the constraints existing of monolithic architectures (where DTs are mainly envi-
sioned as passive entities) through a set of modular and loosely-coupled EDTs in order to
ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:3

enable twins distribution and manage domain specific processing and legacy customization
and to support scalable, observable and dynamic microservices deployments.
We emphasise that the proposed solution is meant to be complementary rather than in compe-
tition with existing edge modules and DT solutions (also in the cloud). The presented paradigm
shift aims to exploit EDTs to support last-mile interoperability through a flexible and effective
one-to-one management of the cyber-physical relationships without limiting it to a centralized
dispatching/proxying of packets but introducing the awareness about what to be digitalized and
how in order to provide an effective abstraction on the physical layer. Furthermore, the possibility
of decoupling responsibilities, extend functionalities, and work locally with real-time performance
allows supporting the creation of dynamic and interoperable long-running environments where
EDTs can work side-by-side with PAs cooperating with applications and other DTs across multi-
tier architectures.
The paper presents a detailed analysis of the current state of the art with a specific focus on
the adoption of DTs on the edge (Section 2), investigates the role and contribution of the proposed
EDTs through the actualization in the target context of the main cutting-edge DT’s capabilities and
properties [50, 51] (representativeness & contextualization, shadowing, augmentation, observability,
and composition detailed in Section 3). Furthermore, it introduces a first architectural definition
and implementation (Section 4) and experimentally evaluates EDTs performance in multiple IoT
application scenarios through a comparison with state of the art protocols and frameworks (on the
edge and in the cloud) in terms of the introduced overhead and delay, the resources consumption,
development complexity and flexibility (Sections 5 and 6). Finally, Section 7 presents a detailed
discussion of the proposed work and Section 8 concludes the paper and sketches future works.

2 STATE OF THE ART & MOTIVATIONS


The original DT concept [75] has been recently revisited due to the advent of the IoT and the
quick migration to a technological ecosystem where the effective collaboration between cyber
and physical layers represent a fundamental enabler for the next generation of applications. A DT
represents the digitised software replica of a physical asset with the specific responsibility to clone
available resources and functionalities, and to extend existing behaviours with new capabilities.
The analysis of the state of the art has been conducted through the definition of a methodology
composed of four stages: defining search keywords, contribution collection, contribution categori-
sation and collation, and contribution analysis. Search keywords comprise: “Digital Twin”, “IoT
Architectures”, “Industrial IoT”, “Edge IoT”, “Fog IoT”, and“Multi-access Edge Computing”. Due to the
wide nature of the topic, we selected together conferences and journal papers mainly related to
IoT/IIoT, networking, distributed and agent systems, manufacturing, and robotics with a partic-
ular focus on works related to the analysis of DT’s modeling, design, cyber-physical interaction,
implementation, and experimental evaluation. In general, we used Google Scholar to identify most
of the research material. Excluded contributions are mainly related to works where the usage of
DTs is marginal or associated to their adoption for product design or life-cycle management or for
2D/3D visualization and graphical representation techniques. Furthermore, in order to provide a
comprehensive analysis we extended our investigation and analysis by including also fragmented
interesting scientific manuscripts outside these main areas, research projects, standardization ef-
forts and existing open-source or commercial DT platforms.
With the aim to schematically analyze existing approaches and to highlight the research oppor-
tunities that we would like to address, we categorized analyzed contribution based on research
topics and a set of DT oriented evaluation criteria: (i) Pattern: defines if DTs have been modeled as
passive entities subordinated to external modules or as active components able to encapsulate and

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:4 M. Picone et al.
Table 1. Comparison of the Main State-of-the-Art References and the Proposed EDT Approach
Digital Twin Evaluation Criteria
Arch. Edge Domain IoT/IIoT Heterogeneity
Pattern Distributed
Level Evaluation Specific Oriented Management

Research Papers

[60] [72] [68]


[69] [40] [18] Cloud
Fragmented Researches [58] [28] [45] Passive Edge Partial No Partial No No
[16]
[43] [34] [76] Passive Cloud
Agents [22] [55] [71] Active Edge Yes No Partial No No
[46] [17] [29] Passive Cloud
DTs Ecosystems [59] [57] Edge Partial No No No No
Active
[79] [10] [11] Passive Cloud
Networking [35] [77] [56] Active Edge Partial No Partial Partial Yes

IIoT, Manufacturing & [42] [70] [21] Cloud


[36] [37] Passive Edge Partial No Yes Yes No
Robotics

Projects, Platforms & Standardization

[7] [30] [47]


Cloud Providers [5] [6] [48] Passive Cloud No No Yes No No
[31] [27] [26]
[1] [54] [25] Cloud
Research Projects [32] [2] Passive Edge Partial No Partial No No
[21] [79] [24]
Standardization Efforts [41] [52] [23] Passive Cloud No No No Partial Yes
[17] [49]

Proposed EDTs Active Edge Yes Yes No Yes Yes

to execute their application logic; (ii) Architectural Level: specifies if DTs have been envisioned as
cloud only component or if they can be adopted also on the edge; (iii) Distributed: points out if DTs
have been modeled as individual software components or aggregated into a centralized module;
(iv) Edge Evaluation: highlights if the proposed approach analyzes and evaluates DTs instance run-
ning on the edge with their performance and the introduced overhead; (v) IoT/IIoT Oriented: details
if DTs have been modelled or adopted to support IoT/IIoT application scenarios; and vi) Hetero-
geneity Management: labels solutions where DTs are adopted to support physical heterogeneity or
if they rely on external modules to interact with the physical layer. The resulting categorization
has been schematically structured and reported in Table 1.
We selected these evaluation criteria in order to conduct a structured review and analysis of
the current state of the art taking into account multiple sources such as scientific contributions,
research projects together also with market-ready platforms and efforts from the main standard-
ization bodies. Analyzed contributions have been grouped according to matching criteria in eight
different groups with the goal to better support the discussion and highlight at the same time ex-
isting positive trends and new research opportunities. Within the analyzed solutions, DTs mainly
results as passive entities co-located and centralized at the same architectural layer (typically the
cloud) and subordinated to external modules to control their properties, data, and behaviours. The
possibility of executing DTs as active entities on the edge together with the detailed evaluation of
their peculiarities has been only partially addressed through fragmented references and without
a detailed modeling and experimentation.

Fragmented Researches. Even if a set of core abstract definitions of DTs’ capabilities have been
recently envisioned in the literature [50, 51, 62], the research field attracted during last years a mul-
titude of excellent domain specific approaches where DTs have been modeled and characterized
through different heterogeneous and fragmented solutions related, for example, to data analyt-
ics [60], behavioral modeling [68], digital health [58], ontology definition [72], or specific device

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:5

mirroring [69]. In [18, 40] the authors present two interesting initial evaluations of edge DTs in the
specific contexts of blockchain technologies and Social Internet of Things (SIoT) while authors
in [16, 28, 45] described the importance of bringing DTs on the edge, highlighting the novelty
and the interest in this new research field with respect to different domains such as vehicular
applications and e-health. Despite this progress and individual research and company-based ef-
forts, certain gaps still exist in the field, which have caused delay in the widespread adoption of
this concept [63]. An extensive, clear, and detailed survey is reported in [8] where the researchers
studied and analyzed the state-of-the-art definitions investigating also the common characteristics
of DTs and the domains in which they are are currently being developed and adopted. Analyzed
approaches represents on the one hand interesting and valuable contributions to the field includ-
ing also some options to deploy twins on the edge. On the other hand, they are mainly domain-
specific, without a detailed focus on heterogeneity management and they only partially address the
challenges of proposing a general modelling for edge DTs together with a missing extensive eval-
uation. Furthermore, DTs have been mainly envisioned and deployed as passive components and
in most cases aggregated into a unique centralized architectural entity delegating the definition of
their behaviours to third-party applications and services.
Digital Twins & Agents. DTs are recently quickly gaining traction also in the Agent and Multi-
Agent Systems (MASs) as a brick to handle and engineering the relationships between cyber-
physical systems. Authors in [43] provide a detailed analysis of the opportunities and challenges
related to how these two peculiar software entities can cooperate to exploit the best advantages of
both solutions across different application domains. In [34] and [76] authors investigate the link
between DTs and agents through manufacturing and decision-making systems while in [22] this
relationship has been analyzed in the context of the healthcare domain. Works presented in [55]
and [71] propose to build DTs of real organisations and adopt agents to structure systems as an au-
tonomous, behaviour-centred perspective encapsulating decision making and intelligence capabil-
ities. Presented approaches represent appealing research contributions and directions envisioning
DTs not only as passive aggregate entities but also as active instances with specific behaviours and
potentially distributed at different architectural layers. Existing underexplored aspects are mainly
related to the missing detailed analysis and evaluation of edge DTs modeling in terms of capabilities
and responsibilities (also with respect to other DTs and agents) and how the DTs can effectively
support physical heterogeneity management within cyber-physical and IoT applications.
Digital Twins Ecosystems. A broader, pervasive and ecosystemic perspective about the DTs and
in general about the digitalization of the physical world has been proposed and shared with the
Gemini Principles as introduced in [46] and supported by the National Digital Twin (NTD) [17]
Project considering the opportunity of virtualising physical assets associated for example to build-
ings, sensors and connected devices in the country. In the literature, this pervasive vision has a
strong match also with the concept of mirror worlds (as software models of a portion of the reality)
presented in [29], and further explored and developed in the context MASs in [59]. As for DTs,
their primary objective is to exploit software tools and the associated functionalities abstract the
heterogeneity and complexity in order to simplify cyber-physical interactions. The same vision
applies to the new concept of Web of Digital Twins recently introduced in [57], which could be
considered a concrete approach to design and develop mirror worlds through DTs with a specific
analysis and modeling of the core DT capabilities and the associated life cycle. On the one hand,
presented approaches, perfectly match the envisioned ecosystemic view of DTs deployed across
multiple architectural layers and foster the idea of identifying capabilities and responsibilities to
shape and deploy interoperable DTs mainly as active entities. On the other hand, the analysis
and characterization of edge DTs modeling is not yet deeply investigated and/or experimentally

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:6 M. Picone et al.

evaluated and the idea of exploiting them as a dedicated approach to effectively support the in-
teraction and heterogeneity management of physical layer is still not tackled or detailed. The pro-
posed incremental contribution of this work is to focus our attention specifically on the role and
responsibilities of edge DTs aiming to understand and deeply evaluate how they can be modeled
and built to optimize their peculiarities, challenges together with performance and the introduced
costs.
Digital Twins & Networking. The application of DT approaches and technologies in the network-
ing field has been recently envisioned and introduced in [79] with the aim to develop various aug-
mented network applications to realize an efficient and cost effective data driven network manage-
ment in order to accelerate the definition of innovative services decoupled from the complexity of
the underlying communication systems. This idea has been also fostered in [10, 11, 35] where net-
work DTs have been adopted to support intelligent and network-aware application in industrial
application scenarios to enable dynamic QoS management and routing re-configurations. Other
network-oriented approaches [56, 77] investigate the relationship between DTs and Software De-
fined Networking (SDN) or Network Function Virtualization (NFV) with the aim to manage
heterogeneous deployment abstracting the physical layer. This dynamic trend and the combina-
tion of intelligent networking with DTs represent an appealing research direction that will gain a
lot of traction due also to the quick evolution of 5G and 6G specifications and software architec-
tures. The main differences with the proposed approach is that DTs have been mainly approached
as passive centralized entities (only in some cases DTs are modeled as active and interoperable
components) and that analyzed solutions are strictly domain specific in the context of networking
without a generalized modeling and characterization of the responsibility and peculiarities of edge
DTs. Furthermore, a detailed analysis of the performance and the overhead associated to the de-
ployment of the DTs on edge facilities is still not fully explored yet even if the idea of distributing
twins across multiple architectural layers became relevant for networking infrastructure.
Digital Twins & Industry. The industrial world and in particular the Industrial Internet of Things
Consortium is proposing a shared reference architecture [21, 42, 70] taking in to account DTs re-
lationship, composition, and main services (e.g., prediction, maintenance, safety). Similar works
have been done by the Robotics and Robot Operating System (ROS) [36, 37]. The limitations of
the existing IIoT solutions are mainly related to their specificity for a target application domain
and the adoption of passive aggregated and centralized DTs together with the missing detailed
definition and evaluation of how edge DTs should be modeled, implemented, and deployed. On
the other hand, in the manufacturing and robotics field the pathological introduction of domain
specific DT oriented approaches increases the overall data and protocol ramification and conse-
quently makes it extremely difficult to create an ecosystem where devices, services, and users can
efficiently work together through interoperable and standard technologies. Furthermore, with re-
spect to these categories, DTs are mainly approached as passive components relying on external
modules to shape their behaviours and without any evaluations of their applicability as indepen-
dent entities (also on the edge) with the consequence of only being reference data structures for
PAs.
Cloud Providers & Research Projects. The state of the art historically confirmed the importance
of an efficient edge processing and heterogeneity management in IoT applications. Progressively,
intermediate proxies and hubs concentrated the authority to handle connected things and data
streams [20, 73] in order to solve heterogeneity issues in IoT deployments. The main difference
between these components and edge digital twins is that they provide a one-to-many aggregated
management and a single application logic focused only of forwarding packets and translating

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:7

protocols without taking into account the possibility of distributing responsibilities among mul-
tiple loosely-coupled and scalable components. On the other hand, a DT can be also a dynamic
software entity with a symbiotic connection with its physical counterpart and that is able not only
to support interoperability by shadowing the original properties but also to mirror behaviours, to
provide augmented functionalities and to abstract the composition of the physical world hiding
its complexity to applications.
In this challenging context, it is clear that the linkage between the physical and the digital object
is the key feature of DTs and their effective shadowing capabilities. The need to always rely on In-
ternet connections and the strong dependency to cloud services can generate critical issues related
to the real-time collection and processing of large quantities of data making it difficult to design
effective DTs’ oriented services and interaction models. Unfortunately, existing DTs’ approaches
are principally focused on a cloud-driven design and providers like Amazon, Google, Azure, Bosch
and Eclipse Foundation [7, 26, 27, 30, 47] already consolidated their own implementations and and
only recently tried to move processing and analytics workloads on the edge [5, 6, 31]. The limita-
tions of these approaches are mainly associated to the adoption of legacy communication patterns
forcing the introduction on the edge of intermediate components such as hubs and gateways re-
sponsible to securely exchange data and commands with a cloud only DT representation. Existing
solutions are primarily based on the centralization and aggregation of DTs as passive entities where
they do not implement any model or active behaviour failing to encapsulate the physical counter-
part and delegating the responsibility of the contextualization and synchronization with the PA to
external components. Furthermore, the possibility of adopting DTs on the edge in order to handle
the last-mile heterogeneity is totally unaddressed and not evaluated, and even if it is theoretically
possible to deploy some cloud-oriented solutions (e.g., Eclipse Ditto) also on the edge, there is the
concrete risk to introduce unnecessary delays and force the overall architecture to a monolithic
vision of DTs (see Section 6).
Recent research projects such as 5G-CORAL [2] and 5G-DIVE [1, 32] projects are also propos-
ing hierarchical architectures supporting distributed computing infrastructure by taking also into
account DTs’ role to enable Industry 4.0 and autonomous drone use cases. In [25, 38] twins are
instead adopted in the 5G automotive context to enable a real-time mirroring of active vehicles in
a target area of interest to analyze the environmental factors influencing the driving behaviors or
to predict the actions taken by the car. In the analyzed references, the role of DTs start assuming
an important position through different application scenarios and architectural layers with the
possibility also of deploying them both on the edge and in the cloud. However, DTs are mainly
structured as passive entities subordinated to external components, and a detailed and proper def-
inition and modeling of the role, capabilities, and responsibilities of edge DTs is still missing to-
gether with their extensive evaluation. Proposed approaches are mainly reasonably focused on
specific application domains and the possibility of adopting DTs on the edge to build an effective
and low-latency digitalization of the physical layer to simplify the innate existing heterogeneity
and fragmentation is still under investigated.

Standardization Efforts. Standardization organizations and consortia are actively working on


shaping interoperable cross-domain environments with respect to IoT, IIoT [21], networking [79],
and edge/cloud architectures [24]. In this context, DTs represent a new concept that starts appear-
ing in the standardization efforts and the associated proposals to enable simplifying cyber-physical
interaction. The World Wide Web Consortium (W3C) with Web of Things (WoT) [41] and
the oneM2M organization [52] are actively working to provide a uniform access and description
of physical assets to make the IoT standard and interoperable across multiple application domains
and deployments. The Digital Twin Consortium [23] and Digital Twin Programme [17], but also

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:8 M. Picone et al.

concrete contributions from specific companies such as the Digital Twin Definition Language
(DTDL) by Microsoft [49] (analyzed in details in Section 6.2), are trying to propose their point of
view to uniform DTs. Unfortunately, within these fundamental activities the definition of the role
of DTs is at an early stage with a lot of differences among the proposed solutions and a common
perspective of exiling DTs as marginal and passive cloud architectural components where the def-
inition of their behaviours is completely delegated to external software modules, and DTs appear
just as reference data structures to represent PAs. The possibility of envisioning DTs as active en-
tities operating also on the edge together with their detailed modeling and evaluation is still not
yet analyzed or experimentally evaluated.
EDT Contribution. The conducted analysis of the existing DT’s state of the art contributions and
research allows to highlight existing limitations with respect to edge approaches in terms of: (i)
fragmented design and modeling; (ii) adoption of monolith and centralized approaches; (iii) lim-
ited interoperability and delegated heterogeneity management; and (iv) internet dependency and
introduced delay. Nevertheless, despite the dynamic and quick evolution of research activities on
the topic and the high number of existing scientific and industrial contributions, important open
questions and research challenges are still under-explored and worthy of investigation. In this
context, the characterization of the role, capabilities, and responsibilities of DTs running on the
edge is still not well defined, structured, and experimented in the literature. Furthermore, the pos-
sibility of modelling and executing edge DTs as domain independent, interoperable, and as active
entities encapsulating a specific behaviour together with a set of specific functionalities, is new
and represents a research opportunity to envision a different category of DT-driven applications.
The focus of the presented work is to propose a different approach to overcome the existing
limitations with the aim to obtain an effective and generalized approach to obtain a last-mile dig-
italization and heterogeneity management through the deployment of EDTs operating as active
entities close their physical counterparts. Nevertheless, the proposal of a first detailed architecture
and implementation together with an associated extended evaluation represent a step forward to
understand the feasibility of an integrated ecosystem of distributed and pervasive digital twins.
EDTs are not meant to be a replacement of what is already available but can represent instead
an efficient glue between edge physical assets and digital services through a set of well defined
properties and capabilities in a vision where multiple twins can cooperate together in the same
environment, decoupling responsibilities according to their role and the associated architectural
layer.

3 EDGE DIGITAL TWIN - MODELING AND PECULIARITIES


The aim of the proposed EDT approach is first of all to provide a model and a structured definition
of the peculiar responsibilities of DTs running on the edge envisioned as active interoperable enti-
ties, aware of the characteristics of the target physical assets and responsible for their digitalization
and exposition to the cyber world. In this section, we present a detailed modeling and characteriza-
tion of the core EDT’s capabilities and responsibilities (depicted also in Figure 1), while in Section 4
we describe how the proposed design has been mapped into a reference architecture and imple-
mentation. The identified general and abstract fundamental capabilities (recently envisioned in
[50, 51]) that should be analyzed to characterize and EDT are the following:
Representativeness & Contextualization. Defines how much the DT represents and accurately
measures its physical counterpart with respect to its context and design goal in terms of: (i) Prop-
erties: data fields that represent the state of an entity (e.g., the temperature value or the status of a
switch); Events: asynchronous happenings associated to the physical asset such as an overheating
condition or the notification of a software update; (iii) Behaviours: actions that can be performed

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:9

Fig. 1. The role of our EDTs in each of the fundamental DT’s capabilities and operational phases.

by or on the physical asset to change its status or its functioning (e.g., a toggle to turn on and off
the light); and (iv) Relationships: represents how a DT map links and connections among assets at
the physical layer such as a light bulb inside a room belonging to a building floor.
EDTs operate as independent entities close to the physical layer aware of the characteristics
of the target asset and thanks to their internal behaviour they can support a fine-grained
representation and contextualization deciding which characteristics of the PAs should be cloned
according to the target operational context or application goal. If the same DTs are modeled as
a cloud only entities or through a centralized/aggregated approach they would fail to implement
and encapsulate the presented capability being completely unaware of the physical deployment
and they will necessarily require additional intermediates components to handle the process.
Shadowing. It is the process used by the DT to keep its state aligned and updated with the
corresponding PA according to the modelled behaviour (e.g., mirror only a subset of the available
functionalities or properties) and the characteristics of the physical target (e.g., the use of standard
or legacy protocols). The existing challenge is related to the heterogeneity of the PAs and how the
physical-digital mapping can be handled by a DT.
EDTs internally implements the shadowing procedure and the responsibilities to locally oper-
ate and communicate with the associated PAs, enabling an active pattern where each twin has
the full control of its decisions. This approach allows also to immediately manage heterogeneity
and support interoperability through the adoption of uniform and standard protocols and data for-
mats with low-latency performance. Any change in the state of a PA will be captured by the EDT
through a dedicated physical adapter (see Section 4) at the most appropriate level of abstraction.
At the same time, EDTs are also responsible for translating external incoming actions and mes-
sages and forwarding them to the PA in order to keep the two counterparts always bidirectionally
synchronized. Consequently, external applications and consumers can interact directly with the
EDT without handling or even knowing the complexity required to talk with the associated PA.
Observation. It is the capability to allow external applications and services (also other DTs) to
detect every relevant change in the state of the PA and the DT, monitor the behaviours, and collect
generated metrics and events. The possibility to observe a DT represents a fundamental require-
ment in order to envision an open-system where connected, interoperable, and pervasive applica-
tions and DTs can operate and collaborate in distributed and microservices oriented deployments.
EDTs are responsible for detecting and translating physical raw data into more fine-granular
and contextualized data, events, and insights making them available to applications and services

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:10 M. Picone et al.

observing from the digital layer. This native EDTs capability avoids the introduction of additional
intermediate components and enables a direct observability of the digitalized assets integrated
also with specific EDTs resource and application layer metrics related, for example, to memory
consumption or run-time and communication exceptions.
Augmentation. PAs come with a well-defined set of functions that are fixed for their entire life
cycle and even if they do not have processing constrains they may have update limitations due to
dependencies, security, and ownership. This capability is adopted to modify, update, and improve
the PA’s functionalities over time through the implementation of new low-latency behaviours and
communication patterns.
EDTs are active entities capable of modelling augmentation as an internal core capability al-
lowing to natively support the definition and injection of new functionalities directly on the twin
through a flexible and modular architecture and without the need of any external component. This
approach allows digital services (applications and other DTs) to easily exploit EDT behaviours
interacting with a uniform abstraction layer hiding the physical complexity and providing the
desired local capabilities with the best performance.
Composition. It represents the ability of a DT to abstract the complexity of a larger system and
to focus on a few relevant properties and functionalities without having the knowledge of all the
entire system and the need to consider the functionalities of all the aggregates’ sub-components.
Multiple levels of abstraction and composition can be envisioned according to the target use case
and and the application’s goal.
EDTs are aware of the local cyber-physical complexity and can enable representing both the re-
lationships existing in the physical world (e.g., sensors in a building) as well as to carry out oppor-
tunistic and dynamic digital collaborations (e.g., the DT of a technician interacting with the DT of
an industrial equipment). The possibility to handle this composition internally on the EDT and di-
rectly on the edge reduces the latency and the application’s complexity by simplifying the resulting
architecture and allowing external components to immediately interact with target aggregated en-
tities without handling or even knowing the complexity of the underlying deployments. Through
EDTs we can build new interoperability patterns where things and services can seamlessly coop-
erate without any prior knowledge or configuration and supporting different scopes, visibility and
granularity according to the application domain, the modeled use cases, and the data consumers.

4 ARCHITECTURE & IMPLEMENTATION


Following the above presented modeled capabilities, in this section we introduce the designed
EDT’s architecture and its first implementation in Java. As schematically illustrated in Figure 2,
the base layer of the proposed architecture is represented by the Core Engine (CE) responsible to
shape the EDT’s behaviour and all its capabilities and responsibilities through the execution and
coordination of the following sub-modules:
• Communication & Protocol Manager (CPM): defines the communication capabilities
of the EDT (with both the digital and physical layers) through the execution of multiple
adapters allowing the implementation of both standard protocols and patterns (such as the
RESTful interaction with CoAP or a Pub/Sub and broker-based communication through
MQTT) and/or domain-specific solutions. The number and the typologies of active adapters
can change over time allowing to introduce the support for new protocols and interaction
forms;
• Resource Manager (RM): enables the discovery of the available resources on the PA (e.g.,
sensors and actuators) through the functionalities provided by the CPM and handles their
selection, digitalization, enrollment, and maintenance on the EDT;
ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:11

Fig. 2. EDT’s architectural structure with built-in managers, modules, and components to flexibly model and
deploy twins.

• Data Manager (DM): implements dedicated features to support data processing and storage
related to incoming and outgoing packets and messages (through CPM and RM) associated
to both the physical and the digital layers. Furthermore, it allows the EDT to model and store
its internal data structure composed by properties, relationships, and supported actions;
• Behaviour Manager (BM): provides the possibility to execute multiple independent
functions on the EDT to shape the envisioned behaviours and achieve the target application
goal. Through the interaction with other components (CPM, RM, and DM), each function
can be triggered and associated to a specific EDT’s event (generated by other modules) such
as the update of a resource on the PA or the incoming request from an external application;
• Composition Manager (CM): structures and manages the links among both PAs and EDTs
through the definition of parent-child and composition relationships allowing also the
navigation among linked entities through an interface exposed by the CPM;
• Metric & Logs Manager (MLM): provides a set of shared and structured functionalities to
easily track, collect (from all the other modules), and send all the relevant twin’s metrics
and logs in order to support the observation of the running EDT with the aim to enable
monitoring, diagnostic, and detection of anomalies.
In the current implementation, the CE is defined through a Java-based multi-thread engine able
to simultaneously and effectively execute designed sub-modules as independent threads in order
to enable a modular and dynamic software solution to support multiple communication adapters
(also in real-time) with both the physical and the digital layers, and to shape the behaviour of
the target EDT. Each manager is modeled through a dedicated runnable object extending a base
class responsible for defining: (i) its internal life-cycle functionalities such as start, stop, restart,
and pause; (ii) a structured configurability where each module can require and use a set of dedi-
cated parameters and options; and (iii) a dedicated callback system to allow the CE to be aware of
modules evolution and potential malfunctioning (e.g., connection or disconnection from the tar-
get MQTT broker). Involved modules communicate internally through an asynchronous pattern
based on a shared message queue allowing them to: (i) subscribe to messages of interest through
to the definition of specific message filters; (ii) publish new messages, and (iii) be notified when a
new message matching the defined filter is available.
Each EDT’s module has also the possibility to attach to its core functionalities (e.g., the manage-
ment of an incoming packet from and external application or the response to a CoAP request on a
physical device) a chain of execution steps denoted as Processing Pipeline, allowing to personalize
the behaviour of the EDT without changing other reusable functionalities (e.g., the capability to
interact with an MQTT broker). Processing pipelines are modeled through dedicated classes and
data structures responsible for shaping the nature of input and output data of each step, the man-
agement of chain progression, and the detection of possible errors through dedicated callbacks

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:12 M. Picone et al.

and event listeners. The combination of the processing pipelines together with the capability of
the CPM to support multiple communication adapters at the same time allow the EDT’s architec-
ture to evolve over time by adding new components and functionalities. Once a new feature is
available and integrated within the presented architecture (e.g., the support for a new protocol or
a specific data format) it can be easily be re-used across multiple EDT instances without any addi-
tional development and through a dynamic configuration system, allowing the CE to load modules
of interest according to the nature of the target twin.
Nevertheless, from an execution and deployment perspective, the implemented EDT can be
executed both as independent Operating System’s Java process or packed into a container to
be executed on dynamic virtualized and microservices oriented environments as illustrated in
Section 5.5.

4.1 Modules Interaction & Capabilities Mapping


The combination of CPM, RM, and BM allows the EDT to define and implement its representa-
tiveness & contextualization, shaping how the EDT represents its physical counterpart. In particu-
lar, CPM and RM support the communication with the associated device(s) discovering available
properties, behaviours, and relationships according to the adopted protocols and data formats and
identifying physical interfaces associated to resources, measurements, and actions. On the other
hand, the BM defines the internal EDT’s model responsible for analyzing available information
and descriptions extracted from the physical layer and decides which physical aspect should be
digitalized in the twin with respect to its context and application goal.
The shadowing capability follows sequentially the previous one and it is responsible to effec-
tively create a bidirectional communication between the the EDT and the PA in order to build
and maintain an effective synchronization between the two counterparts according to the defined
EDT’s mapping and behaviour (e.g., maintaining updated only two sensors and one actuator avail-
able on the device.). The shadowing is mainly supported by the combination of the CPM, RM,
and DM where the first is in charge of the management of the heterogeneity and interoperabil-
ity for the physical layers through the implementation of the required communication protocols
dedicated to interact with the PA over time. RM and DM interact with CPM to support the shad-
owing to properly store and keep updated data and information related the mapping of digitalized
resources defining and building the status of the twin at a specific time.
The observation is instead granted by the combination of CPM and MLM. On the one hand, the
CPM implements communication protocols and adapters to communicate with external digital ap-
plication both through request/response and asynchronous interaction patterns, allowing external
services to be aware and notified about variations during the EDT life cycle (e.g., a measurement
has been updated, a new resource on the PA has been correctly enrolled, or the synchronization
with the device has been paused due to connectivity issues). On the other hand, the MLM shared an
additional set of methods to store and send metrics, and logs data about the real-time performance
and the operational flow of each active EDTs in order to support an effective monitoring, diagnos-
tic and balancing of active deployments (e.g., to estimate or handle the allocated computational
resources).
The possibility to extend PA functionalities through EDT’s augmentation capability is imple-
mented exploiting the features provided by the DM and the BM in charge of supporting modular-
ity and extensibility to the overall architecture. The DM is directly integrated with the the CPM
to allow the execution of a custom software processing pipeline applied to each incoming and out-
going packet according to target rules (e.g., the match of a specific MQTT topic). It can be used
for example to translate from a specific data format to another (e.g., from JSON to XML) or to
compress data before the forwarding to external consumers. Furthermore, the BM provides a set

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:13

Fig. 3. Operational flow for an Edge Digital Twin mirroring: (a) an MQTT physical asset using a dedicated
DT’s configuration specifying the list of target incoming and outgoing topics; (b) a CoAP IoT device through
the standard .well-known/core resource discovery procedure.

of shared, re-usable and extensible software extensions with the aim to easily integrate additional
behaviour on the EDT. For example, the implementation of an internal caching system or the in-
tegration with a third party cloud service can be easily designed and dynamically loaded in core
structure in order to maximize code reusability and to reduce the implementation cost.
A proper modeling of the physical layer requires the correct mapping of relationships among
PAs and the associated twins. The EDT implements composition using the functionalities and inter-
faces exposed by the CM in order to manage how and if the deployed entities are linked together.
EDTs can be dynamically linked together through the use of an external coordinator (aware of
the details of the physical deployment) or autonomously by using, for example, IoT service and
resource discovery technologies [19]. The resulting composed EDT can also expose additional
properties and functionalities through its augmentation capability in order to simplify the de-
scription and the interaction with the physical world (e.g., providing the averaged floor temper-
ature value and/or allowing to switch off all the lights in a target room with a single command).
Furthermore, without any prior knowledge or configurations, external consumers can navigate
through linked EDTs starting from the high level abstracted entry point (e.g., the EDT of the tar-
get building) in order to discover linked resources and functionalities matching their application
goals.
The interface is mapped into an HTTP RESTful (REpresentational State Transfer) API (Ap-
plication Programming Interface) for a simplified and standard interoperability, and the com-
posed resources and properties can be also exposed by each composed EDT using existing IoT
standards such as CoRE Resource Directory [66] or the WoT Things Description [61].

4.2 Built-In Support for IoT Protocols


A set of built-in IoT features are already available in the first implementation to provide an out-of-
the-box shadowing of both MQTT and CoAP devices through a zero-code configurability. The in-
troduction and description of these modules is also useful to show how an EDT can autonomously
handle the binding and the synchronization with its physical counterpart.
For MQTT (Figure 3(a)), the EDT acts both as a subscriber and publisher in order to allow a
bidirectional communication associated to device’s outgoing messages (e.g., telemetry or events)
and incoming packets from external applications (e.g., commands). Involved steps are: (1) The
twin subscribes on the things MQTT broker in order to receive messages and data from its phys-
ical counterpart; (2/3) Incoming and outgoing messages are exchanged between the two entities
through the available broker, and (4) the EDT forwards all the messages (with the same topics
structure) to a target destination broker potentially different from the previous one and dedicated
only to the interaction with external consumers.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:14 M. Picone et al.

Fig. 4. Experimental setup showing EDT’s standardization and heterogeneity features with legacy Philips
Hue & Ikea Trådfri smart lighting.

For CoAP (Figure 3(b)), the involved steps with a RESTful protocol like CoAP are: (1) the EDT
sends a GET on the standard “/.well-known/core” URI in order to retrieve the list of available re-
sources; (2) the smart object responds with the list of available resources using the standard CoRE
Link Format [64] and CoRE Interface [67]; (3) the EDT creates a digital copy of each resource keep-
ing the same standard descriptive attributes (e.g., id, URI, interface type, resource type, observ-
ability); (4) an external client sends a CoAP request to the EDT; (5) the EDT forwards the request
to the physical object with the same request attributes and payload (if present); (6) the device han-
dles the request and responses back to the digital replica; and (7) the EDT forwards the response to
the requesting external client. If a caching system is active on the EDT (and the available data are
updated) the response to the client can be directly managed by the twin avoiding the interaction
with the physical thing.

4.3 Deployment & Use Cases


EDTs can be adopted in multiple application scenarios in order to effectively mirror both standard
and domain specific physical objects. An EDT is deployed with an extensible key-value startup
configuration received through an administration application (or any other orchestration module)
and containing all the required information to start mirroring the physical counterpart. Config-
uration information may be extended according to the target supported protocol or deployment
while the built-in modules support the personalization of: the target smart object IP address and
port, MQTT broker endpoint, caching configuration, processing pipeline definition, and logs and
metrics collectors information.
When a new device, protocol or behaviour needs to be supported by the EDT, only a small por-
tion of the source code must be extended to include the new functionality by relying on the frame-
work’s core structure. Figure 4 illustrates an experimental use case where Philips Hue and IKEA
Trådfri smart light systems are installed in the same edge environment. Both systems wirelessly
connect light bulbs through IEEE 802.15.4 and dedicated network bridges responsible for handling
the communication with external applications. The first uses a custom HTTP (without security sup-
port) RESTful communication based on a set of domain specific JSON messages. The latter supports
instead the CoAPs protocol with a message data format inspired to the OMA LightweightM2M
(LwM2M) Object and Resource Registry1 but without any support for CoRE Link Format or CoRE
Interface standards. As illustrated, the EDT’s core is shared among the active twins together with
the CoAP communication module and the SenML processing pipeline, and the required custom

1 OMALightweightM2M (LwM2M) Object and Resource Registry - http://www.openmobilealliance.org/wp/OMNA/


LwM2M/LwM2MRegistry.html.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:15
Table 2. Experimental Evaluation’s Metrics
Metric Description
Configuration Setup Time [ms] Configuration’s reading and engine’s startup.
MQTT Module Setup Time [ms] Activation of the MQTT Module according to its configuration
MQTT Topic Subscription Time [ms] Communication with brokers and subscription to target topics
CoAP Module Setup Time [ms] Activation of the CoAP Module according to its configuration
CoAP Resource Discovery Time [ms] Execution of resource discovery from the EDT to the device
CoAP Resource Initialization Time [ms] Creation of the digital replica of discovered resources
End To End (E2E) Delay [ms] EDT’s delay to process incoming or outgoing messages
Heap Usage [MBytes] Java Heap’s used memory
CPU Usage [Adimensional] % of used CPU by the EDT

implementations are limited to bridges’ connectors to map legacy communication flows and data
formats.
This example perfectly depicts a heterogeneous scenario where thanks to the EDT’s capabilities
and the presented modular architecture it is possible through a small development customization
(also re-usable across multiple deployments) to easily address a fragmented context augmenting
functionalities and bringing uniformity to data and communications on the edge.

5 EXPERIMENTAL ANALYSIS
This section is dedicated to an exhaustive set of EDT’s experimental evaluations with the aim to
analyze the performance in terms of introduced communication overhead and resource consump-
tion considering multiple operational scenarios. We defined a heterogeneous IoT environment
with multiple emulated smart objects and consumer applications targeting both CoAP and MQTT
as the main reference protocols and a set of evaluation metrics summarized in Table 2.
We adopted both emulated and real IoT devices in our experiments. Experiments with emulated
devices enable easily scaling and tuning of operational parameters during the experiments. Their
adoption does not affect the EDT’s overhead since in edge deployments, physical assets are exter-
nal to computational facilities and the EDT’s behaviour is consequently independent from things’
nature. Emulated devices have been implemented through independent Java applications and pro-
cesses taking into account the possibility to use both CoAP and MQTT application layer protocols
and allowing easily running multiple instances according to the target evaluation scenario. Each
emulated smart object is fully configurable in terms of number of managed resources, data genera-
tion frequency, payload size, and the number of target messages of interactions to manage during
its life-cycle. The number and the type of the resources held by each device is randomly generated
at startup with a configurable range (for our experiment between 1 and 10). Generated resources
on an object can include at the same time sensors generating only telemetry messages associated
to random measurements) or actuators allowing to both generate telemetry data related to status
changes or receive actions. Interaction and communication options of emulated sensors and actu-
ators on each device are related and mapped according to the selected protocols. Both MQTT and
CoAP emulated devices use SenML as reference standard data format for generated messages and
CoAP devices implement also the support for CoRE Link Format and CoRE Interface standards.
The experimental evaluation has been completed with the development of specific configurable
demo applications (implemented in Java and supporting both MQTT and CoAP) responsible for
emulating the behaviour of external service interest to interact with both EDTs and/or physical
devices to collect data (observing telemetry measurements) or trigger actions (changing the status
of an actuator). All the implemented software and components have been also integrated with
a shared metrics system (Graphite2 ) and logs collection module in order to support the storage,
query, and analysis of experimental data.

2 Graphite Monitoring Platform - https://graphiteapp.org/.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:16 M. Picone et al.

Fig. 5. EDT’s startup phases to properly mirror a target device considering both MQTT and CoAP (a), EDT
MQTT E2E Delay as function of the message rate (b), payload size (c), and the QoS level (d).

Emulated devices, EDTs, and consumer applications have been deployed and executed accord-
ing to the target experimental configuration using three different edge nodes equipped with an
Intel Core i7 2.2 GHz and 8 GBytes of RAM, running a Debian based Linux distribution and con-
nected through an 802.11 WiFi Network. Furthermore, experiments have been extended to include
real devices in order to evaluate the feasibility to run EDTs on constrained devices and their capa-
bility to effectively handle heterogeneity and domain specific deployments. The experimentation
included Raspberry Pi Model B boards (700 MHz CPU, 128 MBytes of RAM, 10/100 Mbits Ether-
net connectivity and Raspbian OS), Philips Hue and IKEA smart lightning systems with dedicated
platform specific lights bulbs and communication bridges. The presented configurations have been
designed to support the focus of the paper to provide an analysis on the feasibility of deploying
DTs on the edge through the EDTs.

5.1 Edge Digital Twin Startup Performance


The first group of evaluations investigates the required time to complete the principal EDT startup
phases. The graph in Figure 5(a) analyzes the involved steps for MQTT and CoAP EDT’s modules
and each value averages the results of 1,000 distinct runs. The first phase is the Configuration Setup
where the EDT loads the provided configuration and the list of target protocols managers. On one
hand, the MQTT Setup phase requires only the creation of the two connections toward physical
and digital brokers while the MQTT Topics Subscription phase involves the subscription to the con-
figured topics of interest. On the other hand, the CoAP module requires as first step to initialize
a CoAP Client and a CoAP Server for its bi-directional communication with the physical counter-
part and external consumers (CoAP Setup phase). The next phase is the CoAP Resource Discovery
where the EDT sends a GET request to the standard ./well −known/core URI to obtain the list and
the description of available resources. The execution time considers both the request/response
communication and the processing time required to analyze the response and to create a map of
available resources. The final step is the CoAP Resource Init where the EDT creates all the digital
resources making them available to external consumers through the CoAP Server. Even though
the difference of the two protocols, an operative EDT can be generated on average in  60ms for
MQTT and  110ms for CoAP.

5.2 End to End Delay Analysis


The second analysis analyzes the effect of the use of EDTs on the E2E delay both for MQTT and
CoAP communications on different devices and with respect to an existing reference centralized
DT management solution. In the target scenario a consumer application — unaware of the presence
of the digital twin — is interested in collecting real-time data from a target physical device.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:17

Figure 5(b) shows the E2E delay as a function of the messages rate (msg/sec) using a SenML
formatted payload of 100 Bytes. The message rates ranges from 5msд/sec to 100msд/sec covering
a good set of real-time interactions and showing the good performance and the reduced overhead
introduced by the EDT. Figure 5(c) analyzes instead the delay with respect to the Payload Size
(ranging from 100 Bytes to 5000 Bytes) with a fixed message rate of 10msд/sec to show how also
with an increased payload size the average EDT’s overhead is almost unchanged.
The graph in Figure 5(d) shows the impact on the delay with respect to the three MQTT Quality
of Service (QoS) levels (associated to a progressively increased reliability) in order to discover
the best configuration according to the final deployment. The analysis considers four different
combinations both for the physical and digital counterparts over a set of 10,000 messages. Results
confirm how the adoption of QoS level 2 on both sides produces a higher E2E delay and that level
0 is the quickest solution without any reliability support. In a target edge deployment considering
a target deployment where EDTs and the MQTT brokers are on the same edge node we can reduce
the delay relying on the TCP protocol without the risk of packet losses. Presented results suggest
to properly balance the configured QoS levels according to the target deployments and the overall
network reliability. An efficient compromise can be obtained for example using a QoS = 2 between
physical assets and their broker (where the communication can be unstable) and QoS = 0 within
EDTs and the edge facilities.
The next set of analyses focuses on the CoAP’s E2E Delay as a function of the message rate and
the payload size. Considering the request/response nature of the protocol we also extended the
analysis in order also to understand how an EDT’s CoAP caching module may reduce the load on
the physical thing minimizing at the same time the introduced overhead. The evaluation compares
the E2E delay for the following cases with: (i) the mediation of the EDT; (ii) the direct access to
the object, and (iii) the adoption of a cache. The “Max-Age” CoAP option [65] is used to specify
the maximum time a response may be cached before it is considered not fresh (1 second for each
resource of our experiments).
The graph in Figure 6(a) and (b) reports the E2E delay with respect to message rate and payload
variations showing that when the EDT’s cache is not active the overhead cost will be doubled
due to the need of forwarding both requests and responses. On the other hand, the adoption of
an EDT’s caching system allows to obtain at the same time a protection for the physical devices,
fresh data for the consumers and a significantly reduced response time. Results show also how
all the tested configurations produce an increased delay for payload greater than 1000 Bytes and
keep an almost constant behavior for lower sizes. This turning point is due to the specifications
of the CoAP protocol that limits the packet size to the UDP’s Maximum Transmission Unit
(MTU) of 1280 bytes. Larger packets will be fragmented and handled with the use of block-wise
transfers [13] with a consequent higher overhead. The same effect is absent with MQTT since it
has a default message size limit of 260KByte without any fragment management at the application
layer.

5.3 Results with Constrained Devices


We extended the evaluation of the proposed solution through the use of constrained boards with
limited computational and memory capabilities in order to understand its impact on the EDT’s
delay. We executed the emulated CoAP and MQTT smart objects on Raspberry Pi Model B boards
equipped with a 700 MHz CPU, 128 MBytes of RAM, 10/100 Mbits Ethernet, and Raspbian OS. The
graphs in Figures 6(c) and (d) report the obtained delay with and without the use of the EDT and
considering a messaged rate of 10msд/sec and a payload size of 100 Bytes. The results show how
the overall MQTT E2E delays are lightly increased due to the limited performance of the physical

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:18 M. Picone et al.

Fig. 6. E2E Delay CoAP results for the message rate (a) and payload variations (b). The E2E Delay measured
considering an IoT Smart Object running on a Raspberry Pi Board for both MQTT (c) and CoAP protocol (d).

Fig. 7. A timeline oriented experimental analysis of EDT Memory consumption (a) and CPU usage (b) con-
sidering both CoAP and MQTT use cases. An averaged analysis over multiple experiments for the same
protocols and metrics (c) and (d).

device but the EDT’s overhead is comparable with the averaged value obtained with previous
configurations and experiments. The behavior is also confirmed with the CoAP protocol while the
adoption of the EDT’s cache provides a significant responsiveness benefit as reported in Figure 6(d).
These results confirm how the presence of EDTs allows improving the performance of constrained
IoT deployments while protecting the core devices from unnecessary requests.
Graphs in Figure 7 report the CPU and the Memory Heap usages for CoAP and MQTT EDTs. The
analysis takes into account different Memory Heap sizes to understand how and if the performance
will be affected over a period of approximately 15 minutes and a continuous rate of activities (pub-
lish and requests) for active devices with 10 distinct resources. Graphs (a) and (b) show the temporal
analysis over the target experimental time window while results in (c) and (d) depict average trends.
Obtained results confirm how an EDT running on the edge node can effectively operate also with a
strongly limited amount of available memory (8 Mbytes) and with an average CPU usage of 0.14%
for both for MQTT and CoAP. Furthermore, they support the envisioned possibility of running
multiple DTs on the same edge computing infrastructure, allowing the creation of a distributed
network of connected EDTs also on devices with limited computational and memory resources.

5.4 Custom Processing & Heterogeneity Management


This subsection analyzes the performance and the EDT’s efficiency to handle IoT heterogeneity
through the use of domain specific communication modules and processing pipelines. The experi-
mental setup refers to the previously presented smart lighting use case illustrated in Figure 4. The
graphs in Figure 8 show the response time with and without the presence of the EDT respectively,
for sensing (a) and actuation (b) phases. As reported, the introduced overhead is mainly due to the
communication phases while the data format adaptation requires a negligible amount of time. As
expected, CoAP is more efficient compared to HTTP, in particular in constrained environments
and the actuation procedure on average is lightly more expensive compared to sensing. Figures 8(c)
ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:19

Fig. 8. Comparison of delay and processing time with legacy Philips Hue and IKEA Trådfri smart lighting
systems. Sensing (a) and Actuation (b) tests with and without EDTs. Code statistics in terms of code lines (c)
and size (d) to integrate custom connectors and SENML processing.

Fig. 9. Docker-based virtual networking deployment where multiple consumer applications are in segregated
zones.

and (d) report, respectively, the required number of lines of code and the associated size to imple-
ment the required connectors compared to the size of the EDT core engine. Thanks to the EDT’s
modularity, it is possible to effectively extend twin’s behavior overcoming the limitations and the
heterogeneity of deployed domain specific devices without affecting the performance.

5.5 Dynamic Virtual Networking Analysis


With the goal to understand if and how the EDTs can work and perform without any changes in
dynamic network environments (implemented using Docker3 container platform), we designed an
additional experimental setup illustrated in Figure 9. The deployed scenario considers two EDTs
and three consumer applications orchestrated on different virtual segregated networks. Each twin
is associated to a single target network (Network A and B) and both are also connected to Network
C. A dedicated consumer application is activated in all the available networks collecting data from
reachable twins in its segregated environment. Consumer A is always connected to its network
while Consumer B and C are dynamically attached and removed from their environments. We also
introduced an additional metric denoted as “Consumer App Success” indicating if a consumer ap-
plication is operating correctly or if it has been disconnected from its network. A different success
value has been assigned to each application (Consumer-C=1, Consumer-B=2, and Consumer-A=3)
and 0 is the common value for errors. The E2E Delay is the other adopted metric used to measure
the obtained performance and a connection timeout of 200 ms has been used both on MQTT and
CoAP to easily highlight in case of unreachable networks. The graphs in Figure 10(a) and (c) show
how consumer applications and EDTs can be dynamically added and removed from available vir-
tual networks keeping a network segregation where only authorized entities can communicate.
Figures (b) and (d) report instead the measured performance of the containerized EDTs showing
how the delay is not affected by the introduced virtual networking keeping the same performance
of previously presented results. Presented results show how containerized EDTs can efficiently

3 Docker Container Platform - https://www.docker.com/.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:20 M. Picone et al.

Fig. 10. (a) Consumer App Success performance for CoAP consumers in a dynamic networking scenario.
(b) E2E Delay for CoAP consumers in a dynamic networking scenario. (c) Consumer App Success performance
for MQTT consumers in a dynamic networking scenario. (d) E2E Delay for MQTT consumers in a dynamic
networking scenario.

work also in virtualized environments without any disruption and provide an additional flexibility
option for digital twin management on the edge.

6 COMPARISON & INTEGRATION WITH EXISTING PLATFORMS


Following the aim of this work and the goal to understand the feasibility of edge digital twins in
distributed ecosystems, in this section we analyze and compare the proposed EDT approach with
two of the main production-ready DT solutions, namely the open-source Eclipse Ditto framework
and the Microsoft Azure cloud platform. The first represents the only available option that allow us
to manage the installation and deployment of a DT service on the edge while the latter is the state
of the art for DT modelling in the cloud and a perfect match to design a multi-layer DTs solution.
In the next subsections, we analyze the provided features, compare the performance with EDTs,
and discuss existing limitations and open challenges. Furthermore, in the last part we propose a
Smart Home use case and an integrated solution for an edge-cloud architecture combining EDTs
with cloud DTs implemented through Microsoft Azure.

6.1 Edge Comparison - Eclipse Ditto


As previously anticipated, Eclipse Ditto is the main open-source reference for digital twin man-
agement. Notwithstanding its cloud nature, it can be deployed also on edge nodes representing
the perfect performance comparison with the proposed approach. Ditto handles DTs through the
centralization of all the communications and the use a custom message data format and interac-
tion pattern exposed through a set of protocols (HTTP, MQTT, AMQP and WebSocket). The Ditto
framework is based on the following core functionalities: (i) Device as a Service: to abstract devices
into DTs providing synchronous and asynchronous APIs to interact with physical devices; (ii) State
management for digital twins: to handle reported, desired, and current state of DTs, including sup-
port for synchronization and publishing of state changes; and (iii) Access control enforcement: to
control access and authorize each API call applying a resource based access. Figures 11(a) schema-
tizes Ditto’s main building blocks in terms of communication capabilities and DT features. The
combination of APIs, Gateway, and Connectivity modules define the interaction with both the
physical devices and external applications while Things and Policies components shape, respec-
tively, devices and DTs data structures and the management of access control lists. In terms of in-
teraction with physical IoT devices, the framework provides different options taking into account
both objects that can directly integrate the provided SDK and things that cannot be customized
and require an intermediate module to communicate with the platform. For the experiments we
considered both IoT devices and external consumer applications directly integrated with Ditto’s
SDK in order to send and receive data.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:21

Fig. 11. Eclipse Ditto setup considering both devices directly integrated with the SDK or using one of the
supported protocols on the device or through intermediate nodes (a). Comparison between the E2E Delay
using Eclipse Ditto and the EDT solution with respect to the message rate (b) and the payload size (c).

Eclipse Ditto represents a flexible solution to implement DTs applications, however it provides
a solution that is mainly centralised where all DTs are deployed at the same architectural point,
limiting flexibility among multiple computational facilities and the definition and independent
DT instances as proposed and evaluated. Furthermore, DTs are modeled as passive entities co-
located at the same architectural and subordinated to external modules and application to control
their properties, data, and behaviours. Each DT does not define its shadowing process and appears
just as a data structure for data coming from the physical asset. With this approach, DTs can be
used to model an application scenario without introducing any active behaviour and without the
support for the most recent state-of-the-art DT capabilities and properties such as augmentation
and composition.
In order to properly understand and evaluate the effort and the complexity required to handle
the creation and management of the integration with Eclipse Ditto in terms of load and required
modifications to physical assets, we listed in Table 3 the sequence of involved steps to: (i) create
and manage IoT devices associated to DTs; (ii) create and manage DTs references and data struc-
ture; and (iii) handle telemetry outgoing from devices and actions and commands coming from
external applications. As reported, the sequence of required operations is not trivial, involves mul-
tiple protocols and custom interaction patterns, and may significantly affect the implementation
of IoT devices or require the introduction in the deployment of custom interoperability modules
responsible only for handling the mapping with Ditto.
Furthermore, the management complexity should be considered together with the impact of a
centralized framework to interaction latency and real-time requirements. With the aim of evaluat-
ing the performance in terms of introduced communication delay and overhead of Ditto operating
on the edge and comparing it with the proposed EDT, we shaped an experimental setup with

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:22 M. Picone et al.
Table 3. Device Perspective - Eclipse Ditto Digital Twin Setup & Configuration Tasks
Id Name Protocol(s) Custom Pattern(s) Frequency Description
Creation Verify if the Ditto Device reference and data
1 Check Device HTTP Yes Req/Resp
Update structure have been correctly created.
Create/Update Creation Create or updated the Ditto Device reference and
2 HTTP Yes Req/Resp
Device Update data structure.
Create Creation Create Ditto Credentials to operate with the
3 HTTP Yes Req/Resp
Credentials Update target created device.
Creation Check if the Ditto Thing has been correctly
4 Check Thing HTTP Yes Req/Resp
Update created and available.
Create/Update Creation Create or update the Ditto Thing reference and
5 HTTP Yes Req/Resp
Thing Update data structure.
Create/Update Creation Create or update the policies associated to the
6 HTTP Yes Req/Resp
Policies Update target Ditto Thing.
Create/Update Creation Create or update the features associated to the
7 HTTP Yes Req/Resp
Features Update target Ditto Thing.
HTTP MQTT Handle telemetry data coming from the physical
Handle Req/Resp
8 AMQP Yes Data Update device to update the reference on Ditto device
Telemetry Pub/Sub
WebSocket and thing.
Handle AMQP Handle incoming action from Ditto associated to
9 Yes Pub/Sub External Input
Actions WebSocket the target device and thing.

emulated CoAP and MQTT IoT devices communicating in a local network over IEEE 802.11 links
and DTs deployed through EDTs and Ditto on a local edge node. In the analyzed scenario, IoT
devices embed Ditto’s SDK to directly communicate with the framework and limiting latency and
communication overhead between physical and digital counterparts and consumer applications in-
teract with both EDTs and Ditto to the measure E2E delay through different setup configurations
and protocols. Figure 11(b) shows the delay as a function of the message rate with a fixed payload
size of 100Bytes. On average, the E2E delay introduced by Ditto (21.26ms) is significantly higher
with respect to the performance obtained by the EDT with a delay of 4.24ms (averaging both
MQTT and CoAP values). The same trend is also confirmed by Figure 11(c) considering the vari-
ation of the payload size variation and a fixed message rate of 10msд/sec. Dittos’ clients show an
averaged E2E delay of 21.43ms instead of a value of 5.95.ms calculated considering for MQTT
and CoAP configurations. The explanation of the obtained results is associated to the fact that
Ditto mainly focuses on one-to-many DTs’ inventory and data management features instead of
edge DTs performance. The introduced additional delay should be also considered together with
the constraints associated to the adoption of legacy communication flows and the limitation of
delegating the integration responsibility to the physical assets. The aim of our evaluation is to
show and measure how the new one-to-one EDT’s approach can bring concrete benefits in terms
of edge heterogeneity management and communications performance. Ditto remains excellent as
device-as-a-service framework and can potentially work side-by-side with EDTs to combine the
advantages of both solutions. The EDTs will be responsible for mirroring of the physical counter-
part, heterogeneity management, and the integration with the Ditto framework, while the latter
will handle the complexity of inventory, versioning, data history, and storage control.

6.2 Cloud Comparison - Microsoft Azure


In this section, we analyze the features of the digital twin managed service provided by the Mi-
crosoft Azure cloud platform as the most advanced enterprise solution for the creation of DT based
applications. The main core Azure services involved in the design and implementation process of
cloud DT applications are schematically represented in Figure 12(a) and summarized as follows:
(i) Azure IoT Hub: to enable secure and reliable communication between IoT devices and applica-
tions through a set of protocol adapters enabling communications with MQTT, HTTP APIs, and
AMQP (with SDK); (ii) Azure Event Grid: to convey data coming from IoT devices to an event-bus
shared among all the available cloud services and instances; (iii) Azure Digital Twin: to create and
manage digital representation of real-world things, places, business processes, and people through

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:23

Fig. 12. Microsoft Azure setup considering both devices directly integrated with the SDK or using HTTP or
MQTT to communicate. Timeline comparison between the E2E Delay using Azure Digital Twins in the Cloud
and the EDT on the Edge with respect to a message rate of 10msg/sec and payload size of 200 Bytes.

the use of a structured definition language called Digital Twin Definition Language (DTDL);
and (iv) Azure Functions: to execute compute-on-demand serverless function through the use of
multiple programming languages. They can be used as an integration with DTs to react to incom-
ing events from IoT devices and external applications.
DTDL is a Microsoft defined language for describing models for DTs associated both to IoT de-
vices and logical and physical entities such as a floor in a building or a production process in an
industrial plant. This approach and modeling language enables the provisioning, use, and config-
uration of DTs of all kinds from multiple sources in a single centralized and cloud solution. DTDL
can be used to describe any DTs characteristics and abilities leveraging of semantic annotations
and a well structured design composed by the following metamodels: (i) Property: data fields to
represent the state of an entity; (ii) Telemetry: telemetry fields to represent measurements or events
coming from device sensor readings. Unlike properties, they are not stored on the DT but used as
event-driven input to compute the DT’s state when a change in the physical asset has been de-
tected; (iii) Relationships: represents how a DT can be involved and linked with other DTs through
semantic meanings to define a graph of interrelated entities (e.g., “floor contains room” or “com-
pressor is billed to user”); and (iv) Components: allow to define re-usable modules and interfaces
across multiple DTs descriptions. Even if DTDL is a standard description language, it represents
an appealing effort and a significant step forward to model and shape cloud digital twins with
their functionalities and relationships. However in the overall Azure approach, DTs are still cloud-
only centralized entities on the same tenant (limiting cross-domain applications) and they result as

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:24 M. Picone et al.
Table 4. Device Perspective - Microsoft Azure Digital Twin Setup & Configuration Tasks
Id Name Protocol(s) Custom Pattern(s) Frequency Description
Verify if the Azure IoT Device reference and data
Creation
1 Check Device HTTP Yes Req/Resp structure have been correctly created on the
Update
Azure tenant.
Create/Update Creation Create or update the Azure IoT reference and
2 HTTP Yes Req/Resp
Device Update data structure on the target Azure tenant.
Check DT Creation Check if the correct DT Model is available on the
3 HTTP Yes Req/Resp
Model Update target Azure tenant.
Create DT Creation Create the target DT Model on the reference
4 HTTP Yes Req/Resp
Model Update Azure tenant.
Creation Check if the Azure DT reference and data
5 Check DT HTTP Yes Req/Resp
Update structure has been correctly created and available.
Create/Update Creation Create or update the Azure DT reference and data
6 HTTP Yes Req/Resp
DT Update structure on the target Azure tenant.
Check if the target DT relationship has been
Check DT Creation
7 HTTP Yes Req/Resp correctly created and available between involved
Relationship Update
DTs on the reference Azure tenant.
Create/Update
Creation Create or update the a DT relationship between
8 DT HTTP Yes Req/Resp
Update target DTs on the reference Azure tenant.
Relationship
Handle telemetry data coming from the physical
Handle HTTP MQTT Req/Resp
9 Yes Data Update device to update the reference on Azure IoT
Telemetry AMQP Pub/Sub
device and DT.
Handle Handle incoming action from Azure IoT
10 AMQP Yes Pub/Sub External Input
Actions associated to the target device and the DT.

passive instances subordinated to external modules to control their properties, data, and states. The
only modeling flexibility is provided by the design and adoption of serverless functions to build
event-driven DT dynamic behaviours by reacting to incoming events and data from the physical
layer or external third-party applications.
As previously explained for Eclipse Ditto, and to properly understand the effort and the com-
plexity required to integrate physical assets with Azure DT functionalities, we listed in Table 4
the sequence of involved steps from a device perspective to: (i) create and manage IoT devices
associated to DTs; (ii) create and manage DT models; (iii) create and manage DTs references and
data structure; and (iv) handle telemetry outgoing from devices and actions and commands com-
ing from external applications. On one hand, provided functionalities allow to shape interesting
complex digital twin driven application scenarios. On the other hand, the complexity cost for end
devices and applications to integrate Azure DTs is not negligible and the strong internet and cloud
dependency may represent a limitation for applications and consumers demanding a local interac-
tion and low-latency communication with DTs. Nevertheless, integrating directly end devices with
Azure (or any other cloud platform) interaction patterns represent a strong bound and a potential
limitation to support a migration and adoption to other remote services.
Even though, we know that detailed analysis between IoT oriented edge and cloud communica-
tion delay have been already tackled through multiple application domains and experimentation
environments, we propose a different DT oriented perspective comparing EDTs with cloud digital
twins on Microsoft Azure. Figure 12(b) illustrates a timeline of the E2E delay difference consid-
ering two consumer applications deployed respectively in the cloud to interact with Azure DTs
and on the edge to communicate with EDTs. Both DTs are associated to emulated IoT devices in-
stalled on the edge and generating telemetry data with a message rate of 10msд/sec and a payload
of 200Bytes. In both configurations they communicate using the MQTT protocols but adapting
topics structure, security configurations and payload data formats between edge and cloud. The
local interaction with EDTs is enabled through a local broker over an IEEE 802.11 network while
the communication with Azure instance (activated on a European datacenter to optimize latency)
is enabled through a Gigabit fiber-optic internet access. As expected, the delay difference between
the two setups is relevant showing a volatile observability latency with the cloud DT instances

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:25

with an average delay of 153ms and a standard deviation of of 65ms. On the opposite, the same
interaction and observation on the edge guarantees a stable low latency communication with an
average delay of 5ms and a variation of 0.7ms.
The insight that we would like to highlight with this analysis is not meant to be an attack to cloud
DT solutions, but instead a stimulus to envision an edge cloud interoperability and collaboration.
The adoption of cloud-only DT solutions can work well for specific use cases where the integration
impact on the edge is negligible and the application’s constraints do not require resilient, internet
independent and low-latency communication and interaction with DTs. On the other hand, as
previously anticipated, in the motivations of this work and experimentally illustrated in the next
analysis (Section 6.3), we strongly believe multiple instances of digital twins can co-exists in the
same deployment and EDTs and Cloud DTs can be composed and collaborate to obtain in the same
deployment the advantages of both solutions.

6.3 An Edge/Cloud Integrated Digital Twin Scenario


In this section, we designed, implemented, and experimentally evaluated a simple Smart Home use
case with the aim to understand the benefits provided by the integration at the same time of digital
twins on the edge and in the cloud as depicted in Figure 13(a). In the local environment we have
deployed three emulated IoT devices to monitor temperature, humidity, and energy consumption
connected over IEEE 802.11 and using, respectively, MQTT, HTTP, and CoAP to communicate
with a custom JSON based data format. Each device is associated to an EDT instance deployed on a
local edge node and is responsible for shadowing the device by communicating with the associated
physical counterpart, homogenizing the communication protocol to MQTT and the data format to
the SenML standard (exploiting the augmentation capability). We also deployed an additional EDT
in charge of shadowing the room where sensors have been deployed and using the composition
property to collect and aggregate data from composed EDTs in order to build and expose a unified
view of the environment.
Each EDT integrates also a dedicated adapter responsible for embedding the complexity of com-
municating with Microsoft Azure in order to handle the creation, management, and synchroniza-
tion of cloud DT replicas following the platform-specific integration steps previously illustrated
in Table 4. The EDT’s Azure adapter uses HTTP and AMQP protocols to interact with cloud APIs
and IoT Hub and to exploit the DTDL description language to describe Azure DTs and their rela-
tionships (e.g., sensors belonging to the room).
In order to complete the analysis, we developed and deployed two demo consumer applications:
one to interact over MQTT on the edge with EDTs, and the second one embedding the Azure SDK
to communicate with cloud DTs over the internet. The combination of the two approaches and
the creation of distributed and synchronized DT replicas allowed applications to exploit the best
interaction paradigms according to their architectural position and obtain the correct communica-
tion latency according to their requirements confirming the delay measurements illustrated in the
previous sections. With the presented edge/cloud integrated analysis we would like to highlight
the importance of EDTs and their responsibility to integrate the complexity in terms of application
logic and execution time to communicate with the target cloud platform. Figure 13(b) reports the
required time associated to edge-oriented EDT adapter (MQTT, HTTP, and CoAP) to start up and
shadow the physical counterpart compared with the Azure adapter integration steps according to
the operations identified in Table 4. As illustrated, both the number of involved phases required
to build a cloud replica and the associated execution time are not negligible if they are applied
on physical devices or additional integration and interoperability modules. Furthermore, this com-
plexity should be considered together with potential physical asset changes over time, the required

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:26 M. Picone et al.

Fig. 13. An integrated edge & cloud scenario to show how multiple DTs can co-exist in the same deployment
at different architectural layers with EDTs close to the physical assets and integrated at the same time with
cloud twins.

adaption on DT instances and together with the introduced synchronization delay that has been
already been analyzed in the previous section in Figure 12(b).
To summarize: the advantages of the adoption of the proposed EDTs within integrated edge/-
cloud architecture and application scenarios can be outlined as follows:
• The responsibility to handle the integration with cloud DTs has been completely removed
from physical assets or any other intermediate modules and it is directly managed by the
EDTs through the exploitation of the augmentation capability to handle multiple adapters
at the same time and the composition property to create and keep synchronized the cloud
replicas.
• Deployment owners can avoid any vendor lock-in with cloud providers since the integration
with remote DT and advanced functionalities does not affect core physical devices or assets
but only EDTs and its adapters. Furthermore, the integration with different and additional
cloud providers or the management of updates within the existing deployment will affect
only the EDTs instead of involving other core components.
• Edge applications can locally interact with EDTs through a uniform protocol and data format
(in the implemented scenario MQTT and SenML) obtaining low latency communication, real-
time performance and internet connectivity independence as previously illustrated through
the obtained results.
• Cloud and external applications can benefit, on the other hand, from cloud DTs without the
complexity of directly handling edge deployments and being able to remotely monitor and
interact with shadowed IoT devices by receiving telemetry data and/or send commands and
action requests to physical assets.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:27

7 DISCUSSION
DTs point to a future of pervasive softwarisation of the physical world in terms of highly dynamic
ecosystems of connected and interoperable components, across different application domains and
different network levels from edge to cloud. Among several open questions, in this paper we fo-
cused our attention on design, implementation and experimental evaluation of DTs on edge com-
puting architectures. We foster the idea that cloud-only approaches can limit the effectiveness of
DT systems and applications due to a constrained management of the widespread physical het-
erogeneity and fragmentation, a centralization of responsibilities, and a less performing linkage
between physical and digital counterparts bringing increased delays and reduced reliability. In
this Discussion section we analyze faced challenges and threats, obtained results, and existing
limitations related to the proposed EDT approach, its design and architecture, the presented ex-
perimental evaluation and the comparison with existing solutions and platforms.
Design & Architecture. The initial challenge that has been tackled is related to the missing uni-
form analysis and modeling of DTs’ responsibilities on the edge in terms of capabilities and op-
erational phases. We addressed this initial issue by stating the core DT’s properties of represen-
tativeness & contextualization, shadowing, augmentation, observability, and composition (recently
proposed in the state of the art only as abstract definitions) leading them to a concrete edge char-
acterization with the proposed concept of EDT. Relying on the proposed modeling, we designed a
reference architecture and built its first implementation through the definition of a software stack.
This represents one of the first attempts to effectively analyze the end-to-end design and devel-
opment of DTs running on the edge as active independent components instead of passive entities
aggregated in monolithic software modules or locale on remote cloud platforms.
The proposed EDT framework: (i) relies on a modular engine and a set of shared functionalities;
(ii) minimizes the introduced overhead during the digitalization processes; and (iii) simplifies the
introduction of new capabilities reusing or adapting existing modules. Finally, the security per-
spective represents also a massive topic with respect to DTs and in general related to the design
and development of cyber-physical systems. In particular, a fundamental and challenging topic for
edge digital twins (not only for EDTs) will be to effectively secure and segregate the communica-
tion and interaction between the physical and the digital counterparts (e.g., as reviewed in [4]) with
the risk to directly affecting core capabilities such as representativeness, contextualization, shad-
owing, and observation. In both cases, we believe that the provided initial analysis together with
the definition and characterization of EDTs core functionalities and responsibilities, will properly
enable these fundamental extended investigations.
Performance Evaluation. Starting from the proposed architecture and its first implementation,
we designed and conducted a structured experimental evaluation with the aim to analyze the fea-
sibility of deploying DTs on the edges and in particular for the evaluation of the proposed EDTs.
Obtained results confirmed the effectiveness of the proposed approach in terms of introduced
overhead, communication delay, and consumed resources. EDTs are able to create on the edge
an effective intermediate digital layer encapsulating the responsibilities to handle the physical
complexity, augment existing capabilities, and expose a uniform interface for external services
and applications. Nevertheless, the implemented software stack enables at the same time a useful
code reusability by relying on shared modules and capabilities and the execution of EDTs as in-
dependent entities on virtualized environments in order to exploit the advantages of distributed
microservices architectures combined with dynamic networking.
We are aware that specific angles of the evaluation process can be extended and improved
in particular with respect to networking and virtualization. Communication and networking as-
pects may require, for example, a detailed analysis in terms of application, transport and network

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:28 M. Picone et al.

protocols, and the impact of unreliable links. The topic has been massively analyzed in the IoT lit-
erature providing a solid starting point (e.g., in [33, 39]), and we believe that the proposed modular
architecture can simplify the creation of specific adapters to support new protocols and commu-
nication techniques, and can enable the experimentation through multiple use cases to investi-
gate the detailed facets of networking. With respect to the virtualization topic, under-explored
aspects are mainly related to the investigation of the performance and potentiality of advanced
containerization and orchestration platforms, such as Kubernetes, instead of the simplified use of
a Docker environment. Furthermore, the virtualization may involve also the networking layer to
dynamically control the routing infrastructure through Software Defined Networking (SDN)
and Network Function Virtualization (NFV) techniques.
Platforms Comparison & Integration. The last part of the experimental evaluation has been en-
tirely focused on the comparison of the proposed EDT approach and implementation with Eclipse
Ditto and Microsoft Azure as two of the main existing reference platforms currently available
on the market. On the one hand, the objectives of this additional evaluation have been mainly
related to understanding the limitations of the existing frameworks and to highlight the benefit
of the proposed EDT in terms of supported interaction patterns, centralization and aggregation
levels, and the introduced overhead. On the other hand, we aimed to understand how the com-
bination of edge and cloud approaches can represent an opportunity for DT applications and if
EDTs can be effectively integrated with existing solutions. The conducted analysis perfectly illus-
trates the limitations of the target approaches if analyzed from an edge point of view. In particular,
highlighted limitations include: design complexity and fragmentation due to the adoption of cus-
tom data formats and interaction patterns, the direct impact on deployed physical devices and
the digitalization performance in terms of introduced overhead and a not surprisingly increased
communication delay. At the same time, the design and experimentation of an integrated use case
combining EDT with a cloud DT platform allowed us to close the analysis loop fostering the en-
vision idea of multi-layered DTs architectures where different twins can coexist at the same time
in order to address different responsibilities through a hierarchical and connected structure. This
last analysis represents only an initial comparison and integration activity limited to a target use
case that of course is not yet comprehensive of all the possible design and implementation aspects
due to the fact that the idea of combining multiple DTs across different architectural layers is yet
at an early stage. However, we believe that the proposed integrated analysis combined with the
presented detailed EDT’s experimental analysis represents a valuable contribution to feed to dis-
cussion and enabled the investigation and design of a new generation of DT-driven architectures
through multiple cross-domain applications.

8 CONCLUSION
In this paper, we have introduced and analyzed the design and implementation of the EDT frame-
work. We have shown how EDTs can overcome the limitations of domain specific and centralized
digital twin solutions, by making available a flexible and scalable abstraction layer, suitable for
the deployment of multiple segregated and secured IoT applications and for reducing the complex-
ity of domain-specific implementations management. An extensive set of experiments has been
presented to investigate the behaviors and the performances of the proposed solution, also consid-
ering the comparison with state-of-the-art Open Source DT frameworks. These experiments show
that EDTs are scalable, introduce limited overhead, and consume limited resources.
Future developments are related to the extension of the framework in order to natively support
an extended set of modules dedicated to additional protocols, integration, and connectors to effi-
ciently work and operate in a wider group of heterogeneous application scenarios. In addition, we
will focus on EDT management and orchestration in distributed and mobile environments focusing

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:29

on the challenging context of 5G Multi-access Edge Computing (MEC) through the integration
and evaluation of efficient allocation of computational resources, intelligent networking, and the
dynamic coordination of agents, microservices, and DTs [53]. Finally, we intend to identify proper
engineering guidelines for the development of complex EDT systems [78].

REFERENCES
[1] 5D-DIVE. (Accessed October 01 2021). 5G-DIVE Architecture and Detailed Analysis of Vertical Use Cases. https://5g-
dive.eu/wp-content/uploads/2020/04/D1.1_Final.pdf.
[2] 5G-Coral. (Accessed October 01 2021). Initial System Design, Use Cases, and Requirements. http://5g-coral.eu/wp-
content/uploads/2018/04/D1.1_final7760.pdf.
[3] Sailesh Abburu, Arne J. Berre, Michael Jacoby, Dumitru Roman, Ljiljana Stojanovic, and Nenad Stojanovic. 2020. COG-
NITWIN – hybrid and cognitive digital twins for the process industry. In 2020 IEEE International Conference on Engi-
neering, Technology and Innovation (ICE/ITMC’20). 1–8.
[4] Cristina Alcaraz and Javier Lopez. 2022. Digital twin: A comprehensive survey of security threats. IEEE Communica-
tions Surveys & Tutorials (2022), 1–1. https://doi.org/10.1109/COMST.2022.3171465
[5] Amazon. (Accessed October 01 2021). AWS FreeRTOS. https://aws.amazon.com/it/freertos/.
[6] Amazon. (Accessed October 01 2021). AWS Greengrass. https://aws.amazon.com/it/greengrass/.
[7] Amazon. (Accessed October 01 2021). AWS IoT. https://aws.amazon.com/it/iot/.
[8] B. R. Barricelli, E. Casiraghi, and D. Fogli. 2019. A survey on digital twin: Definitions, characteristics, applications,
and design implications. IEEE Access 7 (2019), 167653–167671. https://doi.org/10.1109/ACCESS.2019.2953499
[9] Paolo Bellavista, Javier Berrocal, Antonio Corradi, Sajal K. Das, Luca Foschini, and Alessandro Zanni. 2019. A survey
on fog computing for the Internet of Things. Pervasive and Mobile Computing 52 (2019), 71–99. https://doi.org/10.1016/
j.pmcj.2018.12.007
[10] Paolo Bellavista, Carlo Giannelli, Marco Mamei, Matteo Mendula, and Marco Picone. 2021. Application-driven
network-aware digital twin management in industrial edge environments. IEEE Transactions on Industrial Informatics
(2021), 1–1. https://doi.org/10.1109/TII.2021.3067447
[11] Paolo Bellavista, Carlo Giannelli, Marco Mamei, Matteo Mendula, and Marco Picone. 2022. Digital twin oriented
architecture for secure and QoS aware intelligent communications in industrial environments. Pervasive and Mobile
Computing 85 (2022), 101646. https://doi.org/10.1016/j.pmcj.2022.101646
[12] Flavio Bonomi, Rodolfo Milito, Jiang Zhu, and Sateesh Addepalli. 2012. Fog computing and its role in the Internet of
Things. In Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing (MCC’12). Association for
Computing Machinery, New York, NY, USA, 13–16. https://doi.org/10.1145/2342509.2342513
[13] C. Bormann and Z. Shelby. 2016. Block-Wise Transfers in the Constrained Application Protocol (CoAP). RFC 7959. RFC
Editor.
[14] Darya Botkina, Mikael Hedlind, Bengt Olsson, Jannik Henser, and Thomas Lundholm. 2018. Digital twin of a cutting
tool. Procedia CIRP 72 (2018), 215–218. https://doi.org/10.1016/j.procir.2018.03.178
[15] X. Duan, C. Zhou, and H. Yang. 2020. Concepts of Digital Twin Network. Internet-Draft draft-zhou-nmrg-digitaltwin-
network-concepts-00. IETF. https://tools.ietf.org/id/draft-zhou-nmrg-digitaltwin-network-concepts-00.html.
[16] Claudia Campolo, Giacomo Genovese, Antonella Molinaro, and Bruno Pizzimenti. 2020. Digital twins at the edge to
track mobility for MaaS applications. In 2020 IEEE/ACM 24th International Symposium on Distributed Simulation and
Real Time Applications (DS-RT’20). 1–6. https://doi.org/10.1109/DS-RT50469.2020.9213699
[17] Centre for Digital Built Britain (CDBB). (Accessed 22 July 2021). National Digital Twin (NDT) Project. https://www.
cdbb.cam.ac.uk/what-we-do/national-digital-twin-programme.
[18] Olga Chukhno, Nadezhda Chukhno, Giuseppe Araniti, Claudia Campolo, Antonio Iera, and Antonella Molinaro. 2020.
Optimal placement of social digital twins in edge IoT networks. Sensors 20, 21 (2020). https://doi.org/10.3390/s20216181
[19] S. Cirani, L. Davoli, G. Ferrari, R. Léone, P. Medagliani, M. Picone, and L. Veltri. 2014. A scalable and self-configuring
architecture for service discovery in the Internet of Things. IEEE Internet of Things Journal 1, 5 (Oct. 2014), 508–521.
https://doi.org/10.1109/JIOT.2014.2358296
[20] S. Cirani, G. Ferrari, N. Iotti, and M. Picone. 2015. The IoT hub: A fog node for seamless management of heteroge-
neous connected smart objects. In 2015 12th Annual IEEE International Conference on Sensing, Communication, and
Networking - Workshops (SECON Workshops’15). 1–6. https://doi.org/10.1109/SECONW.2015.7328145
[21] Industrial Internet Consortium. 2020-02-18 - (Accessed October 01 2021). Digital Twins for Industrial Applications -
White Paper. https://www.iiconsortium.org/pdf/IIC_Digital_Twins_Industrial_Apps_White_Paper_2020-02-18.pdf.
[22] Angelo Croatti, Matteo Gabellini, Sara Montagna, and Alessandro Ricci. 2020. On the integration of agents and digital
twins in healthcare. Journal of Medical Systems 44, 9 (04 Aug. 2020), 161.
[23] Digital Twin Consortium. (Accessed July 01 2022). https://www.digitaltwinconsortium.org/index.htm.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:30 M. Picone et al.

[24] ETSI. (Accessed October 01 2021). Multi-access Edge Computing (MEC); Framework and Reference Architecture. https:
//www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf.
[25] ETSI. (Accessed October 01 2021). Standards Enabled Digital Twin in LSP AUTOPILOT. https://docbox.etsi.
org/Workshop/2018/201810_IoTWEEK/02_IoTWORKSHOP/S06_PART2_IoT_IN_ACTION/AUTOPILOT_NEC-
BAUER_EGM-LI.pdf.
[26] Eclise Foundation. (Accessed October 01 2021). Bosh IoT Suite. https://www.bosch-iot-suite.com/.
[27] Eclise Foundation. (Accessed October 01 2021). Eclipse Ditto. -https://www.eclipse.org/ditto/.
[28] A. Fuller, Z. Fan, C. Day, and C. Barlow. 2020. Digital twin: Enabling technologies, challenges and open research. IEEE
Access 8 (2020), 108952–108971. https://doi.org/10.1109/ACCESS.2020.2998358
[29] David Gelernter. 1991. Mirror Worlds or the Day Software Puts the Universe in a Shoebox: How Will It Happen and What
It Will Mean. Oxford University Press, Inc., New York, NY, USA.
[30] Google. (Accessed October 01 2021). Google Cloud IoT. https://cloud.google.com/solutions/iot.
[31] Google. (Accessed October 01 2021). Google Cloud IoT - Edge. https://cloud.google.com/blog/products/gcp/bringing-
intelligence-edge-cloud-iot.
[32] Carlos Guimaraes, Antonio de la Oliva Delgado, and Arturo Azcorra Salona. 2019. 5G-DIVE: eDge Intelligence for
Vertical Experimentation.
[33] Cenk Gündoğan, Peter Kietzmann, Martine Lenders, Hauke Petersen, Thomas C. Schmidt, and Matthias Wählisch.
2018. NDN, CoAP, and MQTT: A comparative measurement study in the IoT. In Proceedings of the 5th ACM Conference
on Information-Centric Networking (ICN’18). Association for Computing Machinery, New York, NY, USA, 159–171.
https://doi.org/10.1145/3267955.3267967
[34] Maria G. Juarez, Vicente J. Botti, and Adriana S. Giret. 2021. Digital twins: Review and challenges. Journal of
Computing and Information Science in Engineering 21, 3 (04 2021). https://doi.org/10.1115/1.4050244 arXiv:https://
asmedigitalcollection.asme.org/computingengineering/article-pdf/21/3/030802/6696358/jcise_21_3_030802.pdf
030802.
[35] Mehdi Kherbache, Moufida Maimour, and Eric Rondeau. 2022. Network digital twin for the Industrial Internet of
Things. In 2022 IEEE 23rd International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM).
[36] Niki Kousi, Christos Gkournelos, Sotiris Aivaliotis, Christos Giannoulis, George Michalos, and Sotiris Makris. 2019.
Digital twin for adaptation of robots’ behavior in flexible robotic assembly lines. Procedia Manufacturing 28 (2019),
121–126. https://doi.org/10.1016/j.promfg.2018.12.020
[37] Vladimir Kuts, Tauno Otto, Toivo Tähemaa, and Yevhen Bondarenko. 2019. Digital twin based synchronised control
and simulation of the industrial robotic cell using virtual reality. Journal of Machine Engineering 19 (02 2019), 128–144.
https://doi.org/10.5604/01.3001.0013.0464
[38] Junhee Lee, Sungjoo Kang, Jaeho Jeon, and Ingeol Chun. 2020. Multiaccess edge computing-based simulation as a ser-
vice for 5G mobile applications: A case study of tollgate selection for autonomous vehicles. Wireless Communications
and Mobile Computing 2020 (03 2020), 1–15. https://doi.org/10.1155/2020/9869434
[39] Shinho Lee, Hyeonwoo Kim, Dong-kweon Hong, and Hongtaek Ju. 2013. Correlation analysis of MQTT loss and
delay according to QoS level. In The International Conference on Information Networking 2013 (ICOIN’13). 714–717.
https://doi.org/10.1109/ICOIN.2013.6496715
[40] Y. Lu, X. Huang, K. Zhang, S. Maharjan, and Y. Zhang. 2020. Communication-efficient federated learning and permis-
sioned blockchain for digital twin edge networks. IEEE Internet of Things Journal (2020), 1–1. https://doi.org/10.1109/
JIOT.2020.3015772
[41] M. Kovatsch, R. Matsukura, M. Lagally, T. Kawaguchi, K. Toumura, and K. Kajimoto. 9 April 2020 - (Accessed October
01 2021). Web of Things (WoT) Architecture. W3C Recommendation. https://www.w3.org/TR/wot-architecture/.
[42] Somayeh Malakuti and Sten Grüner. 2018. Architectural aspects of digital twins in IIoT systems. In Proceedings of
the 12th European Conference on Software Architecture: Companion Proceedings (ECSA’18). Association for Computing
Machinery, New York, NY, USA, Article 12, 2 pages. https://doi.org/10.1145/3241403.3241417
[43] Stefano Mariani, Marco Picone, and Alessandro Ricci. 2022. About Digital Twins, Agents, and Multiagent Systems: A
Cross-fertilisation Journey. https://doi.org/10.48550/ARXIV.2206.03253
[44] Marketsandmarkets.com. 2020 - (Accessed October 01 2021). Digital Twin Market by Source, Type, Applica-
tion & Geography– COVID-19 Impact Analysis MarketsandMarkets. https://www.marketsandmarkets.com/Market-
Reports/digital-twin-market-225269522.html.
[45] Roberto Martinez-Velazquez, Rogelio Gamez, and Abdulmotaleb El Saddik. 2019. Cardio twin: A digital twin of the
human heart running on the edge. In 2019 IEEE International Symposium on Medical Measurements and Applications
(MeMeA’19). 1–6. https://doi.org/10.1109/MeMeA.2019.8802162
[46] Members of the Digital Framework Task Group. 2018. White Paper: The Gemini Principles. Technical Report. Centre
of Digital Built Britain. Available at https://www.cdbb.cam.ac.uk/DFTG/GeminiPrinciples. Last access: 20210401.
[47] Microsoft. (Accessed October 01 2021). Azure IoT. https://azure.microsoft.com/en-us/overview/iot/.

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
A Flexible and Modular Architecture for Edge Digital Twin 8:31

[48] Microsoft. (Accessed October 01 2021). Azure IoT Edge. https://azure.microsoft.com/en-us/services/iot-edge/#iotedge-


overview.
[49] Microsoft Azure. (Accessed July 01 2022). Digital Twins Definition Language (DTDL). https://github.com/Azure/
opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md.
[50] Roberto Minerva and Noël Crespi. 2021. Digital twins: Properties, software frameworks, and application scenarios. IT
Professional 23, 1 (2021), 51–55. https://doi.org/10.1109/MITP.2020.2982896
[51] R. Minerva, G. M. Lee, and N. Crespi. 2020. Digital twin in the IoT context: A survey on technical features, scenarios,
and architectural models. Proc. IEEE (2020), 1–40.
[52] OneM2M. ([n. d.]). Architecture and Standards for M2M Communications. https://www.onem2m.org/.
[53] Marco Picone, Stefano Mariani, Marco Mamei, Franco Zambonelli, and Mirko Berlier. 2021. WIP: Preliminary evalua-
tion of digital twins on MEC software architecture. In 2021 IEEE 22nd International Symposium on a World of Wireless,
Mobile and Multimedia Networks (WoWMoM’21). 256–259. https://doi.org/10.1109/WoWMoM51794.2021.00047
[54] P. Porambage, J. Okwuibe, M. Liyanage, M. Ylianttila, and T. Taleb. 2018. Survey on multi-access edge computing for
Internet of Things realization. IEEE Communications Surveys Tutorials 20, 4 (2018), 2961–2991.
[55] Anand S. Rao and Michael P. Georgeff. 1991. Modeling rational agents within a BDI-architecture. In Proceedings of the
2nd International Conference on Principles of Knowledge Representation and Reasoning (KR’91). Cambridge, MA, USA,
April 22–25, 1991. Morgan Kaufmann, 473–484.
[56] Filippo Rebecchi, Antonio Pastor, Alberto Mozo, Chiara Lombardo, Roberto Bruschi, Ilias Aliferis, Roberto Doriguzzi-
Corin, Panagiotis Gouvas, Antonio Alvarez Romero, Anna Angelogianni, Ilias Politis, and Christos Xenakis. 2022. A
digital twin for the 5G era: The SPIDER cyber range. In 2022 IEEE 23rd International Symposium on a World of Wireless,
Mobile and Multimedia Networks (WoWMoM’22).
[57] Alessandro Ricci, Angelo Croatti, Stefano Mariani, Sara Montagna, and Marco Picone. 2021. Web of digital twins. ACM
Transaction on Internet Technology. (Dec. 2021). https://doi.org/10.1145/3507909
[58] Alessandro Ricci, Angelo Croatti, and Sara Montagna. 2021. Pervasive and connected digital twins–a vision for digital
health. IEEE Internet Computing (2021). https://doi.org/10.1109/MIC.2021.3052039
[59] Alessandro Ricci, Michele Piunti, Luca Tummolini, and Cristiano Castelfranchi. 2015. The mirror world: Preparing for
mixed-reality living. IEEE Pervasive Computing 14, 2 (2015), 60–63.
[60] D. Riemer. 2018. Feeding the digital twin: Basics, models and lessons learned from building an IoT analytics toolbox
(invited talk). In 2018 IEEE International Conference on Big Data (Big Data’18). 4212–4212.
[61] S. Kaebisch, T. Kamiya, M. McCool, V. Charpenay, and M. Kovatsch. 9 April 2020 - (Accessed October 01 2021). Web of
Things (WoT) Thing Description, W3C Proposed Recommendation 9 April 2020, World Wide Web Consortium (W3C).
https://www.w3.org/TR/wot-thing-description/.
[62] R. Saracco. 2019. Digital twins: Bridging physical space and cyberspace. Computer 52, 12 (2019), 58–64. https://doi.
org/10.1109/MC.2019.2942803
[63] Angira Sharma, Edward Kosasih, Jie Zhang, Alexandra Brintrup, and Anisoara Calinescu. 2020. Digital Twins: State
of the Art Theory and Practice, Challenges, and Open Research Questions. (2020). arXiv:cs.LG/2011.02833
[64] Z. Shelby. 2012. Constrained RESTful Environments (CoRE) Link Format. RFC 6690. RFC Editor.
[65] Zach Shelby, Klaus Hartke, and Carsten Bormann. 2014. The Constrained Application Protocol (CoAP). RFC 7252.
(June 2014). https://doi.org/10.17487/RFC7252
[66] Zach Shelby, Michael Koster, Carsten Bormann, Peter van der Stok, and Christian Amsuess. 2019. CoRE Resource Direc-
tory. Internet-Draft draft-ietf-core-resource-directory-21. IETF Secretariat. http://www.ietf.org/internet-drafts/draft-
ietf-core-resource-directory-21.txt; http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-21.txt.
[67] Zach Shelby, Michael Koster, Christian Groves, Jintao Zhu, and Bill Silverajan. 2019. Reusable Interface Definitions for
Constrained RESTful Environments. Internet-Draft draft-ietf-core-interfaces-14. IETF Secretariat.
[68] J. Sleuters, Y. Li, J. Verriet, M. Velikova, and R. Doornbos. 2019. A digital twin method for automated behavior analysis
of large-scale distributed IoT systems. In 2019 14th Annual Conference System of Systems Engineering (SoSE’19). 7–12.
[69] E. Y. Song, M. Burns, A. Pandey, and T. Roth. 2019. IEEE 1451 smart sensor digital twin federation for IoT/CPS research.
In 2019 IEEE Sensors Applications Symposium (SAS’19). 1–6.
[70] V. Souza, R. Cruz, W. Silva, S. Lins, and V. Lucena. 2019. A digital twin architecture based on the Industrial Internet
of Things technologies. In 2019 IEEE International Conference on Consumer Electronics (ICCE’19). 1–2.
[71] Christian Stary. 2021. Digital twin generation: Re-conceptualizing agent systems for behavior-centered cyber-physical
system development. Sensors 21, 4 (2021).
[72] Charles Steinmetz, Achim Rettberg, Fabíola Gonçalves C. Ribeiro, Greyce Schroeder, and Carlos E. Pereira. 2018. In-
ternet of things ontology for digital twin in cyber physical systems. In 2018 VIII Brazilian Symposium on Computing
Systems Engineering (SBESC’18). IEEE, 154–159.
[73] X. Sun and N. Ansari. 2016. EdgeIoT: Mobile edge computing for the Internet of Things. IEEE Communications Maga-
zine 54, 12 (2016), 22–29. https://doi.org/10.1109/MCOM.2016.1600492CM

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.
8:32 M. Picone et al.

[74] Fei Tao and Qinglin Qi. 2019. Make more digital twins. Nature 573, 7775 (2019), 490–491. https://doi.org/10.1038/
d41586-019-02849-1
[75] Fei Tao, Meng Zhang, and A. Y. C. Nee. 2019. Chapter 1 - Background and concept of digital twin. In Digital Twin
Driven Smart Manufacturing, Fei Tao, Meng Zhang, and A. Y. C. Nee (Eds.). Academic Press, 3–28. https://doi.org/10.
1016/B978-0-12-817630-6.00001-1
[76] Paul Valckenaers. 2018. ARTI reference architecture - PROSA revisited. In Service Orientation in Holonic and Multi-
Agent Manufacturing (Studies in Computational Intelligence), Theodor Borangiu, Damien Trentesaux, André Thomas,
and Sergio Cavalieri (Eds.), Vol. 803. Springer, 1–19. https://doi.org/10.1007/978-3-030-03003-2_1
[77] Xiulei Wang, Li Deng, and Ming Chen. 2022. DTCPN: A digital twin cyber platform based on NFV. In 2022 IEEE 23rd
International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM’22).
[78] Franco Zambonelli. 2017. Key abstractions for IoT-oriented software engineering. IEEE Software 34, 1 (2017), 38–45.
[79] Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin Wu, Mohamed Boucadair,
and Christian Jacquenet. 2022. Digital Twin Network: Concepts and Reference Architecture. Internet-Draft draft-
irtf-nmrg-network-digital-twin-arch-01. Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-irtf-
nmrg-network-digital-twin-arch/01/. Work in Progress.

Received 27 October 2021; revised 9 November 2022; accepted 24 November 2022

ACM Transactions on Internet of Things, Vol. 4, No. 1, Article 8. Publication date: February 2023.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy