MIM8: Local Digital Twins
This is the page describing OASC's MIM8 on Geospatial Data
Description
This MIM describes interoperability in terms of the application domain of Local Digital Twins. In support of describing minimal interoperability mechanisms in this domain the MIM8 working group put forward a minimal definition of Local (or Urban) Digital Twins. This does not preclude any other definitions to be valid, and we recognise that depending on applications features may vary.
A Local (or Urban) Digital Twin is a digital representation of physical assets, systems, or processes in a defined local context (e.g., city, district, building, industry, port, airport). It leverages either on historical data, near real-time data, or real-time data enables visualization, analysis, simulation and reasoning for supporting decision-making.
The working group understands the diversity of local digital twins depending on their functionalities. Below is a table of different functionalities of a Local (or Urban) Digital Twin can have and as such are commonly categorised as: Awareness LDT, Experimental LDT, Predictive LDT, and Intelligent LDT.
Awareness
X
Experimental
X
X
Predictive
X
X
X
Intelligent
X
X
X
X
*Analytics can include 'diagnostic', 'descriptive', 'predictive', and 'prescriptive' capabilities.
While we align with commonly agreed definitions (such as the one above), communities have expressed that simulations require more complex work process than analytics, and hence, experimental digital twins are viewed more complex as predictive LDTs.
We discern the following additional functionalities across the following layers:
Layer 1: Data acquisition (historic/near real-time/real-time data)
sensing
extraction
synthetic data generation
Layer 2: Connectivity
APIs
protocols
file sharing
Layer 3: Data pre-processing
semantics
interoperability
aggregation
Layer 4: Analysis & simulation
AI Models
Physics-based simulations
Layer 5: Communication of results (visualisation)
Dashboard
Multi-dimensional visualisation
natural language interface (like chatbot)
VR
Layer 6: Decision-making
prescription
support
automation
Literature
Deutsches Institut für Normung e. V. (2024). DIN SPEC 91607:2024-11 – Digitale Zwillinge für Städte und Kommunen [Digital twins for cities and municipalities]. DIN e. V https://dx.doi.org/10.31030/3575521
Gil, J., Petrova-Antonova, D., & Kemp, G. J. (2024). Redefining urban digital twins for the federated data spaces ecosystem: A perspective. Environment and Planning B: Urban Analytics and City Science, 0(0). https://doi.org/10.1177/23998083241302578
European Commission: Directorate-General for Communications Networks, Content and Technology, Robalo Correia, A., Sousa, M., Mulquin, M., Santos, F. et al., Mapping EU-based LDT providers and users, European Commission, 2023, https://data.europa.eu/doi/10.2759/547098
European Telecommunications Standards Institute. (2022). ETSI GR CIM 017 V1.1.1 (2022-12) – Context Information Management (CIM); Feasibility of NGSI-LD for Digital Twins [Group Report]. ETSI. https://cdn.standards.iteh.ai/samples/59463/1f99a12b505b412d85a19ebfa4d4d451/ETSI-GR-CIM-017-V1.1.1-2022-12-.pdf
Tartia, J., & Hämäläinen, M. (2024). Co-creation processes and urban digital twins in sustainable and smart urban district development – Case Kera district in Espoo, Finland. Open Research Europe, 4, 130. https://doi.org/10.12688/openreseurope.17791.1
Objective
Information received:
Lack of data models and data standards at data providers side, which requires additional effort for data management. Data silos and missing availability of APIs for data exchange at municipal level (legacy systems and siloed infrastructures in the municipality are often not designed to interoperate). Different standards used by distinct communities in principal. For instance, the FIWARE community employs Smart Data Models, while the geospatial community relies on OGC standards like CityGML. Even small terminological differences (e.g., “roadwork” vs. “street maintenance”) can lead to integration failures or misinterpretation unless a common vocabulary or semantic mediator is applied. This disparity requires mapping these standards to ensure seamless data interoperability. AI models require high-quality, semantically rich, and consistent datasets. Integrating fragmented, incomplete, or inconsistent municipal data degrades AI performance and trustworthiness. Beyond technical aspects, challenges also arise in organisational and cultural domains, such as establishing common rules, governance frameworks, and fostering a culture of data sharing and innovation within public administrations. Deployment and maintaining interoperable systems — especially involving AI, semantic models, or real-time data — requires skilled personnel, often missing in public administration
Legal aspects in contracts for data sharing agreement
Common criteria to assess the required level of data quality
different datasets needed in different models are not interoperable
Comments 28.4.2025
system of system thoughts
Imperative to discuss interoperability in the context of LDT because we are faced with systems. It means federation of systems of systems - there is an architectural aspect.
On top of the systems of systems comes a modular architecture. so systems can feed data to the LDT
communication, scalability, integratability
minimal viable product in the end - what is the minimal architectural pattern? identify components to indentify respective interoperability - here refer to other MIMs
tied to what is the point of the LDT if there is no interoperability. it is tied to the core of an LDT
bottom-up: Information model to udnerstand how and when they use data. - requirement for information management to have LDT otherwise things are scattered and fragmented.
above bold items are requirements
Simpl
Comments 12.05.2025
catalysator of systems, helps multi-level governance, large systems to work coherently, everything should be compatible.
Comments 17.11.2025
Provide different blueprint for different twins and how they work together.
Creata an excel sheet to build a matrix of LDT capabilities crossed with existing MIM capabilities (on the drive) (maturity stages/ layers of interopearbility /capabilities)
What is missing?? From data it is only Dta plan and Control plan. The angle we need is for orchestration mechanism and later we can move towards coreography for agentic AI
1.12.2024
Continuing scope discussion:
look for concrete needs
Collect existing architectures and see how to scale solutions/services from one arch. to the other.
which standard can help procurements
Orchestration has 2 levels (internal and external connection) and across the maturity levels
inter-LDT and intro-LDT, the second one being about interoperability of components across different “layers” of the LDT architecture, most pressingly:
Connecting to different visualisations (GIS, 3D, …)
Introducing different predictive algorithmic models, e.g. get their parametrisation and input data sets right
Define Orchestration: ---— need for technicians.
Prague: 1. micro-climate use case, the model is already there. there are small pilots (workflow defined, no automation and dmove forward by removing obstacles) 2. energy, 3. mobility (transport) -
Parametrisation of predictive algorithms is a challenge
Valencia: ESRI tools - all data from urban platoform (based on FIWARE integrated on the GIS) and integrated in the DT. now information is shown from censors and portal in the twin. goal: add layer provided from the toolbox to have intelligent simulation & prediction based on the data available. -> adding intelligence to data.
orchestration definition/ coreography for combining functionalities
focus on the piece between the computational model and the data pieces!
different DTs within one city
for next time: Sophie describes the scope of the MIM and shares with the MIM8 mailing list
MIM8's scope re orchestration
MIM8 (LDT) positions orchestration as the capability to connect and coordinate LDT components (add capability instead of components) within an LDT (intra-LDT) and between LDTs (inter-LDT), progressively across maturity levels. Intra-LDT orchestration focuses on interoperability across architectural layers, most critically enabling the same scenario outputs to be consumed by different visualisations (e.g., GIS and 3D) and allowing different predictive/algorithmic models to be plugged in with clearly specified inputs, parameters, and outputs, including automated checks for schema/unit/space-time alignment. Inter-LDT orchestration covers controlled exchange and reuse of data/models/scenario results with other LDTs via standard interfaces, with governance hooks such as access control, provenance, and audit logging.
15.12.2025: Discussion re above
Definitions needed/shared language: schema, data, standards (what kind are we talking about)
Tracebility of data
model is AI model
data layer: deploying data model, parametrisation of data, how to connect/trace
visualisation:
describing exterior and interior environments (GIS vs BIM) how to connect those worlds? we need a model (indoor GML vs city GML) - should this be Citiverse because moving between environments
TO DO for next time:
create a matrix for each layer & their issues and map the existing MIMs against them.
Definition of orchestration: scenario interoperability?
@communities: do you compare your scenarios? :
Gotheburg: no modeling or analysis within the LDT for now. analysis/simulation is outside the LDT, instead they take the resutls and visualsie it. enhanced AI LDT conversations start now. -— How to exchange the data? Standards. Same for Scenarios.
existing (Harm), citizen involvement/engagement -— Orchestration - > Visualisation -> Simulation and Prediction and Time Travel for example for urban planning of Positive Energy District
Bieke: experience with slow data. scenario building is for the future. would orchestartion mean including less advanced cities? -— orchestration inter LDTs
Assign definition to orchestration:
Bieke: documentation & repetition of good solutions, pilots
LDT Toolbox: scenario building
LDT4SSC: include context management in the orchestration (e.g.: context broker) - put things in place in the right order. (define things)
Valencia: common use cases that could be replicable to cities. orchestration of services: in the context of DS its data & services.
Harm: combination of LDT's capabilities to analyse historic and future data, make it accessible for analysis, sharing, communication & about policy making (decision making) - how to include citizens.
Gotheburg: makign things work together (data, services, APIs, different layers).
add citizens/ impact for people/citizens.
the definition is too technical, include LDT results
missing word ' ecocystem' , and the market place/ economic measures/ regulations/policies.
Capabilities and Requirements
former C1: Composability of Components
former C2: Exchanging information between data ecosystems (e.g.: local digital twins, data spaces, etc) (Interchangeability of Data)
former C3: Scalability Local Digital Twins
former C4: Federation of Local Digital Twins (networked local digital twins: EDIC) - optional
former C4: Extensibility of LDT
C1: Share data
R1: Data can be exchanged across silos/sectors
R2: LDTs (also across sectors) can work together to inform a use case
R3:
C2: Share services
R1: Services can be exchanged across silos/sectors
R2: The LDT can be applied to other data ecosystems with minimal integration effort
C3: Share components
R1: Common components can serve multiple local digital twin instantiation
R2: The LDT is able to integrate new components across any of the layers, possibly from other LDTs from different sectors
R3: The components from Layers (2), 3, 4 and 5 can be applied to other data ecosystems from different silos/sectors
Comments 9.06
add visualisation of the architecture
flash out capabilities to be in line with description
problem from jumping form layer 2 to 6
for next year: priority is to functional elements
Mechanisms
Specifications
Compliance and Conformance
Interoperability Guidance
Last updated