Bridging the Semantic Gap Between Heterogeneous Modeling ... · Bridging the Semantic Gap Between Heterogeneous Modeling Formalisms and FMI Stavros Tripakis 1;2 David Broman 3 fstavros,[email protected]

Bridging the Semantic Gap Between Heterogeneous

Modeling Formalisms and FMI

Stavros TripakisDavid Broman

Electrical Engineering and Computer SciencesUniversity of California at Berkeley

Technical Report No. UCB/EECS-2014-30

http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-30.html

April 25, 2014

Copyright © 2014, by the author(s).All rights reserved.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission.

Bridging the Semantic Gap Between Heterogeneous Modeling

Formalisms and FMI∗

Stavros Tripakis1,2 David Broman1,3

{stavros,broman}@eecs.berkeley.edu1University of California, Berkeley 2Aalto University 3Linkoping University

April 25, 2014

Abstract

FMI (Functional Mockup Interface) is a standard for exchanging and co-simulating model components(called FMUs) coming from potentially different modeling formalisms, languages, and tools. Previouswork has proposed a formal model for the co-simulation part of the FMI standard, and also presented twoco-simulation algorithms which can be proven to have desirable properties, such as determinacy, providedthe FMUs satisfy a formal contract. In this paper we discuss the principles for encoding different modelingformalisms, including state machines, discrete-event systems, and synchronous dataflow, as FMUs. Thechallenge is to bridge the various semantic gaps (untimed vs. timed, signals vs. events, etc.) that arisebecause of the heterogeneity between these modeling formalisms and the FMI API.

1 Introduction

FMI (Functional Mockup Interface) is an evolving standard for model exchange and co-simulation [3, 4,14, 15, 16, 17]. FMI for co-simulation allows to import and co-simulate within a single framework modelcomponents which have been designed using potentially distinct modeling formalisms, languages, and tools.

The FMI standard defines an API (application programming interface) to which these model components,called FMUs (functional mockup units), must conform. Thus, each FMU can be seen as a black-box whichimplements the methods defined in the FMI API (some of these methods are optional, while others aremandatory, meaning that all FMUs must implement them).

FMUs by themselves are passive objects, in the sense that they do not execute. For that reason theyare also called slaves. To execute (simulate) an FMU, we need a so-called master algorithm (MA). The MAcoordinates the execution of a number of FMUs connected in a network. This network can be seen as theentire model, sub-models of which are FMUs. Running the MA on this global model means performing onesimulation run.

Previous work [5] proposed a formal model of (a subset of) FMI for co-simulation. That work alsoproposed two master algorithms and proved that, provided the FMUs obey a formal assume-guarantee type

∗Acknowledgments: The authors would like to thank Lev Greenberg and Michael Masin from IBM, Edward A. Lee andChristopher Brooks from UC Berkeley, and Michael Wetter from Lawrence Berkeley Labs for many exciting discussions andvaluable feedback.This work was partially supported by the Academy of Finland and by the NSF via projects COSMOI: Compositional SystemModeling with Interfaces and ExCAPE: Expeditions in Computer Augmented Program Engineering, by the iCyPhy ResearchCenter (Industrial Cyber-Physical Systems, supported by IBM and United Technologies), the Swedish Research Council (#623-2011-955), and the Center for Hybrid and Embedded Software Systems (CHESS) at UC Berkeley (supported by the NationalScience Foundation, NSF awards #0720882 (CSR-EHS: PRET), #1035672 (CPS: Medium: Timing Centric Software), and#0931843 (ActionWebs), the Naval Research Laboratory (NRL #N0013-12-1-G015), and the following companies: Bosch,National Instruments, and Toyota).

1

of contract, these two algorithms have desirable properties, such as termination and determinacy (the factthat the results of the simulation do not depend on arbitrary factors, but only on the interconnections ofthe FMUs in the network).

To our knowledge, the question how to create FMUs has not been formally addressed. This question isaddressed in this paper. One of the goals of FMI is to enable the modeling and simulation of heterogeneoussystems, that is, systems combining several modeling formalisms and languages of different type (discretevs. continuous, state machine vs. dataflow, etc.). Toward this goal, we discuss the principles of encodingdifferent modeling formalisms (state machines, discrete event, and synchronous dataflow) as FMUs.

In order to encode such a broad set of heterogeneous formalisms as FMUs we need to overcome asignificant challenge, namely, how to bridge the gap between the semantics of the original formalisms, andthe FMI API. The exact nature of this semantic gap depends on the original formalism. For instance, in thecase of encoding a finite state machine (FSM) such as a Mealy or Moore machine [10] as an FMU, we needto bridge the gap between the untimed semantics of FSMs and the timed semantics of FMI. While in thecase of encoding a discrete-event (DE) actor such as those used in Ptolemy [7, 12] as an FMU, we need tobridge the gap between the event-based semantics of DE and the persistent signal-based semantics of FMI.

2 A Formal Model for FMI

We recall the formal model for FMI proposed in [5]. An FMU is a tuple F = (S,U, Y,D, s0, set, get, doStep),where:

• S is the set of (internal) states of F . Note that an element of S is a state, not a state variable.

• U is the set of input variables of F . Note that an element u ∈ U is a variable, not a value. Eachvariable in U ranges over a set of values V. F is called a source if U is the empty set.

• Y is the set of output variables of F . Each variable in Y ranges over the same set of values V. F iscalled a sink if Y is the empty set.

• D ⊆ U × Y is a set of input-output dependencies. D specifies for each output variable which inputvariables it depends upon (if any). This information is used to ensure that a network of FMUs has nocyclic dependencies, and also to determine the order in which all network values are computed duringa simulation step [5].

• s0 ∈ S is the initial state of F .1

• set : S × U × V → S is the function that sets the value of an input variable. Given state s, inputvariable u ∈ U , and value v ∈ V, set(s, u, v) returns the new state obtained after setting u to v.

• get : S×Y → V is the function that returns the value of an output variable. Given state s and outputvariable y ∈ Y , get(s, y) returns the value of y in s.

• doStep : S ×R≥0 → S ×R≥0 is the function that implements one simulation step. Given state s, andtime step h ∈ R≥0, doStep(s, h) returns a pair (s′, h′) such that:

– either h′ = h, which is interpreted as F having accepted h, and having advanced to new state s′;

– or 0 ≤ h′ < h, which is interpreted as F having rejected h, but having made partial progress upto h′, and having reached new state s′.

1Our formalization differs in this point from the formalization in [5]. The latter considered a function init : R≥0 → S which,given as input a time t ∈ R≥0, returns the state, implicitly at that time t. This requires, for correct simulation, that all FMUsin a model are initialized to the same initial time t. We note that the initialization phase of the MAs was not discussed in [5],and the init function was not used in the algorithms presented there. Here, we take a simpler approach and consider that allFMUs are initialized to a given state at time 0.

2

2.1 Semantics of a single FMU

For pedagogical purposes, we explain first the semantics of a single FMU, and then the semantics of a networkof interconnected FMUs.

Consider an FMU F = (S,U, Y,D, s0, set, get, doStep). Since F generally has inputs, its behavior maydepend on the values that these inputs take. In addition, the behavior of F depends on the times whenfunctions such as doStep are invoked. Therefore, the behavior of F is a function of a timed input sequence(TIS). A TIS is an infinite sequence

v0h1v1h2v2h3 · · ·of alternating input assignments, vi, and time delays, hi ∈ R≥0. An input assignment is a function v : U → V.That is, v assigns a value to every input variable in U .

A TIS like the above defines a run of F , which is an infinite sequence of quadruples (t, s,v,v′), wheret ∈ R≥0 is a time instant, s ∈ S is a state of F , v is an input assignment, and v′ : Y → V is an outputassignment:

(t0, s0,v0,v′0)(t1, s1,v1,v

′1)(t2, s2,v2,v

′2) · · ·

defined as follows:

• t0 = 0 and s0 is the initial state of F .

• For each i ≥ 1, ti = ti−1 + hi, that is, ti is the sum of all delays up to the i-th step, in other words,the time when the i-th step occurred.

• For each i, v′i is obtained as follows. First, starting from the current state si, the set method is usedrepeatedly to set all input variables to the values specified by v. This results in a new state s′i. Next,starting from this new state s′i, the get method is used to read the values of all output variables. Thisresults in v′i.

Note that this step also resulted in a new, intermediate state s′i. This state is further used in computingthe next state using doStep.

• For each i, we require that doStep(s′i, hi+1) = (si+1, hi+1), where s′i is the intermediate state computedin the previous step. This means that we are assuming that every hi is accepted by F ,2 and results inthe “next” state si+1.

Note that time delays hi can be zero. As a consequence, the run of F can be seen as a sequence of events(i.e., changes of state, from si to si+1) taking place in so-called superdense time [13]. An event takes placeat superdense time instant (t, n), where t ∈ R≥0 and n ∈ N. The first element, t, models the “real-time”instant when the event took place, and the second element, n, is the index modeling how many events priorto this one also took place at the same t. For example, consider a run of the form:

(0, s0, , )(1, s1, , )(1, s2, , )(4, s3, , ) · · ·

In this run, the event s0 → s1 takes place at superdense time (1, 0). The event s1 → s2 takes place at (1, 1).The event s2 → s3 takes place at (4, 0). And so on.

2.2 Semantics of a network of FMUs

A network of FMUs is a set of FMUs plus a set of connections. A connection is a pair (y, u) where y isan output variable of one FMU and u is an input variable of another (or the same) FMU. We require thatan input be connected to at most one output. On the other hand, an output may be connected to manyinputs. We require that this set of connections, together with the input/output dependencies defined byindividual FMUs, form an acyclic graph. Provided this holds, the network of FMUs defines a single FMUF , as follows [5].

2We are not concerned here with how the environment can “guess” the right values for hi so that they are all accepted byF . In fact, the environment does not have to guess, as this is precisely the job of the MA. The MA finds the right time step hwhich is accepted by all FMUs in a model, possibly by trial-and-error, i.e., using rollback. See [5] for details.

3

• F has as output variables all output variables from all FMUs in the network.

• F has as input variables all input variables which are not connected to an output.

• The functions get and set for F are mapped to the corresponding get and set functions of individualFMUs in the network, to which the variable which is read or written belongs to.

• The function doStep of F corresponds to running one integration step of (one of) the MA proposedin [5]. In a nutshell, the MA propagates values from outputs to inputs throughout the network, andthen performs a doStep to all FMUs. The key issue is how to choose the right time step to make surethat it is accepted by all FMUs. Different techniques, such as rollback, can be used to achieve thisgoal. See [5] for details.

Since a network of FMUs can be seen as a single FMU, based on the principles above, the semantics ofa network of FMUs can be defined to be the semantics of the single FMU that this network defines.

3 Encoding Untimed State Machines as FMUs

We begin by considering state machines of type Moore or Mealy, which are typically used to model digitalcircuits [10]. Usually this type of machine is finite, in the sense that it has a finite number of states, andfinite domain of possible input and output values. Here we will consider a more general model, where thedomains of input, output, and state variables can be infinite. Such machines are useful for capturing, forexample, embedded controllers, such as those that can be programmed using synchronous languages likeLustre [6].

3.1 Mealy and Moore machines

A Mealy machine is a tuple M = (I,O, S, s0, δ, λ), where I is a set of input values, O a set of output values,S a set of states, s0 ∈ S an initial state, δ : S × I → S the transition function, and λ : S × I → O theoutput function. Given current state sn and current input in, δ(sn, in) determines the next state sn+1, i.e.,sn+1 = δ(sn, in). Given current state sn and current input in, λ(sn, in) determines the current output on,i.e., on = λ(sn, in).

A Moore machine is a special case of a Mealy machine where the current output does not depend on thecurrent input, but only on the current state, i.e., where λ(s, i) = λ(s, i′) for all i, i′ ∈ I. In that case we cansimplify and write λ only as a function of S, λ : S → Y , and then also write λ(s) instead of λ(s, i).

3.2 Semantic gap: from untimed to timed

How can we encode a given Mealy machine as an FMU? The main issue is that Mealy machines are untimed,in the sense that they have no a-priori notion of quantitative or real time, but only a notion of “logical” time(a totally ordered set of ticks). For instance, and in contrast to models such as timed automata [1], we cannotexpress things like “the second input is given 3 time units after the first input” or “between two successivetransitions, 2 seconds elapse.” We can only express order, namely, that the second input/transition comesafter the first, the third after the second, etc. On the other hand, FMUs are timed in the sense that doSteptakes as input a time delay h ∈ R≥0, and also the semantics of an FMU as defined in Section 2.1 is timed.

Given the above, in order to map a Mealy machine to an FMU, we have to somehow create a “timedwrapper” of the untimed state machine. There are (at least) two ways to do that:

Periodic wrapper : in this case, the user specifies a period T ∈ R>0 and the machine takes transitionsprecisely at multiples of T . In this approach, the advancement of time is controlled by the machine itself,and not by the environment of the machine.

Aperiodic wrapper : in this case, every doStep invocation is mapped to a transition of the state machine.In this approach, the advancement of time is controlled by the environment, since it is the one that decideswhen the transitions occur.

4

We detail each of these alternatives next.

3.3 Periodic wrapper

The periodic wrapper approach for encoding a Mealy machine as an FMU can be seen as wrapping themachine with a periodic sampler at the inputs and a “hold” at the outputs. Inputs are sampled every T timeunits (T is a parameter provided by the user). Outputs remain constant until the next sampling occurs.3

Let us describe the periodic wrapper approach in more detail. Given a period T ∈ R>0, a Mealy machineM = (I,O, S, s0, δ, λ) is encoded as the FMU F = (I × S × [0, T ], {p}, {q}, {(p, q)}, s0, set, get, doStep),where:

• F has a single input variable p, ranging over I, and a single output variable q, ranging over O.

• F has an internal state variable s, ranging over S, and an internal state variable t, ranging in the realinterval [0, T ]. Note that in addition to those state variables, F also has p and q as state variables.

• In s0, p and q are set to some initial arbitrary values in I and O, respectively, s is set to s0 and t isset to T . Note that the initial input value does not matter, since set must be called before get anddoStep are called.

• set sets p to a given i ∈ I.

• get computes and returns λ(s, i), where i is the current value of p.

• doStep behaves as follows, for given input h ∈ R≥0:

1. If h < t then doStep accepts h, sets t to t− h, and returns h.

2. If h = t then doStep accepts h, resets t to T , sets s to δ(s, x), where x is the current value of p,and returns h.

3. If h > t then doStep rejects h, sets a temporary variable d to t, resets t to T , sets s to δ(s, x),where x is the current value of p, and returns d.

Case 1 corresponds to the case where the environment requests a time step h smaller than t, the timeremaining until the end of the period. In this case the FMU accepts the step, and advances time by h.Case 2 corresponds to the case where h = t. In that case, the step is accepted, time advances, and since theend of a period is reached, a new period begins by performing a transition and resetting the timer t to T .Case 3 corresponds to the case where the environment requests a time step h greater than t. In this case his rejected, but the FMU still makes partial progress, advancing time up to the end of the period, i.e., by t,and again taking a transition as in the second case.

The above encoding works, however, an alternative encoding may be better, although slightly morecomplex to describe. In this alternative encoding doStep behaves as follows, for given input h ∈ R≥0:

1. If h < t then doStep accepts h, sets t to t− h, and returns h.

2. If h = t then

(a) If h > 0 then doStep sets t := 0 and returns h.

(b) If h = 0 then doStep sets s to δ(s, x), where x is the current value of p, sets t := T , and returns0.

3. If h > t then

(a) If t > 0 then doStep rejects h, sets a temporary variable d to t, sets t := 0 and returns d.

3An alternative is to consider outputs as events which occur only at multiples of T , and are “absent” otherwise. Thisapproach is discussed in Sections 4 and 6.

5

(b) If t = 0 then doStep sets s to δ(s, x), where x is the current value of p, sets t := T , and returns 0.

The difference is that now a transition happens in two superdense steps. First t reaches 0. Then t is resetto T . We find this encoding preferable, since it allows the MA to distinguish between rapid changes of acontinuous signal vs. a discrete change of, say, a piecewise constant signal.

Both encodings described above are illustrated in the example of a periodic counter that follows.

3.4 Example: periodic counter

We want to model a periodic counter which starts at 0 and is incremented by 1 every 1 time unit, whileremaining constant between two successive increases. There are two versions of the periodic counter thatone might wish to model:

• Counter A: output is 0 in the time interval [0, 1), 1 in the time interval [1, 2), 2 in the time interval[2, 3), and so on. We will encode this as FMU FA using the first of the two approaches presented above.

• Counter B: output is 0 in the time interval [0, 1], 1 in the time interval [1, 2], 2 in the time interval[2, 3], and so on. In this case, the output takes two successive values at the times of the transitions,corresponding to a “superdense jump”. We will encode this as FMU FB using the second of the twoapproaches presented above.

3.4.1 Counter A

We can model Counter A using FMU:

FA = (N× (0, 1], {}, {q}, {}, s0, set, get, doStep)

where there are two state variables, n ∈ N and t ∈ (0, 1], no input variables, one output variable q, initialstate s0 where n = 0 and t = 1, and the functions get, doStep are defined as follows (set plays no rolebecause there are no inputs):

• get sets q to n.

• doStep(h) behaves as follows:

– if h < t then it sets t := t− h, and returns h;

– if h = t then it sets n := n+ 1, t := 1, and returns h;

– if h > t then it sets d := t, n := n + 1, t := 1, and returns d. In this case step h is rejected butthe system still makes partial progress by t time units.

Let us try to “simulate” FA:

1. Initially n = 0, t = 1. “Global time” is 0.

2. get(q) returns q = 0.

3. doStep(1) is accepted and results in n = 1, t = 1. “Global time” is 1.




7. doStep(0.5) is accepted and results in n = 2, t = 0.5. “Global time” is 2.5.


6



11. We can continue approaching global time 3, but not reaching it, by calling doStep with smaller andsmaller time steps. The value of n (and therefore q) does not change. The value of t approaches 0.Let’s say we are now at t = 0.01, and therefore global time 2.99.

12. doStep(1) is rejected and 0.01 is returned, so global time is 3. The call results in n = 3, t = 1.

We could also have called doStep(0.01) instead. This would have been accepted, and resulted in thesame values as the above, n = 3, t = 1.

13. And so on.

3.4.2 Counter B

We can model Counter B using FMU:

FB = (N× [0, 1], {}, {q}, {}, s0, set, get, doStep)

where the difference from FA is that state variable t can now also take value 0, i.e., t ranges in the interval[0, 1] instead of (0, 1]. This will be used to flag whether we are at the right side of interval [k − 1, k] (whent = 0), or at the left side of interval [k, k + 1] (when t = 1). The functions for FB are defined as follows:

• set and get behave as in FA.

• doStep(h) behaves as follows:

– if h < t then it sets t := t− h, and returns h;

– if h = t then

∗ if h > 0 then it sets t := 0, and returns h; This models the fact that we have reached theright side of interval [k − 1, k].

∗ if h = 0 then it sets n := n+ 1, t := 1, and returns 0; This models the “superdense jump” (inzero time) from the right side of interval [k − 1, k] to the left side of interval [k, k + 1].

– if h > t then

∗ if t > 0 then it sets d := t, t := 0, and returns d;

∗ if t = 0 then it sets n := n+ 1, t := 1, and returns 0.

Let us try to “simulate” FB :

1. Initially n = 0, t = 1. “Global time” is 0.




5. doStep(1) is rejected (0 is returned) and results in n = 1, t = 1. “Global time” is 1.




9. doStep(0.5) is accepted and results in n = 1, t = 0. “Global time” is 2.


11. And so on.

7

3.5 Aperiodic wrapper

This alternative requires no additional user parameter T . Also, the FMU requires no timer variable t. TheFMU accepts all time steps, and makes a discrete transition in the state machine every time doStep is called.The details are omitted.

The aperiodic wrapper approach is brittle in the sense that the timed behavior of the resulting FMU ishighly dependent on the time steps with which its doStep function is called. For example, if the originalmachine implements a counter, which outputs the sequence 0, 1, 2, ..., then, if doStep is called with h =1, h = 1, ..., the FMU will output 2 at time 2. If, on the other hand doStep is called with h = 0.5, h = 0.5, ...,then the FMU will output 4 at time 2.

4 Encoding Discrete-Event Actors as FMUs

Discrete-event (DE) is a timed model where a set of processes, called actors, interact by exchanging timedevents. DE is one of the models of computation supported in a number of languages and tools such asns-3, VHDL, SimEvents, and Ptolemy [7]. The semantics of DE have been formalized in various papers,e.g., [12, 21, 20]. Here we show how to encode typical DE actors such as Periodic Clock and Constant Delayas FMUs, following principles similar to those presented in [21].

Intuitively, the Periodic Clock actor has a parameter T (the period) and produces a sequence of discreteevents at multiples of T , i.e., at times 0, T, 2T, · · · . The Constant Delay actor has a parameter ∆ (the delay)and delays every discrete event that it receives at its input by ∆ time units. For instance, if it receives asinput events at times t1, t2, t3, · · · , then it outputs events at times t′1, t

′2, t′3, · · · , where t′i = ti + ∆, for all i.

4.1 Semantic gap: from events to persistent signals

DE is a timed model, so encoding DE actors as FMUs does not raise the untimed vs. timed issues encounteredin Section 3. On the other hand, we need to deal with another type of semantic gap, namely, the fact thatDE relies on a primitive notion of discrete event, whereas FMUs communicate a-priori by persistent inputand output signals. These signals are “persistent” in the sense that the value of an output, for instance, canbe requested at any point in time by calling get.

We will solve this problem following the same approach as in [21], namely, by introducing a special valuedenoted absent, which models the absence of an event at a certain point in time. Output variables thatcarry events will have value absent most of the time, except at those times when an event occurs, in whichcase the value of the output variable is the value of the occurring event.

For example, consider the case of Periodic Clock, which will be encoded as an FMU FC with no inputs,i.e., a source FMU. For source FMUs, a TIS is just a sequence of time delays, h1h2h3 · · · . Suppose a TISwith h1 := 1 is fed into FC when the period is T = 2. Then, doStep is called for the first time with h = 1,and time advances from 0 to 1. At that point get is called, and FC should return absent, since no event isoutput at time 1.

4.2 FMU for a periodic clock

The Periodic Clock actor has a parameter T (the period) and produces events at times 0, T, 2T, · · · . Theseevents typically also have a value, which we will assume to be some other parameter v. As mentioned above,we will also assume that the set of values V contains the special value absent.

Let us try to model the Periodic Clock as an FMU FC . A reasonable first attempt is to define FC as thetuple ([0, T ], {}, {q}, {}, s0, set, get, doStep), where:

• There is a state variable t ∈ [0, T ] modeling a timer.

• The set of input variables is empty (and therefore set is a no-op).

• There is a single output variable q (with no dependencies since there are no inputs).

8

• s0 sets the timer variable t to 0 (assuming we want the clock to “tick” also at time 0, otherwise wewould initialize t to T ).

• get(t, q) =

{1, if t = 0absent, otherwise.

• doStep(t, h) =

{(t− h, h), if t ≥ h(0, t), otherwise.

The idea is that FC maintains a timer t and decrements the counter by the amount of the step size h. Then,FC outputs the value 1 when t reaches 0, and absent before that. The problem with the above modeling isthat the counter is never reset to T since, once it is at 0, only h = 0 is accepted as a step size and the clockis “stuck”. Instead we use the following, which is in accordance with superdense time semantics:

• doStep(t, h) =

(T, 0), if t = 0(t− h, h), if t > h(0, t), otherwise.

5 Encoding SDF Actors as FMUs

Synchronous Data Flow (SDF) [11] is a dataflow model where a set of actors execute asynchronously andcommunicate via FIFO queues of (a-priori) unbounded length. The main characteristic of SDF is that thenumber of tokens that each actor consumes from its input queues and produces to its output queues everytime it fires is constant and known in advance. In that sense, SDF can be seen as a restricted subclass ofKahn Process Networks [9].

5.1 Semantic gap: from asynchronous queues to persistent signals

Encoding an SDF actor as an FMU is not straightforward. In addition to the fact that (“pure”) SDF is anuntimed model, whereas FMI is timed, we have to solve the problem of bridging the semantic gap betweenthe asynchronous model of concurrency with FIFO queue based communication that SDF is based on, andthe somewhat synchronous model that FMI uses, based on persistent signals as discussed above. This is theproblem we focus on in this section. We first show how a closed SDF graph (i.e., one without open inputs)can be mapped to a network of FMUs in a modular way, i.e., one SDF actor at a time, independently fromthe rest of the SDF graph. We then discuss how SDF FMUs can interface with other FMUs, e.g., DE FMUs.

5.2 Encoding a closed SDF graph as a network of FMUs

Consider first the SDF graph shown in Figure 1. This graph has three SDF actors, denoted A,B,C. A is asource actor with a single output variable. A produces 3 tokens every time it fires. B has a single input anda single output variable. B needs at least 4 input tokens in order to fire, and when it does, it consumes 4tokens from its input queue and produces 2 tokens to its output queue. C is a sink actor with a single inputvariable. C needs at least 5 tokens in order to fire, and consumes 5 tokens from its input queue every timeit fires.4 An SDF graph may also have initial tokens on the queues. In this graph, there are two queues,denoted α and β. We can identify the output queue of A with the input queue of B, denoted α, and theoutput queue of B with the input queue of C, denoted β. There are 3 initial tokens in β, and no initialtokens in α.

The principles for mapping an SDF graph such as the one above to a network of FMUs are the following.We generate three FMUs, one for each SDF actor. Let us denote them FA, FB , FC , for the actors A,B,Cof Figure 1. FA has a state variable holding an output FIFO queue, denoted QoA. FB has a state variableholding an input FIFO queue, denoted QiB , and another state variable holding an output FIFO queue,

4SDF actors may also have internal state, which they update every time they fire.

9

A B Cα β3 4 2 5

•3

Figure 1: An SDF graph.

denoted QoB . FC has a state variable holding an input FIFO queue, denoted QiC . Note that QoA and QiB aredistinct, not shared, variables. So are QoB and QiC . This is necessary, since the translation from SDF actorsto FMUs is modular, e.g., we map actor B to FB independently from the other actors A and C. Initially allqueues are empty, except for the input queue of C, which has 3 initial tokens, corresponding to the 3 initialtokens of β.5

The FMI API is implemented as follows:

• FA.get: returns the current value of the (entire) queue QoA.

• FA.doStep: writes 3 fresh tokens into QoA. Note that the previous value of QoA is over-written.

• FB .set: receives a (possibly empty) ordered list of tokens, and writes this as the value of the inputvariable of FB , denoted viB . Note that viB also holds a queue as its value, but is different from theinput queue state variable QiB . Also note that any previous value stored in viB is over-written.

• FB .doStep: first, it appends the list stored in viB at the end of QiB . Then it checks whether QiB hasenough tokens, in this case at least 4.

– If so, 4 tokens are removed from QiB , the firing computation of B is performed, and the 2 computedoutput tokens are (over-)written to QoB .

– If not, the empty list is (over-)written to QoB .

• FB .get: returns the current value of the (entire) queue QoB .

• FC .set: receives a (possibly empty) ordered list of tokens, and (over-)writes this to viC .

• FC .doStep: first, it appends the list stored in viC at the end of QiC . Then it checks whether QiC hasenough tokens, in this case at least 5.

– If so, 5 tokens are removed from QiC , and the firing computation of C is performed.

– If not, FC .doStep does nothing more and returns.

One might object that it is redundant to have two separate variables vi and Qi. Why not just have Qi andlet set append to it whatever it receives as input? This would work, however, it would not conform to theFMU contract described in [5]. In particular, set would violate Assumption (A2) of Section 4.2 of [5], sinceaccording to (A2) set should only over-write the value of an input variable, and cannot implement a morecomplex operation such as adding an element to a queue.

To illustrate the mapping from SDF to FMUs, let us simulate the beginning of an execution of thenetwork of FMUs FA, FB , FC obtained from the SDF graph of Figure 1:

• Initially, all queues are empty except QiC which contains 3 tokens, say the list [y1, y2, y3].

• FA.get and FB .get both return [] (the empty list).

• Thus, FB .set and FC .set both result in [] being written to viB and viC , respectively.

• FA.doStep produces 3 tokens on its output queue, say the list [x1, x2, x3].

5This is slightly non-modular, as one could argue that the initial tokens are not really part of C, but rather part of the SDFgraph. We do not consider it a problem, however, as the initialization could also be done during the instantiation of FC .

10

• FB .doStep appends viB , i.e., [], at the end of QiB . The latter remains empty. There are not enoughtokens to fire B, so FB .doStep returns.

• FC .doStep returns since there are not enough tokens to fire C.

• This marks the end of the first iteration of the MA, and the second iteration begins.

• FA.get returns [x1, x2, x3]. FB .set sets viB to [x1, x2, x3].

• FB .get returns []. FC .set sets viC to [].

• FA.doStep produces 3 tokens on its output queue, say the list [x4, x5, x6].

• FB .doStep appends viB , i.e., [x1, x2, x3], at the end of QiB , which becomes [x1, x2, x3]. There are notenough tokens to fire B, so FB .doStep returns.

• FC .doStep returns since there are not enough tokens to fire C.

• This marks the end of the second iteration of the MA, and the third iteration begins. Etc.

5.3 Interfacing SDF FMUs with other FMUs

Mapping a closed SDF graph such as the one of Figure 1 to a network of FMUs make little sense, since thereare specialized tools (e.g., Ptolemy) for SDF modeling and simulation. What is interesting about the abovemapping, however, is that it is modular, that is, it maps each SDF actor to a separate FMU. This opensthe possibility for interfacing SDF FMUs to other types of FMUs, such as the ones discussed in previoussections. This interfacing must be performed with care, however, since, as we mentioned above, there is asemantic gap between the concurrency and communication semantics of SDF and that of FMI.

Interfacing SDF FMUs with DE FMUs

In particular, let us consider interfacing SDF FMUs with DE FMUs. By an SDF FMU we mean an FMUwhich is the result of a mapping of an SDF actor such as SDF actor B from Figure 1 and its correspondingFMU FB . By a DE FMU we mean here an FMU producing or consuming discrete events.

Let us first consider a DE FMU F producing a sequence of discrete events at its output. Suppose wewant to connect this output to the input of SDF FMU FB . Our intention here might be that every discreteevent produced by F is mapped to a (single) token given to FB . The above connection does not immediately“type check”, however, since F.get returns scalar values (of some type, or absent), whereas FB .set expectsa list. Therefore, we need an FMU to perform the conversion from scalars to lists. This is a simple FMU,which we will denote FDE→SDF , with a single input variable, a single output variable that directly dependson the input, no internal state variables, and a get method which transforms a scalar input value v 6= absent

to the list [v] of length 1, and the value absent to the empty list [].Now, suppose F receives discrete events at its input, and that we want to connect the output of FB to

the input of F . Here, the interpretation would be that every token generated by FB is mapped to a discreteevent. Since FB generally produces more than one tokens simultaneously (in the case of FB , 2) we canassume that multiple simultaneous events must be fed into F . We therefore need an FMU FSDF→DE whichtakes as input a (possibly empty) list of tokens, and produces as output a sequence of simultaneous discreteevents, one per each token in the list.

FSDF→DE is also easy to define. It has a single input and a single output variable, and a state variablewhich keeps count of the number of events that the FMU still needs to output, to exhaust the number oftokens it received. Every time FSDF→DE receives a list of, say k tokens, it sets the counter to k. It thenforbids time from advancing (by rejecting time steps when its doStep is called) until k simultaneous discreteevents have been produced at the output. If the received list of tokens is empty, then FSDF→DE outputsabsent. The details are omitted.

11

6 Encoding Timed State Machines as FMUs

In Section 3 we considered untimed state machines and in Section 4 we considered timed discrete-eventactors. In this section we consider timed state machines, which can be seen as a model combining statemachines with timed discrete events. Timed state machines have a timed semantics, and therefore there isno need to bridge the untimed-timed semantic gap when encoding them as FMUs. On the other hand, thereare many variants of timed state machines, with many different semantics (sometimes not formal). Someof these semantics raise semantic gaps that need to be bridged. For instance, in the case of state machinescommunicating with timed discrete-events, adding the absent value may be necessary.

We begin with timed automata [1], which is a formal model, and show how a deterministic timed au-tomaton can be encoded as an FMU. We then show examples of other types of timed state machines, similarto those used in languages such as UML, SysML, and Rhapsody Statecharts, and show how they can beencoded as FMUs as well.

6.1 Timed Automata

We consider timed automata communicating with input and output events. Such a timed automaton is atuple

(EI , EO, C,Q, q0, Inv,�)

where EI is a set of input events; EO is a set of output events; C is a finite set of clocks; Q is a finite set ofcontrol states; q0 ∈ Q is the initial control state; Inv is a function assigning to each q ∈ Q a clock invariant,explained below; and � is a finite set of actions, each being a tuple of the form

(q, q′, e, g, C ′)

where q, q′ ∈ Q are the source and destination control states; e ∈ EI ∪ EO is either an input event or anoutput event; g is the clock guard, explained below; and C ′ is a subset of clocks to reset to 0, C ′ ⊆ C.

Invariants and guards are conjunctions of simple constraints on clocks, of the form c ≤ k and c < k,where c ∈ C is a clock and k ∈ Z is an integer constant. For clock invariants, we assume only constraints ofthe form c ≤ n where n is a non-negative integer.

The semantics of a timed automaton (TA) is defined as a timed transition system (TTS). A TTS is atuple (S, s0,−→) where S is its state of TA states, s0 is the initial TA state, and −→ is its transition relation.A state s ∈ S is a pair (q, v), where q ∈ Q is a control state of the TA; and v : C → R≥0 is a clock valuation,

i.e., a function that assigns a non-negative real value to every clock. The initial state is s0 = (q0,~0) where~0 is the clock valuation assigning 0 to every clock in C. Note that, because of the special form of clockinvariants, ~0 is guaranteed to satisfy Inv(q0). The transition relation has two types of transitions:

Discrete transitions of the form (q, v)e−→ (q′, v′) where e ∈ EI ∪EI . Such a transition is possible iff there

exists an action (q, q′, e, g, C ′) such that v satisfies the guard g, and v′ is obtained from v by resetting all clocksin C ′ to zero and leaving all others unchanged. That is, ∀c ∈ C ′ : v′(c) = 0 and ∀c ∈ C − C ′ : v′(c) = v(c).We denote v′ by v[C ′ := 0]. In addition, it must be the case that v′ satisfies the invariant of the destinationcontrol state q′, written v′ |= Inv(q′).

Timed transitions of the form (q, v)δ−→ (q, v + δ) where δ ∈ R≥0 and v + δ denotes the clock valuation

v′ defined by ∀c ∈ C : v′(c) = v(c) + δ. Such a transition is possible iff the invariant at control state q is notviolated by the elapse of time, i.e., v+ δ |= Inv(q). Note that, because of the special form of clock invariants,and the fact that the starting valuation v satisfies Inv(q) (this can be shown by induction), v + δ |= Inv(q)implies that ∀0 ≤ δ′ ≤ δ : v + δ′ |= Inv(q).

A TA state (q, v) is called reachable if there exists a path in the TTS defined by the TA that ends onthat state.

Example

An example of a timed automaton modeling a simple controller for a light is shown in Figure 2. Theautomaton has a single input event, “touch” (a label a? on an action denotes the fact that a is an input

12

c ≤ 0

c ≤ 0

c ≤ 0touch?

c := 0

on! touch?, c < 2

c := 0

touch?, c ≥ 2

c := 0

off!

bright!

touch?

c := 0

touch?

touch? touch?

Figure 2: A timed automaton modeling a light controller.

event), and three output events, “on”, “off”, and “bright” (a label b! denotes the fact that b is an outputevent). The automaton has 6 control states and one clock, c. The states labeled with the clock invariantc ≤ 0 are transient states, meaning that no time can elapse on those states. This is ensured by the constraintc ≤ 0 and the fact that c is reset to zero whenever entering such a control state. Clock resets are denotedon the actions by c := 0. Control states labeled with no clock invariant implicitly means that the invariantin that state is true, i.e., an arbitrary amount of time can elapse in that control state.

The logic of this controller is as follows. Assume that initially the light is off. Touching the lamp oncetriggers a sensor issuing the input event “touch”. This is followed (in zero time) by the light being turnedon, at a normal level of brightness. If a second touch follows quickly after the first one (within less than 2time units, similarly to a double-click on a computer mouse) this is interpreted as the user wanting a brighterlight. Otherwise, a touch at a state where the light is on is interpreted as the user wanting to turn the lightoff.

6.2 Determinism and other restrictions

Timed automata is a modeling formalism developed primarily with verification in mind. As such, the modelis very general, and allows to describe non-deterministic automata, automata with timelocks (where timecannot elapse at all) or zenoness (where time cannot elapse beyond a certain upper bound), and otherphenomena which may be considered problematic in the context of FMI. In particular, non-determinism isa problem, since FMUs are by definition deterministic (in the sense that the methods of the FMI API aremathematically modeled as total functions). Therefore, in order to be able to encode a timed automaton asan FMU, we will impose some restrictions on it.

First, we require that the clock invariants of the automaton are such that, for any reachable state (q, v),and any action (q, q′, e, g, C ′), whenever the guard g is satisfied by the current clock valuation v, then theinvariant of the destination control state q′ is also satisfied by the new valuation v[C ′ := 0] obtained afterthe reset, i.e., v[C ′ := 0] |= Inv(q′). We call this the invariant sanity condition. The condition that the nextstate of an FMU is always well defined. This condition forbids, for instance, an automaton such as the oneshown in Figure 3 (left), where at the initial state, when clock c = 2, say, the action to the middle state isenabled, but the clock invariant of that state, c ≤ 1, is violated. A simple fix is shown to the right of thefigure.

c ≤ 1a?

c ≤ 1a?, c ≤ 1

Figure 3: A pathological timed automaton (left); fixed version (right).

Second, we require that the automaton is receptive meaning that it is able to accept any input eventat every reachable state. Formally, for every reachable state (q, v) and every input event e ∈ EI , the TTS

13

of the automaton must have a discrete transition (q, v)e−→ (q′, v′) to some state (q′, v′). This condition

removes ambiguity about what to do when an input event is received by an FMU, in cases where there isno corresponding outgoing action labeled with that input in the automaton. Note that, in order to ensurethis condition, we had to add self-loops labeled with “touch?” at all transient control states of the lightcontroller automaton of Figure 2.

Third, we require that the automaton is deterministic. Intuitively, we want two things. First, for anyreachable state, and any input event, we want the automaton to have a uniquely defined successor statewhen (and if) it receives that event. Second, if the automaton decides to produce an output event, we wantthe output event to be unique, but also the timed at which it is produced to be uniquely defined. These areseveral conditions, and somewhat tricky to get right, therefore, we proceed step by step.

We say that a TA is input-deterministic if for every reachable state (q, v) and every input event e ∈ EI ,there is at most one state (q′, v′) such that (q, v)

e−→ (q′, v′). Notice that input-determinism together withreceptiveness, imply that there is a unique successor state (q′, v′).

We say that a TA is output-deterministic if for every reachable state (q, v) and every output event e ∈ EO,

if there exists a state (q′, v′) such that (q, v)e−→ (q′, v′), then the following conditions hold:

1. There is no e′ ∈ EO such that e′ 6= e and (q, v)e′−→ (q′′, v′′) for some (q′′, v′′).

2. There is no δ ∈ R≥0 such that δ > 0 and (q, v)δ−→ (q, v + δ).

The first condition says that if the automaton decides to output e, then it doesn’t also have a transitionwith a different output event e′. The second condition says that if the automaton decides to output e, thentime cannot elapse. This forbids an ambiguity in the FMU of the form “should we output something now,or should we wait?”

An example of a TA which violates output-determinism is shown to the left of Figure 4. This automatonis problematic for two reasons. First, it doesn’t specify precisely at what time in the interval [0, 1] the outputevent a should be issued. Second, it doesn’t even specify whether output a should be issued at all. Indeed,since there is no clock invariant at the initial control state, time can in principle elapse beyond c > 1 withoutthe automaton issuing any output. A fixed version of the automaton is shown to the right of the figure.Here, a clock invariant is imposed so that time cannot elapse beyond c = 1. Moreover, the guard c = 1 atthe output action ensures that the output event is issued precisely at time 1.

a!, c ≤ 1c ≤ 1

a!, c = 1

Figure 4: An output-nondeterministic timed automaton (left); fixed version (right).

One might think that together input and output-determinism give us what we want, but there is asubtlety. Consider the example shown in Figure 5 (left). Suppose the automaton is at its initial controlstate with c = 1, and there is input event b present at that time. What should the automaton do? Shouldit output event a, or should it take the discrete transition labeled b?

c ≤ 1a!, c = 1

b?

c ≤ 1a!, c = 1

Figure 5: A nondeterministic timed automaton (left); fixed version (right).

To avoid such ambiguities, we impose a further condition. We say that a TA is deterministic if it is

14

input-deterministic, output-deterministic, and in addition, for every reachable state (q, v) which is an output

state, that is, which has a transition (q, v)e−→ (q′, v′) with e ∈ EO, the following condition holds:

• For any e ∈ EI there is a transition (q, v)e−→ (q, v).

The last condition, together with input-determinism, ensures that when an output event is ready to beissued, all input events are ignored (i.e., are consumed without a change of state).

Even with the above restrictions, users can still design timed automata which may appear pathological.An example is shown in Figure 6. This TA is zeno in the sense that it produces an infinite number of outputevents a in zero time. However, this automaton satisfies all our conditions above, so we do not forbid it(meaning we are able to encode it as an FMU). We prefer not to impose additional restrictions forbiddingsuch automata, in order not to limit the users’ modeling options.

c ≤ 0 a!

Figure 6: A zeno timed automaton.

6.3 Encoding timed automata as FMUs

We assume given a TA (EI , EO, C,Q, q0, Inv,�) which satisfies the clock invariant sanity condition, recep-tiveness, and determinism. We encode this TA as an FMU F = (S,U, Y,D, s0, set, get, doStep), where:

• F has n + 1 state variables where n = |C| is the number of clocks in the TA. F has a state variableq ranging over Q, and a state variable xi ranging over R≥0, for every clock ci ∈ C, i = 1, ..., n. Notethat with these state variables, a state s of F has the same form as a state of the original TA, i.e., scan be viewed as a pair (q, v) where v is a clock valuation.

• F has a single input variable u, ranging over EI ∪ {absent}.

• F has a single output variable y, ranging over EO ∪ {absent}.

• D = {(u, y)}, i.e., y depends on u.

• The initial state s0 of F is such that q is set to q0, every xi is set to 0, and u and y are set to somearbitrary value.

• set sets the input variable u to a given value. This value is either an input event in EI , or absent.

• get behaves as follows, depending on the current state (q, v) of the FMU.

– If (q, v) is an output state of the TA, that is, there exists e ∈ EO and (q′, v′) such that (q, v)e−→

(q′, v′), then get sets the output variable y to e. Note that determinism ensures that both e and(q′, v′) are unique.

– Otherwise, get sets the output variable y to absent.

doStep(h) behaves as follows, again depending on the current state (q, v) of the FMU:

• If (q, v) is an output state of the TA, then let e ∈ EO and (q′, v′) be the uniquely defined output event

and successor state such that (q, v)e−→ (q′, v′).

– If h = 0 then doStep accepts h, sets q := q′, xi := v′(ci), for i = 1, ..., n, and returns 0.

15

– If h > 0 then doStep rejects h, but again sets q := q′, xi := v′(ci), for i = 1, ..., n, and re-turns 0. (Note that the behavior here is identical to the previous case, only the interpretationaccepts/rejects is different.)

Note that doStep ignores any input event which might be present at input variable u in this case. Thisdoes not violate the TA semantics, thanks to the determinism assumption which ensures that suchinputs are in any case ignored by the TA (i.e., leave its state unchanged).

• Otherwise:

– If u = absent and v+h |= Inv(q) then doStep accepts h and updates all xi variables to xi := xi+h.

– If u = absent and v + h 6|= Inv(q) then, by the fact that v |= Inv(q) and the form c ≤ k of clockinvariants, there exists a largest h′ ∈ R≥0, such that 0 ≤ h′ ≤ h and v + h′ |= Inv(q). Then,doStep rejects h, updates all xi variables to xi := xi + h′, and returns h′.

– If u = e for some e ∈ EI , then by the assumptions of receptiveness and determinism, there is aunique successor state (q′, v′) such that (q, v)

e−→ (q′, v′). Then, doStep rejects h, sets q := q′,xi := v′(ci), for i = 1, ..., n, and returns 0.

6.4 Ptolemy and Rhapsody state machines

So far in this section we considered the formal model of timed automata. Other variants of timed statemachines are also used in tools such as SysML/Rhapsody from IBM and Ptolemy from UC Berkeley(ptolemy.org), to name a few. It is beyond the scope of this paper to show complete and formal en-codings of these types of state machines as FMUs, as this would also require formalizing their semantics.Still, it is worth discussing a few examples in order to present the basic principles of how such encodingscould be developed.

First, we look at a timed state machine from SysML/Rhapsody, shown in Figure 7. For simplicity, in thisexample there are only input events, labeled eventA1, eventA2 and eventA3, and no outputs. Ignoring forthis discussion the mechanism of event-based interaction in SysML/Rhapsody (which is itself non-trivial),let us focus on the timed part of the machine of Figure 7, namely, the timeout statement tm(10). This canbe intuitively explained as follows. Upon entering state 2, set a clock to 0; when the clock reaches 10, thetimeout transition to state 0 is taken, unless in the meantime event eventA3 occurred, in which case themachine has already moved to state 1.

This logic looks simple enough to model as a timed automaton. Attempting to do that, we come up withthe TA shown in Figure 8. In this automaton, we included a “dummy” output event TO, since our currentformalization of TA does not allow “silent” actions (i.e., without input nor output events).

Unfortunately, the TA of Figure 8 suffers from several problems. First, it is not receptive, since forinstance, there is not outgoing transition from s0 labeled with input event A2. This problem can be fixed byadding appropriate self-loops as in Figure 9. A second problem is that the TA of Figure 8 does not satisfythe determinism condition. In particular, it is ambiguous what to do in the case where at control state s2,c = 10 and input event A3 arrives. A possible fix is shown in Figure 9. This fix is simple enough, but itis unclear whether it captures the semantics of SysML/Rhapsody. Ultimately, defining the mapping fromgeneral SysML/Rhapsody state machines to FMUs amounts to defining a semantics for the SysML/Rhapsodylanguage, which beyond the scope of this work.

We now turn our attention to state machines in Ptolemy. An example is shown in Figure 10. Ptolemy statemachines also have a timeout statement as this example illustrates. Ptolemy state machines communicate viavarious mechanisms. One mechanism is input and output events, as in timed automata and SysML/Rhapsodystate machines. The machine of Figure 10 has two input ports and two output ports, all of which carryevents. Reacting to an input event a (similar to the label a?) is written in Ptolemy as a isPresent. Emittingan output event b is achieved by output actions such as out1=x in the transition from s1 to s2. Note that inthis case the event emitted carries a value, in this case, the current value of x. The latter is a state variableof the machine, which can be set in set actions such as x=x+1 in the transition from s1 to s2.

16

Figure 7: A Rhapsody state machine with a timeout statement.

s0 s1 s2, c ≤ 10A1? A2?

c := 0

A3?

TO!

c = 10

Figure 8: A timed automaton attempting to model the state machine of Figure 7.

The machine of Figure 10 has several similarities, but also several differences with the one in Figure 7.Regarding differences, first, the machine of Figure 10 has more than one input ports, and more than oneoutput ports. It also has complex guards on input events, such as the guard of the transition from s3 to s4,which requires an event to be present at in1 and no event to be present at in2. Also, a variable such as x

could sometimes be observable to the external world, and therefore can be considered an output. Becauseof this, the machine of Figure 10 can be seen as having not only output events, but also persistent outputsignals.

These additions can be easily accommodated when encoding the machine of Figure 10 as an FMU.First, the two input ports in1 and in2 can be mapped to two input variables, say, u1 and u2 in the FMU,and similarly for output ports. The special value absent allows to encode the guard in1 isPresent &&

!in2 isPresent without issues, as u1 6= absent ∧ u2 = absent. Finally, persistent outputs are the defaultoutput mechanism in FMUs, so having an additional output variable for x is also straightforward.

17

s0 s1 s2, c ≤ 10A1? A2?

c := 0

A3?, c < 10

TO!

c = 10

A2?, A3? A1?, A3?

A1?, A2?

A3?, c = 10

Figure 9: Fixing the timed automaton of Figure 8 to ensure receptiveness and determinism.

Figure 10: A Ptolemy state machine with a timeout statement and state variable x.

7 Encoding Continuous-Time Models as FMUS

In this section we show how models with continuous-time semantics can be into FMUs. First, we show howmodels with pure ordinary differential equations can be encoded in an FMU. This is followed by extendingODEs with zero-crossing functions, resulting in piecewise continuous signals with discrete changes.

7.1 Models with Pure Continuous Signals

An ordinary differential equation (ODE) in explicit state space form may be written as ˙x = f(x, u, t), wherex : X → V are the states (dependent variables mapped to values), ˙x : X → V the derivatives of the set ofvariables X, u : U → V the mapping from the set of input variables to values, and t ∈ R the independentvariable representing time. We use the bar notation x for describing mapping between two sets, in this casethe mapping between state variables X and values V. For brevity, we also use the notation XV = X → Vwhen describing such mapping. Let λ : R×XV×UV → YV be the output function that computes the outputmapping YV from state variables and direct input. An FMU can then be defined as

F = (S,U, Y,D, (x0, u⊥, 0, q0), set, get, doStep). (1)

where

• S = R×XV×UV×Q is the set of all possible states. A specific state s ∈ S of an FMU is a quadruple(t, x, u, q), where t is the absolute simulation time, x the state mapping, u the input value mapping,

18

and q ∈ Q the state of the numerical solver. We assume it exists a numerical ODE solver (explicit orimplicit) with a solver function solve(x, u, t, q, f), where t is the time that the solver should advanceto and f is the previously defined explicit ODE function. The solve function returns a tuple (x′, q′),where x′ is the updated state mapping and q′ the new solver state.

• Sets U and Y represent all input and output variables, respectively.

• The input-output dependency relation D ⊆ U×Y can be derived from the output function λ as follows.D = {(u, y) | u ∈ U and y ∈ Y if λ(t, x, u) = y uses u to compute y for some t ∈ T and x ∈ XV}

• The initial state of the FMU is a quadruple (0, x0, u⊥, q0) where 0 indicates that the simulation isinitialized to start at time zero, x0 is the mapping of initial values for state variables, u⊥ = {u0 7→⊥, . . . , un 7→ ⊥} are the initial values of the input mapping u, where ⊥ indicates that the initial valueis undefined, and q0 is the initial state of the solver state.

• Function set : S ×U ×V→ S is defined as set(s, u, v) = s′ where s = (t, x, u, q) and s′ = (t, x, u[u 7→v], q). The notation u[u 7→ v] means that a previous mapping for u in u is replaced with value v.

• Function get : S × Y → V computes the output value using output function λ. That is, get(s, y) = v′

where s = (t, x, u, q) and y = λ(t, x, u) and v′ = y(y). Note that in this simple formalization, alloutput values are computed every time get is called, even if only one value is requested. In a realimplementation, this may be made more efficient by caching the computed output values.

• Function doStep : S × R≥0 → S × R≥0 is simple to define in the pure continuous case since wecan assume that any communication step will be accepted. Numerical errors (e.g., integration error ordivision by zero) are not treated as rejection of time step and are outside the scope of this formalization.Consequently, doStep(s, h) = ((t + h, x′, u, q′), h) where s = (t, x, u, q) and (x′, q′) = solve(x, u, t +h, q, f). Note that the solver function solve may take multiple of internal solver steps, which isorthogonal to the communication step size h.

7.2 Models with Piecewise Continuous Signals

In previous section, we described how an ODE with pure continuous signals may be encoded as an FMU.Piecewise continuous signals can, on the other hand, contain discontinuous jumps in between continuousintervals. A simple example of such a model is the classic bouncing ball model, where the velocity of theball changes instantaneously from a negative to a positive value when the ball bounces on the ground.

Discontinuous events can be categorized into timed events and state events, where the former is onlydependent on time and can be easily be predicted, whereas the latter needs to be detected using zerocrossing detection. To enable the formalization of zero crossing detection, we introduce a set Zid of zero-crossing identifiers, and a root finder function g : R × XV × UV → P(Zid × R), where P() is the powerset. When calling the root finder function g(t, x, u) a set of tuples of the form (z, d) is returned, where tis simulation time, x the state, u the input mapping, z a zero-crossing identifier, and d the distance fromthe zero crossing for z. Function g is called by a solver function that is slightly extended compared toSection 7.1. The extended solver function solvezc(x, u, t, q, f, g), takes the root finder function g as anargument and returns quadruple (x′, q′, t′, Z), where x′ is the updated state mapping, q′ the new solverstate, t′ the new time, and Z the set of zero crossing identifiers. If Z = ∅ no zero crossings were detectedduring the communication step. If Z 6= ∅, then Z ⊆ Zid is the set of zero crossing identifiers for the zerocrossings that were detected at time t′.

An FMU with piecewise continuous signals can then be defined in the same way as in (1), with thefollowing differences:

• The set of all possible states S = R × XV × UV × Q × B is now extended with a boolean value (lastelement) that is used by the FMU to enable superdense time. The default value is false. The value istrue when the master algorithm should take a zero communication step size so that superdense timecan be used to distinguish between limit from the left and right.

19

• The set of input variables U , the set of output variables Y , the input-output dependency relation D,the initial value tuple (x0, u⊥, 0, q0, false), function set, and function get, are all defined in the sameway as in Section 7.1.

• Function doStep(s, h) = (s′, h′) may either reject the proposed time step 0 ≤ h′ < h or accept the timestep h′ = h, where s = (t, x, u, q, b). When the FMU is calling the solver solvezc(x, u, t+ h, q, f, g) =(x′, q′, t′, Z) a time step is rejected if t′ < t + h. A zero crossing or time event can occur regardlessif the communication step was rejected or accepted, that is, if it was predicted that a crossing occursat time t, the time step will be accepted even if the crossing occurred at t. The following cases applywhen returning a value from doStep.

– If b = false and Z = ∅, then h′ = h and s′ = (t + h, x′, u, q, false). This means that no zerocrossings occurred during this time step.

– If b = false and Z 6= ∅ then h′ = t′ − t and s′ = (t′, x′, u, q′, true).

– If b = true then return with h′ = 0 and s′ = (t, x′′, u, q′, false), where x′′ is the state mappingafter that the state has been updated according to the actions for handling the zero crossing. Forinstance, in the bouncing ball example, the state that is updated is the velocity.

8 Related Work

The FMI standard [17] is currently used by many modeling and simulation tools, both within industry andacademia. More than 50 tools have support for FMI6, where approximately 20 of them support exportof version 1.0 models for co-simulation. Although many tools implement ways to generate FMUs fromcontinuous-time models (such as Modelica models), we are not aware of any work that formally describeshow to encode FMUs in general, especially for non-continuous-time models like the ones we focus on here.

The closest related work is [5], which provides a formalization of a subset of the FMI standard, togetherwith master algorithms (MA) that are proven to be determinate. Our paper builds on this work, by usingthe same formalization, assuming the use of their MA, and describing encoding strategies for various modelsof computations. Ptolemy II [7] is an environment for composing and simulating heterogenous concurrentcomponents. The components in Ptolemy II are implemented in Java and called actors and have similarstructures as FMUs, but with a different interface. A formalization of Ptolemy’s actor interface and encodingsof various models of computations have been proposed in [21].

There exist works that describe how FMUs can be used in existing modeling environments and how masteralgorithms may be implemented. Bastian et al. [2] have proposed a fixed-step size MA that is designed tobe platform independent. Schierz et al. [19] describe a strategy for adaptive communication size control.Feldman et al. [8] present a plugin for Rhapsody for generating FMUs from Statechart SysML blocks. Theyprovide high level guidelines for how to generate Statechart FMUS, but do not provide a formalization.Pohlmann et al. [18] also describe how to encode statechart models, described in MechatronicUML. Theirpaper is also discussing implementation strategies, but the implementation is for FMI for model exchangeand not co-simulation.

9 Conclusion

In this paper, we show how various models of computation, such as state machines, discrete-event, dataflow,and timed automata, can be encoded as functional mock-up units (FMUs), which are model componentsimplementing the FMI standard. The main challenge is the gap between the semantics of the source formalismand the semantics of FMI. Faced with this problem, we show how to overcome the semantic gaps fromuntimed to timed models, from events to persistent signals, and from asynchronous queues to persistentsignals. Future work includes reporting on an implementation and evaluation on a set of case studies,

6http://www.fmi-standard.org/tools

20

including heterogeneous models that combine FMUs from formalisms presented in this paper together withcontinuous-time FMUs that are generated from e.g., Modelica tools.

References

[1] R. Alur and D. Dill. A theory of timed automata. Theoretical Computer Science, 126:183–235, 1994.

[2] J. Bastian, C. Clauss, S. Wolf, and P. Schneider. Master for Co-Simulation Using FMI. In Proceedingsof the 8th Modelica Conference, pages 115–120, 2011.

[3] T. Blochwitz, M. Otter, et al. The Functional Mockup Interface for Tool independent Exchange ofSimulation Models. In Proceedings of the 8th International Modelica Conference, 2011.

[4] T. Blochwitz, M. Otter, et al. Functional Mock-up Interface 2.0: The Standard for Tool independentExchange of Simulation Models. In Proceedings of the 9th International Modelica Conference, 2012.

[5] D. Broman, C. Brooks, L. Greenberg, E. A. Lee, S. Tripakis, M. Wetter, and M. Masin. DeterminateComposition of FMUs for Co-Simulation. In Proceedings of the 13th ACM & IEEE InternationalConference on Embedded Software (EMSOFT’13), 2013.

[6] P. Caspi, D. Pilaud, N. Halbwachs, and J. Plaice. Lustre: a declarative language for programmingsynchronous systems. In 14th ACM Symp. POPL. ACM, 1987.

[7] J. Eker, J. Janneck, E. Lee, J. Liu, X. Liu, J. Ludvig, S. Neuendorffer, S. Sachs, and Y. Xiong. Tamingheterogeneity – the Ptolemy approach. Proceedings of the IEEE, 91(1):127–144, Jan. 2003.

[8] Y. A. Feldman, L. Greenberg, and E. Palachi. Simulating Rhapsody SysML Blocks in Hybrid Modelswith FMI. In Proceedings of the 10th International Modelica Conference, pages 43–52, 2014.

[9] G. Kahn. The semantics of a simple language for parallel programming. In Information Processing 74,Proceedings of IFIP Congress 74. North-Holland, 1974.

[10] Z. Kohavi. Switching and finite automata theory, 2nd ed. McGraw-Hill, 1978.

[11] E. Lee and D. Messerschmitt. Synchronous data flow. Proceedings of the IEEE, 75(9):1235–1245, 1987.

[12] E. A. Lee. Modeling concurrent real-time processes using discrete events. Ann. Softw. Eng., 7(1-4):25–45, 1999.

[13] E. A. Lee. Constructive models of discrete and continuous physical phenomena. Technical ReportUCB/EECS-2014-15, EECS Department, University of California, Berkeley, Feb 2014.

[14] MODELISAR Consortium and Modelica Association. Functional Mock-up Interface for Model Exchangeand Co-Simulation – Version 2.0 Beta 4, August 10, 2012. Retrieved from https://www.fmi-standard.

org.

[15] MODELISAR Consortium and Modelica Association. Functional Mock-up Interface for Co-Simulation,October 12, 2010. Version 1.0, Retrieved from https://www.fmi-standard.org.

[16] MODELISAR Consortium and Modelica Association. Functional Mock-up Interface for Model Ex-change, October 12, 2010. Version 1.0, Retrieved from https://www.fmi-standard.org.

[17] MODELISAR Consortium and Modelica Association. Functional Mock-up Interface for Model Ex-change and Co-Simulation, October 18, 2013. 2.0 Release Candidate 1, Retrieved from https:

//www.fmi-standard.org.

21

[18] U. Pohlmann, W. Schafer, H. Reddehase, J. Rockemann, and R. Wagner. Generating Functional MockupUnits from Software Specifications. In Proceedings of the 9th International Modelica Conference, pages765–774, 2012.

[19] T. Schierz, M. Arnold, and C. Clauss. Co-simulation with communication step size control in an FMIcompatible master algorithm. In Proceedings of the 9th International Modelica Conference, pages 205–214, 2012.

[20] C. Stergiou, S. Tripakis, E. Matsikoudis, and E. A. Lee. On the Verification of Timed Discrete-EventModels. In 11th International Conference on Formal Modeling and Analysis of Timed Systems – FOR-MATS 2013. Springer, 2013.

[21] S. Tripakis, C. Stergiou, C. Shaver, and E. A. Lee. A modular formal semantics for Ptolemy. Mathe-matical Structures in Computer Science, 23:834–881, Aug. 2013.

22

Documents

Bridging the Semantic Gap Between Heterogeneous Modeling ... · Bridging the Semantic Gap Between Heterogeneous Modeling Formalisms and FMI Stavros Tripakis 1;2 David Broman 3 fstavros,[email protected]