Semantic adaptation for FMI co-simulation with hierarchical simulators

Abstract

Model-based design can shorten the development time of complex systems by the use of simulation techniques. However, it can be hard to simulate the system as a whole if it is developed in a concurrent fashion by multiple and specialized teams. Co-simulation, with the support of the Functional Mockup Interface (FMI) Standard, is proposed as a way to promote tool interoperability while protecting the intellectual property of subsystems. The standard allows uniform communication between subsystem simulators, but does not state how the inputs and outputs should be interpreted, nor how the subsystems should interact correctly.

Semantic adaptations can be quickly made to correct the interactions with subsystem simulators that were produced with different assumptions, and avoid changing those subsystems, their simulators, or the orchestration algorithm that computes the co-simulation. In this work, we explore how to describe common adaptations and what their meaning is in the context of FMI co-simulation.

The result is a sound language that enables the implementation of adaptations with minimal effort. A distinct feature is that it describes adaptations for groups of interconnected subsystem simulators in the same way as for a single simulator, and the implementation is itself a simulator, thanks to a sound definition of hierarchical co-simulation.

This work paves the way for research into the correct combination and interfacing of different adaptations.

Keywords

Co-simulation Functional Mockup Interface Standard hierarchical co-simulation semantic adaptation

1. Introduction

The systems we engineer today are characterized by increasing complexity. Model-based design can boost the development of such systems by enabling their analysis at higher levels of abstraction via simulation. However, it can be difficult to simulate the system as a whole if it is developed in a distributed fashion, by multiple and specialized teams.¹

Two factors contribute to this difficulty: (a) specialized teams have their own tools; and (b) some of the components of the system are provided by different suppliers,² and have valuable intellectual property (IP).

The first difficulty is a natural consequence of using the most appropriate formalism for a specific domain.³ The same can be expected from external suppliers. During the development process, if a team wishes to understand how a component being developed behaves when interacting with the rest of the system, it is useful that the tool in use can import and simulate correctly the models created by the other teams (with different tools). As we show shortly, it can be difficult to correctly simulate imported models, as these belong to potentially different domains, each with their own set of specialized simulators.³

As for the second difficulty, if the team is using externally supplied components and wishes to simulate them, it may not be able to import the components’ models because these contain protected IP. For sufficiently complex components, a “lock-in” contract can be made to allow the team access to those models. However, the team will no longer be free to benchmark components from different competing suppliers.

Co-simulation, with the support of the Functional Mockup Interface (FMI) Standard,⁴ is proposed as a way to promote tool interoperability while addressing the IP protection requirement. The models are exported as executable black boxes that receive inputs and produce outputs, allowing for the simulation of the component they stand for. In the FMI, each black box is called a Functional Mockup Unit (FMU), the term adopted in this document.

The standard provides a common interface to allow uniform communication with the black boxes, solving the combinatorial explosion of import–export formats. However, it does not ensure that the black boxes are interacted with in a semantically correct manner.

When a team is given an FMU that does not behave as expected, we say that there is an interaction mismatch between the FMU and the rest of the system. Interaction mismatches can be roughly classified as follows:

Signal data mismatch happens when the signals provided by the FMU are not compatible with the ones that are expected (e.g., different frame of reference or different physical units).

Model of computation mismatch happens when the provided FMU assumes a different model of computation⁵ than the one actually used to compute the overall behavior of the system (e.g., FMUs exported by a timed automata modeling and simulation tool^6,7 have to make assumptions about the other interacting FMUs).

Capability mismatch happens when a given FMU lacks some capabilities (see Gomes’ paper⁸ for an overview of capabilities of FMUs) that affect the simulation performance (e.g., FMUs that lack higher-order input extrapolation, an important capability that affects the accuracy and stability of the co-simulation^9,10).

Rather than asking the original producer of the FMU to correct an interaction mismatch, it can be useful that the team is able to correct it immediately. Note that any mismatch happens between a given FMU and a usage intent, and therefore it is not necessarily the case that the best correction of a mismatch is done by the producer (if the FMU is to be reused).

In fact, as the work of Arnold et al., Bastian et al., and Gomes et al. show,^9,11–13 some mismatches happen as a product of the (incorrect) handling of multiple interacting FMUs, and the correction has to be done for that specific interaction.

The above arguments motivate the need for semantic adaptations, and lead to the following research question:

RQ1 How can we describe the most common semantic adaptations on multiple types of black box FMUs in a productive manner, and realize them without violating modularity and transparency.

Informally, we call semantic adaptation of an FMU the set of modifications made to the inputs/outputs and interaction with environment, of the FMU, with the purpose of correcting an interaction mismatch. This concept is formalized later in this work.

Productivity is related to the effort required to describe an adaptation. Modularity refers to the fact that any FMU should be adapted by changing how it is interacted with, and not how it is implemented. Transparency means that any tool that imports FMUs should not have to be changed in order to import, and interact with, an adapted FMU.

The descriptions should be made in an independently developed language because it is impractical that every tool capable of importing FMUs is able to implement the adaptations. Furthermore, one cannot expect that any user of an FMU has the ability to modify the importing tool to support these. Compared to implementing these adaptations manually, a language reduces the accidental complexity, prevents mistakes, and allows soundness analyses to be carried out.

In this paper, we build on prior work^14–16 to define a language that allows for the descriptions of the most common semantic adaptations that can be used in FMI co-simulation, surveyed by Gomes et al.¹⁷ A distinct feature of the language proposed here is that it describes adaptations for groups of interconnected FMUs in the same way as for a single FMU, thanks to a sound definition of hierarchical co-simulation.

The definition of hierarchical co-simulation, and the semantics of the language, are presented in a bottom-up approach, as illustrated in Figure 1. In Section 2 we introduce a co-simulation abstraction with simulation units and how these relate to FMUs. Section 4 contains the formal foundations of a special kind of simulation unit that is the template to implement any semantic adaptation. In Section 3 a running example is described, and in Section 5 the language and its semantics are described. Section 6 judges how well we have addressed the research question. Section 7 discusses the flaws of our approach and research opportunities. Finally, Sections 8 and 9 present the related work and conclude, respectively.

Figure 1.

Overview of DSL semantics and document structure.

2. Background

In this section we introduce the concepts, terminology, and assumptions used throughout this document. We cover co-simulation, the FMI Standard, semantic adaptation, and domain-specific languages.

2.1. Co-Simulation

We briefly summarize the main concepts related to co-simulation and refer the reader to the work of Gomes et al. for a more detailed introduction of each concept.¹⁷

We use dynamical system to refer to a model that has a notion of state and rules describing the evolution of that state across time, starting from an initial state. Inputs and outputs can be defined to describe the environment.

A simulator is an algorithm that takes a dynamical system and input signals as input, and computes an approximated behavior trace of the dynamical system.

A simulation unit (also known as a simulation application¹⁸) is the composition of a simulator together with a dynamical system, essentially representing a mockup of a real system. It accepts input trajectories and produces a behavior trace.

Simulation units (or just units) can be coupled through their inputs and outputs. A coupling restriction (or just couplings) is an output connected to an input. It means that the trajectory computed at that output—for example, a function of the continuous time—must be equal to the one computed at the input, at all times.

The orchestrator (or master) is an algorithm that takes a set of simulation units and their coupling restrictions—that is, a co-simulation scenario—and computes the behavior trace of all units, trying to satisfy the coupling restrictions. In practice, these restrictions can only be satisfied at certain countable points in time, called communication points. These points are agreed upon by the simulation units and the orchestrator.

A basic orchestrator will, at each communication point, copy data points from outputs to inputs, and ask each unit to compute its own behavior trace until the next communication point. The collective behavior trace is called the co-simulation.

We capture the essence of a simulation unit with reference i, using the discrete time system notation, in one of the following four possible ways:

\begin{matrix} 〈 x_{i} (t + {\tilde{H}}_{i}), {\tilde{H}}_{i} 〉 = F_{i} (t, H, x_{i} (t), \underset{reactive}{\underset{︸}{u_{i} (t + H)}} or \underset{delayed}{\underset{︸}{u_{i} (t)}}) \\ y_{i} (t) = \underset{Mealy}{\underset{︸}{G_{i} (t, x_{i} (t), u_{i} (t))}} or \underset{Moore}{\underset{︸}{G_{i} (t, x_{i} (t))}} \\ x_{i} (0) = \underset{reactive}{\underset{︸}{Ini t_{i} (u_{i} (0))}} or \underset{delayed}{\underset{︸}{Ini t_{i} ()}} \end{matrix}

(1)

where t denotes the simulated time, $x_{i}$ denotes the state vector, $u_{i}$ the input vector, $Ini t_{i}$ computes the initial state, $H > 0$ denotes the requested communication step size, $0 < {\tilde{H}}_{i} \leq H$ denotes the communication step size taken by the unit, $F_{i}$ is the state transition function, and $G_{i}$ the output function. Bold symbols will always refer to vectors in this paper.

The definition in Equation (1) covers the different kinds of simulation units considered (based on the orchestrators surveyed by Gomes et al.¹⁷): reactive Mealy, reactive Moore, delayed Mealy, and delayed Moore. The difference is in where and when the unit expects inputs to be provided. For example, a delayed Moore unit can compute its output without requiring an input, and can compute its future state ( $x_{i} (t + {\tilde{H}}_{i})$ ) with just the current input $u_{i} (t)$ . A reactive Mealy unit, on the other hand, requires an initial input to compute the initial state and needs to know the next input in order to compute the next state/output.

We use shortcuts such as $F_{i} (t, H, x_{i} (t), \dots)$ , $G_{i} (t, \dots)$ , and $Ini t_{i} (\dots)$ to denote the appropriate function depending on the kind of unit i. Furthermore, we make the following remarks about each simulation unit i:

F_i and $G_{i}$ are mathematical functions (also denoted pure).

The internal definition of $F_{i}$ and $G_{i}$ is unknown, but the kind of unit is known.

If $〈 \cdot, {\tilde{H}}_{i} 〉 = F_{i} (t, H, x_{i} (t), \dots)$ and ${\tilde{H}}_{i} < H$ , then the unit rejects the step size H requested. Furthermore, for any $\tilde{H} \leq {\tilde{H}}_{i}$ , we assume that $〈 \cdot, \tilde{H} 〉 = F_{i} (t, \tilde{H}, x_{i} (t), \dots)$ .

Given a set of unique unit references $D = {1, \dots, n}$ , a co-simulation scenario is defined as the aggregation of each simulation unit definition, in Equation (1), plus a coupling function that defines the input of i as a function of the outputs of units ${j : j \in D \ {i}}$ . Formally, combining the notation used by Arnold et al. and Kübler and Schiehlen,^9,19 a scenario is given by Equation (2):

\begin{matrix} {\begin{matrix} 〈 x_{i} (t + {\tilde{H}}_{i}), {\tilde{H}}_{i} 〉 = F_{i} (t, H, \dots) \\ y_{i} (t) = G_{i} (t, \dots) \\ u_{i} = c_{i} (y_{1}, \dots, y_{i - 1}, y_{i + 1}, \dots, y_{n}) \\ x_{i} (0) = Ini t_{i} (\dots) \end{matrix} \\ for each i \in D \end{matrix}

(2)

where $c_{i}$ denotes the coupling function, and each $F_{i}, G_{i}$ follows one of the definitions in Equation (1). Commonly, $c_{i}$ is linear and maps at most one component of one of the inputs (the inputs/outputs are vector quantities), onto one component of the output. We assume that $c_{i}$ is linear.

Let $i, j \in D$ be two different units, and $\bar{0}$ be the zero matrix of appropriate dimension. If $\frac{\partial c_{i}}{\partial y_{i}} \neq \bar{0}$ , then i gets part of its input from j. Informally, this means that at least one component of $u_{i} = c_{i} (\dots)$ is determined by at least one component of $y_{i}$ . We say that a unit $i \in D$ depends algebraically on unit $j \in D$ , with $i \neq j$ , if i gets part of its input from j and i is not a delayed Moore. So, for example, if i gets part of its input from j, but it is a delayed Moore, then i does not depend algebraically on j.

Using the algebraic dependency relationship, one can build a directed graph—called the dataflow graph—with one node $n_{i}$ per simulation unit $i \in D$ , and an edge $(n_{j}, n_{i})$ between two nodes $n_{j}, n_{i}$ whenever the unit i depends algebraically on unit j. This procedure is based on the causal block diagram simulation algorithm.^20,21 A topological order of the resulting graph gives an execution order that respects the units’ algebraic dependencies.

Depending on the coupling function and on the kind of simulation units being coupled, algebraic loops may occur. An algebraic loop includes any input/output/state that depends on itself, at the same time point.¹⁹

If an algebraic loop exists between the units, then it is not possible to compute a topological ordering of the dataflow graph. For now, we assume that such topological order can always be computed for a given co-simulation scenario. We denote that order via a mapping $σ : N \to D$ , that returns the unit reference $σ (j)$ that is jth in the topological order. So $σ (1)$ gives a unit that is first in the topological order—that is, that has no algebraic dependencies.

With a well-defined topological order, the orchestrator only has to provide inputs to, execute, and get outputs from, the units in that order. Algorithm 1 formalizes what is known in the state of the art as the Gauss–Seidel orchestrator. It computes the behavior trace of a given co-simulation scenario as described in Equation (2). To be concise, we abbreviate the output and state transition function calls, which depend on the kind of unit (lines 11, 19, and 21). Furthermore, the orchestrator provides the inputs ( $u c_{σ (j)} or u p_{σ (j)}$ , in line 19) that each unit expects, working for both reactive and delayed units alike. This is the main reason we single out this orchestrator in this work.

Algorithm 1 Gauss–Seidel orchestrator for co-simulation scenarios can be topologically sorted.
Data: The stop time T, a starting communication step size $\hat{H}$ , and a set of unit references
$D = {1, \dots, n}$ .
1 $t : = 0$ ; //Simulation time
2 $H : = \hat{H}$ ; //Communication step size
//Initialize variables
3 for $i = 1, \dots, n$ do
4 $x_{i} : = 0$ ; //State vector
5 $u c_{i} : = y_{i} : = 0$ ; //Current I/O variables
6 $u p_{i} : = 0$ ; //Previous input variables
7 end
//Compute initial states
8 for $j = 1, \dots, n$ do
9 $u c_{σ (j)} : = c_{σ (j)} (y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
10 $x_{σ (j)} : = Ini t_{σ (j)} (u c_{σ (j)}) or Ini t_{σ (j)} ()$
11 $y_{(σ j)} : = G_{σ (j)} (t, x_{σ (j)}, u c_{σ (j)}) or G_{σ (j)} (t, x_{σ (j)})$ ;
12 $u p_{σ (j)} : = u c_{σ (j)}$ ;
13 end
14 while $t < T$ do
15 $accepted : = false$ ;
16 while $not accepted$ not
17 for $j \in (1, \dots, n)$ do
18 $u c_{σ (j)} : =$
$c_{σ (j)} (y_{1}, \dots, y_{σ (j) - 1}, y_{(j) + 1}, \dots, y_{n})$ ;
19 $〈 {\tilde{x}}_{σ (j)}, {\tilde{H}}_{σ (j)} 〉 : =$
$F_{σ (j)} (t, H, x_{σ (j)}, u c_{σ (j)} or u p_{σ (j)})$ ;
20 $y_{σ (j)} : = G_{σ (j)} (t + {\tilde{H}}_{σ (j)}, x_{σ (j)}, u c_{σ (j)})$
21 $or G_{σ (j)} (t + {\tilde{H}}_{σ (j)}, x_{σ (j)})$ ;
22 end
23 $\tilde{H} : = min_{i \in D} ({\tilde{H}}_{i})$ ;
24 if $\tilde{H} < H$ then
25 $H : = \tilde{H}$ ;
26 else
27 $accepted : = true$ ;
28 end
29 end
//Commit state and update I/O
30 for $j = 1, \dots, n$ do
31 $x_{i} : = {\tilde{x}}_{i}$ ;
32 $u p_{i} : = u c_{i}$ ;
33 end
34 $t : = t + H$ ; //Advance time
35 end

Without loss of generality, we assume the most basic step size control policy in Algorithm 1: the communication step size is never increased after being rejected by some unit.^a The orchestrator uses the most recent consistent state.

2.2. FMI Standard

The FMI Standard⁴ defines the interface and interaction pattern that allows simulation units to communicate. In the standard, a simulation unit is called a Functional Mockup Unit (FMU).

2.2.1. FMUs and simulation units

This subsection establishes the equivalence between FMUs and simulation units (recall Figure 1), and the assumptions we make throughout this paper.

Given a simulation unit i (described in Equation (1)), we define its equivalent FMU, and vice versa, as follows:

FMU State: the state of the FMU corresponds to the state of the unit $x_{i}$ . The FMU does not make the state explicit, but instead implements functions that can be used to set and retrieve the state.

Inputs: FMUs have input ports, each accepting a scalar quantity. Each dimension in the input $u_{i}$ corresponds to one input port of the FMU. The FMU implements functions that allow the orchestrator to set those inputs (e.g., fmi2SetReal and fmi2SetInteger) and a single vector quantity $u_{i}$ can be set via multiple calls to those functions.

Outputs: the outputs of the FMU are analogous to the inputs. To obtain an output $y_{i}$ , multiple calls are made to the dedicated functions (e.g., fmi2GetReal and fmi2GetInteger).

Initial State: the initial state computed by the $Ini t_{i}$ function corresponds to the computation performed by the FMU in the initialization mode. We assume that an initial state of a unit/FMU can always be found from the $Init (\dots)$ function (and initial input, in case of a reactive unit). This is in accordance with the FMI Standard, but it restricts our scope to scenarios in which the consistent initial state of one unit depends on factors (e.g., the initial state of another unit) other than its initial inputs.

Co-simulation step: a state transition invocation $〈 {\tilde{x}}_{i}, {\tilde{H}}_{i} 〉 : = F_{i} (t, H, x_{i}, u_{i})$ is mapped to (in order): an optional invocation to set the state of the FMU to $x_{i}$ ; multiple invocations to set the input $u_{i}$ ; an invocation to the fmi2DoStep function; a query to find out up to which time the FMU computed the step (to get ${\tilde{H}}_{i}$ ); and an (optional) invocation to get the new state of the FMU ${\tilde{x}}_{i}$ . The manipulation of the state is optional for orchestration algorithms that do not perform rollback operations. However, in this paper we assume that the FMUs support rollback.

Output function: if the unit is a Mealy unit, then the execution of the output function $y_{i} : = G_{i} (t, x_{i} (t), u_{i} (t))$ corresponds to setting the inputs to the FMU, and then getting the outputs. If the unit is a Moore unit, then the outputs can be enquired without first setting the inputs.

It is the role of the orchestrator to set the appropriate inputs depending on whether the FMU is reactive or delayed, or Mealy or Moore.

We define the type of the FMU by applying the following rules, in order:

If the unit does not disclose any input-to-output feedthrough, it is assumed to be Mealy.

If at least one output variable depends instantaneously on an input variable, we assume that the unit is Mealy.

If the previous two rules do not apply, the unit is assumed to be Moore.

If the capability flag canInterpolateInputs is set, then the unit is reactive.

Otherwise, the unit is delayed.

To establish the equivalence of the couplings restrictions of units and those of FMUs, we note that the definition of algebraic dependency remains the same between FMUs. Thus, the dataflow graph can be built as described in the previous subsection.

Having established the equivalence between simulation units and FMUs, we will henceforth use the two terms interchangeably.

2.3. Semantic adaptation

The interface of an FMU (or of a simulation unit) comprises not only the specification of the inputs and outputs, but also how it is to be interacted with.¹⁴ It may be the case that in different co-simulation scenarios, the same FMU has to be interacted with differently (e.g., for accuracy/performance concerns). While modifying the orchestrator to support a new interaction pattern will solve the problem, it is not ideal since: (a) the interaction pattern may be specific to a single FMU (therefore not reusable); and (b) modifications to the orchestrator may require extensive testing to ensure that it retains its correctness properties (e.g., see the work of Gheorghe et al.²²).

Our work avoids changes to the underlying orchestration algorithm, and focuses on those changes around the FMU itself in the form of semantic adaptations, using hierarchical co-simulation.

An adaptation targets an FMU, or group of FMUs, which we will call the internal FMU(s), and the end result of an adaptation is a new FMU, which we call the external FMU. The external FMU interacts with the internal FMU(s) without requiring them to be modified (modularity). The adjectives internal and external reflect the hierarchical nature of our approach and are illustrated in Figure 2.

Figure 2.

Internal FMUs, external FMU, and semantic adaptation.

We introduce below a non-exhaustive list of semantic adaptations that can be classified according to the interaction mismatch they intend to correct:

Signal data mismatch: conversion of units and reference frame translation.

Model of computation mismatch: hold, quantization, data-triggered execution, and timed transitions.

Capability mismatch: interpolation/extrapolation of inputs, fixed-point iteration, multi-rate adaptation, time and partial derivative adaptation, accurate threshold crossing, and re-initialization.

See the work of Gomes et al., and references thereof, for variants of these adaptations.^8,17

2.3.1. Conversion of units and reference frame translation

The conversion of units and reference frame adaptations take an internal FMU and create an external FMU whose inputs/outputs are algebraic transformations of the input/outputs of the internal FMU.

2.3.2. Interpolation/extrapolation of inputs

An FMU that stands for a continuous system, such as a DC motor, approximates its behavior trace by discretizing the time continuum into a finite set of points²³ and applying a numerical method at each of those points.

In co-simulation, when the orchestrator asks an FMU to compute the behavior trace over an interval of time, from t to $t + H$ , the FMU discretizes the interval and computes the internal solution at each of these points, called micro-steps. The most common FMUs assume that between t and $t + H$ the inputs provided by the orchestrator are constant. Naturally, for large H, this assumption causes a significant error in the co-simulation.^10,24–26

Instead of reducing H, it is possible to adapt the FMU to better approximate its inputs. Essentially, the external FMU discretizes the interval $t \to t + H$ and runs the state transition function of the internal FMU multiple times, providing an approximated input at each of the time points. The internal FMU will still assume a constant input, but will do so in smaller intervals of time.

2.3.3 Fixed-point iteration

If an algebraic loop exists, then the involved units will belong to the same cycle in the corresponding dependency graph.

As proposed by Gomes and by Van Acker et al.,^8,16 given a co-simulation scenario (recall Equation (2)) that has one cycle involving at least two simulation units (non-trivial), it is possible to create an external FMU that replaces all the units in the cycle. All the couplings external to the cycle become couplings to the hierarchical simulation unit.

At each state transition of the external FMU, a fixed-point iteration technique is applied to the inputs/outputs of the internal FMUs.

If a scenario has multiple non-trivial cycles, this adaptation can be applied to reduce the scenario to one in which all the algebraic loops are solved.¹⁶ Algorithm 1 can then be applied to compute the co-simulation.

2.3.4. Multi-rate adaptation

For FMUs simulating first-order ordinary differential equations (ODEs), the larger the interval between the points, the less accurate the computed behavior trace will be.²⁷

The multi-rate adaptation is used to increase the accuracy while not sacrificing the performance in a co-simulation. Applied to co-simulation, the technique, well known in the circuit simulation domain,²⁸ consists of groups of interconnected internal FMUs that communicate more frequently.^16,29 This can serve two purposes: optimize the communication cost between the internal units;⁸ or optimize the accuracy of the co-simulation (especially when the internal units are physically tightly coupled¹⁷).

Similarly to the input extrapolation adaptation, the state transition function of the external unit instructs the internal units to perform multiple steps and exchange values at each of those steps. The higher the rate of the adaptation, the higher the number of internal steps performed.

This adaptation can be combined with the approximation of inputs adaptation to provide for approximated inputs at each of the internal state transition invocations.

2.3.5. Time and partial derivative adaptation

Time and partial derivative information about each simulation unit’s outputs can be used to optimize the co-simulation process in many different ways (e.g., see Sicklinger et al.’s article³⁰).

In the FMI Standard, since the FMUs can optionally provide time and partial derivative information, it is often the case that some units do not support it. To mitigate this, a derivative adaptation can be used to produce an external FMU that provides (numerically estimated) partial and time derivatives.

2.3.6. Accurate threshold crossing

A co-simulation trace is more accurate if all units exchange values at the time when a certain signal crosses a given threshold. The problem of accurately finding that time is well known in the hybrid system simulation domain,^31,32 and many techniques exist to address it.^23,27 In FMI co-simulation, the most basic technique to accurately locate a crossing consists of rejecting a step size and proposing a new one, that possibly coincides with the threshold crossing moment.

The accurate zero crossing adaptation ensures that the external FMU rejects the proposed step size when one of the inputs of the internal FMU crosses a significant threshold too late.¹⁵

2.3.7. Re-initialization

An internal FMU that is expecting a smooth input signal may yield unexpected behavior traces when given a discontinuous signal (we consider a discontinuous signal to be a sufficiently rapidly changing one in between co-simulation communication points).^10,33,34 For example, an FMU that is using a multi-step numerical solver that assumes the input to be continuous (see Andersson et al. for a possible solution to this problem³⁵).

A re-initialization adaptation ensures that the external unit: (a) locates accurately the time of the discontinuity (e.g., in the same manner as the accurate crossing adaptation); and (b) the external unit is properly reset before handling the new value of the input. In the FMI Standard, item (b) requires three steps: save the unit state; reset and initialize the unit; and restore the state.

2.3.8. Quantization

Quantization is an adaptation commonly used to convert a continuous signal into a discrete event one. The (continuous) set of possible input values is discretized into regions and, during the co-simulation, whenever the continuous signal enters a new region, an event is produced.^36,37

In co-simulation, this adaptation transforms an internal FMU that expects continuous inputs and produces continuous outputs, into an external FMU that deals with events (see the works by Awais et al., Bolduc and Vangheluwe, Camus et al., and Quesnel et al.^38–41).

The realization of this adaptation is very similar to the zero crossing one, except that the thresholds to locate are induced by the input space discretization.

2.3.9. Hold

The hold family of adaptations can be seen as the dual of the multi-rate adaptations.

If an internal FMU should run slower than the rest of the simulation units, then it can be adapted with a hold adaptation. The external FMU will trick the orchestrator and obey the proposed step sizes, but will avoid executing the internal FMU every time a step is requested. For example, if a zero-order hold adaptation is used, then the external unit will produce an output that is equal to the most recent output produced by the internal unit.

There are many variants of this adaptation, with varying degrees of accuracy, borrowed from well-known approximation techniques.²⁷

The two adaptations below are novel in FMI-based co-simulation domain, but well known in the discrete event domain.

2.3.10. Data-triggered execution

The data-triggered execution is an adaptation most useful when the modeler knows that a particular internal FMU will only produce relevant behavior when certain conditions are true over its inputs. The adaptation executes the internal FMU only when these conditions are met.

2.3.11. Timed transitions

The time transition adaptation can be used when the internal FMU is known to have internal state changes, triggered after a known amount of time. The adaptation will query the internal FMU to know when exactly the next state transition function call should take place, and will call it only when that time arrives. It can be combined with the data-triggered execution to achieve a lazy execution of units.

Each of the semantic adaptations described above has many variants that make their ad-hoc implementation not only error prone, but also tedious. Additionally, one can extract the shared commonalities in the implementation of all semantic adaptations. The interplay between many small variants and shared commonalities is one of the motivating factors to use a domain-specific language (DSL) for the description of the adaptations.

2.4. Domain-specific languages

DSLs offer a way to deal with the essential complexity of a given domain, while avoiding its accidental complexity.⁴²

We highlight two important advantages that come from the use of a DSL in the context of our contribution:

The most common tasks in the target domain are performed in a very simple, productive, and intuitive manner (for a trained domain expert)—the descriptions made in our DSL do not deal with the idiosyncrasies of an implementation of the FMI Standard, even though an FMI-compliant external FMU can be generated.

By maximally constraining the user, a DSL ensures that he or she makes fewer mistakes and allows domain-level validation—our DSL allows the user to specify extra information that can be used to detect mistakes (a simple validation being the compatibility of units in inputs/outputs).

3. Running example

To showcase the language, the case study we present is adapted from a power window system, described by Prabhu and Mosterman⁴³ and Denil.⁴⁴ This system is the familiar automated car window, which responds to the driver/passenger pressing up/down buttons to raise/lower it. If an obstruction is detected, the window retracts for a few moments to avoid injury. This example was chosen for its heterogeneity and need for semantic adaptations.

3.1. The example scenario

Figure 3 shows the co-simulation scenario of the power window, consisting of five FMUs, with the illustrated input and output ports. The figure is a block representation of a co-simulation scenario as described in Equation (2). The FMUs were produced by the authors using independent tools.

Figure 3.

Power window co-simulation scenario.

The environment FMU, coded manually, is an abstraction of the behavior of the driver and passenger. Whenever the driver/passenger pushes a button up/down, the respective output will pulse to signal the event. When the button is released, the stop output pulses.

The controller FMU, produced from the Yakindu Statecharts tool, represents the software subsystem that ensures the safe operation of the window. It gets Boolean pulse inputs and decides whether the motor should go up or down, through its Boolean pulse outputs. If an object is detected (that is, obj_detected pulses) and the passenger (or driver) has pushed the up button, then the controller should instruct the DC motor to go down for 1 s. This is done by pulsing the down output and, after 1 s, pulsing the stop output.

The power is an ODE-based unit, exported with OpenModelica, representing the DC motor and the up/down switched circuit that drives the motor. Whenever the u input is greater than $0.5$ , the DC motor moves the window up. Analogously, whenever the d input is greater than $0.5$ , it moves the window down.

The window and obstacle are stateless units, coded manually, that map the inputs to the outputs using algebraic equations. The obstacle FMU outputs a force proportional to how compressed it is. Non-zero compression happens only when the input displacement exceeds a given threshold (e.g., $0.45 m$ ).

An object is detected when the armature_current spikes, caused by a sudden increase in the reaction_torque input of the DC motor, cause in turn by an increase in the reaction_forced of the object being compressed.

As illustrated in the figure, all units in this example are reactive, so the controller, power, window, and obstacle form a single cycle. The power and controller are Moore and the remaining units are Mealy.

Figure 4 shows the behavior trace of the example produced via a monolithic model produced in OpenModelica.⁴⁵ In the figure, the driver continuously pushes the up button, asking the controller to move the window up, but the controller detects an object at about 2.5 s (due to the armature current spike), which causes it to override the requests of the driver and retract the window for 1 s.

Figure 4.

Power window monolithic simulation results.

3.2. Semantic adaptations

The scenario presented in Figure 3 cannot be used as is to compute a co-simulation such as the one shown in Figure 4 because the FMUs are incompatible.

The adaptations that need to be made were introduced in Section 2, and are detailed in the list below and illustrated in Figure 5. These will be referred to throughout this paper.

lazy_sa– for controller:

execute only if the inputs change (data-triggered execution);

execute only when its state transition needs to be called (timed transition adaptation) due to internal triggers. In FMI, this information can be obtained by asking controller to perform a very large step;

zero-order hold its outputs.

controller_sa– for lazy_sa:

map the armature_current to a Boolean signal object_detected that is true whenever there is a threshold crossing. The condition that defines the crossing is $| armature_current | > 5$ ^b and the lazy_sa unit should be invoked at the time of crossing;

convert output, taking into account the stop signal.

window_sa– for window:

negate the reaction_torque value;

convert the units of height from centimeters to meters.

power_sa– for power:

ignore the algebraic loop between controller and power, and between power and window, by delaying the outputs of power by one co-simulation step. This effectively makes the external FMU a delayed unit.

loop_sa– for window_sa and obstacle:

solve the algebraic loop between obstacle and window_sa by successive substitution providing an initial guess for height.

rate_sa– in order to prevent divergence in the fixed-point iteration caused by the above adaptation, smaller communication step sizes should be taken between the obstacle and the window FMUs. To this end:

use a multi-rate adaptation, where loop_sa is executed 10 times faster than the remaining scenario;

interpolate the input signal motor_speed.

Figure 5.

The modeled adaptations in the power window example.

4. Hierarchical co-simulation for semantic adaptation

The most straightforward way of dealing with semantic adaptations is by creating a master algorithm that implements them. There are multiple problems with this approach: (a) it forces the master algorithm to be specific to the scenario, which hinders the potential for reuse; and (b) it violates the transparency principle by not allowing the FMU (plus adaptations) to be easily imported onto other tools that perform co-simulation, such as Simulink^®, INTO-CPS,⁴⁶ or DACCOSIM.⁴⁷

To avoid these problems, we implement the semantic adaptations as FMUs in a hierarchical way. In fact, our language defines semantic adaptations (plus internal FMUs) as FMUs themselves, allowing for adaptations to be described “on top of” other adaptations. This way, the orchestrator and semantic adaptations can be clearly separated, as well as the semantic adaptations between themselves.

As part of our contribution, we extend the definitions provided in Section 2 to explain what hierarchical co-simulation is, and we give an overview on how the main semantic adaptations are implemented.

4.1. Hierarchical co-simulation

Before giving the formal definition of hierarchical co-simulation, we start with an example of what a “default” hierarchical co-simulation unit is and what it does.

A default hierarchical simulation unit is one that wraps a set of connected internal units, along with their interdependencies, and behaves in a manner that is indistinguishable from any other simulation unit. The internal FMUs have internal inputs/outputs (in between the units) and external inputs/outputs. This is called the default hierarchical unit because it does not adapt the behavior of the internal units. It merely wraps them.

To give details about how the default hierarchical unit is constructed, we extend the definition of the co-simulation scenario to make the distinction between internal and external inputs. Let $u_{ext}$ denote the input vector that is external to the co-simulation scenario. A co-simulation scenario with $D = {1, \dots, n}$ units, and with external input $u_{ext}$ , is then described as:

\begin{matrix} {\begin{matrix} 〈 x_{i} (t + {\tilde{H}}_{i}), {\tilde{H}}_{i} 〉 = F_{i} (t, H, \dots) \\ y_{i} (t) = G_{i} (t, \dots) \\ u_{i} (t) = c_{i} (u_{ext} (t), y_{1} (t), \dots, y_{i - 1} (t), y_{i + 1} (t), \dots, y_{n} (t)) \\ x_{i} (0) = Init (\dots) \end{matrix} \\ for each i \in D \end{matrix}

(3)

Given a co-simulation scenario as defined in Equation (3), and assuming that the topological order $σ : N \to D$ is well defined, the default hierarchical reactive Mealy FMU is constructed by the following steps:

Aggregate the state $x_{i}$ and the previous input $u p_{i}$ of each FMU i into a single entity $x$ that becomes the state of the hierarchical unit.

Implementing the state transition function as a single co-simulation step of Algorithm 1.

Formally, the unit is defined as in Equation (4):

\begin{matrix} 〈 x (t + \tilde{H}), \tilde{H} 〉 = F (t, H, x (t), u_{ext} (t + H)) \\ y (t) = G (t, x (t), u_{ext} (t)) \\ x (0) = Init (u_{ext} (0)) \end{matrix}

(4)

where: $x = {[u p_{1}, \dots, u p_{n}, x_{1}, \dots, x_{n}]}^{T}$ is the total state vector and ${[\cdot]}^{T}$ is the matrix transpose operation; the initial state vector is calculated by the Init function, defined in Algorithm 2, which finds the initial inputs and states to each of the internal units depending on their types; $u_{ext}$ is the external input vector; function G is described in Algorithm 3, which computes the outputs of all internal units from the given inputs; and function F is detailed in Algorithm 4, which executes a single co-simulation step of Algorithm 1 and returns the minimum step size selected.

Algorithm 2 Init function of the default hierarchical reactive Mealy, described in Equation (4).
1 Function $Init (u_{ext})$
2 for $i = 1, \dots, n$ do
3 $x_{i} : = u p_{i} : = y_{i} : = 0$ ;
4 end
5 for $j \in (1, \dots, n)$ do
6 $u p_{σ (j)} : =$
$c_{σ (j)} (u_{ext}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
7 $x_{σ (j)} : = Ini t_{σ (j)} (u p_{σ (j)}) or Ini t_{σ (j)} ()$ ;
8 $y_{σ (j)} : = G_{σ (j)} (0, x_{σ (j)}, u p_{σ (j)})$
9 $or G_{σ (j)} (0, x_{σ (j)})$ ;
10 end
11 return ${[u p_{1}, \dots, u p_{n}, x_{1}, \dots, x_{n}]}^{T}$ ;
12 end

Algorithm 3 Output function of the default hierarchical reactive Mealy, described in Equation (4).
1 Function $G (t, {[u p_{1}, \dots, u p_{n}, x_{1}, \dots, x_{n}]}^{T}, u_{ext}$
2 for $i = 1, \dots, n$ do
3 $u c_{i} : = y_{i} : = 0$ ;
4 end
5 for $j \in (1, \dots, n)$ do
6 $u c_{σ (j)} : =$
$c_{σ (j)} (u_{ext}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
7 $y_{σ (j)} : = G_{σ (j)} (t, x_{σ (j)}, u c_{σ (j)})$
8 $or G_{σ (j)} (t, x_{σ (j)})$ ;
9 end
10 return ${[y_{1}, \dots, y_{n}]}^{T}$ ;
11 end

Algorithm 4 State transition function of the default hierarchical reactive Mealy, described in Equation (4).
1 Function
$F (t, H, {[u p_{1}, \dots, u p_{n}, x_{1}, \dots, x_{n}]}^{T}, u_{ext})$
2 for $i = 1, \dots, n$ do
3 $u c_{i} : = y_{i} : = 0$ ;
4 end
5 for $j \in (1, \dots, n)$ do
6 $u c_{σ (j)} : =$
$c_{σ (j)} (u_{ext}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
7 $〈 {\tilde{x}}_{σ (j)}, {\tilde{H}}_{σ (j)} 〉 : =$
$F_{σ (j)} (t, H, x_{σ (j)}, u c_{σ (j)} or u p_{σ (j)})$ ;
8 $y_{σ (j)} : = G_{σ (j)} (t + {\tilde{H}}_{σ (j)}, {\tilde{x}}_{σ (j)}, u c_{σ (j)})$
9 $or G_{σ (j)} (t + {\tilde{H}}_{σ (j)}, {\tilde{x}}_{σ (j)})$ ;
10 end
11 $\tilde{H} : = min_{i \in D} ({\tilde{H}}_{i})$ ;
12 return $〈 {[u c_{1}, \dots, u c_{n}, {\tilde{x}}_{1}, \dots, {\tilde{x}}_{n}]}^{T}, \tilde{H} 〉$ ;
13 end

The construction of the default hierarchical reactive Moore, delayed Mealy, or delayed Moore is done similarly and we omit it. The next subsection presents similar constructions for all kinds of units, incorporating adaptations.

The default hierarchical unit gives the basic transformation that underlies the semantic adaptation of one, or a connected group of, internal FMU(s). In the following subsection we describe the generic mechanism that enables the creation of hierarchical units with semantic adaptations.

4.2. Generic semantic adaptation

Previous work^14,15 supports the hypothesis that any semantic adaptation can be described by the following elements that mediate the interactions of the external FMU with the internal units:

external input rules, describing how the inputs provided to the external FMU are stored in the state of the external FMU;

internal input rules, detailing how the values stored internally are mapped into inputs of the internal FMUs;

control rules, determining what happens when the state transition function of the external FMU is invoked;

internal output rules, describing how the outputs of the internal FMUs are stored in the state of the external FMU;

external output rules, detailing how the values stored in the state of the external FMU are mapped to output values of the external FMU.

This subsection formalizes how a generic external FMU incorporating the above rules is constructed.

To formalize the above rules, we define the state of the external FMU. The external FMU is constructed from a given co-simulation scenario, defined in Equation (3), with $D = {1, \dots, n}$ units and external input vector $u_{ext}$ . Its state is then defined as $x = {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T}$ with $x_{in}$ , $x_{ctrl}$ , and $x_{out}$ denoting the input, output, and control storage vectors, respectively, and $x_{1}, \dots, x_{n}$ being the internal units’ states. The vectors $x_{in}$ , $x_{ctrl}$ , and $x_{out}$ form the semantic adaptation storage and depend on the adaptations implemented in the external FMU.

Depending on the kind of external FMU being constructed, its initial state is computed by

\begin{matrix} Init (u_{ext}) = {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T} \\ or Init () = {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T} \end{matrix}

where $Init ()$ , to be detailed shortly, makes use of the initialization functions $Ini t_{i}$ of the internal units to get their initial states.

We now introduce the formal representation of the semantic adaptation rules, introduced at the beginning of this subsection:

The application of the external input rules to the provided input is

In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext}) = {\tilde{x}}_{in}

The application of the internal input rules to create the internal input vector is denoted as

MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, h, dt) = {[{\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}]}^{T}

This function is used whenever the input to any of the internal units needs to be computed. It is used in the Ctrl rules (defined next) and in the output function of the external unit. In most adaptations, this function is invoked immediately before a call to the state transition function $F_{i}$ of any internal unit. In line with the FMU interface, h is the communication step size that will be passed to the state transition $F_{i}$ invocation, dt is the displacement of the time in unit i, relative to the external unit, and ${\tilde{u}}_{i}$ denotes the vector that will be used as the external input to unit i, or ignored if the unit does not depend on the external input. Multiple calls to this function can be made—potentially one per internal state transition call.

The application of the control rules, to compute the new state ${\tilde{x}}_{i}$ of each internal unit i, the step size advanced $\tilde{H}$ , and the new control/output storage state ${\tilde{x}}_{ctrl}, {\tilde{x}}_{out}$ of the semantic adaptation, is

\begin{matrix} Ctrl (t, H, {[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[x_{1}, \dots, x_{n}]}^{T}) = \\ 〈 {\tilde{x}}_{ctrl}, {\tilde{x}}_{out}, {[{\tilde{x}}_{1}, \dots, {\tilde{x}}_{n}]}^{T}, \tilde{H} 〉 \end{matrix}

This function invokes the MapIn/MapOut functions before/after a state transition of an internal unit is invoked.

The application of the internal output rules

MapOut ([x_{in}, x_{ctrl}, x_{out}]^{T}, {[y_{1}, \dots, y_{n}]}^{T}, h, dt) = {\tilde{x}}_{out}

Analogously to MapIn, the invocation of this function is controlled by Ctrl. Parameters h and dt denote the communication step size and time displacement, passed as arguments to the most recently invoked state transition function $F_{i}$ .

The application of the external output rules to compute the external outputs, from the semantic adaptation state

Out ({[x_{in}, x_{ctrl}, x_{out}]}^{T}) = y

Intuitively, the internal input/output functions serve to decouple the rate of execution of the internal units from the rate of execution of the external FMU.

A semantic adaptation is a concrete definition of:

storage structure— $x_{in}$ , $x_{ctrl}$ , and $x_{out}$ ;

initialization— $Init ()$ ;

external input rules—In;

internal input rules—MapIn;

control rules—Ctrl;

internal output rules—MapOut;

external output rules—Out;

We now describe how these functions are used in the specification of an external FMU.

The generic external unit is defined exactly as a simulation unit (recall Equation (1)):

\begin{matrix} 〈 x (t + \tilde{H}), \tilde{H} 〉 = F (t, H, x (t), {\tilde{u}}_{ext} (t + H) or u_{ext} (t)) \\ y (t) = G (t, x (t), u_{ext} (t)) or G (t, x (t)) \\ x (0) = Init (u_{ext}) or Init () \end{matrix}

(5)

where $x = {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T}$ denotes the state of the external FMU. Both an external reactive or delayed unit has the same implementation of F, described in Algorithm 5 (but note that the definition of Ctrl will likely differ). The definitions of G differ for a Mealy or Moore external unit, and are detailed in Algorithm 6.

Algorithm 5 State transition function of the generic external FMU, defined in Equation (5).
1 Function
$F (t, H, {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T}, u_{ext})$
2 ${\tilde{x}}_{in} : = In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext})$ ;
3 $〈 {\tilde{x}}_{ctrl}, {\tilde{x}}_{out}, {[{\tilde{x}}_{1}, \dots, {\tilde{x}}_{n}]}^{T}, \tilde{H} : 〉 =$
$ctrl (t, H, {[{\tilde{x}}_{in}, x_{ctrl}, x_{out}]}^{T}, {[x_{1}, \dots, x_{n}]}^{T})$ ;
4 return $〈 {[{\tilde{x}}_{in}, {\tilde{x}}_{ctrl}, {\tilde{x}}_{out}, {\tilde{x}}_{1}, \dots, {\tilde{x}}_{n}]}^{T} \tilde{H} 〉$ ;
5 end

Algorithm 6 Output functions of the generic external FMU, per kind of unit, defined in Equation (5).
1 Function $G (t, H, {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T}, u_{ext})$
2 ${\tilde{x}}_{in} : = In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext})$ ;
3 if $σ$ is defined then
4 for $i = 1, \dots, n$ do
5 $u c_{i} : = y_{i} : = {\tilde{y}}_{i} : = 0$ ;
6 end
7 for $j \in (1, \dots, n)$ do
8 ${[{\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}]}^{T} : =$
$MapIn ({[{\tilde{x}}_{in}, x_{ctrl}, x_{out}]}^{T}, 0, 0)$ ;
9 $u c_{σ (j)} : =$
$c_{σ (j)} ({\tilde{u}}_{σ (j)}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
10 $y_{σ (j)} : = G_{σ (j)} (t, x_{σ (j)}, u c_{σ (j)})$
11 $or G_{σ (j)} (t, x_{σ (j)})$ ;
12 ${\tilde{x}}_{out} : =$
$MapOut ({[{\tilde{x}}_{in}, x_{ctrl}, x_{out}]}^{T}, y_{1}, \dots, {y_{n}}^{T}, 0, 0)$ ;
13 end
14 else
15 ${\tilde{x}}_{out} : = x_{out}$ ;
16 end
17 $y : = Out ({[{\tilde{x}}_{in}, x_{ctrl}, {\tilde{x}}_{out}]}^{T})$ ;
18 return $y$ ;
19 end
20 Function $G (t, {[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T}$
21 if $σ$ is defined then
22 for $i = 1, \dots, n$ do
23 $u c_{i} : = y_{i} : = {\tilde{y}}_{i} : = 0$ ;
24 end
25 for $j \in (1, \dots, n)$ do
26 ${\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}^{T} : =$
$MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, 0, 0)$ ;
27 $u c_{σ (j)} : =$
$c_{σ (j)} ({\tilde{u}}_{σ (j)}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
28 $y_{σ (j)} : = G_{σ (j)} (t, x_{σ (j)}, u c_{σ (j)})$
29 $or G_{σ (j)} (t, x_{σ (j)})$ ;
30 ${\tilde{x}}_{out} : =$
$MapOut ({[{\tilde{x}}_{in}, x_{ctrl}, x_{out}]}^{T}, y_{1}, \dots, {y_{n}}^{T}, 0, 0)$ ;
31 end
32 else
33 ${\tilde{x}}_{out} : = x_{out}$ ;
34 end
35 $y : = Out ({[x_{in}, x_{ctrl}, {\tilde{x}}_{out}]}^{T})$ ;
36 return $y$ ;
37 end

In Algorithm 6, we stress the following:

The definitions take into account that it may not be possible to sort the internal units topologically, so the semantic adaptations support dependency cycles.

Multiple calls to G can be made without changing the state of the external unit.

If a Moore external FMU has at least one internal unit that depends on external input, then this input must be stored in the input storage $x_{in}$ of the semantic adaptation by the In function (line 2 of Algorithm 5), and then retrieved by the MapIn function (line 8 of Algorithm 6).

To make these definitions easier to understand, we provide two examples: the default reactive Mealy hierarchical unit presented in the previous subsection, and the algebraic loop semantic adaptation that involves the obstacle and window_sa units of the power window example (loop_sa).

The default reactive Mealy hierarchical unit can be informally described as follows:

The state $x_{ctrl}$ of the semantic adaptation includes the previous inputs of the internal units.

The Init function is analog to the one described in Algorithm 2.

The In, MapIn, MapOut, and Out are roughly identity functions.

The Ctrl function implements the body of F in Algorithm 4.

Formally, functions Init and Ctrl are defined in Algorithm 7, and:

\begin{matrix} In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext}) = u_{ext} \\ MapIn ([x_{in}, x_{ctrl}, x_{out}], h, dt) = \\ {[{\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}]}^{T}, with {\tilde{u}}_{i} = x_{in} \\ MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[y_{1}, \dots, y_{n}]}^{T}, h, dt) = \\ {[y_{1}, \dots, y_{n}]}^{T} \\ Out ({[x_{in}, x_{ctrl}, x_{out}]}^{T}) = x_{out} \end{matrix}

(6)

Algorithm 7 Init and Ctrl functions of the default reactive Mealy hierarchical unit.
1 Function $Init (u_{ext})$
2 for $i = 1, \dots, n$ do
3 $x_{i} : = u p_{i} : = y_{i} : = 0$ ;
4 end
5 for $j \in (1, \dots, n)$ do
6 $u p_{σ (j)} : =$
$c_{σ (j)} (u_{ext}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
7 $x_{σ (j)} : = ini t_{σ (j)} (u p_{σ (j)}) or ini t_{σ (j)} ()$ ;
8 $y_{σ (j)} : = G_{σ (j)} (0, x_{σ (j)}, u p_{σ (j)})$
9 $or G_{σ (j)} (0, x_{σ (j)})$ ;
10 end
11 $x_{in} : = x_{out} : = 0$ ;
12 $x_{ctrl} : = {[u p_{1}, \dots, u p_{n}]}^{T}$ ;
13 return ${[x_{in}, x_{ctrl}, x_{out}, x_{1}, \dots, x_{n}]}^{T}$ ;
14 end
15 Function
$Ctrl (t, H, 〈 x_{in}, {[u p_{1}, \dots, u p_{n}]}^{T}, x_{out} 〉, {[x_{1}, \dots, x_{n}]}^{T})$
16 $x_{ctrl} : = {[u p_{1}, \dots, u p_{n}]}^{T}$ ;
17 for $i = 1, \dots, n$ do
18 $u c_{i} : = y_{i} : = 0$ ;
19 end
20 for $j \in (1, \dots, n)$ do
21 ${[{\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}]}^{T} : =$
$MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, 0, 0)$ ;
22 $u c_{σ (j)} : =$
$c_{σ (j)} ({\tilde{u}}_{σ (j)}, y_{1}, \dots, y_{σ (j) - 1}, y_{σ (j) + 1}, \dots, y_{n})$ ;
23 $〈 {\tilde{x}}_{σ (j)}, {\tilde{H}}_{σ (j)} 〉 : =$
$F_{σ (j)} (t, H, x_{σ (j)}, u c_{σ (j)} or u p_{σ (j)})$ ;
24 $y_{σ (j)} : = G_{σ (j)} (t + {\tilde{H}}_{σ (j)}, {\tilde{x}}_{σ (j)}, u c_{σ (j)})$
25 $or G_{σ (j)} (t + {\tilde{H}}_{σ (j)}, {\tilde{x}}_{σ (j)})$ ;
26 ${\tilde{x}}_{out} : =$ ;
$MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, y_{1}, \dots, {y_{n}}^{T}, 0, 0)$ ;
27 end
28 $\tilde{H} : = min_{i \in D} ({\tilde{H}}_{i})$ ;
29 return
$〈 {[u c_{1}, \dots, u c_{n}]}^{T}, {\tilde{x}}_{out}, {[{\tilde{x}}_{1}, \dots, {\tilde{x}}_{n}]}^{T}, \tilde{H} 〉$ ;
30 end

The second example refers to the adaptation loop_sa, which essentially performs a fixed-point iteration between the obstacle and window_sa units, computing improved values for their input/outputs via successive substitution.

The external FMU, called loop_sa in Figure 5, is a reactive Moore unit, and has an input $u_{ext} \in R^{2}$ with two dimensions (displacement and speed) and one output (tau). Whenever the state transition of the external FMU is called, a successive substitution is performed between the two internal units, using the most recently found value of disp as an initial guess. Formally, let the index $1$ refer to the window_sa unit, and $2$ to obstacle, so that, for example, $u c_{2}$ refers to the input to the obstacle unit. For the sake of simplicity, we assume that the system starts with all inputs/outputs being zero. Then, the functions that characterize the adaptation are shown in Equation (7). Note that had we not assumed that the system starts with zero inputs/outputs, the Init would have to compute a fixed-point iteration to find a consistent initial state. This is possible with our formalization.

Section 5 describes a DSL for the definition of such semantic adaptations. The examples provided there clarify the need for the semantic adaptation functions defined in the current section.

\begin{matrix} Init (u_{ext}) = {[0, 0, 0, Ini t_{1} (0), Ini t_{2} (0)]}^{T} \\ In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext}) = u_{ext} \\ MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, h, dt) = {[x_{in}, 0]}^{T} \\ MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[y_{1}, y_{2}]}^{T}, h, dt) = y_{1} \\ Out ({[x_{in}, x_{ctrl}, x_{out}]}^{T}) = [\begin{matrix} 1 & 0 & 0 \\ 0 & 1 & 0 \end{matrix}] x_{out} \end{matrix}

(7)

Ctrl is defined in Algorithm 8.

Algorithm 8 Ctrl function of external FMU loop_sa, illustrated in Figure 5.
1 Function $Ctrl (t, H, {[x_{in}, y p_{1}, x_{out}]}^{T}, {[x_{1}, \dots, x_{n}]}^{T})$
2 $u_{1} : = 0$ ;
3 $y_{1} : = y p_{1}$ ;
4 $u_{2} : = y p_{2} : = y_{2} : = 0$ ;
5 ${[{\tilde{u}}_{1}, {\tilde{u}}_{2}]}^{T} : = MapIn ({[x_{in}, y p_{1}, x_{out}]}^{T}, 0, 0)$ ;
6 for $i \in (1, \dots, MAX_ITERATIONS)$ do
7 $u_{2} : = c_{2} ({\tilde{u}}_{2}, y_{1})$ ;
8 $〈 {\tilde{x}}_{2}, {\tilde{H}}_{2} 〉 : = F_{2} (t, H, x_{2}, u_{2})$ ;
9 $y_{2} : = G_{2} (t + {\tilde{H}}_{2}, {\tilde{x}}_{2}, u_{2})$ ;
10 $u_{1} : = c_{1} ({\tilde{u}}_{1}, y_{2})$ ;
11 $〈 {\tilde{x}}_{1}, {\tilde{H}}_{1} 〉 : = F_{1} (t, H, x_{1}, u_{1})$ ;
12 $y_{1} : = G_{1} (t + {\tilde{H}}_{1}, {\tilde{x}}_{1}, u_{1})$ ;
13 if $‖ y_{1} - y p_{1} ‖ \approx 0 and ‖ y_{2} - y p_{2} ‖ \approx 0$ then
14 ${\tilde{x}}_{out} : =$
$MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[y_{1}, y_{2}]}^{T}, 0, 0)$ ;
15 break;
16 else
17 $y p_{1} : = y_{1}$ ;
18 $y p_{2} : = y_{2}$ ;
19 end
20 return $〈 y_{1}, {\tilde{x}}_{out}, {[{\tilde{x}}_{1}, {\tilde{x}}_{2}]}^{T}, H 〉$ ;
21 end

5. A DSL for semantic adaptation

We introduce a DSL for the specification of the set of rules introduced in Section 4 (which form a semantic adaptation). Since research in semantic adaptation is ongoing, the language should be expressive enough to cover future semantic adaptations. Additionally, the implementation should not violate the modularity and transparency principles.

To these ends, the DSL—named baseSA—mixes imperative concepts with convenient functions that perform common operations on simulation units. A description made in this DSL can be used to generate hierarchical units.

The language and the examples used in this paper are available for download.^c

baseSA allows the description of the internal FMUs and their couplings (i.e., the internal scenario as described in Equation (3)), and how semantic adaptation rules (Init, In, MapIn, Ctrl, MapOut, and Out) are implemented.

The remainder of this section is organized as follows. First, the baseSA DSL is introduced by describing the semantic adaptations of the running example and what their intended meaning is. Then, a more detailed description of the language (syntax and semantics) is provided.

5.1. The baseSA DSL

Listing 1 shows the baseSA definition of the semantic adaptation that generates the window_sa in Figure 5. The first few lines (lines 1 and 2 in the example) of any description declare the name of the semantic adaptation and where the resulting external FMU will be generated.

Listing 1.

The simple data adaptation window_sa in baseSA.

Following that, the internal scenario is declared. The example listing (lines 4–7) declares a single internal FMU and its ports.

baseSA descriptions work by exclusion: the user only specifies what needs to be changed, and the rest is assumed from the information provided. Hence, Listing 1 only needs to declare the output ports of the external FMU (disp and tau), in line 13, and how they get their values: disp gets its value implicitly from the height port, and tau gets its value explicitly (via the specification of output rules).

Lines 11–15 declare the output rules. These specify how the tau output port of the external FMU gets its value, and this is done by assigning it the value of the reaction_torque output port, of the window FMU. The example declares a single output rule, but in general multiple output rules can be declared. In general, each output rule has three parts: a condition, a MapOutRule part (syntactically preceded by “->”), and an OutRule part (syntactically preceded by “–>”). The condition decides whether the rule should be applied, and the other two parts contribute to the definition of the corresponding functions MapOut and Out, respectively.

Following the exclusion principle, Listing 1 omits several bits of information about the external FMU that are required for a full definition of a semantic adaptation: input ports; Init function; In function; MapIn function; and Ctrl function.

In general, this information is assumed by applying multiple conventions, detailed in Section 5.3. The intended behavior is to follow the default hierarchical unit definition wherever the information is omitted (recall Equation (6) and Algorithm 7). For the example in Listing 1, the following is applicable:

The external FMU (windowSA) has an input port for every input port of any internal FMU that has no incoming connection. This means that windowSA has three input ports, each bound to the corresponding input port of the internal FMU window.

Each of the input ports of the internal FMU that have no incoming connections gets its value from the corresponding external input port declared by the previous convention. The implementation of bindings is made via a storage variable. In Listing 1, this means that an extra input rule is created to encode the transfer of values. The input storage variables are also created.

Any output variable bindings are realized in a manner similar to the previous convention: add an output rule and declare the necessary output variables to perform the transfer of values.

Any expression referring to the output of any internal FMU, in the Out part of an output rule, is assumed to refer to the storage variable with the most recent value of that output (output variables are created for the outputs of each internal FMU). In Listing 1, this means that window.reaction_force, in line 13, gets replaced by a reference to an output variable.

After applying the previous two conventions, the implicit bindings are removed.

Listing 2 shows the same adaptation as Listing 1, after applying the conventions introduced above:

All input ports and output ports of the external FMU are declared, with no implicit bindings defined.

Input storage variables, and their initial values, are declared (stored_windowsa_reaction_force, stored_windowsa_displacement, stored_windowsa_speed). These are part of the $x_{in}$ state vector of the semantic adaptation.

Output storage variables, and their initial values, are declared (stored_window_reaction_torque and stored_window_height), comprising part of the $x_{out}$ state vector.

A parameter per storage variable is added to allow the configuration of the initial value of that variable (technical detail: the parameters are mapped to FMI parameters).

Input rules, as the one in lines 31–41, are in general composed of two parts: the InRule part, which in the example assigns values to the input storage variables; and the MapInRule part, which assigns the stored values to the input ports of the internal FMUs in the example. These make up the respective functions In and MapIn.

The control rules make use of the special function H_window := do_step(window, t, H), which: automatically uses the MapIn function to compute the inputs to the internal FMU window; computes any extra internal input (this applies to internal interconnected units); invokes the state transition function of window with t and H, and invokes the MapOut function to compute its outputs. do_step also takes into account the type (Mealy/Moore and reactive/delayed) of the internal unit invoked. The returned value is the step size taken by the unit.

Output rules define the functions MapOut (which stores the outputs of window in the output storage variables) and Out (which sets the outputs of the external FMU from the output storage variables). Notice that the conversion of units between the height and disp ports is also done.

Listing 2.

The adaptation window_sa in explicit form.

In any baseSA description, there is no need to define explicitly the initial state (computed by the Init function). It is inferred from the input, control, and output storage variables, plus the information about the internal units (extracted from their XML description file).

Listing 3 describes the adaptation defining the external FMU loop_sa in Figure 5. The adaptation is targeted at two internal FMUs (window_sa and obstacle) that are interconnected as specified in lines 14–15. In general, the internal connectivity information is needed so that the generated code knows how to set the inputs to the internal FMUs. The listing does not declare input ports; therefore, according to the general conventions, the external FMU has all the input ports that have no incoming connections (displacement and speed). A single output port is declared (tau), which gets its value from the tau output of window_sa.

Listing 3.

Adaptation that generates loop_sa.

Notice that the external FMU is declared as reactive Moore, and that the internal FMUs cannot be topologically sorted. Whenever this is the case, when the external output function is called, the values of the output ports returned (in the example, the value of tau) are the ones computed in the most recent state transition function.

The control block of Listing 3 implements Algorithm 8 with the following differences.

As part of the semantics of the do_step function: the MapInRule and MapOutRule instructions (which are implicit in Listing 3 by convention) are executed automatically to set the inputs of the internal FMUs; and the inputs of each FMU, if unspecified by an assignment, are set according to the internal connectivity information declared in lines 14–15.

The convergence test (line 33) is made only in the disp port (to simplify).

The state manipulation of the internal FMUs is facilitated by the use of the save_state and rollback functions.

The rate_sa adaptation is implemented in Listing 4. It is worth noticing the MapIn portion of the input rules, in line 33, which calculates the interpolation of the speed value. This function is called whenever inputs to the internal FMUs need to be provided, with $h = micro_step$ being the communication step size asked to the internal FMU ( $micro_step$ refers to the argument used in the state transition invocation, in line 20), and $dt = inner_time - t$ (where $inner_time$ is the argument used for the state transition call).

Listing 4.

Adaptation that generates rate_sa.

Listing 5 implements adaptation lazy_sa. This adaptation assumes the default mappings for the inputs, but declares them because they are referred to in the Ctrl block.

Listing 5.

Adaptation that generates lazy_sa.

In general, every reference to an input port of the external FMU, made outside of the In block, is replaced with a reference to the variable that stores the most recently given value of that. For example, the expression lazy_sa.obj_detected is replaced by the variable that stores that input.

The adaptation in Listing 5 performs two tasks: it keeps track of the previous value of each signal, and invokes the internal unit state transition function (i.e., the do_step) whenever there is a change; and it keeps track of the next time to execute the internal unit (assuming that no inputs change) and invokes it when such time arrives, to cater for internal timed transitions. At the same time, the output signals are always available (held constant) because of the storage output variables.

The adaptation controller_sa is shown in Listing 6. The control rules apply regula falsi to locate the crossing of the armature signal into the threshold T.

Listing 6.

Adaptation that generates controller_sa.

This example shows how the conditions in the output rules can be used to select which rules are applied. Informally, in general, at the end of each external state transition, when MapOut is invoked, all the conditions in the rules are evaluated. The ones that evaluate to true are recorded as part of the $x_{out}$ state. Afterwards, whenever Out is called, only the rules that evaluated to true contribute to the output of Out.

The power_sa adaptation was omitted due to its simplicity. It declares the external FMU as a delayed Moore and lists the output port bindings.

The above adaptations generate the FMUs for the co-simulation scenario illustrated in Figure 5. The orchestrator in Algorithm 1 then computes the results shown in Figure 6. Comparing these results with the ones in Figure 4, one sees that they are similar, except for the fact that the armature current has a higher peak in the co-simulation. This is because the threshold crossing adaptation was disabled, since the power FMU does not support rollback.

Figure 6.

Power window co-simulation results.

In the following subsections, we describe the language (syntax and semantics) in more detail. The syntax is described using extended Backus–Naur form (EBNF),⁴⁸ and the semantics are presented informally by describing a transformation of baseSA descriptions to the Init, In, MapIn, Ctrl, MapOut, and Out functions, introduced in line 13.

5.2. Syntax

The partial syntax of baseSA is detailed in Listing 7. We omit the definition of the most common symbols:

ID is an identifier;

URL is a URL;

PhysicalUnit denotes any physical unit;

Expression is an expression that defines a value—for example, comparison, addition, constant, variable reference, etc.

Statement is a programming language statement. It includes if-statement, static for loop, local variable declarations, assignments, references to variables/parameters, built-in function calls, etc.

Listing 7.

The (partial) EBNF grammar of baseSA.

Table 1 summarizes the special functions and variables.

Table 1.

List of built-in symbols and their meaning.

Symbol	Availability	Description
$t \in R$	ControlRule (Ctrl)	Argument provided in the state transition function of the external FMU
$H \in R$	ControlRule (Ctrl)	Co-simulation step size passed as argument to the state transition function of the external FMU
$do_step (fmu, t_{i}, h) \in R$	ControlRule (Ctrl)	Asks an internal FMU to perform a co-simulation step and returns the size of the computed interval
$h \in R$	MapInRule, MapOutRule ( $MapIn, MapOut$ )	Co-simulation step size passed as argument to the state transition function of the internal FMU
$dt \in R$	MapInRule, MapOutRule ( $MapIn, MapOut$ )	Let $t_{i}$ denote the time given as argument to the state transition function of an internal FMU; then $dt = t_{i} - t$
$save_state (fmu)$	ControlRule (Ctrl)	Stores the state of an internal FMU
$rollback (fmu)$	ControlRule (Ctrl)	Rolls back an internal FMU to the last saved state
$is_close (x, y, rtol, atol) \in Bool$	Everywhere	Approximate equality
$get_next_time_step (fmu) \in R$	Everywhere	Returns the maximum time step an internal FMU is willing to accept
$\sin, \cos, min, \dots$	Everywhere	Implements the corresponding mathematical function

The full grammar definition, and an editor of baseSA descriptions, developed with Xtext,⁴⁹ is available for download.^c Figure 7 shows the editor interface.

Figure 7.

The baseSA editor.

5.3. Semantics

In this subsection, we define the semantics by describing informally how each syntactic construction in baseSA is mapped to the definition of Init, In, MapIn, Ctrl, MapOut, and Out functions, introduced in Section 4 (recall Figure 1). This is done in two stages: first, we detail how any baseSA description is reduced to its explicit form; and then we describe how each baseSA description in explicit form can be mapped to the semantic functions.

5.3.1 Reduction to explicit form

Let sa be the name of a given baseSA description. For the sake of brevity, we make the assumption that every port has a unique name (this is not assumed by the code generator).

In order to reduce the given baseSA description to its explicit form, the following rules are applied in order, with the description resulting from the application of one rule being used in the next rule.

AddInPorts—for each input port ip of any internal FMU f that has no incoming connections, create an external input port declaration ip -> f.ip, if there is none already declared with the same name.

AddInParams—for each external input port declaration ip, create a parameter declaration INIT_SA_IP := v (if it does not exist already), where v is the default value of the parameter.

AddInVars—for each declared external input port ip, declare an input variable stored_sa_ip := INIT_SA_IP (if it does not exist) with initial value equal to the corresponding declared parameter in the previous rule.

AddInRule—prepend a new rule to the input rules block, with a true condition, and: in the InRule part, for each declared external input port ip, add an assignment stored_sa_ip := sa.ip; in the MapInRule part, for each input binding declared ip -> f.ip, create an assignment f.ip := ip. If units need to be converted, the right-hand side of the assignment is replaced accordingly.

RemoveInBindings—for each input binding declared ip -> f.ip, replace it by just ip. Any physical unit declaration is also removed.

AddOutPorts—if no output ports are declared, create an output port declaration op <- f.op per output port op of each internal unit f.

AddOutParams—analogous to AddInParams: for each output port declaration op of each internal FMU f, create a parameter declaration INIT_F_OP := v (if such parameter does not exist), with v being the default value.

AddOutVars—analogous to AddInVars: for each output port declaration op of each internal FMU f, create an output variable declaration stored_f_op := INIT_F_OP, if it does not exist already.

AddOutRule—prepend a new output rule to the output rules block, with a true condition, and: in the MapOutRule part, add an assignment stored_f_op := f.op, per output port op of each internal unit f; in the OutRule part, for each output binding op <- f.op declared, add an assignment sa.op := f.op. If units need to be converted, the assignment is replaced accordingly.

RemoveOutBindings—analogous to RemoveInBindings: for each declared output binding op <- f.op, remove the binding (and any unit declaration), leaving just the output declaration op.

CreateCtrlRules—if there is no control rules block declared, create one, and: compute the topological order $σ$ of the internal scenario (if it cannot be computed, abort with an error); for each internal unit declaration f, in topological order, append var $H_{f}$ := do_step(f, t, H); append (at the end of the block) either return H_f if there is only one internal FMU, or return min( $H_{1}$ , …, $H_{n}$ ), where $H_{i}$ refers to each of the local variables declared in the previous assignments.

ImplementInternalBinding—for each connection in the internal scenario f1.op -> f2.ip, locate the do_step(f2, …) instruction in the control rules block. Before this instruction, if there is no assignment of the form f2.ip := …, insert f2.ip := f1.op immediately before the instruction do_step(f2, …).

ReplacePortsRefsByVars—for every input rule, go through the MapInRule part and replace every reference to an external input port ip by a reference to the stored_sa_ip input variable. In the control rules block, replace every reference to an output port op of an internal unit f by a reference to the corresponding storage variable stored_f_op. For each output rule, in the OutRule part, replace any reference to an output port op of an internal unit f by a reference to the corresponding storage variable stored_f_op.

Listing 2 is the result of applying the above rules to Listing 1.

5.3.2. Mapping to generic semantic adaptation

Given a baseSA description in explicit form, we now explain how it is mapped to the formal definition of a generic external unit. In the generic external unit definition (recall Equation (5)), the elements that need to be defined are:

the space of $x_{in}$ , $x_{ctrl}$ , and $x_{out}$ ;

$Init (u_{ext}) or Init ()$ , depending on the kind of external unit;

$In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext})$ ;

$MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, h, dt)$ ;

$Ctrl (t, H, {[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[x_{1}, \dots, x_{n}]}^{T})$ ;

$MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[y_{1}, \dots, y_{n}]}^{T}, h, dt)$ ;

$Out ({[x_{in}, x_{ctrl}, x_{out}]}^{T})$ ;

Each of the above elements are now defined.

Part of $x_{in}$ is determined by the input variables declared: $x_{in}$ has one dimension per declared input variable. The type of the dimension (real, Boolean, etc.) corresponds to the type of the declared variable. In addition, $x_{in}$ has one Boolean dimension per input rule. For example, is there are three numeric variables declared, and one input rule, then $x_{in} \in R^{3} \times Bool$ .

Analogously to $x_{in}$ , $x_{out}$ has one dimension per declared output variable, and an additional Boolean dimension per declared output rule.

The control storage vector $x_{ctrl}$ has one dimension per declared control variable. Additionally, if the semantic adaptation is a reactive one and the initial baseSA description (not the explicit one) does not include any control rules, the $x_{ctrl}$ has one dimension per internal delayed unit.

The external input function

In ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, u_{ext}) = {\tilde{x}}_{in}

is defined to perform the following steps in order:

Evaluate all conditions of the input rules in the order that they are declared, and for each condition, mark the corresponding location of ${\tilde{x}}_{in}$ with the outcome (true or false).

For the input rules whose conditions evaluated to true in the previous step, execute the InRule part, in the order that the rules are declared (this computes the remainder of ${\tilde{x}}_{in}$ ).

Function

MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, h, dt) = {[{\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}]}^{T}

executes the MapInRule part of the input rules whose condition evaluated to true (this information is stored in $x_{in}$ ) in order of their declaration. The executed input port assignments form ${[{\tilde{u}}_{1}, \dots, {\tilde{u}}_{n}]}^{T}$ .

Function

MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[y_{1}, \dots, y_{n}]}^{T}, h, dt) = {\tilde{x}}_{out}

is analogous to In. It evaluates all the conditions of the output rules in the order that they are declared, and for each of those conditions, marks the appropriate location of ${\tilde{x}}_{out}$ with the outcome of the condition evaluation. Then it computes the remaining portion of ${\tilde{x}}_{out}$ by executing the MapOutRule part of each of the output rules whose conditions evaluated to true.

Function

Out ({[x_{in}, x_{ctrl}, x_{out}]}^{T}) = y

is analogous to MapIn. It executes the OutRule part of the output rules whose condition evaluated to true (in the order in which they are declared) to compute the output vector $y$ .

The role of the initialization function (derived automatically from the baseSA description) is to find a consistent initial state, defining the initial values of the storage vectors $x_{in}$ , $x_{out}$ , and $x_{ctrl}$ . If the semantic adaptation is declared as reactive, then Init requires the initial input, according to Equation (1).

First, the parts of $x_{in}$ , $x_{ctrl}$ , and $x_{out}$ that correspond to the declared input/control/output variables are initialized according to the initial value that is declared for them.

If it exists, the part of $x_{ctrl}$ that corresponds to the previous inputs to the internal units is initialized by computing the initial input to all the internal units in the topological order (such order exists by assumption). This is similar to Algorithm 2, except that the functions In, MapIn, and MapOut are invoked to adapt any external input to the internal units, and initialize the condition flags.

Function

\begin{matrix} Ctrl (t, H, {[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[x_{1}, \dots, x_{n}]}^{T}) = \\ 〈 {\tilde{x}}_{ctrl}, {\tilde{x}}_{out}, {[{\tilde{x}}_{1}, \dots, {\tilde{x}}_{n}]}^{T}, \tilde{H} 〉 \end{matrix}

runs the instructions declared in the control rules block in the order that they are declared. The assignments performed to control variables make up part of the output vector ${\tilde{x}}_{ctrl}$ . The executed assignments to the input ports of each internal FMU i, up to the instruction $do_step (i, t_{i}, h_{i})$ , make up part of the unit input vector $u_{i}$ .

Any variable reference in the control rules block refers to the most recently given value of that variable.

Each instruction $do_step (i, t_{i}, h_{i})$ maps to the following steps, performed in Ctrl:

Invoke MapIn function to compute the external input of unit i:

\begin{matrix} {[\dots, {\tilde{u}}_{i}, \dots]}^{T} : = \\ MapIn ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, h_{i}, t_{i} - t) \end{matrix}

(8)

Note that ${\tilde{x}}_{ctrl}$ represents the control state vector that was affected by the assignments made since the beginning of the execution of the Ctrl function. $x_{in}$ and $x_{out}$ represent the (unchanged) vector provided as input to Ctrl.

Merge the input vector $u_{i}$ computed by previous assignments with ${\tilde{u}}_{i}$ to form the unit input $u c_{i}$ ;

Invoke the state transition function of the unit:

\begin{matrix} 〈 {\tilde{x}}_{i}, {\tilde{H}}_{i} 〉 : = F_{i} (t, H, x_{i}, u c_{i} or u p_{i}) \end{matrix}

(9)

Get the output of the unit:

\begin{matrix} y_{i} : = G_{i} (t + {\tilde{H}}_{i}, {\tilde{x}}_{i}, u c_{i}) or G_{σ (j)} (t + {\tilde{H}}_{i}, {\tilde{x}}_{i}) \end{matrix}

(10)

Invoke the MapOut function to compute an updated output storage vector:

\begin{matrix} {\tilde{x}}_{out} : = \\ MapOut ({[x_{in}, x_{ctrl}, x_{out}]}^{T}, {[y_{1}, \dots, y_{n}]}^{T}, h_{i}, t_{i} - t) \end{matrix}

(11)

Finally, upon returning, if the external FMU is a reactive unit, and the initial baseSA description does not declare a control rules block, Ctrl stores the most recent inputs provided to each delayed internal units in the ${\tilde{x}}_{ctrl}$ vector, to be used as delayed inputs in a subsequent external state transition call. This instruction is similar to line 29 of Algorithm 7.

6. Evaluation

In this section we judge how well our approach answers the research question posed in this work.

The requirements set by the research question are:

Productivity: does the language have impact on the productivity of its users?

Expressivity: is the language expressive enough to cover current and future needs?

Modularity: do the internal FMUs need to be changed?

Transparency: does the external FMU behave exactly as an FMU?

6.1. Productivity

In general, DSLs have the potential to boost users’ productivity.^42,50 For baseSA, we describe an early experiment to assess the productivity.

6.1.1. Goals

Productivity is measured by comparing the time it takes for a trained user to: (a) create an external FMU using our DSL; and (b) code the same external FMU.

As a surrogate measure, we compare the approximate number of lines of code (LOCs) required for a semantic adaptation coded by hand, with the LOCs of the corresponding semantic adaptation expressed in baseSA.

6.1.2. Experimental setup

As part of the development of the code generator, all semantic adaptations identified in Figure 5, except rate_sa, were coded by hand and the effort taken was recorded.

6.1.3. Results

Table 2 shows the adaptation, the approximated LOCs, and the effort in coding the semantic adaptations in C.

Table 2.

Effort in hand-coding hierarchical semantic adaptations.

Semantic adaptation	Lines of code	Effort (person-hours)
lazy_sa	700	9
controller_sa	750	24
power_sa	680	16
window_sa	690	8
loop_sa	690	16
Total	3510	73

As Table 2 shows, even though the semantic adaptations differ in complexity, they have a similar number of LOCs. This is evidence that there is a large portion of code dedicated to common FMI-related management tasks. With baseSA, the user does not have to code the following:

Memory management: the inputs, outputs, and local variables of the external FMU are stored in dynamically allocated memory.

Variable dereferencing: to set/get values to/from an internal FMU, a list of value references (integers which identify a variable) has to be provided. Any mistake here may cause the internal FMU to give the wrong results, but not necessarily crash, which makes it hard to debug.

State management: the external FMU has to support rollback, and for that the state variables must be properly serialized and deserialized. In the case study, each semantic adaptation requires approximately 140 LOCs to implement the set/get state.

Consistent inputs management: the external FMU, which is reactive and has internal delayed units, has to keep track of the previous inputs to these.

6.1.4. Threats to validity

LOCs is only a surrogate measure for the productivity of a DSL, albeit a common one,⁵¹ and depends on the programmer. However, the tasks described in the above list are handled automatically by the code generator of baseSA .

The values provided in Table 2 lack external validation. We intend to perform a second round of experiments in which we will ask a participant to code a semantic adaptation, then train him or her and measure the effort it takes to code the same adaptation in baseSA.

6.2. Expressivity

The baseSA DSL is imperative in the sense that it describes how the semantic adaptations are performed. However, it forces a structure in the definition of the semantic adaptations, aided by the distinction between data (input/output rules) and control adaptations. We argue that this structure does not restrict the expressiveness of the semantic adaptations.

To provide evidence for this, we describe how the adaptations used in the case study are representative of the semantic adaptations and coupling algorithms surveyed by Gomes et al.¹⁷

Extrapolation/interpolation schemes: these techniques,^{10,27,33,34,52–54} are similar to rate_sa.

Jacobi-based orchestration: this orchestration algorithm,^{11,47,55–60} is similar to the Gauss–Seidel coupling except that it assumes that all units are delayed. A way to implement it as a semantic adaptation is to define a control rule that sets explicitly the inputs to the internal FMUs, and then invokes the do_step function on them.

Algebraic constraint couplings: this coupling technique,^24,25,30,61 can be implemented by a fixed-point iteration (recall adaptation loop_sa) and extra algebraic computations on the units’ inputs and outputs.

Semi-implicit coupling: these techniques,^25,62–65 are similar to the ones above, except they perform two iterations only.

Error control: Richard extrapolation^9,47,66 can be implemented by creating a semantic adaptation that runs a whole scenario at twice the rate of the original one; multi-order input extrapolation^59,67 amounts to implementing two approximation schemes (see item above) run in parallel; the embedded method⁶⁸ requires that a semantic adaptation is implemented to perform a discretized numerical integration of some of the signals in the internal scenario; energy-based techniques⁶⁹ can be implementing by coding semantic adaptations which monitor for energy dissipativity in some of the signals in the internal FMUs.

We do restrict the expressiveness of the language, with the intent of guaranteeing that it terminates:

No function definitions are allowed.

No recursive definitions of semantic adaptations are allowed.

For loops must have a static range.

These restrictions make expressing some of the above techniques more cumbersome, but not impossible.

6.3. Modularity

The simulation unit specification, introduced in Equation (1), was shown to be a valid abstraction of an implementation of an FMU in Section 2. Furthermore, it is clear that changing the implementation of any of the functions $Init, G, F$ implies a change in the FMU implementation. In Section 5.3 these functions are invoked as part of the implementation of each semantic adaptation, but never changed, thus showing that the corresponding FMU implementations are not affected by the implementation of the language.

6.4. Transparency

Section 4 describes how a generic semantic adaptation forms a simulation unit that obeys the definition in Equation (1) (see Equation (5)). Furthermore, Section 5.3 describes how baseSA is implemented by “filling in” the semantic adaptation functions that are used in Section 4. The semantics does not require the hierarchical unit definition, in Equation (5), to be changed. Therefore, our approach does not violate transparency.

7. Discussion and future work

This section discusses some of the characteristics and limitations of our contribution, and research opportunities for the future.

Automatic semantic adaptation identification. Throughout this work, we assumed that the user knows that an adaptation is required in order to make the co-simulation possible. An interesting research direction is to explore what means can be employed in trying to identify the need for specific semantic adaptations.

Runtime performance. Despite not being our primary goal, the performance of the generated FMU should be similar to a custom-coded one. To this end, the code generator under development performs most tasks at compile time. However, we have not carried out any experiments to measure the performance of the generated code.

A research direction is to explore how to merge multiple adaptations, to avoid generating the intermediate hierarchical FMUs. For example, in Figure 5, adaptations loop_sa and rate_sa could be merged into one single adaptation, provided that the user has no intention of using loop_sa for other purposes. However, while it is clear what the result should be for this example, in general this is a non-trivial task: When can two arbitrary adaptations be merged?

Solving this problem brings a performance benefit, but also provides new insights into the nature of adaptations. In addition, one can ask: If two semantic adaptations can be combined, are they commutative? This question is important because it allows us to optimize. If there is a semantic adaptation that will cause rollbacks, we want it to be the first to execute, to avoid wasting computation. An example of this is the controller_sa, which performs the crossing location before the lazy_sa gets the opportunity to run.

Trying to answer the above questions will inevitably lead to another question: What is the right level of abstraction to analyze the combination of semantic adaptations? This question is related to the next discussion topic.

Usability and productivity. As part of trying to find out what is the right level of abstraction to analyze semantic adaptations, we are developing a new language that allows for a more declarative description of semantic adaptations. This language, as opposed to baseSA, allows for a much more concise description of the most common semantic adaptations by just enumerating what semantic adaptations should be used to form the external FMU.

The descriptions made in this language compile to baseSA, whose role is to provide a solid foundation.

The main benefits of using this language are:

The user does not need to know how semantic adaptations are implemented.

It is minimal, meaning that it enables the user to specify common semantic adaptations (e.g., multi-rate, successive substitution) as concisely as describing them in natural language.

It further restricts the user into using well-known semantic adaptations, which prevents mistakes.

It may provide insight into the research questions identified in the previous subsection.

Listing 8 shows an example of what such a DSL looks like. The syntax reuses part of the syntax of baseSA. The description of the FMUs can be done in a separate module, which is then imported (line 1). For this example, the FMUs are described as in lines 4–15 of Listing 3. After the preliminaries, the description of each semantic adaptation occupies one line (line 6 for loop_sa and line 7 for rate_sa). In this language, adaptations are applied in order, meaning that the outermost adaptation is the multi-rate one.

Listing 8.

Example description in higher-level semantic adaptation domain-specific language.

Each adaptation has some degree of configuration. For example, the multi-rate is configurable with an input approximation adaptation. This highlights another interesting research direction, related to the combination of semantic adaptations: How and when can semantic adaptations interface with each other? In this example, it is clear that any input approximation adaptations can complement a multi-rate adaptation, but what are the essential characteristics of input approximation and multi-rate adaptations that make them so compatible? The same question applies to output approximation adaptations (the family of hold adaptations) and the lazy-related ones. A possible direction to explore is to look at the object-oriented world, and study how can semantic adaptations define interfaces and specialization, so that their interaction is well defined.

Discrete event FMU implementation. The current version of the FMI Standard (version 2.0) lacks essential features to enable accurate hybrid co-simulation.^70–74

Until new extensions are made, there are many different ways in which a cyber system (e.g., a state chart) can be simulated in an FMU.^7,73–77 At least one of the implementations the authors used before (the Stategraph⁷) already includes semantic adaptations to facilitate its integration with the FMI.

Our work shows that, when implementing an FMU that simulates a cyber system, it is best to leave out as many semantic adaptations as possible. The more adaptations an FMU already contains, the harder it is to adapt to other contexts.

8. Related work

Outside the context of FMI, the problem of composing and adapting operational semantics of multiple languages is discussed in numerous papers and references therein.^14,78–84

Within the context of FMI, we can divide the related works into two categories: (a) those whose prime purpose is to describe co-simulation scenarios; and (b) those that target the description of orchestration algorithms. Neither of these categories target primarily the description of semantic adaptations, but can potentially be extended to include simple descriptions. Due to our pure hierarchical co-simulation approach, our contribution complements any of these works.

Under Category (a), we highlight the work of Van Acker et al.,¹⁶ Larsen et al.,⁴⁶ Galtier et al.,⁴⁷ and Campagna et al.⁸⁵ These works introduce a language for the description of a co-simulation scenario, with the purpose of running a co-simulation. The work of Larsen et al.⁴⁶ and Galtier et al.⁴⁷ assumes that a generic orchestration algorithm is used, whereas Van Acker et al.¹⁶ and Campagna et al.⁸⁵ aim at generating an orchestrator that is specific to the scenario described. Our DSL allows for the description of a co-simulation scenario, and a specific master algorithm can be generated from that description.

DACCOSIM⁴⁷ follows a related approach with respect to hierarchical co-simulation, allowing the scenario to be grouped by computational nodes. In contrast to our work, this hierarchy is computational and not functional. Moreover, it is not transparent, as the distinction is made between local (internal to computational nodes) and global orchestrators. Nevertheless, each FMU is wrapped with code that performs error control, highlighting the need for semantic adaptation.

In Category (2), we highlight Campagna et al.,⁸⁵ Gheorghe,²² and Aslan et al.⁸⁶ The work by Campagna et al.⁸⁵ allows the description of master algorithms using the business process modeling notation. We argue that the visual notation for the description of an orchestration algorithm works well for simple cases, with two units. However, when multiple semantic adaptations become necessary, or the number of simulation units increases, the visual notation rapidly becomes cluttered. The work does not describe any intention to use the notation to describe semantic adaptations, but the notation has an extension mechanism that can in principle be used to describe simple semantic adaptations.

The most related to our own is the work of Aslan et al.⁸⁶ This introduces an object-oriented framework for co-simulation that allows for both the development of FMUs and for orchestration algorithms, in C++. Class specialization is used extensively to maximize reuse, sharing some of the benefits with our contribution. The main difference to our work is the level of abstraction and the intention to use semantic adaptations. While their work is capable of expressing semantic adaptations, our work is targeted toward that purpose. One can position their work as helping develop FMUs for simulators that need to support the FMI Standard, and our work can be used to adapt already-existing FMUs. Furthermore, the description of a complex adaptation such as rate_sa is more compact in our DSL.

9. Conclusion

This paper addressed the problem of describing the most common semantic adaptations on multiple types of black box simulation units in a productive manner while avoiding the modification of the units (modularity) and tools for co-simulation (transparency).

To make this possible, we propose a DSL, available for download,^c that is both expressive (due to its imperative nature) but also productive (due to its conventions and high-level constructs). Each description refers to a group of interconnected FMUs and dictates how those FMUs interact with the environment.

The essential mechanism that enables the semantic adaptations is the concept of hierarchical co-simulation, formalized in this work. The meaning of each adaptation is given by mapping it onto hierarchical co-simulation units, which in turn are mapped to units and FMUs, as illustrated in Figure 1.

The main distinguishing factor from the related work is our focus on semantic adaptations for FMI-based co-simulation, which imposes the modularity and transparency requirements.

This work opens up new opportunities for research into semantic adaptations—for example, how to find higher levels of abstraction to describe semantic adaptations, and explore how different semantic adaptations can interface and complement each other. We intend to explore these in the future.

Footnotes

Acknowledgements

We are grateful to Prof. Peter Gorm Larsen (Aarhus University) for the in-depth discussions regarding the potential applications of our work. Furthermore, we are in debt to the reviewers for the in-depth improvements made to this manuscript.

Funding

This research was partially supported by Flanders Make vzw, the strategic research center for the manufacturing industry, a PhD fellowship grant from the Agency for Innovation by Science and Technology in Flanders (IWT, dossier number 151067), and by the INTO-CPS project, funded by the European Commission’s Horizon 2020 program (grant number 664047).

ORCID iD

Cláudio Gomes

Notes

Author biographies

Cláudio Gomes is a PhD student in the University of Antwerp and member of the Modelling, Simulation and Design Lab (MSDL), interested in co-simulation of hybrid systems.

Bart Meyers is a research engineer at Flanders Make vzw, and is associated with the University of Antwerp, where he obtained his PhD. His main research topic is modeling of software-intensive systems.

Joachim Denil is an assistant professor in the University of Antwerp and member of the CoSys-Lab. His main research interest is multi-paradigm modeling of software-intensive systems.

Casper Thule is a PhD student at Aarhus University and member of the Software Engineering Research Group. His area of research is hybrid co-simulation and cyber–physical systems.

Kenneth Lausdahl is a postdoctoral student at Aarhus University and member of the Software Engineering Group, interested in tool automation and co-simulation of hybrid systems.

Hans Vangheluwe is a professor at the University of Antwerp, Belgium, an adjunct professor at McGill University, Canada, and an adjunct professor at the National University of Defense Technology (NUDT) in Changsha, China. He heads the MSDL research lab. His research interests include the multi-paradigm modeling of complex, software-intensive, cyber-physical systems.

Paul De Meulenaere is a professor at the University of Antwerp and member of the research group CoSys-Lab. His main research field is model-based development methods for embedded real-time systems.

References

Nielsen

Larsen

Fitzgerald

et al . Systems of systems engineering: basic concepts, model-based techniques, and research directions. ACM Comput Surv 2015; 48(2): 18:1–18:41. DOI:10.1145/2794381.

Van der Auweraer

Anthonis

De Bruyne

et al . Virtual engineering at work: the challenges for designing mechatronic products. Eng Comput 2013; 29(3): 389–408. DOI:10.1007/s00366-012-0286-6.

Vangheluwe

De Lara

Mosterman

PJ.

An introduction to multi-paradigm modelling and simulation. In: Proceedings of the AIS 2002 conference (AI, Simulation and Planning in High Autonomy Systems), Lisbon, Portugal, April 2002, pp.9–20. Berlin: Springer.

Blockwitz

Otter

Akesson

et al . Functional Mockup Interface 2.0: the standard for tool independent exchange of simulation models. In: 9th international Modelica conference, Munich, Germany, 19 November 2012, pp.173–184. Linköping: Linköping University Electronic Press.

Lee

Sangiovanni-Vincentelli

A framework for comparing models of computation. IEEE Trans Comput-Aided Des Integr Circuits Syst 1998; 17(12): 1217–1229. DOI:10.1109/43.736561.

Tripakis

. Bridging the semantic gap between heterogeneous modeling formalisms and FMI. In: International conference on embedded computer systems: architectures, modeling, and simulation (SAMOS), Samos, 19–23 July 2015, pp. 60–69. New York: IEEE.

Otter

Malmheden

Elmqvist

et al . A new formalism for modeling of reactive and hybrid systems. In 7th international Modelica conference, Como, Italy, 20–22 September 2009, pp.364–377. Linköping: Linköping University Electronic Press.

Gomes

. Foundations for continuous time hierarchical co-simulation. In: ACM student research competition (ACM/IEEE 19th international conference on model driven engineering languages and systems), Saint Malo, France, 3–5 October 2016. New York: ACM.

Arnold

Clauß

Schierz

. Error analysis and error estimates for co-simulation in FMI for model exchange and co-simulation v2.0. In: Schöps

Bartel

Günther

et al . (eds) Progress in differential-algebraic equations. Berlin: Springer.

10.

Busch

Continuous approximation techniques for co-simulation methods: analysis of numerical stability and local error. J Appl Math Mech 2016; 96(9): 1061–1081. DOI:10.1002/zamm.201500196.

11.

Bastian

Clauß

Wolf

et al . Master for co-simulation using FMI. In: 8th international Modelica conference, Dresden, Germany, 20–22 March 2011, pp.115–120. Linkpings Universitet: Linkping University Electronic Press.

12.

Gomes

Karalis

Navarro-López

et al . Approximated stability analysis of bi-modal hybrid co-simulation scenarios. In: 1st workshop on formal co-simulation of cyber–physical systems, Trento, Italy, 2 February 2018, 345–360. Berlin: Springer.

13.

Gomes

Legat

Jungers

et al . Stable adaptive co-simulation: a switched systems approach. In: IUTAM symposium on co-simulation and solver coupling, Darmstadt, Germany, 18–20 September 2017. IUTAM.

14.

Meyers

Denil

Boulanger

et al . A DSL for explicit semantic adaptation. In Jacquet

Balasubramanian

(eds) 7th international workshop on multi-paradigm modeling, Miami, USA, 30 September 2013, pp.47–56. Berlin: Springer.

15.

Denil

Meyers

De Meulenaere

et al . Explicit semantic adaptation of hybrid formalisms for FMI co-simulation. In: Society for Computer Simulation International (ed.) Symposium on theory of modeling & simulation: DEVS integrative M&S symposium, Alexandria, VA, pp.99–106. San Diego, CA: Society for Computer Simulation International.

16.

Van Acker

Denil

Meulenaere

et al . Generation of an optimised master algorithm for FMI co-simulation. In: Society for Computer Simulation International (ed.) Symposium on theory of modeling & simulation: DEVS integrative M&S symposium, Alexandria, VA, pp.946–953. San Diego, CA: Society for Computer Simulation International.

17.

Gomes

Thule

Broman

et al . Co-simulation: state of the art. Technical report, 2017.

18.

1730-2010 – IEEE recommended practice for distributed simulation engineering and execution process (DSEEP).

19.

Kübler

Schiehlen

Two methods of simulator coupling. Math Comput Modell Dyn Syst 2000; 6(2): 93–113. DOI:10.1076/ 1387-3954(200006)6:2;1-M;FT093.

20.

Posse

de Lara

Vangheluwe

. Processing causal block diagrams with graphgrammars in atom³. In: European joint conference on theory and practice of software (ETAPS), workshop on applied graph transformation (AGT), Grenoble, pp. 23–34. Berlin: Springer.

21.

Gomes

Denil

Vangheluwe

Causal-block diagrams. Technical report, University of Antwerp, 2016, http://msdl.cs.mcgill.ca/people/claudio/pub/Gomes2016a.pdf.

22.

Gheorghe

Bouchhima

Nicolescu

et al . A formalization of global simulation models for continuous/discrete systems. In: Proceedings of the 2007 summer computer simulation conference, San Diego, USA, 15–18 July 2007, pp.559–566. San Diego, CA: Society for Computer Simulation International.

23.

Cellier

Kofman

Continuous system simulation. New York: Springer Science & Business Media, 2006.

24.

Arnold

Stability of sequential modular time integration methods for coupled multibody system models. J Comput Nonlinear Dyn 2010; 5(3): 9. DOI:10.1115/1.4001389.

25.

Schweizer

Co-simulation method for solver coupling with algebraic constraints incorporating relaxation techniques. Multibody Sys Dyn 2016; 36(1): 1–36. DOI:10.1007/s11044-015-9464-9.

26.

Andersson

Methods and tools for co-simulation of dynamic systems with the functional mock-up interface. PhD Thesis, Lund University, Sweden, 2016.

27.

Burden

Faires

JD.

Numerical analysis. 9th ed. Boston, MA: Cengage Learning, 2010.

28.

Lelarasmee

Ruehli

Sangiovanni-Vincentelli

AL.

The waveform relaxation method for time-domain analysis of large scale integrated circuits. IEEE Trans Comput Aided Des Integr Circuits Syst 1982; 1: 131–145. DOI:10.1109/TCAD.1982.1270004.

29.

González

Naya

MÁ

Luaces

et al . On the effect of multirate co-simulation techniques in the efficiency and accuracy of multibody system dynamics. Multibody Sys Dyn 2011; 25(4): 461–483. DOI:10.1007/s11044-010-9234-7.

30.

Sicklinger

Belsky

Engelmann

et al . Interface Jacobian-based co-simulation. Int J Numer Methods Eng 2014; 98(6): 418–444. DOI:10.1002/nme.4637.

31.

Zhang

Yeddanapudi

Mosterman

. Zero- crossing location and detection algorithms for hybrid system simulation. In: IFAC world congress, Seoul, 6–11 July 2008, pp.7967–7972. Amsterdam: Elsevier.

32.

Mosterman

PJ.

An overview of hybrid simulation phenomena and their support by simulation packages. In: Vaandrager

van Schuppen

(eds) Hybrid systems: computation and control. Berg en Dal: Springer, 1999, pp.165–177.

33.

Dronka

Rauh

. Co-simulation-interface for user-force-elements. In: SIMPACK user meetingBaden-Baden, 9–10 September 2008. Gilching: SIMPACK.

34.

Busch

Zur effizienten Kopplung von Simulationsprogrammen. PhD Thesis, Kassel University, Germany, 2012.

35.

Andersson

Führer

Åkesson

Efficient predictor for co-simulation with multistep sub-system solvers. Technical report, 2016. http://lup.lub.lu.se/record/dbaf9c49-b118-4ff9-af2e-e1e3102e5c22 (accessed 25 March 2018).

36.

Kofman

Junco

Quantized-state systems: a DEVS approach for continuous system simulation. Simulation 2001; 18(3): 123–132.

37.

Bolduc

Vangheluwe

Expressing ODE models as DEVS: quantization approaches. In: Proceedings of the AIS 2002 conference (AI, Simulation and Planning in High Autonomy Systems), Lisbon, Portugal, April 2002, pp.163–169. Piscataway, NJ: IEEE.

38.

Awais

Palensky

Elsheikh

et al . The high level architecture RTI as a master to the functional mock-up interface components. In: International conference on computing, networking and communications (ICNC), San Diego, USA, 28–31 January 2013, pp.315–320. New York: IEEE..

39.

Bolduc

Vangheluwe

. Mapping ODES to DEVS: adaptive quantization. In Summer computer simulation conference, Montreal, Canada, 20–24 July 2003, pp.401–407. San Diego, CA: Society for Computer Simulation International..

40.

Camus

Galtier

Caujolle

et al . Hybrid co-simulation of FMUs using DEV&DESS in MECSYCO. In: Symposium on theory of modeling & simulation: DEVS integrative M&S symposium (TMS/DEVS 16), Pasadena, USA, 3–6 April 2016. Picataway, NJ: IEEE.

41.

Quesnel

Duboz

Versmisse

et al . DEVS coupling of spatial and ordinary differential equations: VLE framework. In: Open international conference on modeling and simulation, volume 5, France, 2005, pp.281–294.

42.

Kelly

Tolvanen

JP.

Domain-specific modeling: enabling full code generation. New York: John Wiley & Sons, 2008.

43.

Prabhu

Mosterman

. Modeling, simulating, and validating a power window system using a model-based design approach. https://fr.mathworks.com/company/newsletters/articles/modeling-simulating-and-validating-a-power-window-system-using-a-model-based-design-approach.html (accessed 15 March 2018).

44.

Denil

Design, verification and deployment of software intensive systems: a multiparadigm approach. PhD Thesis, University of Antwerp, Belgium, 2013.

45.

Fritzson

Aronsson

Pop

et al . OpenModelica: a free open-source environment for system modeling, simulation, and teaching. In: Conference on computer aided control system design, international conference on control applications, international symposium on intelligent control, Munich, Germany, 4–6 October 2006, pp.1588–1595. New York: IEEE.

46.

Larsen

Fitzgerald

Woodcock

et al . Integrated tool chain for model-based design of cyber-physical systems: the INTO-CPS project. In: 2nd international workshop on modelling, analysis, and control of complex CPS (CPS data), Vienna, Austria, 11 April 2016, pp.1–6. New York: IEEE.

47.

Galtier

Vialle

Dad

et al . FMI-based distributed multi-simulation with DACCOSIM. In: Spring simulation multi-conference, Alexandria, VA, 12–15 April 2015, pp.804–811. San Diego, CA: Society for Computer Simulation International.

48.

Wirth

Extended Backus–Naur form (EBNF), 1996.

49.

Xtext: language engineering for everyone. https://eclipse.org/Xtext/index.html (accessed 15 March 2018).

50.

Kieburtz

McKinney

Bell

et al . A software engineering experiment in software component generation. In: 18th international conference on software engineering, Berlin, Germany, 25–29 March 1996, pp.542–552. New York: IEEE.

51.

Boehm

Abts

Brown

et al . Software cost estimation with Cocomo II. Upper Saddle River, NJ: Prentice Hall, 2000.

52.

Ben Khaled

Duval

Gaïd

MEMB

et al . Context-based polynomial extrapolation and slackened synchronization for fast multi-core simulation using FMI. In: 10th international Modelica conference, 10–12 March 2014, pp.225–234. Linköping: Linköping University Electronic Press.

53.

Stettinger

Horn

Benedikt

et al . Model-based coupling approach for non-iterative real-time co-simulation. In: European control conference (ECC), Strasbourg, 24–27 June 2014, pp.2084–2089. Piscataway, NJ: IEEE.

54.

Brembeck

Pfeiffer

Fleps-Dezasse

et al . Nonlinear state estimation with an extended FMI 2.0 co-simulation interface. In: 10th international Modelica conference, Lund, 10–12 March 2014, pp.53–62. Linköping: Linköping University Electronic Press.

55.

Friedrich

. Parallel co-simulation for mechatronic systems. PhD Thesis, Fakultt fr Maschinenwesen, Germany, 2011.

56.

Krammer

Fritz

Karner

. Model-based configuration of automotive co-simulation scenarios. In: 48th annual simulation symposium, Alexandria, VA, 12–15 April 2015, pp.155–162. San Diego, CA: Society for Computer Simulation International.

57.

Enge-Rosenblatt

Clauß

Schneider

et al . Functional digital mock-up and the functional mock-up interface: two complementary approaches for a comprehensive investigation of heterogeneous systems. In: 8th international Modelica conference, Dresden, Germany, 20–22 March 2011. Linköping: Linköping University Electronic Press.

58.

Asada

. Co-simulation of algebraically coupled dynamic subsystems. In: American control conference, Volume 3, Arlington, VA, 25–27 June 2002, pp.2273–2278. Piscataway, NJ: IEEE.

59.

Busch

Schweizer

. An explicit approach for controlling the macro-step size of co-simulation methods. In: 7th European nonlinear dynamics. Rome, Italy, 24–29 July 2011, pp.24–29. Darmstadt: Technische Universitat Darmstadt.

60.

Wetter

Co-simulation of building energy and control systems with the Building Controls Virtual Test Bed. J Build Perform Simul 2010; 4(3): 185–203. DOI:10.1080/19401493.2010.518631.

61.

Asada

HH.

Co-simulation of algebraically coupled dynamic subsystems without disclosure of proprietary subsystem models. J Dyn Syst Meas Contr 2004; 126(1): 1.

62.

Schweizer

Semi-implicit co-simulation approach for solver coupling. Arch Appl Math 2014; 84(12): 1739–1769.

63.

Schweizer

et al . Stabilized implicit co-simulation methods: solver coupling based on constitutive laws. Arch Appl Math 2015; 85(11): 1559–1594. DOI:10.1007/s00419-015-0999-2.

64.

Schweizer Lu

. Predictor/corrector co-simulation approaches for solver coupling with algebraic constraints. J Appl Math Mech 2015; 95(9): 911–938. DOI:10.1002/zamm.201300191.

65.

Schweizer

Stabilized index-2 co-simulation approach for solver coupling with algebraic constraints. Multibody Sys Dyn 2015; 34(2): 129–161. DOI: 10.1007/s11044-014-9422-y.

66.

Arnold

Hante

Köbis

MA.

Error analysis for co-simulation with force-displacement coupling. PAMM 2014; 14(1): 43–44. DOI:10.1002/pamm.201410014.

67.

Busch

Schweizer

Coupled simulation of multibody and finite element systems: an efficient and robust semi-implicit coupling approach. Arch Appl Math 2012; 82(6): 723–741. DOI: 10.1007/s00419-011-0586-0.

68.

Hoepfer

. Towards a comprehensive framework for co-simulation of dynamic models with an emphasis on time stepping. PhD Thesis, Georgia Institute of Technology, USA, 2011.

69.

Sadjina

Kyllingstad

Skjong

et al . Energy conservation and power bonds in co-simulations: non-iterative adaptive step size control and error estimation. Eng Comput 2017; 33(3): 607–620. DOI:10.1007/s00366-016-0492-8.

70.

Broman

Brooks

Greenberg

et al . Determinate composition of FMUs for co-simulation. In: 11th ACM international conference on embedded software, 29 September–4 October 3013, Montreal, Canada. Press Piscataway, NJ: IEEE.

71.

Broman

Greenberg

Lee

et al . Requirements for hybrid cosimulation standards. In: 18th international conference on hybrid systems: computation and control, HSCC ’15, New York, USA, 14–16 April 2015, pp.179–188. New York: ACM.

72.

Centomo

Deantoni

de Simone

. Using SystemC cyber models in an FMI co-simulation environment: results and proposed FMI enhancements. In: Euromicro conference on digital system design (DSD), Limassol, Cyprus, 13 August–2 September 2016, pp.318–325. New York: IEEE.

73.

Cremona

Lohstroh

Broman

et al . Step revision in hybrid co-simulation with FMI. In: 14th ACM-IEEE international conference on formal methods and models for system design, Kanpur, India, 18–20 November 2016. Piscataway, NJ: IEEE.

74.

Feldman

Greenberg

Palachi

. Simulating Rhapsody SysML blocks in hybrid models with FMI. In: 10th international Modelica conference, Lund, 10–12 March 2014, pp.43–52. Linköping: Linköping University Electronic Press.

75.

Tripakis

Broman

Sciences

Bridging the semantic gap between heterogeneous modeling formalisms and FMI. Technical report, 2014.

76.

Pohlmann

Schäfer

Reddehase

et al . Generating functional mockup units from software specifications. In: 9th international Modelica conference, Munich, 3–5 September 2012, pp.765–774. Linköping: Linköping University Electronic Press.

77.

Cremona

Lohstroh

Tripakis

et al . FIDE: an FMI integrated development environment. In: 31st annual ACM symposium on applied computing, SAC ’16, Pisa, 4–8 April 2016, pp. 1759–1766. New York: ACM Press.

78.

Lacoste-Julien

Vangheluwe

de Lara

et al . Meta-modelling hybrid formalisms. In: IEEE international symposium on computer aided control systems design, Taipei, Taiwan, 2–4 September 2004, pp.65–70. New York: IEEE.

79.

Davis

II Goel

Hylands

et al . Overview of the Ptolemy project. Technical report, 1999. http://ptolemy.eecs.berkeley.edu (accessed 15 March 2018).

80.

Vara Larsen

DeAntoni

Combemale

et al . A behavioral coordination operator language (BCOoL). In: 18th international conference on model driven engineering languages and systems (MODELS), Ottawa, ON, 30 September–2 October 2015, pp.186–195. New York: IEEE.

81.

Deantoni

. Modeling the behavioral semantics of heterogeneous languages and their coordination. In: Architecture-centric virtual integration (ACVI), Venice, Italy, 5–8 April 2016, pp.12–18. New York: IEEE.

82.

Mustafiz

Gomes

Barroca

et al . Modular design of hybrid languages by explicit modeling of semantic adaptation. In: Proceedings of the symposium on theory of modeling & simulation: DEVS integrative M&S symposium, DEVS ’16, Pasadena, CA, 3–6 April 2016, pp.29:1–29:8. Piscataway, NJ: IEEE.

83.

Boulanger

Hardebolle

Jacquet

et al . Semantic adaptation for models of computation. In: 11th international conference on application of concurrency to system design (ACSD), Newcastle Upon Tyne, 20–24 June 2011, pp.153–162. Piscataway, NJ: IEEE.

84.

Boulanger

Hardebolle

. Simulation of multi-formalism models with ModHel’X. In: 1st international conference on software testing, verification, and validation, Lillehammer, Norway, 9–11 April 2008, pp.318–327. New York: IEEE.

85.

Campagna

Kavka

Turco

et al . Solving time-dependent coupled systems through FMI co-simulation and BPMN process orchestration. In: IEEE international symposium on systems engineering (ISSE), Edinburgh, Scotland, 3–5 October 2016, pp.1–8. New York: IEEE.

86.

Aslan

Durak

Taylan

. MOKA: an object-oriented framework for FMI co-simulation. In: Proceeding SummerSim ‘15 Proceedings of the Conference on Summer Computer Simulation, Chicago, IL, 26–29 July 2015. New York: ACM.