![Fig. 5. A schematic view of the proposed co-simulation which follows the generic continuous/discrete synchronization model introduced in [23]. The Matlab/Simulink simulator solves the plant model at each simulation step. For each sampling time τi, the Matlab/Simulink simulation delivers the system state x(τi) and forwards it to the virtual prototype simulated in SystemC. The virtual prototype updates the control vector u(τi) and determines the delay di which are forwarded back to the Matlab/Simulink simulation.](/figures/fig-5-a-schematic-view-of-the-proposed-co-simulation-which-22kzzh0q.webp)
![Fig. 6. A simplified vehicle model based on the Quarter Car Model [24] is used here as the plant. This model assumes the vehicle has four identical wheels and the surface conditions of road stay static. The co-simulation begins with 50m/s as the initial velocity of the vehicle, followed by a full brake. The vehicle runs on wet road surface.](/figures/fig-6-a-simplified-vehicle-model-based-on-the-quarter-car-e0u96b8t.webp)
![Fig. 9. Evaluation of the wheel rotational speed over time [s] using cosimulation to highlight the ABS functionality.](/figures/fig-9-evaluation-of-the-wheel-rotational-speed-over-time-s-3qyr9ukt.webp)
![Fig. 11. Evaluation of the application-specific constraint slip over time [s] using co-simulation.](/figures/fig-11-evaluation-of-the-application-specific-constraint-134spzie.webp)
![Fig. 10. Evaluation of the application-specific control quality metric braking distance over time [s] using co-simulation.](/figures/fig-10-evaluation-of-the-application-specific-control-fz4trlid.webp)
A Co-simulation Approach for System-Level
Analysis of Embedded Control Systems
(Invited Paper)
Michael Glaß, J
¨
urgen Teich, and Liyuan Zhang
Hardware/Software Co-Design, University of Erlangen-Nuremberg
Email: {glass, teich, liyuan.zhang}@cs.fau.de
Abstract—Control applications have become an integral part
of modern networked embedded systems. However, there often
exists a gap between control engineering and system design. The
control engineer has detailed knowledge about the algorithms but
is abstracting from the system architecture and implementation.
On the other hand, the system designer aims at achieving high-
quality implementations based on quality constraints specified
by the control engineer. This may result in either an overde-
signed system in case the specifications are pessimistic or an
unsafe system behavior when specifications are too optimistic.
Thus, future design automation approaches have to consider the
quality of control applications both as design objectives and
design constraints to achieve safe yet highly optimized system
implementations. The work at hand introduces an automatic
tool flow at the Electronic System Level (ESL) that enables
the optimization of a system implementation with quality of
control being introduced as a principal design objective, like
the maximum braking distance, while respecting constraints
like maximum slip to ensure maneuverability of a car. The
gap between mathematically well-defined models for system
synthesis and common analysis techniques for control quality
is bridged by co-simulation: A SystemC-based virtual prototype
of a distributed controller implementation is combined with high-
level models of the plants specified in Matlab/Simulink. Through
a model transformation, the traditional development process
of control applications is combined with state-of-the-art ESL
techniques, ensuring model consistency while enabling a high
degree of automation.
I. INTRODUCTION
In modern means of transport like the automotive and
avionics domain, many important control applications are
implemented on heterogeneous distributed embedded systems
that may consist of up to hundreds of Electronic Control Units
(ECUs) as well as various sensors, actuators, and field bus
systems. One important class of such applications are driver
assistance systems in modern cars that, e. g., automatically
keep a driver-specified speed of the car termed cruise control.
In recent years, such applications have become more and more
complex such that modern adaptive cruise control systems not
only adapt the speed according to the driver’s setting, but also
to the distance of cars running ahead and may even consider
the surrounding of the car to predict whether the driver may
overtake so to avoid needless braking. Another class are X-
by-Wire applications that substitute mechanical and hydraulic
systems for steering or braking. Here, the quality of the control
applications is one of the key factors that determine their
applicability with respect to (safety) constraints and the quality
perceived by the consumer.
The design of such distributed embedded systems has be-
come an extremely challenging task. Recently, Design Space
Exploration (DSE) approaches at the Electronic System Level
(ESL) have been developed, trying to assist the system de-
signer in this task. The approaches aim at automatically
investigating the tremendous design space and search for
system implementations that are optimized with respect to
several design objectives while meeting design constraints.
Typical design objectives are, e. g., monetary costs, power
consumption, or dependability. Design constraints are much
more specific to applications and the system and may be,
e. g., mounting space limitations, wiring capabilities, safety
requirements, or the stability of certain control applications.
From a system designer’s point of view, these objectives
and constraints are typically predefined. Given these, DSE
approaches assist the designer with an optimization loop
that performs system synthesis and evaluation: During system
synthesis, a candidate implementation of the system is derived
by selecting architecture components, binding of tasks onto
the components, routing of messages, and scheduling tasks
and messages. The evaluation is responsible for analyzing each
candidate implementation to quantify its design objectives and
check whether all constraints are satisfied.
However, the quality of a control application may not be
seamlessly translated into constraints like a maximum/average
end-to-end latency or jitter. In fact, it is well known that, e. g.,
the distribution of end-to-end delays may have a significant
impact on control quality [1]. In current practice, this existing
gap may be bridged by control engineers specifying rather
pessimistic design constraints. In such cases, the system im-
plementation delivered by the system engineer may be in fact
overdesigned which, of course, deteriorates design objectives.
Avoiding such an overdesign, the control engineer may specify
more optimistic design constraints that work fine for the
average case. However, the system may not be able to deliver
its correct service under all conditions, possibly resulting in
low service quality of the application or even unsafe behavior.
To close this gap, the quality of a controller has to be
considered directly during system design to avoid an inac-
curate approximation based on design constraints only. This
consideration is included in a controller synthesis with the
discipline being often referred to as Control-Scheduling-Co-
Design [2]. Existing approaches typically implement the con-
troller itself as a set of periodic tasks that communicate via
periodic messages, being mapped mostly to dedicated com-
ponents. However, in modern distributed embedded systems,
there is no dedicated subsystem per control application, but
the tasks of different applications have to share computation
as well as communication resources, causing varying end-to-
end latencies or even message loss. To achieve good control
performance, these effects that are a result of the mapping of
control applications to a distributed system with shared media
have to be taken into account. While several known approaches
take these effects into account, they typically assume a fixed
architecture platform and task mapping while taking into
account the effects of different scheduling strategies [3], [4]
only. When increasing the degree of freedom for the system
designer by enabling variation in architecture, task mapping,
routing, and scheduling, there exists a gap between the model
of the controller’s implementation and the required data for
the control performance analysis, i. e., a model of the plant.
The work at hand presents a possibility to close this gap
through co-simulation of an advanced system model including
the controller and an advanced plant model. As pointed out
in [5], classic system modeling languages like C are agnostic
of the system behavior and may only cover functional behavior
of a controller. As a remedy, the system model employed
here comprises of an actor-oriented behavioral model that,
combined with the current architecture, task mapping, message
routing, and scheduling forms a virtual prototype of the imple-
mentation. The plant itself is modeled by the control engineer
using a methodology that is well-established in his/her field
like Matlab/Simulink [6]. Through co-simulation, a complete
ESL design methodology is achieved that is capable of concur-
rently optimizing control quality as a principal design objective
together with classic design objectives. Moreover, it enables
to take design constraints like the stability of the control
application or application-specific constraints like maximum
braking distance into account. To further increase the degree of
automation, it is outlined how to (semi-)automatically translate
Matlab/Simulink models of sensors, actuators, and controllers
into an actor-oriented System Description Language (SDL), in
particular, SysteMoC [7]. This class of description languages
is typically employed at the ESL since it provides executable,
synthesizable, and often even verifiable system models. Par-
ticularly the aspect of translating a complete Matlab/Simulink
controller model to SysteMoC, setting up a virtual prototype,
and performing a co-simulation to determine control quality is
presented using Brake-by-Wire with anti-lock braking system
as a control application.
The rest of the paper is structured as follows: Section II
introduces related work from the area of control-scheduling-
co-design. Section III introduces ESL design fundamentals.
The modeling of control applications in an ESL design flow
is presented in Sec. IV. The proposed co-simulation approach
to evaluate control quality is outlined in Sec. V. A Brake-by-
Wire case study from the automotive domain is investigated
in Sec. VI before the paper is concluded in Sec. VII.
II. RELATED WORK
In recent years, several design tools have been developed
to help the designers to analyze and evaluate the control
performance under timing influence. These tools may be
coarsely divide into two groups, see [8] for a survey: Tools that
focus on the statistical analysis of how timing affects control
quality and tool flows that rely on system simulation.
Jitterbug is a widely used MATLAB-based toolbox that
allows the computation of a quadratic performance criterion
for a linear control system under various timing conditions [9].
The tool helps the designer to quickly evaluate how sensitive
a control system is with respect to delay, jitter, lost samples,
etc. Jitterbug is used in several works: In [10], the authors
use Jitterbug to determine the cost function when considering
the problem of optimal static period assignment for multiple
independent control tasks executing on the same processor.
In [11], the authors propose a control-scheduling co-design
method that integrates controller design with both static and
priority-based scheduling of the tasks and messages. The de-
sign objective is to optimize the overall control quality. In [3],
[12], the authors present a methodology to consider delay
distributions and not just worst case delays while optimizing
the control performance. Limitations of Jitterbug include: (a)
seamless applicability for linear systems only; (b) performance
analysis is restricted to a single design objective, i. e., the
quadratic cost; and (c) the delay distributions in each control
application are assumed to be given and independent of each
other. Particularly, the delay distributions cannot be derived
from a behavioral model only since they are agnostic of
system behavior, e. g., timing variation caused by contention
on computation and communication resources shared between
several control tasks.
TrueTime is a MATLAB/Simulink-based simulator for real-
time control systems. It enables the co-simulation of controller
task execution in real-time kernels, network transmissions,
and continuous plant dynamics [13]. TrueTime uses kernel
and network blocks to carry out the control tasks, which are
characterized by a number of attributes like deadlines, release
times, and priorities. Several existing works employ TrueTime
to simulate and evaluate control systems, see [14], [15], [16],
[17].
This work aims at overcoming the decoupling of delay
distributions, considering multiple control quality objectives,
and supporting ESL design for embedded control systems. The
methodology proposed in the following applies co-simulation
of a virtual prototype of the control application mapped to the
system architecture and the high-level model of the physical
environment. It is worth mentioning that recent works, see
for example [18], aim at avoiding intensive control quality
analysis by simulation or third-party tools and rely on formal
models that efficiently approximate the control quality instead.
This has the potential to significantly speed-up DSE.
III. ESL DESIGN FUNDAMENTALS
This work introduces the aspect of control quality into
system design by developing adequate models for controllers
and an evaluation of controllers and plants based on co-
simulation. Thus, the methodology is capable of introducing
classic control quality metrics and application-specific metrics
as both principal design objectives and design constraints and
into Electronic System Level (ESL) design. In this section, the
required fundamentals in ESL design of embedded systems
are outlined.
The vast majority of ESL design approaches, see [19] for
a survey, is inspired by the Y-chart approach as schematically
included in Fig. 1. The ESL design approach as employed here
starts with an executable specification, i. e., a behavioral model
of the functionality of the system. The models for available
system components, cf. Model of Architecture (MoA) see [19],
such as processors, buses, memory units, etc. are stored within
a component library. From this, a graph-based exploration
model is derived. The exploration model consists of an appli-
cation that models the functionality and an architecture that
models the available resources. During the phase of Design
Space Exploration (DSE), a set of high-quality system-level
implementations is delivered to the designer who chooses one
(or several) to be refined in the next lower level of abstraction.
The set of high-quality implementations results from the
presence of multiple, often conflicting objectives that makes
DSE a Multi-Objective Optimization Problem. During DSE,
implementations are obtained by mapping the application onto
the architecture in a process termed system synthesis. The
quality of each implementation with respect to given objectives
and its compliance with given design constraints is determined
in an evaluation step.
A. Executable Specification
In [7], a library for modeling and simulating actor-oriented
behavioral models termed SysteMoC is presented. SysteMoC is
executable
specification
component
library
application
architecture
system
synthesis
evaluation
system-level implementation
design space exploration
exploration model
Fig. 1. During system design at ESL, a behavioral model termed executable
specification and a component library are transformed to an exploration
model. This model is employed during Design Space Exploration (DSE) to
synthesize implementation candidates and evaluate them to quantify design
objectives and investigate design constraints. DSE delivers a set of high-
quality implementation candidates from which the designer choses the best
trade-off as the system-level implementation for subsequent design phases.
based on SystemC, a de facto standard for system-level mod-
eling, adding actor-oriented Models of Computation (MoC)
to develop an analyzable executable specification language.
In actor-oriented models, actors, which encapsulate the sys-
tem functionalities, are potentially executed concurrently and
communicate over dedicated abstract channels. Thereby, ac-
tors produce and consume data (so-called tokens), which are
transmitted by those channels. Actor-oriented models may be
represented as bipartite graphs, consisting of channels and
actors. An actor is a tuple a = (I, O, F, R) containing actor
ports partitioned into a set of actor input ports I and a set
of actor output ports O, the set of functions F and the Finite
State Machine (FSM) R. The functions encapsulated in an
actor are partitioned into actions and guards and are activated
during transition of a the finite state machine (FSM) R that
also represents the communication behavior of the actor (i. e.,
the number of tokens consumed and produced in each actor
activation). An action produces outputs, which are used by
the firing FSM to generate tokens for the FIFO channels
connected to the actor output ports. A guard (e. g. check in
Fig. 2) returns a Boolean value and the assignment of one or
several guards to the FSM implements the required control
flow. A channel is a tuple c = (I, O, n, d) containing channel
ports partitioned into a set of channel input ports I and a set of
channel output ports O, its buffer size n ∈ N
∞
= {1, . . . , ∞},
and also a possibly empty sequence d ∈ D
∗
of initial tokens,
where D
∗
denotes the set of all possible finite sequences of
tokens. The basic SysteMoC model uses FIFO channels to
present unidirectional point-to-point connection between an
actor output port and an actor input port. Actors are only
permitted to communicate with each other via channels, to
which the actors are connected by ports. In a SysteMoC actor,
the communication behavior is separated from its functionality,
which is a collection of functions that can access data on
channels via ports. A graphical representation of a simple
Fig. 2. Visual representation of an actor, which sorts input data according
to its algebraic sign. The actor consists of one input port i
1
and two output
ports o
1
and o
2
. Transitions are depicted as directed edges. Each transition
is annotated with an activation pattern, a boolean expression which decides
if the transition can be taken, and an action (e. g. fpositive, fnegative) can be
executed if the transition is taken.
SysteMoC actor is given in Fig. 2 which sorts input data
according to its algebraic sign.
B. Exploration Model
For the DSE, an exploration model termed specification
defines the available hardware components as well as the
processing tasks that need to be distributed in the system.
This graph-based specification (see Fig. 3(c)) consists of the
plattform architecture, the application, and a relation between
these two views, the mapping constraints:
• The architecture is modeled by a graph g
a
(R, E
a
) and
represents all available interconnected components, i. e.,
hardware resources. The vertices r ∈ R represent the
resources, e. g., ECUs, buses, sensors or actuators. The
edges E
a
model available communication links between
resources.
• The application is modeled by an application graph g
t
(T ∪
C, E
t
) that represents the behavior of the system. The
vertices t ∈ T denote processing tasks and the vertices
c ∈ C communication tasks. The directed edges e ∈ E
t
⊆
(T × C) ∪ (C × T ) denote data dependencies between
tasks, respectively actors.
• The relation between architecture and application is given
by a set of mapping edges E
m
. Each mapping edge m ∈
E
m
is a directed edge from a task to a resource, with a
mapping m = (t, r) ∈ E
m
indicating that a specific task
t can be mapped to hardware resource r.
C. System Synthesis
From the specification of the system that implicitly includes
all design alternatives, a system level implementation has to
be deduced, respectively synthesized. This implementation
corresponds to the hardware/software system that will be
implemented. The synthesis thereby involves the following
steps:
• The allocation α ⊆ R denotes the subset of the available
resources that are actually used and implemented in the
embedded system.
• The binding β ⊆ E
m
is a subset of the mapping edges
in which each processing task is bound to a hardware
resource that executes this task at runtime.
• The routing γ ⊆ R of each communication task is a
subset of resources over which a communication task is
routed.
• The schedule φ can be either static (with predefined start
times of the tasks) or dynamic (with assigned periods or
deadlines to the tasks).
Thus, an implementation is given by a tuple (α, β, γ, φ).
IV. CONTROLLER MODELING FOR ESL DESIGN
Introducing a novel design objective (design constraint)
requires (a) an adequate modeling and consideration during
system synthesis and (b) providing an evaluation technique to
quantify the design objective (to check for compliance with the
design constraint). This section introduces the proposed system
modeling approach. The employed control quality analysis
technique based on co-simulation is presented in the next
section. The overall modeling flow is depicted in Fig. 3.
A. Controller and Executable Specification
Control systems with feedback possess multiple advantages
in comparison to open-loop systems. The structure of a quite
general feedback control system is as follows, see Fig. 3(a):
The current state of the system x is sampled by a sensor and
a controller computes the new control signal which is send to
an actuator. The actuator generates the control vector u which
affects the behavior of the physical system that is also called
plant.
For the modeling of complex controllers and plants, control
engineers typically employ rich tool boxes, Matlab/Simulink
being one of the most prominent ones. The latter uses time-
based block diagrams to present functional units that exchange
data via signals (lines). Hence, there exists a significant simi-
larity between Matlab/Simulink modeling and actor-oriented
models as employed in ESL design that is the base of
an automatic transformation pattern to derive an actor-based
executable specification from Matlab/Simulink code: For every
(non-hierarchical) block in Matlab/Simulink, a corresponding
SysteMoC actor is stored in an actor library. Thus, every
basic block that appears in a complex controller model can
directly be transformed one-to-one to a SysteMoC actor. Each
signal is (a) directly transformed to a SysteMoC channel with
either FIFO or register semantics if it has only one sender
and one receiver or (b) transformed to multiple channels with
broadcasting if it has one sender and multiple receivers. In case
the control engineer specified an S-function block, an empty
actor stub with correct channels is created and has to be filled
manually. Note that the detailed transformation procedure has
to take into account different data types etc. and may have to
be adapted to the respective SDL used.
B. Control Application Exploration Model
To take into account feedback control systems during DSE,
the control applications are transformed to graphs g
t
(T ∪
C, E
t
). In case of a multi feedback controller design problem,
a system specification consists of a set P of plants. The
application graph g
t
of such a system is defined as:
g
t
=
[
p∈P
a
p
(1)
Here, each plant p is controlled by a separate control appli-
cation, modeled as a control application graph a
p
. Looking
at a single control application, the control application graph
a
p
has to represent the control application of its state space
model according to Fig. 3. Each control application graph
a
p
describes the part of the feedback control system that is
subsequently implemented: the sensor sampling the state x
p
of plant p and preprocessing this data; the controller computing
the control vector; and the actuator generating the control
signal u
p
. This leads to the following definition of a control
application graph a
p
of a feedback controller design problem
for a plant p:
• The set of sensor tasks S
p
models the sensors monitoring
plant p. Each element s ∈ S
p
is a vertex, denoting one
single sensor task.
• The set of controller tasks H
p
where each element h
p
∈
H
p
is a vertex, denoting a processing task computing a
part of the control vector.
• The set of actuator tasks U
p
where each element u
p
∈ U
p
is a vertex, denoting a processing task to generate one
control signal for plant p.
• The set of communication tasks C
p
where each element
c
p
∈ C
p
is a vertex, represents a data transfer.
• The directed edges e
p
∈ E
p
⊆ (S
p
× H
p
) ∪ (H
p
× H
p
) ∪
(H
p
× U
p
) model data dependencies between the tasks.
Thus, a control application graph a
p
is defined as a
p
((S
p
∪
H
p
∪ U
p
∪ C
p
), E
p
). Note that this definition allows multiple
sensor, controller, and actuator tasks that may be required to
control a single plant.
The proposed exploration model may, in case the behavioral
model can or shall not be derived as an intermediate step, be
directly derived from the state-space model of the controller.
If the executable specification is given as proposed here, the
transformation from the executable specification to the respec-
tive exploration model can be performed fully automatically,
following a transformation pattern presented in [20].
V. CONTROL QUALITY EVALUATION BY CO-SIMULATION
In this section, a co-simulation approach for control quality
evaluation is presented. First, the used performance estimation
technique based on virtual prototyping of the system imple-
mentation is introduced. By co-simulating a Matlab/Simulink-
based plant model and the virtual prototype of the system,
i. e., sensors, controllers, and actuators mapped to architecture
components, see [21], application-specific metrics such as the
braking distance can be used to reflect control quality.
A. Performance Simulation by Virtual Prototyping
A key aspect of the evaluation phase addressed in this work
is performance simulation. The goal is to evaluate the system
behavior, i. e., the behavior of tasks and their communication
when mapped to system components. The work at hand
employs a SystemC-based performance simulation to form a
Virtual Prototype VP of the system. In general, the VP consists
of an application enriched with architecture information.
To execute a performance simulation for a VP, the concept
of Virtual Processing Components (VPCs) [22] is used, a
custom library for performance simulation of SystemC models.
VPC has to be configured with the implementation deter-
mined by the system synthesis. A VPC model consists of
three components: (1) the resources in the system, (2) the
mapping of the tasks to the resources, and (3) the routing
that specifies the communication paths. Each node in the
architecture graph g
a
represents a resource modeled in the
VPC library. Resources include communication as well as
computation resources. To allow execution of multiple tasks
running on one VPC resource, a scheduling policy for each
VPC resource is determined from the implementation. Each
node from the application graph g
t
is mapped to one VPC
resource. This mapping is given by the implementation.
For a proper timing simulation, the computation delay is
determined by the mapping. This delay depends on attributes
(c) exploration model
(b) executable specification
(a) controller
plant
controller
actuator
sensor
x
u
s1
out
in(1)&out(1) / sense
...
out[0] = data;
sense
s1
in
out
in(1) / control
...
out[0] = data;
sense
s2
...
out[0] = data;
control
out(1)
s1
in
in(1)&out(1) / act
...
out[0] = data;
act
in
out
t
s
t
c
t
a
c
sc
c
ca
r
sen1
r
sen2
r
cpu1
r
cpu2
r
act
application
architecture
Fig. 3. Shown is (a) a typical controller in the state space model. Its proposed transformation into an executable specification, see (b), is depicted by dotted
edges. From the executable specification, the desired exploration model, see (c), can automatically be derived as well. The resulting application consists of
three tasks with a sensor task t
s
modeling the sensor, a control task t
c
modeling the controller including the input vector, and an actuator task t
a
modeling
the actuator. A platform architecture graph is depicted in the exploration model as well, consisting of two different sensors suitable to carry out the sensor
task, two CPUs suitable to execute the control task, and an actuator to implement the actuator task. The possible mapping of tasks to resources is depicted
by the dashed edges.
of the resources like the operations executed per second and of
the task like the number of instructions. The communication
between the tasks mapped to the resources has to be defined
also for VPC. For each communication task c ∈ C, a route is
specified by hops across VPC resources. For each hop, some
parameters can be defined such as a message priority.
The virtual prototyping approach based on VPCs extends
the standard SystemC simulator; for the sake of comprehensive
introduction of the co-simulation, the complete VPC-based
virtual prototyping approach is termed SystemC simulator in
the following.
B. Co-Simulation
Complex control applications often consist of multiple con-
trol loops that interact with each other to a large extend.
The kind of interaction may even be situation-dependent as
known from driver assistance systems that, e. g., may adapt to
changing environment. In these cases, the quality of a single
control loop can hardly capture the control quality of the
whole application or system. In fact, application-specific con-
trol quality metrics may become both comprehensive design
objectives such as the braking distance and valuable design
constraints such as the maximum slip of a wheel to ensure
maneuverability of a car. These metrics, however, vary from
application to application and their outcome may significantly
depend on the use case.
As outlined before, Matlab/Simulink offers a rich toolbox
to model complex and multiple plants but cannot consider
varying sensor to actuator delays. On the other hand, the
proposed performance estimation reflects the system behavior
of several complex controllers that interact with each other
but has serious drawbacks modeling complex plant behavior.
To derive the described application-specific control quality
metrics, a co-simulation approach is implemented in which the
control application including sensors and actuators is modeled
in SystemMoC while the plant is modeled in Matlab/Simulink.
The sensor actor in the VP reads the actual state x of the
plant periodically. The sampling times that are denoted as
τ
1
, . . . , τ
i
, . . . τ
n
with τ
s
= τ
i+1
− τ
i
, ∀i being the sampling
interval. After sampling the state x(τ
i
) at sampling time τ
i
,
the implementation of the controller computes the control
vector u(τ
i
). The delay from sensor from controller to actuator
caused by computation, scheduling, and resource contention is
defined as d
i
. This delay d
i
is determined during the discrete-
event-simulation of the VP. This means, after sampling the
sensor value at τ
i
, the control vector u(τ
i
) is updated at
τ
i
+ d
i
1
. Hence, the plant has to be updated with respect to
the delay. Therefore, the control vector at an arbitrary time τ
is given as follows:
u(τ) =
u(τ
i−1
), τ
i
≤ τ < τ
i
+ d
i
u(τ
i
), τ
i
+ d
i
≤ τ < τ
i+1
(2)
Given both simulations run in parallel, synchronization mech-
anisms are necessary. The complete synchronization during
the co-simulation process is controlled by a co-simulation
interface, implemented as a Matlab/Simulink S-function. Fig. 4
schematically depicts the proposed coupling. The main tasks
1
For FIFO-based channels in the actor-oriented model, the delay has to
be always smaller than the sampling interval, i. e., ∀i : d
i
< τ
s
. For
register-based channels, this assumption becomes obsolete. Just as in real-
world controller implementations, the actuator may then skip some control
vectors since these are updated and overwritten by a subsequent control vector.