LDT Interoperability Blueprint

Living Document,

This version:
https://spec.knows.idlab.ugent.be/ldt-interoperability-blueprint/all/015966d2d02e53cb9f6862481178329013e93890
Previous Versions:
Issue Tracking:
GitHub
Editors:
(Ghent University - imec)
Sille Sepp (TalTech)
Laura Riou (Cerema)
Lucas Vieira Magalhães (LIST)
Thimo Thoeye (OASC)
Not Ready For Implementation

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

Before attempting to implement this spec, please contact the editors.


Abstract

To-do

1. Introduction

The Interoperability Blueprint provides business, organisational, and technical guidelines for building our own Local Digital Twin (LDT) and interconnecting with other LDTs. An LDT is a digital representation of physical assets, systems, or processes in a defined local context (for example, city, district, building, industry, port, and airport). LDTs are based on structured data models and contextualised data. They leverage either historical data, near real-time data, or real-time data, and they enable visualisation, analysis, simulation, and reasoning services that support decision-making. First, we will elaborate on why LDTs can be useful, followed by a high-level overview of an LDT. Next, we will explain the importance of being able to add new components to an LDT (Section 1.3) and discover existing components that can be added to an LDT (Section 1.4). Finally, we will discuss how this blueprint aligns with Minimum Interoperability Mechanisms (MIMs) Plus (Section 1.5) and how data spaces and LDTs are related (Section 1.6). The remainder of this deliverable is structured as follows:

Although this blueprint mainly guides us through the process of building a new LDT with the focus on interoperability, we can also use its recommendations for updating an existing LDT and interlinking LDTs. The scope of the blueprint isn’t to offer guidelines for every use case in which an LDT is being built or has been built, as every LDT operates in a very specific context.

1.1. Why use an LDT

An LDT is a virtual replica of a territory based on structured data models, real-time data feeds, and potentially 3D representations, which can integrate simulation models (flows, usage, impacts, and so on). It aims to dynamically represent the territory at various spatial and temporal scales to analyse, understand, anticipate, and simulate the effects of public policies, environmental hazards, climate change, development projects or disruptions. The digital twin supports strategic decision-making, consultation, foresight, and scenario design. It can even include automated decision-making and execution. It can incorporate historical datasets, time-delayed data, Building Information Modelling (BIM), Geographic Information Systems (GIS), and/or specific models (mobility, climate, energy, and so on). LDTs can offer the following capabilities to users:

Note that we do not derive this definition of an LDT from a formal international standard. Instead, it is a project-specific conceptualisation influenced by existing frameworks such as Digital Twins, the EU LDT Toolbox, MIMs Plus 8 on Local Digital Twins, Smart City models, and Data Spaces. While relevant standards (for example, ISO 23247, ISO/IEC 30182, and ISO 30173) provide partial guidance, there is currently no universally accepted standard definition for LDTs in the context of urban or territorial systems.

1.2. High-level overview of an LDT

TO-DO
Test

1.3. Adding a new Surface-level component to an existing LDT

TO-DO
Test

1.4. Discovering which Surface-level components work on which existing LDTs

TO-DO
Test

1.5. Alignment with MIMs Plus

TO-DO
Test

1.6. Relationship between data spaces and LDTs

2. LDT building blocks based on DSSC & DS4SSCC-DEP building blocks

2.1. Business and organisational building blocks

TO-DO
Test

2.2. Technical building blocks

TO-DO
Test

3. Workflows

3.1. Adding a new Surface-level component to an existing LDT

3.2. Discovering which Surface-level components work on an existing LDT

4. Reference architectures

4.1. Business and organisational architecture

4.2. Technical architecture

TO-DO
Test

4.2.1. Support different data models

TO-DO
Test

4.2.2. Support different data exchange types

TO-DO
Test

4.2.3. Support for the usage of data from different LDTs

TO-DO
Test

4.2.4. Support for working with different AI models

TO-DO
Test

4.2.5. Standards and protocols

4.2.5.1. Artefacts
4.2.5.2. Interaction between components

5. Workflows using reference architectures

5.1. Adding a new Surface-level component to an existing LDT

5.2. Discovering which Surface-level components work on an existing LDT

6. How to build an LDT

6.1. Explore and validate

6.2. Define and implement

6.2.1. How to build a Data Acquisition component

6.2.2. How to build a Data Management component

6.2.3. How to build a Connectivity component

6.2.4. How to build Decision-Making components

6.2.5. How to build Analysis components

6.2.6. How to build Visualisations