UC Riverside
2016 Publications
Title
Automotive Cyber-Physical Systems: A Tutorial Introduction
Permalink
https://escholarship.org/uc/item/3v94g6jg
Journal
IEEE Design & Test, 33(4)
ISSN
2168-2356 2168-2364
Authors
Chakraborty, Samarjit
Al Faruque, Mohammad Abdullah
Chang, Wanli
et al.
Publication Date
2016-08-01
DOI
10.1109/MDAT.2016.2573598
Peer reviewed
eScholarship.org Powered by the California Digital Library
University of California
Automotive Cyber–Physical
Systems: A Tutorial
Introduction
Samarjit Chakraborty
Technical University of Munich
Mohammad Abdullah Al Faruque
University of California, Irvine
Wanli Chang
TUM CREATE
Dip Goswami
Eindhoven University of Technology
Marilyn Wolf
Georgia Institute of Technology
Qi Zhu
University of California, Riverside
h
TODAY, MOST OF the innovation in the automo -
tive domain i s in electronics and software. All new
features in modern cars—like advanced driver as-
sistance systems—are based on electronics and
software rather than on mechanical engineering
innovati ons. A modern high-end car has over
100 million lines of code [1] and it is widely
believed that thi s number will continue to grow in
the near future. Such code implements different
control applications spanning across various
functionalities—from safety-critical functions, to
driver-assistance and comfort-related ones. These
applications run on a distributed electronics and
electrical (E/E) architecture, consisting of often
hundreds of programmable electronic
control units (ECUs) that communicate
via different types of communication
buses like CAN [2], FlexRay [3], LIN
[4], and more recently also automotive
Ethernet [5].
Current hardware/software develop-
ment workflows for the automotive do-
main are highly compartmentalized.
Here, control algorithms are designed by develop-
ment teams who often have no influence or even
little or no view into the E/E architecture on which
the software implementing these controllers will
eventually run. As a result, the design of the con-
trol algorithms is based on a number of idealistic
assumptions like the control inputs can be com-
puted instantaneously, there is no delay between
sensing and the use of the sensor data to compute
the control input, or between the time the control
input is computed and when it is available for ac-
tuation. Further, the availability of finite precision
arithmetic and the side effects introduced when
compiling controll er models into code are also not
systematically addressed. While these issues are
anyway difficult to address because of the lack of
well-established techniques for ha ndling them in
the control theory literature, their effects become
very pronounced in the automotive domain be-
cause of the highly d istributed and h eterogeneous
nature of automotive E/E architectures.
Editor’s notes:
This tutorial gives an introduction to novices in CPS and particularly high-
lights the basics of control theory with respect to automotive applications.
The authors furthermore describe the “semantic gap” between control
models and their implementation and conclude t hat a n ew CPS-oriented
design approach is required.
—Jörg Henkel, Karlsruhe Institute of Technology
Color versions of one or more of the figures in this paper are available on-
line at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/MDAT.2016.2573598
Date of publication: 26 May 2016; date of current version:
17 June 2016.
2168-2356/16 B 2016 IEEE IEEE Design & TestCopublished by the IEEE CEDA, IEEE CASS, IEEE SSCS, and TTTC
92
Tutorials
In other words, because many of the assump-
tions made at the model level do not hold when
the designed controllers are implemented, t here is
a large performance gap between the controller
models and their implementations. In extreme
cases, even the stability of a controller—which was
verified at the model level—might not hold after
the code synthesized from the model is imple-
me nted. Thi s semantic gap between control
models and their implementation necessitates a
significant amount of ex post facto testing, debug-
ging and redesign, often using ad hoc techniques.
This not only makes cer tification difficult, but also
leads to resource over-dimensioning thereby in-
creasing costs.
In addition to the importance of cer tification or
guaranteeing correctness because of the safety-
critical nature of many automotive functionalities,
the automotive domain is also highly cost sensitive.
Hence, resource-efficient implementation of auto-
motive control software is an importan t issue. How-
ever, traditional techniques for controller design
have only focused on ensuring stability and satisfy-
ing control perfor mance metrics such as settling
time or peak overshoot. While efficient implemen-
tation of algorithms is one of the cornerstones of
computer scienc e, when it comes to control algo-
rithms, there are ver y few standard te chniques
for designing efficient implementations of these
algorithms.
CPS-oriented design
The essence of the cyber–physical system
(CPS) paradigm is the integrated design of control
algorithms and the computational platforms on
which these algorithms would run. While the dis-
tributed and heterogeneous nature of automotive
E/E architectures makes them a perfect candidate
for CPS-oriented design, it is only recently that
some progress has been made in this direction
[6], [7].
Techniques ac counting for platform architec-
ture characteristic s at the control design stage, as
well as resource-efficient design of control algo-
rithms are star ting to appear in the scientific litera-
ture [8]–[10]. There is now also an improved
awareness of how design decisions for d ifferent
subsystems and components in an automotive
hardware/software architecture influence each
other. This understanding has led to a number of
codesign proposals. For example, t raditionally
HVAC (heating, ventilation, and air conditioning)
systems in cars have only focused on pass enger
comfort and energy usa ge. However, for electri c
veh icles (EVs) the HVAC control can have a major
influence on battery lifetime and capacity fading.
Given the current costs of batteries and the issues
withdrivingrangesofEVs,accountingforbattery
characteristics when designing automotive HVAC
systems has been gaining traction recently. S imi-
larly, as ECUs are becoming more powerful, they
are increasingly being exposed to the side effect s
of semiconductor technology scaling like
manufacturing variability, s oft e rror s, and aging.
This is e special ly critical in the automotive domain
because such ECUs, unlike processors in con-
sumer electronics, are exposed to extreme temper-
atures and electromagnetic interferences. By
appropriately designing control algorithms (whe re
the software implementing these algorithms would
run on the ECUs) some of these reliability and ag-
ing effects can be mitigated.
Finally, security for the automotive domain
[11], [12] is a cha llenging proble m b ecause of the
resource-constrained and cost-sensitive nature of
automotive E/E architectures. H ere, investigating
the impact of differe nt light-weight security mecha-
nisms on higher layer control algorithms and appli-
cationsseemstobemeaningful.Towardthis,
me chan isms for evaluating the tradeoffs between
security and control performance are now star ting
to emerge.
Organization
This tutorial gives an overview of some of these
problems, recent advancements in addressing
them, an d the challenges in moving forward. It is
intended for beginning researchers and practi-
ti oners to enable further exploration and is not an
exhaustive survey of this topic. For example, impor-
tant issues in advanced driver assistance systems
and autonomous driving—such as the interac tion
between video pr ocessing , AI, and control theory
have not been discussed. The focus has instead
been on highlighting the interplay between em-
bedded systems and software design and control
theor y for the automotive domain.
While we have attempted to give the reader
some insights into the mathematical details of the
topics d iscussed here, wherever poss ible, we have
July/August 2016
93
tried to keep the mathematics to a minimal and fo-
cused on the main intuitions.
The first section of this article describes basic
control theory, which is required to appreciate
what follows next. The next sectio n, entitled
Resource-awar e automotive control software de-
sign, discusses how control/architecture code sign
techniques may be used to s yst ematica lly imple-
ment control algorithms on automotive E/E archi-
tectures, taking into account diffe rent res ource
constrains. The following section continues this
discussion but focuses on platform reliability
issues and b attery usage in the cas e of electric ve-
hicles. The section Automotive climate co ntrol
continues with electric vehicles and outlines the
benefits of coordinating the HVAC system in
an electric car with its motor control, before
discussing automotive CPS from the perspective
of security.
Feedback control systems
In this section, we briefly describe the basics of
feedback control applications that w ill be consid-
ered in the later sections. A control application
regulates the behavior of a dynamic system [13].
Most of them are modeled by a set of linear differ-
ential equations
_
xðtÞ¼AxðtÞþBuðtÞ
yðtÞ¼CxðtÞ (1)
where xðtÞ2R
n
is the system state, yðtÞ is the sys-
tem output, and uðtÞ is the control input applied
to the system. When implemented on embedded
platforms, the system states are periodically mea-
sured by the sensors at discrete-time instances
t
k
¼ kh; k ¼ 0; 1; 2; 3; ....Theintervalðt
kþ1
t
k
Þ is
the sampling period h. The sampled system states
are x½k¼xðt
k
Þ.Similarly,thesampledsystemout-
put is y½k¼yðt
k
Þ. The control input is updated
only at the discrete-time instances t
k
and is held
constant over the sampling interval h using a zero-
order hold (ZOH) circuit. Thus
uðtÞ¼u½k; t
k
t G t
kþ1
: (2)
The above ZOH impleme ntation can be modeled
by solving (1), resulting in
x½ k þ 1¼A
d
x½kþB
d
u½k
y½k¼Cx ½k (3)
where
A
d
¼ e
Ah
; B
d
¼
Z
h
0
ðe
A
dÞB: (4)
Clearly, A
d
and B
d
depend on the sampling
period h.
Quality of control (QoC). Quality/performance of
a control application i s often quantified with
respect to user requirements, for example, speed
of response and comfor t. Settling time is a widely
used metric to quantify QoC. The time it takes
for the system output y½k to reach and stay in
aclosedregionaroundthereferencevaluey
ref
(e.g., 0:98y
ref
to 1:02y
ref
) is the settling ti me and
is denoted as t
s
. Shorter settling time implies
better QoC. In many safety-cri tical automotive
control loops, there is a maximum settling time re-
quirement t
0
s
that must be satisfied for functional
correctness.
Controller. A controller aims to design u½k such
that the QoC requirements are met. The general
structure of a linear state-feedback controller is as
follows:
u½k¼Kx½kþFr (5)
where K is the feedback gain and F is the feedfor-
ward gain. A control algorithm computes the gains
K and F .
Controller design. The discrete-time dynamics in
(3) with c ontrol input (5) is called the closed-loop
system dynamics
x½ k þ 1¼ðA
d
þ B
d
KÞx½kþB
d
Fr: (6)
Stabilityofaplantandcontrolsystemdependson
the eigenvalues of ðA
d
þ B
d
KÞ, which are refe rred
to as the system poles and are denoted by p
i
for
1 i n. A stable system requires all poles
jp
i
j G 1. U sually, poles closer to zero provide a
faster response and require a higher value of the
input signal u½k.OncethefeedbackgainK is
designed, the static feedforward gai n F is obta ined
to achieve y½k!y
ref
, and is given by
F ¼ 1=ðC
d
ðI A
d
B
d
KÞ
1
B
d
Þ (7)
where I is an n-dimensional identity matrix. Clearly,
the QoC of a control loop depends on the poles p
i
IEEE Design & Test
94
Tutorials
of ðA
d
þ B
d
KÞ. The poles can be placed at desired
lo cations p
i
for QoC optimization by pole-
placement methodologies (by desi gning the feed-
back gain K [14]). The controller design question
boils down to the choice of desired poles p
i
such
that QoC requirements are met and/or optimized.
Physical constraints. In almost every real-world
system, due to the physical constraints of the
actuator, there is some maximum available contr ol
input and the controller needs to be designed
such that the maximum value of ju½kj does not
exceed this limit U
max
.
Resource-aware automotive control
software design
As described earlier, automotive E/E platforms
are highly r esource constrained as well as cost sen-
sitive. In this section, throug h examples, we outline
how computation-, memor y-, and communication-
aware control applications may be designed. Note
that these are the three primary resource types that
are targeted when designing efficient algorithms,
but in the particul ar case of cont rol algorithms, the
techniques necessar y deviate significantly com-
pared t o conventional control algorithm design.
For the case of computation-aware de sign, some of
the mathematical details have been outl ined, espe-
cially to highlight the differences with conven-
tional controller design as descr ibed in the earl ier
section Feedback control systems. For the remain-
ing two cases (memory- and communication-aware
desig n), only the high-level design strategy has
been de scri bed.
Computation-aware control systems design
OSEK/VDX-compliant operating systems (OSs),
with preemptive fixed-priority scheduling, are widely
used in the automotive domain [15], [16]. With
such an OS once each application gets released, it is
allowed to access the processor periodically. There
are various predefined periods of release times, and
each application is assigned one. Different applica-
tions may have different periods. Every time an ap-
plication is released, its program gets the chance to
be executed, depending on its priority.
Here, a time table containing all the periodic re-
lease times within the alleged hyperperiod (i.e.,
the minimum common multiple of all p eri ods) of
the applications needs to be configured. An
example with a set of three periods 2, 5, and 10 ms
is illustrated in Table 1. The hyperperiod is equal
to10ms,andthetimetablerepeatsitselfevery10
ms by resetting the timer.
Generally for a feedback control application, a
shorter sa mpling period allows the control ler to re-
spond to its plant more frequently, and is thus po-
tentially able to achieve better QoC. The obvious
downside is a higher processor load, since the
control program is executed more frequently. Let
us assume that the se t of available periods re-
stricted by an OSEK/VDX OS is .Denotinge
i
to be
the worst case execution time (WCET) of a control
application C
i
, if conventional controller design
and a uniform sampling period of h is used, t he
processor load for C
i
is
L
i
¼
e
i
h
: (8)
The upper bound on the load of any processor is
1. Considering a single processor p
X
fijC
i
runs on pg
L
i
1: (9)
Clearly, increasing the sampling period of a control
application decreases its processor load, and thus
potentially enabl es more applications to be inte-
grated on the ECU, thereby resulting in a more
cost-effective system.
Since an OSEK/VDX OS only offers a limited set
of pr edefined sampling periods to the control ap-
plications at hand and often the optimal sampling
period for a given control application is not di-
rectly realizable, the conventional way is to us e the
largest sampling period offered by the OS that is
Table 1 An example OSEK/VDX OS time table of
applications release.
July/August 2016
95
