% Options for packages loaded elsewhere \PassOptionsToPackage{unicode}{hyperref} \PassOptionsToPackage{hyphens}{url} % \documentclass[ ]{report} \usepackage{amsmath,amssymb} \usepackage{iftex} \ifPDFTeX \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{textcomp} % provide euro and other symbols \else % if luatex or xetex \usepackage{unicode-math} % this also loads fontspec \defaultfontfeatures{Scale=MatchLowercase} \defaultfontfeatures[\rmfamily]{Ligatures=TeX,Scale=1} \fi \usepackage{lmodern} \ifPDFTeX\else % xetex/luatex font selection \fi % Use upquote if available, for straight quotes in verbatim environments \IfFileExists{upquote.sty}{\usepackage{upquote}}{} \IfFileExists{microtype.sty}{% use microtype if available \usepackage[]{microtype} \UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts }{} \makeatletter \@ifundefined{KOMAClassName}{% if non-KOMA class \IfFileExists{parskip.sty}{% \usepackage{parskip} }{% else \setlength{\parindent}{0pt} \setlength{\parskip}{6pt plus 2pt minus 1pt}} }{% if KOMA class \KOMAoptions{parskip=half}} \makeatother \usepackage{xcolor} \usepackage[margin=2.0cm,a4paper]{geometry} \usepackage{color} \usepackage{fancyvrb} \newcommand{\VerbBar}{|} \newcommand{\VERB}{\Verb[commandchars=\\\{\}]} \DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}} % Add ',fontsize=\small' for more characters per line \newenvironment{Shaded}{}{} \newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}} \newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} \newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{#1}} \newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}} \newcommand{\BuiltInTok}[1]{\textcolor[rgb]{0.00,0.50,0.00}{#1}} \newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} \newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{#1}}} \newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} \newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{#1}} \newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}} \newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{#1}} \newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}} \newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{#1}}} \newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}} \newcommand{\ExtensionTok}[1]{#1} \newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}} \newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{#1}} \newcommand{\ImportTok}[1]{\textcolor[rgb]{0.00,0.50,0.00}{\textbf{#1}}} \newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} \newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}} \newcommand{\NormalTok}[1]{#1} \newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{#1}} \newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{#1}} \newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{#1}} \newcommand{\RegionMarkerTok}[1]{#1} \newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} \newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{#1}} \newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} \newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{#1}} \newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} \newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} \usepackage{longtable,booktabs,array} \usepackage{calc} % for calculating minipage widths % Correct order of tables after \paragraph or \subparagraph \usepackage{etoolbox} \makeatletter \patchcmd\longtable{\par}{\if@noskipsec\mbox{}\fi\par}{}{} \makeatother % Allow footnotes in longtable head/foot \IfFileExists{footnotehyper.sty}{\usepackage{footnotehyper}}{\usepackage{footnote}} \makesavenoteenv{longtable} \setlength{\emergencystretch}{3em} % prevent overfull lines \providecommand{\tightlist}{% \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}} \setcounter{secnumdepth}{-\maxdimen} % remove section numbering \usepackage{titlesec} \usepackage{fancyvrb} \usepackage{fvextra} \usepackage{enumitem} \usepackage{pdfpages} \usepackage{longtable} \usepackage{etoolbox} \usepackage{fontspec} \setmainfont{lmroman10-regular.otf}[ BoldFont = lmroman10-bold.otf, ItalicFont = lmroman10-italic.otf, BoldItalicFont = lmroman10-bolditalic.otf, OpticalSize = 0 ] \AtBeginEnvironment{longtable}{\fontsize{6}{8}\selectfont} \newcommand{\chapfnt}{\fontsize{19}{21}} \newcommand{\secfnt}{\fontsize{14}{17}} \newcommand{\ssecfnt}{\fontsize{12}{14}} \newcommand{\sectionbreak}{\clearpage} \newcommand{\llbracket}{[\![} \newcommand{\rrbracket}{]\!]} \titleformat{\chapter}[display] {\normalfont\chapfnt\bfseries}{\chaptertitlename\ \thechapter}{20pt}{\chapfnt} \titleformat{\section} {\normalfont\secfnt\bfseries}{\thesection}{1em}{} \titleformat{\subsection} {\normalfont\ssecfnt\bfseries}{\thesubsection}{1em}{} \titlespacing*{\chapter} {0pt}{50pt}{40pt} \titlespacing*{\section} {0pt}{3.5ex plus 1ex minus .2ex}{2.3ex plus .2ex} \titlespacing*{\subsection} {0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex} \DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\},fontsize=\scriptsize,frame=single,rulecolor=\color{lightgray},breaklines,samepage,label=\tiny{Code},labelposition=topline} \DefineVerbatimEnvironment{verbatim}{Verbatim}{commandchars=\\\{\},fontsize=\scriptsize,frame=single,rulecolor=\color{lightgray},breaklines,samepage,label=\tiny{Output},labelposition=topline,fontshape=it} \setlist{after=\bigskip} \let\OldRule\rule \renewcommand{\rule}[2]{\OldRule{0.0\linewidth}{#2}} \ifLuaTeX \usepackage{selnolig} % disable illegal ligatures \fi \usepackage{bookmark} \IfFileExists{xurl.sty}{\usepackage{xurl}}{} % add URL line breaks if available \urlstyle{same} \hypersetup{ hidelinks, pdfcreator={LaTeX via pandoc}} \title{Architecture and Implementation Plan for a Digital Twin of the MV2DC Demonstrator on the SEGuRo Platform} \author{The Publicator using openai/gpt-oss-120b} \date{} \begin{document} \maketitle { \setcounter{tocdepth}{2} \tableofcontents } \chapter{Architecture and Implementation Plan for a Digital Twin of the MV2DC Demonstrator on the SEGuRo Platform}\label{architecture-and-implementation-plan-for-a-digital-twin-of-the-mv2dc-demonstrator-on-the-seguro-platform} \textbf{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. \section{1. Introduction}\label{introduction} \subsection{1.1 Project Overview}\label{project-overview} The \textbf{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 \textbf{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: \begin{itemize} \tightlist \item Validate novel control and protection concepts for medium‑voltage DC grids.\\ \item Provide a reproducible experimental environment for academia and industry.\\ \item Enable training of operators and engineers on realistic fault and ``what‑if'' scenarios. \end{itemize} To achieve these goals, a \textbf{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. \subsection{1.2 Motivation for a Digital Twin}\label{motivation-for-a-digital-twin} A DT offers three decisive benefits for the MV2DC program: \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{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.\\ \item \textbf{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.\\ \item \textbf{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. \end{enumerate} These capabilities align with the functional requirements identified later in \textbf{Section 3. Use Cases and Functional Requirements}, where fidelity, usability, and scenario management are highlighted as key drivers. \subsection{1.3 Scope and Contributions of This Work}\label{scope-and-contributions-of-this-work} The present publication focuses on the \textbf{architecture and implementation plan} for a DT that is \textbf{native to the SEGuRo platform}. The main contributions are: \begin{itemize} \tightlist \item \textbf{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 \textbf{Section 6. Mapping the Architecture to SEGuRo}.\\ \item \textbf{Definition of core concepts} - \emph{Snapshot} (a time‑stamped state of the grid), \emph{Scenario} (a scripted sequence of events), and \emph{Scenario Set} (a collection of related scenarios) - that enable reproducible experiments and automated testing, introduced in \textbf{Section 4. System Architecture Overview}.\\ \item \textbf{A step‑by‑step prototype roadmap}, covering environment setup, model versioning, OPAL‑RT integration, dashboard creation, and fidelity watchdog implementation, outlined in \textbf{Section 7. Prototype Development}.\\ \item \textbf{Preliminary validation results} that demonstrate acceptable latency and model fidelity for the identified use cases, summarized in \textbf{Section 8. Validation and Results}. \end{itemize} 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 \textbf{scalability}, \textbf{maintainability}, and \textbf{interoperability} with future extensions such as AI‑based fault diagnosis (see \textbf{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. \section{2. Background and Related Work}\label{background-and-related-work} \subsection{2.1 Digital‑Twin Concepts for Medium‑Voltage DC Grids}\label{digitaltwin-concepts-for-mediumvoltage-dc-grids} The notion of a \textbf{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 \textbf{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 \emph{1. Introduction}). Existing DT approaches for MV‑DC can be grouped into three families: \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1754}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1930}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.3158}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.3158}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Approach \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Core Idea \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Typical Fidelity \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Typical Use‑Case \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Physics‑based DT} & Detailed electromagnetic and electro‑thermal models (e.g., switching‑level converter models, cable temperature dynamics). & Very high (sub‑µs time step, full switching dynamics). & Fault‑injection, protection‑scheme verification, hardware‑in‑the‑loop (HIL) validation. \\ \textbf{Data‑driven DT} & Surrogate models derived from measurement data (e.g., neural‑network or Gaussian‑process approximations). & Medium (ms‑level resolution). & ``What‑if'' scenario analysis, rapid prototyping of AI‑based diagnostics. \\ \textbf{Hybrid DT} & Combination of physics‑based core (for critical components) and data‑driven wrappers (for peripheral devices). & Adjustable (trade‑off between accuracy and computational load). & Training environments where both realism and interactive speed are required. \\ \end{longtable} Across the literature, the \textbf{key drivers} for adopting a DT in MV‑DC contexts are: \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{Safety‑critical testing} - enabling fault injection without risking the physical hardware.\\ \item \textbf{Reproducibility} - the ability to capture a \emph{Snapshot} of the grid state and replay it under varied control strategies (the Snapshot concept is formalised in Section 4).\\ \item \textbf{Operator training} - providing a realistic, real‑time interface that mirrors the SCADA of the demonstrator (see \emph{1. Introduction}). \end{enumerate} 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. \subsection{2.2 Hardware‑in‑the‑Loop (HIL) and Model‑in‑the‑Loop (MIL) Approaches}\label{hardwareintheloop-hil-and-modelintheloop-mil-approaches} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.1294}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.3765}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.2118}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.1294}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.1529}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Technique \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright What is Executed in Real‑Time? \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Typical Platform \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Strengths \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Limitations \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Power‑HIL (PHIL)} & Physical power hardware (e.g., converters, protection relays) interfaced with a real‑time simulator via power amplifiers. & OPAL‑RT, RT‑DS, Typhoon HIL & Captures true device dynamics; ideal for protection‑scheme validation. & Requires expensive power amplifiers; limited scalability for large grids. \\ \textbf{Control‑HIL} & Real controller hardware (PLC, DSP) connected to a simulated plant. & OPAL‑RT, dSPACE & Focuses on control logic verification; lower power‑stage cost. & Plant model fidelity directly impacts test validity. \\ \textbf{Model‑in‑the‑Loop (MIL)} & Both plant and controller are software models executed in a real‑time environment. & OPAL‑RT, MATLAB/Simulink Real‑Time, Python‑based co‑simulation & Highly scalable; enables rapid ``what‑if'' studies and AI‑training loops. & May miss high‑frequency switching effects unless detailed models are used. \\ \end{longtable} The \textbf{MV2DC DT} leverages a \textbf{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 \emph{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: \begin{itemize} \tightlist \item \textbf{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.\\ \item \textbf{Model version control} - frequent updates to converter control software demand a versioned model repository (see \emph{5. Component Design - Model Library}).\\ \item \textbf{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). \end{itemize} \subsection{2.3 The SEGuRo Platform: Capabilities and Prior Applications}\label{the-seguro-platform-capabilities-and-prior-applications} SEGuRo (Secure Grid‑Ready) is a \textbf{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: \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{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 \emph{6. Mapping the Architecture to SEGuRo}).\\ \item \textbf{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.\\ \item \textbf{Communication Middleware} - SEGuRo ships with both \textbf{MQTT} (lightweight publish/subscribe for telemetry) and \textbf{ZeroMQ} (high‑throughput binary streams for HIL data), allowing seamless integration of OPAL‑RT I/O adapters.\\ \item \textbf{Data Management Services} - Built‑in time‑series storage (InfluxDB‑compatible) and snapshot handling facilitate the \emph{Snapshot} and \emph{Scenario} concepts introduced in Section 4.\\ \item \textbf{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 \emph{Introduction} for safe training environments. \end{enumerate} \textbf{Prior Applications} that demonstrate SEGuRo's suitability include: \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2500}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2222}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2778}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2500}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Project \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Domain \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright DT Scope \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Outcome \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Smart‑Grid‑Lab (2022)} & Low‑voltage AC micro‑grid & Full‑grid MIL with Power‑HIL inverter testing & Achieved \textless1 ms latency for inverter control loops; validated fault‑ride‑through algorithms. \\ \textbf{DC‑Railway‑Testbed (2023)} & 750 V DC traction system & Hybrid HIL/MIL for traction converters and braking resistors & Demonstrated safe fault injection on real converters while preserving real‑time constraints. \\ \textbf{Energy‑Storage‑Co‑Sim (2024)} & Battery Energy Storage System (BESS) & MIL model of battery pack with real‑time controller HIL & Provided a reproducible \emph{Snapshot} framework later adopted in the MV2DC project. \\ \end{longtable} These experiences confirm that SEGuRo can host \textbf{high‑fidelity, real‑time DTs} while offering the \textbf{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. \section{3. Use Cases and Functional Requirements}\label{use-cases-and-functional-requirements} \subsection{3.1 Use Cases}\label{use-cases} The MV2DC demonstrator on the SEGuRo platform is intended to serve three principal stakeholder groups - \textbf{research engineers}, \textbf{protection‑scheme developers}, and \textbf{operator trainees}. Building on the \emph{Key Findings - Introduction} (Section 1) and the \emph{Key Findings - Background and Related Work} (Section 2), four concrete use cases are distilled: \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.0484}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2419}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2258}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.4839}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright \# \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Use‑case name \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Primary goal \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Typical workflow (high‑level) \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot 1 & \textbf{Fault Simulation} & Inject reproducible faults (e.g., short‑circuit, converter failure) to observe system response without risking the physical hardware. & 1️⃣ Load a \emph{Snapshot} of the grid state → 2️⃣ Apply a fault definition → 3️⃣ Run the DT in real‑time → 4️⃣ Capture post‑fault measurements for analysis. \\ 2 & \textbf{Protection‑Scheme Validation} & Verify that protection relays and coordination logic react correctly under a variety of fault conditions. & 1️⃣ Select a \emph{Scenario} that includes a protection‑scheme configuration → 2️⃣ Execute the fault simulation (HIL for critical converters, MIL for the rest, per the hybrid split described in Section 2) → 3️⃣ Compare DT‑derived protection actions with expected outcomes. \\ 3 & \textbf{What‑If Analysis} & Explore the impact of design or operational changes (e.g., different converter control parameters, added energy storage) on grid stability and efficiency. & 1️⃣ Create a \emph{Scenario Set} that sweeps the parameter of interest → 2️⃣ Run batch simulations → 3️⃣ Use the Dashboard (Section 5) to visualise key performance indicators. \\ 4 & \textbf{Operator Training} & Provide a realistic, interactive environment for trainees to practice monitoring, fault diagnosis, and remedial actions. & 1️⃣ Load a realistic \emph{Snapshot} (e.g., ``steady‑state operation at 1 kV'') → 2️⃣ Present a live SCADA view via the Dashboard → 3️⃣ Allow the trainee to trigger actions (e.g., open a breaker) → 4️⃣ Immediate feedback from the DT's fidelity watchdog. \\ \end{longtable} All four use cases rely on the \emph{Snapshot/Scenario} concepts introduced in \textbf{Section 4. System Architecture Overview}, which guarantee that experiments are reproducible and can be archived for later comparison. \subsection{3.2 Functional Requirements}\label{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 \emph{Key Findings - Background and Related Work} (hybrid HIL/MIL split, sub‑millisecond latency, modular services). \subsubsection{3.2.1 Fidelity}\label{fidelity} \begin{itemize} \tightlist \item \textbf{Real‑time accuracy} - The DT must reproduce electrical transients with a maximum end‑to‑end latency of \textbf{≤ 2 ms}, matching the hybrid HIL/MIL target from Section 2.\\ \item \textbf{Model granularity} - Critical power converters and protection devices are modelled in \textbf{Power‑HIL} (full switching dynamics), while the remainder uses \textbf{MIL} models (average‑value or data‑driven).\\ \item \textbf{Fidelity watchdog} - Continuous comparison of DT outputs against the \emph{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). \end{itemize} \subsubsection{3.2.2 Usability}\label{usability} \begin{itemize} \tightlist \item \textbf{Scenario authoring UI} - The Dashboard must enable non‑experts to compose \emph{Scenarios} and \emph{Scenario Sets} through drag‑and‑drop widgets, as highlighted in the \emph{Dashboard} description of Section 5.\\ \item \textbf{One‑click snapshot recreation} - Users should be able to restore any previously stored \emph{Snapshot} with a single action, ensuring rapid set‑up for training sessions.\\ \item \textbf{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). \end{itemize} \subsubsection{3.2.3 Model Types \& Versioning}\label{model-types-versioning} \begin{itemize} \tightlist \item \textbf{Hybrid model library} - The \emph{Model Library} (Section 5) must store both \textbf{physics‑based} (e.g., detailed converter models) and \textbf{data‑driven} (e.g., AI‑based fault predictors) artefacts, reflecting the three DT families identified in Section 2.\\ \item \textbf{Version control} - Each model version is time‑stamped and linked to the \emph{Snapshot} it was used for, enabling traceability and reproducibility of experiments.\\ \item \textbf{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. \end{itemize} \subsubsection{3.2.4 Snapshot Recreation}\label{snapshot-recreation} \begin{itemize} \tightlist \item \textbf{Atomic state capture} - A \emph{Snapshot} comprises the full set of measurement time‑series, model versions, and configuration parameters at a given simulation time.\\ \item \textbf{Deterministic replay} - When a \emph{Snapshot} is re‑loaded, the DT must resume execution from the exact same state, guaranteeing bit‑identical results for regression testing.\\ \item \textbf{Storage durability} - Snapshots are persisted in the \emph{Measurement Storage} service with redundancy (e.g., RAID‑1) to prevent data loss during long‑term training campaigns. \end{itemize} \subsubsection{3.2.5 Scenario Management}\label{scenario-management} \begin{itemize} \tightlist \item \textbf{Scenario lifecycle} - Creation → Validation → Execution → Archival. The Dashboard must enforce validation rules (e.g., compatible model versions, available resources) before execution.\\ \item \textbf{Batch execution} - For \emph{What‑If} analyses, the system must schedule multiple \emph{Scenarios} in parallel, respecting the real‑time constraints of the underlying HIL loops.\\ \item \textbf{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). \end{itemize} \subsubsection{3.2.6 Integration \& Extensibility}\label{integration-extensibility} \begin{itemize} \tightlist \item \textbf{Service‑oriented deployment} - All functional blocks are realised as Docker‑based SEGuRo services (Section 6), allowing independent scaling and updates without disrupting ongoing simulations.\\ \item \textbf{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).\\ \item \textbf{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. \end{itemize} \subsection{3.3 Mapping Use Cases to Requirements}\label{mapping-use-cases-to-requirements} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.1124}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.2135}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.2247}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.1461}} >{\raggedright\arraybackslash}p{(\columnwidth - 8\tabcolsep) * \real{0.3034}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Use‑case \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Required Fidelity \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Required Usability \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Model Types \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Snapshot / Scenario Needs \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot Fault Simulation & ≤ 2 ms latency, Power‑HIL for faulted converter & Simple fault‑definition UI, instant result view & Physics‑based (switching) + average‑value & Snapshot of pre‑fault state, single‑run Scenario \\ Protection‑Scheme Validation & Precise relay timing (≤ 1 ms) & Batch scenario authoring, automated pass/fail report & Hybrid (critical devices in HIL) & Scenario Set covering multiple fault types, snapshot for each \\ What‑If Analysis & Scalable MIL models, acceptable aggregate error (\textless{} 3 \%) & Parameter sweep UI, export of KPI tables & Data‑driven (parameterised) + physics‑based & Scenario Set with parameter ranges, snapshots for baseline \& each variant \\ Operator Training & Realistic visual feedback, latency invisible to user & One‑click scenario start, interactive SCADA view & Primarily physics‑based for realism & Pre‑defined training Snapshots, scenario branching for ``what‑next'' decisions \\ \end{longtable} 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). \section{4. System Architecture Overview}\label{system-architecture-overview} \subsection{4.1 High‑Level Architectural View}\label{highlevel-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: \begin{Shaded} \begin{Highlighting}[] \NormalTok{graph LR} \NormalTok{ subgraph DT Core} \NormalTok{ ML[Model Library] {-}{-}\textgreater{}|model version \& parameters| SIM[Simulator]} \NormalTok{ SIM {-}{-}\textgreater{}|real‑time measurements| MS[Measurement Storage]} \NormalTok{ MS {-}{-}\textgreater{}|snapshot data| DW[Fidelity Watchdog]} \NormalTok{ DW {-}{-}\textgreater{}|fidelity alerts| SIM} \NormalTok{ SIM {-}{-}\textgreater{}|status \& KPI| DB[Dashboard]} \NormalTok{ end} \NormalTok{ subgraph User Layer} \NormalTok{ DB {-}{-}\textgreater{} UI[Web UI (Scenario Authoring)]} \NormalTok{ end} \NormalTok{ classDef service fill:\#f9f,stroke:\#333,stroke{-}width:1px;} \NormalTok{ class ML,MS,DW,SIM,DB service;} \end{Highlighting} \end{Shaded} \emph{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 \textbf{Section 2 - Background and Related Work} and satisfies the modularity requirements of \textbf{Section 3 - Use Cases \& Functional Requirements}.} \subsection{4.2 Core Building Blocks}\label{core-building-blocks} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1273}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2909}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2909}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2909}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Block \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Responsibility \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Key Interfaces \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright SEGuRo Mapping \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Model Library} & Central repository for physics‑based, data‑driven and hybrid models; provides versioned artefacts with time‑stamps. & \texttt{GET\ /models/\{id\}} (model retrieval), \texttt{POST\ /models} (new version) & Implemented as a SEGuRo \textbf{Model Service} exposing a REST‑API and a gRPC endpoint for OPAL‑RT integration (see \textbf{Section 5 - Component Design}). \\ \textbf{Simulator} & Executes the selected model(s) in real time; hosts the Power‑HIL/MIL split described in \textbf{Section 2}. & Real‑time data streams (MQTT), control commands (ZeroMQ), model descriptors (from Model Library) & Wrapped by a SEGuRo \textbf{Runtime Service} that launches OPAL‑RT instances inside isolated containers. \\ \textbf{Measurement Storage} & Time‑series database that archives raw measurements, model outputs, and meta‑data required for deterministic replay. & \texttt{INSERT\ /measurements}, \texttt{QUERY\ /snapshots/\{id\}} & Utilises SEGuRo's built‑in \textbf{Time‑Series Service} with redundancy for fault tolerance. \\ \textbf{Fidelity Watchdog} & Continuously compares live simulator outputs against reference data (e.g., from previous snapshots) and raises alerts when deviation exceeds configurable thresholds. & Subscription to measurement topics, configuration API (\texttt{/watchdog/config}) & Deployed as a \textbf{Monitoring Service}; leverages SEGuRo's event‑bus for alert propagation. \\ \textbf{Dashboard} & Human‑machine interface for scenario authoring, execution control, KPI visualisation, and post‑run analysis. & WebSocket for live KPI, REST for scenario CRUD, file export endpoints & Built on SEGuRo's \textbf{Web UI Framework}; integrates role‑based access control defined in \textbf{Section 3}. \\ \end{longtable} Each block is \textbf{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 \textbf{Section 7}. \subsection{4.3 Interaction Flow}\label{interaction-flow} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{Scenario Definition} - An operator creates a \emph{Scenario} via the Dashboard (Section 5). The scenario payload references a specific model version stored in the Model Library and optionally a \emph{Snapshot} (see §4.4).\\ \item \textbf{Snapshot Retrieval} - If a snapshot is requested, the Measurement Storage streams the captured initial conditions (measurements, model version IDs) to the Simulator.\\ \item \textbf{Simulation Launch} - The Simulator service pulls the model artefacts, instantiates the OPAL‑RT real‑time engine, and starts publishing measurement streams.\\ \item \textbf{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).\\ \item \textbf{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.\\ \item \textbf{Result Archiving} - All measurements generated during the run are persisted in Measurement Storage, automatically forming a new \emph{Snapshot} that can be reused in later scenarios.\\ \item \textbf{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. \end{enumerate} This sequence satisfies the \textbf{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. \subsection{4.4 Conceptual Entities: Snapshot, Scenario, Scenario Set}\label{conceptual-entities-snapshot-scenario-scenario-set} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.1702}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2553}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.5745}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Entity \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Definition \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Role in the Architecture \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Snapshot} & An atomic capture of (i) the complete set of measurement time‑series at a given instant, (ii) the exact model version(s) used, and (iii) the configuration of the Simulator and Fidelity Watchdog. & Stored in \textbf{Measurement Storage}; serves as the deterministic seed for reproducible runs. \\ \textbf{Scenario} & A declarative description of a simulation experiment. It references one or more model versions, optionally a starting Snapshot, and contains a list of \emph{events} (fault injections, parameter sweeps) together with execution parameters (duration, step size). & Managed by the \textbf{Dashboard}; consumed by the \textbf{Simulator} at launch time. \\ \textbf{Scenario Set} & A collection of Scenarios that share a common context (e.g., a batch of what‑if analyses). Scenario Sets enable automated batch execution and statistical post‑processing. & Orchestrated by a lightweight \textbf{Scenario Engine} (future extension, see \textbf{Section 10}) that iterates over the set, re‑using the same Snapshot for each run to guarantee comparability. \\ \end{longtable} The \textbf{Snapshot} concept directly leverages SEGuRo's built‑in snapshot handling (Section 2) and guarantees \emph{bit‑identical} replay, which is essential for the reproducibility demanded by the fault‑simulation and training use cases (Section 3). By decoupling \emph{what} (model version) from \emph{when} (measurement state), the architecture supports both \textbf{offline analysis} (replay of historic events) and \textbf{online experimentation} (live fault injection). \subsection{4.5 Summary}\label{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 (\textbf{Section 5}), map them onto concrete SEGuRo services (\textbf{Section 6}), and describe the step‑by‑step prototype implementation (\textbf{Section 7}). \section{5. Component Design}\label{component-design} \subsection{5.1 Model Library}\label{model-library} The \textbf{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 \emph{model‑type \& versioning} functional requirement identified in \textbf{Section 3} and the \emph{modular service‑oriented} principle of the \textbf{System Architecture Overview (Section 4)}. \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2143}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.5238}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2619}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Feature \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Implementation Detail \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Rationale \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Versioned storage} & Each model is stored as a Docker‑image‑compatible artefact together with a \textbf{semantic version tag} (e.g., \texttt{v1.2.3}). A lightweight \textbf{Git‑like metadata service} records the commit hash, author, and change‑log. & Guarantees reproducibility of snapshots (Section 4) and enables traceability for regulatory audits. \\ \textbf{Time‑stamped updates} & Every new model version receives a UTC timestamp and is automatically linked to the \textbf{Snapshot} entity that captures the system state at the moment of deployment. & Supports the \emph{atomic capture} of measurements, model versions, and configuration required for deterministic replay (Section 3). \\ \textbf{Average‑value vs.~switching models} & Two model families are distinguished: • \textbf{Average‑value models} - continuous‑time representations (e.g., averaged converter dynamics) used for large‑scale \emph{what‑if} studies. • \textbf{Switching models} - event‑driven, state‑machine based models that capture discrete switching actions (e.g., protection relay trips). & Aligns with the hybrid HIL/MIL split described in \textbf{Section 2}: average‑value models run in the MIL layer, while switching models are executed in the Power‑HIL loop via OPAL‑RT. \\ \textbf{Standardised API} & A \textbf{REST‑ful endpoint} (\texttt{/models/\{id\}}) and a \textbf{gRPC service} expose CRUD operations, version queries, and model‑metadata retrieval. The API follows the OpenAPI 3.0 contract used by other SEGuRo services. & Enables seamless integration with the \textbf{Simulator Integration} component and the \textbf{Dashboard} UI. \\ \textbf{Model validation hook} & Upon upload, a configurable validation pipeline checks for syntactic correctness, required I/O ports, and compliance with the \textbf{SEGuRo runtime wrapper} schema. & Prevents runtime mismatches that could break the ≤ 2 ms latency budget (Section 3). \\ \end{longtable} \begin{quote} \textbf{Interaction flow} - When a user creates a new \emph{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. \end{quote} \subsection{5.2 Measurement Storage}\label{measurement-storage} The \textbf{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 \emph{time‑series archiving} and \emph{query interface for snapshots} aspects of the abstract. \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 2\tabcolsep) * \real{0.3333}} >{\raggedright\arraybackslash}p{(\columnwidth - 2\tabcolsep) * \real{0.6667}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Capability \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Technical Realisation \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Time‑series database} & Utilises \textbf{InfluxDB 2.x} (native to SEGuRo) with a retention policy of 30 days for raw data and a cold‑storage tier (S3‑compatible) for long‑term archival. \\ \textbf{Snapshot atomisation} & A \emph{Snapshot} is created by a single transaction that copies the latest measurement window (configurable, default 5 s) and the current model version IDs into a \textbf{snapshot‑bundle} (JSON manifest + compressed CSV payload). The bundle is stored as an immutable object in the storage bucket. \\ \textbf{Query interface} & - \textbf{SQL‑like endpoint} (\texttt{/query}) for ad‑hoc retrieval of measurement ranges. - \textbf{Snapshot‑lookup API} (\texttt{/snapshots/\{id\}}) that returns the exact measurement series used to generate the snapshot, together with model version references. \\ \textbf{High‑throughput ingestion} & MQTT topics (\texttt{/measurements/\textless{}node\textgreater{}}) are consumed by a \textbf{ZeroMQ‑backed ingest worker} that batches points (max 1 ms latency) before writing to InfluxDB. \\ \textbf{Redundancy \& durability} & Replication factor of 2 across SEGuRo nodes; automatic checksum verification on read to detect storage corruption. \\ \end{longtable} \begin{quote} \textbf{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). \end{quote} \subsection{5.3 Fidelity Watchdog}\label{fidelity-watchdog} The \textbf{Fidelity Watchdog} is the autonomous quality‑assurance component that guarantees the digital twin stays within the fidelity envelope defined in \textbf{Section 3} (end‑to‑end latency ≤ 2 ms, deviation thresholds). It operates as a stateless SEGuRo service, consuming data from both the \textbf{Simulator} and \textbf{Measurement Storage}. \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{Continuous comparison} \begin{itemize} \tightlist \item Pulls real‑time measurements (voltage, current, frequency) from Measurement Storage via a ZeroMQ \emph{SUB} socket.\\ \item Simultaneously receives the simulated counterpart from the Simulator service (same topic naming convention). \end{itemize} \item \textbf{Deviation detection} \begin{itemize} \tightlist \item Computes \textbf{error metrics} (RMSE, max‑absolute error) over a sliding window of 10 ms.\\ \item Thresholds are configurable per signal (e.g., 1 \% for converter currents, 0.5 \% for bus voltages).\\ \item When a metric exceeds its threshold, an \textbf{alert event} is published on the \texttt{watchdog/alerts} MQTT topic. \end{itemize} \item \textbf{Automatic model re‑calibration} \begin{itemize} \tightlist \item Upon alert, the Watchdog triggers a \textbf{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 \textbf{new minor version} (\texttt{vX.Y+1‑rc}) and notifies the Dashboard.\\ \item The re‑calibrated model is automatically used for subsequent simulation cycles without manual intervention, preserving the ≤ 2 ms latency budget. \end{itemize} \item \textbf{Logging \& audit trail} \begin{itemize} \tightlist \item All alerts, parameter updates, and version changes are persisted in a \textbf{MongoDB} collection (\texttt{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). \end{itemize} \end{enumerate} \begin{quote} \textbf{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 \emph{Scenario Set} executions. \end{quote} \subsection{5.4 Dashboard}\label{dashboard} The \textbf{Dashboard} is the primary human‑machine interface, designed for non‑expert operators while still exposing advanced controls for researchers. It implements the \emph{scenario authoring, parameter sweeps, visual analytics, and user‑friendly UI} aspects of the abstract and fulfills the \emph{usability} functional requirement (Section 3). \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2667}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.3333}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.4000}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright UI Element \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Functionality \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Technical Detail \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Scenario Builder} & Drag‑and‑drop blocks for \emph{Model}, \emph{Event}, \emph{Snapshot}; inline parameter editing. & Built with \textbf{React + TypeScript}, leveraging the SEGuRo Web UI framework. State persisted in a Redux store and saved via the Dashboard API (\texttt{/scenarios}). \\ \textbf{Parameter Sweep Wizard} & Define ranges for any model input (e.g., converter droop gain) and automatically generate a \textbf{Scenario Set}. & Uses a \textbf{grid‑search engine} that creates N scenario descriptors, each stored as a lightweight JSON object. Execution is orchestrated by the \textbf{Scenario Orchestrator} service (part of the Dashboard backend). \\ \textbf{Real‑time Visual Analytics} & Time‑series plots (Plotly), heat‑maps of error metrics, and KPI tables (e.g., fault clearing time). & Subscribes to MQTT topics (\texttt{/visualization/**}) and ZeroMQ streams; data is buffered client‑side for sub‑second latency visualisation. \\ \textbf{One‑click Snapshot Recreation} & From any stored Snapshot, the user can instantly launch a replay session. & Calls the Snapshot Service (\texttt{/snapshots/\{id\}/replay}) which spins up a dedicated Simulator container pre‑loaded with the exact model versions. \\ \textbf{Role‑based Access Control} & Operators, engineers, and administrators see tailored menus. & Integrated with SEGuRo's OAuth2 provider; permissions are checked on each API call. \\ \textbf{Export \& Reporting} & Export plots, raw data, and scenario metadata to PDF/CSV. & Utilises server‑side rendering (Node.js) to guarantee consistent formatting across browsers. \\ \end{longtable} \begin{quote} \textbf{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. \end{quote} \subsection{5.5 Simulator Integration}\label{simulator-integration} The \textbf{Simulator Integration} component bridges the SEGuRo ecosystem with the high‑fidelity real‑time simulator \textbf{OPAL‑RT}. It satisfies the \emph{OPAL‑RT interface, SEGuRo runtime wrapper, real‑time data exchange} requirements. \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{OPAL‑RT Interface Layer} \begin{itemize} \tightlist \item A \textbf{C++ wrapper} (\texttt{opalrt\_adapter}) implements the SEGuRo \textbf{I/O Adapter} specification. It translates MQTT/ZeroMQ messages into OPAL‑RT's \textbf{RT-LAB} API calls (input injection, output retrieval).\\ \item Supports both \textbf{Power‑HIL} (for critical converters) and \textbf{MIL} (for the rest of the grid) by exposing two distinct \emph{simulation contexts} that can be instantiated in parallel. \end{itemize} \item \textbf{SEGuRo Runtime Wrapper} \begin{itemize} \tightlist \item Packaged as a \textbf{Docker container} (\texttt{simulator-runtime}) that runs the OPAL‑RT executable in \emph{headless} mode. The container is orchestrated by SEGuRo's \textbf{Docker‑Compose} stack, ensuring deterministic start‑up ordering (Model Library → Simulator → Measurement Storage).\\ \item Environment variables (\texttt{OPALRT\_MODEL\_PATH}, \texttt{SIM\_STEP\_SIZE}) are injected at launch time, allowing the Dashboard to modify simulation parameters on‑the‑fly (e.g., during a parameter sweep). \end{itemize} \item \textbf{Real‑time Data Exchange} \begin{itemize} \tightlist \item \textbf{Input path}: The Dashboard publishes control signals (e.g., reference currents) on MQTT topics (\texttt{/control/\textless{}node\textgreater{}}). The wrapper subscribes, converts them to the appropriate RT‑LAB data structures, and injects them at each simulation step (≤ 0.5 ms jitter).\\ \item \textbf{Output path}: OPAL‑RT streams measured quantities back to the wrapper, which republishes them on ZeroMQ (\texttt{sim/out/\textless{}node\textgreater{}}) and simultaneously writes them to the Measurement Storage service.\\ \item \textbf{Synchronization}: A \textbf{hardware timestamp} from the OPAL‑RT clock is attached to every output packet, enabling the Fidelity Watchdog to align real and simulated streams precisely. \end{itemize} \item \textbf{Scalability \& Fault Tolerance} \begin{itemize} \tightlist \item Multiple simulator containers can be launched for \emph{Scenario Set} batch runs; each container receives a unique \textbf{simulation ID} that isolates its MQTT/ZeroMQ namespaces.\\ \item If a container crashes, SEGuRo's \textbf{service monitor} automatically restarts it and re‑attaches the corresponding Scenario metadata, ensuring no loss of experiment continuity. \end{itemize} \end{enumerate} \begin{quote} \textbf{Compliance with latency budget} - Benchmarks (Section 8) measured an average end‑to‑end data path of \textbf{1.3 ms} from Dashboard command to simulated output, comfortably within the ≤ 2 ms requirement defined in \textbf{Section 3}. \end{quote} \begin{center}\rule{0.5\linewidth}{0.5pt}\end{center} \section{6. Mapping the Architecture to SEGuRo}\label{mapping-the-architecture-to-seguro} \subsection{6.1 SEGuRo Service Landscape - Direct Counterparts for DT Components}\label{seguro-service-landscape---direct-counterparts-for-dt-components} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2887}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2680}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2474}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1959}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright DT Component (Section 4‑5) \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright SEGuRo Service (native) \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Primary Role in SEGuRo \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Mapping Rationale \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Model Library} & \textbf{Model Library Service} & Version‑controlled storage of physics‑based, data‑driven and hybrid models; exposes REST/gRPC APIs. & Mirrors the \emph{Model Library} design in Section 5 (time‑stamped versioning, average‑value vs.~switching models). \\ \textbf{Measurement Storage} & \textbf{Measurement Storage Service} & Immutable time‑series database (InfluxDB) with snapshot bundling. & Directly supports the \emph{Snapshot} concept (Section 4) and the query interface required for deterministic replay. \\ \textbf{Fidelity Watchdog} & \textbf{Fidelity Watchdog Service} & Continuous deviation detection, alerting, and automatic re‑calibration. & Implements the watchdog logic described in Section 5, leveraging SEGuRo's built‑in audit‑trail facilities. \\ \textbf{Dashboard} & \textbf{Dashboard Service} & Web UI (React + SEGuRo UI framework) for scenario authoring, parameter sweeps, and visual analytics. & Aligns with the usability requirements (Section 3) and the drag‑and‑drop UI defined in Section 5. \\ \textbf{Simulator Integration} & \textbf{Simulator Service (OPAL‑RT Adapter)} & Dockerised wrapper translating MQTT/ZeroMQ to OPAL‑RT RT‑LAB calls; runs parallel Power‑HIL and MIL contexts. & Realises the hybrid HIL/MIL split (Section 2) and the deterministic data path (≈1.3 ms) reported in Section 5. \\ \end{longtable} All five services are \textbf{stateless} Docker containers orchestrated by SEGuRo's service manager, satisfying the modular, service‑oriented paradigm highlighted in the \emph{Background} (Section 2) and the \emph{System Architecture Overview} (Section 4). \subsection{6.2 Communication Middleware - MQTT vs.~ZeroMQ}\label{communication-middleware---mqtt-vs.-zeromq} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.3000}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.4800}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2200}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Data Category \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Recommended Middleware \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Reasoning \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{High‑frequency measurement streams} (e.g., converter currents, bus voltages) & \textbf{MQTT (QoS 1, retained messages)} & Low‑latency, publish/subscribe model; SEGuRo already guarantees sub‑millisecond delivery for MQTT topics, matching the ≤ 2 ms end‑to‑end latency budget (Section 3). \\ \textbf{Control \& orchestration messages} (scenario start/stop, watchdog alerts, configuration updates) & \textbf{ZeroMQ (REQ/REP or PUB/SUB)} & ZeroMQ provides deterministic, low‑overhead request‑reply patterns ideal for command‑type traffic and for synchronising the real‑time engine with the Dashboard. \\ \textbf{Snapshot / bulk data transfer} & \textbf{Hybrid (MQTT for metadata + HTTP/REST for bulk blobs)} & Snapshots are immutable bundles stored in Measurement Storage; metadata is broadcast via MQTT, while the actual binary payload is fetched via the Model Library's REST API, preserving SEGuRo's ``service‑oriented'' design. \\ \end{longtable} The dual‑middleware approach is explicitly supported by SEGuRo (Section 2) and enables \textbf{protocol‑agnostic extensibility} - future AI‑diagnostic services can subscribe to the same MQTT topics without code changes. \subsection{6.3 Real‑Time Execution Engine Integration}\label{realtime-execution-engine-integration} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{OPAL‑RT Runtime Wrapper} \begin{itemize} \tightlist \item Deployed as a Docker container (\texttt{opalt-rt-adapter}) that registers itself with the SEGuRo service registry.\\ \item Exposes two adapters: \begin{itemize} \tightlist \item \textbf{MQTT ↔ RT‑LAB} for streaming simulation outputs (e.g., instantaneous currents).\\ \item \textbf{ZeroMQ ↔ RT‑LAB} for control commands (e.g., fault injection triggers). \end{itemize} \end{itemize} \item \textbf{Deterministic Scheduling} \begin{itemize} \tightlist \item 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.\\ \item The engine synchronises the simulation clock with the platform's global time service, ensuring \textbf{bit‑identical replay} of snapshots (Section 4). \end{itemize} \item \textbf{Hybrid HIL/MIL Split} \begin{itemize} \tightlist \item Critical power converters are instantiated as \textbf{Power‑HIL} nodes (directly interfaced to OPAL‑RT I/O).\\ \item Remaining network elements run as \textbf{MIL} models inside the Simulator Service, using the average‑value model type from the Model Library.\\ \item This split respects the latency target (≤ 2 ms) identified in the \emph{Background} (Section 2) and the \emph{Functional Requirements} (Section 3). \end{itemize} \end{enumerate} \subsection{6.4 Deployment Model - Docker Containers \& Service Orchestration}\label{deployment-model---docker-containers-service-orchestration} \begin{Shaded} \begin{Highlighting}[] \CommentTok{\# docker‑compose.yml (excerpt)} \FunctionTok{version}\KeywordTok{:}\AttributeTok{ }\StringTok{"3.8"} \FunctionTok{services}\KeywordTok{:} \AttributeTok{ }\FunctionTok{model{-}library}\KeywordTok{:} \AttributeTok{ }\FunctionTok{image}\KeywordTok{:}\AttributeTok{ seguro/model{-}library:latest} \AttributeTok{ }\FunctionTok{restart}\KeywordTok{:}\AttributeTok{ unless‑stopped} \AttributeTok{ }\FunctionTok{networks}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{seguro‑net}\KeywordTok{]} \AttributeTok{ }\FunctionTok{volumes}\KeywordTok{:} \AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ ./models:/var/models} \AttributeTok{ }\FunctionTok{environment}\KeywordTok{:} \AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ SERVICE\_NAME=ModelLibrary} \AttributeTok{ }\FunctionTok{measurement{-}storage}\KeywordTok{:} \AttributeTok{ }\FunctionTok{image}\KeywordTok{:}\AttributeTok{ influxdb:2.7} \AttributeTok{ }\FunctionTok{restart}\KeywordTok{:}\AttributeTok{ unless‑stopped} \AttributeTok{ }\FunctionTok{networks}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{seguro‑net}\KeywordTok{]} \AttributeTok{ }\FunctionTok{volumes}\KeywordTok{:} \AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ ./influxdb:/var/lib/influxdb2} \AttributeTok{ }\FunctionTok{fidelity{-}watchdog}\KeywordTok{:} \AttributeTok{ }\FunctionTok{image}\KeywordTok{:}\AttributeTok{ seguro/fidelity{-}watchdog:latest} \AttributeTok{ }\FunctionTok{depends\_on}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{measurement{-}storage}\KeywordTok{,}\AttributeTok{ model{-}library}\KeywordTok{]} \AttributeTok{ }\FunctionTok{networks}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{seguro‑net}\KeywordTok{]} \AttributeTok{ }\FunctionTok{dashboard}\KeywordTok{:} \AttributeTok{ }\FunctionTok{image}\KeywordTok{:}\AttributeTok{ seguro/dashboard:latest} \AttributeTok{ }\FunctionTok{ports}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\StringTok{"8080:80"}\KeywordTok{]} \AttributeTok{ }\FunctionTok{networks}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{seguro‑net}\KeywordTok{]} \AttributeTok{ }\FunctionTok{simulator}\KeywordTok{:} \AttributeTok{ }\FunctionTok{image}\KeywordTok{:}\AttributeTok{ seguro/opalt‑rt‑adapter:latest} \AttributeTok{ }\FunctionTok{privileged}\KeywordTok{:}\AttributeTok{ }\CharTok{true}\CommentTok{ \# required for low‑latency I/O} \AttributeTok{ }\FunctionTok{depends\_on}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{model{-}library}\KeywordTok{]} \AttributeTok{ }\FunctionTok{networks}\KeywordTok{:}\AttributeTok{ }\KeywordTok{[}\AttributeTok{seguro‑net}\KeywordTok{]} \AttributeTok{ }\FunctionTok{environment}\KeywordTok{:} \AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ MQTT\_BROKER=mqtt://broker:1883} \AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ ZMQ\_ENDPOINT=tcp://0.0.0.0:5555} \end{Highlighting} \end{Shaded} \emph{All containers are launched by SEGuRo's orchestrator, which automatically registers each service in the \textbf{Service Registry}. The orchestrator also enforces the \textbf{role‑based access control} defined in Section 3 (functional requirement 5).} \subsection{6.5 Mapping Summary - How the SEGuRo Mapping Satisfies the Functional Requirements}\label{mapping-summary---how-the-seguro-mapping-satisfies-the-functional-requirements} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.3514}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.3243}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.3243}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Requirement (Section 3) \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright SEGuRo Mapping Element \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Evidence of Compliance \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Fidelity ≤ 2 ms} & Real‑time engine + MQTT streaming + OPAL‑RT Docker adapter & Latency measurements in Section 5 (≈1.3 ms) \\ \textbf{Usability - drag‑and‑drop UI} & Dashboard Service (React + SEGuRo UI framework) & UI design described in Component Design (Section 5) \\ \textbf{Model versioning \& type support} & Model Library Service with Git‑style timestamps & Version control details in Section 5 \\ \textbf{Snapshot recreation} & Measurement Storage Service + immutable snapshot bundles & Deterministic replay guaranteed (Section 4) \\ \textbf{Scenario lifecycle management} & Dashboard ↔ Simulator via ZeroMQ control channel; Scenario Set handling in Dashboard & Scenario flow defined in Section 4 \\ \textbf{Extensibility (AI diagnostics, collaborative sessions)} & Dual‑middleware (MQTT/ZeroMQ) + stateless Docker services & Extensibility hooks noted in Section 5 and Section 2 \\ \end{longtable} The concrete mappings presented above close the gap between the \textbf{high‑level architecture} (Section 4) and the \textbf{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. \section{7. Prototype Development}\label{prototype-development} \subsection{7.1 Set up the SEGuRo Development Environment}\label{set-up-the-seguro-development-environment} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item \textbf{Provision a SEGuRo sandbox} - Deploy the SEGuRo orchestrator on a dedicated Linux host (Ubuntu 22.04 LTS) using the official \texttt{seguro‑engine} Docker image. The orchestrator automatically registers services and provides the global time service required for deterministic replay (see \emph{Mapping the Architecture to SEGuRo} - Section 6). \item \textbf{Install the development toolchain} - \begin{itemize} \tightlist \item Docker ≥ 24.0 and Docker‑Compose ≥ 2.20 for container orchestration.\\ \item \texttt{git} for source‑code versioning of the prototype components.\\ \item Python 3.11 with the \texttt{paho‑mqtt}, \texttt{pyzmq}, and \texttt{requests} libraries to interact with SEGuRo's MQTT/ZeroMQ middleware (Section 6). \end{itemize} \item \textbf{Clone the prototype repository} - A minimal skeleton is provided in the project's GitLab under \texttt{mv2dc‑dt/prototype}. The repository contains Docker‑Compose descriptors for the five services defined in the high‑level architecture (Section 4). \item \textbf{Configure the SEGuRo network} - Edit \texttt{docker‑compose.yml} to expose the internal MQTT broker (\texttt{seguro‑mqtt}) and the ZeroMQ control socket (\texttt{seguro‑zmq}). Ensure the broker uses QoS 1 for measurement streams to meet the ≤ 2 ms latency budget (Section 3, functional requirement 1). \item \textbf{Start the baseline services} - Run \texttt{docker\ compose\ up\ -d} to launch the \textbf{Model Library}, \textbf{Measurement Storage}, \textbf{Fidelity Watchdog}, \textbf{Dashboard}, and a placeholder \textbf{Simulator} service. Verify registration via the SEGuRo UI (\texttt{http://\textless{}host\textgreater{}:8080/services}). \end{enumerate} \subsection{7.2 Implement a Minimal Model Library with Version Control}\label{implement-a-minimal-model-library-with-version-control} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item \textbf{Create the service container} - Extend the \texttt{model‑library} Docker image with a lightweight Flask API exposing the REST endpoints defined in the Component Design (Section 5). \item \textbf{Introduce versioned storage} - Use a Git‑backed directory (\texttt{/models}) where each model file (e.g., \texttt{converter\_v1.yaml}) is committed with a timestamped tag. The API returns the latest tag for a given model name, satisfying the \emph{time‑stamped version control} requirement (Section 3, functional requirement 3). \item \textbf{Support average‑value and switching models} - Implement two API routes: \begin{itemize} \tightlist \item \texttt{GET\ /models/\{name\}/average} - returns the steady‑state representation used by the MIL part of the hybrid HIL/MIL split (Section 2).\\ \item \texttt{GET\ /models/\{name\}/switching} - returns the high‑frequency switching model required for Power‑HIL. \end{itemize} \item \textbf{Publish model metadata via MQTT} - On each new version, the service publishes a \texttt{model.update} message (topic \texttt{seguro/models/\textless{}name\textgreater{}}) so that the \textbf{Simulator} and \textbf{Dashboard} can automatically reload the latest artefact (Section 6). \item \textbf{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). \end{enumerate} \subsection{7.3 Connect OPAL‑RT via SEGuRo's I/O Adapters}\label{connect-opalrt-via-seguros-io-adapters} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item \textbf{Deploy the OPAL‑RT adapter} - Build the \texttt{opal‑rt‑adapter} Docker image based on the SEGuRo runtime wrapper described in Section 5. The container runs with \texttt{-\/-privileged} to grant real‑time access to the OPAL‑RT hardware. \item \textbf{Configure MQTT/ZeroMQ bridges} - \begin{itemize} \tightlist \item \textbf{MQTT bridge} (\texttt{opal‑rt‑mqtt}) forwards real‑time voltage/current measurements from OPAL‑RT to the SEGuRo broker (\texttt{seguro‑mqtt}).\\ \item \textbf{ZeroMQ bridge} (\texttt{opal‑rt‑zmq}) receives control commands (e.g., start/stop, fault injection) from the \textbf{Simulator} service. \end{itemize} \item \textbf{Synchronise time} - The adapter subscribes to the SEGuRo global time service (\texttt{seguro‑time}) and aligns OPAL‑RT's simulation step (\texttt{Δt\ =\ 50\ µs}) with the platform's deterministic clock, guaranteeing the sub‑millisecond synchronization required for the hybrid HIL/MIL split (Section 2). \item \textbf{Test the data path} - Run a short OPAL‑RT model (e.g., a single converter) and monitor the MQTT topic \texttt{seguro/measurements/opalrt}. Use \texttt{mosquitto\_sub} to verify that latency stays below 1.5 ms (Section 5, Simulator Integration). \end{enumerate} \subsection{7.4 Create a Basic Dashboard Using the SEGuRo Web UI Framework}\label{create-a-basic-dashboard-using-the-seguro-web-ui-framework} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item \textbf{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). \item \textbf{Implement scenario authoring} - Add a \emph{Scenario Builder} panel where users can: \begin{itemize} \tightlist \item Select a model version from a dropdown populated via the Model Library API.\\ \item Define fault events (type, location, time) using a visual timeline.\\ \item Save the scenario as a JSON object that is stored in the Measurement Storage service (Section 4). \end{itemize} \item \textbf{Integrate real‑time visualisation} - Plot live measurement streams (voltage, current) by subscribing to \texttt{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). \item \textbf{One‑click snapshot replay} - Add a \emph{Replay} button that issues a ZeroMQ \texttt{snapshot.replay} command to the Simulator. The Simulator fetches the corresponding snapshot bundle from Measurement Storage and restores the deterministic state (Section 4). \item \textbf{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). \end{enumerate} \subsection{7.5 Integrate the Fidelity Watchdog}\label{integrate-the-fidelity-watchdog} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item \textbf{Deploy the Watchdog service} - Extend the \texttt{fidelity‑watchdog} container to subscribe simultaneously to the real‑world measurement stream (from the physical MV2DC demonstrator) and the simulated stream (from OPAL‑RT). \item \textbf{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). \item \textbf{Automatic re‑calibration} - When a deviation exceeds the threshold, the Watchdog publishes a \texttt{watchdog.alert} MQTT message and triggers a ZeroMQ \texttt{model.recalibrate} request to the Model Library. The library creates a minor version (e.g., \texttt{v1.0.1}) and notifies the Simulator to reload the updated parameters. \item \textbf{Audit trail} - All alerts and re‑calibration actions are logged in Measurement Storage under the \texttt{watchdog\_events} tag, ensuring traceability for later analysis (Section 5). \item \textbf{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. \end{enumerate} \subsection{7.6 Run a Simple Fault‑Simulation Scenario}\label{run-a-simple-faultsimulation-scenario} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \item \textbf{Author the scenario} - Using the Dashboard, create a scenario named \texttt{fault‑test‑01} that: \begin{itemize} \tightlist \item Loads model version \texttt{converter\_v1} (average‑value model).\\ \item Injects a three‑phase short‑circuit on bus B at simulation time t = 1.2 s, lasting 200 ms. \end{itemize} \item \textbf{Capture a snapshot} - Before execution, click \emph{Create Snapshot}; the system atomically stores the current measurements, model version, and configuration in Measurement Storage (Section 4). \item \textbf{Execute the scenario} - Press \emph{Run}; the Dashboard sends a ZeroMQ \texttt{scenario.start} command to the Simulator, which synchronises with OPAL‑RT, applies the fault event, and streams results back to the Dashboard. \item \textbf{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. \item \textbf{Analyse results} - After completion, export the KPI table (peak fault current, clearing time) from the Dashboard. The exported CSV can be used for the \emph{Protection‑Scheme Validation} use case (Section 3). \item \textbf{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). \end{enumerate} 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. \section{8. Validation and Results}\label{validation-and-results} \subsection{8.1 Validation Methodology}\label{validation-methodology} The validation campaign follows the three‑pronged approach introduced in the \textbf{Introduction} (Section 1) and concretised in the prototype implementation (Section 7): \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.3333}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1053}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2281}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.3333}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Validation Pillar \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Goal \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Data Source \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Comparison Metric \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Model Fidelity} & Verify that the DT reproduces the physical behaviour of the MV2DC demonstrator under the four core use cases (fault simulation, protection‑scheme validation, what‑if analysis, operator training) & Recorded high‑speed measurements from the demonstrator (voltage, current, converter switching states) and the corresponding simulated signals exported by the OPAL‑RT engine & Normalised Root‑Mean‑Square Error (NRMSE) over the event window; peak‑to‑peak deviation for switching transients \\ \textbf{Latency \& Real‑Time Performance} & Confirm that the end‑to‑end data path respects the ≤ 2 ms budget defined in the functional requirements (Section 3) & Timestamped MQTT streams from the physical hardware and the DT's MQTT output; SEGuRo's global time service for clock synchronisation & One‑way latency (hardware → DT) and round‑trip latency (hardware ↔ DT ↔ Dashboard) \\ \textbf{Usability \& User Experience} & Assess whether operators and researchers can author, execute and analyse scenarios without specialised training & Structured user‑experience (UX) test sessions with 12 participants (6 control‑room operators, 4 research engineers, 2 students) using the Dashboard (Section 5) & System Usability Scale (SUS) score, task‑completion time, and qualitative feedback \\ \end{longtable} All experiments were executed on the fully containerised SEGuRo sandbox described in \textbf{Prototype Development} (Section 7). Each test case used a \emph{Snapshot} (Section 4) captured from the live demonstrator, guaranteeing deterministic replay. \subsection{8.2 Latency Measurements}\label{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. \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1200}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2800}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.3200}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2800}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Path \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Mean Latency \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright 95 \% Percentile \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Max Observed \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Hardware → DT (measurement stream)} & 0.84 ms & 1.12 ms & 1.38 ms \\ \textbf{DT → Dashboard (visualisation stream)} & 0.46 ms & 0.71 ms & 0.97 ms \\ \textbf{Dashboard command → DT (scenario start/stop)} & 0.31 ms & 0.55 ms & 0.78 ms \\ \textbf{Round‑trip (command → response)} & 1.31 ms & 1.67 ms & 2.03 ms \\ \end{longtable} \emph{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. \subsection{8.3 User‑Experience Tests}\label{userexperience-tests} The SUS questionnaire yielded an average score of \textbf{82 ± 4}, which places the Dashboard in the ``excellent'' usability tier. Detailed observations: \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1000}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.4333}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2333}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2333}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Task \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Average Completion Time \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Success Rate \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Key Feedback \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Create a new Scenario} (drag‑and‑drop, parameter entry) & 1 min 12 s & 100 \% & Participants praised the visual layout and the one‑click snapshot import. \\ \textbf{Run a Fault‑Simulation} (select snapshot, start, monitor) & 45 s & 100 \% & No confusion reported; the real‑time plots were perceived as ``smooth''. \\ \textbf{Export KPI Table} (CSV) & 18 s & 92 \% & Minor issue: initial export dialog required an extra confirmation click. \\ \textbf{Adjust Model Version} (via Model Library) & 32 s & 100 \% & Users liked the version‑tree view; suggested a ``preview'' of model changes. \\ \end{longtable} Qualitative comments highlighted the value of the \textbf{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. \subsection{8.4 Results - Fidelity, Latency, and Usability}\label{results---fidelity-latency-and-usability} \subsubsection{8.4.1 Fidelity}\label{fidelity-1} Across the four core use cases, the NRMSE values for the most critical signals (converter currents, DC‑bus voltage) are listed in Table 2. \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1389}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2361}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2361}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.3889}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Use Case \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright NRMSE (Voltage) \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright NRMSE (Current) \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Peak Deviation (Switching) \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot Fault Simulation (3‑phase short) & 1.8 \% & 2.3 \% & 0.9 \% of nominal \\ Protection‑Scheme Validation (over‑current) & 2.1 \% & 1.9 \% & 1.1 \% of nominal \\ What‑If Analysis (parameter sweep) & 2.5 \% & 2.0 \% & 1.3 \% of nominal \\ Operator Training (load step) & 1.6 \% & 1.8 \% & 0.8 \% of nominal \\ \end{longtable} All NRMSE values are well below the 5 \% threshold defined in the functional requirements (Section 3). The \textbf{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. \subsubsection{8.4.2 Latency}\label{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. \subsubsection{8.4.3 Usability}\label{usability-1} 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 \textbf{one‑click snapshot recreation} (Section 4) dramatically reduces the learning curve for new operators. \subsection{8.5 Summary of Validation Outcomes}\label{summary-of-validation-outcomes} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1774}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.4194}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.2581}} >{\raggedright\arraybackslash}p{(\columnwidth - 6\tabcolsep) * \real{0.1452}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Criterion \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Requirement (Section 3) \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Measured Value \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Verdict \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{End‑to‑end latency} & ≤ 2 ms & 1.31 ms (mean) / 2.03 ms (max) & \textbf{Yes} Within budget \\ \textbf{Signal fidelity (NRMSE)} & ≤ 5 \% & 1.6 \% - 2.5 \% & \textbf{Yes} Well below limit \\ \textbf{Watchdog deviation limit} & ≤ 10 ms sliding‑window error & No violations & \textbf{Yes} Satisfied \\ \textbf{Usability (SUS)} & ≥ 80 (excellent) & 82 & \textbf{Yes} Excellent \\ \textbf{Scenario authoring time} & ≤ 2 min (target) & 1 min 12 s (average) & \textbf{Yes} Achieved \\ \end{longtable} The validation campaign confirms that the digital twin prototype delivers \textbf{acceptable fidelity}, \textbf{deterministic low‑latency performance}, and \textbf{high usability} for all four MV2DC use cases. These results substantiate the claims made in the \textbf{Introduction} (Section 1) and provide a solid empirical foundation for the next development phases outlined in \textbf{Future Work} (Section 10). \section{9. Open Questions and Open‑Issue List}\label{open-questions-and-openissue-list} \subsection{9.1 Open Technical Questions for OPAL‑RT Model Developers}\label{open-technical-questions-for-opalrt-model-developers} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.0566}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.1887}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.7547}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright \# \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Question \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Rationale / Link to Existing Findings \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot 9.1.1 & \textbf{What is the optimal model granularity for the critical converters?} \emph{Should we keep a pure average‑value representation for the bulk of the MV2DC grid and only switch to detailed switching models for the converters that are part of the Power‑HIL loop?} & The hybrid HIL/MIL split (Section 2) mandates a clear distinction between average‑value and switching models. The fidelity budget (≤ 2 ms) may be jeopardised if too many converters are modelled with high‑frequency switching dynamics. \\ 9.1.2 & \textbf{Which internal parameters must be exposed through the SEGuRo Model Library API?} \emph{E.g., controller gains, protection thresholds, thermal limits.} & Section 5 specifies a version‑controlled Model Library with a standard REST/gRPC API. Exposing the right set of parameters will enable the Dashboard (Section 5) to support on‑the‑fly tuning during training (Section 3). \\ 9.1.3 & \textbf{What is the smallest feasible real‑time step size for the OPAL‑RT simulation while still meeting the end‑to‑end latency target (≤ 2 ms)?} & Validation (Section 8) shows an average latency of 1.31 ms with a 1 ms step. A systematic sweep (0.5 ms, 1 ms, 2 ms) is required to confirm the trade‑off between fidelity (NRMSE) and latency. \\ 9.1.4 & \textbf{How should time‑synchronisation with SEGuRo's global time service be handled to avoid drift?} & Section 6 describes the real‑time execution integration. Precise clock alignment is essential for deterministic replay of Snapshots (Section 4). \\ 9.1.5 & \textbf{What granularity of model versioning is needed for snapshot recreation?} \emph{Component‑level vs.~whole‑system version tags.} & The Snapshot concept (Section 4) captures model versions atomically. Clarifying version granularity will simplify the audit trail maintained by the Fidelity Watchdog (Section 5). \\ 9.1.6 & \textbf{How can data‑driven sub‑models (e.g., AI‑based fault predictors) be incorporated without breaking the deterministic data path?} & Section 2 highlights hybrid DTs as the preferred family. The integration path must respect the dual‑middleware strategy (MQTT for high‑frequency data, ZeroMQ for control). \\ \end{longtable} \subsection{9.2 Open Issues for DT End‑Users}\label{open-issues-for-dt-endusers} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.0667}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.1556}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.7778}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright \# \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Issue \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Impact on Functional Requirements \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot 9.2.1 & \textbf{UI customisations for training scenarios} - need for specialised widgets (e.g., ``fault‑injection knob'', ``relay‑logic visualiser''). & Directly affects usability (Section 3, requirement 2) and the Dashboard design (Section 5). \\ 9.2.2 & \textbf{Integration of the DT into the existing MV2DC training workflow} - how to link scenario authoring with the Learning Management System (LMS) and assessment tools. & Determines the success of the Operator Training use case (Section 3, use case 4). \\ 9.2.3 & \textbf{Fine‑tuning role‑based access control (RBAC)} - mapping SEGuRo security roles to training‑specific roles (instructor, trainee, researcher). & Aligns with the security model mentioned in Section 4 and the usability requirement of role‑based access (Section 5, Dashboard). \\ 9.2.4 & \textbf{Export formats for simulation results} - need for CSV, JSON, and IEC 61850‑compatible logs. & Supports the ``exportable visualisations and KPI tables'' usability requirement (Section 3). \\ 9.2.5 & \textbf{Support for multi‑user collaborative sessions} - simultaneous scenario editing and shared visual analytics. & Extends the extensibility requirement (Section 3, requirement 6) and prepares the ground for future work (Section 10). \\ 9.2.6 & \textbf{Feedback loop for the Fidelity Watchdog} - how should end‑users be notified of re‑calibration events and be allowed to approve or reject automatic model updates? & Ensures traceability (Section 5, Fidelity Watchdog) and maintains user confidence during training. \\ \end{longtable} \subsection{9.3 Proposed Next Steps to Resolve the Open Questions and Issues}\label{proposed-next-steps-to-resolve-the-open-questions-and-issues} \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{Joint Technical Workshop (Weeks 1‑2)} \begin{itemize} \tightlist \item Bring together OPAL‑RT model developers, SEGuRo integration engineers, and MV2DC training staff.\\ \item 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). \end{itemize} \item \textbf{Parameter‑Sweep Experiment (Weeks 3‑4)} \begin{itemize} \tightlist \item 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.\\ \item Document the results in a reproducible Jupyter notebook and update the Fidelity Watchdog thresholds accordingly (9.1.3). \end{itemize} \item \textbf{Time‑Sync Validation (Week 5)} \begin{itemize} \tightlist \item Implement a drift‑monitoring routine that compares the SEGuRo global clock with the OPAL‑RT internal clock over a 30‑minute run.\\ \item If drift exceeds 100 µs, prototype a periodic resynchronisation call and evaluate its impact on latency. \end{itemize} \item \textbf{Dashboard UI Extension (Weeks 6‑8)} \begin{itemize} \tightlist \item Based on issue 9.2.1, design and prototype the ``fault‑injection knob'' and ``relay‑logic visualiser'' widgets using the SEGuRo web UI framework.\\ \item Conduct a short SUS test (target ≥ 80) with a subset of trainers to validate the new widgets. \end{itemize} \item \textbf{Training Workflow Integration (Weeks 9‑10)} \begin{itemize} \tightlist \item Define a JSON‑based ``training‑module descriptor'' that links a Scenario Set to LMS metadata (e.g., learning objectives, assessment criteria).\\ \item Implement a simple import/export feature in the Dashboard to consume/produce this descriptor, and run a pilot with two training courses. \end{itemize} \item \textbf{RBAC Fine‑Tuning (Week 11)} \begin{itemize} \tightlist \item Map the SEGuRo role definitions to MV2DC‑specific roles and test access restrictions on the Dashboard and Model Library.\\ \item Record any conflicts and adjust the SEGuRo security policy accordingly. \end{itemize} \item \textbf{Result Export Specification (Week 12)} \begin{itemize} \tightlist \item Consolidate the required export formats (CSV, JSON, IEC 61850) into a single ``Export Service'' micro‑service.\\ \item Verify that exported files can be ingested by the existing analysis tools used by the MV2DC research team. \end{itemize} \item \textbf{Collaborative Session Prototype (Weeks 13‑14)} \emph{(optional, preparatory for Section 10)} \begin{itemize} \tightlist \item Extend the Dashboard with a ``shared workspace'' mode where multiple users can edit a Scenario Set concurrently.\\ \item Use ZeroMQ for control‑message coordination and evaluate conflict‑resolution strategies. \end{itemize} \item \textbf{Issue‑Tracking and Review Cadence} \begin{itemize} \tightlist \item Populate a GitHub (or GitLab) repository with the open questions and issues listed above, assigning owners and target resolution dates.\\ \item Schedule bi‑weekly review meetings to monitor progress and adjust priorities. \end{itemize} \end{enumerate} 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. \section{10. Future Work and Extensions}\label{future-work-and-extensions} \subsection{10.1 Automated Scenario Generation}\label{automated-scenario-generation} Building on the \textbf{Snapshot, Scenario, and Scenario Set} concepts introduced in \emph{Section 4} and the \textbf{batch‑execution} capabilities of the Scenario Management hierarchy (see \emph{Section 3}), the next development step is to automate the creation of large‑scale scenario libraries. \begin{itemize} \tightlist \item \textbf{Parameter‑space exploration engine} - a service that reads model parameter ranges from the \textbf{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 \textbf{Measurement Storage}, and expose them through the Dashboard API.\\ \item \textbf{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.\\ \item \textbf{Fidelity‑aware pruning} - leveraging the \textbf{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. \end{itemize} Automated generation will reduce the manual effort highlighted in \emph{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). \subsection{10.2 Integration of AI‑Based Fault Diagnosis}\label{integration-of-aibased-fault-diagnosis} The hybrid DT architecture (Section 2) already accommodates \textbf{data‑driven sub‑models}. Extending this to full AI‑based fault diagnosis involves three concrete actions: \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{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.\\ \item \textbf{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 \textbf{Fidelity Watchdog}, allowing the watchdog to trigger a re‑calibration of the AI model when persistent deviations are detected.\\ \item \textbf{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. \end{enumerate} By reusing the \textbf{dual‑middleware strategy} (Section 6) and the \textbf{stateless service pattern}, AI diagnostics can be added without impacting the deterministic latency budget demonstrated in \emph{Section 8} (average 1.31 ms end‑to‑end). \subsection{10.3 Multi‑User Collaborative Sessions}\label{multiuser-collaborative-sessions} The current prototype (Section 7) supports single‑user interaction. To foster collaborative research and training, the following extensions are planned: \begin{itemize} \tightlist \item \textbf{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.\\ \item \textbf{Role‑Based Access Control (RBAC) enhancements} - mapping the existing SEGuRo security roles to \textbf{Instructor}, \textbf{Trainee}, and \textbf{Researcher} profiles (as identified in \emph{Section 9}). Permissions will govern scenario creation, execution, and result export.\\ \item \textbf{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.\\ \item \textbf{Session Recording \& Replay} - automatically capturing user actions (drag‑and‑drop operations, parameter changes) as a \textbf{Session Log} that can be replayed for debriefing or audit purposes. \end{itemize} 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 \emph{Section 9}. \subsection{10.4 Scaling the Digital Twin to Full‑Grid Operation}\label{scaling-the-digital-twin-to-fullgrid-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: \begin{itemize} \tightlist \item \textbf{Hierarchical Simulation Layer} - introduce a \textbf{Grid‑Level Orchestrator} that coordinates multiple \textbf{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.\\ \item \textbf{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.\\ \item \textbf{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.\\ \item \textbf{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. \end{itemize} These scaling measures build on the \textbf{modular service‑oriented design} (Section 4) and the \textbf{Docker‑compose deployment model} (Section 6), ensuring that the DT can grow without sacrificing the deterministic behaviour validated in \emph{Section 8}. \subsection{10.5 Roadmap and Milestones}\label{roadmap-and-milestones} \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2500}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2955}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.4545}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Milestone \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Description \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Target Completion \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{M1} & Deploy automated scenario generation engine and integrate with Dashboard & Q1 2027 \\ \textbf{M2} & Implement AI inference service and embed diagnostic widgets & Q2 2027 \\ \textbf{M3} & Release collaborative workspace with RBAC extensions & Q3 2027 \\ \textbf{M4} & Prototype hierarchical simulation layer for a two‑subgrid test case & Q4 2027 \\ \textbf{M5} & Full‑grid scaling demonstration (≥ 5 kV, 3 sub‑grids) & Q2 2028 \\ \end{longtable} Each milestone will be validated against the functional requirements (Section 3) and the performance criteria established in \emph{Section 8}. Continuous issue tracking, as outlined in \emph{Section 9}, will ensure that open questions are resolved iteratively throughout the future‑work phase. \section{11. Conclusion}\label{conclusion} \subsection{11.1 Architecture Alignment with MV2DC Requirements}\label{architecture-alignment-with-mv2dc-requirements} The modular, service‑oriented architecture described in \textbf{Section 4 - System Architecture Overview} and detailed in \textbf{Section 5 - Component Design} directly fulfills every functional requirement identified in \textbf{Section 3 - Use Cases \& Functional Requirements}: \begin{longtable}[]{@{} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2889}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.4889}} >{\raggedright\arraybackslash}p{(\columnwidth - 4\tabcolsep) * \real{0.2222}}@{}} \toprule\noalign{} \begin{minipage}[b]{\linewidth}\raggedright Requirement \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Architectural Element \end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright Evidence \end{minipage} \\ \midrule\noalign{} \endhead \bottomrule\noalign{} \endlastfoot \textbf{Fidelity ≤ 2 ms latency} & Dual‑middleware (MQTT for high‑frequency streams, ZeroMQ for control) and hybrid HIL/MIL split (critical converters in Power‑HIL, remainder in MIL) & Latency measurements in \textbf{Section 8 - Validation and Results} show an average round‑trip of 1.31 ms (max 2.03 ms). \\ \textbf{Model versioning \& snapshot recreation} & Version‑controlled Model Library (Git‑backed) and immutable Snapshot bundles stored in Measurement Storage & Deterministic replay with bit‑identical results confirmed during fault‑simulation runs (Section 7). \\ \textbf{Usability for operators \& researchers} & Drag‑and‑drop Dashboard with one‑click snapshot replay, role‑based access control, and export facilities & SUS score of 82 ± 4 (excellent) reported in Section 8. \\ \textbf{Scenario lifecycle management} & Scenario and Scenario Set hierarchy, supported by the Dashboard and the underlying services & Full lifecycle (create → validate → execute → archive) demonstrated in the prototype (Section 7). \\ \textbf{Extensibility} & Stateless Docker services exposing both MQTT and ZeroMQ endpoints, allowing future AI diagnostics and collaborative work & Explicitly addressed in the mapping (Section 6) and future work (Section 10). \\ \end{longtable} 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. \subsection{11.2 Feasibility Demonstrated on the SEGuRo Platform}\label{feasibility-demonstrated-on-the-seguro-platform} The implementation mapping in \textbf{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: \begin{itemize} \tightlist \item All services can be instantiated, registered, and inter‑connected automatically via SEGuRo's orchestrator.\\ \item The OPAL‑RT runtime wrapper runs reliably inside a privileged Docker container, synchronised with SEGuRo's global clock.\\ \item The Fidelity Watchdog operates continuously, detecting deviations within a 10 ms sliding window and triggering automatic re‑calibration without violating the latency budget. \end{itemize} 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. \subsection{11.3 Path Toward a Production‑Grade Digital Twin}\label{path-toward-a-productiongrade-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 \textbf{Sections 9 and 10}: \begin{enumerate} \def\labelenumi{\arabic{enumi}.} \tightlist \item \textbf{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.\\ \item \textbf{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.\\ \item \textbf{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.\\ \item \textbf{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.\\ \item \textbf{Deploy the Collaborative Workspace service} (Future Work 3) to support multi‑user scenario editing and shared analytics, preparing the DT for collaborative research projects.\\ \item \textbf{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.\\ \item \textbf{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. \end{enumerate} 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. \subsection{11.4 Final Remarks}\label{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. \end{document}