Architecture and Implementation Plan for a Digital Twin of the MV2DC Demonstrator on the SEGuRo Platform

Abstract: This paper presents a comprehensive architecture and implementation plan for a digital twin (DT) of the MV2DC demonstrator, realized on the SEGuRo platform. The work begins by contextualising the MV2DC project and the necessity of a DT to enable fault simulation, protection‑scheme validation, what‑if analyses, and operator training. A review of related digital‑twin concepts, including hardware‑in‑the‑loop and model‑in‑the‑loop approaches, highlights the unique capabilities of SEGuRo for real‑time, modular simulation. From concrete use cases, functional requirements such as high fidelity, ease of use, snapshot recreation, and scenario management are derived. A high‑level architecture is then introduced, comprising a Model Library, Measurement Storage, Fidelity Watchdog, Dashboard, and Simulator integration, together with the notions of Snapshot, Scenario, and Scenario Set. Detailed component designs specify versioned model storage, time‑series archiving, continuous deviation detection with automatic re‑calibration, a user‑friendly web dashboard, and seamless OPAL‑RT coupling via SEGuRo wrappers. The mapping of these components onto SEGuRo’s services, middleware, and containerised execution environment is described, followed by a step‑by‑step prototype development workflow. Validation against recorded demonstrator data demonstrates acceptable latency, fidelity, and usability across the defined use cases. Open technical questions and future extensions - including automated scenario generation, AI‑based fault diagnosis, and collaborative multi‑user sessions - are outlined. The results confirm that the proposed architecture fulfills the MV2DC digital‑twin requirements and provides a viable pathway toward a production‑grade DT on SEGuRo.

1. Introduction

1.1 Project Overview

The Medium‑Voltage DC (MV2DC) Demonstrator is a research‑grade test‑bed that showcases the operation of a 1 kV DC distribution grid equipped with power electronic converters, modular protection devices, and a supervisory control‑and‑monitoring (SCADA) layer. The demonstrator is hosted at the SEGuRo (Secure Grid Operations) platform, which provides a modular, service‑oriented environment for real‑time simulation, hardware‑in‑the‑loop (HIL) testing, and data‑centric analytics.

The MV2DC project aims to:

• Validate novel control and protection concepts for medium‑voltage DC grids.
• Provide a reproducible experimental environment for academia and industry.
• Enable training of operators and engineers on realistic fault and “what‑if” scenarios.

To achieve these goals, a Digital Twin (DT) of the demonstrator is required - a high‑fidelity, real‑time replica that can be interrogated, re‑configured, and extended without interfering with the physical hardware.

1.2 Motivation for a Digital Twin

A DT offers three decisive benefits for the MV2DC program:

1. Testing & Validation - Fault injection, protection‑scheme verification, and controller tuning can be performed in a risk‑free virtual environment, dramatically reducing the need for costly physical re‑configurations.
2. Training & Education - Operators can practice response procedures on a realistic replica that mirrors the exact dynamics of the physical grid, including transient over‑voltages, converter saturation, and protection device latency.
3. Research & Innovation - Researchers can explore “what‑if” analyses (e.g., topology changes, renewable integration) and rapidly prototype AI‑based diagnostics, leveraging the same underlying models that drive the real demonstrator.

These capabilities align with the functional requirements identified later in Section 3. Use Cases and Functional Requirements, where fidelity, usability, and scenario management are highlighted as key drivers.

1.3 Scope and Contributions of This Work

The present publication focuses on the architecture and implementation plan for a DT that is native to the SEGuRo platform. The main contributions are:

• Systematic mapping of DT building blocks (model repository, measurement storage, fidelity monitoring, user dashboard, and real‑time simulator) onto SEGuRo’s modular services, as detailed in Section 6. Mapping the Architecture to SEGuRo.
• Definition of core concepts - Snapshot (a time‑stamped state of the grid), Scenario (a scripted sequence of events), and Scenario Set (a collection of related scenarios) - that enable reproducible experiments and automated testing, introduced in Section 4. System Architecture Overview.
• A step‑by‑step prototype roadmap, covering environment setup, model versioning, OPAL‑RT integration, dashboard creation, and fidelity watchdog implementation, outlined in Section 7. Prototype Development.
• Preliminary validation results that demonstrate acceptable latency and model fidelity for the identified use cases, summarized in Section 8. Validation and Results.

By anchoring the DT design to SEGuRo’s existing services (e.g., MQTT/ZeroMQ for data streams, Docker containers for isolated simulation instances), the work ensures scalability, maintainability, and interoperability with future extensions such as AI‑based fault diagnosis (see Section 10. Future Work and Extensions).

The remainder of this document elaborates on the background, requirements, architectural design, and validation of the MV2DC digital twin, establishing a solid foundation for a production‑grade implementation on the SEGuRo platform.

2. Background and Related Work

2.1 Digital‑Twin Concepts for Medium‑Voltage DC Grids

The notion of a digital twin (DT) - a high‑fidelity, real‑time replica of a physical asset - has become a cornerstone for modern power‑system research, especially for emerging medium‑voltage DC (MV‑DC) networks. In the MV2DC project the demonstrator is a 1 kV DC grid equipped with converters, protection devices, and a SCADA system (see 1. Introduction). Existing DT approaches for MV‑DC can be grouped into three families:

Across the literature, the key drivers for adopting a DT in MV‑DC contexts are:

1. Safety‑critical testing - enabling fault injection without risking the physical hardware.
2. Reproducibility - the ability to capture a Snapshot of the grid state and replay it under varied control strategies (the Snapshot concept is formalised in Section 4).
3. Operator training - providing a realistic, real‑time interface that mirrors the SCADA of the demonstrator (see 1. Introduction).

Recent case studies (e.g., the European “DC‑Grid‑Lab” and the US “Hybrid DC Test‑Bed”) demonstrate that a physics‑based DT integrated with a real‑time simulator (OPAL‑RT) can achieve latency below 1 ms while preserving switching‑level fidelity, which aligns with the performance targets outlined for the MV2DC DT.

2.2 Hardware‑in‑the‑Loop (HIL) and Model‑in‑the‑Loop (MIL) Approaches

The MV2DC DT leverages a hybrid HIL/MIL strategy: critical converters and protection devices are exercised in Power‑HIL mode to preserve switching dynamics, while the remainder of the grid (cables, loads, SCADA) is represented by MIL models. This split satisfies the fidelity requirements identified in 3. Use Cases and Functional Requirements (e.g., fault simulation and protection‑scheme validation) while keeping computational load manageable for the SEGuRo runtime.

Key lessons from prior HIL/MIL deployments that inform the present work include:

• Synchronization is paramount - deterministic time‑stamping (e.g., IEEE 1588 PTP) is required to keep the physical and simulated domains aligned, a capability already provided by SEGuRo’s middleware.
• Model version control - frequent updates to converter control software demand a versioned model repository (see 5. Component Design - Model Library).
• Latency budgeting - studies show that end‑to‑end latency must stay below 2 ms for accurate protection‑scheme testing; this target guides the design of the Fidelity Watchdog (Section 5).

2.3 The SEGuRo Platform: Capabilities and Prior Applications

SEGuRo (Secure Grid‑Ready) is a modular, service‑oriented platform originally conceived for real‑time operation of micro‑grids and has been extended to support MV‑DC demonstrators. Its salient features, relevant to the MV2DC DT, are:

1. Service‑Based Architecture - Core functionalities (e.g., data acquisition, model execution, user interface) are exposed as independent Docker‑containerised services, enabling flexible deployment and scaling (see 6. Mapping the Architecture to SEGuRo).
2. Real‑Time Execution Engine - A deterministic scheduler (based on POSIX‑RT and optional hardware‑assisted time‑bases) guarantees sub‑millisecond task execution, which is essential for HIL loops.
3. Communication Middleware - SEGuRo ships with both MQTT (lightweight publish/subscribe for telemetry) and ZeroMQ (high‑throughput binary streams for HIL data), allowing seamless integration of OPAL‑RT I/O adapters.
4. Data Management Services - Built‑in time‑series storage (InfluxDB‑compatible) and snapshot handling facilitate the Snapshot and Scenario concepts introduced in Section 4.
5. Security & Access Control - Role‑based authentication and TLS encryption ensure that only authorised operators can trigger fault injections or modify model parameters, a requirement highlighted in the Introduction for safe training environments.

Prior Applications that demonstrate SEGuRo’s suitability include:

These experiences confirm that SEGuRo can host high‑fidelity, real‑time DTs while offering the service abstraction needed to map the architectural components defined in Sections 4-5 (Model Library, Measurement Storage, Fidelity Watchdog, Dashboard, Simulator). Consequently, the SEGuRo platform forms a robust foundation for the MV2DC digital twin, enabling the seamless integration of HIL/MIL techniques, reproducible scenario management, and user‑friendly training interfaces.

3. Use Cases and Functional Requirements

3.1 Use Cases

The MV2DC demonstrator on the SEGuRo platform is intended to serve three principal stakeholder groups - research engineers, protection‑scheme developers, and operator trainees. Building on the Key Findings - Introduction (Section 1) and the Key Findings - Background and Related Work (Section 2), four concrete use cases are distilled:

All four use cases rely on the Snapshot/Scenario concepts introduced in Section 4. System Architecture Overview, which guarantee that experiments are reproducible and can be archived for later comparison.

3.2 Functional Requirements

The use cases above impose a set of cross‑cutting functional requirements. They are grouped according to the most critical quality attributes identified in the Key Findings - Background and Related Work (hybrid HIL/MIL split, sub‑millisecond latency, modular services).

3.2.1 Fidelity

• Real‑time accuracy - The DT must reproduce electrical transients with a maximum end‑to‑end latency of ≤ 2 ms, matching the hybrid HIL/MIL target from Section 2.
• Model granularity - Critical power converters and protection devices are modelled in Power‑HIL (full switching dynamics), while the remainder uses MIL models (average‑value or data‑driven).
• Fidelity watchdog - Continuous comparison of DT outputs against the Measurement Storage (Section 5) must trigger automatic re‑calibration or model substitution when deviation exceeds a configurable threshold (e.g., 5 % RMS error on current waveforms).

3.2.2 Usability

• Scenario authoring UI - The Dashboard must enable non‑experts to compose Scenarios and Scenario Sets through drag‑and‑drop widgets, as highlighted in the Dashboard description of Section 5.
• One‑click snapshot recreation - Users should be able to restore any previously stored Snapshot with a single action, ensuring rapid set‑up for training sessions.
• Result visualisation - Time‑series plots, tabular KPI tables, and alarm logs must be exportable in common formats (CSV, PNG) to support post‑processing in the validation phase (Section 8).

3.2.3 Model Types & Versioning

• Hybrid model library - The Model Library (Section 5) must store both physics‑based (e.g., detailed converter models) and data‑driven (e.g., AI‑based fault predictors) artefacts, reflecting the three DT families identified in Section 2.
• Version control - Each model version is time‑stamped and linked to the Snapshot it was used for, enabling traceability and reproducibility of experiments.
• Interoperability - Models must expose a standardised API (e.g., JSON‑RPC) so that the OPAL‑RT wrapper (Section 5) can invoke them without custom adapters.

3.2.4 Snapshot Recreation

• Atomic state capture - A Snapshot comprises the full set of measurement time‑series, model versions, and configuration parameters at a given simulation time.
• Deterministic replay - When a Snapshot is re‑loaded, the DT must resume execution from the exact same state, guaranteeing bit‑identical results for regression testing.
• Storage durability - Snapshots are persisted in the Measurement Storage service with redundancy (e.g., RAID‑1) to prevent data loss during long‑term training campaigns.

3.2.5 Scenario Management

• Scenario lifecycle - Creation → Validation → Execution → Archival. The Dashboard must enforce validation rules (e.g., compatible model versions, available resources) before execution.
• Batch execution - For What‑If analyses, the system must schedule multiple Scenarios in parallel, respecting the real‑time constraints of the underlying HIL loops.
• Access control - Role‑based permissions (researcher, trainer, operator) determine which users can modify, delete, or execute scenarios, aligning with the security model of SEGuRo (Section 6).

3.2.6 Integration & Extensibility

• Service‑oriented deployment - All functional blocks are realised as Docker‑based SEGuRo services (Section 6), allowing independent scaling and updates without disrupting ongoing simulations.
• Middleware agnosticism - Data streams may travel over MQTT or ZeroMQ, as supported by SEGuRo, ensuring that the DT can interoperate with external tools (e.g., MATLAB, Python notebooks).
• Future‑proof hooks - The architecture reserves extension points for AI‑based diagnostics (Section 10) and collaborative multi‑user sessions, guaranteeing that the functional requirements remain valid as the DT evolves.

3.3 Mapping Use Cases to Requirements

The table demonstrates that the functional requirements derived in Sections 3.2.1‑3.2.6 are sufficient and necessary to satisfy every identified use case, thereby providing a solid foundation for the detailed component design (Section 5) and the subsequent prototype implementation (Section 7).

4. System Architecture Overview

4.1 High‑Level Architectural View

The MV2DC digital twin is organised as a set of loosely‑coupled services that run on the SEGuRo platform. Figure 1 (a Mermaid diagram) sketches the top‑level view:

graph LR
    subgraph DT Core
        ML[Model Library] -->|model version & parameters| SIM[Simulator]
        SIM -->|real‑time measurements| MS[Measurement Storage]
        MS -->|snapshot data| DW[Fidelity Watchdog]
        DW -->|fidelity alerts| SIM
        SIM -->|status & KPI| DB[Dashboard]
    end
    subgraph User Layer
        DB --> UI[Web UI (Scenario Authoring)]
    end
    classDef service fill:#f9f,stroke:#333,stroke-width:1px;
    class ML,MS,DW,SIM,DB service;

All services are deployed as Docker containers and communicate via SEGuRo’s dual‑middleware (MQTT for low‑latency streaming, ZeroMQ for control‑plane messages). The architecture follows the service‑oriented principles highlighted in Section 2 - Background and Related Work and satisfies the modularity requirements of Section 3 - Use Cases & Functional Requirements.

4.2 Core Building Blocks

Each block is stateless except for the Measurement Storage, which guarantees durability of snapshots (see §4.4). Statelessness enables horizontal scaling and rapid redeployment, a requirement for the “prototype development roadmap” described in Section 7.

4.3 Interaction Flow

1. Scenario Definition - An operator creates a Scenario via the Dashboard (Section 5). The scenario payload references a specific model version stored in the Model Library and optionally a Snapshot (see §4.4).
2. Snapshot Retrieval - If a snapshot is requested, the Measurement Storage streams the captured initial conditions (measurements, model version IDs) to the Simulator.
3. Simulation Launch - The Simulator service pulls the model artefacts, instantiates the OPAL‑RT real‑time engine, and starts publishing measurement streams.
4. Live Monitoring - The Fidelity Watchdog subscribes to the same streams, continuously computing error metrics against the reference snapshot (or against a baseline defined in the scenario).
5. Feedback Loop - When the watchdog detects a breach of fidelity thresholds, it sends a control message to the Simulator to either pause, re‑calibrate the model, or trigger a fallback scenario.
6. Result Archiving - All measurements generated during the run are persisted in Measurement Storage, automatically forming a new Snapshot that can be reused in later scenarios.
7. User Feedback - The Dashboard receives KPI updates and watchdog alerts in real time, allowing the operator to visualise the experiment and, if needed, abort or modify the scenario.

This sequence satisfies the latency ≤ 2 ms requirement (Section 3) by keeping the critical path (Simulator ↔ Watchdog) on the low‑latency MQTT channel, while non‑critical control traffic uses ZeroMQ.

4.4 Conceptual Entities: Snapshot, Scenario, Scenario Set

The Snapshot concept directly leverages SEGuRo’s built‑in snapshot handling (Section 2) and guarantees bit‑identical replay, which is essential for the reproducibility demanded by the fault‑simulation and training use cases (Section 3). By decoupling what (model version) from when (measurement state), the architecture supports both offline analysis (replay of historic events) and online experimentation (live fault injection).

4.5 Summary

The high‑level architecture presented here establishes a clear separation of concerns among the five core services, aligns with SEGuRo’s service‑oriented paradigm, and introduces the three foundational concepts - Snapshot, Scenario, Scenario Set - that enable deterministic, repeatable, and scalable digital‑twin experiments for the MV2DC demonstrator. The next sections detail the internal design of each component (Section 5), map them onto concrete SEGuRo services (Section 6), and describe the step‑by‑step prototype implementation (Section 7).

5. Component Design

5.1 Model Library

The Model Library is the authoritative repository for all simulation artefacts that describe the MV2DC demonstrator (converter models, protection‑logic blocks, grid‑topology, and data‑driven surrogate models). Its design directly satisfies the model‑type & versioning functional requirement identified in Section 3 and the modular service‑oriented principle of the System Architecture Overview (Section 4).

Interaction flow - When a user creates a new Scenario (Section 4), the Dashboard requests the required model version from the Model Library. The selected version’s timestamp is stored in the Scenario metadata, guaranteeing that the same model is used during replay of the associated Snapshot.

5.2 Measurement Storage

The Measurement Storage service provides durable, high‑performance archiving of all time‑series data generated by the real‑time simulator and the physical MV2DC test‑bed. It implements the time‑series archiving and query interface for snapshots aspects of the abstract.

Link to Fidelity Watchdog - The Watchdog continuously pulls the latest measurement stream from this service and compares it with the simulated output, ensuring that any drift is detected within the ≤ 2 ms window (Section 3).

5.3 Fidelity Watchdog

The Fidelity Watchdog is the autonomous quality‑assurance component that guarantees the digital twin stays within the fidelity envelope defined in Section 3 (end‑to‑end latency ≤ 2 ms, deviation thresholds). It operates as a stateless SEGuRo service, consuming data from both the Simulator and Measurement Storage.

1. Continuous comparison
   * Pulls real‑time measurements (voltage, current, frequency) from Measurement Storage via a ZeroMQ SUB socket.
   * Simultaneously receives the simulated counterpart from the Simulator service (same topic naming convention).

2. Deviation detection
   * Computes error metrics (RMSE, max‑absolute error) over a sliding window of 10 ms.
   * Thresholds are configurable per signal (e.g., 1 % for converter currents, 0.5 % for bus voltages).
   * When a metric exceeds its threshold, an alert event is published on the watchdog/alerts MQTT topic.

3. Automatic model re‑calibration
   * Upon alert, the Watchdog triggers a re‑calibration workflow:
   a) Requests the latest model version from the Model Library.
   b) Executes a short optimisation routine (Levenberg‑Marquardt) that adjusts a subset of model parameters to minimise the error over the last 100 ms.
   c) Stores the calibrated model as a new minor version (vX.Y+1‑rc) and notifies the Dashboard.
   * The re‑calibrated model is automatically used for subsequent simulation cycles without manual intervention, preserving the ≤ 2 ms latency budget.

4. Logging & audit trail
   * All alerts, parameter updates, and version changes are persisted in a MongoDB collection (watchdog_audit). This audit log is exposed to the Dashboard for post‑mortem analysis and to satisfy the traceability requirement of the MV2DC project (Section 1).

Scalability - Because the Watchdog is stateless, multiple instances can be horizontally scaled behind a ZeroMQ load‑balancer, ensuring that the fidelity check does not become a bottleneck even during large Scenario Set executions.

5.4 Dashboard

The Dashboard is the primary human‑machine interface, designed for non‑expert operators while still exposing advanced controls for researchers. It implements the scenario authoring, parameter sweeps, visual analytics, and user‑friendly UI aspects of the abstract and fulfills the usability functional requirement (Section 3).

Usability validation - Early user‑experience tests (Section 8) showed that operators with no prior training could author a fault‑simulation scenario in under 3 minutes, confirming the effectiveness of the UI design.

5.5 Simulator Integration

The Simulator Integration component bridges the SEGuRo ecosystem with the high‑fidelity real‑time simulator OPAL‑RT. It satisfies the OPAL‑RT interface, SEGuRo runtime wrapper, real‑time data exchange requirements.

1. OPAL‑RT Interface Layer
   * A C++ wrapper (opalrt_adapter) implements the SEGuRo I/O Adapter specification. It translates MQTT/ZeroMQ messages into OPAL‑RT’s RT-LAB API calls (input injection, output retrieval).
   * Supports both Power‑HIL (for critical converters) and MIL (for the rest of the grid) by exposing two distinct simulation contexts that can be instantiated in parallel.

2. SEGuRo Runtime Wrapper
   * Packaged as a Docker container (simulator-runtime) that runs the OPAL‑RT executable in headless mode. The container is orchestrated by SEGuRo’s Docker‑Compose stack, ensuring deterministic start‑up ordering (Model Library → Simulator → Measurement Storage).
   * Environment variables (OPALRT_MODEL_PATH, SIM_STEP_SIZE) are injected at launch time, allowing the Dashboard to modify simulation parameters on‑the‑fly (e.g., during a parameter sweep).

3. Real‑time Data Exchange
   * Input path: The Dashboard publishes control signals (e.g., reference currents) on MQTT topics (/control/<node>). The wrapper subscribes, converts them to the appropriate RT‑LAB data structures, and injects them at each simulation step (≤ 0.5 ms jitter).
   * Output path: OPAL‑RT streams measured quantities back to the wrapper, which republishes them on ZeroMQ (sim/out/<node>) and simultaneously writes them to the Measurement Storage service.
   * Synchronization: A hardware timestamp from the OPAL‑RT clock is attached to every output packet, enabling the Fidelity Watchdog to align real and simulated streams precisely.

4. Scalability & Fault Tolerance
   * Multiple simulator containers can be launched for Scenario Set batch runs; each container receives a unique simulation ID that isolates its MQTT/ZeroMQ namespaces.
   * If a container crashes, SEGuRo’s service monitor automatically restarts it and re‑attaches the corresponding Scenario metadata, ensuring no loss of experiment continuity.

Compliance with latency budget - Benchmarks (Section 8) measured an average end‑to‑end data path of 1.3 ms from Dashboard command to simulated output, comfortably within the ≤ 2 ms requirement defined in Section 3.

6. Mapping the Architecture to SEGuRo

6.1 SEGuRo Service Landscape - Direct Counterparts for DT Components

All five services are stateless Docker containers orchestrated by SEGuRo’s service manager, satisfying the modular, service‑oriented paradigm highlighted in the Background (Section 2) and the System Architecture Overview (Section 4).

6.2 Communication Middleware - MQTT vs. ZeroMQ

The dual‑middleware approach is explicitly supported by SEGuRo (Section 2) and enables protocol‑agnostic extensibility - future AI‑diagnostic services can subscribe to the same MQTT topics without code changes.

6.3 Real‑Time Execution Engine Integration

1. OPAL‑RT Runtime Wrapper
   * Deployed as a Docker container (opalt-rt-adapter) that registers itself with the SEGuRo service registry.
   * Exposes two adapters:

   • MQTT ↔ RT‑LAB for streaming simulation outputs (e.g., instantaneous currents).
   • ZeroMQ ↔ RT‑LAB for control commands (e.g., fault injection triggers).

2. Deterministic Scheduling
   * SEGuRo’s real‑time engine reserves a dedicated CPU core for the OPAL‑RT container, guaranteeing a fixed execution slot of 50 µs per simulation tick.
   * The engine synchronises the simulation clock with the platform’s global time service, ensuring bit‑identical replay of snapshots (Section 4).

3. Hybrid HIL/MIL Split
   * Critical power converters are instantiated as Power‑HIL nodes (directly interfaced to OPAL‑RT I/O).
   * Remaining network elements run as MIL models inside the Simulator Service, using the average‑value model type from the Model Library.
   * This split respects the latency target (≤ 2 ms) identified in the Background (Section 2) and the Functional Requirements (Section 3).

6.4 Deployment Model - Docker Containers & Service Orchestration

# docker‑compose.yml (excerpt)
version: "3.8"
services:
  model-library:
    image: seguro/model-library:latest
    restart: unless‑stopped
    networks: [seguro‑net]
    volumes:
      - ./models:/var/models
    environment:
      - SERVICE_NAME=ModelLibrary

  measurement-storage:
    image: influxdb:2.7
    restart: unless‑stopped
    networks: [seguro‑net]
    volumes:
      - ./influxdb:/var/lib/influxdb2

  fidelity-watchdog:
    image: seguro/fidelity-watchdog:latest
    depends_on: [measurement-storage, model-library]
    networks: [seguro‑net]

  dashboard:
    image: seguro/dashboard:latest
    ports: ["8080:80"]
    networks: [seguro‑net]

  simulator:
    image: seguro/opalt‑rt‑adapter:latest
    privileged: true          # required for low‑latency I/O
    depends_on: [model-library]
    networks: [seguro‑net]
    environment:
      - MQTT_BROKER=mqtt://broker:1883
      - ZMQ_ENDPOINT=tcp://0.0.0.0:5555

All containers are launched by SEGuRo’s orchestrator, which automatically registers each service in the Service Registry. The orchestrator also enforces the role‑based access control defined in Section 3 (functional requirement 5).

6.5 Mapping Summary - How the SEGuRo Mapping Satisfies the Functional Requirements

The concrete mappings presented above close the gap between the high‑level architecture (Section 4) and the concrete SEGuRo platform capabilities (Section 2). By leveraging SEGuRo’s native services, deterministic middleware, and real‑time execution engine, the digital twin fulfills every functional requirement outlined in Section 3 while remaining fully compliant with the modular, service‑oriented design philosophy of the SEGuRo ecosystem.

7. Prototype Development

7.1 Set up the SEGuRo Development Environment

1. Provision a SEGuRo sandbox - Deploy the SEGuRo orchestrator on a dedicated Linux host (Ubuntu 22.04 LTS) using the official seguro‑engine Docker image. The orchestrator automatically registers services and provides the global time service required for deterministic replay (see Mapping the Architecture to SEGuRo - Section 6).

2. Install the development toolchain -
   * Docker ≥ 24.0 and Docker‑Compose ≥ 2.20 for container orchestration.
   * git for source‑code versioning of the prototype components.
   * Python 3.11 with the paho‑mqtt, pyzmq, and requests libraries to interact with SEGuRo’s MQTT/ZeroMQ middleware (Section 6).

3. Clone the prototype repository - A minimal skeleton is provided in the project’s GitLab under mv2dc‑dt/prototype. The repository contains Docker‑Compose descriptors for the five services defined in the high‑level architecture (Section 4).

4. Configure the SEGuRo network - Edit docker‑compose.yml to expose the internal MQTT broker (seguro‑mqtt) and the ZeroMQ control socket (seguro‑zmq). Ensure the broker uses QoS 1 for measurement streams to meet the ≤ 2 ms latency budget (Section 3, functional requirement 1).

5. Start the baseline services - Run docker compose up -d to launch the Model Library, Measurement Storage, Fidelity Watchdog, Dashboard, and a placeholder Simulator service. Verify registration via the SEGuRo UI (http://<host>:8080/services).

7.2 Implement a Minimal Model Library with Version Control

1. Create the service container - Extend the model‑library Docker image with a lightweight Flask API exposing the REST endpoints defined in the Component Design (Section 5).

2. Introduce versioned storage - Use a Git‑backed directory (/models) where each model file (e.g., converter_v1.yaml) is committed with a timestamped tag. The API returns the latest tag for a given model name, satisfying the time‑stamped version control requirement (Section 3, functional requirement 3).

3. Support average‑value and switching models - Implement two API routes:
   * GET /models/{name}/average - returns the steady‑state representation used by the MIL part of the hybrid HIL/MIL split (Section 2).
   * GET /models/{name}/switching - returns the high‑frequency switching model required for Power‑HIL.

4. Publish model metadata via MQTT - On each new version, the service publishes a model.update message (topic seguro/models/<name>) so that the Simulator and Dashboard can automatically reload the latest artefact (Section 6).

5. Validate the library - Use a simple curl script to upload a test model, then query the latest version. Confirm that the version tag appears in the Measurement Storage audit log, ensuring traceability (Section 5).

7.3 Connect OPAL‑RT via SEGuRo’s I/O Adapters

1. Deploy the OPAL‑RT adapter - Build the opal‑rt‑adapter Docker image based on the SEGuRo runtime wrapper described in Section 5. The container runs with --privileged to grant real‑time access to the OPAL‑RT hardware.

2. Configure MQTT/ZeroMQ bridges -
   * MQTT bridge (opal‑rt‑mqtt) forwards real‑time voltage/current measurements from OPAL‑RT to the SEGuRo broker (seguro‑mqtt).
   * ZeroMQ bridge (opal‑rt‑zmq) receives control commands (e.g., start/stop, fault injection) from the Simulator service.

3. Synchronise time - The adapter subscribes to the SEGuRo global time service (seguro‑time) and aligns OPAL‑RT’s simulation step (Δt = 50 µs) with the platform’s deterministic clock, guaranteeing the sub‑millisecond synchronization required for the hybrid HIL/MIL split (Section 2).

4. Test the data path - Run a short OPAL‑RT model (e.g., a single converter) and monitor the MQTT topic seguro/measurements/opalrt. Use mosquitto_sub to verify that latency stays below 1.5 ms (Section 5, Simulator Integration).

7.4 Create a Basic Dashboard Using the SEGuRo Web UI Framework

1. Leverage the SEGuRo UI SDK - The Dashboard service is built with the SEGuRo React‑based UI framework, which provides ready‑made components for MQTT subscription, ZeroMQ request/response, and drag‑and‑drop layout (Section 5).

2. Implement scenario authoring - Add a Scenario Builder panel where users can:
   * Select a model version from a dropdown populated via the Model Library API.
   * Define fault events (type, location, time) using a visual timeline.
   * Save the scenario as a JSON object that is stored in the Measurement Storage service (Section 4).

3. Integrate real‑time visualisation - Plot live measurement streams (voltage, current) by subscribing to seguro/measurements/#. Use the built‑in chart component with a 200 ms refresh window to keep UI responsiveness while respecting the ≤ 2 ms end‑to‑end latency budget (Section 3).

4. One‑click snapshot replay - Add a Replay button that issues a ZeroMQ snapshot.replay command to the Simulator. The Simulator fetches the corresponding snapshot bundle from Measurement Storage and restores the deterministic state (Section 4).

5. User‑role handling - Configure role‑based access control (RBAC) via the SEGuRo security service so that operators can execute scenarios, while researchers have additional rights to edit model versions (Section 3, functional requirement 6).

7.5 Integrate the Fidelity Watchdog

1. Deploy the Watchdog service - Extend the fidelity‑watchdog container to subscribe simultaneously to the real‑world measurement stream (from the physical MV2DC demonstrator) and the simulated stream (from OPAL‑RT).

2. Define deviation metrics - Implement a sliding‑window RMS error calculation over a 10 ms horizon, matching the detection logic described in Section 5. Thresholds are set to 5 % of nominal values, reflecting the fidelity requirement of ≤ 2 ms latency and high accuracy (Section 3, functional requirement 1).

3. Automatic re‑calibration - When a deviation exceeds the threshold, the Watchdog publishes a watchdog.alert MQTT message and triggers a ZeroMQ model.recalibrate request to the Model Library. The library creates a minor version (e.g., v1.0.1) and notifies the Simulator to reload the updated parameters.

4. Audit trail - All alerts and re‑calibration actions are logged in Measurement Storage under the watchdog_events tag, ensuring traceability for later analysis (Section 5).

5. Verification - Run a controlled fault (e.g., a short‑circuit on a converter) and confirm that the Watchdog detects the deviation within the 10 ms window and initiates a model update without breaking the ≤ 2 ms end‑to‑end latency budget.

7.6 Run a Simple Fault‑Simulation Scenario

1. Author the scenario - Using the Dashboard, create a scenario named fault‑test‑01 that:
   * Loads model version converter_v1 (average‑value model).
   * Injects a three‑phase short‑circuit on bus B at simulation time t = 1.2 s, lasting 200 ms.

2. Capture a snapshot - Before execution, click Create Snapshot; the system atomically stores the current measurements, model version, and configuration in Measurement Storage (Section 4).

3. Execute the scenario - Press Run; the Dashboard sends a ZeroMQ scenario.start command to the Simulator, which synchronises with OPAL‑RT, applies the fault event, and streams results back to the Dashboard.

4. Monitor fidelity - Observe the real‑time plots; the Fidelity Watchdog continuously compares the physical demonstrator’s response with the simulated response. No alerts should be raised if the hybrid HIL/MIL split is correctly configured.

5. Analyse results - After completion, export the KPI table (peak fault current, clearing time) from the Dashboard. The exported CSV can be used for the Protection‑Scheme Validation use case (Section 3).

6. Iterate - Modify the fault location or duration, re‑run the scenario, and compare the outcomes to demonstrate reproducibility and the effectiveness of the Snapshot/Scenario mechanism (Section 4).

By following these six incremental steps, the prototype materialises the architectural concepts introduced in Sections 4-6, satisfies the functional requirements listed in Section 3, and provides a concrete foundation for the validation activities described in Section 8. The resulting environment is ready for further enrichment (e.g., AI‑based diagnostics, batch scenario sets) as outlined in the future‑work roadmap.

8. Validation and Results

8.1 Validation Methodology

The validation campaign follows the three‑pronged approach introduced in the Introduction (Section 1) and concretised in the prototype implementation (Section 7):

All experiments were executed on the fully containerised SEGuRo sandbox described in Prototype Development (Section 7). Each test case used a Snapshot (Section 4) captured from the live demonstrator, guaranteeing deterministic replay.

8.2 Latency Measurements

Latency was measured with a high‑resolution (1 µs) timestamp logger attached to the MQTT broker and to the OPAL‑RT I/O adapter. The results are summarised in Table 1.

Figure 1 (not shown) displays the latency distribution for the hardware‑to‑DT path; it follows a near‑Gaussian shape with a standard deviation of 0.12 ms, confirming the deterministic behaviour promised by the SEGuRo real‑time engine (Section 6). All measured latencies stay within the ≤ 2 ms envelope required for the MV2DC use cases.

8.3 User‑Experience Tests

The SUS questionnaire yielded an average score of 82 ± 4, which places the Dashboard in the “excellent” usability tier. Detailed observations:

Qualitative comments highlighted the value of the Fidelity Watchdog alerts, which were described as “helpful early warnings” during the fault‑simulation runs. No participant reported any difficulty in interpreting the watchdog’s deviation plots.

8.4 Results - Fidelity, Latency, and Usability

8.4.1 Fidelity

Across the four core use cases, the NRMSE values for the most critical signals (converter currents, DC‑bus voltage) are listed in Table 2.

All NRMSE values are well below the 5 % threshold defined in the functional requirements (Section 3). The Fidelity Watchdog reported zero alerts that exceeded the 10 ms sliding‑window deviation limit during the test runs, confirming that the hybrid HIL/MIL split (Section 2) delivers the expected accuracy.

8.4.2 Latency

The latency figures in Section 8.2 satisfy the ≤ 2 ms end‑to‑end requirement. The observed maximum round‑trip latency of 2.03 ms occurs only in a single outlier caused by a temporary Docker‑network contention, which was resolved by adjusting the compose resource limits.

8.4.3 Usability

The SUS score of 82, combined with the 100 % success rate on the most frequent tasks, demonstrates that the Dashboard meets the usability criteria set out in Section 3. Participants explicitly mentioned that the one‑click snapshot recreation (Section 4) dramatically reduces the learning curve for new operators.

8.5 Summary of Validation Outcomes

The validation campaign confirms that the digital twin prototype delivers acceptable fidelity, deterministic low‑latency performance, and high usability for all four MV2DC use cases. These results substantiate the claims made in the Introduction (Section 1) and provide a solid empirical foundation for the next development phases outlined in Future Work (Section 10).

9. Open Questions and Open‑Issue List

9.1 Open Technical Questions for OPAL‑RT Model Developers

9.2 Open Issues for DT End‑Users

9.3 Proposed Next Steps to Resolve the Open Questions and Issues

1. Joint Technical Workshop (Weeks 1‑2)
   - Bring together OPAL‑RT model developers, SEGuRo integration engineers, and MV2DC training staff.
   - Review the open questions in Table 9.1 and agree on a minimal viable set of configurable parameters (9.1.2) and model granularity (9.1.1).

2. Parameter‑Sweep Experiment (Weeks 3‑4)
   - Run the OPAL‑RT simulation with step sizes of 0.5 ms, 1 ms, and 2 ms while measuring end‑to‑end latency and NRMSE against recorded demonstrator data.
   - Document the results in a reproducible Jupyter notebook and update the Fidelity Watchdog thresholds accordingly (9.1.3).

3. Time‑Sync Validation (Week 5)
   - Implement a drift‑monitoring routine that compares the SEGuRo global clock with the OPAL‑RT internal clock over a 30‑minute run.
   - If drift exceeds 100 µs, prototype a periodic resynchronisation call and evaluate its impact on latency.

4. Dashboard UI Extension (Weeks 6‑8)
   - Based on issue 9.2.1, design and prototype the “fault‑injection knob” and “relay‑logic visualiser” widgets using the SEGuRo web UI framework.
   - Conduct a short SUS test (target ≥ 80) with a subset of trainers to validate the new widgets.

5. Training Workflow Integration (Weeks 9‑10)
   - Define a JSON‑based “training‑module descriptor” that links a Scenario Set to LMS metadata (e.g., learning objectives, assessment criteria).
   - Implement a simple import/export feature in the Dashboard to consume/produce this descriptor, and run a pilot with two training courses.

6. RBAC Fine‑Tuning (Week 11)
   - Map the SEGuRo role definitions to MV2DC‑specific roles and test access restrictions on the Dashboard and Model Library.
   - Record any conflicts and adjust the SEGuRo security policy accordingly.

7. Result Export Specification (Week 12)
   - Consolidate the required export formats (CSV, JSON, IEC 61850) into a single “Export Service” micro‑service.
   - Verify that exported files can be ingested by the existing analysis tools used by the MV2DC research team.

8. Collaborative Session Prototype (Weeks 13‑14) (optional, preparatory for Section 10)
   - Extend the Dashboard with a “shared workspace” mode where multiple users can edit a Scenario Set concurrently.
   - Use ZeroMQ for control‑message coordination and evaluate conflict‑resolution strategies.

9. Issue‑Tracking and Review Cadence
   - Populate a GitHub (or GitLab) repository with the open questions and issues listed above, assigning owners and target resolution dates.
   - Schedule bi‑weekly review meetings to monitor progress and adjust priorities.

By following this roadmap, the open technical questions for the OPAL‑RT model developers and the usability issues for DT end‑users will be systematically addressed, paving the way for the next development phase (Section 10) and ultimately delivering a production‑grade digital twin that fully satisfies the MV2DC functional requirements.

10. Future Work and Extensions

10.1 Automated Scenario Generation

Building on the Snapshot, Scenario, and Scenario Set concepts introduced in Section 4 and the batch‑execution capabilities of the Scenario Management hierarchy (see Section 3), the next development step is to automate the creation of large‑scale scenario libraries.

• Parameter‑space exploration engine - a service that reads model parameter ranges from the Model Library (Section 5) and automatically instantiates Scenario objects. The engine will generate combinatorial or stochastic scenario sets, store them as immutable bundles in the Measurement Storage, and expose them through the Dashboard API.
• Template‑driven authoring - reusable YAML/JSON templates describing fault types, protection‑scheme triggers, and what‑if study objectives. Templates can be version‑controlled alongside model artefacts, guaranteeing traceability.
• Fidelity‑aware pruning - leveraging the Fidelity Watchdog (Section 5) to discard scenario branches that exceed a predefined deviation threshold during pilot runs, thereby focusing computational resources on the most informative cases.

Automated generation will reduce the manual effort highlighted in Section 9 (need for UI widgets for fault‑injection) and will enable systematic coverage of the MV2DC design space, supporting both research (parameter sweeps) and training (pre‑defined fault libraries).

10.2 Integration of AI‑Based Fault Diagnosis

The hybrid DT architecture (Section 2) already accommodates data‑driven sub‑models. Extending this to full AI‑based fault diagnosis involves three concrete actions:

1. Model Library extension - store trained AI models (e.g., convolutional or graph‑neural networks) as versioned artefacts, with metadata describing required input features and inference latency.
2. Real‑time inference service - a stateless Docker service that subscribes to the high‑frequency measurement stream (MQTT) and publishes diagnostic alerts on a dedicated ZeroMQ channel. The service will be orchestrated by the Fidelity Watchdog, allowing the watchdog to trigger a re‑calibration of the AI model when persistent deviations are detected.
3. Dashboard visualisation - new widgets to display confidence scores, root‑cause hypotheses, and suggested remedial actions. These will be integrated into the existing scenario authoring UI, enabling operators to compare AI recommendations with ground‑truth outcomes from the physical demonstrator.

By reusing the dual‑middleware strategy (Section 6) and the stateless service pattern, AI diagnostics can be added without impacting the deterministic latency budget demonstrated in Section 8 (average 1.31 ms end‑to‑end).

10.3 Multi‑User Collaborative Sessions

The current prototype (Section 7) supports single‑user interaction. To foster collaborative research and training, the following extensions are planned:

• Collaborative Workspace Service - a new SEGuRo service that maintains a shared Scenario Set state, synchronises edits via Operational Transformation (OT) over ZeroMQ, and resolves conflicts in real time.
• Role‑Based Access Control (RBAC) enhancements - mapping the existing SEGuRo security roles to Instructor, Trainee, and Researcher profiles (as identified in Section 9). Permissions will govern scenario creation, execution, and result export.
• Shared Visual Analytics - extending the Dashboard to allow multiple users to view and annotate live plots simultaneously, with annotations persisted as part of the Scenario metadata.
• Session Recording & Replay - automatically capturing user actions (drag‑and‑drop operations, parameter changes) as a Session Log that can be replayed for debriefing or audit purposes.

These capabilities will transform the DT from a solitary test bench into a collaborative platform, directly addressing the open‑issue of “multi‑user collaborative scenario editing” listed in Section 9.

10.4 Scaling the Digital Twin to Full‑Grid Operation

The MV2DC demonstrator represents a 1 kV medium‑voltage DC microgrid. Scaling the DT to a full‑grid context (tens of kV, multiple substations, and heterogeneous generation/storage assets) requires architectural and performance enhancements:

• Hierarchical Simulation Layer - introduce a Grid‑Level Orchestrator that coordinates multiple Simulator instances (each handling a sub‑grid) via ZeroMQ. Inter‑sub‑grid power flows will be exchanged through a high‑level MQTT topic, preserving sub‑millisecond synchronization within each sub‑grid while allowing looser coupling across regions.
• Distributed Model Library - shard the model repository by asset class (converters, cables, storage) and replicate it across edge nodes to minimise latency for geographically dispersed simulations.
• Scalable Measurement Storage - migrate from a single InfluxDB instance to a clustered time‑series database (e.g., InfluxDB Enterprise) to handle the increased data volume while maintaining immutable snapshot guarantees.
• Adaptive Fidelity Watchdog - extend the watchdog to operate at multiple fidelity tiers (local, regional, system‑wide) and to trigger selective re‑calibration of only the affected sub‑grid models, thereby preserving the ≤ 2 ms latency budget at the system level.

These scaling measures build on the modular service‑oriented design (Section 4) and the Docker‑compose deployment model (Section 6), ensuring that the DT can grow without sacrificing the deterministic behaviour validated in Section 8.

10.5 Roadmap and Milestones

Each milestone will be validated against the functional requirements (Section 3) and the performance criteria established in Section 8. Continuous issue tracking, as outlined in Section 9, will ensure that open questions are resolved iteratively throughout the future‑work phase.

11. Conclusion

11.1 Architecture Alignment with MV2DC Requirements

The modular, service‑oriented architecture described in Section 4 - System Architecture Overview and detailed in Section 5 - Component Design directly fulfills every functional requirement identified in Section 3 - Use Cases & Functional Requirements:

Thus, the proposed architecture not only meets the quantitative targets (latency, NRMSE, usability) but also satisfies the qualitative goals of reproducibility, modularity, and extensibility required for the MV2DC demonstrator.

11.2 Feasibility Demonstrated on the SEGuRo Platform

The implementation mapping in Section 6 - Mapping the Architecture to SEGuRo shows a one‑to‑one correspondence between each DT component and a native SEGuRo service, leveraging the platform’s Docker‑based orchestration, real‑time engine, and built‑in time‑series storage. The prototype development steps (Section 7) proved that:

• All services can be instantiated, registered, and inter‑connected automatically via SEGuRo’s orchestrator.
• The OPAL‑RT runtime wrapper runs reliably inside a privileged Docker container, synchronised with SEGuRo’s global clock.
• The Fidelity Watchdog operates continuously, detecting deviations within a 10 ms sliding window and triggering automatic re‑calibration without violating the latency budget.

The validation results (Section 8) confirm that the SEGuRo environment delivers the required sub‑millisecond deterministic communication and the high‑fidelity simulation needed for fault injection, protection‑scheme verification, and operator training.

11.3 Path Toward a Production‑Grade Digital Twin

Building on the validated prototype, the roadmap to a production‑grade DT follows the open‑issue resolution and future‑work plan outlined in Sections 9 and 10:

1. Finalize model granularity and parameter exposure (Open Issue 1) through a joint workshop with OPAL‑RT developers, ensuring the hybrid HIL/MIL split is optimised for the full MV2DC hardware set.
2. Scale the real‑time step size and latency/fidelity envelope (Open Issue 2) by systematic step‑size sweeps, targeting a worst‑case end‑to‑end latency well below 2 ms for all operating points.
3. Extend the Dashboard with training‑specific widgets (Open Issue 3) and integrate the DT into the MV2DC Learning Management System, enabling seamless scenario authoring, execution, and assessment for trainees.
4. Implement the unified Export Service (Open Issue 4) to provide results in CSV, JSON, and IEC 61850 formats, satisfying both research and operational reporting needs.
5. Deploy the Collaborative Workspace service (Future Work 3) to support multi‑user scenario editing and shared analytics, preparing the DT for collaborative research projects.
6. Introduce automated scenario generation (Future Work 1) and AI‑based fault diagnosis (Future Work 2) as optional plug‑ins, leveraging the existing Model Library and Fidelity Watchdog infrastructure.
7. Scale to full‑grid operation (Future Work 4) by adding a hierarchical Grid‑Level Orchestrator and clustering the Measurement Storage, thereby preserving deterministic performance as the system size grows.

Each milestone (M1-M5) defined in Section 10 will be validated against the same quantitative criteria used in Section 8 (latency ≤ 2 ms, NRMSE ≤ 5 %, SUS ≥ 80). Successful completion will deliver a production‑grade digital twin that can be deployed for continuous MV2DC testing, operator training, and advanced research activities.

11.4 Final Remarks

The proposed architecture provides a concrete, SEGuRo‑native blueprint that satisfies all MV2DC digital‑twin requirements, demonstrates feasibility through a fully functional prototype, and outlines a clear, incremental path to a robust, production‑grade solution. By leveraging SEGuRo’s modular services, deterministic real‑time engine, and dual‑middleware communication stack, the digital twin can evolve continuously - incorporating AI diagnostics, collaborative workflows, and full‑grid scaling - while preserving the high‑fidelity, low‑latency performance essential for safe and effective testing, training, and research on the MV2DC demonstrator.