Design Synthesis and Optimization

for Automotive Embedded Systems

Qi Zhu
University of California, Riverside
ISPD 2014
April 2, 2014
 More Intelligent Vehicles Active and Passive Safety

2
by Leen and Effernan IEEE Computer
 Challenges in Automotive: Electronics and Software
Shifting the Basis of Competition
Fuel Cell
More electronics and software Wheel Motor
More distributed, more contention

90% of all future innovations will be on
Value from Electronics & Software

electronics systems Hybrid PT

Electric Brake
Software $

100M Lines of Code (+9900%)

2% ACC DoD
Other $ Electronics $
Other $ Software $
9% 13% OnStar Rear Vision GDI
8% 13%
Passive Entry
OBD II

50 ECUs (+150%)
BCM

$1182 (+196%)
Electronics $
EI ABS HI Spd Data Side Airbags
24%
... MechanicalRear
TCC $ aud/vid Head Airbags Mechanical $
76% 20 ECUs 55%
EGR CDs 1M LOC
$400

Electric Fan
1970s 1980s 1990s AVG. 2000s AVG. 2010s 2020s
ABS: Antilock Brake System EGR: Exhaust Gas Recirculation.
ACC: Adaptive Cruise Control GDI: Gas DirectVehicle
Injection Integration
BCM: Body Control Module OBD: Onboard Diagnostics
DoD: Displacement On Demand System Connection
TCC: Torque Converter Clutch
ECS: Electronics, Controls, and Software PT: Powertrain
4
Subsystem Controls & Features Forefront of Innovation
 More Distributed System, More Sharing Among Functions
Post- function17
2014 function16
function15
function14

to function13
2012/14 function12
function11
function10

to function9
2010/12 function8
function7
function6
function5

Pre- ACC
2004 Stabilitrak 2
Onstar emergency notification

Speed-dependant volume
Subsystem

Brake

HVAC

Body

Steering

Suspension
detection
Object
sensing
Environment

Infotainment
protection
Occupant
lighting
Exterior
Information
Occupant

Engine

Transmiss.

Telematics
Courtesy: GM Research
Automotive Security

6
 Challenges in Automotive: Methodologies and Tools

More problems in vehicle electronic systems:

50% of warranty costs related to electronics and software.
Recalls related to electronic systems tripled in past 30 years.
Hard to diagnose: more than 50% of the ECUs replaced are technically
error free.

Methodologies and tools are needed for

Modeling, analyzing and verifying complex system behavior with
formal models.
Synthesizing models to implementation while maintaining functional
correctness and optimizing non-functional metrics such as
performance, reliability, cost, security, energy, extensibility.
Addressing multicore and distributed platforms.

7
 AUTOSAR Architecture
SW-C SW-C SW-C SW-C
Description Description Description Description

AUTOSAR

AUTOSAR

AUTOSAR

AUTOSAR
SW-C n
SW-C 1

SW-C 2

SW-C 3
Virtual Functional Bus

System
ECU Deployment tools Constraint
Descriptions Description

ECU1 ECU2 ECU3

AUTOSAR
AUTOSAR

AUTOSAR

AUTOSAR
SW-C 3

SW-C n
SW-C 1

SW-C 2

RTE RTE RTE

Basic Software Basic Software Basic Software

Gateway
Typical Automotive Supply Chain
From functional models to runnable (code) implementations, to task
models deployed onto architecture platform.

Suppliers AUTOSAR component OEMs

protecting IP Task code

SR
(Simulink)
models

(courtesy: Fabio Cremona)

 Functional model
Input Output
interface interface
s1 s2 s4 signal
f1 f2 f3 f4 period
is_trigger
s3 precedence
Functional
function
model period Jitter constraint s5
activation mode f5 f6
deadline
 Architecture model

s1 s2 s4
f1 f2 f3 f4
s3
Functional
model s5
f5 f6

ECU1 ECU2 ECU3

Architecture
model OSEK1 bus
CAN1 speed (b/s)
ECU
clk speed (Mhz)
register width
 Mapping

s1 s2 s4
f1 f2 f3 f4
s3
Functional
model s5
f5 f6

Software tasks
task1 SR1 task2 msg1 task3 task4
model
task msg2 message
period resource CANId
priority WCBT
WCET period
activ.mode length
transm. mode
ECU1 ECU2 ECU3 is_trigger
Architecture
model OSEK1
CAN1
 Model-Based Design and Synthesis
Functional Model Software Tasks Model
Task gen.
2
3 1 4
5
6

Task mapping

Architecture Model

CPU 1 CPU 2 CPU k

13
 Automotive Design Requirements
Primary Secondary What is captured Metrics unit
Performance/ End-to-end time distance between two events milliseconds
Time latency (related to stability and performance)

Jitter maximum delay of a periodic signal with milliseconds, or % of period,

respect to ideal reference
Input coherency time distance between two milliseconds
events/samples from multiple sensors
observing the same object/phenomenon
Dependability Reliability expectation on failure, related to expected time between
warranty cost impact failures MTTF or fault rate
(number of faults per hour)
Availability percentage of uptime MTTF/(MTTF+MTTR)

Safety which faults can be tolerated and which number of components/cutset

cannot. Related to fault tolerance, fail
safe vs fail operational
Extensibility room for functional additions (e.g.
Complement to resource utilization)
Cost
Piece cost (life cycle cost)
that must fail for the system to
fail
fraction of resource utilization
available for future use
$

Degree of Reuse ability to design/deploy using preexisting number of units deployed

solutions, (SW or HW components,
schedules and configurations)
Scalability suitability for a range of content level number of programs or 14
(while cost-effective) product lines
Task Generation from Functional Model

Synchronous Reactive
Semantics

Stateflow (FSMs) block Dataflow block

15
 Multi-task Generation of Synchronous Finite
State Machines
1 e1: 2ms
S1 1 : e1 / a1
0.25ms

S2
e1: 2ms S1
e2: 5ms 1 : e1 / a1
S3 3 : e1 / a3
0.25ms 0.3ms
2 : e2 / a2
4 : e2 / a4 0.2ms S2 2 e2: 5ms
0.5ms 2 S1
1
S3 3 : e1 / a3 2 : e2 / a2
0.3ms 4 : e2 / a4
0.2ms S
0.5ms 2

(a) Single task implementation S3

Task Period: 1ms
(b) Multi-task implementation
Task Period: 2ms, 5ms

16
 Multi-task Generation of FSMs

4-cycle conflicts
(a) Original FSM
(b) Partitioned model based on events
(c) Mixed-Partitioned model

17
 General Partitioned Model
e1: 2ms 1
S1
e2: 3ms 1 : e 1 / a1
2
2 : e2 / a 2 0.4ms
Partition is valid as long
0.2ms
5 : e 2 / a5 4 : e2 / a4
S2
as there are no cycles
0.4ms 0.5ms
1 2
S3 3 : e 1 / a3
0.3ms

1 1 2 1
3
T1: 1ms

3
2 T1: 1ms
T1: 2ms

3 2
4 4 4
5 5 5
T2: 1ms T2: 3ms T2: 1ms

18
 FSM Task Implementation Optimization

Design space
Map transitions in each FSM F to a set of tasks
Assign priorities to all tasks
Design objectives
Breakdown factor
Maximum factor that the execution time of all actions may be
scaled by while maintaining system schedulability
Action extensibility
For each action a, the maximum factor a that the execution time
of a may be scaled by a while maintaining system schedulability
System action extensibility is a weighted average of each actions
extensibility.

[ Qi Zhu, Peng Deng, Marco Di Natale and Haibo Zeng, Robust and Extensible Task Implementations
of Synchronous Finite State Machines, DATE 2013. ] 19
Task Generation of Macro Dataflow Blocks
(Synchronous Block Diagram)

20
 Model-Based Design and Synthesis
Functional Model Software Tasks Model
Task gen.
2
3 1 4
5
6

Task mapping

Architecture Model

CPU 1 CPU 2 CPU k

22
 Task Mapping onto Distributed Platform
Address metrics: end-to-end latency and system extensibility.
Based on mathematical programming and heuristics.
Challenges: formulation and efficiency.
Focus on analytical worst case analysis for CAN-based systems
with periodic tasks and messages.

Problems 1: Allocation & Priority 2: Period 3: Extensibility

Assignment Assignment Optimization
Design Allocation, Priority, Period Allocation, Priority,
Variables Signal Mapping Signal Mapping
Objective Latency Latency Extensibility
Approach Mixed integer linear Geometric MILP & Heuristic
programming (MILP) programming (GP)

23
 Task Allocation and Priority Assignment
300ms
10ms 20ms 40ms 40ms
40ms
T1 S1 T2 S4
1 1 T3
1 Function
20ms
20ms S2 20ms
40ms Model
S5 100ms
20ms 3
T4 T5 T6
2 S3 2 M2 2
1
20ms 20ms Task to ECU
M1
T7 S6 Signal packing
3 2
Message to bus
M3
Priority

ECU1 ECU2 ECU3

Architecture
BUS1
Model
BUS2
24
 Two-step Algorithm Flow
Constraints: Design inputs:
End-to-end latency on given paths Task worst case execution times
Utilization bound on ECUs and buses Signal lengths
Objective: Task and signal periods
Sum of latencies on given paths Architecture topology, bus speeds

Step1:
Heuristic:
Assign task allocation
Task and signal priorities
(using MILP)

Step2:
Assign signal packing, task
and message priorities
(using MILP)
[Wei Zheng, Qi Zhu, Marco Di Natale and Alberto Sangiovanni-Vincentelli, Definition of Task Allocation and Priority Assignment
in Hard Real-Time Distributed Systems, RTSS 2007. ]
[Qi Zhu, Haibo Zeng, Wei Zheng, Marco Di Natale and Alberto Sangiovanni-Vincentelli, Optimization of Task Allocation and 25
Priority Assignment in Hard Real-Time Distributed Systems, ACM TECS, 2012]
 Security-Aware Task Mapping for CAN-
based Distributed Systems
When retrofitting CAN architectures with security mechanisms,
MACs (message authentication codes) may be added to CAN
messages to protect against masquerade and replay attacks.
However, adding MAC bits to a design may not lead to optimal
or even feasible systems due to limited CAN message sizes and
timing constraints.
In this work, we designed an optimal MILP formulation and a
heuristic for optimizing task allocation, signal packing, MAC key
sharing, and priority assignment, while meeting both the end-to-
end latency constraints and security constraints.

[Chung-Wei Lin, Qi Zhu, Calvin Phung, Alberto Sangiovanni-Vincentelli, Security-Aware

Mapping for CAN-Based Real-Time Distributed Automotive Systems, ICCAD 2013]

26
 Summary
Model-based synthesis for automotive embedded
systems
Functional model with different semantics: FSMs, dataflow,
heterogeneous and hierarchical models.
Multicore and distributed architecture platform.
Task generation and task mapping need to be addressed in
a holistic framework.
Functional correctness (affected by timing).
Other non-functional requirements on performance, reliability,
power, thermal, security, extensibility, etc.

27
 Problem 1: Allocation & Priority Assignment
300ms
10ms 20ms 40ms 40ms
40ms
T1 S1 T2 S4
1 1 T3
1 Function
20ms
20ms S2 20ms
40ms Model
S5 100ms
20ms 3
T4 T5 T6
2 S3 2 M2 2
1
20ms 20ms Task to ECU
M1
T7 S6 Signal packing
3 2
Message to bus
M3
Priority

ECU1 ECU2 ECU3

Architecture
BUS1
Model
BUS2
28
 Experimental Results
Active safety application in GM experimental vehicle.
Function Model
Sensing & Object Object Object Target Drivers Features Arbitration Actuators
- Object Enable/Disable
1.6 Detection Tracking Fusion
DFD Selection Inputs ACP
MSB_L
CSV 19 Drivers Criticality
0601 Accel Pedal,
Control ACP Vector
.ACP
Brake Pedal,
Commands Forward Criticality
Steering Whl,
ACP Vector MSB_R
Gear Lever Drivers TOS_ACP Target ACP
Control Data Criticality
SAS, PAS, RWA,
Commands Switch Vector BCM
Yaw Rate, Lat Body
Vehicle FSRACC
Accel, VehSpd, Vehicle Function
Vehicle Motion Data

- 41 Tasks
Actual Gear, Path
Path FSRACC Actuators
Actual Direction of Calc Forward ACP
Nearest Brake &
Travel Suspension,
Engine

ath le
In-Path ACC Brake, &
P hic
TOS_FSRACC Commands Suspension
e Target Engaged Engine
V
RF-MRR Data Commands
Mid-Range
RF- Object Data
Forward
Commanded
Mid-Range Damping
LF- MRR Object Feature Control Park
Forward
Detection Object List . VB Output Arbitrator Brake
MRR and Fusion Forward TOS_VB Hold
LF-MRR VB Vehicle
Lane
Object Data Brake &
Path
Engine Commanded

- 83 Signals
Long-Range Long-Range Commands Vehicle Brake
Front- Forward Forward Forward Forward Switch Vehicle Accel
Front-LRR Object Object List Object Object Motion Commanded
LRR Object Data Detection Fusion List Control Vehicle
Long-Range Turn Supervisor Accel
Forward Signal Switch Throttle
Front . Commanded
Object List? Switches Status
Camera Forward- Engine
Object Data Looking Torque
Front- Camera Camera Commanded
LK
Camera Object Forward AFS
RWA
Detection Object List Optical
Front Lane Data Other

- 171 paths with 100ms to 300ms

.
Camera Control Output
Lane Steering
Lane Data Switch Arbitration
Sense HW
Optical Forward Forward Status . Troque
Lane
Lane Data Lane Path Lane
Function
Estimation Path
On/Off LDW
RR- RR-MRR Switch Switch LED LED in
Object Data Mid-Range .
MRR Rear Mid-Range Status Command Switch ?
LDW
LR- Object Rear
MRR LR-MRR Detection Object List
Object Data and Fusion Map . Haptic
Lane Data

deadlines
Seat
Map (Road Class) Go
Map Lane Data Notifier
Data Optical Switch
GPS GPS .
(Overpass) Lane Data Chime
Data
Rear .
Lane
Map2ADAS
Map Path . FCA . .
Map TOS_FCA
Lane Data Cluster
Map Must fix all feature
Wheel Data Raw Wheel descriptions in your
Speed Speeds files
Sensors Mid-Range SAPA .
since the HMI DIC
Rear
. Object List
.
Supervisor
has been removed.
Left Side
OSRVM_L
Short-Range NAPA
Left Side Left Side .
(U/S ?) Left Side
Mid/Long Object Object
Detection List .
Range
(Radar ?) . .

Using MILP based synthesis

OSRVM_R
TOS_LCA .
LCA .
Right Side .
Short-Range
Switch
(U/S ?) Side
Right Side Right Side Right t
.
Mid/Long Objec TOS_SBZA
Object List SBZA HUD
Range Detection
(Radar ?) . .
Vehicle Lane
Rear HMI
Position Path
Fusion? Supervisor
in the Lane History

(single-bus option)
- Initial: total latency > 24000 ms, do not
satisfy E2E latency constraints.
Mapping
...
ECU1 ECU2
- After Step1: total latency = 12295 ms,
satisfy all constraints.
ECU20 ECU21 ... - After Step2: total latency = 4928 ms.

Architecture Model
.
..

ECU61 ECU62 ... - 9 ECUs

- single-bus or dual-bus 29
 Problem 2: Period Assignment
Design variables are task and message periods.
Allocation and priorities of tasks and messages are given.
Utilization and end-to-end latency constraints.
Task worst case response time:

Approximate the
ceiling function

Geometric Programming
30
 Iterative Algorithm Flow
Iteratively change i Start

Parameters all i = 1;
maxIt max. # iterations ItCount = 0;
errLim max. permissible relative
error between r and s ItCount++;
(s, t) = GP();
Calculate r;
ei = (si ri)/ri;

(GP)
max(|ei|) < errLim
s =1 OR
No i = i - e i
ItCount > maxIt
r
(Fixpoint)
Yes
End
t 31
 Experimental Results

GP optimization meets all

deadlines in 1st iteration
Solution time: 24s

Maximum error reduced from

58% to 0.56% in 15 iterations
Average error reduced from
6.98% to 0.009%

[Abhijit Davare, Qi Zhu, Marco Di Natale, Claudio Pinello, Sri Kanajan and Alberto Sangiovanni-Vincentelli, Period Optimization
for Hard Real-time Distributed Automotive Systems, DAC 2007. ] 32
 Problem 3: Extensibility Optimization
Extensibility metric: function of how much the execution time
of tasks can be increased without violating constraints.

Same design variables as in allocation & priority assignment.

Constraints on utilization and end-to-end latency.
Utilization constraints (linear):

Latency constraints (non-linear):

33
 MILP and Heuristic Hybrid Algorithm
- one signal per msg
Initial Task and Signal Initial Task Allocation - utilization constr.
Priority (heuristics) (MILP approximation)
- latency constr. w/o
extensibility factor

Signal Packing and

Message Allocation
(weight-based heuristic)

Task Re-allocation
Task and Message
(greedy heuristic w/
Priority Assignment
incremental changes)
(iterative heuristic)

Reach Stop
Condition?
No
Yes
End 34
 Experimental Results
Parameter K to trade off between extensibility and latency.

30000
25000
Total Latency (ms)

manual K=0
20000
K=0.1
15000
10000
K=0.5 K=0.2
5000
0
16 18 20 22 24
Task Extensibility

[Qi Zhu, Yang Yang, Eelco Scholte, Marco Di Natale and Alberto Sangiovanni-Vincentelli, Optimizing Extensibility in Hard Real-
Time Distributed Systems," RTAS 2009.]
[Qi Zhu, Yang Yang, Marco Di Natale, Eelco Scholte and Alberto Sangiovanni-Vincentelli, Optimizing the Software Architecture for
Extensibility in Hard Real-Time Distributed Systems, IEEE TII, 2010.] 35
 End-to-End Latency
R1 R2 R3
o1 o2 o3
t1 t2 t3

t1 r1
o1
t2 r2
o2
t3 r3
o3
End-to-End Latency

For each object in the path, add

Period (ti)
Worst case response time (ri)

36
 Task Worst Case Response Time
Tasks: periodic activation and preemptive execution.

Interference from higher priority tasks on the same ECU

oi
Period (ti)
Response Time (ri)

Computation time Interference time

37
 Task Worst Case Response Time Formulation

Task i and j need to be

one the same ECU k.

Task j needs to have

higher priority than i.

38