scispace - formally typeset

Proceedings ArticleDOI

A co-simulation approach for system-level analysis of embedded control systems

16 Jul 2012-pp 355-362

TL;DR: The work at hand introduces an automatic tool flow at the Electronic System Level that enables the optimization of a system implementation with quality of control being introduced as a principal design objective, while respecting constraints like maximum slip to ensure maneuverability of a car.

AbstractControl 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 overdesigned 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.

Summary (4 min read)

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.
  • 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.
  • 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.
  • Moreover, it enables to take design constraints like the stability of the control application or application-specific constraints like maximum braking distance into account.

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 cosimulation.
  • The ESL design approach as employed here starts with an executable specification, i. e., a behavioral model of the functionality of the system.
  • From this, a graph-based exploration model is derived.
  • 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.
  • In actor-oriented models, actors, which encapsulate the system functionalities, are potentially executed concurrently and communicate over dedicated abstract channels.
  • 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).
  • 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.

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 ga(R,Ea) and represents all available interconnected components, i. e., hardware resources.
  • The edges Ea model available communication links between resources.
  • The application is modeled by an application graph gt(T∪ C,Et) that represents the behavior of the system.

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 schedule φ can be either static (with predefined start times of the tasks) or dynamic (with assigned periods or deadlines to the tasks).

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.

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 latter uses timebased block diagrams to present functional units that exchange data via signals .
  • Hence, there exists a significant similarity 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.
  • 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.

B. Control Application Exploration Model

  • To take into account feedback control systems during DSE, the control applications are transformed to graphs gt(T ∪ C,Et).
  • Looking at a single control application, the control application graph ap has to represent the control application of its state space model according to Fig.
  • 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.

V. CONTROL QUALITY EVALUATION BY CO-SIMULATION

  • A co-simulation approach for control quality evaluation is presented.
  • First, the used performance estimation technique based on virtual prototyping of the system implementation is introduced.
  • By co-simulating a Matlab/Simulinkbased 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.
  • 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.
  • 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.
  • For a proper timing simulation, the computation delay is determined by the mapping.

B. Co-Simulation

  • Complex control applications often consist of multiple control loops that interact with each other to a large extend.
  • In fact, application-specific control 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.
  • 3) The SystemC simulator computes the control vector u(τi).
  • 5) The co-simulation interface invokes the Simulink simulation while at the same time, the SystemC simulator advances its simulation time to the beginning of the next sampling time τi+1 and is suspended by the co-simulation interface.
  • 7) After the delay di has passed, the co-simulation interface updates the control vector in the plant with the value of u(τi) by invoking the Matlab/Simulink simulation engine.

VI. CASE STUDY: BRAKE-BY-WIRE

  • As a case study, a Brake-by-Wire (BbW) system from the automotive domain shall serve as an example where applicationspecific control quality measures may serve as comprehensive design objectives and constraints.
  • The BbW system contains several networked ECUs that communicate over a field bus to control the braking process on the four wheels, see Fig. 7. A simplified vehicle model based on the Quarter Car Model [24] is used here as the plant.
  • The ABS controller monitors the deceleration of the four wheels.
  • Comparing VP 1, VP 2, and VP 3, reducing sampling interval results in decreased braking distance and, hence, improved control quality but consumes more bandwidth.
  • With the slip value in VP 5 being always in the optimal range between 0.04 and 0.2, the ABS functionality is perfectly guaranteed according to the specification.

VII. CONCLUSION

  • This must be considered by design automation approaches to achieve safe system implementations of high quality.
  • This work presents a tool flow at the Electronic System Level (ESL) that enables the modeling, analysis, and optimization of a distributed controller systems with quality of control being considered as principal design objectives and constraints.
  • This co-simulation not only allows to determine metrics from the control theory domain like quadratic cost or stability but also application-specific control quality metrics like the maximum braking distance.
  • A presented model transformation combines the traditional development process of control applications with state-of-the-art ESL techniques, ensuring model consistency while enabling a high degree of automation.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

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
=
[
pP
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(τ
i1
), τ
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.

Figures (12)
Citations
More filters


20 Apr 2016
Abstract: ..................................................................................................... 90 KOKKUVÕTE .................................................................................................. 92 ACKNOWLEDGEMENTS ............................................................................... 94 Appendix A ........................................................................................................ 95 Appendix B ...................................................................................................... 103 Appendix C ...................................................................................................... 109 Appendix D ...................................................................................................... 117 Appendix E ...................................................................................................... 125 Appendix F ...................................................................................................... 133

55 citations


Proceedings ArticleDOI
11 Apr 2016
TL;DR: A co-optimization approach for FlexRay-based distributed control systems, that synthesizes both the controllers and the task and communication schedules and generates a Pareto front representing the trade-offs between these two, which allows the engineers to make suitable design choices.
Abstract: Recently, research on control and architecture co- design has been drawing increasingly more attention. This is because these techniques integrate the design of the controllers and the architecture and explore the characteristics on both sides to achieve more efficient design of embedded control systems. However, there still exist several challenges like the large design space and inadequate trade-off opportunities for different objectives like control performance and resource utilization. In this paper, we propose a co-optimization approach for FlexRay-based distributed control systems, that synthesizes both the controllers and the task and communication schedules. This approach exploits some FlexRay protocol specific characteristics to reduce the complexity of the whole optimization problem. This is done by employing a customized control design and a nested two-layered optimization technique. Therefore, compared to existing methods, the proposed approach is more scalable. It also allows multi-objective optimization taking into account both the overall control performance and the bus resource utilization. This approach generates a Pareto front representing the trade-offs between these two, which allows the engineers to make suitable design choices.

32 citations


Journal ArticleDOI
TL;DR: This paper shows by example how probabilistic bit flips are systematically abstracted and propagated towards higher abstraction levels up to the application software layer, and how RAP can be used to parameterize architecture-level resilience methods.
Abstract: The Resilience Articulation Point (RAP) model aims at provisioning researchers and developers with a probabilistic fault abstraction and error propagation framework covering all hardware/software layers of a System on Chip. RAP assumes that physically induced faults at the technology or CMOS device layer will eventually manifest themselves as a single or multiple bit flip(s). When probabilistic error functions for specific fault origins are known at the bit or signal level, knowledge about the unit of design and its environment allow the transformation of the bit-related error functions into characteristic higher layer representations, such as error functions for data words, Finite State Machine (FSM) state, macro-interfaces or software variables. Thus, design concerns at higher abstraction layers can be investigated without the necessity to further consider the full details of lower levels of design. This paper introduces the ideas of RAP based on examples of radiation induced soft errors in SRAM cells, voltage variations and sequential CMOS logic. It shows by example how probabilistic bit flips are systematically abstracted and propagated towards higher abstraction levels up to the application software layer, and how RAP can be used to parameterize architecture-level resilience methods.

27 citations


Book ChapterDOI
28 Oct 2013
TL;DR: This work introduces a model transformation framework that converts a Simulink model to an executable specification, written in an actor-oriented modeling language that serves as the input of well-established Electronic System Level (ESL) design flows that enables Design Space Exploration (DSE) and automatic code generation for both hardware and software.
Abstract: Matlab/Simulink is today's de-facto standard for model-based design in domains such as control engineering and signal processing. Particular strengths of Simulink are rapid design and algorithm exploration. Moreover, commercial tools are available to generate embedded C or HDL code directly from a Simulink model. On the other hand, Simulink models are purely functional models and, hence, designers cannot seamlessly consider the architecture that a Simulink model is later implemented on. In particular, it is not possible to explore the different architectural alternatives and investigate the arising interactions and side-effects directly within Simulink. To benefit from Matlab/Simulink's algorithm exploration capabilities and overcome the outlined drawbacks, this work introduces a model transformation framework that converts a Simulink model to an executable specification, written in an actor-oriented modeling language. This specification then serves as the input of well-established Electronic System Level (ESL) design flows that, e. g., enables Design Space Exploration (DSE) and automatic code generation for both hardware and software. We also present a validation technique that considers the functional correctness by comparing the original Simulink model with the generated specification in a co-simulation environment. The co-simulation can also be used to evaluate the performance of implementation candidates during DSE. As case study, we present and investigate a torque vectoring application from an electric automotive vehicle.

14 citations


References
More filters

Proceedings ArticleDOI
05 May 2008
TL;DR: It is concluded that it will not be sufficient to improve design processes, raise the level of abstraction, or verify designs that are built on today's abstractions to realize the full potential of cyber-Physical Systems.
Abstract: Cyber-Physical Systems (CPS) are integrations of computation and physical processes. Embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa. The economic and societal potential of such systems is vastly greater than what has been realized, and major investments are being made worldwide to develop the technology. There are considerable challenges, particularly because the physical components of such systems introduce safety and reliability requirements qualitatively different from those in general- purpose computing. Moreover, physical components are qualitatively different from object-oriented software components. Standard abstractions based on method calls and threads do not work. This paper examines the challenges in designing such systems, and in particular raises the question of whether today's computing and networking technologies provide an adequate foundation for CPS. It concludes that it will not be sufficient to improve design processes, raise the level of abstraction, or verify (formally or otherwise) designs that are built on today's abstractions. To realize the full potential of CPS, we will have to rebuild computing and networking abstractions. These abstractions will have to embrace physical dynamics and computation in a unified way.

3,020 citations


"A co-simulation approach for system..." refers background in this paper

  • ...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....

    [...]


Journal ArticleDOI
Tai C Yang1
10 Jul 2006
Abstract: A survey on networked control systems (NCSs), published in a previous paper, is updated and extended. A simple framework and some general formulations for the study of NCSs are proposed. In addition to the survey on NCSs, the impact of NCSs on traditional large-scale system control methodologies with a related application is also reviewed.

704 citations


"A co-simulation approach for system..." refers methods in this paper

  • ...Several existing works employ TrueTime to simulate and evaluate control systems, see [14], [15], [16], [17]....

    [...]


Proceedings ArticleDOI
21 Jun 1995
TL;DR: The paper formulates and discusses timing problems in real-time systems from the sampled data point of view and different ways to eliminate the effects of communication delays are considered.
Abstract: The paper formulates and discusses timing problems in real-time systems from the sampled data point of view. Different ways to eliminate the effects of communication delays are considered.

211 citations


"A co-simulation approach for system..." refers background in this paper

  • ..., the distribution of end-to-end delays may have a significant impact on control quality [1]....

    [...]


Proceedings ArticleDOI
12 Dec 2000
TL;DR: The paper presents the emerging field of integrated control and CPU-time scheduling, where more general scheduling models and methods that better suit the needs of control systems are developed.
Abstract: The paper presents the emerging field of integrated control and CPU-time scheduling, where more general scheduling models and methods that better suit the needs of control systems are developed. This creates possibilities for dynamic and flexible integrated control and scheduling frameworks, where the control design methodology takes the availability of computing resources into account during design and allows online trade-offs between control performance and computing resource utilization.

173 citations


"A co-simulation approach for system..." refers background in this paper

  • ...consideration is included in a controller synthesis with the discipline being often referred to as Control-Scheduling-CoDesign [2]....

    [...]

  • ...This consideration is included in a controller synthesis with the discipline being often referred to as Control-Scheduling-CoDesign [2]....

    [...]


Journal ArticleDOI
TL;DR: This paper develops and proposes a novel classification for ESL synthesis tools, and presents six different academic approaches in this context based on common principles and needs that are ultimately required for a true ESL synthesis solution.
Abstract: With ever-increasing system complexities, all major semiconductor roadmaps have identified the need for moving to higher levels of abstraction in order to increase productivity in electronic system design. Most recently, many approaches and tools that claim to realize and support a design process at the so-called electronic system level (ESL) have emerged. However, faced with the vast complexity challenges, in most cases at best, only partial solutions are available. In this paper, we develop and propose a novel classification for ESL synthesis tools, and we will present six different academic approaches in this context. Based on these observations, we can identify such common principles and needs as they are leading toward and are ultimately required for a true ESL synthesis solution, covering the whole design process from specification to implementation for complete systems across hardware and software boundaries.

162 citations


"A co-simulation approach for system..." refers background in this paper

  • ...Model of Architecture (MoA) see [19], such as processors, buses, memory units, etc....

    [...]

  • ...The vast majority of ESL design approaches, see [19] for a survey, is inspired by the Y-chart approach as schematically included in Fig....

    [...]


Frequently Asked Questions (1)
Q1. What have the authors contributed in "A co-simulation approach for system-level analysis of embedded control systems" ?

On the other hand, the system designer aims at achieving highquality implementations based on quality constraints specified by the control engineer. 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.