modular multi-rate and multi-method real-time simulation - liu

Modular Multi-Rate and Multi-Method Real-Time Simulation

Bernhard Thiele† Martin Otter† Sven Erik Mattsson‡

[email protected] [email protected] [email protected]† German Aerospace Center (DLR), Institute for System Dynamics and Control,

82234 Wessling, Germany‡ Dassault Systèmes AB, Ideon Science Park, SE-223 70 Lund, Sweden

Abstract

The demand to ever increase realism and scope ofmodels routinely exceeds the currently available com-puting power and thus requires thoughts on improv-ing simulation efficiency. This is especially true forreal-time simulations, where fixed timing constraintsdo not allow to just “wait a bit longer”.

This paper presents a new approach in Modelica thatallows a modeler to separate a model into different par-titions for which individual solvers can be assigned. Ineffect, this allows to use multi-rate and multi-methodtime integration schemes that can contribute to im-prove the efficiency of a (real-time) simulation.

The first part of the paper discusses basic considera-tion relating to modular (real-)time integration. After-wards, the implementation of a convenient Modelicalibrary for the partitioning of physical models is brieflydescribed. Finally, the presented library is used to par-tition a detailed six degree of freedom robot model formodular simulation. The simulation performance ofthat partitioned model is compared to the simulationperformance achieved by using “conventional” globalsolvers.

Keywords: multi-rate / multi-method time integra-tion; simulation; clocked discretized continuous-timepartitions.

1 Introduction

Testing the actual embedded systems hardware inprocessor-in-the-loop (PIL) or hardware-in-the-loop(HIL) setups, usually requires that the “virtual” partsof the overall systems are simulated under real-timeconstraints. This means that the simulation must runas a hard real-time application that always meets itstiming deadlines.

Inputs and outputs of a real-time simulation need tobe processed at regular intervals. The length of this

interval is called the simulation frame time. The worstcase computation time needs to be less than the sim-ulation frame time. Explicit fixed-step solvers are ap-propriate numerical integration routines for real-timesimulations. Variable-step solvers are generally notappropriate for two reasons: a) because real-time sim-ulation must normally perform I/O operations at reg-ular intervals, and b) because the flexible number ofperformed simulation model evaluations impede deter-ministic prediction of worst case computations times.

Implicit fixed-step solvers are problematic in thecontext of real-time simulation, because the numberof iterations required by implicit methods is theoret-ically unbounded. However, their numerical proper-ties with regard to integrating stiff systems1 is muchmore favorable compared to explicit solver methods.When integrating stiff systems using explicit methods,the largest possible step size is severely limited due tostability problems of the integration algorithms. Im-plicit methods can perform much better in such cases.Because of that, attempts have been made to use im-plicit methods also in real-time simulation. Elmqvistet al. [5, 4] describe techniques that allow to minimizethe number of iteration variables for implicit methods(in some cases the number of iteration variables canbe reduced to zero!). These algorithms are available inthe commercial tool Dymola for real-time simulationpurposes under the umbrella term inline integrationalgorithms. The development of linearly implicit orsemi-implicit methods are another noticeable attemptin which implicit solver methods are “approximated”by methods that exhibit a bounded number of worst-case iterations. This improves the suitability of thesemethods for real-time simulation purposes

Computational resources are finite. As a conse-quence the computational requirements of the real-time simulation must accommodate with available

1Stiff systems typically contain dynamically fast and highlydamped components.

DOI10.3384/ECP14096381

Proceedings of the 10th International ModelicaConferenceMarch 10-12, 2014, Lund, Sweden

381

hardware resources. If the computational load re-quired for the simulation is too high, the simulationmodel needs to be adapted in order to meet the tim-ing deadlines. Typical options for improving the com-putational performance include model simplification,use of more efficient algorithms and operations, or re-placing computational intensive subsystems with fasttable lookups. Another option is to split the simula-tion model into subsystems, which can be executed inparallel across multiple processors, or which can beexecuted with different frame rates. The later optionis termed multiframing or multi-rate integration andcan be attractive if some subsystems have significantlylonger time constants than others. Details about typi-cal techniques used in the context of real-time simula-tion can be found in relevant literature, e.g., [7, 3].

The new synchronous language elements extensionto Modelica [8, Chapter 16] also provides languageprimitives that allow the developer to partition modelsinto several parts that can be solved separately by dif-ferent numerical solver methods. A crucial aspect ofthe partitioning task is to establish adequate couplingmechanism between the separate partitions. Following[6] the term modular simulation is used to underlinethat modular coupling approach.

During the partitioning the developer can take ad-vantage of a-priori system knowledge to improve theperformance of the simulation. Partitions can be exe-cuted with different frame rates and/or can utilize dif-ferent numerical integration algorithms. In that waymulti-rate and multi-method integration schemes canbe realized. To the knowledge of the authors, this is arather unique feature in a modeling language for physi-cal systems. However, the suitable preparation of sim-ulation models for multi-rate and multi-method inte-gration is still a non trivial task.

In order to facilitate the preparation of simula-tion models for multi-rate and multi-method integra-tion schemes a Modelica library named MULTIRATE

has been build that wraps necessary methodologicaland technical knowledge in an easy-to-use framework.The theory behind this library, as well as its technicalimplementation and application to practical problemswill be demonstrated in the following sections.

2 Clocked Discretized Continuous-Time

Using the synchronous language elements extension[8, Chapter 16] it is possible to define clocks thatassociate a continuous-time solver to the equations

associated to that clock. This is illustrated in Fig-ure 1. Line 4 defines a periodic clock with the in-

1model ClockedDiscretizedContinuousTime2Real x(start=0), u;3// 500 ms, no solver:4Clock clk = Clock(5,10);5// 500 ms, ExplicitEuler solver:6Clock clk_solver=7Clock(clk, "ExplicitEuler");8equation9// associate clock clk_solver to u:10u = sample(1.0, clk_solver);11der(x) = -x + u;12end ClockedDiscretizedContinuousTime;

0 1 2 3 40

0.20.40.60.8

time [s]va

lue

x

Figure 1: Clocked discretized continuous-time exam-ple.

terval 500ms. Line 7 defines a solver clock basedon the previously defined clock and assigns as solvermethod "ExplicitEuler". Other methods that arepredefined by the language standard are discussed be-low. Line 10 associates clock clk_solver with thevariable u (by “sampling” the literal constant 1.0using clock clk_solver). Due to clock inferencethe differential equation in line 11 can be deducedto be also associated with clk_solver and thereforethe differential equation needs to be solved by the"ExplicitEuler" method with a fixed-step integra-tion step size of 500ms. The corresponding plot of xis shown at the right-hand side of Figure 1.

The specification [8, Section 16.8.2] defines theconceptual solution algorithms of the predefined meth-ods (tools may provide support for additional solvermethods). Since the following discussion is based onthese algorithms the respective part from the specifica-tions is reproduced below in a slightly adapted form2.

The solvers are defined with respect to the underlying or-dinary differential equation in state space form to which the

2Most notably, in contrast to the specification text the solvermethods are defined in terms of integrating from clock tick ti toti+1, instead of from ti−1 to ti. This is just a simple index shift.The advantage is, that it allows to present some equations in aslightly more concise and readable form.


382 Proceedings of the 10th International ModelicaConferenceMarch 10-12, 2014, Lund, Sweden

DOI10.3384/ECP14096381

Table 1: Predefined solver methods for solverclocks

Solver Method Solution method(for all methods:yi := g(xi,ui, ti))

Explicit-Euler

xi+1 := xi + h · xixi := f (xi,ui, ti)

ExplicitMid-Point2

xi+1 := xi + h · f (xi + 12 h · xi,

ui+ui+12 , ti + 1

2 h)xi := f (xi,ui, ti)

Explicit-Runge-Kutta4

k1 := h · xi

k2 := h · f (xi + 12 k1,

ui+ui+12 , ti + 1

2 h)

k3 := h · f (xi + 12 k2,

ui+ui+12 , ti + 1

2 h)k4 := h · f (xi + k3,ui+1, ti+1)xi+1 := xi + 1

6 (k1 + 2k2 + 2k3 + k4)xi := f (xi,ui, ti)

Implicit-Euler

xi+1 := xi + h · xi+1†

xi := f (xi,ui, ti)

Implicit-Trapezoid

xi+1 := xi + 12 h · (xi + xi+1) †

xi := f (xi,ui, ti)† Equation system with unknowns: xi+1, xi+1.

continuous-time partition can be transformed, at least con-ceptually (t is time, u(t) is the real vector of input variablesto the partition, x(t) is the real vector of continuous-timestates, and y(t) is the real vector of algebraic and/or outputvariables to other partitions):

x = f (x,u, t)

y = g(x,u, t)

The solver methods (with exception of "External"3) aredefined by integrating from clock tick ti to clock tick ti+1

and computing the desired variables at ti+1, with h = ti+1−ti = interval(ui+1) and xi+1 = x(ti+1).

Table 1 shows the definitions of the predefinedsolver methods using the notation from above.

3 Multi-Rate

Multi-rate integration can be attractive if some sub-systems have significantly longer time constants thanothers. This is often the case for multi-domain physi-cal systems since the components of different physicaldomains often exhibit significant different time con-stants. A typical example are systems with slow me-chanical parts which are controlled by fast electrical

3The solver method "External" means that the solutionmethod is defined in the simulation environment and not in theModelica model.

circuits. If an explicit integration method is used, thenumerical stability of the whole system depends on thefastest time constant and it is necessary to choose a re-spective small step size for integration.

The MULTIRATE library doesn’t impose limits onthe number of partitions with different frame rates thatmay be executed together. However, for clarity the ba-sic idea of multi-rate integration is demonstrated withtwo ODE partitions4 that will be discretized for twodifferent execution rates:

x f (t) = f f (x f ,xs, t) (1a)

xs(t) = fs(x f ,xs, t) (1b)

The sub-index f stands for the “fast” partitionand s stands for the “slow” partition. Using theExplicitEuler method from Table 1 for discretiza-tion results in a system of recurrence equations of theform:

x f (ti + j ·h f ) = x f (ti +( j−1) ·h f )

+ h f · f f(x f (ti +( j−1) ·h f ),

xs(ti +( j−1) ·h), ti +( j−1) ·h)

(2a)

xs(ti+1) = xs(ti)+ k ·h f · fs(x f (ti),xs(ti), ti

)

(2b)

where k and j are integers, k is the ratio of the two stepsizes, j = 1 . . .k, h f is the step-size of the fast partition,and ti+1− ti = k · h f = hs is the step-size of the slowpartition.

Note that Equation (2a) does not specify how xs(ti +( j− 1) · h) is calculated. Equation (2b) is not definedfor intermediate values between ti and ti+1. Therefore,an interpolation or extrapolation scheme needs to beused to estimate the intermediate values.

For real-time simulation the sequence in which thecomputation of fast and slow frames are interspersed isimportant. Ledin [7] describes three typical executionschemes. The timing diagram in Figure 2 shows thatexecution schemes by means of an example where theratio of the slow and the fast step size, k, is k = 3. Thethree schemes are described briefly below:

1. Multiframing in a single task with no fast-framereal-time I/O. The slow frame rate is treated as a“master” frame rate in which the slow frame isexecuted first, followed by a burst of the k fastframes. This scheme is only acceptable if the fastframes do not perform any real-time I/O.

4In general, partitions in the MULTIRATE library may consistof differential and algebraic equations and the partitions are cou-pled over designated input and output variables, but this is omittedhere in favor of a more succinct presentation of the basic idea ofmulti-rate integration.

Session 2E: Modelica Tools 1

DOI10.3384/ECP14096381


383

2. Multiframing in a single task with fast-framereal-time I/O. The fast frames are executed atfixed intervals of h f length. The computationsneeded in the slow frame are split into severalsubframes which are interspersed after the fastframe calculations. However, splitting the slowframe into several suitable subframes is rarely asimple thing to do. This is a serious drawback ofthis method.

3. Multiframing in a multitasking environment withrate monotonic scheduling (RMS). In this casethe scheduler will give CPU access to the taskwith the higher priority (computation of fastframes) and interrupt the lower priority task(computation of slow frames) until the higher pri-ority task has finished its computations. Duringthe times in which the higher priority task is idle,the CPU access is given back to the lower prior-ity task to resume its computations. No (manual)splitting into subframes is needed which is a hugeadvantage compared to the previous method.

hsRunningIdleRunningIdle

SlowFrame

FastFrame

tn tn+1

Time


SlowFrame

FastFrame

tn tn+1

h f


SlowFrame

FastFrame

tn tn+1

h f

Single task with no fast-frame I/O

Single task with fast frame I/O

Multitasking environment with RMS

Figure 2: Three different multiframing schemes forreal-time simulation.

4 Multi-Method

Multi-method integration (also called mixed-mode in-tegration) is yet another option to improve the execu-tion performance of (real-time) simulation. In contrastto multi-rate integration that uses different integrationstep sizes for distinct partitions, multi-method inte-gration uses different integration methods for distinctpartitions. Similarly to multi-rate integration, multi-

method integration can be attractive if some partitionshave significantly longer time constants than others.

A typical scenario is to split a system into fast partsand slow parts and use an implicit integration methodfor the fast parts and an explicit integration method forthe slow parts. Schiela and Olsson [11] describe sucha mixed-mode integration scheme (using explicit andimplicit Euler methods) in which they employ an auto-matic partitioning approach based on linearization andeigenvalue analysis. This disburdens the developerfrom partitioning the system. However, if a systemis highly nonlinear, inspecting eigenvalues becomesquestionable since the eigenvalues of the linearizedsystem move around with time. A user controlled par-titioning, leveraging a-priori system knowledge, canbe more adequate and effective in such cases.

Similar to multi-rate integration, the basic idea ofmulti-method integration is demonstrated on the ba-sis of two ODE partitions in the form of equation sys-tem (1). Using the ImplicitEuler method from Ta-ble 1 for the “fast” partition and the ExplicitEulermethod for the “slow” partition results in recurrenceequations of the form:

xs(ti+1) = xs(ti)+ h · fs(x f (ti),xs(ti), ti

)(3a)

x f (ti+1) = x f (ti)+ h · f f(x f (ti+1),xs(ti+1), ti+1

)(3b)

where h = ti+1− ti is the integration step-size. At first,xs(ti+1) is computed using the explicit Euler method.This value is afterwards used to compute x f (ti+1) us-ing the implicit Euler method.

The MULTIRATE library allows to combine any ofthe solver methods listed in Table 1. Note that it is eas-ily possible to combine multi-rate and multi-methodintegration within the framework of the MULTIRATE

library. This allows to exceed the benefits compared toapplying the methods separately.

5 Partition Coupling

An important aspect when applying multi-rate andmulti-method integration is the coupling between theinvolved partitions. In the context of the frameworkprovided by the MULTIRATE library the couplingscheme of Figure 3 depicts the basic idea (liberally ab-stracting from the details). Note that although the cou-pling is discussed by considering the special case oftwo coupled partitions, the basic principles carry overto the general case of n partitions.

Partition 1 and 2 may be discretized by using one ofthe solver methods defined in Table 1. Different solver



DOI10.3384/ECP14096381

x1 = f1(x1,u1, t)Partition 1

y1 = g1(x1,u1, t)

Extra-/Interpolation

x2 = f2(x2,u2, t)Partition 2

y2 = g2(x2,u2, t)

Extra-/Interpolation

u2y2n ,y2n+1

y1n ,y1n+1u1

t ∈ [Tn,Tn+1]

t ∈ [Tn,Tn+1]

Figure 3: Coupling of two partitions. Communicationtakes place at discrete time instants t = T0,T1, . . . ,Tk.Depending on the applied coupling scheme the ap-proximation of the coupling terms u1, u2 can be basedon interpolation (if y1n+1 , or respectively y2n+1 is avail-able) or it must be based on extrapolation.

methods, as well as different step sizes can be used aslong as the ratio of the step sizes is an integer.

Data exchange between clocked discretizedcontinuous-time partitions is only possible at clockticks. Therefore, the clock ticks of the slower partitiondetermine the discrete time grid in which data isexchanged between the two partitions. This is quitesimilar to the situation encountered in co-simulationscenarios, in which the communication and dataexchange between two distinct systems is restricted todiscrete synchronization points Tn.

However, in contrast to co-simulation the modularintegration considered in the MULTIRATE frameworkhas some distinctive characteristics:

• It inherits the characteristics of the synchronousmodel of computation that has been introducedin the “Synchronous Language Elements” exten-sion in Modelica 3.3 [8, Chapter 16]. This has theadvantage that the formal model of various cou-pling schemes can be expressed in a high-level,declarative manner which is close to the under-lying conceptual mathematical model. However,the drawback is that optimizations that require amore low-level control can not be realized.

• Modelica uses acausal connectors to assemblemodels of physical components. However, thecoupling of partitions according to Figure 3 re-quires causal data-flow. It is not obvious howconvenient and effective coupling schemes can be

realized when a model should be partitioned atacausal connectors.

5.1 Mathematical Model

For the further analysis more detailed mathematicalmodels than the one indicated in Figure 3 are pro-posed. As before, the discussion is based on two parti-tions, but carries over to more general settings involv-ing n partitions.

Figure 4 depicts a continuous-time domain modelfor two coupled partitions, including inputs (u1,u2)and outputs (y1,y2) due to real-time I/O hardware de-vices. The dynamics of the coupled partitions aremodeled as differential-algebraic equations (DAEs) inautonomous semi-explicit form

x1 = f1(x1(t), x2(t),z1(t), z2(t), u1(t)

)(4a)

0 = γ1(x1(t), x2(t),z1(t), z2(t), u1(t)

)(4b)

y1 = g1(x1(t), x2(t),z1(t), z2(t), u1(t)

)(4c)

x2 = f2(x1(t),x2(t), z1(t),z2(t), u2(t)

)(4d)

0 = γ2(x1(t),x2(t), z1(t),z2(t), u2(t)

)(4e)

y2 = g2(x1(t),x2(t), z1(t),z2(t), u2(t)

)(4f)

with differential variables xi ∈Rnxi , algebraic variableszi ∈ Rnzi , (real-time) inputs ui ∈ Rnui , and outputs yi ∈Rnyi where nxi ,nzi ,nui ,nyi ∈ N and consistent initialconditions xi(t0) = xi,0, zi(t0) = zi,0. The (continuous-time) variables with tilde, xi, zi, ui are reconstructedfrom a number of m ≥ 1 sampled (discrete-time) val-ues of the variables without tilde of the same name bymeans of extrapolation or interpolation using a “recon-struction” operator denoted Ψ

xi(t), zi(t) = Ψi(χi,ζi)(t) t ∈ [Tn,Tn+1] (4g)

ui(t) = Ψui(υi)(t) (4h)

where χi,ζi,υi are sampled at time instants tk ∈(Tn−m,Tn] (extrapolation), or tk ∈ (Tn+1−m,Tn+1] (in-terpolation)

χik ,ζik = xi(Tk),zi(Tk) k = 1 . . .ki, Tk < Tk+1,

ki ∈ N, χi ∈ Rnxi×ki , ζi ∈ Rnzi×ki

υik = ui(Tk) k = 1 . . .kui , Tk < Tk+1,

kui ∈ N, υi ∈ Rnui×kui .

The operator Ψ is loosely borrowed from the math-ematical framework described in [12, p. 1495], whereit is defined as extrapolation operator. The definitionthere is mathematically more technical and rigorousthan considered necessary for this work.


DOI10.3384/ECP14096381


385

x1 = f1(x1(t), x2(t),z1(t), z2(t), u1(t)

)Partition 1, t ∈ [Tn,Tn+1]

0 = γ1(x1(t), x2(t),z1(t), z2(t), u1(t)

)

y1(t)u1(t)

y1 = g1(x1(t), x2(t),z1(t), z2(t), u1(t)

)

u1(t)

Ψ1

x1(t),z1(t)

x1(t), z1(t)x2 = f2

(x1(t),x2(t), z1(t),z2(t), u2(t)

)Partition 2, t ∈ [Tn,Tn+1]

0 = γ2(x1(t),x2(t), z1(t),z2(t), u2(t)

)

y2 = g2(x1(t),x2(t), z1(t),z2(t), u2(t)

)

Ψu1

Ψ2

x2(t),z2(t)

x2(t), z2(t)

u2(t) u2(t)Ψu2

y2(t)

Figure 4: Illustration of the used continuous-time domain mathematical model for partition coupling, includingexternal real-time I/O (u1,u2,y1,y2). The inputs to the partitions are first sampled at discrete time instantst = T0,T1, . . . ,Tk, subsequently the operators Ψi are applied to the (time-discrete) signals in order to provideextrapolated/interpolated continuous-time signals during a period of continuous-time system evolution (t ∈[Tn,Tn+1]).

Data exchange between partitions and the update ofcoupling terms is restricted to the time-discrete syn-chronization points t = T0,T1, . . . ,Tk. In co-simulationthe steps from Tn → Tn+1 are referred to as macrosteps. The union of all macro-time steps is a a macro-time grid where the partitions update their couplingterms. Generally, the real-time inputs and outputsof the respective partitions may be sampled at dis-crete time instants that are different to the macro-timegrid instants. During a macro step Tn→ Tn+1 the dy-namics of the partitions evolve according to the gov-erning DAE using extrapolated (or interpolated) data.Note that xi, zi, ui are continuous in each macro stepTn → Tn+1 but may have jump discontinuities at thesynchronization points Tn.

Since this work is concerned with real-time simula-tion, it is natural to consider only equidistant macro-time grids with constant macro-step size h = (Tn+1−Tn). Moreover, the utilized synchronous frameworkin conjunction with the discretization formula givenin Table 1 suggests to describe the coupling within a(discrete-time) recurrence equation framework. Thestep-sizes hi of the two partitions may differ, but theratio between the slower and faster period must be aninteger multiple. Without loss of generality assumethat h1 is the faster partition and denote N = h2/h1 asthe frame ratio. The partitions are synchronized at thediscretization points (≡ macro-time grid)

t = k ·N ·h1 = k ·h2 = k ·h, k ∈ N. (5)

At these points the equations of both partitions have tobe fulfilled concurrently (synchronous model of com-putation).

The overall discretized system equations can now bedescribed in terms of the faster sampling period h = h1,further also denoted as micro-time step. The pre-cise time dependencies, i.e., at which instant ti = i ·h1on the micro-time grid coupling variables from timeinstant ti≤ j are required depend on the utilized dis-cretization method. Table 2 shows the dependenciesfor the solver methods supported by the Modelica stan-dard. The important characteristics to be observedare:

1. Algebraic equations always, regardless of the uti-lized solver method, require the variable values atthe current time instant on the micro/macro-timegrid.

2. For state integration using ExplicitEuler cou-pling variable values and state variable valuesfrom previous activation times are sufficient.

3. The other two explicit methods require couplingvariable values from the current time instant (dueto the occurrence of term ui+ui+1

2 in the definingequations in Table 1)!

4. The implicit methods require coupling variablevalues and state variable values from the currenttime instant.



DOI10.3384/ECP14096381

Table 2: Coupled variables time dependencies afterdiscretization

Solver Method Time instant dependenciesFor all methods: h1 is the step-sizeof the fast partition, andti+1− ti = N ·h1 = h2 = his the step-size of the slow partition,N, j ∈ N, N = h2/h1, j = 1 . . .N.x1,i, z1,i, x2,i, z2,i are approximatedfrom x1,i,z1,i,x2,i,z2,i by a suitableextrapolation method.Time dependencies in the algebraicequations are always:0 = γ1(x1,iN+ j, x2,iN+ j,

z1,iN+ j, z2,iN+ j)0 = γ2(x1,(i+1)N ,x2,(i+1)N ,

z1,(i+1)N ,z2,(i+1)N)

Explicit-Euler

x1,iN+ j = f1(x1,iN+ j−1, x2,iN+ j−1,z1,iN+ j−1, z2,iN+ j−1)

x2,(i+1)N = f2(x1,iN ,x2,iN , z1,iN ,z2,iN)

Explicit-MidPoint2 /RungeKutta4

x1,iN+ j = f1(x1,iN+ j−1, x2,iN+ j,z1,iN+ j−1, z2,iN+ j)

x2,(i+1)N = f2(x1,(i+1)N ,x2,iN ,z1,(i+1)N ,z2,iN)

Implicit-Euler /Trapezoid

x1,iN+ j = f1(x1,iN+ j, x2,iN+ j,z1,iN+ j, z2,iN+ j)

x2,(i+1)N = f2(x1,(i+1)N ,x2,(i+1)N ,z1,(i+1)N ,z2,(i+1)N)

This has the following consequences for clocked dis-cretized continuous-time partitions that are coupledwithin Modelica’s synchronous computation frame-work:

• In the general case, there is no scheduling of γ1and γ2, that satisfies reciprocal data dependencieswithout resorting to extrapolation from previousvalues.

• State integration using ExplictEuler allowsto use x1,iN , z1,iN = x1,iN ,z1,iN (no extrapolationneeded, since values already available at ti+1N).However, x2,iN+ j−1, z2,iN+ j−1 need extrapolationfor j > 1. Scheduling of f1, f2 at the macro-timegrid is always possible, since only past values arerequired at these points.

• For state integration using the remaining explicitand implicit methods, there is no scheduling of f1and f2 that satisfies reciprocal data dependenciesin the general case without resorting to extrapo-lation from previous values.

Note that in Modelica’s synchronous computationframework it is not allowed to have algebraic loopsspanning clocked discretized continuous-time parti-tions (however, it is allowed to have algebraic loopswithin a partition!). Therefore, there must be a sortingfor the coupling equations at macro-time grid pointsthat allows to evaluate them in a sequential order thatsatisfies data dependencies.

The previous discussion already allows to identifysome of the consequences when using the synchronousframework for partition coupling:

• A staggered method (Gauss-Seidel scheme) thatwould first integrate the slow partition, extrapo-lating the inputs from the coupled (fast) partition,and after that integrate the fast partition, interpo-lating from the results of the slow partition, is notfeasible. This is because within the synchronousframework new values are accessible only at thepoints at time where they are valid and not di-rectly after they have been computed. Also, it isnot possible for the modeler to directly influencethe sequence of calculations. This is at the dis-cretion of the simulation tool that will only guar-antee to respect data flow dependencies.

• Nevertheless, an execution scheme similar to the“Single task with no fast-frame real-time I/O” de-picted in Figure 2 is feasible, however, the inter-polation of coupling variables during executionof the fast partitions is not possible (extrapolationis required).

• The synchronous model of computation makesthe abstractions that equations at time instantsare evaluated instantaneously. However, in real-ity, computation takes time. From a real-time I/Otiming perspective it is desirable that the simula-tion time instants of inputs and outputs closely fitthe real-time instants. For that reason, dedicatedreal-time integrators are typically designed to re-quire only past inputs for the integration up to thecurrent time instant. This allows to compute theoutput values required at real-time instants t = Tn

during a computational period scheduled at t <Tn. This computational timing details are beyondthe scope of the Modelica specification. How-ever, observe that all solvers specified in Table 1(except ExplicitEuler) require the (real-time)inputs at t = Tn in order to compute the outputsat t = Tn. Therefore, the real-time outputs willbe inevitable afflicted with a (potentially consid-erable) computational delay (toutputs = Tn + tdelay).


DOI10.3384/ECP14096381


387

Obviously, it will often be desirable to keep atleast tdelay as small as possible. For the “Singletask with no fast-frame real-time I/O” scenario itis therefore advisable to schedule the computa-tion of the slow frame’s real-time outputs beforeexecuting the fast frames (just as depicted in Fig-ure 2)5.

• Parallel coupling methods using solely extrapo-lated coupling terms (Jacobi-scheme) can be re-alized within the available synchronous frame-work. Therefore, parallel execution of frames asdepicted at the bottom of Figure 2 should be fea-sible. This is expected to be particularly attractiveif a simulation can benefit from multi-core hard-ware and distribute the computational load on theavailable cores6.

• Some of the solver methods in Table 1 are multi-pass methods7, i.e., they require several “inter-mediate” evaluation of f (..) during integration.Since communication within the synchronousframework can only occur at clock ticks, theneeded intermediate values of the inputs u arecomputed by interpolation. The alternative to ac-tually acquire (real-time) samples of u for this in-termediate evaluations is not possible in the cur-rent framework. However, it should be noted thatfor dedicated real-time integrators the use of in-termediate input samples is typically considered[1, 9].

5.2 Partition Coupling at Acausal Connec-tors

In Figures 3 and 4 the coupling of partitions is accom-plished by causal (directed) dataflow. However, physi-cal modeling in Modelica relies on acausal connectors.It is not obvious how to accomplish partition couplingat the boundary of acausal connectors.

The following discussion is based on couplingsat the boundary of rotational mechanical connectorsfrom the Modelica Standard Library. However, the

5The Modelica standard doesn’t provide any possibility for amodeler to control the scheduling of computations. Therefore, areasonable scheduling of real-time I/O can be seen as an imple-mentation quality trait of a Modelica tool.

6However, the Modelica standard doesn’t provide any meansfor a modeler to control whether computations are parallelized. Atthe time of writing this article the authors are not aware of anyModelica tool that supports parallelization of clocked partitions.

7Namely, the solver methods ExplicitMidPoint2 andExplicitRungeKutta4.

presented principles are easily transferable to otherphysical connectors.

Consider the academic example model in Figure 5and assume the model shall be partitioned somewherebetween the inertias J1 and J2.

(a) Modelica component diagram of assembly.

φ1 φ2dc

cc

J1 J2

d1

c1

d2

c2

(b) Schematic diagram of mechanical assembly.

Figure 5: The example model: a linear 2-DOF oscilla-tor.

Figure 6 shows two common approaches to partitionthe model for modular integration [2]:

Force/displacement coupling Partition P1 providesthe cut torque at its boundary as output which isthe input to partition P2. Conversely, partition P2provides the displacement at its boundary as out-put which in turn is the input to partition P1 (Fig-ure 6a).

Displacement/Displacement coupling The couplingforce element of S1 is duplicated in S2. The twopartitions are coupled by the displacements of S1and S2 (Figure 6b).

5.3 Implementation in Modelica

The Modelica MULTIRATE library provides conve-nient building blocks for partitioning a model formulti-rate and multi-method simulation. It is imple-mented on top of the synchronous language elements,partly reusing functionality provided by the MODEL-ICA_SYNCHRONOUS library [10].

5.3.1 Force/Displacement Coupling

The component diagram in Figure 7a shows the oscil-lator from Figure 5a in a force/displacement couplingconfiguration. The coupling component subSample1is an instance of the SubSampleForceDisp class fromthe MULTIRATE library. The SubSampleForceDispclass provides a few parameters to modify the couplingcharacteristics, namely inferFactor to define that the



DOI10.3384/ECP14096381

φ1τ1 τ2

φ2

P2P1

dc

cc

J1 J2

d1

c1

d2

c2

[φ2φ2

]

τ1

(a) Force/displacement coupling.

cc

dcφ1τ1 τ2

P2P1

φ2

cc

J1

d1

c1

J2

d2

c2

dc

[φ2φ2

]

[φ1φ1

]

(b) Displacement/displacement coupling.

Figure 6: Partitioning the example model.

tool shall determine the sub-sample factor by clock in-ference. Otherwise, the sub-sample factor can be en-tered manually. Efficient polynomial extrapolation ofarbitrary degree nP is supported for extrapolating val-ues stemming from the slow partition during executionof the fast partition8. With default settings the out-put of the fast partition will be delayed one clock tick,however parameter useDirectFeedthrough allows toavoid that delay. The delay is necessary if both par-titions need at macro-time steps t = iN the currentcoupling values of the respective other partition. Ashas been discussed in Section 5.1 this reciprocal datadependencies lead to illegal algebraic loops spanningthe coupled partitions. Note that if at least one of thepartitions uses ExplicitEuler as solver method, ascheduling without algebraic loops may become feasi-ble and useDirectFeedthrough may be set to true.

The design of the icon of the SubSampleForceDispclass gives a visual clue regarding the intended place-ment within a model. The component at the left handside receives a displacement (φ and derivatives of φ ),and needs to provide a torque τ . This is typical forspring like elements. The right hand side compo-nent receives a torque and reacts with a displacement.This is typical for inertia like components. The sub-

8Note that nP=0 is equivalent to holding the value constantand nP=1 is equivalent to linear extrapolation. Moreover, whileincreasing the order of extrapolation may result in improved nu-merical stability and accuracy in some applications it may also de-teriorate numerical stability (see [2] for comprehensive numericalexperiments regarding extrapolation and interpolation of couplingsignals in co-simulation scenarios). In many cases, nP=0 or nP=1seems to be a good choice.

sampling factor is displayed at the bottom of the icon(provided that inferFactor=false).

The internal structure of the SubSampleForceDispclass is depicted in Figure 7b. The parallel brancheswith component uDirect1 and unitDelay19 are con-ditional branches. Their activation is mutually ex-clusive and depends on the value of the parame-ter useDirectFeedthrough. The subSample1 blockwraps Modelica’s subSample(..) operator, whichperforms fast-to-slow rate transitions. ComponentabsoluteSensor returns an array with the displace-ment variables {φ , φ , φ}. Upsampling and (polyno-mial) extrapolation of the variables is performed by thesuperSample1 block. Since φ is a discrete-time (sam-pled) signal (see Figure 4), it carries no informationabout its derivatives. It is the task of component moveto force the movement of flange flange_a according tosignals φ , φ and φ . In the implementation smoothnessinformation of φ is recovered at the sampling pointsby using the sampled values of φ and φ and setting therecovered signal equal to flange_a.phi. This is ac-complished by using the derivative annotation as de-scribed in [8, Section 17.7, “Declaring Derivatives ofFunctions”]. Components torqueSensor and torque1are from the Modelica Standard Library.

9The unitDelay1 block wraps the previous operator. Ac-cording to the current specification [8, Section 16.8.1] the use ofprevious within a clocked discretized continuous-time partitionis forbidden. However, the Dymola 2014 FD01 tool used for thiswork is more lenient and allows it. This is a desirable feature inorder to enable the described implementation.


DOI10.3384/ECP14096381


389

j2

J=10

j1

J=10d=10

cd1

c=1e4d=10

cd2

c=1e4fixed1 fixed2

assignSolver1 periodicClock1

100 us

ImplicitTrapezoid

d=10

cc

c=1e42

f ast slow

subSample1

p

t·1/z

assignSolver2periodicClock2

200 us

ExplicitRungeKutta4

(a) Example model using a force/displacement couplingin a multi-rate and multi-method configuration. The cou-pling component subSample1 is an instance of classSubSampleForceDisp from the MULTIRATE library.

absoluteSensor

{phi, w, a}phi,w,a

move

subSample1

factor

torque1

tau

superSample1

factor

n nP

superSample1

factor

n nP

torqueSensor1

tau

unitDelay1

1

zy_start=0

uDirect1

flange_bflange_a

(b) Component composition diagram of classSubSampleForceDisp. This class implements theforce/displacement coupling.

Figure 7: Force/displacement coupling using theMULTIRATE library.

5.3.2 Displacement/Displacement Coupling

The component diagram in Figure 8a shows the os-cillator in a displacement/displacement coupling con-figuration. The component cc is an instance of classSubSampleDispDisp from the MULTIRATE library. Itconstitutes both: the dynamic equations of motion forthe spring/damper element and the partition couplingequations.

The upper part of parameters of theSubSampleDispDisp class is identical to the pa-rameters provided by the SubSampleForceDisp class.The lower part provides parametrization for thespring/damper element.

The internal structure of the SubSampleForceDispclass is depicted in Figure 8b. Note that the dynamicequations for the spring/damper element are dupli-cated: while component springDamper1 is assignedto the slow partition, springDamper2 is assigned tothe fast partition. This “overlapping” integration of-ten leads to more favorable numerical stability proper-ties (see Busch [2]). Aside from this, the componentsappearing in Figure 8b are already known from Fig-

d=10

cc

c=1e4

f ast slow

3

j2

J=10

j1

J=10d=10

cd1

c=1e4d=10

cd2

c=1e4fixed1 fixed2

assignSolver1 periodicClock1

100 us

ExplicitMidPoint2

assignSolver2periodicClock2

300 us

ExplicitEuler

(a) Example model using displacement/displacement cou-pling in a multi-rate and multi-method configuration.

absoluteSensor2

{phi, w, a}phi,w,a

move2

d=d

springDamper2

c=c

absoluteSensor1

{phi, w, a}

subSample1

factor

subSample1

factor

d=d

springDamper1

c=cphi,w,a

move1

unitDelay1

1

zy_start=0

unitDelay1

1

zy_start=0

superSampleExpo2

factor

n nP

superSampleExpo2

factor

n nP

uDirect1

flange_bflange_a

(b) Implementation of displacement/displacement couplingclass.

Figure 8: Displacement/displacement coupling usingthe MULTIRATE-library.

ure 7b.While this section described the partitioning at the

example of 1-dimensional, rotational mechanics, it isneedless to say that the basic approach carries overto other physical domains. Furthermore, the mindfulreader may miss a SubSampleDispForce class. Thatclass was omitted, since it basically results by swap-ping and adapting respective components in Figure 7b.

6 Application to a 6-DOF RobotModel

In order to understand whether the partitioning is suit-able for “real-world” systems with considerable com-plexity, the RobotR3 example (a detailed model of arobot with six degrees of freedom) from the MultiBodypackage of the Modelica Standard Library (MSL) wasadapted and partitioned into three parts (see Figure 9):

1. “clockControl” partition. The partition con-sists of a clocked discrete-time path planningcomponent and clocked discrete-time P-PI cas-



DOI10.3384/ECP14096381

mechanics

1

3

2

5

4

6

pathPlanning

w

6 axes

axis1

axis2

axis3

axis4

axis5

axis6

clockControl

800 us

clockDrive

800 us

ImplicitEuler

fast slow

subSample5

p

t·1/z

fast slow

subSample6

p

t·1/z

fast slow

subSample4

p

t·1/z

fast slow

subSample3

p

t·1/z

fast slow

subSample2

p

t·1/z

fast slow

subSample1

p

t·1/z

clockMultiBody

800 us

ExplicitMidPoint2

assignSolver

axisControlBus1

axisControlBus2

axisControlBus3

axisControlBus4

axisControlBus5

axisControlBus6

cont

rolB

us

Figure 9: 6-DOF robot example adapted from theRobotR3 example of the multi-body package of theMSL.

cade controllers for the six axes (inner PI-controllers to control the motor speeds, and outerP-controllers to control the motor positions).Therefore, the continuous-time controllers andthe path planning component from the originalRobotR3 example were replaced by a discrete-time (digital) implementation. The sample periodof that partition is set to 800 µs.

2. “clockDrive” partition. The remaining parts ineach axis (motor including current controller andthe gearbox including gear elasticity and bearingfriction) are combined into a clocked discretizedcontinuous-time partition. The steady-state ini-tialization found in the original RobotR3 examplewas removed since the initialization of clockedpartitions differs from the standard scheme of ini-tialization in Modelica [8, Section 16.9, “16.9 Ini-tialization of Clocked Partitions”]. Instead, com-patible initial values have been set at appropri-ate places. “ImplicitEuler” with a step size of800 µs is used as solver method.

3. “clockMultiBody” partition. Except for set-ting compatible initial values, the multi-bodypart is identical to the original RobotR3 model.“ExplicitMidPoint2”, also with a step size of800 µs, is used as solver method.

Partitions “clockDrive” and “clockMultiBody” arecoupled at the mechanical flanges connecting the axes

with the mechanics multi-body system by force/dis-placement components with constant extrapolation(nP=0) and no direct feedthrough.

The simulation performance using the solver clockswas compared against simulations performed on thesame model (using various solvers), but without us-ing coupled clocked discretized continuous-time par-titions (see Figure 10).

mechanics

1

3

2

5

4

6

pathPlanning

w

6 axes

axis1

axis2

axis3

axis4

axis5

axis6

clockControl

800 us

axisControlBus1

axisControlBus2

axisControlBus3

axisControlBus4

axisControlBus5

axisControlBus6

cont

rolB

us

Figure 10: Comparison model: 6-DOF robot examplewithout coupled clocked discretized continuous-timepartitions.

The numerical experiment is conducted on a note-book with an Intel Core 2 Duo CPU P9700 @ 2.8 GHzand 4.0 GB of RAM. The simulation tool is Dymola2014 FD01 running on a 64-bit Microsoft Windows 7operating system.

The reference simulation result is obtained by sim-ulation of the comparison model (Figure 10) usingDASSL as integrator. The solver parameter “Toler-ance” is set to 0.0001 for all simulation runs. Thesimulation interval is always set to [0,2] seconds. Thestep size of the tested solver methods is iteratively in-creased until either integration fails (which for the con-sidered model typically means that too large residu-als appear while solving (nonlinear) systems of equa-tions), or the simulation result deviates considerablyfrom the DASSL reference solution.

The decision whether a result deviates considerablefrom the reference solution is made by two criteria:a) visual inspection of the trajectory of the load at therobot arm tip, and b) deviation of the trajectory to the


DOI10.3384/ECP14096381


391

reference solution defined by the norms

E2 =

√∫ te

t0er(t)2 dt (6a)

E∞ = supt≥t0

(er(t)) (6b)

where t0 is the simulation start time, te is the simulationstop time and

er(t) =‖r(t)− rDASSL(t)‖‖rDASSL(t)‖ r,rDASSL ∈ R3

provides a relative error measurement by relating thedistance between the obtained solution r(t) and thereference solution rDASSL(t) to the magnitude of thevector rDASSL(t). For the actual computation of E2and E∞, (6a) and (6b) are numerically evaluated overan uniformly spaced grid with spacing ∆t = 0.0008.Therefore, the integral in (6a) is approximated by nu-merical summation.

In Figure 11 the DASSL reference solution is com-pared with the result when simulating the coupled par-titions model of Figure 9 and the result when simulat-ing the comparison model of Figure 10 with an inlineimplicit Euler solver.

Figure 11a shows the first Cartesian coordinate ofthe trajectory of the robot arm tip. It can be observedthat the solution computed by the implicit Euler solverwith fixed step size 0.0016 s diverges considerably atthe end of the simulation run. Examining the evolutionof the norms E2 and E∞ confirms that observation (seeFigure 11b). At t = 2 s the relative error of the implicitEuler solution compared to the DASSL reference isabout 3%.

Beside using the DASSL integrator, various real-time inline integrators provided by the tool Dymola[5] were tested with the comparison model. Table 3summarizes the results obtained by that simulation ex-periments and contrasts them to the result obtainedby simulation of the coupled partitions model of Fig-ure 9.

The inline implicit Euler solver displayed the bestperformance of the tested “conventional” solvers.However, for this scenario it was possible to even out-perform that solver by a factor of about 2.9 (at com-parable accuracy to the reference solution) by using acoupling of clocked discretized continuous-time parti-tions in combination with judiciously selected solvermethods.

0.0 0.4 0.8 1.2 1.6 2.0

-1.0

-0.8

-0.6

-0.4

-0.2

0.0

Trajectory comparison of mechanics.load.frame_b.r_0[1]

[m]

(a) Trajectory of the first Cartesian coordinate of the robotarm tip.

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 20

0.005

0.01

0.015

0.02

0.025

0.03

Time [s]

Nor

m’s

val

ue

Norms E2 and E∞

E2 Coupled partitions

E∞ Coupled partitions

E2 Implicit Euler 0.0016s

E∞ Implicit Euler 0.0016s

(b) Evolution of the norms E2 and E∞ over the simulationtime.

Figure 11: Simulation results of coupled partition ap-proach and implicit Euler solver (step size 0.0016 s)compared to the DASSL reference solution.

7 Conclusions

This paper presented a new approach in Modelica thatallows a modeler to separate a model into different par-titions for which individual solvers can be assigned.This effectively allows multi-rate and multi-methodtime integration schemes that can improve simulationefficiency in certain cases. Additionally, there is a po-tential to execute the partitions in parallel to gain fur-ther simulation speedups. However, this is not sup-ported by currently available tools.

The approach is based on clocked discretizedcontinuous-time partitions, a concept that was intro-duced as part of the synchronous language elementsextension into the Modelica 3.3 language standard.However, until now it has not been applied in the con-text considered in this article.

The article started with a formal description of



DOI10.3384/ECP14096381

Table 3: Comparison of solver methods

Solver Step size (s) CPU-time for E2 E∞integration (s)

DASSL 10.8 0 0Coupled partitions 2×0.0008 0.7 0.0014 0.0019Inline implicit Euler 0.0008 2.0 0.0058 0.0081Inline implicit Euler (considerable deviation) 0.0016 (1.2) 0.0207 0.0313Inline trapezoidal 0.0008 2.1 0.0059 0.0082Inline trapezoidal (considerable deviation) 0.0016 (1.3) 0.0208 0.0313Inline explicit Euler 0.00002 2.3 0.0009 0.0017Inline explicit Euler 0.00004 (Failed)Mixed explicit/implicit Euler 0.0004 3.5 0.0004 0.0008Mixed explicit/implicit Euler 0.0008 (Failed)Inline explicit RK 4 0.00002 8.6 0.0004 0.0009Inline explicit RK 4 0.00004 (Failed)

the mathematical prerequisites of coupling partitionswithin the synchronous language elements frameworkwith special regard to timing requirements inherentto real-time simulations. In the following, the im-plementation of a Modelica library for the partition-ing of physical models, denoted as MULTIRATE li-brary, was sketched out. Finally, elements of that li-brary were used to partition a detailed robot modeland the simulation performance of that partitionedmodel was compared to “conventional” inline inte-grators provided by the Dymola tool. This numeri-cal experiment illustrated: a) that the partitioning isfeasible also for comprehensive, “real-world” models,and b) that by using a coupling of clocked discretizedcontinuous-time partitions in combination with judi-ciously selected solver methods considerable simula-tion speedups can be achieved (the speedup factor wasabout 2.9 for the example model).

Despite this encouraging result, it also needs tobe noted that it can take substantial efforts to find agood partitioning and select a combination of solvermethods and corresponding integration step sizes thatoutperform a simulation using “conventional” solvers.Nevertheless, particularly for real-time simulations,investing that additional effort may be worthwhile ifreal-time constraints cannot be satisfied by using aconventional global solver approach.

Acknowledgements

Partial financial support of DLR by the German BMBF(within the ITEA2 project MODRIO) and of Das-sault Systèmes by the European Union (within theCleanSky project MODELSSA) for this developmentis highly appreciated.

References[1] Dennis S. Bernstein. The treatment of inputs in real-time

digital simulation. SIMULATION, 33(2):65–68, 1979.

[2] Martin Busch. Zur effizienten Kopplung von Simulationspro-grammen. PhD thesis, Universität Kassel, 2012.

[3] Francois Cellier and Ernesto Kofman. Continuous SystemSimulation. Springer Science + Business Media, Inc., 2006.

[4] Hilding. Elmqvist, Sven Erik Mattsson, and Hans Olsson.New Methods for Hardware-in-the-Loop-Simulation of StiffModels. In Martin Otter, Hilding Elmqvist, and Peter Fritz-son, editors, 2nd Int. Modelica Conference, Oberpfaffen-hofen, Germany, March 18–19 2002.

[5] Hilding Elmqvist, Martin Otter, and Françoise E. Cellier.Inline Integration: A New Mixed Symbolic/Numeric Ap-proach for Solving Differential-Algebraic Equation Sys-tems. In European Simulation Multiconference, 1995.

[6] R. Kübler and W. Schiehlen. Modular simulation in multi-body system dynamics. Multibody System Dynamics, 4(2-3):107–127, 2000.

[7] Jim Ledin. Simulation Engineering. CMP Books, Lawrence,Kansas 66046, first edition, 2001.

[8] Modelica Association. Modelica—A Unified Object-Oriented Language for Systems Modeling v3.3.Standard Specification, May 2012. available athttp://www.modelica.org/.

[9] Stefan Nowack and Georg Feil. Reduction of time delays inRunge-Kutta integration methods. SIMULATION, 48(1):24–27, 1987.

[10] Martin Otter, Bernhard Thiele, and Hilding Elmqvist. ALibrary for Synchronous Control Systems in Modelica. InMartin Otter and Dirk Zimmer, editors, 9th Int. ModelicaConference, Munich, Germany, September 2012.

[11] Anton Schiela and Hans Olsson. Mixed-mode Integrationfor Real-time Simulation. In Modelica Workshop 2000 Pro-ceedings, pages 69–75, Lund, Sweden, 2000.

[12] Tom Schierz and Martin Arnold. Stabilized overlappingmodular time integration of coupled differential-algebraicequations. Applied Numerical Mathematics, 62(10):1491 –1502, 2012.


DOI10.3384/ECP14096381


393

modular multi-rate and multi-method real-time simulation - liu

Documents