PaperlayerView exact revision on arXiv

Source-linked AI summary

Efficient Co-simulator Integration with Application to Smart Grids

Talha Ibn Aziz, Jihoon Og, Ioanis Nikolaidis, Omid Ardakanian

arXiv:2609.03118v1cs.NI

TL;DR

Co-simulation must coordinate heterogeneous simulators and events, but lock-step advancement can waste computation. This work integrates smart-grid simulators through MOSAIK and refines event-based synchronization and NS-3 event filtering. The reported benchmark results show shorter execution times while preserving accuracy and causal order.

  • Problem

    Co-simulation faces interoperability, configuration, and computational-overhead challenges, while lock-step advancement repeatedly steps federates that may have no events.

    Source: §I · pp. 1–2, B. Time synchronization · p. 5

  • Method

    The paper integrates five federates through MOSAIK and uses logical-time lower bounds and NS-3 event filtering to process internal events efficiently.

    Source: §III · p. 4, D. Discussion · p. 12

  • Results

    Approximately 4–5× faster execution in the IEEE 13-node tap-control scenario and 50% faster execution in the 1,793-node distributed state-estimation case, without loss of accuracy or violation of causal order.

    Source: §VI · p. 13

  • Takeaways & Limitations

    The platform provides a reusable foundation for evaluating technologies, control strategies, and resilience under realistic cyber-physical conditions.

    Source: §VI · p. 12

    Event-based gains may be reduced for extremely dense events or federates that cannot expose next-event timestamps, and LBTS overhead may offset benefits.

    Source: D. Discussion · p. 12

Abstract

from arXiv · show

The evolution of the electric power grid towards a "smart grid" is an example of an emerging large-scale cyber-physical system. To study the potential of cyberattacks or other sources of extreme events, high-fidelity co-simulation is the only realistic strategy. In this work, we demonstrate a practical and high-performance co-simulation strategy for smart grids, which provides lessons about co-simulation integration that can be carried over to other cyber-physical systems. Specifically, we present a co-simulation platform based on the Mosaik framework that integrates several federates including OpenDSS for power flow, a refined NS-3 for communication networks, and custom Python-based simulators for on-load tap changer control, distributed state estimation, and data collection. We compare synchronization strategies -- exhaustive lock-step time advancement versus an optimized event-driven approach that exploits lower-bound time stamps (LBTS) and next-event prediction -- and introduce targeted refinements to NS-3 event handling and relevance filtering of internal events. Performance is evaluated on two standard IEEE benchmark systems: the 13-node test feeder with tap-changer voltage regulation and a large-scale 33-bus system augmented with 32 European low-voltage feeders (1,793 nodes total) performing distributed state estimation with thousands of phasors and smart meters. Experimental results demonstrate that the refined event-based synchronization that uses LBTS-based NS-3 event filtering reduces execution time by up to 50% (and more than 4$\times$ in smaller scenarios) compared to na\"ive lock-step methods, while strictly preserving temporal correctness and simulation accuracy. We additionally summarize a domain ontology that standardizes multi-simulator configuration and entity mapping across power, communication, and control domains.

I. INTRODUCTION

Smart-grid studies need high-fidelity co-simulation, but integrating heterogeneous simulators and coordinating their events is complex and computationally costly. The paper compares synchronization approaches and situates its strategy among prior co-simulation frameworks.

I. INTRODUCTION

  • Operational-grid studies of cyber threats and extreme events are constrained by safety, cost, and regulation, motivating flexible, scalable simulation environments.New technologies and cross-domain interactions also increase complexity and uncertainty for reliable grid operation.Source: §I · p. 1
  • Heterogeneous simulators often lack compatible interfaces, while configuration and coordination grow more complex and concurrent execution can consume substantial resources.The paper frames co-simulation as integrating simulators to model phenomena that a single tool cannot accurately capture.Source: §I · p. 1
  • Lock-step stepping can waste computation on federates with no events, whereas event-driven execution requires simulators to expose next-event timestamps.The paper compares the approaches in computational complexity, execution time, and temporal correctness.Source: §I · p. 2

II. RELATED WORK

  • Prior work describes HLA as an interoperability ruleset whose federates, Runtime Infrastructure, and Runtime Interface coordinate interactions and global event ordering.The cited background also situates smart grids as multi-domain systems with feedback among power, communication, and control components.Source: §II · p. 2

A. Co-simulation Frameworks

Existing co-simulation frameworks trade synchronization precision, efficiency, scalability, and integration effort. The paper presents an approach that avoids fixed synchronization points and a globally maintained event queue while preserving causal order.

A. Co-simulation Frameworks

  • EPOCHS and INSPIRE use fixed time-step synchronization, with finer synchronization increasing precision at a computational-efficiency cost.INSPIRE uses conservative time management and a fixed MTAR lookahead for its network simulator.Source: A. Co-simulation Frameworks · p. 2
  • GECO uses a global event queue, but constructing one across independent simulators is difficult because their event structures and semantics differ.The discussion also notes ADEVS's global or local queue designs and its dependence on C++ implementations or wrappers.Source: A. Co-simulation Frameworks · pp. 2–3
  • HELICS can scale to 100,000 federates, while its configuration and API integration effort makes it better suited to large simulations than minimal-configuration prototyping.Source: A. Co-simulation Frameworks · p. 3
  • The demonstrated smart-grid approach avoids both a globally maintained event queue and fixed synchronization points while maintaining accuracy and causal order.The paper states that its synchronization strategies are independent of application domain.Source: A. Co-simulation Frameworks · p. 3

B. Example Framework: MOSAIK

The paper uses MOSAIK to connect established power and communication simulators with application-specific components. Simulator characteristics inform their integration and synchronization roles.

B. Example Framework: MOSAIK

  • MOSAIK provides a lightweight platform for coordinating federates through a simulator manager, scheduler, and API.Its simulator categories distinguish time-based, event-based, and hybrid behavior by how execution steps are triggered and outputs remain valid.Source: B. Example Framework: MOSAIK · p. 3

C. Example Simulator: Power Grid Simulators

  • OpenDSS supports detailed transmission and distribution system simulation, and its static-state model permits circuit changes at arbitrary time points.Its scripting model allows users to select specific modules for a run.Source: C. Example Simulator: Power Grid… · p. 3

D. Example Simulator: Network Simulators

  • NS-3 is a customizable discrete-event network simulator whose internal components can support user-developed modules for co-simulation.The paper selects OpenDSS and NS-3 for their maturity and compatibility with Python, which eases MOSAIK integration with minimal simulator customization.Source: D. Example Simulator: Network Simulators · pp. 3–4

III. INTEGRATION STRATEGY

The integration strategy couples power flow, communication, control, state estimation, and data collection through MOSAIK. Its synchronization design handles feedback dependencies and seeks to avoid unnecessary lock-step execution while maintaining causal order.

III. INTEGRATION STRATEGY

  • Five federates—power flow, communication network, controller, estimator, and collector—are connected through MOSAIK using customized wrappers and high- or low-level APIs.The low-level API uses sockets and JSON messages to support federates running in separate processes.Source: §III · p. 4
  • Power flow uses OpenDSS with a Python wrapper, NS-3 handles network packets, Python federates implement control and estimation, and the collector stores data in HDF5.Source: §III · p. 4

A. Integration with MOSAIK

  • Federate configurations specify simulation parameters, initial states, interconnections, and data formats, while MOSAIK uses the dependency graph to order execution and resolve circular dependencies.Source: A. Integration with MOSAIK · p. 4, B. Time synchronization · p. 4
  • MOSAIK routes sensor readings through the network to the controller or estimator, carries tap decisions back to the power-flow federate, and sends federate outputs to the collector.The architecture figure depicts the federates and their interactions through MOSAIK.Source: A. Integration with MOSAIK · p. 4, Figure 1 · p. 5

B. Time synchronization

  • When sensor data and a tap decision arrive at the same timestamp, the strategy prioritizes sensor data to reflect delays in real voltage regulation.For the controller-to-network connection, sensor data relay is likewise prioritized over tap-control relay when both have data to exchange.Source: B. Time synchronization · p. 5
  • Lock-step execution causes repeated context switches even when no federate has an event, prolonging runtime in proportion to the simulated time steps.Source: B. Time synchronization · p. 5
  • Skipping event-free steps requires next-event timestamps and lower-bound computation; predicting timestamps can be difficult when simulators hide their event queues or depend on other federates.The paper distinguishes event-based simulators, whose next event cannot be determined in advance, from time-based and hybrid simulators.Source: B. Time synchronization · p. 5
  • The network federate is event-based, while the power-flow, controller, and estimator federates can combine scheduled and externally triggered activity; the collector is externally triggered.At coincident power-flow events, circuit changes are applied after sensor-data generation; controller and estimator results can follow fixed computation delays.Source: B. Time synchronization · p. 5

C. NS-3 Refinements

The NS-3 refinement enables event-driven advancement by predicting relevant future events despite an opaque, event-rich internal queue. LBTS bounds and relevance filtering let NS-3 advance conservatively while preserving temporal correctness.

  • Next-event prediction enables batched advancement while preserving simulation accuracy, but unmodified NS-3 exposes its next timestamp only through a complex internal queue with many irrelevant events.Source: C. NS-3 Refinements · p. 5
  • MOSAIK's LBTS max-advance bound lets NS-3 run forward conservatively, stopping at relevant packet receptions or the bound and reporting the next timestamp.NS-3 tracks receptions at sensor, controller, and estimator nodes as relevant events.Source: C. NS-3 Refinements · pp. 5–6
  • A modified RunUntil pauses on relevant receptions beyond MOSAIK's requested time and returns their timestamp, unlike NS-3's queue-draining Simulator::Run().Source: C. NS-3 Refinements · p. 6, Figure 2 · p. 6

D. Complexity Analysis

The analysis isolates synchronization and inter-simulator communication overhead, assuming the federates themselves are already efficient. It characterizes MOSAIK's graph traversal and the added cost of filtering relevant events.

  • The analysis assumes federates are already as efficient as possible and focuses on synchronization and communication overhead; NS-3's JSON-message time is analyzed separately.Source: D. Complexity Analysis · p. 6
  • MOSAIK's synchronization graph traversal scales as O(|V|+|E|) in simulators and dependencies, with dependencies often comparable in number to simulators.Source: D. Complexity Analysis · p. 6
  • Event relevance filtering may examine every message waiting in the sink queue in the worst case, though that queue is often small.Source: D. Complexity Analysis · p. 6

IV. REFERENCE DESIGN

The reference design evaluates co-simulation on two IEEE feeder scenarios, with communication topologies derived from power-grid topologies and a standardized ontology configuring the federates. The tap-control case uses a 13-node feeder with sensors, a controller, and an actuator.

IV. REFERENCE DESIGN

  • Communication topologies are derived from established IEEE power-grid benchmarks; the standardized ontology defines simulated entities, properties, relations, and federate configuration.Source: §IV · pp. 6–7
  • The 13-node feeder represents a small-scale tap-control case, while the larger 33-bus system represents residential loads and distributed state estimation.Source: §IV · p. 7

A. Tap Control

  • In the tap-control case, a node-611 sensor reports voltage every 100 ms to the controller at node 632, which actuates a transformer at node 650.Source: A. Tap Control · p. 7

B. Distributed State Estimation

The section evaluates distributed state estimation on an augmented 1,793-node grid and reports tap-control performance across synchronization refinements. Event-driven refinement reduces execution time, while the DSE evaluation excludes the most granular stage because of memory limits.

B. Distributed State Estimation

  • The DSE case has 1,793 nodes, with phasors at primary nodes and smart meters at secondary nodes generating 8,030 sensor-data sets per simulated minute.Phasors are sampled every 2 seconds; smart meters are sampled every 15 seconds for platform stress testing.Source: B. Distributed State Estimation · pp. 7–8
  • Its communication network has 1,793 devices, and the estimator records messages every 200 ms and estimates states every 1,000 ms.The wired links use 1 ms delay and 1,024 Kbps; the 6LoWPAN configuration instead uses LR-WPAN links.Source: B. Distributed State Estimation · p. 8

V. RESULTS AND DISCUSSION

  • The DSE results compare only Stages 2 and 3 because Stage 1's granular steps generate too much sensor data for available memory.The authors identify fine time steps and MOSAIK's JSON-formatted inter-simulator messages as contributing factors.Source: §V · p. 8

A. Scenario 1: Tap Control

  • Tap-control runs simulate 40 seconds with one to four sensors, each generating data every 100 ms, and controller actions every 200 ms.Ten runs per case averaged under 40 seconds of execution; sensor locations vary across cases.Source: A. Scenario 1: Tap Control · p. 8, Figure 5 · p. 9
  • In the tap-control simulation, Stage 3 relevance filtering of NS-3 events improves execution time further; across all stages, more sensors generate more events and increase execution time linearly.Figure 6 reports overall simulation execution times across refinement stages, with error bars showing the minimum and maximum execution times across 10 runs.Source: A. Scenario 1: Tap Control · p. 9, Figure 6 · p. 9
  • At Stage 1, federates take 40,000 steps; at Stage 2, a single-sensor case yields 592 Power Flow events because communication delays skip controller generations.A sensor generates 400 values and the controller 200 tap events over the 40-second simulation; the collector matches Power Flow step counts.Source: A. Scenario 1: Tap Control · p. 9
  • In tap-control case 4, Stage 3 reduces NS-3 execution time by about 0.18 seconds (26.1%) and total execution time by about 0.76 seconds (31%).Stage 3 further refines NS-3; its benefit to total execution time is more prominent in larger simulations.Source: A. Scenario 1: Tap Control · p. 9

B. Scenario 2: DSE

In the 60-second DSE scenario, stage 3 relevance filtering cut overall execution time by about half, with NS-3 accounting for most of the runtime. The reduction also lowered NS-3 and MOSAIK execution costs without changing simulator event counts.

B. Scenario 2: DSE

  • Across 10 test runs of a single exhaustive simulation with phasors at 33 primary nodes and smart meters at 1,760 secondary nodes, average execution time fell from 342.732 s in stage 2 to 171.259 s in stage 3, reducing overall time by approximately 50%.Source: B. Scenario 2: DSE · p. 10
  • NS-3 steps fell from 42194 to 15064 (64.3%), and its execution time fell from 226.09 seconds to 93.64 seconds (approximately 58.6%).MOSAIK execution time fell from 61.59 seconds to 21.58 seconds (approximately 65%) as fewer context switches and data exchanges were needed.Source: B. Scenario 2: DSE · p. 10
  • The Collector's execution time was negligible, while the Estimator processed larger data volumes than the tap-control Controller at each estimation interval.The Estimator generates results every 1000 ms; its execution time is longer than the Controller's in tap control.Source: B. Scenario 2: DSE · p. 10
  • Stage 3 refinement affects NS-3, while the other three federates show negligible execution-time change; event counts stay unchanged, preserving simulation accuracy.The DSE comparison also reports moderate execution-time increases in Power Flow and MOSAIK relative to tap control, while NS-3 and Controller/Estimator rise most substantially.Source: B. Scenario 2: DSE · p. 10

C. Scalability Analysis

The scalability experiments relate execution time and event volume to the number of federates, message-generation rates, and network settings. Stage 3 retains event-count fidelity while refining relevant-event processing, but network conditions can reduce message delivery and simulator events.

C. Scalability Analysis

  • Stage 2 execution time increases linearly as Sender/Receiver pairs are added, while NS-3 event generation plateaus once network links become saturated.At saturation, destination message reception stops increasing even as sources continue introducing messages and corresponding events.Source: C. Scalability Analysis · p. 11
  • For the same simulator count, event counts are identical across refinement stages, while Stage 3 execution time follows the optimized trend in the 1,793-node State Estimation network.The event count rises with added simulators until NS-3 link queues saturate.Source: C. Scalability Analysis · p. 11
  • With 50 Senders, increasing the message-generation interval from 200 ms to 1000 ms decreases execution times and event counts, mostly for NS-3.More frequent messages increase NS-3 execution and JSON communication times as larger, more frequent messages are exchanged.Source: C. Scalability Analysis · p. 11
  • Changing bandwidth or link delay produced minimal event-count and execution-time variation, except that raising delay from 15 ms to 1000 ms reduced messages conveyed.The messages are small; delayed sensor data can reach the Controller too late for it to receive all data.Source: C. Scalability Analysis · p. 12
  • At 10% link error rates, the Controller receives no messages; increasing errors distort arrivals and reduce events across simulators, with Power Flow least affected.In Tap Control, TCP retransmissions initially prevent message loss, but at high error rates retransmissions also fail.Source: C. Scalability Analysis · p. 12

D. Discussion

The strategy combines logical-time lower bounds with relevance filtering to improve execution while preserving causal order. Its performance depends on event sparsity and simulators' ability to expose next-event timestamps.

D. Discussion

  • Logical-time lower-bound computation supports efficient internal-event processing without breaking causal order, while NS-3 relevance filtering reduces redundant time management and execution.The reported strategy improves execution without compromising simulation accuracy, although overall processing remains demanding as network complexity grows.Source: D. Discussion · p. 12
  • When events occur in every time unit, optimization overhead may make performance worse than lock-step; the approach also requires simulators to share next-event timestamps.The authors state that for the majority of complex co-simulation scenarios, the strategies can reduce overall execution time significantly.Source: D. Discussion · p. 12

VI. CONCLUSION

The platform integrates power, communication, control, state-estimation, and data-collection simulators, and compares lock-step with event-driven synchronization. Event-driven co-simulation with NS-3 relevance filtering reduces execution time while preserving accuracy and causal order, with benefits dependent on workload and simulator instrumentation.

VI. CONCLUSION

  • The Mosaik platform couples OpenDSS, refined NS-3, and purpose-built control, state-estimation, and data-collection federates for realistic feedback loops and inter-domain interactions.Source: §VI · p. 12
  • The comparison evaluates exhaustive lock-step synchronization against event-driven synchronization using lower-bound time-stamp computation and next-event prediction.Source: §VI · p. 12
  • Intelligent relevance filtering inside NS-3 achieved execution-time reductions of approximately 4–5× for the IEEE 13-node tap-control scenario and 50% for the 1,793-node distributed state-estimation case, without loss of accuracy or violation of causal order.Source: §VI · p. 13
  • For typical sparse-event smart-grid workloads, event-based co-simulation with appropriate simulator instrumentation yields substantial performance gains over naive time-stepped execution.Extremely dense events or opaque federates that cannot expose next-event timestamps can let LBTS computation overhead partially offset the benefits.Source: §VI · p. 13
  • Future work will explore multithreading within and across federates and apply the techniques to a broader set of cyber-physical-system applications.Source: §VI · p. 13

APPENDIX

The appendix describes an ontology adapted to represent smart-grid objects and their properties and connections across power, communication, and control domains. Its classes capture equipment, characteristics, location, measurements, and object relationships.

APPENDIX

  • The ontology adapts a building-metadata schema to OpenDSS, NS-3, and Python programs, defining objects and properties used to connect them.Some relationships, including feeds, are drawn from the earlier schema.Source: APPENDIX · p. 14

A. Equipment Class

  • Equipment covers physical smart-grid entities, separating electrical equipment such as buses and transformers from network devices and processors such as controllers, estimators, and sensors.Source: A. Equipment Class · p. 14

B. Characteristics Class

  • Characteristics describe circuit settings, line-code impedance values used for state-estimation admittance matrices, and communication-technology specifications for network devices.OpenDSS cannot simulate more than one active circuit at a time.Source: B. Characteristics Class · p. 14

C. Location and Measurable Class

D. Object Properties

  • Object properties connect classes: sensors measure Measurable objects, equipment can feed other equipment, and controllers feed actuators that control equipment.In the tap-control example, filled lines show object relations and dashed lines show inheritance; attachesTo, locatedAt, feeds, and connectsTo encode relations.Source: D. Object Properties · p. 14, Figure 16 · p. 15
Loading 2609.03118v1…