# MIM8: Local Digital Twins 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** (with human supervision)**.** | Category of LDT | Visualisation | Simulation | Analytics\* | Autonomous | | --------------- | ------------- | ---------- | ----------- | ---------- | | 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 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). 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, 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. 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. ## Objective Enables Local Digital Twins (LDTs) to **orchestrate** workflows, data, models and visualisations across systems, domains, and communities. It ensures that LDTs move beyond isolated, project-specific implementations toward federated, reusable, and scalable ecosystems, ensuring: * Cross-domain decision support (e.g. climate, mobility, urban planning) * Reuse of models, datasets, and simulation outputs across communities and use cases * Participation of multiple stakeholders (public, private, citizens) * Progressive maturity from standalone LDTs to interconnected virtual worlds environments (note, virtual worlds environments is not addressed by MIM8.) In doing so, this MIM leverages on all [MIMs](https://oasc.gitbook.io/mims-specification-8) (0,1,2,6,3,4,7,5) and provides guidance for interoperable orchestration measures. 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., Geo 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.* ## Capabilities and Requirements | C1: Provide access to datasets used within the LDT, including static, real-time, and simulation data and calculation models. | | ---------------------------------------------------------------------------------------------------------------------------- | | see [MIM0](https://oasc.gitbook.io/mims-specification-8/mim0-accessing-data) | | C2: Exchange data with external systems and other LDTs using interoperable interfaces. | | --------------------------------------------------------------------------------------------- | | see MIM3 (add services, MIM3, only talks about data), MIM6 ( notify MIM6 about 'breakclass' ) | | C3: Reuse (deterministic or AI) models across different domains, communities, use cases, and/or LDTs. | | -------------------------------------------------------------------------------------------------------------------- | | R3.1: The model should have a description of its methods and data. | | R3.2: The model should have a known standardised API. | | R3.3: Trustworthy, reliable, and ethical (in turn minimised bias) use of innovative methods (LLMs, agentic AI, etc). | | R3.4: Data should be authoretative and authenticated. | | C4: Coordinate and manage data, models, and processing workflows within an LDT (intra-LDT) and across LDTs (inter-LDT). | | ----------------------------------------------------------------------------------------------------------------------- | | R4.1 | | C5: Provide multiple visualisation of data and results (e.g. 2D, 3D, dashboards) from common underlying data and models. | | ------------------------------------------------------------------------------------------------------------------------ | | R5.1 | | C6: Ensure that data exchanged (and simulation outputs) within and between LDTs can be interpreted consistently through shared or mapped semantics. | | --------------------------------------------------------------------------------------------------------------------------------------------------- | | see[ MIM2](https://oasc.gitbook.io/mims-specification-8/mim2-representing-data) add request for 'ecosystems' (refer beyond ISO2700) | | | | ---------------------------------------------------------------------------------------------------------------------------------------- | | 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 | ## Mechanisms | LDT resource catalogue | A catalogue or registry that enables discovery of LDT resources, including datasets, models, services, workflows, outputs and visualisation layers. | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | distinguish between |

  • data resources;
  • model and service resources;
  • workflow or scenario templates;
  • visualisation assets;
  • published outputs.
| | implementations | DCAT, DCAT-AP, DCAT-NL, CKAN, OGC API Records, CSW or platform-native catalogues. | ## Specifications ## Compliance and Conformance ## Interoperability Guidance --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mims.oascities.org/local-digital-twins/mim8-local-digital-twins.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.