Scuola Superiore Sant’Anna Design methods and tools for real-time (automotive) Abhijit Davare, Marco Di Natale, Paolo Giusto, Claudio Pinello, Alberto Sangiovanni- Vincentelli, Wei Zheng, Qi Zhu, GM Research and Development University of California at Berkeley, Scuola Superiore S. Anna, embedded systems
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
-
Scuola Superiore Sant’Anna
Design methods and tools for real -time (automotive)
Abhijit Davare, Marco Di Natale , Paolo Giusto, Claudio Pinello, Alberto Sangiovann i-Vincentelli, Wei Zheng, Qi Zhu,
GM Research and DevelopmentUniversity of California at Berkeley,
Scuola Superiore S. Anna,
Design methods and tools for real -time (automotive) embedded systems
-
Outline
• Automotive architecture trends and challenges
• Platform-based system-level design and timing evaluation metrics
• Issues with model-based design
• From analysis to synthesis
2
• From analysis to synthesis
• Activation models and end-to-end latencies
• Problem definition– Example
• MILP Optimization
• Case Study
-
Active and Passive Safety
3
by Leen and Effernan – IEEE Computer
-
AS - ACC (from Continental web site)
• Adaptive Cruise Control (ACC) – Chassis Electronics Combined with Safety Aspects
As with conventional cruise control, the driver specifies the desired velocity - ACC consistently maintains this desired speed.
In addition, the driver can enter the desired distance to a vehicle driving in front.
4
distance to a vehicle driving in front.If the vehicle now approaches a car travelling more slowly in the same lane, ACC will recognize the diminishing distance and reduce the speed through intervention in the motor management and by braking with a maximum of 0.2 to 0.3 g until the preselected distance is reached. If the lane is clear again, ACC will accelerate to the previously selected desired tempo.
-
AS-LDW (from Continental web site)• Lane Departure Warning System (LDW)
5
LDW wil warn the driver if he or she is on the verge of inadvertently drifting out of the lane. Using a CMOS Camera and an image processing algorithm, this driver assistance system registers the course of the lane in relation to the vehicle. The system "sees", as it were, the course of the road and where the car is going. If the warning algorithm detects an imminent leaving of the current driving lane, the system warns the driver with haptic, kinestatic, or acoustical feedback. Possible warning alerts can be a trembling in the steering wheel, a vibrating seat or a virtual washboard sound. Series production is planned for 2005.
-
Evolution of Integrated Functions
to 2010/1
to 2012/14
Post-2014
function17
function9
function10
function11
function12
function13
function14
function15
function16
6
Speed-dependant volume
Onstar emergency notification
Body
HVAC
ACCPre-2004
Stabilitrak 2
function6
function5
2010/12
Telematics
Transmiss.
Engine
Occupant
Informatio
nExterior
lighting
Occ.
protection
Infotainm.
Environm.
sensing
Object
detection
Suspension
Steering
Brake
Subsystem
function7
function8
-
Automotive architecture trends
• Horizontally-integrated functions are becoming key differentiators and are gaining increasing authority
• An increasing number of functions will be distributed on a decreasing number of ECUs and enabled through an increasing number of smart sensors and actuators• today: > 5 buses and > 30 ECUs
• 90% of innovation in cars for the foreseeable future will be enabled through the Electronic Vehicle Architecture
7
enabled through the Electronic Vehicle Architecture
• Transition from single-ECU Black-box based development processes to a system-level engineering process • System-level methodologies for quantitative exploration and selection,
• From Hardware Emulation to Model Based Verification of the System
• Architectures need to be defined years ahead of production time, with incomplete information about (future) features
• Multiple non-functional requirements can be defined
-
Outline
• Automotive architecture trends and challenges• Platform-based system-level design and timing evaluation metrics– worst-case analysis– stochastic analysis
• Issues with model-based design
8
• Issues with model-based design • From analysis to synthesis• Activation models and end-to-end latencies• Problem definition
– Example
• MILP Optimization• Case Study
-
Function
Deployment Design Process
Function
Functional
Design
Requirements and
specification definition
IP Functional
Library Blocks
9Architecture
Solution
Function
Architecture
DevelopmentIP Architecture
Library Blocks
Architecture
Map function
to architectureMapping
System Quality
Analysis
-
f1 f2 f3 f4
f5 f6
s4
s5
s2
s3
s1
Functional model
deadline
Jitter constraintfunctionfunctionfunctionfunctionperiodactivation mode
signalsignalsignalsignalperiodis_triggerprecedence
Input Input Input Input interfacinterfacinterfacinterfac
eeee
Output Output Output Output interfacinterfacinterfacinterfac
eeee
Functional model
10
-
f1 f2 f3 f4
f5 f6
s4
s5
s2
s3
s1
Functional model
Architecture model
11
ECU2ECU1 ECU3
OSEK1CAN1
Execution architect. model
ECUECUECUECUclk speed (Mhz)register width
busbusbusbusspeed (b/s)
-
f1 f2 f3 f4
f5 f6
s4
s5
s2
s3
s1
task task task task
Functional model
System SR
Deployment model
12
ECU2ECU1 ECU3
OSEK1CAN1
task1 task2 task3 task4System platform model
Execution architect. model
SR1 msg1
msg2tasktasktasktaskperiodpriorityWCETactiv.mode
messagemessagemessagemessageCANIdperiodlengthtransm. modeis_trigger
resourceresourceresourceresourceWCBT
-
RequirementsRequirementsRequirementsRequirements
ModelModelModelModelModel ModelModelModelModelModel ModelModelModelModelModel Validation
SystemSystemSystemSystem----level virtual prototyping level virtual prototyping level virtual prototyping level virtual prototyping and architecture selectionand architecture selectionand architecture selectionand architecture selection
Virtual prototyping (virtual platforms)Virtual prototyping (virtual platforms)Virtual prototyping (virtual platforms)Virtual prototyping (virtual platforms)Validation
Manual
RequirementsRequirementsRequirementsRequirements
ModelModelModelModelModel
Tool integration platform
PrototypePrototypePrototypePrototype
Unit Testing
ModelModelModelModelModel ModelModelModelModelModel ModelModelModelModelModel
ModelSW Implem.SW Implem.SW Implem.SW Implem. ModelSW Implem.SW Implem.SW Implem.SW Implem. ModelSW Implem.SW Implem.SW Implem.SW Implem.
Debugging
ModelPrototypePrototypePrototypePrototype ModelPrototypePrototypePrototypePrototype ModelPrototypePrototypePrototypePrototypeIntegr. Testing
ECU1 ECU2 ECU3
Debugging
Manual/Automatic
ModelModelModelModelModel
ModelSW Implem.SW Implem.SW Implem.SW Implem.
ModelPrototypePrototypePrototypePrototype
-
FunctionalModel
SoftwareModel
� Control algorithm design� Plant Model design� Fault Model� Functional Simulation
Allocate Functionto Tasks
� Task and their WCET� Signals
Functionality
PhysicalArchitecture
Model
� ECU architecture� Network architecture
ArchitectureFunctional
Requirements
Design Process and Requirement
F A
M
Non Functional Requirements
Timing CostDependability
Input Coherency
14
Model
Mapping
� Signals� Middleware� OS
� Allocating tasks to ECU� Allocating signals to BUS
System Quality Analysis
M
QAEnd to End Latency
Jitter
� Schedulability Theory Based
� Worst Case Analysis
-
Functional Model: An example
xxx
Yaw rate, Lat accel, Veh speed, Act gear, Act
Acc. Pedal, brake pedal,
steering wheel, Gear
level Vehicle Path
calc
VehicleMotion control
Supervisor
Steering torque
led & switch
ddd
Turn Signal Switches
Haptic seat
Functional
Design
Function Examplexxx
15
xxxgear, Act direction
Front camera
yyy
aaa
bbb
ccc
Forward lane path estimation
eee
on/off switch
Chime
ggg
fff
Requirements and
specification definition
< 100 ms< 100 ms< 100 ms< 100 ms
F A
M
QA
-
Architecture Model: An example
Architecture Option
Fwd EOCM
SCM
Rear / Side EOCMVehicle Path
Front
FrontCameraLRR_F
ObjDetectMRR_LR MRR_RR MRR_LF MRR_RF
MRR_LSBZA_L
MRR_RSBZA_R
16
ECM
SAS
TCM
IMU
BCM
IPC AMP
ONSTARGMLAN
EPSEHPS
RADIO(Silver Box)Map 2 Adas
Brake
ITBC AFL
Stg TorqueOverlay
EPS/EHPS
Strg Torq Ctrl
Service Only
Lane Keeping
PosOverlay
EPSEHPS
Architecture
Development
F A
M
QA
-
Deployment: An example
-
12
End-to-end latencies
ECU and bus utilizations
17
EPS
EHPS
.
ITBC
MSB 1
MSB 2AFL
PALC
3
4
F A
M
QA
-
Periodic Activation Model
1τ 2m 3τ 4m 5τ 6o
1ECU
2ECU
4ECU
1o
CAN
0e
• Predictable activation model easy latency computation
• Suffers from high worst case latencies
1T 1r
18
3,1L
2o
3o
∑∈
+=),(:
, )(jiPok
kkji
k
rTL ∑∈
+=
)( ihpjj
j
iii CT
rCrWhere
113,1 rTL +=
2T 2r
22 rT ++
3T 3r
33 rT ++
-
Data Driven Activation Model
1τ
m
1τ 2m 3τ 4m 5τ 6o
1ECU
2ECU
4ECUCAN
• Shorter end to end latencies
• Large interference intervals withbursty activations
1w
2wJ
19
3,1L
2m
3τ
∑∈
=),(:
,jiPokkji
k
wL WhereApprox.
∑∈
++=
)( ihpjj
j
jiii CT
JwCw
13,1 wL =
2w2J
2w+
3w3J
3w+
-
Functions Reqmt Alt 5 Alt 5exp Alt 6 Alt 7 (event)
Functions Reqmt Alt 1 Alt 2 Alt 4 Alt 4expfunction5 180 433.92 178.92 159.08 116.58 312.32 119.82 312.32 119.82function4 100 395.21 155.21 109.35 89.35 180.93 70.93 180.93 70.93function3 300 678.72 196.22 711.25 191.25 711.60 191.60 724.18 204.18function2 300 520.99 170.99 479.06 129.06 479.19 129.19 489.19 139.19function1 300 695.38 232.88 715.75 195.75 716.10 196.10 728.68 208.68
Synthesis opportunity
Case study 1
20
Functions Reqmt Alt 5 Alt 5exp Alt 6 Alt 7 (event)function5 180 310.58 118.08 310.58 118.08 230.06 72.56 130.1 60.06function4 100 180.97 70.97 180.97 70.97 180.97 70.97 80.97 58.47function3 300 532.74 162.74 532.74 162.74 532.74 162.74 333.9 123.9function2 300 489.57 139.57 489.57 139.57 489.57 139.57 303.8 113.8function1 300 537.24 167.24 537.24 167.24 537.24 167.24 318.9 128.9
• By transmitting messages “on event”, the worst case latency can be reduced in most cases
• By properly allocating functions to ECUs the end-2-end latency can be improved
-
Stochastic and simulation-based analysis
• Simulation
– Built C++ simulator for can message analysis (at bit level – only arbitration)
– Currently being expanded to end-to-end computations, periodic sampling model for latency analysis
21
latency analysis
• Stochastic analysis
– Approximate analysis of pmf of message latencies in CAN bus (complete - target ?)
– Future work
• End-to-end analysis of sampling model
• Regression-based analysis to define pmf from general information (such as load or loads at harmonic rates)
-
Stochastic and simulation-based analysis
2262 msg set (subset of chassis bus). Low priority ms g – Distributions of latencies
-
Outline
• Automotive architecture trends and challenges• Platform-based system-level design and timing evaluation metrics– worst-case analysis– stochastic analysis
• Issues with model-based design
23
• Issues with model-based design• From analysis to synthesis• Activation models and end-to-end latencies• Problem definition
– Example
• MILP Optimization• Case Study
-
Issues with model-based development
• Model-based design methodologies
– improve the quality and the reusability of software.
– The possibility of defining components (subsystems) at higher levels of abstraction and with well defined interfaces allows separation of concerns and improves modularity and
24
concerns and improves modularity and reusability.
– The availability of verification tools (often by simulation) gives the possibility of a design-time verification of the system properties.
• However, most modern tools for model-based design have a number of shortcomings
-
Issues with model-based development
• Lack of separation between the functional model and the architecture model
• Lack of support for the definition of the task and resource model
• Insufficient support for the specification of timing constraints and attributes
25
timing constraints and attributes
• Lack of modeling support for the analysis and the back-annotation of scheduling-related delays
• Issue of semantics preservation
-
Outline
• Automotive architecture trends and challenges• Platform-based system-level design and timing evaluation metrics– worst-case analysis– stochastic analysis
• Issues with model-based design • Time predictability and timing isolation
26
• Time predictability and timing isolation• From analysis to synthesis • Activation models and end-to-end latencies• Problem definition
– Example
• MILP Optimization• Case Study
-
Opportunities for synthesis
PeriodsActivation modes
SystemFunctionality
SystemArchitecture
MappingTask and message
Function to ECU allocation
Number and type of ECUs and busesSystem topology
DATE 07 (MILP)
DAC 07 (GP)
Simul. annealing
27
Flow To Implementation
Mapping
PerformanceAnalysis
Refinement
message priorities
allocationFunction to task mapping
DATE 07 (MILP)RTAS 07 (B&B)
Current (formulation found for 1 bus case – MILP)
-
Periodic Activation Model
EndEndEndEnd----totototo----end end end end latency latency latency latency analysisanalysisanalysisanalysis
Periodic Periodic Periodic Periodic asynchronous asynchronous asynchronous asynchronous
activation modelactivation modelactivation modelactivation modelHigh latency, but allows decoupling the
scheduling problem
ECUECUECUECU1111 CANCANCANCAN
ECUECUECUECU2222
ττττ1111evevevev0000
evevevev
mmmm2222 ττττ3333ECUECUECUECU3333
mmmm4444 ττττ5555
28
ECUECUECUECU1111 CANCANCANCANevevevev0000
where (approx.)
ττττ1111rrrrTTTT1111 TTTT1111
TTTT2222
ττττ1111mmmm2222
ττττ3333
mmmm2222rrrrTTTT2222
-
Event-based Activation Model
EndEndEndEnd----totototo----end end end end latency latency latency latency analysisanalysisanalysisanalysis
DataDataDataData----driven precedence driven precedence driven precedence driven precedence constrained activation constrained activation constrained activation constrained activation
modelmodelmodelmodelLower latency for high priority paths, jitter
increases along the path
ECUECUECUECU2222
ττττ1111evevevev0000 mmmm2222 ττττ3333ECUECUECUECU3333
mmmm4444 ττττ5555
29
ECUECUECUECU1111 CANCANCANCAN
where (approx.)
JJJJ3333
TTTT1111 ττττ1111mmmm2222
ττττ3333
ττττ1111wwww
mmmm2222wwww
-
Activation modes: latency tradeoffs
End to end latency requirements
16o8τ17o
18o
14o 15o1τ
9τ
3τ
3ECU
2ECU
CAN
10m
7m
2m
6τ
4m 5τ
11τ 12m 13τ
1ECU
19o
Periodic Event-based
30
End to end latency requirements
,od 701514⇒o
,od 1001716⇒o
,od 1201918⇒o
Mixed activation mode
-
Model Definition
• Selection of the activation event and link groups
1l4l
5l
l
Task27
CAN1CAN3
)(lg1repor =Group RepresentativeLink Group
31
2l
3l
6l
An object can be activated by:• Periodic Timer• Signal from a single predecessor
T27=100
CAN2
CAN4
7l
8lro
9l• AND composition of signals from a link group
-
Latencies of OSEK Tasks and CAN Messages
iii
ihpjj
j
jiii
wJr
CT
JwCw
+=
++= ∑
∈ )(
iii
iiqi
ihpjj
j
jiii
wJr
qTqww
CT
JqwCqqw
+=
−=
+++= ∑
∈
})({max
)()1()(
)(
[Jos78]
Processor
Processor
First q InstancesFirst q Instances First InstanceFirst InstanceLinear ApproximationLinear Approximation
Upper
Upper
Lower
Lower ∑
∑
↓↓
∈
↑↑
++=
++
+=)(
)(
)1(
jji
ii
ihpjj
j
jiii
CT
JwCw
CT
JwCw
Linear CombinationLinear Combination
∑
∑∑
∈
∈∈
−
+×+=
)(
)()(
1)(
ihpjj
ihpjjj
ihpjji
i u
uJCC
w
αα
32
ii
iii
Tqrqq
wJr
≤=
+=
)(,...0 **[Jos78]
ii
iii
iiiqi
ihpjj
j
jiiii
Tqrqq
wJr
qTqwqCw
CT
JqwqqCBqwq
≤=
+=
−+=
+++= ∑
∈
)(,...0
})({max
)()(
**
)(
Bus
Bus
Lower
Lower
Upper
Upper
Lower
Lower
∑∈
+=)(
)(ihpj
jj
ii CTCw
∑
∑
∈
↓↓
∈
↑↑
++=
++
+=
)(
)(
)(
)1(
ihpjj
j
jiii
ihpjj
j
jiii
CT
JwqBwq
CT
JwqBwq
∑
∑∑
∈
∈∈
−
+×+=
)(
)()(
1)(
ihpjj
ihpjjj
ihpjji
i u
uJCB
wq
αα
iii
iii
ihpjj
j
jiii
wJr
Cwqw
CT
JwqBwq
++++====++++====
++++++++==== ∑∑∑∑
∈∈∈∈ )(
-
Linear Approximation
1τ 2m 3τ 4m 5τ14o 15o
8τ 7m 6τ17o 16o
18o 19o9τ 10m 11τ 12m 13τ
1514 ,ooL
1716 ,ooL
1918 ,ooL
36.44 86.130 03.507upperLinear _
int_ poFixed
lowerLinear _
40 88 312
91.38 43.79 96.294
A linear combination of linear upper and lower boun ds can be sufficiently accurate to be used as an estimator of actual e2e latency
33
-
MILP Solution
Set of resources (CAN, ECUs) :
Set of links connecting schedulable objects :
communication functions
Set of objects implementing the computation and:
R
E
V
ii
ii
oT
o
object ofPeriod:
object ofPriority :ππππParameters
Sets
34
ii
ii
oC
oT
object ofon timetransmissiexecution/caseWorst :
object ofPeriod:
tss,t
ii
ii
ii
ooL
ow
oJ
or
andobject between latency endtoEnd:
object oftimequeueingrunnablecaseWorst :
object ofJitter Release:
object oftimeresponsecaseWorst :Variables
=otherwise,0
by driven -eventisofactivationIf,1,
hkkh
ooy
-
Feasibility Constraints 1
oGLgkrk
oGLgkr
kskr
MyJ
y
yy
kh
kh
×≤
≤
=
∑
∑
∈
∈
1
)(,
)(,
,,
Jitter Inheritance Rule
1l
2l
3l
4l
5l
6l
1Lg
2Lg
3Lg
1R
2R
ko
All links in one group assumethe same activation model
Only one of the incoming link group can provide its activation signal
If none of incoming groups carryactivation signal, then release jitter
35
kkrr
krrk
k
JMyr
MyrJ
Jkh
≤×−−×−+≤
≤
)1(
)1(
0
,
,
MyJ
rJ
JMyr
khk
hk
kkhh
×≤≤
≤×−+
,
, )1(
2R
ko
activation signal, then release jitterof object k is 0
Release jitter inherited from object r which has largest wcrt from the activating group
Simplified version of link groups
-
Feasibility Constraints 2
hhh Jwr +=
∑
∑
∈
↓↑
∈
−×−+×
+++=
PPpPP
hhpkk
k
khhh
r
rrrLLL
CT
JwCw
2
)(
))1((
)(
αα
α
Calculation of worst case response time
• A linear combination of linear upper and lower bounds is used as an estimation of runnable queuing time
• alpha is chosen to minimize the mean square fit function
WCRT Rule
36
jijijjj
jjjji
jijji
jij
zMyTJw
TJwz
Mywz
zw
,,
,
,,
,
)1(
≤×−++
++≤
×−+≤
≤
tsts
Plvuts
dL
zLtsvu
,,
,,
,,
≤
= ∑∈Path end to end latency can not
exceed deadline
jo
++=
j
jjjj
jij
ji
J
oTJw
lw
z
jitter release with signalother
by activated bemay otherwis,
signal activation carries link if ,
,
Latency Rule
-
Possible Objective Function
∑
∑∈
p
GLgkj
r
h
LMinimize
yMaximize ,Minimization of the number of event buffers in the system
Minimization of sum of end to end latencies
37
∑
∑
∈
∈
−×PP
ppp
PPp
r
rrr
r
r
dLMaxMinimize )0,(γ
end to end latencies
Minimization of sum of weighted deadline violation
-
Outline
• Automotive architecture trends and challenges
• System-level design methodology and timing evaluation
38
timing evaluation
• Activation models and end-to-end latencies
• Problem definition
– Example
• MILP Optimization
• Case Study
-
Experimental vehicle case study
Functional Architecture
Mapping
• 100 Tasks• 322 Messages
39
Physical Architecture
Using Schedulabilitytheory to set schedulableobject activation model
..
.ECU1 ECU2
..
.ECU20 ECU21
...
..
.ECU61 ECU62
• 6 BUSes• 38 ECUs
-
Case study resultsProblem characterization
• 38 ECUs, 6 Buses• Bus speed between 25
and 500 kb/s• Bus utilization between
30% to 50% • CPU utilization between
5% to 60%• 100 tasks, 322 messages
Before Optimization(all periodic)• Worst case = 577ms
was found for paths with deadline 300ms
• Worst case = 255.5ms found for paths with deadline 200ms
• Worst case = 145.4ms
Optimization results
• A feasible solution is found if using the largest lateness path metric
after changing 24 groups• 294.8 for paths with d=300 • 158.1 for paths with d=200• 95.46 for paths with d=100(61.57 average slack)
40
• 100 tasks, 322 messages• Number of links in the
functional dataflow is 507• 184 Paths analyzed
between 10 pairs of functional nodes
• Worst case = 145.4ms found for paths with deadline 100ms
(61.57 average slack)• the solution was improved
with 5 extra branches(76.79 average slack)αααα practically constant =0.465with weighted sum of pathlatencies (evaluating all nodes) no solution found
Time to solve is • 2.6 s for the exact analysis• 7 s for the linear approx(on a 1.4GHz PC)
-
Approach
• Mathematical programming
– Modifying an object period affects multiple paths
– Additional constraints due to legacy tasks and messages
• Geometric Programming: Poly-time optimization
– Standard Form:
4141
– x = (x1, x2, …, xn) are positive real-valued variables
– g is a set of monomial functions
– f is a set of posynomial functions
• Sum of monomials
-
Geometric programming formulation
• Approximate the response time ri with si– 0 ≤ αi ≤ 1
– If all αi = 1, si ≥ ri
Minimize the sum of
4242
Minimize the sum ofapprox. response times
Meet end-to-endlatency deadlines
Transformed equationsfor approx. response times
Ensure schedulability
Meet utilization bounds
Lower and upper bounds for periods
-
Iterative Procedure to Reduce Error
• Iteratively change αibased on error
• Parameters
– maxIt – max. # of iterations
– errLim – max.
Start
all αi = 1;ItCount = 0;
ItCount++;(s, t) = GP(α);Calculate r;
4343
– errLim – max. permissible error
Calculate r;ei = (si – ri)/ri;
Max(|ei|) < errLimOR
ItCount > maxIt
End
Yes
αi = h(αi, ei)No
-
Case Study: Advanced Safety Vehicle
• From GM Research
• E.g. enhanced cruise control, lane departure warning, parallel parking assist .
.
-
.
.
.
.
4444
• Architecture
– 38 ECUs
– 4 buses
• Functionality
– 92 tasks
– 196 messages
.
.
� End-to-end latency constraints
� Over 12 source-sink task pairs
� 222 total paths
� Deadlines range from 100ms to 300ms
-
Experiments
• GP optimization meets all deadlines in 1st
iteration
• Solution time: 24s
4545
� Maximum error reduced from 58% to 0.56% in 15 iterations
� Average error (not shown) reduced from 6.98% to 0.009%
-
Concluding remarks
– Quantitative analysis offers opportunities for architecture exploration and selection
– Domains of cost, dependability and time have been identified as prime candidates
• not considering, for example, power
– Analysis techniques are at different levels of
46
– Analysis techniques are at different levels of maturity
– Uncertainty challenge
• Some required information is typically not available in the early development stages
• Requirements extraction process is not mature
– Synthesis to be extended to other domains
• leveraging MILP or GP formulations of the placement, priority assignment and period definition problems
-
Concluding remarks
– Worst case timing analysis can be applied to design optimization problems
– With respect to end-to-end latencies in distributed architectures there are multiple dimensions that can be explored
• task allocation
47
• task allocation
• period assignment
• priority assignment
• ...
– Also, most active safety functions are not truly hard real-time and worst case analysis may be pessimistic
• end-to-end stochastic analysis
• design optimizations based on stochastic analysis ?
-
Q&A
Thank you!
48
-
49
E-mail: [email protected]
Scuola Superiore Sant’Anna, CNR research area, Via Moruzzi 1, 56124 Pisa, Italy
Related Documents
