The FMI 3.0 Standard Interface for Clocked and Scheduled Simulations

This paper gives an overview of the FMI 3.0 support for two kinds of clock-based simulations: Synchronous Clocked Simulation, and Scheduled Execution. The former is used when the information about multiple simultaneous events (cause and exact time of occurrence) can be unambiguously conveyed. The later facilitates real-time simulations comprising multiple black-box models, by allowing fine grained control over the computation time of sub-models. A formalization is presented along with example application scenarios, meant as an introduction to the conceptualization of clocks in the FMI Standard.


Introduction
As more and more Modeling and Simulation (M&S) tools are used in system engineering processes, it becomes clear that standards are needed to improve the interoperability of such tools.The Functional Mockup Interface (FMI) Standard (2.0 2014) aims at enabling the exchange and cooperative simulation of black-box models.Version 2.0 of the standard strikes a balance between supporting the most common features across the plethora of M&S tools, and enabling the advanced simulation scenarios.Its wide adoption has, however, placed pressure in supporting two important use cases are: simulation scenarios where timed and state events play a frequent role in synchronizing a subset of the participating models (e.g., controller code with tasks running at different rates); and scenarios where the goal is to control the computation time of the different models, so that a real-time co-simulation can be achieved.
Contribution.This paper gives an overview of the FMI 3.0 support for two kinds of clock based simulations: Synchronous Clocked Simulation (SC), and Scheduled Execution (SE).The former aims at scenarios where the cause and exact time of occurrence of multiple simultaneous events can be unambiguously conveyed.The later facilitates real-time simulation among black-box models, by allowing a finer grained control (compared to version 2.0) over when/which model partitions can be executed.
Structure.The next section will introduce the common concepts and the interface elements that are common to SC and SE.Then in Section 3 SC is detailed, along with a motivating example.Section 4 focuses on SE, following the same structure as Section 3. In Section 5, we discuss some of the relevant related works, and in Section 6 we summarize and conclude.

Common Interface and Concepts
Co-simulation is a technique to combine multiple blackbox simulation units to compute the combined models' behaviour.See Kübler and Schiehlen (2000) and Gomes et al. (2018), for an introduction.The simulation units, often developed and exported independently from each other in different M&S tools, are coupled using an orchestration algorithm, often developed independently as well, that communicates with each simulation unit via its interface.This interface, an example of which is the FMI Standard interface for Co-Simulation, comprises functions for setting/getting inputs/outputs and computing the associated model behaviour over a given time interval.
The FMI 3.0 defines three interface types: the Co-Simulation (CS), the Model Exchange (ME), and the Scheduled Execution (SE).In the FMI, a simulation unit is called a Functional Mockup Unit (FMU), and it may implement one or more of the three interfaces.An FMU is a zip containing: binaries and/or source code implementing the API functions; miscellaneous resources; and an XML file, describing the variables, model structure, and other data.
For each interface type, the FMU may implement optional features, such as declaring synchronous clocks (in case of ME or CS), or scheduled execution clocks (in case of SE). Figure 1 summarizes the different interface types and the main concepts relevant to this paper.All three interfaces (CS, ME, and SE) share common functionality, such as the declaration and usage of variables and clocks.
The differences between the three interface types can be seen on the left hand side of Figure 1.The Importer refers to the software that imports the FMU.We distinguish three importers, each corresponding to one of the interface types, and each with different responsibilities.The ME importer often needs to provide a differential equation (ODE) solver, and must handle events.In contrast, the CS importer does not need to provide an ODE solver, because such a solver can be implemented inside the CS FMU.Finally, the SE importer needs a task scheduler that will determine exactly when each task implemented in the FMU will be executed.
The ME and CS both contain mechanisms to communicate events to the importer, and, as we detail later, both enable Synchronous Clocked (SC) simulation.
Broadly, a simulation involving multiple connected FMUs goes through the following modes1 : Initialize -The FMUs are instantiated and their initial state/inputs/outputs/parameters are calculated or set by the importer.
Step -The simulation is progressing in simulated time, and FMUs that represent ODEs are being numerically integrated.Event -The simulated time is stopped and events (e.g.clock ticks, parameter changes) are being processed.Terminate -The simulation has finished and all resources are freed.The Step and Event modes come after the Initialize mode, and are interleaved.
In the following sub-sections, we introduce FMI3.0 clocks, how they are declared, connected, and interacted with, as well as common constraints imposed by the standard.These are common to the SC and SE clock interpretations.

Clock Taxonomy
Clocks represent an abstraction of activities whose occurrence is tied to specific points in time.They appear in many modeling formalisms for systems that interact with the real world (Benveniste et al. 2003;Modelica Association 2021), where it is important to represent computa-tions that happen at different rates, or as a result of conditions observed in the environment.Conceptually, each clock represents a sequence of instants in time where the clock is active, called ticks.From the entities that can interact with a clock, we highlight the FMU and the importer (recall Figure 1).The FMU is the entity that declares the clock, while the importer is the code activating the clock in the FMU.
Clocks are declared in the XML file, and can be seen as a special kind of variable.The XML description for each clock contains, among others, an identifier called the value reference, a causality attribute (whether the clock is an input or output, as we will discuss later), and an interval attribute (declaring the type of clock, discussed later).Dynamically, during the simulation, each clock can be either active or inactive (denoted as the clock's state), and its state can be either set or get by the importer, depending on the clock type and its causality (see below).
There are two main types of clocks: time-based and triggered.Time-based clocks are associated with an interval, dictating, at any moment in simulated time, the interval (in simulated time units) between the last tick and the next tick.Such intervals can be queried or set by the importer, depending on the clock's interval attribute (see below).In contrast, triggered clocks have no a priori known interval.The FMU or importer has to set/get the (activation) state of the clock.The different clock types are listed in Table 1 according to who calculates the intervals and ticks the clock.
Before discussing the causality of clocks, it is important to distinguish between the entity that dictates the clock interval vs. the entity that actually activates the clock.This distinction is important in the context of the FMI because the simulated time is a real-valued quantity, represented by a finite-resolution variable.For example, the FMU may declare the interval of a periodic clock in the XML, but it is the importer that will decide exactly at which simulated time the clock ticks.Due to numerical inaccuracies, it may happen that the interval (in simulated time) between clock ticks does not match exactly the interval declared by the FMU.
Time-based clocks are always input clocks, since it is always the importer that is responsible for activating the clock (even though the clock interval information may come from other entities, as shown in Table 1).Triggered clocks, on the other hand, can be input or output clocks.Triggered input clocks, just like time-based input clocks, can only be set by the importer, whereas triggered output clocks are set internally by the FMU, and can only be queried by the importer.The causality therefore plays a role in determining how clocks can be connected.

Clock Variables and Dependencies
Just like any other variable, an output clock can be connected to an input clock.It is also possible to connect two input clocks or even have one input clock connected to two different output clocks.A connection from clock w c to clock v c means that whenever clock w c ticks, then clock v c should also tick.For triggered clocks, that is relatively easy to enforce: whenever one clock activates, the other should be activated.For time-based clocks, the importer must take into account the interval attributes of the clocks and decide whether such connection makes sense or not.For example, if one clock has a constant interval, and another clock has a fixed interval, then the importer may simply set the correct period for the second clock.FMUs can declare the internal dependencies between their output and their input variables in the XML section denoted as Model Structure.An output variable y depends on an input variable u when the computation of y's value requires the value of u.For example, in Figure 2, y m is computed from, among other dependencies, u m .
Each output clock y c can also depend on one or more input clocks or variables.The meaning is that the state of such input clocks or the value of the input variables is taken into account when deciding whether y c will tick.For example, in Figure 2, y c m may tick when u c m ticks, or because of the value change of u m .Note that it is not necessarily the case that y c will tick whenever an input clock, that y c depends on, ticks.
When a clock w c ticks (we use w c when the causality of the clock is irrelevant), there is a set of variables whose values are computed.We denote that set by "w c 's variables", or "clocked variables" when the specific clock is unimportant.FMI imposes few constraints on the clocked variables.However, the FMU can declare in its XML, for each variable, which clocks w c depends on (usually one).For example, in Figure 2, y m is computed when u c m ticks.Lacking such declaration, the importer needs to assume the worst case: all output variables are computed when w c ticks.The value of w c 's variables should only be accessed when (one of the) w c is active, i.e., is ticking.Accessing the w c 's variables when w c is not ticking results in undefined behaviour.

Synchronous Clocked Simulation
In this section, we describe the Synchronous Clock (SC) interpretation of the clocks interface, introduced in the previous section.This interpretation is inspired by the clock implementation in the Modelica specification (Modelica Association 2021) and existing synchronous clock theories such as Benveniste et al. (2003), but had to be adapted to reflect the constraints of black-box co-simulation.
As such, we offer no guarantees of semantic equivalence.
We start with detailing the main simulation modes for both ME and CS FMUs, as if no clocks were declared.In order to focus on the essential mechanisms, we abstract away from the ME and CS interfaces, and present them in a unified manner using set theoretic constructs, while referring the reader to the standard for more details.

Background on CS and ME
Following the super-dense time formulation as in Lee and Zheng (2005), the simulation time is a tuple t = (t R ,t I ) where t R ∈ R ≥0 , t I ∈ N ≥0 .In Step mode, the real part of time t R is increasing and t I = 0, and during Event mode, the integer part of time t I is increasing while t R is held constant.Figure 3 illustrates a possible trajectory for the values of a variable v under super-dense time.As can be seen, the Step mode produces a continuous evolution for the value of v, while the Event mode introduces discontinuities in the calculation of v.Under Event mode, a variable may acquire multiple values, each computed by one iteration of the Event mode, discerned by the t I part of the timestamp.
Step Mode Step Mode Event Mode In Step mode, the FMU and importer cooperate in approximating the solution of a system of differential equa-tions, described by the FMU.In the case of ME, the FMU provides the derivatives and the importer provides the inputs and solver, whereas in CS, the importer provides the inputs, and the FMU provides the derivatives and solver (recall Figure 1).
The importer may then switch the FMU to Event mode if one or more of the following situations occur2 : Time events -the simulated time t = (t R , 0) reached a value t R that was known at the end of the last Event mode; State events -The value of some variable crossed a threshold that is known to the FMU; Input events -The value of an input variable changed in a discrete way, introducing a discontinuity.In version 3 of the FMI Standard, both ME and CS interfaces describe the mechanism by which the FMU communicates the occurrence of events to the importer, so we will not discuss these mechanisms here.It suffices to assert that the importer is able to determine that the FMU should switch to Event mode at the appropriate simulated time.
During Event mode, the FMU and importer cooperate in solving a set of algebraic equations that are associated with the event that triggered the Event mode, known to the FMU.To solve the equations, the importer will typically construct a dependency graph between the output and input variables, using the Model Structure declared by the FMU.Note that the FMU may be part of a larger simulation model, where external variables form its inputs, and can also depend on its outputs.Therefore the dependency graph may involve not just the FMU variables, but other relevant external variables.As a result, there might exist cyclic dependencies between variables of the FMU.These manifest in the form of non-trivial strongly connected components in the dependency graph (Tarjan 1971).It is up to the importer to solve the algebraic loop, by setting and querying the variables of the FMU.The FMU plays its role by recomputing any output variable that might change as a result of new values for the input variables set by the importer.The important outcome is that all variables of the FMU have acquired a value.
The FMU may remain in Event mode, and perform a new iteration, if more events occur.These new events may be caused by the importer or by a new value for some variable.The FMI defines the mechanism by which the FMU or importer agree that a new event iteration is needed.Each new event iteration corresponds to one increment in the integer part of the simulated time.If no more event iterations are needed, Event mode is finished.
Note that, in Event mode, as part of the procedure to solve non-linear equations, there may be hundreds of iterations to converge and obtain a solution.These intermediate values are not shown in Figure 3 and do not cause the integer part of super-dense time to increment because they happen within one super-dense time instant.Therefore in Figure 3 there are three event handling iterations.When switching back to Step mode, the FMU also informs the importer of the next time-based event (if such event is defined).

Discerning Events
The basic event signaling mechanism offered by FMI 2.0 is adequate for most applications that do not rely on many events.However, they are insufficiently expressive for simulations with many simultaneous events.We illustrate this with a simple example shown in Figure 4, devised to motivate the need for clocks.The example shows a closed loop control system, where the CtrlFMU is specified as an FMU, and the remaining sub-models are specified in some other language.We sketch the CtrlFMU equations, but note that the importer has no access to these (it can only query the FMU for the values of the output variables).The CtrlFMU, every 1/r seconds (we abuse the notation r to denote both a clock r and its frequency), gets a sample from the Plant (produced by the Sensor), and calculates its next state, based on the previous state pre(u_r), the sampled value x_r, and some configuration parameter a that is calculated by the Supervisor.The latter, depending on the Plant dynamics, the sampling rate of which we ignore, may decide to reconfigure the Controller.
Using only the basic event mechanism of FMI, it is cumbersome to simulate Figure 4, for the following reasons: • If it is the FMU that decides when to sample, there is no way for the importer to know the sample rate r.The importer only receives information about the next time event, after each Event mode of the CtrlFMU.• There is no way for the FMU to know exactly which equations to enable when entering Event mode.
When the Supervisor computes a new value for a_s, the CtrlFMU must be in Event mode, because of the input event.Then CtrlFMU must rely on approximate floating point comparisons to know that only the Config equation is to be enabled.Conversely, when a new sample x_r is available, the CtrlFMU must know that the Config equation must remain disabled.Figure 5 shows how clocks address the limitations highlighted by the example in Figure 4.By introducing a triggered input clock s and a time-based input clock r, it is made clear who is responsible for the unambiguous activation of the clocks: the Supervisor controls s, and the importer controls r.Furthermore, no approximate floating point comparisons are needed to know which equations have to be active when entering Event mode.

Synchronous Clocks Semantics
We now detail the main functions that interact with clocks.
In order to do so, we must define a compact FMU abstraction.Without loss of generality, we can focus on formalizing what happens in a simulation where the FMU is in Step mode, switches to Event mode, and then resumes Step mode.
Definition 1 (SC FMU Instance).An SC FMU instance with identifier m is represented by the tuple ′ represents the state at (t R ,t I + 1) and b informs the importer whether one more Event iteration is needed.
• nextT m : S m × U c m → R ≥0 ∪ {NaN} is the function that allows the importer to query the time of the next clock tick.This function is only applicable to tunable, changing, and countdown clocks, and the returned value is calculated according to the clock type as discussed in Table 1.The value NaN can be returned for countdown clocks, and it means that the clock currently has no schedule.The major differences between above formalization and the FMI interface are as follows.
• There is no explicit representation of state.Most FMI functions take an FMU instance as an argument, and the manipulations to the instance are performed implicitly.We choose to make state explicit so as to explicitly convey which functions change the state of the instance.• The FMI describes the callback function by which, in CS, the FMU and importer may decide when to prematurely terminate the invocation to stepT m .For ME, the importer is responsible for implementing stepT m (recall Figure 1).We now discuss informally the semantics of each function implemented in an FMU instance m, with a focus on the clock functions.Since clock operations happen only in Event mode, we will focus on that mode.Moreover, we present the semantics in the order that a generic importer would interact with the FMI instance m.
Entering Event Mode.Clocks can only tick in Event mode.During Step mode, the FMI provides mechanisms for the FMU and importer to agree that there's a clock that needs to tick, and will therefore switch the FMU to Event mode at the appropriate time.m (input or output) has been activated, and let (t R ,t I ) represent the current super-dense time.When w c m is activated, there is a set of equations, associated to w c m , that becomes active (are enabled) for the current super-dense time instant (t R ,t I ).The set of output variables whose value is computed by w c m 's equations is denoted as "w c m 's variables".While w c m is active, invocations to get m on w c m 's variables will trigger their computation according to w c m 's equations.However, the values that w c m 's variables acquire while w c m is active are only made permanent when commit c m is invoked.If set c m is invoked to de-activate an active clock w c m at time (t R ,t I ) (before commit c m is invoked), then m should ensure that w c m 's variables return to the values they had immediately before w c m became active (this is not a strict requirement, since those variables should not be consulted once w c m became inactive).When stepE m is invoked, w c m becomes inactive along with its equations, and the superdense time instant becomes (t R ,t I + 1).If stepE m is invoked before commit c m is invoked, then commit c m is invoked by m.

Propagating Clock Activations. In Event mode, if a clock w c
m is (in-)active at super-dense time (t R ,t I ), then the importer must ensure that all other clocks that are connected to w c m must also be (in-)active for time (t R ,t I ).Triggered output clocks may activate during a super-dense time instant, or after a call to stepE m .Therefore, the importer must query triggered output clocks to monitor activations.FMI allows declaring the variables in the XML file that may influence a triggered output clock (recall Figure 2).It is outside the scope of FMI to ensure that a simulation scenario is well defined (e.g., it does not result in an infinite number of (de-)activations).
Scheduling Time-Based Clocks.In Event mode, after a call to stepE m , at super-dense time (t R ,t I ), m must be able to inform the importer of the time of the next tick of each clock u c m ∈ U c m that is tunable, changing, or countdown.This is done through function nextT m , when u c m satisfies one of the following conditions: 1. u c m is a countdown clock; or 2. u c m is not a countdown clock, and u c m was active in the super-dense time that was just concluded, at time (t R ,t I − 1).The Importer should use this information to schedule the next Event mode.If nextT m returns 0, then the importer must do a new event iteration.
Generic Clocked Simulation Algorithm.The following summarizes the Event Mode algorithm that coordinates the simulation with multiple FMU instances, with connected inputs/outputs and clocks.Let M denote the set of FMU instances participating in the simulation.We assume that one FMU instance m ∈ M or the importer has requested to enter Event mode.Therefore we assume that every other instance m ′ ∈ M ∧ m ′ ̸ = m has been stepped up to the same super-dense time (t R , 0).In the following, we use _ to denote an non-important argument.The goal of Step 3 is to solve the system of equations that became active due to the clock activations.There are no guarantees that such a system has a solution, or that the clock activations will stabilize.It is up to the Importer to determine this, so we leave it intentionally unspecified.

Scheduled Execution
SE and SC have the following in common: they use the same clock types, as introduced in Section 2; directly connected clocks (e.g., y c m and u c n in Figure 2) will tick at the same simulated times (although the corresponding equations will be executed at different wall-clock times, see below); after a clock tick, there may be more clock ticks, either at the same time, or at some time in the future.However, there are differences, detailed later: • Each SE clock w, when activated at simulated time t R ∈ R ≥0 , represents a task that needs to be executed.In contrast, in SC, w merely enables a set of equations that are subsequently solved.• In SE, there is a clear distinction between the wallclock time, and the simulated time.For example, two clocks may tick at the same simulated time t R ∈ R ≥0 (because they are connected, or because they have the same period), but their corresponding tasks will execute at different wall-clock times.However, the two tasks will be computed with simulated time t R .• In SE, the execution of a task can be pre-empted by a higher priority task.This has the important consequence that the FMU must inform the importer of when a task should not be pre-empted.The main goal of SE is to facilitate real-time simulation.

Motivating Example
Figure 6 shows an abstract example, where an FMU declares three input clocks and one output clock.Each input clock, when ticked, instructs the importer, who acts as a task scheduler (recall Figure 1), to execute the corresponding model partition (defined next) as soon as possible.
A model partition, or just partition, represents code that should be executed as soon as (in real time) an input clock ticks.Partitions contain arbitrary code that reads the inputs of the FMU, writes to the FMU's local variables (which can be shared among tasks) and outputs, and can trigger other clocks or update their interval.The inputs to each partition are set by the importer immediately before executing that partition, as part of the task corresponding to that partition.In Figure 6, u c m 's partition reads and writes the shared variable x m , and either updates the interval of v c m or ticks y c m .We stress the distinction between model partition and a task: the former represents code that is executed within the context of the later.So a task T contains code that sets the inputs of the FMU, invokes the model partition P, and reads the outputs.Such a task will simply be denoted as "P's task".For example, in Figure 6, when execution Partition 1's task, the importer sets the values for input u m before executing Partition 1.
In SE, there is a need for a function that the importer invokes, to tell the FMU to execute a partition.Note the difference between the partition activation function (defined later) and the clock set/get functions: the later inform the importer that a task should be scheduled, while the former executes as part of the previously scheduled task.
In Figure 6, input clock u c m ticks every 10ms and w c m ticks every 50ms, so every so often, the two clocks will tick simultaneously.When that happens, the scheduler needs to know whose task has the highest priority.As a result, the FMU needs to declare a priority level for each input clock.In Figure 6, u c m 's task (the one executing Partition 1) should be executed before w c m 's (Partition 3).Output clocks, in SE, are never directly associated to a partition of the FMU where they are declared.Instead, these can be connected to input clocks (including the ones of the owning FMU).
Because tasks can be pre-empted, certain operations, such as updating a shared variable, must be atomic (see example below).As such, the FMU must inform the importer of when it should not be interrupted, to prevent mixed resource access that would create inconsistent values.
Since partitions can trigger and update the interval of other clocks, there must be a mechanism for the FMU, in the middle of the calculation of a partition, to inform the importer that a clock has ticked or has a new interval, so that the importer can schedule the corresponding tasks.
Figure 7 illustrates a possible execution trace of the tasks corresponding to the partitions declared in Figure 6.At the initial wall-clock time, both task 1 and 3 are scheduled to execute.Since Task 1 has higher priority, it runs first, and Task 3 is delayed.While executing Task 1, the FMU informs the importer that v c m 's task (Task 2) should be scheduled to run at wall-clock time t 2 .At wall-clock time t 2 , Task 1 is still executing, so Task 2 is delayed until wall clock time t 3 .At t 3 , Task 2 starts executing, but note that the activation time of Task 2 is still its scheduled time t 2 .This is where the wall-clock time t 3 differs from the simulated time t 2 .At t 4 , Task 2 is pre-empted, because of Task 1. Finally, after being delayed substantially, Task 3 gets to execute, with its simulated time t 0 .

Scheduled Execution Semantics
The following formalization is a simplification meant to highlight the main functions defined in the FMI Standard.
The main concepts being formalized are tasks, clocks, and activation of model partitions.In addition, we will use the notation task(u c m ), for u c m ∈ U c m , to denote the task that will execute u c m 's partition.Scheduling Tasks.In SE, the importer operates as a scheduler of tasks that will activate the model partitions.As summarized in Table 1, clocks can be ticked by the FMU or importer, but we will focus on input clocks, since these are the ones that can be associated to a partition (when an output clock ticks, the importer is responsible for ticking all connected input clocks and therefore scheduling the corresponding tasks).Right after invoking (s m ′ , true) = get c m (_, y c m ) on an output clock y c m that is active, the clock y c m should be inactive in state s m ′ .An input clock u c m may tick, and its period may be updated, in the middle of an activate m computation.Because task(u c m ) may be of high priority, the importer must not wait the end of activate m to schedule task(u c m ).As such, the importer implements a function update m : S m → S m defined by the FMI, that the FMU can invoke (in the FMI Standard, this is implemented as a callback mechanism).The importer, inside update m , may consult the status of clocks and their intervals (through get c m and nextT m functions), and schedule the corresponding tasks accordingly.
The time at which the importer schedules task(u c m ) is computed according to: u c m 's declared interval; function nextT m ; or through the get c m ′ (_, y c m ′ ) function of some other clock y c m ′ and FMU instance m ′ .In the last case, task(u c m ) is scheduled to execute as soon as possible, according to the priorities known to the importer.
Executing Tasks.A task task(u c m ) that is scheduled to time t i , due to the priorities chosen and consequent delays incurred, may only execute at a later wall-clock time t j > t i .When task(u c m ) is executed, it should set the relevant inputs through function set m (the importer knows the relevant inputs through the XML of m), activate the partition trough function activate m (_, u c m ,t i ), and possibly read the calculated outputs, through get m .
Safeguarding Pre-emption.Unless otherwise stated by the FMU or importer, a task can be pre-empted at any moment.In order to allow the FMU to inform its environment that the currently executing task should not be pre-empted, the FMI defines two functions: lockP and unlockP that the FMU and importer can invoke, and are implemented by the importer.lockP informs the environment that a task cannot be pre-empted until unlockP is invoked.
Generic Scheduled Execution Algorithm.Let M denote a set of FMU instances, assumed to be initialized.An extensive study of hybrid system simulation challenges was carried out in Mosterman and Biswas (2000), and includes, for example, the possibility of an event iteration driving the system into chattering.And Tripakis and Broman (2014), Broman et al. (2015) and Liboni et al. (2018) focus such discussion in the context of the FMI Standard, providing solutions to some of these challenges.These works complement ours by helping importers assess whether a given simulation scenario is well behaved.We refer the reader to Gomes et al. (2018) for more references in co-simulation of hybrid systems.
The goal of this paper is to describe the main mechanisms standardized in the FMI Standard that enable synchronous clocked simulation and scheduled execution.We can therefore highlight related work that share the same goals.
Regarding SC simulation, we highlight the work in Otter, Thiele and Elmqvist (2012) and Elmqvist, Otter and Mattsson (2012), that introduce the synchronous clocks constructs used in the Modelica language, specified in Modelica Association (2021).Such work, and references thereof on synchronous languages (Benveniste et al. 2003;Colaço and Pouzet 2003), were used as basis for the definition of the SC approach described here.The main difference is that an SC clock does not enforce a partition on the equations that can be written by it.These differences make it more difficult to ensure well-formedness of cosimulation scenarios, but provide more flexibility, reflecting the heterogeneous use cases of FMI.

Conclusion
This paper summarizes the results of the FMI project developing interfaces to interact with clocks.This is a challenging task, because the kinds of simulation scenarios covered can combine traditional events with clock ticks, and may possibly be ill-defined while still conforming to the FMI Standard.This is intentional, as the FMI aims at flexibility, placing the burden of ensuring well-formedness on the importer.
We have presented two interpretations of clocks.The main differences between them lie in the degree of control that the importer has over the duration of computations, and on the behavior of the independent variable with respect to the wall clock time.The formalization provided is meant as an introduction to the clocks and their conceptualization in the FMI Standard.The FMI Standard document is continuously being improved, and therefore remains the source of truth.We refer the reader to (Junghanns et al. 2021) for an account of the most important features being developed for the FMI 3.0.

Figure 2 .
Figure 2. Example clock connections and dependencies.The symbols m and n refer to FMUs.

Figure 3 .
Figure 3. Example variable trajectory under super-dense time.
nextT m ⟩ where: • S m represents the abstract set of possible FMU states.A given state s m ∈ S m of m represents the complete internal state of m: active clocks, active equations, current mode (Step or Event mode) current valuations for input and output variables, etc. • U m and Y m represent the set of input and output variables, respectively.• U c m and Y c m represent the set of input and output clocks, respectively.• set m : S m × U m × V → S m and get m : S m × Y m → S m × V are functions to set the inputs and get the outputs, respectively (we abstract the set of values that each input/output variable can take as V ).Both set m and get m return a new state because both can trigger the computation of equations.• set c m : S m × U c m × B → S m and get c m : S m × Y c m → S m × B are the functions that (de-)activate the input clocks and query the output clocks (returning the activation status), respectively, and B denotes the boolean set.• commit c m : S m ×W c m → S m is a function that updates the clocked states of a given input/output clock in the set W c m = U c m ∪ Y c m .Clocked states are clocked variables whose value depends on the previous value (e.g., u_r in Figure 4).• stepT m : S m × R ≥0 → S m × R ≥0 × B is a function representing the Step mode computation.If m is in state s m at simulated time (t R ,t I ), (s m ′ , h, b) = stepT m (s m , H) approximates the state s m ′ of m at time (t R + h, 0), with h ≤ H.When b = true, we know that the importer and m have agreed to interrupt the Step mode prematurely, and m is ready to go into Event mode.• stepE m : S m → S m × B represents one super-dense time iteration of the Event mode.If m is in state s m at time (t R ,t I ), then (s m ′ , b) = stepE m (s m ) represents the computation of m's internal super-dense step transition, where s m Such mechanisms are represented by (s m ′ , h, b) = stepT m (s m , H), when b = true.In this case, s m ′ represents the state of the FMU ready to begin the Event mode, at super-dense time (t R + h, 0), where t R is the real part of the time of s m .As discussed in Section 3.1, the causes of b = true can be many.Ticking Clocks.In Event mode, m in state s m ∈ S m may activate any triggered output clock y c m ∈ Y c m , a fact that can be communicated to the importer via the function call get c m (s m , y c m ).Conversely, any input clock u c m ∈ U c m that needs to be ticked (according to the interval information), is activated by the importer, through the function call set c m (s m , u c m , true).Enabling/Disabling Clock Equations.Let s m ∈ S m denote the state of m right after a clock w c 1. Every m ∈ M enters Event mode (super-dense time instant is t I = 0); 2. Activate any time-based clocks scheduled to tick at (t R , 0), by invoking set c m ′ (_, w c m ′ ) for any input/output clock w c m ′ ∈ W c m ′ and any instance m ′ ∈ M; 3. Construct and solve system of equations for t I : (a) For all y c m ∈ Y c m of any instance m ∈ M, forward activation state of triggered clocks: i. Invoke get c m (_, y c m ), and set c m ′ (_, u c m ′ ) or get c m ′ (_, y c m ′ ), for any other clock u c m ′ ∈ U c m ′ or y c m ′ ∈ Y c m ′ and instance m ′ ∈ M that is transitively connected to y c m or has become active as a result of the clock activations; ii.Invoke commit c _ (_, w c ) for any active input/output clock w c whose input variables have been set.(b) Invoke get m ′ (_, y m ′ ) and set m ′ (_, u m ′ , _) in the appropriate order, for any instance m ′ ∈ M. 4. Invoke stepE m (_) for m ∈ M (signals end of Event iteration t I ). 5. Schedule clocks by invoking nextT m on every relevant clock, for m ∈ M. 6.If any m ∈ M wishes to repeat the event iteration, or if a clock returned a zero interval, go to Step 3 (start iteration t I + 1).

Figure 6 .
Figure 6.Motivating example, where an FMU declares three input clocks and one output clock.

Definition 2 (
SE FMU Instance).An SE FMU instance with identifier m is represented by the tuple ⟨S m ,U m ,Y m ,U c m ,Y c m , set m , get m , get c m , activate m , nextT m ⟩ where: • S m , U m , Y m , U c m , and Y c m , are defined as in Definition 1. • set m : S m ×U m × V → S m and get m : S m ×Y m → V are functions to set the inputs and get the outputs, respectively.In contrast with the SC FMU in Definition 1, get m does not alter m's state because any nontrivial computation of outputs should be done in the partitions associated with the input clocks, executed through the invocation of the activate m function.• get c m : S m ×Y c m → S m × B queries the output clocks.Note that, in contrast to SC, get c m (_, y c m ) changes the state of m, because it automatically de-activates y c m (the justification is provided below).• activate m : S m × U c m × R ≥0 → S m is a function representing the computation of a partition.If m is in state s m at wall-clock time t i , s m ′ = activate m (s m , u c m ,t i ) represents three successive steps: the activation of clock u c m , the computation of the partition associated to clock u c m , and de-activation of clock u c m .In state s m ′ , clock u c m will be inactive.• nextT m : S m × U c m → R ≥0 ∪ {NaN} is the function that allows the importer to query the time of the next clock tick.It is defined as in Definition 1.
1. Schedule task(u c m ), for all u c m ∈ U c m and all m ∈ M, if interval of u c m is constant fixed, or calculated; 2. When update m (_) is invoked, do: (a) Lock pre-emption with lockP; (b) If (_, true) = get c m (_, y c m ), schedule task(u c m ′ ) for any clock u c m ′ that is transitively connected to y c m .(c) Unlock pre-emption with unlockP; Overview of relevant concepts.Note that there might be domain specific importers which do not need an ODE solver because the supported FMUs do not contain continuous variables.This figure attempts to illustrate the most common differences between the interface types.

Table 1 .
Overview of clock types and their attributes.
3. Each task task(u c m ) is implemented as: (a) Set the inputs of m using set m (locking preemption with lockP and unlockP if needed); (b) Invoke activate m (_, u c m ,t i ), where t i is the simulated time that task(u c m ) was scheduled to execute.(c) Get the outputs of m using get m (locking preemption with lockP and unlockP if needed); Synchronous clocks are one of the solutions proposed to tackle the more general challenge of co-simulating hybrid systems.Other proposals have been made in the state of the art, but none of them tackle the problem of discerning different simultaneous events in the context of co-simulation.For instance, Cremona et al. (2016) proposes a master algorithm hybrid co-simulation.The proposal includes support for absent signals, mandatory implementation of rollback, zero duration step size, cosimulation FMUs supporting feed-through, and predictable step sizes.However, it excludes algebraic loops, due to the introduced non-determinism.Our proposed interfaces enables algebraic loop resolution, even when clocks are involved, but does not provide guarantees of convergence.
and AUTOSAR Standards, which enable different suppliers to develop and test software independently, and subsequently integrated the different applications.Such work complements the SE Interface by standardizing the importer environment, where FMU SE instances can execute.