Co-simulation at Di ff erent Levels of Expertise with Maestro2

,


Introduction
Co-simulation is a technique for simulating complex systems by combining multiple simulation tools into a single simulation Kübler and Schiehlen (2000b); Gomes et al. (2018b) Interoperability between simulation tools is achieved through the use of Functional Mock-up Units (FMUs) defined by the Functional Mock-up Interface (FMI) standard Committee (2014Committee ( , 2021).An FMU encapsulates a Simulation Unit (SU) by providing a standardised interface of inputs, outputs, and functions to let a co-simulation framework control the simulation of a coupled system of FMUs, referred to as a scenario.A scenario is obtained by coupling inputs and outputs of the FMUs in the scenario, as illustrated in Figure 1.A coupling denotes that the output FMU's state influences the input FMU's state.Figure 1 depicts a scenario with two coupled FMUs of a coupled mass-spring-damper, similar to a later example in Section 4.
A co-simulation framework executes the scenario by computing the joint behaviour of the system by coordinating the execution of the FMUs in the scenario ac-

MSD1 MSD2
Figure 1: A co-simulation scenario with two SUs MSD1 and MSD2 representing a coupled mass-spring-damper system.The SUs are represented as rectangles, and the arrows f 1 and f 2 denote the connections between the SUs.

40
Figure 2 shows that the OA significantly affects the The function R links each input to indicate whether the input SU expects the coupled output to be simulated before or after the input SU itself.
Definition 2 (Scenario).A scenario is a structure ⟨C, L, R⟩, where • C is a finite set (of SU identifiers).Step algorithm for the watertank scenario in Figure 3.

Runtime Modules
More advanced features and functionality are typically implemented as runtime modules, which are loaded and executed during the execution of a MaBL specification through function calls.
A runtime module is a dynamically linked library that exposes a set of functions that can be called from MaBL to perform specific tasks that are not natively supported.
For example, the FMI2 runtime module provides the FMI2 interface and offers various runtime module options.The "regular" runtime module unpacks an FMU, loads its dynamically linked library, and invokes its functions.On the other hand, the JFMI2 module allows loading an entity by specifying the class name instead of the FMU path.This is particularly useful for prototyping, as it enables development in other JVM-based languages such as Java, Kotlin, or Scala, bypassing the need for compilation into shared libraries and packages.
Another example of a runtime module is the Fault Injection module, which allows faults to be injected into the simulation with minimal effort.Specifically, the module wraps around an FMU and intercepts all data to and from the FMU, allowing it to modify the data before it is passed to the FMU based on a given configuration (Frasheri et al. ( 2021)).

Generation of Specifications
To cater for users with different levels of expertise, Maestro2 offers a variety of approaches to generating a MaBL specification as illustrated in Figure 6.The most basic approach is to manually write the specification in MaBL, which is a viable option for small specifications  exchange the data between the linked ports.

778
The MaBL API provides complete flexibility to the

Case Studies
This section presents two case studies that illustrate how Maestro2 can be used to tackle a broad variety of co-simulation scenarios.This section provides a brief overview of the case studies, the essential challenges that cannot be solved by a standard co-simulation framework, and the role of Maestro2 in tackling these challenges.More details about the case studies can be found in the corresponding references.
At time t: doStep(S 1 ,H): Advances the state of FMU S 1 by H getOut(S 1 ,y): Returns the output y of the FMU S 1 setIn(S 1 ,u,y): Assigns the input u of the FMU S 1 to the value y

Figure 2 :
Figure 2: Comparison of the results of two different OAs for the scenario in Figure 1 with its analytical solution.The step size used in the co-simulation is 0.1 s.

•
L is a function L : U → Y, where U = c∈C U c and Y = c∈C Y c , and where L(u) = y means that the output y is coupled to the input u. • R : U → B is a predicate, which describes the SUs' input approximation functions.R(u) = true means that SU c expect the SU d of the output y coupled to u to be simulated before c. similarly, R(u) = false means that SU c expect the SU d of the output y coupled to u to be simulated after c.To illustrate the concepts introduced in Definitions 1 and 2, consider the scenario in Figure 3 and the corresponding behavioural trace shown in Figure 4.The scenario consists of two SUs, a controller SU and a tank SU, and two couplings, one from the output valve state of the controller SU to the input valve state of the tank SU, and one from the output water level of the tank SU to the input water level of the controller SU.Each SU has some parameters (e.g.max level and min level) which are used to configure the simulation.The function R is omitted from the scenario, as it is not part of the FMI standard, and is discussed in Section 2.2.The controller SU is a simple controller that opens or closes a valve based on the current water level, and the tank SU is a simple tank that keeps track of the current water level based on the flow of water in and out of the tank through the valve.The behaviour trace of the scenario is in Figure 4 and is obtained by simulating the scenario from time 0 to 10 seconds.The trace is the function σ that maps time to the state of the scenario, i.e. σ(t) = s (t) c | c ∈ C .The co-simulation error is the difference between the simulated behaviour of the scenario and its ideal behaviour, i.e. the behaviour obtained by simulating the scenario with an infinitely small step size or by solving the differential equations analytically, which is generally not possible.The simulation of a scenario is controlled by the OA, which is the algorithm coordinating the execution of the SUs in the scenario to obtain the joint behavioural trace of the system.The OA comprises multiple stages, including everything from loading the SUs to terminating the simulation and performing the co-simulation by invoking the set c , get c , and doStep c functions defined

Figure 3 :
Figure 3: The the co-simulation scenario of the water tank example illustrated as a block diagram.The scenario is adapted from Mansfield et al. (2017).

Figure 4 :Figure 5 :
Figure 4: The behavioural trace of the Water Tank example shown as a plot of the water level and valve state over time for a simulation from 0 to 10 seconds with a step size of 0.1 seconds.The scenario is adapted from Mansfield et al. (2017).

441X479
-in-the-loop: Co-simulations include simulators that 442 are constrained to progress in sync with the wall-443 clock time, because they represent human opera-444 tors or physical subsystems.445 Fault Injection: Co-simulations provide an additional 446 test environment where all sorts of scenarios can 447 be tested.Fault injection is a specific type of 448 test where faults and other irregularities are in-449 jected into the system to investigate the system's 450 behaviour under such conditions.451 Last but not least, co-simulation tools have differ-452 ent audiences ranging between researchers, students, 453 and industry from different domains.Each audience 454 has different requirements and expectations from a co-455 simulation tool.At the same time, students and re-456 searchers are interested in transparency and customi-457 sation possibilities, while the industry is interested in 458 plug-and-play, stable, scalable, and mature solutions 459 with consumable interfaces.Consequently, we believe 460 that the co-simulation framework, presented in the next 461 section, meets the needs of all audiences by providing 462 a low-level interface for students and researchers and a 463 high-level interface for industry.464 3. Co-simulation with Maestro2 465 This section describes the guiding principles behind 466 Maestro2, namely the separation of concerns between 467 the specification of a co-simulation and the execution of 468 a co-simulation.The separation of concerns is achieved 469 through the use of a Domain Specific Language (DSL) 470 called MaBL, which specifies a co-simulation scenario that can be analysed, verified and optimised prior to execution.The section begins with a brief introduction to 473 the Maestro2 framework before introducing the MaBL 474 DSL and how it is used to describe and analyse a co-475 simulation scenario.Finally, the section shows how 476 Maestro2 uses code generation to provide a performant 477 and flexible co-simulation engine.Maestro2 is a co-simulation framework based on the 480 FMI standard.It is written in Java and is available as 481 open source software (https://github.com/INTO-482CPS-Association/maestro).Co-simulation is per-483 formed by executing a MaBL specification, a "C-like" 484 DSL for specifying co-simulation scenarios.The speci-485 fication describes all the steps of the OA (see Figure 5), 486 the FMUs involved and the connections between them.487 The general idea behind the invention and use of MaBL 488 is to separate the specification of the OA from the ex-489 ecution of the OA.This need arises from the desire to 490 analyse, verify and optimise the OA prior to execution, 491 which was identified based on the experience with Mae-492 stro1 (Thule et al. (2019)).493 The Maestro2 approach, illustrated in Figure 6, can 494 be summarised as follows: The user can either write a 495 MaBL specification manually or generate it using one 496 of the approaches described in Section 3.3.The MaBL 497 specification is then fine-tuned and analysed by a range 498 of expansion plugins, which also can be used to ex-499 pand the specification with additional functionality.Fi-500 nally, the MaBL specification is executed using either 501 the MaBL interpreter or a code generator, which gener-tion.The simulation block (line 8 in Listing 1) con-523 tains a set of imports (lines 9-10), which are used to 524 import so-called runtime modules, and a set of anno-525 tations (lines 11-13), which are used to configure the 526 simulation environment available to expansion plugins 527 within the simulation, which are described below.Run-528 time modules are treated in Section 3.2.1,whereas ex-529 pansion plugins are described in Section 3.3.1.

Figure 6 :
Figure 6: The Maestro2 is centred around the MaBL DSL.Maestro2 provides different approaches to generate a MaBL specification to enable cosimulation practitioners of different levels of expertise.A MaBL specification can be analysed by a range of expansion plugins.Finally, Maestro2 offers two approaches to execute a MaBL specification, namely the MaBL interpreter and a code generator.

Figure 7 :
Figure 7: The different approaches to generate a MaBL specification in terms of workload and customizability.

786Figure 8 :
Figure 8: Performance comparison of Maestro, Maestro2 Interpreter and Maestro2 Code Generated version.In the left figure the time for loading the FMUs is subtracted from the total simulation time.In the right figure it is included.
is a large field and challenging to 1067 cover thoroughly, with co-simulation frameworks being 1068 a moving target.For this reason, we introduce some 1069 of the existing co-simulation frameworks and compare 1070 them to our contribution in

Figure 10 :
Figure 10: Possible algorithms.Adapted from Inci et al. (2021).Both algorithms are valid according to the FMI standard and can be used to simulate the system depicted in Figure9.

Figure 12 :Figure 13 :Figure 14 :
Figure 12: On the top, error in v 1 for adaptive and static co-simulation sequences.At the bottom, sequence changes of the adaptive cosimulation (corresponds to the best order output in Figure 11).Reproduced from Inci et al. (2021).
Furthermore, we plan to extend Maestro2 to be ap-plicable in the context of digital twin engineering, 1211 more specifically, the incubator project (Feng et al. 1212 (2021a,b)), some initial results of which are presented

Figure 15 :
Figure 15: Numerical results as reported in Gomes et al. (2021a).The full video can be seen online Association (2021).
Although the example is simple, it still empow-764 ers the user as they do not have to worry about the com- ). 691 JacobianStepBuilder produces the MaBL neces-692 sary to perform Step stage of the OA based on the Ja-693 cobian iteration method.Jacobian iteration performs a 694 simulation step by prompting all FMUs to progress in 695 time, retrieves the necessary outputs, and sets the nec-696 essary inputs (Gomes et al. (2018d)).The plugin can, 697 similarly to Maestro1, be tailored to use different meth-698 ods for dynamically determining the step size when per-699 forming a simulation with a variable step size (Thule 700 et al. (2019)).The current implementation supports the 701 following methods: 702 Zero Crossing: Synchronise the FMUs at a point in 703 time where a given signal is zero or two signals 704 intersect.705 Bounded Difference: The bounded difference con-contains a guide for creating new expansion plugins to 745 enable expert users to extend the Maestro2 framework 746 with new functionality.761 ing 3, which is used by the Initialization plugin 762 to change the mode of an FMU to Initialisation 763 Mode.

Table 1
, on the item where

Table 1 :
Overview of co-simulation frameworks and their customization options.
This is referred to as Entity-Component- 1100and plotting capabilities.While this shares the goals 1101 of Maestro2, the approach is different.One could, for