Digital Twin Building Blocks for Designing A Generic City-Wide Data Exchange Platform

1. Introduction

The first Digital Twin (DT). concept came after the launch of the National Aeronautics and Space Administration (NASA) Apollo 13 in April 1970, right after an explosion in the oxygen tanks critically damaging the spacecraft. The rescue mission by NASA involved creation of physically duplicated systems at ground level to match the spacecraft in orbit and used these physical twins to train astronauts and mission controllers in every mission scenario to mitigate multiple failures in reality [1]. Since then, DTs have been becoming predominantly virtual rather than physical. As a result, driven by remarkable industrial attention, DTs have flourished and ripened in many domains including aeronautics, healthcare, urban planning and agriculture. There is a growing interest from the software engineering and the software architecture communities that have proposed software architectural solutions for DTs.

[2] proposed the first definition of DTs as information-mirroring models of physical assets. Accordingly, a physical system has a virtual representation and the DT facilitates the information flow between the virtual and physical systems. The two systems enable a continuous synchronisation of the virtual to the physical part and vice versa. Thus, a DT can be considered a virtual instance of physical assets capable of continuously mirroring them. In essence, a DT duplicates physical objects (people, objects, spaces, systems, processes, etc.) in the real world into digital objects in the digital world, and provides various simulations for solving problems in the real world, or for correction and improvement [3].

Following the notable industrial adoption of DTs [e.g., [4,5,6,7,8]], there has been a growing need to connect them. [1] stated that although there is a lack of widely accepted reference architectural solutions for DTs, most of them are built using a combination of the layered and service-oriented patterns and address quality attributes of maintainability, performance efficiency, and compatibility. However, there is no current research addressing when and under which conditions what data governance style should be employed by City Councils, Transport Authorities, Hospitals, Emergency Services, and other organisations to facilitate data sharing. [9] stated that various proposals to achieve collective work between DTs have been investigated, however, more research is required to develop and validate appropriate mechanisms to ensure the successful deployment of federation in complex real-world cases that require collaboration among individual systems.

In this paper, our goal is to investigate the opportunities and barriers for a common data exchange model so that DTs can be connected with the aim of creating a generic data exchange platform that enables the reconfiguration of data from multiple sources. This may generate greater insights for DT adoption for decision making and de-risking investment and targeted resources. A generic data exchange platform could increase the capture and re-use of data from various systems and IoT devices. Federation may reduce the need for individual case-specific data exchange platforms for transforming data and increase the ability for open data platforms to share and exchange data irrespective of its initial configuration. However, there is a key question that comes to mind: what are the common building blocks in a tech stack that are required for the development of a range of DTs to operate a generic city-wide data exchange platform.

In the remaining sections of this paper, we will first review the current state of DTs, Data Exchange, and IoT, and then, investigate existing standards, data models, data governance and interoperability issues in DTs. After analysing the common components of a range of DTs, we propose a system architecture for federation. We then conclude with producing a set of recommendations for the development of Federated DT (FDT) systems. The scope of the review of data exchange models is limited with smart city applications but the proposed FDT system architecture should be applicable to any domain.

2. Digital Twins

As cities expand and their challenges become more complex, there is a growing need for cities to become smarter in leveraging their increasingly connected technologies to address these challenges. Through the strategic application of digital innovations, urban areas can enhance their resilience, efficiency, and overall liveability, contributing to a more sustainable future [10]. At the core of the smart city concept are DTs of the urban environment and the entities and systems within it. These DTs must be able to interact to fully unlock their potential, otherwise they will be siloed with relevant data and insights from one twin unused by others. The goal of the smart city is a convergence between IoT, DTs, and AI to manage effectively the complex systems, resources and assets encountered in the urban space [11]. DTs must connect with their physical twin and client applications in order to transfer data.

According to BS ISO/IEC 30173:2023 Digital Twin—Concepts and terminology, a digital twin is a “digital representation… of a target entity… with data connections that enable convergence between the physical and digital states at an appropriate rate of synchronization”. A typical example of a Digital Twin (DT) application may be a wind turbine (physical twin). The wind turbine may have sensors measuring various operational parameters, such as rotation speed, power generated, temperature, etc. The data from these sensors can be used to update a virtual model (the virtual twin). For example, this model can be used for monitoring to inform control of the wind turbine, or simulations could be run to determine how the wind turbine will perform under different conditions, given its current state. A simple 4-layer architecture in Figure 1, illustrates the multiplicity of data connections required in a Federated Digital Twin (FDT) system. Traditionally, this has been achieved using a variety of communication protocols and data formats, which introduces problems of interoperability.

International Digital Twin Case Studies

As demonstrated in Table 1, there is an extensive use of CityGML for data representation by the International digital twins and other OGC standards, such as GeoJSON. Table 1 consolidates the technical details, integration strategies, data exchange mechanisms, and applications of DTs in Singapore [13,14,15,16], Helsinki [17,18,19], Amsterdam [20,21,22,23], Berlin [24,25,26,27], and Dubai [28,29,30]. There is a diversity of approaches to integration of DTs, including centralised and federated approaches. In these DTs, data exchange is mostly through APIs.

3. Data Exchange

Data can come from a variety of sources and in a variety of formats. Data of relevance to a Smart City Digital Twin could include traffic data, condition of built infrastructure, temperature and air quality measurements, and many more. The data being produced may be event-driven (e.g., an alert that water-level has exceeded a threshold) or may be regularly sampled (e.g., the river height every hour). Even if the data is regularly sampled it might not be transmitted as soon as it is available, it may be aggregated or processed before being sent. This may be to reduce the volume of data transported or that the processed data is more useful than the raw data. Data exchange may involve real-time or “live” data, or archived data. The OPC UA framework for automation in manufacturing, provides device interfaces for accessing archived data as well as subscribing to specific data streams from devices at the desired rate of update. There is also an interface component for subscribing to event notifications from a device.

FDTs may support various communication types to facilitate real-time data transmission, processing, and decision-making. The three potential primary communication modes in an FDT are as following [31]:

1. Physical-to-Physical (P2P): P2P communication occurs between physical objects, such as IoT devices, sensors, actuators, and edge devices.

2. Physical-to-Virtual (P2V): P2V communication connects a physical object with its digital twin, enabling real-time data exchange between the physical and virtual environments.

3. Virtual-to-Virtual (V2V): V2V communication occurs entirely within the virtual environment, where multiple DTs interact and share data to coordinate decisions, simulate scenarios, and optimize operations.

These are distinct contexts for data exchange, where the data exchanged may be different. For instance, two digital twins may share data in the form of predicted operational parameters that are not directly observable in their physical twins. Whereas physical twins are most likely to share data on their current state with their digital twin. A key question is whether the Physical and Digital twins make their data available through web interfaces, which may take the form of APIs to them or Linked Data published by them. In automated manufacturing, the communication between physical devices is often required to be high-speed and there is a trade-off between the amount of context that can be provided and the speed of communication. This transfers more generally to the DT case, where the DT may be required to be updated in near real time [32].

3.1. Metadata

Despite the heterogeneity of data sources and formats as seen in the use cases, there are common elements that a receiving system would need to use incoming data correctly. The first is to understand the syntax of the data, so that it may be parsed/loaded. Secondly, it is necessary to know the meaning of the data (semantics)—what the data is, what units is it recorded in, and which device/sensor produced it, etc. This is usually included as metadata. The other important thing to know is when the data was recorded/synthesised.

• Data format (syntactic)—is the data JSON, XML, etc.?
• What is this data? e.g. Temperature in degrees Celsius.
• Timestamp—when was the data recorded/apply to?
• ID—which device/sensor produced this data?
• Location—where was this data recorded? Important for georeferencing.

Further fields may indicate the quality or validity of the data, allowing the receiving system to determine whether to use the data for its own purposes, or not. This theme will be developed further in the Interoperability section of this paper (in Section 6).

3.2. Comparisons Between Data Exchange Formats: JSON Vs XML

Table 2 lists general characteristics of two popular data exchange formats, JSON vs XML. Both are human and machine readable. As the schemas are flexible, required metadata can be added to support semantic interoperability. JSON originated in the need to encode JavaScript Objects hence the name JavaScript Object Notation for web traffic. However, JSON is now a widely used data format beyond its original context, with wide support across systems and programming languages. The JSON syntax is standardised in ISO/IEC 21778:2017. XML (Extensible Markup Language) was similarly defined for storing and transmitting data via the web. However, XML has a document focus as opposed to the data focus of JSON. This may be a disadvantage with sensors, etc. producing large quantities of numerical data, as XML does not support arrays.

3.3. Internet-of-Things (IoT)

The Internet-of-Things is simply the network of devices that connect to the internet to exchange information, which may include receiving commands to carry out physical actions if the device is so capable. Digital Twins are part of the Internet-of-Things (IoT) and therefore there is much commonality in the architecture with the use case of Digital Twins. Many of the problems faced in the creation of a platform for DTs are the same as those that have been faced for IoT generally. Of particular interest are the problems of:

• Interoperability—there are a plethora of communication protocols and data formats that make it difficult for devices to collaborate.
• Security—due to the connected nature of IoT devices they are exposed to possible cyberattacks.
• Privacy—IoT devices often collect personal and sensitive data.
• Scalability—as the number of IoT devices in the system increases, there is additional device management, network traffic and data to be processed.
• Data Management—IoT devices may generate large amounts of data that need to be processed, stored and analysed.

These are all problems that must also be addressed in a Federated Data Exchange Architecture for Digital Twins.

A model architecture of a typical IoT system is given below in Table 3. This architecture illustrates the data journey from the physical device to its use in applications and the decisions made using those applications. At different levels of the architecture different formats and protocols are used and these can vary between devices creating challenges with interoperability. The example formats/protocols are not intended to be exhaustive in Table 3. At the perception layer data must be encoded digitally (e.g., JSON), placed in an application level messaging protocol (e.g., HTTP), which must then be transported over the internet (e.g., IPv6/TCP) or other network, to where will be processed and used in applications.

4. Data Exchange for Digital Twins

ISO 23247-4:2021 Automation systems and integration—Digital twin framework for manufacturing, Part 4: Information Exchange is the only published ISO standard for data exchange for DTs. It is specific to the manufacturing context and recommends using protocols such as MTConnect and OPC-UA for edge device communication and HTTP/REST APIs for communication to user entities of the DT. Asset Administration Shell is suggested as the data model for describing digital twins, which can be encoded in various formats, e.g., JSON, XML, RDF (The Resource Description Framework, a method to describe and exchange graph data).

Data exchange comes with issues of verifiability: how do we know that the data came from the presumed source? How do we know that the data was not altered? A related issue is selective disclosure: How do we share some parts of our data to some parties and not others? Verification of the data source is important. Data should not be altered, once shared. Data parsing for sharing with interested parties must be possible. Distributed ledger (blockchain) technologies have been suggested as solutions to the issue of verifiability of data exchanged in the DT ecosystem. [35] aimed to solve the problems of verifying integrity, traceability, and data ownership across the many interacting units of a smart city with their SIGNED framework. Their framework has 2 key components a Traceability Layer to track digital assets, and a digital wallet to manage cryptographic credentials and verification for those assets. The blockchain is deployed in the Traceability Layer to hold a registry of verifiable public keys and public addresses that can be used for data exchange. There is some momentum to using blockchain in securing IoT; and Siemens has recently partnered with Minima to embed blockchain into IoT devices, so that data integrity, and communication can be verified cryptographically2.

5. Data Governance

Data governance plays a critical role in ensuring the security, integrity, and usability of data within the FDT architecture. The key objectives are:

• Data Security: Protect sensitive information from unauthorised access, breaches, and tampering.
• Data Privacy: Comply with regulations (e.g., GDPR) to protect individuals’ data and ensure lawful data handling.
• Data Integrity: Ensure that data exchanged among DTs is accurate, consistent, and reliable.
• Transparency and Accountability: Define clear roles and responsibilities for data ownership, processing, and oversight.
• Interoperability and Standards: Establish protocols and standards to enable seamless data exchange between heterogeneous systems.

Nine key Data Governance Framework Components have been identified:

• Role-Based Access Control (RBAC): a fundamental mechanism that ensures only authorised users or systems can access specific data. It enforces access rules based on predefined roles and responsibilities.
• Blockchain for Security and Traceability: provides tamper-proof, decentralised ledger capabilities to enhance trust and security in data transactions.
• Data Quality Management: Ensuring high-quality data is critical for the effectiveness of DTs. Poor-quality data can lead to flawed decision-making and loss of stakeholder trust.
• Privacy Preserving Mechanisms: FDTs often handle sensitive personal or operational data, making privacy a top priority.
• Interoperability and Standardisation: For a federated system to function effectively, it must facilitate data exchange among DTs, each potentially operating on different standards and formats.
• Data Encryption: ensures that data remains secure during transmission and storage.
• Data Life Cycle Management: Governance policies should address how data is created, shared, stored, archived, and ultimately deleted.
• Monitoring and Auditing: Continuous monitoring ensures the platform remains compliant and secure.
• Stakeholder Engagement and Training: The success of data governance relies on informed and engaged stakeholders.

By addressing these governance components in detail, the FDT platform will establish itself as a secure, transparent, and efficient data ecosystem, driving the successful implementation of smart city initiatives. The following tools in Table 4 have been identified for potential use for implementing Governance functions:

5.1. Governance Recommendations

• Data Sovereignty Compliance: Ensure all governance policies align with UK-specific regulations on data sovereignty and public sector data sharing.
• Regular Review and Updates: Establish a governance review cycle to adapt to emerging technologies, regulations, and city needs.
• Transparency with Citizens: Develop public-facing documentation to explain how data is collected, used, and protected, fostering trust in the system.

5.2. Role-Based Access Levels for the FDT Platform

As identified above, Role-Based Access Control (RBAC) is essential for assuring security data privacy on the FDT platform. Seven Roles and their requirements have been identified for a Smart City FDT Platform, as shown in Table 5. Each role is designed to ensure operational efficiency, data integrity, and compliance with governance policies while fostering collaboration among public and private sectors, academic institutions, and the public.

6. Interoperability for Digital Twins

When data is exchanged between systems it is necessary that the receiving system can interpret the data it has received for those systems to be interoperable. Interoperability of DTs has been identified as a key challenge in smart cities and healthcare frameworks [36]. Interoperability, according to the Oxford Dictionary of Computer Science 7th Edition, is “The ability of systems to exchange and make use of information in a straightforward and useful way; this is enhanced by the use of standards in communication and data format.” As data are heterogeneous in sources, attributes, formats, and protocols, it is necessary to standardise communication and formats to ensure interoperability between DT components [37].

[38] used the Level of Conceptual Interoperability Model (LCIM) to quantify the degree to which systems are interoperable (Table 1). It is a scale that runs from no interoperation, up to complete awareness of other systems. The LCIM is a ladder in that the higher levels cannot be obtained unless the lower levels have been reached first. The level of desired interoperability implies what information is required to by the digital twins. In the Applications Layer for IoT, the protocols listed carry the formats from the Perception layer. Together these allow reaching Level 2 (Syntactic) of LCIM, as the data is exchanged in known formats, but the meaning of the data (i.e., semantics) is not. An example of achieving Level 3 (Semantic) is the OPC-UA standard (an interoperability framework). This standard defines “domain-specific information models” for more than 60 types of industrial equipment, These models standardise the types of information that each equipment type can provide. They are defined by committees and therefore take time to develop and, as stated before, are domain-specific. However, this is a solution to reach semantic interoperability.

Table 1. The Level of Conceptual Interoperability Model (LCIM) Levels (Adapted from [39]).

Level	Type	Description	Common Premise
6	Conceptual	Interoperating systems at this level are completely aware of each others information, processes, contexts, and modeling assumptions.	conceptual model
5	Dynamic	Interoperating systems are able to re-orient information production and consumption based on understood changes to meaning, due to changing context as time increases.	execution model
4	Pragmatic	Interoperating systems will be aware of the context (system states and processes) and meaning of information being exchanged.	workflow model
3	Semantic	Interoperating systems are exchanging a set of terms that they can semantically parse.	reference model
2	Syntactic	Have an agreed protocol to exchange the right forms of data in the right order, but the meaning of data elements is not established.	data structure
1	Technical	Have technical connection(s) and can exchange data between systems	communication protocol
0	None	N/A	N/A

Table 1. The Level of Conceptual Interoperability Model (LCIM) Levels (Adapted from [39]).

Level	Type	Description	Common Premise
6	Conceptual	Interoperating systems at this level are completely aware of each others information, processes, contexts, and modeling assumptions.	conceptual model
5	Dynamic	Interoperating systems are able to re-orient information production and consumption based on understood changes to meaning, due to changing context as time increases.	execution model
4	Pragmatic	Interoperating systems will be aware of the context (system states and processes) and meaning of information being exchanged.	workflow model
3	Semantic	Interoperating systems are exchanging a set of terms that they can semantically parse.	reference model
2	Syntactic	Have an agreed protocol to exchange the right forms of data in the right order, but the meaning of data elements is not established.	data structure
1	Technical	Have technical connection(s) and can exchange data between systems	communication protocol
0	None	N/A	N/A

Manufacturing is the most advanced domain in terms of Digital Twin ISO standardisation with ISO 23247-1:2021, however it is in the early stages of adoption and not all frameworks in that domain implement all the functionalities mandated in the standard [40]. As there is not the same degree of standardisation in other domains, and as there are a wide variety of possible domains, this promotes investigation into possible general solutions. This leads to some questions:

• What level of interoperability do we require?
• What information on the data from a DT (i.e., metadata) do we require for the required level?
• Does that metadata need to be in the data exchange format for discoverability?

For data from one digital twin to be usable by another, it is necessary to reach at least Level 3 (Semantic) of the LCIM ladder. The aim is therefore to achieve semantic interoperability as a minimum.

6.1. OASC MIMs

Open Agile Smart Cities (OASC)3 is a global network of cities and communities that supports the digital transformation of local administration. It includes the UK’s Connected Places Catapult as a partner. The OASC MIMs 2024 (Minimal Interoperability Mechanisms) framework, focuses on developing a “minimal but sufficient level of interoperability for data, systems, and services specifically in the context of smart city solutions.” The MIMs framework has 10 (incomplete) levels with suggested “mechanisms” to achieve those levels. Of interest here are MIM1—Context Information, MIM2—Data Models, and MIM7—Places).

ETSI NGSI-LD, SensorThings API and LDES (Linked Data Event Streams) were suggested as mechanisms to fulfil the requirements in MIM1. The suggested mechanisms for satisfying the requirements in MIM2 (other than where referencing another MIM), is to use those from standard data models. The list given is intended to be updated, but currently includes the ISO 5087 series of standards for the City Data Model; NGSI-LD compliant data models; oneM2M base ontology (SAREF-compatible); Core vocabularies of ISA2/Interoperable Europe based on Single Digital Gateway Regulation; DTDL based on JSON-LD; and spatial/spatio-temporal data based on MIM7 recommendations. The first MIM7 requirement is to expose Geospatial data through a standards-based web service. The second is for sharing geospatial data an interoperable way using the open standards for data encoding (GeoJSON, GML, GeoPackage, City GML and CityJSON) and the OGC API and OGC SensorThings API for access (MIM7—Places | OASC MIMs 2024, n.d.).

To summarise, the MIMs emphasise the use of open standardised formats and semantic descriptions for machine interoperability; and making the data accessible through web-based APIs. The data exchange formats and architecture, should be aligned with the OASC MIMs, as these will enable interoperability.

6.2. Semantic Interoperability

Different data sources will have different data formats and even those with the same function, e.g., temperature monitoring, may report that data in different ways (e.g., Fahrenheit or Celsius, XML or JSON). For these data to be usable by applications, this heterogeneity has to be overcome. Hence, a common understanding of the data is imperative, thus enabling semantic interoperability. There is a range of semantic interoperability solutions that could be used for data from smart cities. [41] list 64 semantic interoperability solutions.

It is essential for semantic interoperability that the data is labelled with metadata, which is of a standardised type, using a common controlled vocabulary of standardised terms. The data and metadata must also be structured in a standardised way called using structural rules called a schema. For example, the Open Geospatial Consortium (OGC) ESPRESSO project4 aimed to develop “shared semantics and vocabularies” as part of their conceptual Smart City Information Framework. This framework will use CityGML as a reference data model, which was commonly used in the international smart city use cases previously examined.

One of the key enabling technologies for achieving semantic and higher interoperability is ontologies. To use the definition of [41]: Ontologies “are collections of computer-readable term definitions of domain or application-specific knowledge, specifying sets of instances/data (concepts/classes), their properties, and binary relationships between them. They are used to obtain and explicitly represent not only domain, but also- and cross-domain knowledge”. The ontology specifies the structure of knowledge relationships (meanings) in a formal way [42]. This is different to a vocabulary that only specifies allowable terms and not the relations between them, and schemas that specify the data structure/format. A taxonomy is a hierarchical classification that specifies “is a” or parent-child relationships, e.g., thermometer is a sensor. Its semantic structure is less rich than a full ontology, which can include relations such as “part of”, etc.

Knowledge graphs represent the actual data and its relationships in an ontology. Hence, appropriate ontologies enable LCIM Levels 4-6. OGC also specifies a number of ontologies that could be used in a smart city data exchange framework, including those for sensor network measurements. There are multiple ways in which knowledge representations, such as knowledge graphs can be applied in DTs (see Figure 2). Knowledge Representations (KR) in Figure 2 can be specialised locally to layers or across layers (multi-layer).

As [41] stated, there are a wide range of ontological models that apply to cities, covering City infrastructure (roads, etc.); Environmental Data (weather, air quality, etc.); Social and economic data (demographics, economic indicators, etc.); Services and resources (availability of health, education, energy and water, etc.); Events and incidents (festivals, traffic accidents, etc.); Buildings and Spaces (floor plans, capacities, etc); City Government (organisation, officials, policies); Real-time data (traffic, public transit schedules, etc.). They point out that there are a variety of relevant existing ontologies that are unstandardised and may have gaps in coverage and overlap with others (many will have models for sensors and devices). They suggest aligning ontologies used to minimize overlap allowing for “more efficient data sharing and integration between different systems…”.

6.2.1. Semantic Annotation

This is the process of adding semantic metadata to data resources (archival or streaming). According to [41] most semantic annotation methods focus on mapping sensor information to an established ontology using a specific mapping language. The added annotations are machine readable, enabling systems to comprehend what the data is from the supplied metadata.

6.2.2. Semantic Queries and Reasoning

To fully utilise the data being collected in a Smart City it is important to be able to query and reason over all the data in the city model. This enables decision and policy making informed by all the available sources. For example, Knowledge Graphs in RDF format is queried using SPARQL (or derivatives such as GeoSPARQL for geospatial data in RDF). W3C list 32 reasoners for OWL, an open-source example is Apache Jena5.

6.2.3. Limitations of Ontologies for Smart Cities

Many of the limitations of using and maintaining ontologies described by [41], can be mitigated through using open standard ontologies where available, as listed in Table 7. These ontologies need to be sufficiently extensible that when new concepts need to be added to the ontology, they can be.

7. Approaches to Semantic Interoperability

As stated by [41]: “An important issue that remains unresolved in the development of Internet of Everything (IoE)-enabled smart cities, is how to facilitate a common understanding of data and messages exchanged between entities described by different ontologies in order to establish semantic interoperability. To the best of our knowledge, today there is a lack of well-established frameworks that focus on the automated semantic translation of data and communication messages, mostly based on effective ontological alignments, despite the fact that this issue has been raised for many years” They point out there are currently 2 main approaches to semantic interoperability using ontologies by smart city platforms:

i)

reusing standard ontologies, e.g., SOSA/SSN6 for sensor networks and actuators

ii)

defining their own monolithic smart-city ontology, e.g., STAR-CITY, CityPulse.

Another important consideration is the maturity level of the proposed solution.

7.1. Semantic Technologies Useful in the Smart City Context

7.1.1. JSON

IEEE 2888.1-2024 [44] specifies JSON as the syntax for data exchange. This standard defines the vocabulary, data formats and APIs for communicating with sensors. The schema provides the JSON syntax for specifying (“interfacing”) sensor data, for brevity it will not be reproduced here. In addition to the root schema, there are schemas for numerous sensor types, some of which will have utility in the smart city domain. These include cameras, temperature, pressure, humidity, wind, gas (that could be used for air quality), GPS, and generic cases. The same standard also specifies a JSON format for describing (“recognizing”) sensor capabilities. This is intended to enable interoperability by describing a sensor’s capabilities. So, the “interfacing” and “recognizing” formats are used together to provide the relevant semantic information and context to understand the sensor measurements.

7.1.2. RDF

Resource Description Framework (RDF) is a W3C standard7 for representing and exchanging relational data on the Web. RDF is based on semantic triples of the type subject-predicate-object. RDF triples encode relationships, such as Sensor 1-measures-temperature. The RDFS (S for Schema) extension is used for describing ontologies and written in XML. RDF can then be used to represent data according to the schema. OWL the Web Ontology Language extends RDFS with additional features. SPARQL is a semantic query language to query RDF databases. It is a semantic query language based on querying the graph structure of RDF. There is also C-SPARQL or Continuous-SPARQL designed to query streams of RDF data. OWL and RDF are the most common formats for storing data in knowledge graphs for DTs, according to the systematic review of [43].

7.1.3. Linked Data

Linked Data is data available on the Web that uses typed links to connect data from different sources (Bizer, Heath and Berners-Lee, n.d.). Linked Data uses the Resource Description Format (RDF) to make typed statements about the world. Linked Data uses HTTP URIs (Universal Resource Identifiers) as names for things and RDF/SPARQL to return information. The links create a “Web of Data”. If this data is accessible openly on the web, then it is called Linked Open Data (LOD). Related technologies are Linked Open Vocabularies (LOD)8, which encourages reuse of vocabularies (many of which are ontologies), and Linked Open Reasoning (LOR), to make rule-based inferences on LOD. An application of this is in the sensor domain [45].

7.1.4. JSON-LD

JSON-LD extends JSON to the Linked Data context9. It is designed to be lightweight and help JSON data interoperate on the Web. There can be ambiguity in the meaning of JSON property names from different sources, e.g., “measurement”: 30 could mean a temperature of 30 degrees or windspeed of 30 mph. JSON-LD solves this problem by introducing contexts using an “@Context” property whose value is a URL that points to a document that provides the context of the field names. The context also allows developers to use short property names, as these are disambiguated by the context. JSON-LD also introduces the property “@id” whose value is a URI and hence is a unique identifier for the entity. This allows entities with the same short names, e.g., “Sensor 1” to be disambiguated through their @id, which is unique. Another key property is “@Type” which gives the entity a type, e.g., “Bus”. There are other useful features of JSON-LD for semantic annotation, but these are the key features. JSON-LD is also convertible to RDF.

7.1.5. GeoJSON

GeoJSON is an open format for encoding collections of simple geographical features, using JSON [46]. The geometry types expressible in GeoJSON are: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection. GeoJSON uses the WGS84 datum, which is the same as the GPS satellite navigation system.

7.1.6. CityGML

A key element of a digital twin of a city is the 3D city modelling. The Open Geospatial Consortium’s (OGC) CityGML is the most established data format and semantic information model for the representation of 3D urban objects [37]. It was used by all the international DT case studies (listed in Table 1 in Section 2.1). CityGML 3.0 has improved integration with Building Information Modelling (BIM), including support for dynamic data from sensors and simulations. OGC City Geography Markup Language (CityGML) Part 2: GML Encoding Standard, details the XML-based encoding scheme for data exchange. CityGML is not an ontology, but there are ontologies based on CityGML, such as CityOWL. Interestingly this was generated automatically from the UML description of CityGML [47].

CityJSON is another OGC standard that is a lighter weight encoding of CityGML 3.0 and was designed to be easier to use, specifically in the development of the APIs. According to the standard, using JSON instead of the XML-based GML compresses files by a factor of 6 and simplifies their structure. Hence, there is a significant benefit to using CityJSON assuming the little-used features from CityGML that were not included are not needed. These 2 formats are the most established data formats for 3D city models [37].

7.1.7. Other OGC Standards

Other than the CityGML based formats and standards, certain OGC formats could be useful in the Smart City DTs. These including the SOSA/SSN ontology for sensor networks, e.g., for air quality measurements and the following web services and APIs listed in Table 8:

7.1.8. Smart Data Models10

FIWARE Foundation, IUDX, TM Forum and OASC are collaborating to encourage the adoption of common data models across multiple domains, including smart cities. These models have a schema that defines the format of NGSIv2 or NGSI-LD payloads.

7.1.9. DTDL

Microsoft uses the (open) Digital Twin Definition Language (DTDL) across its Azure platform for IoT and DTs11. They have committed with Siemens to unify DTDL with the “IOT, Thing Description” standard. DTDL is a language for describing models and interfaces for IoT DTs and is used to create ontologies for DTs. DTDL supports complex interlinking of resources and semantic annotation [48]. A Smart Cities Ontology for Digital Twins, was adapted by Microsoft in collaboration with Open Agile Smart Cities (OASC) from the NGSI-LD encoding of smart city open models from Smart Data Models. There is also a separate DTDL based ontology for Smart Buildings.

7.1.10. Smart City Ontologies

A systematic review of ontologies relevant to smart cities is given in [53]. These include ontologies specifically for urban planning, public administration, economics, energy, sensors, traffic, environments, security and privacy, risk management, health, social systems, crisis management. This illustrated the large range of ontologies available. Focusing here on smart city specific, ontologies. ETSI, the European Telecommunications Standards Institute, has published an ontology for Smart cities that is a European Standard: SAREF4CITY (Figure 3), which is an extension to the SAREF reference ontology for IoT [49].

Km4City, another city ontology, was developed to interconnect Florence and the Tuscany region. It operates over 9 domains: Administration; Street Guide; Points-of-Interest; Local Public Transport; Sensors; Temporal; and Metadata. However, Km4City was not produced by a standards organisation. SAREF and Km4City both apply the ontology reuse strategy to some degree. Standards-based sub-ontologies are listed in Table 2.

Table 2. Standards-based sub-ontologies reused by smart city ontologies.

Ontology	Description	Integrated Ontology
oneM2M ontology	Ontology for IoT and machine to machine interoperability.	SAREF
W3C SKOS ontology	Represents knowledge organisation systems.	SAREF
OGC and W3C SOSA/SSN ontology	Describes sensors and their observations.	SAREF, Km4City
OGC and W3C Time ontology	Describes temporal concepts.	SAREF
OGC GeoSPARQL vocabulary	Ontology for geographic information representation	SAREF, Km4City

Table 2. Standards-based sub-ontologies reused by smart city ontologies.

Ontology	Description	Integrated Ontology
oneM2M ontology	Ontology for IoT and machine to machine interoperability.	SAREF
W3C SKOS ontology	Represents knowledge organisation systems.	SAREF
OGC and W3C SOSA/SSN ontology	Describes sensors and their observations.	SAREF, Km4City
OGC and W3C Time ontology	Describes temporal concepts.	SAREF
OGC GeoSPARQL vocabulary	Ontology for geographic information representation	SAREF, Km4City

7.1.11. Next Generation Service Interface-Linked Data (NGSI-LD)

In a separate stream to the SAREF ontology development, ETSI have also developed NGSI-LD, which is a REST based API ecosystem for accessing context data, as demonstrated in Figure 4. The NGSI-LD cross-domain informational model, that can be mapped to the SAREF ontology. NGSI-LD standardises the property graphs data model and provides a standardised API. ETSI suggests an architecture for an NGSI-based smart city platform that makes explicit the need for semantic functions and is based around the NGSI-LD Context Broker and the NGSI-LD API. The broker through the NGSI-LD API returns NGSI-LD Entity information to consumers. Entities are the information representative of something in the real world (e.g., a bus). NGSI-LD can be serialised using JSON-LD.

Annex A of (GR CIM 020—V1.1.1—Context Information Management (CIM); NGSI-LD; Guidelines for the deployment of Smart City and Communities data platforms, n.d.) provides advice on using NGSI-LD data in a CityGML-based 3D environment. It is explicitly not mapping NGSI-LD attributes to CityGML objects or vice versa. NGSI-LD. NGSI-LD supports all the GeoJSON geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection in the information model. NGSI-LD is incompatible with common GIS systems such as ArcGIS, OpenGIS, QGIS and Geoserver. However, connectors to the NGSI-LD context broker have been developed.

SAREF ontologies can be mapped to the NGSI-LD data model and then serialised for transport using JSON-LD. This provides a full solution for exchange of data representable in those ontologies. There are also relevant SAREF extensions (in addition to SAREF4CITY) including the SAREF4BLDG which is based on Industry Foundation Classes (IFC). IFC is standardised in ISO 16739:2013 Industry Foundation Classes (IFC) for data sharing in the construction and facilities management industries”. However, this solution does not cover the models of building structure and the generally accepted standard for this is CityGML.

8. DIATOMIC Digital Twin Use Cases

As a step towards an FDT implementation, an open standard digital twin platform has been developed within 2023-2025 UKRI West Midlands Innovation Accelerator project Diatomic (Digital InnovAtion TransfOrMatIve Change) UK Accelerator (App no:10055175 PCR number: 52454). There are five Digital Twin Use cases developed by Connected Places Catapult partners: Aston University, Birmingham City University, the University of Birmingham in the United Kingdom and the University of Ulsan in South Korea. The regional FDT model focused on Birmingham Smart City concept, integrates these DTs using the Diatomic-Azure Digital Twin platform which is a sandbox for generic DT development. These DTs operate independently but collectively contribute to a federated system, enabling data sharing, insights generation, and informed decision-making across the network. Figure 5 presents a hexagonal architecture, a software architectural design pattern which aims at loosely-coupled interchangeable components. Adaptors provide interoperability between components. This is the current DIATOMIC-Azure architecture of the FDT Platform for Birmingham Smart City. Three layers have been demonstrated as Domain Model, Domain Services and API & Admin Services. Connections are possible using four sets of APIs including Functional APIs, Event & UI APIs, Admin APIs, and Data APIs.

The DTs have heterogeneous data inputs, involving sensor data, LiDAR point clouds, camera imagery and geographical information. There are significant commonalities across the use cases. Table 10 includes descriptions of the DT use cases with mappings to the nine common elements identified in this project. These common elements called “building blocks” are listed below:

3D Visualisation Asset Management Predictive Analytics Artificial Intelligence Machine Learning

6. Authorisation Methods 7. Access Control 8. API 9. Sensors

9. System Architecture for a Federated Data Exchange Platform in Smart Cities

This section presents the potential system architectures for the FDT Data Exchange Platform that can be used in a Smart City. The development of an FDT data exchange platform for Birmingham City, as an example, involves integrating three existing DTs, developed by Aston University, the University of Birmingham, and Birmingham City University using Diatomic-Azure platform, with scalability to accommodate future reginal and international use cases. The architectures are designed to ensure interoperability, scalability, and security in real-time data exchange to improve urban management and decision-making for future DTs. By employing a range of microservices in the proposed architectures, the platform aims to ensure modularity, scalability, and flexibility, making it easier to manage, update, and extend the platform to accommodate future DTs and evolving city needs.

9.1. Layered Federated Digital Twin Architecture

The layered FDT architecture in Figure 6 is similar to the layered IoT architecture in Table. This is as expected as the FDT architecture is built on top of IoT. The layered architectural model, NEXUS (Networked Exchange of Unified Systems) [55] comprises the following layers:

• Data sources and physical system layer,
• Middleware and Integration Layer,
• Data Layer,
• Enablement Layer,
• DT Layer,
• Federation Layer, and
• Application Layer.

These layers have been described in Table 11.

9.2. Composable Federated Digital Twin Architecture

The Composable Architecture in Figure 7 is essentially a microservices-driven framework with self-contained components that have clear functionalities. Specifically, individual services or “building blocks” operate independently but interoperate through APIs. The same features are present as in the layered architecture, but there is increased flexibility in their communication, compared to the layered design.

9.3. Comparison of Architectures

Table 12 provides a comparative list to evaluate proposed system architectures [56,57]. The Layered architecture may use services/microservices within layers, but layers have distinct responsibilities, i.e., the separation of concerns is by layer. The composable architecture has a significant benefit in that it is highly flexible and customisable and scalable by design. This comes at the cost of increased issues around security and governance of interfaces. There are approaches including Zero Trust Architecture (ZTA) to mitigate these issues, but further work is needed to ensure a secure design such as with a distributed ledger technology. By requiring authentication for every request, ZTA minimizes the risk of data breaches, even if a user or device within the network is compromised. The assumption of “breach” ensures no implicit trust is given, limiting attackers’ lateral movement.

9.4. Implementation of a Federated Digital Twin Platform

The layered architecture in Figure 6 with some composability of services within layers has been developed using the Siemens IoT and Digital Twin products to build the Diatomic-Azure Data Exchange platform. Table 13 lists the Siemens products that can be used in each architectural layer that may allow interoperability between DTs.

Extensive use of a single vendor’s components can facilitate interoperability between the components, but can lead to vendor lock-in if proprietary protocols are used, especially between layers. This makes it more difficult to change components, which can result in pricing vulnerability and increased switching costs. Vendor lock-in can lead to a reliance on the vendor to implement new features, which ties development to their roadmap. The reduction in flexibility to be able to change modules, can limit the ability to use best in class technologies if they are not provided by the vendor. Therefore, there is a need to explore other solutions.

Figure 6 demonstrates the system architecture of the Diatomic Azure DT development platform with a subset of Azure building blocks used by the DTs developed by the Birmingham universities. The Azure Building Blocks is a command line tool and set of Azure Resource Manager templates designed to simplify deployment of Azure resources. Authoring a set of simplified parameters to specify settings for Azure resources, the command line tool merges these parameters with best practice defaults to produce a set of final parameter files that can be deployed with the Azure Resource Manager templates. Azure building blocks include fundamental components forming a hierarchy for governance, billing, and access control, enable scalable and secure cloud solutions. Data is shared with arrange of users using an Open Data Platform Client and platform users using a Single Pane Glass UI Framework as the interface.

Figure 6. The system architecture of the Diatomic Azure DT development platform with building blocks.

Figure 6. The system architecture of the Diatomic Azure DT development platform with building blocks.

Architectural Considerations for Semantic Interoperability

The proposed architecture’s translation services are responsible for interoperability. An approach taken by South Korea’s City Data Hub uses NGSI-LD as a common data model for its internal data representation [54] demonstrated in Figure 8.

The advantage of using NGSI-LD as a common data model is that it is not necessary to be able to directly convert from every format into every other format. It is only necessary to have convertors for each format to, and from, the common data model. The common data model is then used for processes internally to the smart city platform. In the City Data Hub, adaptors to NGSI-LD in the Data Ingest Module, convert between standardised APIs and NGSI-LD. The City Data Hub separates the common data model in NGSI-LD from the semantic data (reflecting the smart city ontology) encoded in RDF in the Semantics module. This represents a separation of format translation (syntactic) and semantic annotation (which is only applied to LOD). As Birmingham is twinned with Ulsan in South Korea, which is part of the Korean Smart City Network12, there may be opportunities for learning from those cities’ experiences using NGSI-LD and smart city ontologies. As stated previously NGSI-LD data model is capable of representing the SAREF-based ontologies, hence using the NGSI-LD API would fulfil the requirements for a semantic interoperability service. FIWARE maintain an open source NGSI-LD API solution13.

10. Conclusion

In this paper, we have investigated the topic of federated data exchange in a smart city context and how interoperability among the use cases of DTs can be achieved. We are identified nine common elements as “building blocks” in the regional DTs, currently implemented in the Diatomic Azure DT Platform in West Midlands. These are 3D Visualisation, Asset Management, Predictive Analytics, Artificial Intelligence, Machine Learning, Authorisation Methods, Access Control, API, and Sensors. The building blocks identified have been further validated with use cases of 8 SMEs working on the development of a range of DTs. We also proposed a system architecture for federated data exchange, including layered and composable FDT approaches. Our recommendations for Federated Data Exchange are listed in Table 14.

Data exchange in the context of Digital Twins has a number of challenges. Chief among these challenges is how to ensure that the data is understandable by machines (not just processable). There is an understanding in the community that using open standards as much as possible to facilitate interoperability and avoid duplication of effort. However, outside of the manufacturing domain, the ISO standardisation process is embryonic. It is therefore important to use other international standards, such as the European-region ETSI where available, until ISO standards are available. NGSI-LD and related semantic technologies such as DTDL, seem to be emerging as standards, especially in the smart city domain. There is a multiplicity of open ontologies useful for smart cities, including those for sensors, environmental, traffic, governance, etc. These can be reused as part of a semantic interoperability solution.

The SAREF ontologies maintained by ETSI may be preferred, as they are maintained by an EU-supported standards organisation and are therefore a de facto European standard and interoperable with NGSI-LD. FIWARE, who maintain the implementation of NGSI-LD and smart data models, claim more than 400 cities use their solutions [51]. This likely makes their use a de facto smart cities standard and should be considered for the semantic interoperability components of a Smart City Digital Twin.

The composable architecture provides the greatest flexibility for future development of the FDT Data Exchange Platform. There is a need for a semantic service to broker the data exchange, such as NGSI-LD, that serves data according to a common format with common understanding. Where necessary, connectors can be used to translate into other formats such as for display in the application layer. Using JSON-based formats as far as possible for data transmission, allows the data to be human and machine readable with various levels of formal semantics applied, e.g., based on an ontology or a schema (as required). JSON has the advantage of a data-focus, as opposed to XML’s document focus.

We plan to continue the project by investigating pros and cons of various vendor solutions for federated data exchange in DTs, and explore the uptake of the current Diatomic-Azure DT platform by SMEs in West Midlands to develop a smart city eco-system.