Co-simulation: State of the art

1.1 Motivation

• Earlier and more frequent integration of independently developed partial solutions enables holistic development and global analysis of multidisciplinary systems.Late integration is less optimal, while global activities can assess requirements, design spaces, and properties spanning constituent systems.Source: §1.1 · p. 4

1.2 Co-simulation

• Co-simulation composes black-box simulators so teams can use their own tools while integrators perform early conformance checks without exposing suppliers’ intellectual property.It addresses the difficulty of exchanging heterogeneous models and supports evaluating designs from competing suppliers.Source: §1.2 · p. 4, §1.1 · p. 4
• Although co-simulation spans many engineering domains, the average reported scenario uses only two simulators, leaving it below the scale of cyber-physical systems.Applications include automotive, electricity, HVAC, IC and SoC design, maritime, and robotics; ongoing projects and FMI address this unexplored potential.Source: §1.2 · pp. 4–5

1.3 Need for the Survey

• The survey addresses fragmented communities by bridging independently developed techniques, such as dead-reckoning models, to support knowledge exchange and deeper understanding of hybrid co-simulation.The authors state that no existing survey covered the heterogeneous communities studying co-simulation and present a taxonomy to relate their approaches.Source: §1.2 · p. 5, §1.3 · p. 6
• Co-simulation draws on numerical analysis, differential-algebraic simulation, hybrid systems, optimization, hierarchy, formal verification, system testing, dynamic structures, and multi-paradigm modeling.These fields address coupled-system accuracy and stability, algebraic composition, tradeoffs, compositionality, master correctness, black-box testing, changing dependencies, and abstraction switching.Source: §1.3 · p. 6

1.4 Outline

• The survey distinguishes discrete-event and continuous-time co-simulation, both applicable to continuous, discrete, and hybrid coupled systems, and treats their combination as hybrid co-simulation.Later sections classify framework features and the state of the art using a taxonomy.Source: §1.4 · pp. 6–7

2.1 Dynamical Systems – Models of Real Systems

• A dynamical system models a real system through states and evolution rules, with behavior represented by trajectories over a time base.Model validity depends on an experimental frame comparing the model and real-system traces under stated assumptions.Source: §2.1 · pp. 7–8

2.2 Simulators – Computing the Behavior Trace

• A simulator computes a dynamical system’s behavior trace, usually approximately, while accuracy concerns trace error and validity concerns whether the model represents the real system.For continuous-time systems, domain experts should select an appropriate solver.Source: §2.2 · pp. 8–9

2.3 Simulation Units - Mock-ups of Reality

• A simulation unit combines a simulator with a dynamical system, providing a ready-to-use replacement for a real system that accepts inputs and produces a behavior trace.In the FMI standard, the analogous co-simulation term is a Functional Mock-up Unit (FMU).Source: §2.3 · p. 10

2.4 Compositional Co-simulation

• Co-simulation couples independently developed simulation units through an orchestrator that advances simulated time and transfers outputs to inputs according to a co-simulation scenario.The approach supports black-box units, hierarchical composition, and early, inexpensive what-if analysis, but ensuring compositional correctness, validity, and accuracy remains challenging.Source: §2.4 · p. 10

3 Discrete Event Based Co-simulation

• DE co-simulation lets simulation units evolve internal states and exchange values even while simulated time is stopped.Units communicate through time-stamped events, which may be absent when no event is produced.Source: §3 · p. 11, §3.1 · p. 11

3.1 DE Simulation units

• A DE simulation unit is a passive black box governed by external transitions, internal transitions, output events, and a time-advance function.Its output function may produce an event immediately before internal transition, or an absent value when no output occurs.Source: §3.1 · pp. 11–12

3.2 DE Co-simulation Orchestration

• A DE orchestrator selects the next imminent unit, maps its output events to affected units, updates elapsed times, and resolves simultaneous events deterministically.The Select function is necessary because different execution orders can produce different reactions and behavior traces.Source: §3.2 · pp. 13–16
• A DE co-simulation scenario behaves exactly as a DE unit, enabling hierarchical composition while preserving child-state products, event mappings, and coordinated transitions.The resulting unit can be executed as a single unit or composed into larger hierarchical co-simulation scenarios.Source: §3.2 · pp. 16–17

3.3.1 Causality

• Parallel optimistic orchestration can improve wall-clock performance by exploiting dependencies, but it generally requires rollback capabilities and potentially extensive memory for affected simulation units.Pessimistic orchestration avoids causality violations through global ordering but incurs a performance cost.Source: §3.3.1 · p. 19

3.3.2 Determinism and Confluence

• The Select function ensures a unique deterministic trace, whereas confluence requires all possible execution interleavings to produce the same behavior trace.Both determinism and confluence are compositional properties of coupled simulation units.Source: §3.3.2 · p. 19
• Proving confluence is difficult in black-box discrete-event co-simulation because it depends on how child simulation units react to external events.Parallel-DEVS leaves confluence to the modeler.Source: §3.3.2 · pp. 19–20

3.3.3 Dynamic Structure

• Dynamic structure co-simulation changes dependencies over time according to simulation behavior, reducing unnecessary performance costs when potential influences rarely occur.This can improve optimistic parallel co-simulation and support studies of self-organizing systems.Source: §3.3.3 · p. 20

3.3.4 Distribution

• Geographically distributed co-simulation units require approaches addressing communication cost and security, including computation allocation, hierarchical bridging, dead-reckoning models, and security solutions.Source: §3.3.4 · p. 20

4.1 CT Simulation Units

• CT simulation units represent state-space dynamics with state x, input u, output y, and initial state x0, producing behavior traces analytically or through numerical solvers.For sufficiently differentiable dynamics, truncated Taylor approximations underpin iterative solvers such as Forward Euler; CT units need not model physical continuous-time systems exclusively.Source: §4.1 · p. 21

4.2 CT Co-simulation Orchestration

• CT orchestration defines a communication step H between independently stepped units, using extrapolation or interpolation to supply inputs at internal micro-steps.Jacobi execution advances units independently and supports parallelization, whereas Gauss-Seidel ordering enables interpolation and greater accuracy but reduces parallelization potential.Source: §4.2 · pp. 23, 25, 26
• A CT co-simulation scenario can itself behave as a simulation unit, with composed internal states, orchestrator-defined transitions and outputs, and limited exposure of unit internals.This supports hierarchical coupling, but blind coupling can cause compositionality problems and motivate additional unit capabilities or information about hidden dynamics.Source: §4.2 · p. 26

4.3.1 Modular Composition – Algebraic Constraints

• Algebraic coupling requires the orchestrator to find inputs satisfying cross-unit constraints, often using sensitivity information, rollback, finite differences, and iterative correction.Adding a Boundary Condition Coordinator can transform a non-trivial constraint into a simpler one and permit a smaller internal micro-step, while repeated correction improves accuracy at higher computational cost.Source: §4.3.1 · pp. 27–30
• Coupling protected simulation units can be difficult because white-box model simplification is unavailable; rollback must be provided by black boxes or reconstructed from exposed state.The co-simulation trace differs from the analytical co-model because extrapolation and the large communication step H = 0.1 introduce error.Source: §4.3.1 · p. 30, Figure 9 · p. 31

4.3.2 Algebraic loops

• Algebraic loops may involve only inputs or also states; extrapolation can break input-only loops, whereas state-involving loops require repeated steps with rollback until convergence.Fixed-point, dynamic, waveform, strong, and semi-implicit methods trade accuracy against performance, while FMI step mode requires rollback to iterate output variables.Source: §4.3.2 · p. 32

4.3.3 Consistent Initialization of Simulators

• Consistent initialization requires an extra coupling constraint because simulation-unit initial states may depend on the co-simulation context; the constraint can have multiple solutions or algebraic loops.The FMI Standard provides a dedicated mode for searching for a consistent initial state, potentially through fixed-point iteration.Source: §4.3.3 · p. 33

4.3.4 Compositional Convergence – Error Control

• Convergence is guaranteed when simulation units are convergent, the induced coupled model has state-space form, and Jacobi, Gauss-Seidel, or strong coupling uses polynomial input extrapolation.Algebraic loops and complex coupling constraints can prevent the required state-space representation; error estimation can use rollback-based Richardson extrapolation, input-order comparisons, conservation laws, or embedded methods.Source: §4.3.4 · pp. 33–35

4.3.5 Compositional Stability

• Numerical stability concerns whether a co-simulation remains stable for a non-zero communication step when the underlying system is stable, and it can be studied using the spectral radius of an autonomous linear discrete error system.Unlike convergence, stability depends on the characteristics of the co-simulated system; reducing H indefinitely is impractical because of performance and round-off errors.Source: §4.3.5 · p. 36
• For the example parameters, the co-simulation is stable with spectral radius ρ(A) = 0.9992, but becomes unstable when d_k = 6.0E6, with ρ(A) ≈ 76.43.Stability is determined by whether ρ(A) < 1; fixed-point iteration generally improves stability but requires rollback and may impose prohibitive computational costs.Source: §4.3.5 · pp. 38–39, Figure 10 · p. 39

4.3.6 Compositional Continuity

• Input discontinuities can trigger solver reinitialization, discarded multistep information, inaccurate extrapolation, and substantial wasted computation from repeated micro-step retries.Extrapolated interpolation methods avoid discontinuities by matching the input limits across communication-step boundaries; continuous co-simulation scenarios should not contain discontinuities.Source: §4.3.6 · pp. 39–40

4.3.7 Real-time Constraints

• Real-time co-simulation requires every simulation unit to meet timing constraints, while extrapolation must filter measurement noise and orchestration must compensate for network delays.The timing constraint is t = ατ, and Kalman filtering is identified as one statistical technique for protecting extrapolation from noisy measurements.Source: §4.3.7 · pp. 40–41

5 Hybrid Co-simulation Approach

• Hybrid co-simulation is challenging because continuous-time units expect continuous inputs while discrete-event units exchange instantaneous events with potentially discontinuous outputs.An orchestrator must reconcile these assumptions; Hybrid DE wraps continuous units for discrete-event orchestration, whereas Hybrid CT wraps discrete-event units for continuous-time orchestration.Source: §5 · p. 41, §5.1 · p. 42

5.1 Hybrid Co-simulation Scenarios

• Hybrid scenarios model systems such as thermostats by coupling continuous dynamics with discrete controllers, but wrapper choices and signal conversions must preserve constituent-system properties.The section also notes domain-specific orchestration, such as Ptolemy II Director blocks, as an alternative to exclusively Hybrid CT or Hybrid DE approaches.Source: §5.1 · pp. 41–42

5.2.1 Semantic Adaptation / 5.2.2 Predictive Step Sizes

• Semantic adaptations depend on each scenario and unit: configuration languages or specialized computation models can encode event and signal conversions, but require domain knowledge and may expose implementation information.Predictive step sizes can target threshold crossings or infer relevant advances through output quantization, while exact event location may require derivatives or rollbacks.Source: §5.2.1 · p. 43, §5.2.2 · p. 43

5.2.3 Event Location / 5.2.4 Discontinuity Identification / 5.2.5 Discontinuity Handling / 5.2.6 Algebraic Loops, Legitimacy, and Zeno Behavior

• Hybrid orchestration must distinguish steep continuous changes from true discontinuities and handle discontinuity cascades, reinitialization costs, algebraic-loop nonconvergence, illegitimacy, and Zeno behavior.Discontinuities may require absent-signal formalisms, extra indicators, or symbolic information; Zeno behavior may require recognition and regularization.Source: §5.2.4 · p. 44, §5.2.5 · p. 44, §5.2.6 · pp. 44–45

5.2.7 Stability / 5.2.8 Theory of DE Approximated States

• Event sequences can destabilize hybrid systems even when individual continuous modes are stable, motivating analyses that preserve hidden implementation information and characterize stability under wrapped discrete-event behavior.Hybrid co-simulation also needs error-propagation bounds for discrete-event units coupled to erroneous sources, with tolerance detection and adaptive step sizes to keep errors bounded.Source: §5.2.7 · p. 45, §5.2.8 · p. 45

5.2.9 Standards for Hybrid Co-simulation

• Existing FMI and HLA standards have limitations for hybrid co-simulation, which requires correct time and simultaneity handling, test cases, and orchestration strategies accommodating heterogeneous unit features.Proposed extensions and wrapper-based approaches address these gaps, but standardized interfaces alone do not eliminate differences among simulation units.Source: §5.2.9 · p. 45

6.1 Methodology

• The review classified all collected papers from 2011 through 2016 after iterative taxonomy development stabilized, prioritizing influential papers by citation count.The initial taxonomy was built from approximately 30 papers and continually revised as new references were read.Source: §6.1 · p. 46

6.2 Taxonomy

• The taxonomy is a feature model organized into non-functional requirements, simulation-unit requirements, and framework requirements, with mandatory and optional features.Examples include accuracy and IP protection; exposed information, causality, and rollback; and dynamic structure, adaptive step size, and strong coupling.Source: §6.2 · p. 46

6.3 State of the Art

• A taxonomy example classifies an FMI-based multi-rate orchestrator that detects algebraic loops, separates fast and slow units, and selects a shared communication step size.The orchestrator resolves algebraic loops by successive input substitution while storing and restoring simulation-unit state.Source: §6.3 · p. 47

6.4 Discussion

• Accuracy is the most observed non-functional requirement with 31 reports, whereas fault tolerance, hierarchy, and extensibility are least observed.Fault tolerance matters for long-running co-simulations, including industrial runs lasting at least two weeks.Source: §6.4 · p. 47
• The classification reveals limited support for extensibility, nominal state and output values, acausal approaches, advanced framework features, and combined discrete-event and continuous-time co-simulation.Only one approach is reported as supporting both CT and DE domains for any number of simulation units, while accuracy and IP protection remain limited in multi-unit CT/DE approaches.Source: §6.4 · pp. 47–48

• Co-simulation applications have largely used ad-hoc couplings between two simulators from different domains, while future systems will require larger, hierarchical, heterogeneous, accurate, and IP-protected scenarios.The survey notes that unreported applications may substantially expand the observed application base.Source: §7 · p. 48
• The survey separately examines continuous-time and discrete-event co-simulation, their combination, and related work from the past five years through a proposed taxonomy.It aims to summarize, bridge, and enhance future research in co-simulation.Source: §7 · p. 48
• The principal research challenges are semantic adaptation, modular coupling, stability and accuracy, and standards for hybrid co-simulation.These challenges are especially important as co-simulation supports the virtual development of increasingly complex heterogeneous systems.Source: §7 · p. 48
• Adaptations needed to combine simulators from different formalisms are difficult to generalize, even under a common standard, so integrators may need to describe them explicitly as proposed in.This issue is particularly relevant to early system analysis.Source: §7 · p. 48
• Research remains insufficient on modular, stable, and accurate coupling for dynamically structured scenarios, where acausal approaches and bidirectional effort/flow ports inspired by Bond-graphs may help, with related work in [207].The classification identifies this as a main conclusion and a promising direction.Source: §7 · p. 48

A Historical Perspective of Co-simulation

• The historical perspective maps major co-simulation concepts to their recognition over time in the studied state of the art.Table 1 summarizes this temporal relationship.Source: A Historical Perspective of… · p. 77

A.1 One Formalism and Dynamic Iteration

• Decomposing a large circuit into independently integrated coupled subsystems improved simulation speed by up to two orders of magnitude.The approach exploits sparse coupling in circuit equations [167].Source: §A.1 · p. 77
• Dynamic iteration exchanges extrapolated neighbor outputs over [Tn, Tn+1], repeats integration with corrected outputs until convergence, and thereby addresses extrapolation inaccuracy.Subsystem outputs are assigned to inputs as the coupling mechanism.Source: §A.1 · pp. 77–78
• Communication only at Tn and Tn+1 permits independent parallel integration with arbitrary numerical methods and step-size policies.Independent step sizes avoid forcing slow components to use the smallest step required by faster components, resembling multi-rate methods.Source: §A.1 · p. 78

A.2 Two Formalisms: Digital and Analog Co-simulation

• Modern co-simulation coupled software and hardware concurrently, reducing the need for prototype boards, typically with two simulation units and two formalisms.This was among the first modern uses of co-simulation.Source: §A.2 · p. 78
• Analog-digital co-simulation used continuous-time and discrete-event tools at different abstraction levels, enabling faster abstract intervals and more accurate detailed intervals [77, 135, 166, 209].This separation prompted synchronization methods between the two domains.Source: §A.2 · p. 78

A.3 Multi-abstraction/Multi-Formalism Co-simulation

• Multi-abstraction co-simulation combines formalisms such as state machines and differential equations, selectively simulating nearby subsystems in detail and farther subsystems more abstractly.Hardware/software models include RTL and TLM, with studied switching between abstraction levels.Source: §A.3 · p. 78
• As coupled tools became more numerous and heterogeneous, researchers recognized the need for common interfaces, while automotive, railway, and HVAC applications gained time and cost savings over monolithic modeling.These applications use specialized simulation units to cooperatively simulate heterogeneous physical systems.Source: §A.3 · p. 79

A.4 Black-box Co-simulation

• IP protection is a desired characteristic, enabling suppliers and integrators to exchange co-simulation units without disclosing sensitive information or accepting vendor lock-in contracts.Source: §A.4 · p. 79

A.5 Real-time Co-simulation

• Co-simulation is applied throughout development, including early validation and X-in-the-Loop settings that impose hard real-time constraints.These constraints extend the challenges that co-simulation approaches must address.Source: §A.5 · p. 79

• Larger systems of systems make scale and distribution inherent co-simulation challenges.Source: §A.6 · p. 79

• The section provides a detailed classification of each surveyed co-simulation reference across functional, nonfunctional, and structural framework properties.The classification records aspects such as timing, rollback, availability, coupling model, communication model, algorithmic loop, simulation rate, step size, domain, and visualization.Source: B State of the Art in Co-simulation… · p. 79
• The cited applications include maritime and power-system/network co-simulation, alongside integrations involving DEVS, Modelica with NS-2, Matlab with NS-2 through HLA, and ARGoS with NS-2 and NS-3.Source: B State of the Art in Co-simulation… · pp. 79, 80, 83, 87, 90
• The surveyed frameworks include adaptive or specialized time-stepping approaches, including step-size selection based on subsystem behavior, derivatives, or solver settings.Hoepfer2011 [119] seeks an appropriate co-simulation step size, while Schmoll2012 [212] analyzes global error with subsystem solvers and Gunther2012 [108] bases control on derivatives.Source: B State of the Art in Co-simulation… · pp. 80, 84, 86
• Tomulik2011 [229] addresses algebraic-constraint coupling and finds that coupling should use many derivatives of the coupling variables.Its framework uses an implicit algorithm with fixed step size and Jacobian information.Source: B State of the Art in Co-simulation… · p. 81
• Other approaches target parallel or asynchronous execution, including a Jacobi-based mechatronic framework and a semi-implicit Jacobian correction for coupled tools.Friedrich2011 [93] emphasizes parallel co-simulation, while Busch2012 applies a correction based on the Jacobian of subsystem coupling variables.Source: B State of the Art in Co-simulation… · pp. 82, 84
• Multirate co-simulation lets the fast simulator drive execution while the slow simulator supplies extrapolated inputs to avoid excessive computation.Gonzalez2011 studies the resulting efficiency and accuracy for multibody system dynamics.Source: B State of the Art in Co-simulation… · p. 83
• FMI- and HLA-based approaches coordinate heterogeneous continuous, discrete-event, and hybrid simulators through variable or fixed steps, including quantization wrappers and semantic adaptation of simulation units.The approaches include SysML-configured FMI coordination, HLA/FMI distributed simulation, and event-based directors that specialize semantic adaptation.Source: B State of the Art in Co-simulation… · pp. 93–95
• Stabilized and Jacobian-based methods target strongly coupled systems through implicit loops, algebraic constraints, Jacobian information, input extrapolation, and fixed-point computations.One implementation applies a previously described stabilization method in FMI, while another uses interface Jacobians for fixed-point computation.Source: B State of the Art in Co-simulation… · pp. 96–97
• SpaceEx-Uppaal co-simulation supports zero-step transitions by exploiting FMI, but step rejection—not accuracy—drives this behavior and requires abusing the standard for state transitions.The orchestration algorithm follows.Source: B State of the Art in Co-simulation… · p. 98
• Real-time and interactive frameworks couple remote simulators over UDP, but orchestration details, network-delay handling, and scalability remain limited or unreported.The OPAL-RT/OPNET platform provides few orchestration details, while the Unity/OpenMETA framework enables live interaction without reporting added precautions for network delays or failures.Source: B State of the Art in Co-simulation… · pp. 98, 101
• Explicit Gauss-Seidel coupling of CONTAM and EnergyPlus produced instabilities in an HVAC case study despite FMI integration and a 5-minute synchronization step.The study identifies problems with explicit co-simulation even when using Gauss-Seidel communication.Source: B State of the Art in Co-simulation… · p. 99
• Multicore acceleration partitions models into parallel FMUs, breaking algebraic loops by ordering and delaying variables, while mutexes or scheduling changes prevent concurrent execution of identical FMUs.Partitioning choices affect accuracy, especially when loops are broken at less sensitive variables; FMI lacks thread-safety enforcement across multiple instances.Source: B State of the Art in Co-simulation… · p. 100

Framework integration

• Hybrid DEVS/FMI integration wraps DEV and DESS models as FMUs and uses conservative parallel DEVS, but requires FMU rollback through state access [56].A separate DEVS-based framework wraps continuous-time ODE simulators when state variables and derivatives are available [202].Source: B State of the Art in Co-simulation… · pp. 102, 107

Applications and real-time coupling

• Real-time and distributed applications compensate communication delays or bridge heterogeneous simulators, including power-grid delay correction, dead reckoning, RTDS–MATLAB monitoring, and Linux–wireless protocol co-simulation [191, 221, 163, 90].The power-system framework detects discontinuities when derivative-based cubic-spline extrapolation becomes unreliable, while model-based coupling replaces delayed samples.Source: B State of the Art in Co-simulation… · pp. 103–106
• Co-simulation approaches run simulators in parallel with barrier communication, shift communication by half a step, interface FMUs through FMI, or use adaptive step size control mechanisms.Source: B State of the Art in Co-simulation… · pp. 102–105

Adaptive configuration and error control

• Adaptive masters configure execution parameters during co-simulation, while explicit macro-step control estimates extrapolation-induced local truncation error without rollback or re-initialization [31, 52].These approaches vary step sizes to control accuracy and potentially improve performance, with the latter assuming subsystem integration errors are negligible.Source: B State of the Art in Co-simulation… · pp. 106–107
• Richard’s extrapolation, energy-residual PI control, and extrapolated interpolation target error, step-size adaptation, stability, or input discontinuities in explicit co-simulation [14, 207, 50].The energy-based method assumes energy-conserving scenarios and adapts the next step without rollback, while extrapolated interpolation is designed to avoid subsystem-input discontinuities.Source: B State of the Art in Co-simulation… · pp. 108, 110, 111

Solver-coupling algorithms

• Several solver-coupling methods address algebraic constraints through explicit BCC coordination, predictor-corrector schemes, relaxation, sensitivity estimation, or extrapolation without fixed-point iterations [105, 107, 219, 214, 216, 8].These methods target causal conflicts, arbitrary-index systems, stability, proprietary-model protection, and discontinuities, but may require derivatives, repeated communication, rollback, or higher coordinator rates.Source: B State of the Art in Co-simulation… · pp. 112–114

Configuration and orchestration

• Model-based configuration represents executable-unit couplings, tool assignments, and connections, enabling easier well-formedness checks and reusable co-simulation configurations.The approach is accompanied by the ICOS tool and supports configuration management, hierarchy, extensibility, and reuse.Source: B State of the Art in Co-simulation… · pp. 115–116

Distributed FMI frameworks

• DACCOSIM supports distributed and multicore FMI simulation through local and global masters, while FMU wrappers pass outputs directly to connected inputs to avoid bottlenecks [96].Masters coordinate step sizes when rollback is required; an example reports results very close to Dymola, with accuracy estimated from FMU output errors.Source: B State of the Art in Co-simulation… · pp. 115–116

Heterogeneous framework architectures

• FDMU and FMI provide complementary approaches for heterogeneous-system co-simulation, while FDMU adds a tool-independent web-service framework with CAD-based visualization and extensible wrappers [79].FDMU uses functional building blocks, wrappers, a master simulator, and a user console to connect simulation tools and coordinate communication.Source: B State of the Art in Co-simulation… · pp. 118–119

Heterogeneous automotive co-simulation

• TEODACS FlexRayExprt.Sim integrates mechanics, microelectronics, and complete FlexRay network simulation, using model switching to replace detailed models and accelerate co-simulation [130].The platform addresses the absence of solutions simulating all FlexRay network components and supports multiple FlexRay nodes.Source: B State of the Art in Co-simulation… · p. 119

MOKA

• MOKA structures FMU implementations around reusable FMUBlock, FMUPort, and state-variable abstractions, while templating the FMU master to minimize scenario-specific code changes.A demonstrated application uses bouncing-ball and integer-counter FMUs, and future work proposes a DSL for changing scenarios without modifying the master code.Source: B State of the Art in Co-simulation… · p. 120

BCVTB

• BCVTB is an open-source, modular platform that couples heterogeneous building-energy and control simulators through Ptolemy II, executable interfaces, and coupling algorithms [253].It supports interfaces for Simulink, MATLAB, Modelica, and SystemC and is intended to let users select specialized tools or tools matching their expertise.Source: B State of the Art in Co-simulation… · pp. 120–121

C2WT

• The C2WT platform integrates FMI as an HLA federate, enabling FMUs in heterogeneous command-and-control simulations and demonstrating the approach with vehicle thermal management.The work extends the C2WT metamodel with FMI-specific concepts and compares the case study with a simulation in another environment.Source: B State of the Art in Co-simulation… · p. 121

INTO-CPS

• The INTO-CPS tool chain integrates Modelio, Overture, 20-sim, OpenModelica, and RT-Tester through an FMI-based Co-simulation Orchestration Engine (COE).The INTO-CPS application configures co-simulations, while the COE executes them and provides a semantic foundation for model-based cyber-physical-system design.Source: B State of the Art in Co-simulation… · p. 122
• The INTO-CPS COE supports variable step sizes, rollback to the last successful state, and constraints including zero-crossing, bounded difference, sampling rate, and allowed minimum and maximum values.Variable step sizes are described as potentially improving performance, while the constraints support accuracy-related requirements.Source: B State of the Art in Co-simulation… · pp. 122–123

C Co-Simulation Scenario Categorization

• Each category is described together with the references classified under it.The classifications were established in the previous section.Source: C Co-Simulation Scenario Categorization · p. 123

C.1.1 Fault Tolerance

• Fault tolerance requires checkpointing simulation-unit state and recording inputs so a failed unit can be replaced and advanced to the current state.This capability is especially important for long-running simulations.Source: §C.1.1 · p. 123

C.1.2 Configuration Reusability

• Reusable external configurations avoid the time-consuming, error-prone, and non-trivial setup associated with rebuilding co-simulation scenarios.Performance depends on simulating much in little time with few resources, using variable-step integration, signal extrapolation, and parallelism.Source: §C.1.2 · p. 123, §C.1.3 · p. 124

C.1.4 IP Protection

• IP protection hides model structure and variables, using mechanisms such as web services or binary FMI units, while parallelism, distribution, hierarchy, scalability, platform independence, and extensibility broaden deployment and reuse.Distributed frameworks can keep simulation units remote and give suppliers greater control over their use; hierarchical frameworks abstract scenarios as black-box units.Source: §C.1.4 · p. 124, §C.1.6 · p. 126, §C.1.7 · p. 126

C.2 Simulator Requirements

• Simulator requirements classify exposed information such as state and output frequencies, detailed equations, nominal values, signal kinds, derivatives, discontinuities, extrapolation, causality, delays, micro-step outputs, and execution time.These capabilities provide information that can guide communication-step sizing, input extrapolation, and master-algorithm assumptions.Source: §C.2 · p. 128, §C.2.1 · p. 129

C.2.3 Time Constraints

• Execution behavior is further categorized by fixed or dynamic scaled real time, single or multiple rollback, and local or remote availability.Single rollback permits reverting once to a saved past state, whereas multiple rollback permits repeated reversion further into the past.Source: Scaled Real Time Simulation · pp. 135–136, §C.2.4 · p. 137, §C.2.5 · p. 138

C.3.1 Standard

• The taxonomy records standards and coupling mechanisms, including High Level Architecture, Functional Mock-up Interface, Functional Digital Mock-up, and input/output assignments.These categories organize interoperability and the mapping of simulator inputs and outputs within co-simulation scenarios.Source: §C.3.1 · p. 140, §C.3.2 · p. 140

C.3.3 Number of Simulation Units

• Studies are classified by the number of simulation units as two or three or more, alongside references spanning broader unit configurations.The two-unit category lists Lin2011 through Quaglia2012, while the three-or-more category lists Pedersen2015 through Viel2014.Source: §C.3.3 · pp. 142–143

C.3.4 Domain

• The domain taxonomy separates CT and DE applications, with additional studies covering both or other domain classifications.CT references include Pedersen2015, Hoepfer2011, and Faure2011; DE references include Lin2011, Nutaro2011, and Al−Hammouri2012.Source: §C.3.4 · pp. 144–146

C.3.5 Dynamic structure

• The dynamic-structure category is presented without listed references.The supplied passage contains only the category heading and no cited works.Source: §C.3.5 · p. 146

C.3.6 Co-simulation Rate

• Co-simulation rate is categorized as single, multi-rate, or other rate treatments, with multi-rate methods distinguishing slow and fast subsystems and adapting communication steps accordingly.Multi-rate co-simulation provides interpolation or extrapolation for slow systems; the supplied references include Gonzalez2011, Awais2013b, Awais2013a, and Kuhr2013.Source: §C.3.6 · pp. 146–148

C.3.7 Communication Step Size

• Communication step size is classified as fixed or variable, distinguishing studies that use fixed steps from those using variable steps.Fixed-step references include Pedersen2015, Faure2011, and Tomulik2011, whereas variable-step references include Lin2011, Hoepfer2011, and Sun2011.Source: §C.3.7 · pp. 148–150

C.3.8 Strong Coupling Support

• Strong-coupling support is grouped into none or explicit, partial or semi-implicit, and full or implicit methods.The explicit category includes Pedersen2015 and Lin2011; the semi-implicit category includes Busch2012 and Schweizer2014; and the implicit category includes Tomulik2011, Bastian2011a, and Viel2014.Source: §C.3.8 · pp. 150–152

C.3.9 Results Visualization

• Results visualization includes postmortem, live, and interactive categories, represented by distinct reference sets such as Pedersen2015, Hassairi2012, and Bombino2013.Postmortem results are available after simulation, while live and interactive visualization are separate categories.Source: §C.3.9 · pp. 152, 154

C.3.10 Communication Approach

• The communication taxonomy distinguishes Jacobi communication, with references including Pedersen2015, Hoepfer2011, and Schierz2012.Source: §C.3.10 · p. 154
• The communication taxonomy also includes references associated with Schweizer2014, Schweizer2015d, Sadjina2016, Busch2016, and Neema2014.Source: §C.3.10 · p. 155
• Gauss-Seidel communication forms another categorized approach, supported by references including Lin2011, Hoepfer2011, and Bastian2011a.Source: §C.3.10 · p. 155
• Additional communication-approach references include Dols2016, BenKhaled2012, Camus2015, Pedersen2016, and Arnold2014.Source: §C.3.10 · p. 156

D List of Acronyms

• The acronym list defines CPS, CT, DE, DEVS, DTSS, FMI, FR, GVT, IP, IVP, NFR, ODE, and SR for recurring paper terminology.These expand to terms including Cyber-Physical System, Continuous Time, Discrete Event, Functional Mock-up Interface, and Ordinary Differential Equation.Source: D List of Acronyms · p. 157