Challenges in Automotive Cyber-physical Systems Design

Dip Goswami1 Reinhard Schneider1 Alejandro Masrur1Martin Lukasiewycz2 Samarjit Chakraborty1 Harald Voit3 Anuradha Annaswamy4

1Institute for Real-Time Computer Systems, TU Munich, Germany2TUM-CREATE Center for Electromobility, Singapore3Institute for Automatic Control, TU Munich, Germany

4Massachusetts Institute of Technology, USAE-mail: dip.goswami@tum.de, reinhard.schneider@rcs.ei.tum.de, masrur@rcs.ei.tum.de

martin.lukasiewycz@tum-create.edu.sg, samarjit@tum.devoit@lsr.ei.tum.de, aanna@mit.edu

AbstractSystems with tightly interacting computational (cyber)

units and physical systems are generally referred to ascyber-physical systems. They involve an interplay betweenembedded systems, control theory, real-time systems andsoftware engineering. A very good example of cyber-physical systems design arises in the context of automotivearchitectures and software. Modern high-end cars have 50-100 processors or electronic control units (ECUs) that com-municate over a network of buses such as CAN and FlexRay.In such complex settings, traditional control-theoretic ap-proaches – where control engineers are only concernedwith high-level plant and controller models – start break-ing down. This is because implementation-level realitiessuch as message delay, jitter, and task execution times arenot adequately considered when designing the controller.Hence, it is becoming necessary to adopt a more holistic,cyber-physical systems design approach where the seman-tic gap between high-level control models and their actualimplementations on multiprocessor automotive platforms isquantified and consciously closed. In this paper we giveseveral examples on how this may be done and the currentresearch challenges in this area that are being faced by theacademia and the industry.

1 IntroductionToday automotive in-vehicle networks consist of up to

100 ECUs, sensors, and actuators that run a large num-ber of control loops which are closed over a network ofshared resources (Fig. 1(a)). Typical examples include theengine control unit, the body control subsystem, the chas-sis control, and safety functions like adaptive cruise con-trol. In such setups, various functionalities are realized bya number of distributed tasks which communicate by ex-changing messages over the shared network. The perfor-

TaTs

Tc

FlexRay/CAN

m1 m2

ECU1 ECU2

ECU3

Sensor Actuator

Figure 1: Distributed automotive control application.

mance of these applications depends on the operating sys-tem (OS) running on the ECU, where common automotiveOSs can either be preemptive (e.g., OSEK, OSEKTime) ornon-preemptive (e.g., eCos) and the response time of mes-sages transmitted over networks which depends on the arbi-tration policy implemented. In general, the scheduling poli-cies also can either be time-triggered (e.g., the static seg-ment of FlexRay) or event-triggered (e.g., the dynamic seg-ment of FlexRay, or CAN). Inherent heterogeneity and di-verse nature of the modern automotive functionalities makesuch systems very complex. The necessity of tightly inter-acting cyber and physical components requires introductionof new design paradigm [14].

Typically, a feedback control function aims to achievethe desired behavior of a dynamic system by applying ap-propriate inputs to the system. As illustrated in Fig. 2, thetraditional automotive design flow of such applications hastwo distinct and decoupled phases: (i) control algorithmdesign and (ii) its implementation on a specific embeddedsystems platform. The design phase decides on the con-trol algorithm based on the dynamic model (in form of aset of differential or difference equations) obtained by the

1

978-1-4673-2297-3/12/$31.00 ©2012 IEEE 346

System identification

Controllerdesign

Control systemanalysis

systemmodel controller

Codegeneration

Taskpartitioning

Task mapping& scheduling

Messagescheduling

Timing & performanceanalysis

Are control objectives satisfied

g

NO

Equations

Software

Controller Design

Controller Implementation

Figure 2: Control Systems Implementation

system identification techniques. Hence, the outcome ofthis phase is the control algorithm which is designed andanalyzed in simulation setups, e.g., Simulink/Stateflow, tomeet all application-level specifications/requirements (e.g.,stability, settling time, or tracking error). The implementa-tion phase starts with platform-specific code generation forthe proposed control algorithm. Due to the distributed na-ture of the automotive architecture, the control code needsto be partitioned into a number of software tasks for sam-pling the sensor readings (Ts), computing the control inputs(Tc), and performing actuations (Ta) as shown in Fig. 1.These software tasks need to be mapped and scheduled ondifferent ECUs. Depending on the task mappings, controlsignals need to be exchanged via a shared, arbitrated net-work. Hence, data processed by the tasks, e.g., feedbacksignals, are packetized as messages which need to be sched-uled accordingly (Fig. 1(b)). Finally, it is verified whetherthe high-level control objectives are met and if not, a de-sign revision is deemed necessary which starts again withanother control design phase iteration.

1.1 CPS-oriented DesignIn the context of the above-mentioned complex dis-

tributed settings, the traditional design flow – where con-troller design and their implementations are performed in adecoupled fashion – results in (i) a semantic gap betweenthe control algorithms and their implementations and (ii) inmany occasions, an overly conservative design. In the fol-lowing, we illustrate the main shortcomings of traditionaldesign approaches and the motivations for more holisticcyber-physical systems design approach.

• Traditionally, the control theory community haslargely ignored the implementation aspects (both soft-ware and hardware architecture) of controllers and hasfocused on mathematical models, their analysis, andhigh-level simulation. In this process, a number ofsimplifying assumptions have been made when de-signing controllers. They include neglecting the com-putation times when evaluating control laws and ne-glecting the control message communication times. As

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.50

10

20

30

40

50

60

70

Seconds

Spee

d

33% Drop25% Drop0% Drop

Figure 3: Inherent robustness of a control loop.

the implementation platforms became more complexand the semantic gap between high-level control mod-els and their implementations widens, the control the-ory community started investigating what is referredto as networked control systems (NCS) [2, 13], wherethe focus has been on distributed controllers commu-nicating over a wireless network. Research with NCStakes into account issues such as delays suffered bycontrol messages, message loss and jitter, and factorsthese issues into controller design. In general, a ma-jority of the research on NCS assumes a given net-work and focuses on the controller design related as-pects. On the contrary, in the automotive setups underconsideration, the designer has sufficient handle overthe network parameters. Hence, the network designcan significantly be directed by the control related re-quirements and vice-versa – which is exactly the fo-cus of flurry of recent works on cyber-physical de-sign [1, 3–5, 7–9, 12, 15].

• In general, the control applications are different fromusual real-time applications in many aspects. E.g.,a real-time application is often characterized by itsdeadline whereas the control applications are mostlyjudged by their performance. Fig. 3 shows the effectof feedback (packet) drop or deadline miss in a DCmotor speed control application in electric cars wherethe goal is to achieve a speed reference of 50 units.The result shows the system behavior in the presenceof certain deadline miss. The system behavior doesnot deteriorate much with up to 25% of the feedbacksignals being dropped/miss their deadlines. Althoughthe deadline requirements in control are soft in nature,they cannot be categorized as soft real-time applica-tions (which are considered to be less critical) becauseof their stingent performance requirements. Clearly,the control applications are special in many ways. Ig-noring such special properties in the design phase, theembedded implementation of control algorithms oftenleads to conservativeness both in terms of resource uti-

2

347

lization and control performance. The cyber-phyiscaldesign paradigm [3,4,8,12] aims to improve the designby exploiting such specialities of control applications.

In this paper, we illustrate various aspects of the above-mentioned cyber-physical design approaches and associatedchallenges by using several design examples from the auto-motive domain. In Section 2, we describe a typical auto-motive problem setting and design challenges. The cyber-physical design approach is illustrated and demonstratedwith a design example in Section 3. In the following twosections (Section 4 and 5), we demonstrate two design ex-amples on how the special properties of control applicationscan be exploited by cyber-physical design approaches to im-prove the overall design.

2 Problem Setup and Design ChallengesDesign of cyber-physical automotive applications in-

volves challenges both from control theoretic and embed-ded systems sides. In this section, we first describe theoverview of various design objectives from control side.Next, we describe the challenges involved in the design pro-cess of embedded platforms. In the subsequent sections, weshow by a number of design examples how these challengesfrom both domains can be jointly addressed by holistic CPSdesign approaches.2.1 Control Design Challenges

In general, dynamic systems (or plants) are modeled bya set of differential equations,

x(t) = Acx(t) +Bcu(t)

y(t) = Ccx(t) (1)

where x(t) is state vector and u(t) is the control input tothe system. Ac is system matrix and Bc is input vector.In a state-feedback control algorithm, control input u(t) iscomputed utilizing the system states x(t) (feedback signal).The computed u(t) is then applied to the plant which is sup-posed to achieve the desired behavior. The overall loop per-forms three operations:

• Measure: The output of the dynamical system x(t) ismeasured by one or more measuring devices or sensorsand thus, the measured signals act as feedback signals.

• Compute: The feedback signals are compared with de-sired output and necessary correction in the input sig-nal u(t) is computed by the control algorithm.

• Actuate: The correction is incorporated by changingthe input signal or actuation.

Typically, a high level goal of such feedback control aimsto achieve desired behavior (i) fast, and (ii) accurately, whilestability of the loop must be maintained. There are va-riety of stability notions, e.g., x(t) and u(t) are bounded

Ts

Ta

Tc

FlexRay/CAN

ECU3

ECU2

ECU1

= sensor-to-actuator delay

m1 m2

Ta

Tc

Ts

h

Figure 4: Timing diagram of distributed CPS.

(BIBO stability) and y(t) ! r as t ! ", r is the reference(asymptotic stability). The speed and accuracy of the feed-back control system quantify the performance of the con-troller. There is a wide variety of notions to quantify theperformance of a control function. The performance no-tions are broadly classified into two categories: steady stateand transient phase performance. An example of a transientperformance index is the settling time, i.e., how fast the sys-tem responds to some external disturbances. On the otherhand, a commonly used performance index at steady stateis the quadratic cost function which captures a combinationof tracking accuracy and input energy,

J =

! !

0

[u(t)2 + y(t)T y(t)]dt, (2)

where u(t) and y(t) are the system’s input and output re-spectively.

Performing these operations continuously in any im-plementation platform requires infinite computation power.Hence, in a digital implementation platform of such feed-back loops, these operations are performed only at discrete-time intervals (sampling instants). When the time inter-val between two consecutive sampling instants is constant,the continuous-time system (1) can be transformed into adiscrete-time system of the form,

x[k + 1] = Ax[k] +Bu[k]

y[k] = Cx[k] (3)

where sampling instants are t = hk (k = {1, 2, 3 · · · }) andhk+1 # hk = h (sampling period). x[k] and u[k] are thevalues of x(t) and u(t) at t = hk. The performance dependson (i) the sampling period h, and (ii) the sensor-to-actuatordelay ! as illustrated in Fig. 4.

From control side, the design challenges rely on the factsthat (i) shorter period improves the control performance,and (ii) a shorter sampling period requires higher computa-tional and communication resource usage [1,8]. The overallgoal is to choose sampling periods and associated controlrelated parameters of the control tasks such that (i) the con-trol functionalities are robust and provide desired perfor-mance, and (ii) all the control and other tasks and messagesare schedulable, given the resource constraints.

3

348

app1 app2...

appn

$ determine

cyber-physical properties

system architecture

comp3comp2comp1...

compm

$ combinesystem

$ schedule

system scheduling

Figure 5: Illustration of a modular scheduling approach thatis aware of the cyber-physical system properties.

2.2 Platform Design ChallengesThe introduction of the FlexRay bus in the automotive

domain allows a fully synchronous scheduling of ECUs andbus systems. In contrast to the predominant CAN bus, asynchronous time-triggered scheduling reduces end-to-endlatencies significantly and at the same time avoids jitter if itis well configured. A configuration of a time-triggered sys-tem requires the concurrent determination of schedules forall ECUs and buses which is a non-trivial task. For cyber-physical systems in the automotive domain, the schedulinghas to be additionally aware of the underlying applicationsand its constraints. Here, an appropriate abstraction of theplant and its characteristics becomes necessary to support acontrol-aware scheduling as illustrated in Fig. 5. The prop-erties from a cyber-physcial system have to be extracted andrespected within a modular scheduling framework that de-termines a system model from the component models andfinally determines a feasible schedule for the entire system.

The scheduling of cyber-physical systems requires anappropriate application model. In the automotive domain,usually all applications are periodic or defined by a minimalinter-arrival time. The goal of the scheduling is to definethe start times for each task and assignments of messagesto slots. The constraints of the ECUs and buses have to befulfilled while the end-to-end latencies of all applicationshave to be respected. Depending on the underlying cyber-physical system, the latency of an application has also aninfluence on the control quality which should be considered.

The scheduling method has to take all the architecturalconstraints into account such as the bus systems and the op-erating systems. For the ECUs, standard operating systemsare either based on non-preemptive scheduling or the pre-emptive OSEKTime scheduling that is using a last-in-first-

architectureapplications

resource allocationprocess bindingmessage routing

Figure 6: Illustration of a y-chart approach for the architec-tural design space exploration where a set of applicationsis mapped to an architecture template. The design spaceexploration might result in a multitude of different applica-tions.

out (LIFO) scheduler with a dispatch table for each task.Development of scheduling methods for the entire

systems is a challenging task and are often based on IntegerLinear Program (ILP) solvers. In particular, achievinga high efficiency and modularity is an important designgoal of such scheduling frameworks. Although currentframeworks are able to handle more than 100 tasks, theirscalability remains a major concern. Different combina-tions of heuristics and mathematical solvers are used totackle this problem.

Design Space Exploration: With a growing flexibility, theoptimization of automotive networks is becoming a majorchallenge. Here, the following components have to be de-termined: The selection of hardware resources and theirconfiguration (CPU, RAM, etc), the selection of buses andthe wiring, the distribution of tasks and messages that al-low a feasible scheduling. Common design space explo-ration frameworks are based on the approach as illustratedin Figure 6. A set of applications is mapped to an architec-ture template. The design space exploration tasks are usu-ally separated in (i) allocation of resources, (ii) mapping oftasks, and (iii) routing of messages. In a final step a feasibleschedule has to be determined for each implementation.

State-of-the-art exploration frameworks are based onILPs or Evolutionary Algorithms or the combination ofboth. To enable the usage of design space explorationmethods for cyber-physical systems in the automotive do-main, the specific constraints from the control theory andthe physical systems have to be considered. The combina-tion of existing architectural design space exploration ap-

4

349

Stage 1: Controller design

Stage 2: Platform constraints

Stage 3: Synthesis

Implementation

platform configuration

design verification

Control goals

freshness constraints

platform properties

COTS tool chain

controller parameters

Figure 7: Constraint-driven design flow.

proaches and scheduling approaches for synchronous sys-tems is a challenging task that requires a holistic modelingof the entire system. Moreover, to improve the usabilityof design space exploration frameworks, the interaction be-tween the designer and the framework become necessary.This includes the adjustment of priorities of the design ob-jectives and the semi-manual determination of implementa-tions.

3 Constraint-driven Algorithm/ArchitectureCo-design

In this section, we illustrate the cyber-physical de-sign flow in the context of a distributed automotive set-ting described in Section 2. As discussed in the motiva-tional section, the traditional design flow often ignores theimplementation-level effects such as jitter and delays expe-rienced by the feedback signals while being transmitted andprocessed by a network of shared resources. In this designexample we demonstrate how a cyber-physical design ap-proach can address this semantic gap and essentially comeup with a better design by joint design of the controller andthe embedded platform.

The idea is to come up with a set of constraints thatcaptures platform-specific properties (e.g., the constraintscoming from the OS running at the ECUs and schedulingpolicies running on the bus) and at the same time, trans-lates controller-specific requirements into platform-specificconstraints. The (optimal) design solution can either be ob-tained by casting it as a constraint solve problem (CSP) oran ILP problem. The overall design flow can broadly bebroken into three stages (Fig. 7):

• Stage 1 (Controller design): The controller designessentially boils down to the problem of finding suit-able controller gains that meet the control goals (i.e.,stability and performance). For this, we (i) explorethe available sampling periods which satisfy the con-trol goals while checking their feasibility with respectto the underlying implementation platform, and (ii) re-strict the design space of the corresponding schedu-

x1(t)

1 2 3 4 5 6 7 8 9 0

Ts,1

Ta

x1[1] x1[2] x1[3] x1[4]

x1[5] x1[6] x1[7]

x1[8] x1[9]

x1[0]

data flow

x2[0]

x2[1] x2[2] x2[3] x2[4] x2[5] x2[6]

x2[7] x2[8] x2[9]

Tc

Ts,2

k

k

k

x2(t)

task activation

uncorrelated freshness violation > h !"

m3

m2

m1

u[4] u[5]

x2[2]

x1[2]

k

= h !"

x1[1]

u[2]

t

h

Figure 8: Correlation constraint.

ling parameters that may realize those sampling peri-ods. The control gains are synthesized based on thisrestricted design space.

• Stage 2 (Platform Constraints): Further, the ac-tual control performance depends on the the age orfreshness of the feedback signals which are used tocompute the control input. As a result, the freshnessconstraint imposed by the controller design is trans-lated into a set of platform constraints.(1) synchronicity constraint; specifies the phaserequirement between local task schedules and globalbus schedules. Unsynchronized schedules might leadto large delays.(2) schedulability constraint; imposes requirementson task schedules and bus schedules with respect tocompliance with the operating system specificationsand bus protocols.(3) correlation constraint; specifies the time skewamong the control input signal and each element ofthe measured states that is used to compute the input.

• Stage 3 (Synthesis): Finally, a feasible platform con-figuration which satisfies the imposed platform con-straints is synthesized using a constraint solver or anILP-based optimization framework.

To illustrate the above idea, we consider a feedback con-trol application as in (3) with two states and an implemen-tation platform with non-preemptive eCos running on theECUs and FlexRay as a bus system. The control appli-cation is partitioned into four tasks Ts,1, Ts,2, Tc, Ta andcommunicates via three messages m1,m2,m3. The sensortasks Ts,1, and Ts,2 read the states of the continuous signalsx1(t), and x2(t) at every sampling interval h and computethe corresponding outputs x1[k] and x2[k] which are pack-etized as messages m1 and m2 and sent over the bus. The

5

350

0 100 200 300 400 500!300

!200

!100

0

100

ms

y 1

Figure 9: Desired control performance.

0 100 200 300 400 500 600!1

0

1

2

x 105

ms

y 1

Figure 10: Unstable output due to constraint violation.

controller task Tc utilizes both input signals to compute thecontrol input u[k] which is transmitted over the bus and getsprocessed by the actuator task Ta which applies the controlinput to the system. Fig. 8 shows an exemplary timing dia-gram of a distributed controller implementation. Here, thefreshness constraint ! = h implies that the control inputu[k] is utilized for actuation at sampling instants (k + 1).The control objective is to bring back the system to refer-ence (which is zero) after any disturbance. Fig. 9 showsthe desired output of the control system which is obtainedwhen the freshness constraint is satisfied. Clearly, the ap-plication is asymptotically stable as with t ! ", y1 ! 0as mentioned in Section 2.

Fig. 10 shows the case when the freshness constraint on! is violated at sampling instance k = 4 (see Fig. 8) as thecontrol input u[4] gets delayed by more than one samplinginterval, and hence arrives at the actuator task Ta not be-fore k = 5. Hence, u[4] will finally be applied at k = 6which results in ! = 2h or u[4] will be overwritten by u[5].Further, at sampling instant k = 2 the value of x1[2] ar-rives at the controller after the controller task Tc has beentriggered at k = 2, and hence the control law is computedbased on x1[1] and x2[2] which leads to an unpredictablecontrol input u[2] and results in an unstable output as de-picted in Fig. 10.

As we could see, the performance of applications sig-nificantly depends on the design process and the proposedcyber-physical design method could address a number ofdesign- and implementation-level semantic gap.

0 20 40 60 80 1000

10

20

30

40

50

60

70

Sampling instants k

(ms)

Figure 11: Delay variation over FlexRay dynamic segment.

4 Co-design with Flexible Delay Constraints

In this section, we present another design example wherethe properties specific to control applications are exploitedin the platform design and vice-versa. More specifically,the schedule synthesis can significantly be directed bythe inherent robustness of control loops. We considerfeedback control loops closed over the dynamic segmentof FlexRay. The event-triggered nature of communicationin the dynamic segment of FlexRay might cause highvariation in feedback delays and occasional large delays.Fig. 11 shows the typical variation of delays experiencedby the control related messages in the FlexRay dynamicsegment. Given such high variation in delay in the feedbackloop, there are two possible design options:(i) The most obvious design approach to handle such jitterin the feedback loop is to design the control algorithmbased on the worst-case delay. Naturally, this leads tooverly conservative design as it can be seen from Fig. 11that the large delays occur very rarely.(ii) Another possible way to design the feedback controllerconsidering such timing-varying feedback delays is toutilize methods stemming from traditional NCS commu-nity [2, 13]. Mostly, these approaches are based on theassumption that the sensor-to-actuator delay uniformlyvaries between the best-case and the worst-case delayswhich is certainly not the case in most of the real-lifearchitecture. Because of such assumptions, such designoften becomes overly conservative and fails to identifyfeasible designs (or is only applicable to stable plants orplants with marginal instability, as in the example providedin [10]).

Proposed Approach: In contrast to the above approaches,our proposed approach utilizes knowledges from the overallsystem by (i) quantifying the robustness of control loopsin terms of permissible deadline miss and (ii) extracting

6

351

Architecturedesign

Sensor

+ - Controller Actuator SystemPlantControl algorithm

design

delay profile

robustness

schedule

control parameters

Figure 12: Co-design with Flexible Delay Constraints.the delay profile experienced by the control messages for aspecific choice of communication schedule. In this context,a large number of feedback messages suffer a delay nomore than some smaller threshold delay say ! = " andcontrol algorithm that is designed based on this thresholddelay provides a very good performance. When the controlmessages experience delay ! > ", the control performancedeteriorates and can potentially lead to instability. Therobustness of the control loops is defined by how frequentlysuch violation of deadline (i.e., ! > ") is permissible tothe control applications. Here, the robustness is quantifiedas the ratio between number of samples meeting theirdeadlines and missing their deadlines as shown in (4) . Theother aspect is to abstract the delay profile that the controlmessages are going to experience for a particular choiceof schedule. Utilizing these two aspects from control andits implementation platform it is possible (see Fig. 12)(i) to design the control parameters such that deadlineviolation constraint µ is satisfied for a given schedule,or (ii) to design the schedule such that the deadline vi-olation constraint µ is satisfied for given control parameters.

µ =No. of samples meeting their deadlinesNo. of samples missing their deadlines

. (4)

Illustrative Case-study: We illustrate the applicability ofthe proposed co-design guidelines considering an automo-tive application, namely cruise control system. A cruisecontrol system receives reference or commanded vehicle’sspeed from the driver and regulates the speed following thedriver’s command. Based on the reference speed and thefeedback signals, the cruise control system regulates the ve-hicle’s speed by adjusting the engine throttle angle to in-crease or decrease the engine drive force. The system outputis the speed of the vehicle v(t) and u(t) is the engine throttleangle. The objective is to choose u(t) such that v(t) = r,a constant desired speed. We have chosen r = 100. Wehave simulated external disturbances by periodically mak-ing v(t) = 80 (from v(t) = 100).

ECU4

Ta,j

ECU1 ECU3ECU2

Ts,i Tc,i Ts,j Tc,j Ta,i

FlexRay Bus

Sensor Sensor Actuator Actuator

Figure 16: Control application mapping onto a distributedautomotive architecture featuring a FlexRay bus

Time-Triggered Event-Triggered Communication Cycle

Slots

… 1 2 3 … 1 2 3

Figure 17: Schematic representation of the FlexRay proto-col: time- and event-triggered communication segments

Fig. 13 is the system response with higher priority sched-ule with µ = 40 which is greater than desired µ = 10(i.e., meeting design requirement). v[k] reaches r = 100in 1.76sec (i.e., settling time=1.76sec). Fig. 14 shows thesystem response with relatively lesser priority schedule re-sulting in µ = 14 which is still greater than desired µ = 10(i.e., meeting design requirement). v[k] reaches r = 100in 2sec. Fig. 15 shows the system response with low prior-ity schedule resulting in µ = 9 which fails to meet desiredµ = 10 (i.e., design requirement is not met) and the result-ing system is unstable. From the above three cases, it isclear that control application does not need as high priorityas µ = 40 and the priorities which result in µ % 10 aresufficient to achieve acceptable control performance.

5 Multi-mode CPS DesignAs already discussed, available technologies often can-

not fulfill and exploit control-theoretic design requirementswhich can potentially improve the design. Let us consider aset of control applications as given in Eq. (3). Every controlapplication denoted by Ci is partitioned onto a distributedautomotive architecture such that Ts,i (i.e., the sensing taskof Ci) and Tc,i are mapped to the same ECU, whereas Ta,i

is mapped to a separate ECU. As a result, control-relatedmessages need to be transmitted over a shared bus as shownin Fig. 16.

FlexRay is a so-called hybrid bus, i.e., it allows amix of time- and event-triggered communication as shownschematically in Fig. 17. A communication cycle inFlexRay consists of a static or time-triggered segment and adynamic or event-triggered segment. When all control mes-sages are mapped onto the static segment of the bus, thetime-triggered slots and the ECUs may be perfectly syn-

7

352

Seconds

Figure 13: µ = 40 which is greaterthan desired µ = 10 (i.e., meetingdesign requirement).

Seconds

Figure 14: µ = 14 which is greaterthan desired µ = 10 (i.e., meetingdesign requirement).

Seconds

Figure 15: µ = 9 which is lesserthan desired µ = 10 (i.e., designrequirement is not met).

Plant inSteady-

StatePlant in

TransientMode

ChangeProtocol

Plant inTransient

Plant inSteady-

State

Time-TriggeredMode

Event-TriggeredMode

After dwell time

ET-Controller

Disturbance

TT-Controller

Figure 18: Switching scheme between time- and event-triggered communication for control-related messages

chronized resulting in zero (or negligible compared to thesampling period h) communication delays. Clearly, thisleads to a good control performance (Fig. 19).

However, it is widely believed that as application com-plexity and hence communication requirements continue togrow, the bandwidth of the time-triggered segment will notsuffice and a purely time-triggered implementation might beoverly expensive. On the other hand, priority-driven event-triggered implementations suffer from the usual temporalnon-determinism which results in poor control performance(Fig. 21) (a lot of oscillations in the response).

We propose an intermediate design possibility where theaim is to achieve control performance close to a purely time-triggered implementation, but use fewer time-triggered slotsthan what would be necessary for fully time-triggered im-plementation. This is achieved by exploiting the followingtwo observations: (i) the settling time of a controller is moresusceptible to deterioration during its transient phase (i.e.,when the system experiences external disturbances), (ii) it isunlikely for independent control applications to experienceexternal disturbances simultaneously. As a result, an event-triggered implementation might suffice when the applica-tions are in their steady states. When they move to a tran-sient state because of an external disturbance, we proposeto switch the relevant control messages to a time-triggeredslot in order to minimize the reaction or settling time. Thecontrollers used in these two modes (time-triggered andevent-triggered) are such that they can cope with the dif-

ferent properties of the event-triggered and time-triggeredmode such as different delays, packet drop rates, responsetimes, steady-state error, etc. Next to linear controllerslike PID controllers, advanced non-linear controllers suchas adaptive controllers can be used [11]. This is illustratedin Fig. 18 and the corresponding system response is shownin Fig. 20. With the proposed scheme, control applicationsdo not require a time-triggered slot in an exclusive mannerbut only at the event of a disturbance. As a result, multi-ple applications can be assigned to the same slot. Clearly,the proposed switching scheme implies a trade-off betweencontrol performance and the cost of communication (i.e.,number of time-triggered slots).

5.1 Schedulability AnalysisIn the above scheme, a priority-based scheduling be-

comes necessary to grant access to the shared slot in theevent of simultaneous occurrence of disturbances to mul-tiple control applications – the priority given to applica-tions should reflect their urgency. Before switching totime-triggered in the event of a disturbance, an applicationmight have to wait (depending on whether the shared time-triggered slot is currently being used by another applica-tion). Such waiting time essentially deteriorates the controlperformance and the control performance becomes closerto the one with purely event-triggered implementation withhigher waiting time.

To meet a given control performance requirement (whichcannot be achieved by purely event-triggered implementa-tion), it becomes necessary for the control applications toaccess the assigned time-triggered slot within a maximumwaiting time. This maximum waiting time can be com-puted from the controller and its performance requirement.If the waiting time for a control application to access time-triggered slot exceeds this maximum time, the control appli-cation fails to meet the performance requirements. Hence,this acts as deadline for the control application. Clearly,the shared time-triggered slot acts as a processor, the con-trol applications are similar to the task running on it and theoccurrence of disturbances which necessitate time-triggeredcommunication behaves as task triggering. Overall, it is acomplex schedulabilty problem which is needs to decide on(i) slot assignment to the applications, (ii) arbitration policyamong the applications to guarantee performance [6, 7].

8

353

Time (Sec)

Figure 19: Purely time-triggeredcommunication.

Time (Sec)

Figure 20: Mixed time-/event-triggered communication.

Time (Sec)

Figure 21: Purely event-triggeredcommunication.

6 Concluding RemarksAutomotive in-vehicle networks are inherently complex

in nature. In modern cars, several functionalities need feed-back control loops. The traditional design flow performscontroller and implementation platform design in a decou-pled fashion which often leads to a non-optimal and overlyconservative design. In this paper, it is shown using sev-eral design examples that a holistic cyber-physical designapproach is more suitable for such complex design prob-lem. There are two main aspects in such design methodol-ogy (i) joint control/architecture design or co-design, (ii) ex-ploiting special properties of control application in the de-sign process. Design examples demonstrate significant im-provement in overall design.

References

[1] A. Cervin and P. Alriksson. Optimal on-line schedu-ling of multiple control tasks: A case study. In ECRTS,2006.

[2] M. E. M. B. Gaid, A. Cela, and Y. Hamam. Optimalintegrated control and scheduling of networked con-trol systems with communication constraints: Appli-cation to a car suspension system. IEEE Trans. onControl System Technology, 14(4):776–787, 2006.

[3] D. Goswami, R. Schneider, and S. Chakraborty. Co-design of Cyber-Physical Systems via controllers withflexible delay constraints. In ASP-DAC, 2011.

[4] D. Goswami, R. Schneider, and S. Chakraborty. Re-engineering Cyber-Physical control applications forhybrid communication protocols. In DATE, 2011.

[5] S. Hong, X. S. Hu, and M. D. Lemmon. Reducingdelay jitter of real-time control tasks through adaptivedeadline adjustments. In ECRTS, 2010.

[6] A. Masrur, D. Goswami, S. Chakraborty, J. Chen,A. Annaswamy, and A. Banerjee. Timing analysis of

cyber-physical applications for hybrid communicationprotocols. In DATE, 2012.

[7] A. Masrur, D. Goswami, R. Schneider, H. Voit, A. An-naswamy, and S. Chakraborty. Schedulability analysisof distributed Cyber-Physical applications on mixedtime-/event-triggered bus architectures with retrans-missions. In IEEE SIES, 2011.

[8] R. Schneider, D. Goswami, S. Zafar, M. Lukasiewycz,and S. Chakraborty. Constraint-driven synthesis andtool-support for FlexRay-Based automotive controlsystems. In CODES+ISSS, 2011.

[9] S. Soheil, P. Eles, Z. Peng, P. Tabuada, and A. Cervin.Dynamic scheduling and control-quality optimizationof self-triggered control applications. In IEEE RTSS,2010.

[10] X. Tang and J. Yu. Stability analysis for discrete time-delay systems. In Conference on Networked Comput-ing and Advanced Information Management, 2008.

[11] H. Voit, A. Annaswamy, R. Schneider, D. Goswami,and S. Chakraborty. Adaptive switching controllersfor systems with hybrid communication protocols. InAmerican Control Conference, 2012.

[12] H. Voit, R. Schneider, D. Goswami, A. Annaswamy,and C. S. Optimizing hierarchical schedules for im-proved control performance. In IEEE SIES, 2010.

[13] G. C. Walsh, H. Ye, and L. G. Bushnell. Stability anal-ysis of networked control systemss. IEEE Trans. onControl System Technology, 10(3):438–446, 2002.

[14] W. Wolf. Cyber-physical systems. IEEE Computer,42(3):88 – 89, 2009.

[15] F. Zhang, K. Szwaykowska, W. Wolf, and V. J.Mooney. Task scheduling for control oriented require-ments for Cyber-Physical Systems. In IEEE RTSS,2008.

9

354