ETSI GR CIM 017 V1.1.1 (2022-12)

Context Information Management (CIM); Feasibility of NGSI-LD for Digital Twins

DGR/CIM-0017

General Information

• Status: Not Published
• Technical Committee: CIM - cross-cutting Context Information Management
• Current Stage: 12 - Completion
• Due Date: 15-Dec-2022
• Completion Date: 21-Dec-2022

Standards Content (Sample)

GROUP REPORT
Context Information Management (CIM);
Feasibility of NGSI-LD for Digital Twins
Disclaimer
The present document has been produced and approved by the cross-cutting Context Information Management (CIM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR CIM 017 V1.1.1 (2022-12)

Reference
DGR/CIM-0017
Keywords
artificial intelligence, context capturing and
analysis, Digital Twins, IoT
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GR CIM 017 V1.1.1 (2022-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Illustrative use cases . 9
4.0 Introduction . 9
4.1 Water distribution network . 10
4.1.1 Usage . 10
4.1.2 Challenges. 10
4.1.3 Solution proposal . 10
4.1.4 Gaps . 12
4.2 Digital Twins in robotics . 13
4.2.1 Usage . 13
4.2.2 Challenges. 14
4.2.3 Solution proposal . 14
4.2.4 Gaps . 15
4.3 Use of Digital Twins in the aeronautic sector . 15
4.3.1 Usage . 15
4.3.2 Challenges. 15
4.3.3 Solution proposal . 15
4.3.4 Gaps . 17
4.5 eHealth monitoring system . 17
4.5.1 Usage . 17
4.5.2 Challenges. 18
4.5.3 Solution Proposal . 18
4.5.4 Gaps . 21
4.6 Elevator Use Case . 21
4.6.1 Usage . 21
4.6.2 Challenges. 21
4.6.3 Solution Proposal . 21
4.6.4 Gaps . 22
5 Existing initiatives and relations . 22
6 Purpose and usage of Digital Twins . 26
6.1 Classification of Digital Twins . 26
6.1.1 Definition . 26
6.1.2 Atomic-twins . 27
6.1.3 System-Twins (STs): self-contained systems as rooted subgraphs . 27
6.1.4 Systems of Systems Twins (SoSTs): capturing distributed and complex systems . 28
6.2 Digital Twin capabilities . 29
6.2.0 Introduction. 29
6.2.1 Descriptive twin . 30
6.2.2 Predictive twin . 30
6.2.3 Prospective twin . 31
ETSI
4 ETSI GR CIM 017 V1.1.1 (2022-12)
6.2.4 Prescriptive twin . 31
6.2.5 Diagnosis twin . 32
6.3 Digital Twin lifecycle . 32
6.4 NGSI-LD architecture for Digital Twin systems . 33
7 Proposed orientations for NGSI-LD specification . 34
7.1 Summary of identified gaps and recommendations . 34
7.2 Suggested Actuation Workflows for Digital Twins using current NGSI-LD API . 34
7.2.1 Actuators and feedback to the application . 34
7.2.2 Architecture for actuation . 35
7.2.3 Structure of Commands and additional Properties . 36
7.2.3.0 Introduction . 36
7.2.3.1 Property for listing available commands . 36
7.2.3.2 Properties for command endpoints . 37
7.2.4 Communication model . 39
7.2.4.1 Possible communication models . 39
7.2.4.2 Subscription/notification model . 39
7.2.4.3 Forwarding model . 40
7.2.5 Implementation of the subscription-based actuation workflow . 41
7.2.6 Implementation of the registration-based actuation workflow. 42
7.3 Service execution with Digital Twins . 44
7.3.1 Motivation. 44
7.3.2 Solution proposal . 44
7.3.3 Service Executor . 45
7.3.4 Service execution . 45
7.3.5 Service execution example . 46
Annex A: Change History . 49
History . 50

ETSI
5 ETSI GR CIM 017 V1.1.1 (2022-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) cross-cutting Context
Information Management (CIM).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document analyses the use of NGSI-LD information model and API for representation and handling of
digital twins. It starts with a description of actual digital twin use cases, in several vertical domains. Then it provides an
identification of relevant external technical initiatives. Finally, the present document provides concrete views on the
definition of Digital Twins in an NGSI-LD ecosystem including identification of Digital Twin capabilities and life cycle
stages. The final clauses analyse how, taking inspiration from actuation mechanisms, a service execution API could be
defined to handle Digital Twin capabilities.
ETSI
6 ETSI GR CIM 017 V1.1.1 (2022-12)
Introduction
The present document advocates the use of NGSI-LD property graphs as holistic Digital Twins, maintaining multi-level
and multi-scale descriptions of complete environments, such as cities, buildings or factories. The nodes of the proposed
multilevel graph stand for any real-assets, which can be a physical asset or a concept. The arcs of the graph represent
relationships between these entities, which capture the physical and information structure of a system. They can capture
top-down and bottom-up system composition relationships, or transversal connectors (like cables, pipes, etc.) in a
distributed network-like system. A further level of description captures distributed or loosely coupled "systems of
systems" as "graphs of graphs", i.e. graphs, whose "hypernodes" encapsulate other graphs). By maintaining this shared
context, the graph makes it possible for different applications in these environments to locate and share their data
sources on the basis of the consolidated information stored in the graph, much as the knowledge graph of as search
engine does for the Web. The graph platform can play the role of a Digital Twin, in the sense of a one-stop-shop for
applications operating upon these environments. The NGSI-LD specification is thus already an actor in the Digital
Twins area and the present document aims at exploring its current usage, positioning within the overall Digital Twins
technical landscape and providing recommendations for NGSI-LD specification evolution.
Most of the work referenced in the present document was created with the support of the following European Union
Horizon 2020 research projects: No. 818036 (iFishIENCi), No. 821036 (FIWARE4WATER), No. 871319
(ADEPTNESS), No. 731993 (AutoPilot), No. 832876 (aqua-3S), No. 814918 (Fed4IoT) and French project "Cloud
Continuum Souverain et Jumeaux Numériques" funded by BPIFrance under contract DOS0179607/00 - ®
DOS0179608/00, including many contributions from members of the FIWARE Community.

ETSI
7 ETSI GR CIM 017 V1.1.1 (2022-12)
1 Scope
The purpose of the present document is to show to what extent various Digital Twin types can be realized or facilitated
by NGSI-LD and to identify new features for NGSI-LD which would make it more useful for such areas of usage.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Grieves, Michael, et John Vickers: "Digital Twin: Mitigating Unpredictable, Undesirable
Emergent Behavior in Complex Systems". In Transdisciplinary Perspectives on Complex Systems,
edited by Franz-Josef Kahlen, Shannon Flumerfelt, and Anabela Alves, 85‑113. Cham: Springer
International Publishing, 2017.
NOTE: Available at https://doi.org/10.1007/978-3-319-38756-7_4.
[i.2] Gilles Privat: "Phenotropic and stigmergic webs: The new reach of networks". Universal Access in
the Information Society 08/2012; 11(3):1-13., DOI:10.1007/s10209-011-0240-1.
[i.3] Gilles Privat: "The "Systems of Systems". Viewpoint in telecommunications", Orange Research
Blog, September 2018.
[i.4] OWA-EPANET Toolkit.
NOTE: Available at http://wateranalytics.org/EPANET/.
[i.5] Tuegel, Eric, Ingraffea, Anthony, Eason, Thomas, et Spottswood, Stephen. (2011): "Reengineering
Aircraft Structural Life Prediction Using a Digital Twin". In International Journal of Aerospace
Engineering, 2011.
NOTE: Available at https://doi.org/10.1155/2011/154798.
[i.6] Boss, Birgit & Malakuti, Somayeh & Lin, Shi-Wan & Usländer, Thomas & Clauer, Erich &
Hoffmeister, Michael & Stojanovic, Ljiljana & Flubacher, Björn. (2020): "Digital Twin and Asset
Administration Shell Concepts and Application in the Industrial Internet and Industrie 4.0". An
Industrial Internet Consortium and Plattform Industrie 4.0 Joint Whitepaper.
NOTE: Available at https://www.iiconsortium.org/pdf/Digital-Twin-and-Asset-Administration-Shell-Concepts-
and-Application-Joint-Whitepaper.pdf.
[i.7] ETSI GS CIM 009: "Context Information Management (CIM); NGSI-LD API".
[i.8] ETSI GS CIM 006: "Context Information Management (CIM); Information Model (MOD0)".
ETSI
8 ETSI GR CIM 017 V1.1.1 (2022-12)
[i.9] "PackML language for the control of packaging machines".
NOTE: Available at https://en.wikipedia.org/wiki/PackML.
[i.10] IEC TC 65: "Industrial-process measurement, control and automation".
NOTE: Available at https://www.iec.ch/dyn/www/f?p=103:7:14089666729290::::FSP_ORG_ID:1250.
[i.11] ISO 23247-1:2021: "Automation systems and integration -- Digital twin framework for
manufacturing -- Part 1: Overview and general principles".
NOTE: Available at https://www.iso.org/standard/75066.html.
[i.12] ISO 23247-2:2021: "Automation systems and integration -- Digital twin framework for
manufacturing -- Part 2: Reference architecture".
NOTE: Available at https://www.iso.org/standard/78743.html.
[i.13] ISO 23247-3:2021: "Automation systems and integration -- Digital twin framework for
manufacturing -- Part 3: Digital representation of manufacturing elements".
NOTE: Available at https://www.iso.org/standard/78744.html.
[i.14] ISO 23247-4:2021: "Automation systems and integration -- Digital twin framework for
manufacturing -- Part 4: Information exchange".
NOTE: Available at https://www.iso.org/standard/78745.html.
[i.15] ETSI TS 103 828: "SmartM2M; SAREF: Ontology Support for Urban Digital Twins and usage
guidelines".
NOTE: Available at https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=63076.
[i.16] ISO/IEC AWI 30173: "Digital twin -- Concepts and terminology".
NOTE: Available at https://www.iso.org/standard/81442.html.
[i.17] IEC Technology report: "City information modelling and urban digital twins".
NOTE: Available at https://www.iec.ch/basecamp/city-information-modelling-and-urban-digital-twins.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AASX Asset Administration Shell Explorer
AEC Architecture, Engineering, Construction
AI Artificial Intelligence
AMR Autonomous Mobile Robots
API Application Programming Interface
AR Augmented Reality
ETSI
9 ETSI GR CIM 017 V1.1.1 (2022-12)
ARF Augmented Reality Framework
BIM Building Information Management
DMA District Metered Area
DT Digital Twin
DTDL Digital Twin Description Language
EC European Commission
EPANET Environmental Protection Agency Network Evaluation Tool
F6G Fixed 6G
GIS Geographic Information System
HiL Hardware in the Loop
HTTP HyperText Transfer Protocol
IATA International Air Transport Association
ICAO International Civil Aviation Organization
IEC International Electrotechnical Commission
IIoT Industrial Internet of Things
IoT Internet of Things
IOWN Innovative Optical and Wireless Network
IT Information Technology
JSON JavaScript Object Notation
JTC Joint Technical Committee
LD Linked Data
LWM2M Lightweight Machine To Machine
M2M Machine To Machine
ML Machine Learning
MLS Machine Learning Service
MQTT Message Queuing Telemetry Transport
NGSI Next Generation Service Interfaces
OASCs Open and Agile Smart Cities
OGC Open Geospatial Consortium
PackML Packaging Machine Language
QoS Quality of Service
RAMI Reference Architectural Model Industry
RFID Radio Frequency IDentification
ROS Robot Operating System
RWA Real World Asset
SAREF Smart Applications REFerence
SCADA Supervisory Control and Data Acquisition
SiL Software in the Loop
SMS Short Message Service
SoSTs Systems of systems Twins
ST System Twin
STF Specialist Task Force
STs System-Twins
UDT Urban Digital Twins
UI/UX User interface/User experience
UL Ultra Light
URI Universal Resource Identifier
WDS Water Distribution System
WoT Web of Things
4 Illustrative use cases
4.0 Introduction
Clause 4 describes some of the on-going initiatives making use of NGSI-LD information model and API to define and
interact with Digital Twins. The concept of Digital Twins is not elaborated here, because many variations are explained
in the literature [i.1], [i.2], [i.5],[i.6], [i.11], [i.15], [i.16], [i.17].
ETSI
10 ETSI GR CIM 017 V1.1.1 (2022-12)
4.1 Water distribution network
4.1.1 Usage
Management of Water Distribution Systems (WDSs) is an area where DTs have significant potential, and they are
already starting to be implemented to address issues such as optimizing operation of the system, asset management and
water leak localisation. However, development of DTs for WDSs can be complex, with the need for any hydraulic
and/or quality model to be constantly paired with data and information from multiple sources in the physical world,
including, for example, Supervisory Control and Data Acquisition (SCADA) and consumption metering systems.
Transmission, conversion, storage and protection of this data are all important issues for consideration and are currently
complicated by a lack of standardization. However, standardization, along with interoperability and integration are
fundamental features of a successful DT. The described research integrates the WDS simulation toolkit, OWA-
EPANET [i.4], within a FIWARE NGSI-LD environment.
The functionalities foreseen from that integration focus on the system in operation and include:
• Simpler interface to a composed system: such as exposing the "equivalent water pump" of N water pumps
connected in parallel. This equivalent pump can thus be queried and configured as if it would be a real water
pump.
• Predictive analytics: to provide a prediction of the system state in the future (T1), based on the current state
(T0).
• Outliers/anomaly detection: to raise alerts in case the network deviates from its anticipated state.
EXAMPLE 1: By comparing the actual state of the system at T1 with the simulation T1 executed at T0.
EXAMPLE 2: By comparing the state of a subnetwork with expected state calculated using simulation based on
other part of the system.
• What-if scenario: how will the system evolve if an action is taken starting from the current state, modifying
some parameters in the model (i.e. close a valve).
• Network optimisation: starting from the current state, identify the optimum functioning point (i.e. reduce
water pump energy consumption while maintaining requested pressure). When combined with actuation (not
mandatory), this functionality provides automated management.
4.1.2 Challenges
Several challenges have been identified:
• Sharing a common data model representation between the target EPANET simulator and the NGSI-LD
representation.
• Having a model which allows the selection of only sub-parts of the water network (i.e. DMA - District
Metered Area level) to be used within the simulation.
• To provide a service feeding the simulator with appropriate values and configuration parameters and storing
the resulting state without storing the whole simulated result, so as to avoid overloading the system storage.
4.1.3 Solution proposal
A NGSI-LD data model for water network, aligned with the definition of the EPANET hydraulic simulator has been
proposed (https://github.com/smart-data-models/dataModel.WaterDistributionManagementEPANET). An overview is
provided in the picture below. All parts of the network are considered of equal importance from a modelling point of
view so they have all been modelled as entities, including pipes. In addition, most of the network entities are directed,
so connections are made through startsAt and endsAt relationships.
ETSI
11 ETSI GR CIM 017 V1.1.1 (2022-12)

Figure 4.1.3-1: NGSI-LD model of a water distribution network
In addition, as seen on the next picture, a system composition approach has been made by defining entities representing
the different DMAs. This allows a simulation to handle only one specific DMA. Any simulation is associated to a
NGSI-LD entity which holds through its attributes: the simulator configuration options, possibly, a list of value to be
changed change from actual values (to run a "what-if" scenario) and the list of points in the water network to be
controlled so not all the network state needs to be saved.

Figure 4.1.3-2: Handling of simulation parameters within a NGSI-LD representation
To facilitate the integration of the NGSI-LD context information and EPANET, a new interface has been developed.
The key functionalities provided by this are:
a) translation of existing EPANET model data into the requisite NGSI-LD format;
b) posting of this information to a NGSI-LD context broker;
c) retrieval of all data necessary to generate an up-to-date network model for simulation (capturing real-time
network data supplied to the context broker from other sources such as IoT platforms); and
d) as and when required, running hydraulic and quality simulations of the network.
ETSI
12 ETSI GR CIM 017 V1.1.1 (2022-12)

Figure 4.1.3-3: Architecture and functionalities provided in the EPANET-FIWARE integration module
The new NGSI-LD-integrated implementation of EPANET outlined in the previous sections has been applied to a case
study water distribution network from the South West of England to test and demonstrate some of the functionalities
offered. The network is a small, gravity-fed system, with the EPANET model containing only one source (modelled as a
reservoir), 1 005 nodes and 1 035 links. It also contains 91 household level smart meters, which provide daily water
consumption measurements for individual houses. Data from these meters is posted to a Stellio context broker in
accordance with the 'WaterSmartMeter' data model.
In this case study, historical smart meter data is used to adjust and extend the demand patterns in the EPANET model to
capture daily variations in demand and enable more realistic simulation of hydraulic performance under historical
conditions. To illustrate the impact of using smart meter data instead of the default demands defined in the EPANET
input file on the hydraulic simulation results. Figure 4.1.3-4a) compares the results of pressure time series for one
junction with an associated smart meter, Figure 4.1.3-4b) shows the flow rate in the pipe supplying this node.

Figure 4.1.3-4: Example of hydraulic results obtained with the default network model demands and
with demands updated based on data retrieved from smart meters
4.1.4 Gaps
It appeared that in its current version the NGSI-LD specification is fully relevant for definition and management of
Digital Twins, even, in the context of a water distribution network made of several sub-systems. Still, some
improvement could be made:
• Improved handling of system composition to avoid multiplying relationships toward all entities of a sub-
system.
ETSI
13 ETSI GR CIM 017 V1.1.1 (2022-12)
• Improve management of relationships to make them first class citizen as are the entities in the NGSI-LD API
to allow more traditional modelling of a water distribution network. Nevertheless, handling the fact that a pipe
is not directed (water can flow in both way) within a directed graph would require additional investigations.
• Provide capabilities to ease handling of a simulator within a NGSI-LD based deployment. This includes
configuration of the simulator, handling of some special scenarios (e.g. What-if) and storage of the key results.
4.2 Digital Twins in robotics
4.2.1 Usage
Two basic but essential core robotics scenarios should be explored as application enablers:
• 2D Robot Navigation (e.g. autonomous robot navigation for intra-logistics).
• Pick and Place Operations (e.g. palletization, packaging, product sorting, etc.).
An advanced scenario is the 3D navigation of drones. In turn, many features of this scenario may be simplified and
represented as a 2D Navigation.
EXAMPLE: Autonomous Mobile Robot for Warehouse Automation:
- Robot Entity: AMR (Transportation Robot) → Autonomous Navigation System (Interfaces
to Automated Path Planning Module, trajectory planning and obstacle avoidance are opaque).
- Robot Task: Move 'Item X' from 'Loc A' to 'Loc B'.
- EnvModel: Layout of the factory with annotatedLocations, Personnel: Warehouse Operator.
- IIoT Device: RFID Reader; User Interface: Stock Transfer Order Request.

Figure 4.2.1-1: Foreseen usage and expected functionalities from a DT deployment
ETSI
14 ETSI GR CIM 017 V1.1.1 (2022-12)
4.2.2 Challenges
The main challenges Identified for NGSI-based Digital Twins of Robotics Systems are:
• The software architecture of robotics systems is often a complex, monolithic architecture and largely
conditioned by mechatronic requirements. Robustness and efficiency are often at a premium. Reusability,
modularity, interoperability as they are understood in the IT world have been, in general, secondary aspects
within the robotics domain.
• Even at higher levels of discrete control and plan execution the interfaces are extremely heterogeneous.
Almost every robot manufacturer has its own framework/programming suite to develop applications and relies
on an ad/hoc communication protocol to integrate them.
• The Robot Operating System has been trying (and still tries) to offer a common framework for open-source
robotics application development. The adoption in real-world scenarios out of prototypes, laboratories, and
experimental settings is still limited. This invites exploring the robotics frameworks developed by robot
manufacturers and those developed by widespread system integrators and application simulators (Visual
Components). Probably, our space to create value for robotics applications is the implementation of
capabilities that easily integrate on top of these frameworks.
4.2.3 Solution proposal
The proposed solution is made of the following:
1) Smart Gateway on Top of the Native Robot Middleware.
2) NGSI-LD Compliant Digital Twin.
3) Smart Cloud for Accessible and Scalable Robotics Applications.

Figure 4.2.3-1: High level architecture for Digital Twins in robotics
Data: ROS Messages already define a number of properties and structures for core robotics applications that have
remained constant for long. One need to adopt additional data models from industry standards, in particular those
modelling real-world environments and devices and with the monitoring/configuration of automated jobs and
simulations.
Security: Since the robot interacts with the physical world, every scenario that considers an application scenario that
goes beyond the typical hard-coded behaviours for standalone robotics faces a number of security and safety issues.
ETSI
15 ETSI GR CIM 017 V1.1.1 (2022-12)
Services beyond v1.3 of API: Robot entities should advertise their special capabilities and their current hardware
state/configuration. Ideally the Digital Twin should automatically update its state when some end-effectors, sensors or
peripherals are connected, changed, replaced or removed from the base robot.
4.2.4 Gaps
NGSI-LD has potential to implement powerful robotics twins at the "integrated planning and execution levels" in which
context semantics play relevant roles. Objective is then to provide a common context data layer for heterogeneous robot
twins based on standardized context information management.
The main gap to be filled is the integration of NGSI-LD based robotics capabilities within the native executive features
of base robotics platforms. The design of criteria to conveniently monitor/sample/configure the discrete control loop of
the actual robot is not straightforward and still lack mechanisms to implement smart integration behaviours. Even in
simple robotics scenarios, the real-time monitoring of robot resources and capabilities as well as the maintenance of
right-time synchronized representation of the robot world is a challenging task.
4.3 Use of Digital Twins in the aeronautic sector
4.3.1 Usage
The Aeronautical sector is one of the many sectors in which large amounts of data are generated and, consequently, they
can be exploited by the implementation of Digital Twins, improving the performance of processes through the
communication between the physical and the virtual world. This use case presents an Airport Digital Twin Reference
used to improve turnaround process.
Airports are one of the infrastructures that require more organization and security protocols since they have to deal with
a high density of passengers, staff, aircrafts, baggage, data, etc. In particular, flight delays are a common problem
affecting airports, airlines and passengers. The lack of digitalization has made the turnaround process a bottleneck in
airport operations and a common cause of delays. This process is made up of several tasks, and in most airports, their
operations are coordinated through radio communications and paper forms completed by workers.
This use case shows how to improve the turnaround process thanks to context information management provided by
different sources, and how to take advantage of web services and 3D representations instead of printed version forms.
4.3.2 Challenges
DTs have been very prolific in the Aeronautics sector, in fact, one of the first DT use cases was developed in this
domain in the year 2011 [i.5]. Recently the interest of building DTs has increased in this sector, for both specific
purposes (e.g. modelling aircraft turbines and engines), and for general ones (e.g. modelling the whole airport). The
present document describes a DT of a commercial, with the objective of deploying a 2D/3D view application fed with
information in (pseudo)real-time about the airport, including, the stand occupancy, flight information, turnaround
events, etc., together with an operator's application that registers the flight tasks.
Examples of usage:
• Operator: 2D/3D navigation viewing the pending and completed tasks regarding the aircraft "W", placed in the
stand "X", related to the flight "Y" that is scheduled to depart in "Z" minutes.
• Passenger: 2D/3D navigation following its own luggage position in the airport.
The main challenge is on data ingestion and modelling from external sources: each source provides its data in its own
format, using its own protocols and standards. In the Aeronautics sector there are several widely disseminated standards
(e.g. ICAO, IATA). As a consequence, in some cases it is difficult to establish relationships between entities. As an
example, an API that identifies a flight with the ICAO format while another identifies it using the IATA designator.
4.3.3 Solution proposal
Figure 4.3.3-1 shows all the agents present in the Airport Digital Twin use case, including the data source/sink entities,
which interact with a NGSI-LD compliant platform.
ETSI
16 ETSI GR CIM 017 V1.1.1 (2022-12)

Figure 4.3.3-1: Context Information Exchange between Agents and
Data Sources/Actuators in Airport Digital Twin Use Case
Scenario "A": Scheduling Operators Depending on Aircraft Traffic
This scenario aims to improve the schedule of turnaround tasks among the operators of an airport based on the position
of aircrafts and information of flights. When a new aircraft is parked in a stand, the AirportNavigationApplication
updates the 3D model of the airport, the OperatorManagementSystem assigns tasks to the operators, and the operators
receive in their tablet details about their work and the place they have to go. The following data flows may occur.
Table 4.3.3-1: Scenario "A": Scheduling Operators Depending on Aircraft Traffic. Flow 1
Query/Notification from Response from NGSI-LD platform Sources of information used to
AirportNavigationApplication answer the query
Subscri
...