Smart Grid Modelling Language (SG-ML)

• SG-ML is an XML-based modelling framework that unifies power-system topology, cyber-network structures, and operational data using IEC 61850 and PLCopen XML standards.
• It automates the integration of cyber and physical layers, enabling reproducible and scalable smart grid cyber range deployments for cybersecurity experiments and training.
• The framework enriches standard engineering configurations with proprietary XML schemas to specify device parameters, network mappings, and protection thresholds.

Smart Grid Modelling Language (SG-ML) is an XML-based modelling framework for the automated generation of smart grid cyber ranges. Across the early framework paper, the Auto-SGCR implementation paper, and the later language-specification paper, SG-ML is presented as a declarative, schema-driven representation of a smart grid environment that is both human-friendly and machine-readable, allowing a processor or toolchain to parse configuration files and instantiate a functioning cyber-physical testbed with minimal manual setup (Mashima et al., 2024). Its distinguishing characteristic is the unification of power-system topology, cyber-network topology, device configuration, and supplementary operational data within a single modelling workflow built around IEC 61850 Substation Configuration Language (SCL) and IEC 61131 PLCopen XML, augmented by proprietary schemas where the standards are insufficient (Roomi et al., 11 Sep 2025).

1. Historical emergence and problem setting

SG-ML emerged from the practical difficulty of constructing realistic smart grid cyber ranges for cybersecurity experiments, training, and testing. The motivating problem is that a useful cyber range must tightly couple a cyber system emulation with a physical power-system simulation so that device actions, measurements, network exchanges, and electrical consequences remain consistent. The source papers repeatedly emphasize that such environments are difficult to realize in production systems and expensive to realize as hardware testbeds, while conventional research testbeds are often one-off, proprietary, and hard to reconfigure or reproduce (Mashima et al., 2024).

The framework is therefore positioned against manual cyber range construction. In that manual mode, the electrical and cyber layers are often configured separately, or with substantial ad hoc integration effort, which makes the resulting environment difficult to reuse, scale, or share. SG-ML addresses this by making the cyber range a model-driven artifact: a user prepares XML inputs, the SG-ML Processor or Auto-SGCR toolchain parses them, and the range is instantiated automatically (Roomi et al., 24 Jul 2025).

A recurring clarification in the literature is that SG-ML is not introduced primarily as a general-purpose smart-grid modelling language. In the Auto-SGCR paper, it is explicitly the core enabler for automatically generating a smart grid cyber range from standardized configuration files, effectively serving as the “compiler input” for the generation pipeline (Roomi et al., 24 Jul 2025). The later specification paper broadens that framing by defining SG-ML as a unified modelling language for smart grid cyber ranges and as a set of XML schemas that bridge system modelling and automated deployment (Roomi et al., 11 Sep 2025).

This suggests that SG-ML is best understood less as a standalone semantic formalism and more as an executable specification layer for cyber-range synthesis. A plausible implication is that its primary evaluation criterion is not elegance of notation but fidelity, reuse of utility engineering artifacts, and deployability of the resulting test environment.

2. Standards foundation and modelling philosophy

The modelling philosophy of SG-ML is standard-first. Rather than inventing a wholly new syntax, it reuses established XML-based engineering artifacts wherever possible and adds proprietary schemas only where the standards do not provide the information needed for automated instantiation (Mashima et al., 2024). This is presented as a practical mechanism for reducing modelling overhead, improving interoperability, and allowing operators to reuse existing configuration assets.

The main standards reused by SG-ML are IEC 61850 SCL and IEC 61131 PLCopen XML. Within IEC 61850 SCL, the papers identify four central file types:

Artifact	Role in SG-ML	Scope
SSD	System Specification Description	Physical power topology
ICD	IED Capability Description	IED capabilities and internal model
SED	System Exchange Description	Inter-substation exchange
SCD	System Configuration Description	System-wide communication topology

These files are assigned specific modelling roles. SSD describes the physical power topology of a process, substation, or DER plant. SED connects multiple processes and describes inter-process or inter-substation electrical connectivity. ICD defines IED capabilities, protection functions, datasets, and communication settings. SCD describes the system-wide communication topology, including device addressing and LAN or subnetwork structure (Roomi et al., 24 Jul 2025).

The specification paper further states that SCL comprises the main parts Header, Substation, Communication, IED, and Datatype templates, and that SG-ML consumes these structures as deployable inputs rather than merely as documentation (Roomi et al., 11 Sep 2025). For PLCs, SG-ML leverages IEC 61131-3 PLCopen XML so that PLC control logic can be represented in a vendor-neutral XML form and deployed through OpenPLC/OpenPLC61850 workflows. The papers specifically mention extracting structured text logic from OpenPLC and note possible future support for ladder logic (LD) and function block diagrams (FBD) (Roomi et al., 11 Sep 2025).

This standards-centric reuse is one of SG-ML’s core design choices. The stated rationale is that a model should remain close enough to utility engineering artifacts that operators can reuse their own files, while also being rich enough to support testbed instantiation (Roomi et al., 24 Jul 2025). In effect, SG-ML treats existing IEC artifacts as partial executable models and then completes them with supplementary schemas.

3. Internal structure, schemas, and modelling constructs

SG-ML is described as a collection of XML files comprising standard IEC artifacts and supplementary XML schemas introduced to cover missing operational and cyber-range-specific information (Roomi et al., 24 Jul 2025). The Auto-SGCR paper enumerates the framework as consisting of standard IEC 61850 SCL files—SSD, SCD, ICD, and SED—together with Supplementary XML, CPMapping XML, Thresholds XML, SCADA Config XML, and PLCopen XML.

The need for supplementation is explicit. SCL alone does not fully define generator rated power, load profiles, transformer ratings, cable lengths and types, breaker open or close status over time, exact mappings between simulator variables and IEC 61850 attributes, protection thresholds, PLC logic, or SCADA datapoint configuration (Roomi et al., 24 Jul 2025). The specification paper adds further missing categories such as attack injection parameters, scenario-specific metadata, and additional network constraints (Roomi et al., 11 Sep 2025).

At the physical modelling level, SG-ML maps electrical equipment to SCL and auxiliary XML constructs. The examples given include generators, PV and battery assets, transformers, loads, circuit breakers, and cables. For instance, generator location is represented via ConductingEquipment and Terminal connectivityNode, voltage level via Substation/VoltageLevel, while numerical values such as rated active power p_mw and voltage vm_pu come from supplementary XML. Loads similarly use SCL for bus location and supplementary XML for active and reactive power. Circuit breakers use SCL for location and equipment type and supplementary XML for status such as closed. Cable end points are represented through Terminal connectivityNode, while length and standard type are supplied by supplementary XML (Roomi et al., 24 Jul 2025).

The framework also uses a data sequence attribute in supplementary XML to define time-series data. The operational notation stated in the paper is that if the supplementary XML defines n time steps, then Auto-SGCR generates n power-flow simulation models (Roomi et al., 24 Jul 2025). This is one of the few explicit notational conventions associated with SG-ML, alongside attribute names such as q_mvar, stNum, and XCBR.Pos.

For cyber-network modelling, SG-ML relies on SCD communication structures including Communication, SubNetwork, ConnectedAP, Address, and PhysConn. These are used to derive IP address, netmask, gateway, device connectivity, and link structure between IEDs, PLCs, HMI, and switches. A specific modelling device noted in the paper is that PhysConn contains port and cable information, and the same cable name can be used to infer a link in the emulated network (Roomi et al., 24 Jul 2025).

Device modelling is centered on the IEC 61850 IED hierarchy. SG-ML uses IED, Logical Devices (LDs), Logical Nodes (LNs), Data Objects (DOs), datasets, and control blocks. The papers emphasize LN classes such as MMXU for measurements, XCBR for breaker status, and protection LNs including PTOC, PTOV, PTUV, PTRC, CILO, PDIF, and PDIS; the later specification paper additionally mentions PTUF, PDOP, and PTTR (Roomi et al., 24 Jul 2025). Multiple LN instances can be numbered, such as MMXU1 and MMXU2.

Several proprietary schemas are central to executable behavior. The cyber-physical mapping schema connects simulator measurements to IEC 61850 data attributes, for example mapping Load0.Voltage.phsA to IED1.MMXU.PhV.phsA.cVal or IED2.MMXU.PhV.phsA.cVal, depending on the example (Roomi et al., 24 Jul 2025). The threshold schema defines protection settings such as AlarmThreshold and TripThreshold for protection types including PTOC, PTOV, and PDOP, with example values including PTOC (50) instantaneous over-current at 3 to 4 times nominal current, PTOC (51) time over-current at 1.05 p.u. start pickup, PTOV (59) over-voltage at 1.1 p.u. for 10 s alarm and 1.2 p.u. for 2 s trip, PTUV (27) under-voltage at 0.8 p.u. for 10 s alarm and 0.7 p.u. for 2 s trip, and PDOP (32) reverse power where any small amount triggers trip (Roomi et al., 11 Sep 2025). SCADA configuration is handled through a separate schema defining items such as dataSources and dataPoints and attributes including xid, type, updatePeriodType, transportType, host, port, updatePeriods, range, offset, modbusDataType, engineeringUnits, dataSourceXid, and deviceName (Roomi et al., 11 Sep 2025).

4. Processing pipeline and automated instantiation

The SG-ML architecture is consistently described as a model-to-runtime pipeline. The high-level workflow is: user prepares SG-ML input files, the processor parses and combines them, cyber and physical components are generated, open-source runtime tools launch the environment, and the resulting range is used for experiments, training, and testing (Mashima et al., 2024). The later specification paper compresses this into a model → parse → instantiate pipeline (Roomi et al., 11 Sep 2025).

In Auto-SGCR, the toolchain behaves like a compiler. Input SG-ML files are read, merger tools combine subsystem files into grid-wide models, a power simulator is configured from physical topology and supplementary parameters, a network emulator is configured from communication topology, virtual devices are instantiated from ICD data plus supplementary mappings, and the resulting environment is deployed using open-source runtime tools (Roomi et al., 24 Jul 2025). The earlier framework paper presents the same logic through named modules such as SSD Merger, SCD Merger, SSD Parser, Mininet Launcher, Virtual IED Builder, OpenPLC Editor / OpenPLC61850, and SCADA Config Parser (Mashima et al., 2024).

On the physical side, the merged SSD plus supplementary XML are used to configure pandapower. The workflow is to define static topology from Process, VoltageLevel, Bay, and ConductingEquipment, read ratings, status, and load profiles from supplementary XML, use data sequence to generate multiple time steps, run power flow at each step, store measurements and statuses in a MySQL database, and update the system based on breaker or control changes from devices or attacks (Roomi et al., 24 Jul 2025). The early paper additionally notes that dynamic behavior is injected via Power System Extra Config XML, which includes load profiles, breaker statuses, disturbance scenarios, and contingency scenarios such as generator loss or line loss (Mashima et al., 2024).

On the cyber side, the merged SCD is parsed to configure Mininet. SubNetwork and ConnectedAP provide endpoints, Address provides IP parameters, and PhysConn together with cable identifiers determines links; switches and host connections are then created accordingly (Roomi et al., 24 Jul 2025). In the earlier framework description, wide-area communication between substations is simplified in the current version as a single switch connected to all substations (Mashima et al., 2024).

Virtual IED instantiation uses ICD-derived information such as LNs and their types, datasets, control or report blocks, protocol support, and protection functions. The runtime implementation is based on libiec61850 and uses IEC 61850 MMS, GOOSE, and related communication mechanisms together with CPMapping XML for database-to-model mapping and Thresholds XML for protection actions (Roomi et al., 24 Jul 2025). The earlier paper specifies that virtual IEDs are implemented in C using libiec61850 and support MMS for communications between SCADA or PLCs and IEDs, GOOSE and R-GOOSE for IED-to-IED status exchange, and R-SV for sampled measurement values (Mashima et al., 2024).

PLC and SCADA generation follow analogous patterns. PLCs are implemented using OpenPLC61850, which extends OpenPLC for IEC 61850 MMS support, and PLC logic is described using PLCopen XML (Roomi et al., 24 Jul 2025). SCADA configuration is described in SCADA Config XML, validated against a schema, converted to JSON, and uploaded to ScadaBR or SCADABR (Roomi et al., 11 Sep 2025). Taken together, these mechanisms make SG-ML an executable integration layer rather than a purely descriptive data model.

5. Representable systems, case studies, and operational scenarios

The papers describe SG-ML as capable of representing both single-substation and multi-substation environments. At the single-substation level, SG-ML can model the physical layout of a substation, feeders, breakers, transformers, loads, local communication networks, and IED protection and control logic (Roomi et al., 24 Jul 2025). More broadly, the early framework paper lists substations, transmission segments, microgrids, smart homes, generators, PV and battery assets, controllable loads, IEDs, PLCs, SCADA HMIs, circuit breakers, transformers, network switches, and wide-area inter-substation links as representable entities (Mashima et al., 2024).

A central demonstration in the Auto-SGCR work is a 3-substation 66/11 kV sub-transmission system with two incoming feeders and, in one of the larger evaluated configurations, 45 IEDs (Roomi et al., 24 Jul 2025). The later specification paper describes a related three-substation model with SS1, SS2, and SS3, two incoming 66 kV feeders to SS1, outgoing lines to the other substations, redundant lines for resilience, and inter-substation protection and communication (Roomi et al., 11 Sep 2025). These examples are used to show that SG-ML is not confined to a single substation but can represent multiple interconnected substations, inter-substation feeders, communication across substations, and larger IED populations.

The literature also grounds SG-ML in the EPIC testbed. One paper describes EPIC as including a generation segment, transmission segment, microgrid segment, and smart homes segment, all treated as a single substation for simplicity in the demonstration (Mashima et al., 2024). Another paper characterizes the EPIC testbed as comprising a SCADA server, 5 PLCs, 3 generators, 3 VSDs, 12 IEDs, and 10 network switches, using MMS and GOOSE communication and supporting experimentation such as parallel generator attack scenarios (Roomi et al., 11 Sep 2025). These case studies serve primarily as evidence that the language can bridge heterogeneous cyber-physical assets through a single modelling workflow.

Protection logic is a recurrent application domain. The Auto-SGCR paper notes that SG-ML supports configurations for intra-substation protection, inter-substation protection, and protocols such as MMS, GOOSE, R-GOOSE, and R-SV (Roomi et al., 24 Jul 2025). The protection functions mentioned across the papers include PTOC, PTOV, PTUV, PTRC, CILO, PDIF, PDIS, PTUF, PDOP, and PTTR (Roomi et al., 11 Sep 2025). The specification paper also gives a concrete inter-substation example in which differential protection uses sample values exchanged between IEDs on both substations over line L2.

The framework is explicitly connected to cyber-attack experimentation. The early paper discusses false command injection, in which an attacker sends fake IEC 61850 MMS commands such as an open command to a circuit breaker, and ARP-spoofing-based man-in-the-middle attacks, in which traffic between devices is intercepted and manipulated (Mashima et al., 2024). The later specification paper’s mention of attack injection parameters as a category missing from standard models indicates that SG-ML’s scope extends beyond static configuration toward scenario-specific cyber-range behavior (Roomi et al., 11 Sep 2025).

6. Technical significance, limitations, and relation to adjacent approaches

The principal technical significance attributed to SG-ML is reproducible automation. The papers consistently state that the same SG-ML model can recreate the same cyber range, which matters for experiments, published results, attack demonstrations, and training (Roomi et al., 24 Jul 2025). This reproducibility is paired with configurability, portability, extensibility, and shareability: users can tailor grid topology, device lists, communication topology, protection logic, load profiles, breaker statuses, and time-series behavior, while XML-based files built on IEC 61850 artifacts can be moved across environments, shared in the user community, and adapted without extensive programming (Roomi et al., 24 Jul 2025).

SG-ML is also framed as a response to the fragmentation of prior smart grid cyber-range approaches. The papers contrast it with systems built around ModbusTCP, DNP3, or IEEE C37.118.2, with proprietary co-simulation platforms that require manual setup for each scenario, and with IEC 61850 testbeds limited to the substation domain (Roomi et al., 24 Jul 2025). By contrast, SG-ML is described as standard-based, open-source, automatable, multi-substation capable, and customizable by users without extensive programming. The later specification paper sharpens this comparison by characterizing earlier methods as ad hoc and by presenting SG-ML as a unified methodology that integrates both power system and cyber network representations (Roomi et al., 11 Sep 2025).

At the same time, the literature identifies several limitations. First, SCL alone is insufficient, which is why SG-ML requires supplementary XML schemas (Roomi et al., 24 Jul 2025). Second, the current implementation relies on an open-source stack including pandapower, MySQL, Mininet, libiec61850, OpenPLC61850, and SCADABR or ScadaBR (Mashima et al., 2024). Third, open-source fidelity may be lower than that of commercial simulators; the Auto-SGCR paper explicitly notes that commercial simulators may offer superior performance and fidelity (Roomi et al., 24 Jul 2025). Fourth, scaling can become resource intensive: the 104-node case approaches practical limits on a single machine at 100 ms polling intervals, though multi-machine deployment is suggested (Roomi et al., 24 Jul 2025). The earlier framework paper gives the concrete evaluated result that a commodity desktop PC with an Intel Core i9 processor and 16 GB RAM could host a 5-substation model with 104 virtual IEDs and a 100 ms power-flow simulation interval (Mashima et al., 2024).

The physical simulation model imposes a further constraint. Pandapower is identified as a steady-state solver, so the system is not continuously dynamic in the strict real-time sense; instead, it runs power-flow simulation periodically, for example every 100 ms, producing discrete updates (Mashima et al., 2024). The papers suggest future work in extending the platform to commercial simulators such as Matlab Simulink for higher fidelity and real-time behavior, distributing deployments across multiple physical nodes, and further enhancing the open-source generation framework (Roomi et al., 24 Jul 2025).

A common misconception would be to treat SG-ML as identical to IEC 61850 SCL. The papers contradict that interpretation. SG-ML is built on SCL, but it is not reducible to SCL because automated cyber-range generation also requires parameter specifications for physical components, cyber-physical mappings, threshold logic, SCADA configuration, scenario metadata, and, in the later formulation, attack injection parameters and additional network constraints (Roomi et al., 11 Sep 2025). Another misconception would be to regard it as purely a schema collection; the papers define it equally as a processor-mediated workflow that parses, validates, merges, and instantiates the model into an operational environment (Mashima et al., 2024).

In aggregate, the literature depicts SG-ML as a schema-based, standards-aware, and execution-oriented language for smart grid cyber ranges. Its role is to convert utility-style engineering configuration files and supplementary cyber-range specifications into a power-flow simulation model, a cyber-network emulation topology, virtual IEDs, PLCs, SCADA or HMI components, and the mappings and thresholds needed for protection and attack experiments (Roomi et al., 24 Jul 2025). This suggests that its broader significance lies in reframing smart grid cyber-range construction from a bespoke integration task into a repeatable model-driven workflow.