Transcript Scheduling Analysis in the Automotive Design Flow

1
Automotive Software Integration
Razvan Racu, Arne Hamann, Rolf Ernst
Technical
University
of Braunschweig
Kai Richter
Outline
 Software Integration and AUTOSAR

AUTomotive Open System Architecture
 AUTOSAR and System Timing
 System-level Timing Analysis
 Examples
 Conclusion
3
Automotive Integration Challenges
 Complexity

Hundreds of functions

50+ ECUs

Networked control

Many suppliers

Heterogeneous
55 ECUs & 7 Buses of 4 types with Gateways
source: Daimler-Chrysler
 Integration challenges are key

Risks: reliability, quality, liability

Meeting target SOP

Development and production cost
4
AUTOSAR Goals
 Modularity
 tailor the SW-components according to the individual
requirements
 Scalability
 adaptability of SW-components to different vehicle platforms
 avoid proliferation of software with similar functionality
 Transferability
 remapping of SW-components among different HW-components
 balance the use of resources
 Re-usability
 adaptability of SW-components across different product lines
 shorten design process
 improve quality and reliability of E/E systems
 Standardized interfaces
5
AUTOSAR Consortium
Source: www.autosar.org: Status Oct. 2005
6
AUTOSAR Methodology
Source: www.autosar.org
 SW-Components (SW-C)

encapsulate the applications
 Virtual Functional Bus (VFB)


communication mechanisms
interface to Basic SW
 Mapping

configuration and generation
of RTE and Basic SW
 Runtime Environment (RTE)

VFB implementation on a
specific ECU
 Basic Software (BSW)

infrastructural functionality
on an ECU
7
AUTOSAR Software
 The Atomic Software Component
consists of

software component description




operations and data elements provided/required
requirements on infrastructure
required resources (memory, CPU-time, etc)
implementation


object code
source code
 Virtual Functional Bus


enables hardware and mapping independent integration of
SW-components
communication mechanisms


Client-Server
Sender-Receiver
8
SW Components and Runnables
 SW-Components


atomic components with
respect to mapping
provided by one supplier
Sensor SWC
 Runnables


atomic components with
respect to execution
attached to different OS
Tasks
runnableA
SW-C 1
runnableB
RTE
BSW
runnableC
9
Outline
 Software Integration and AUTOSAR

AUTomotive Open System Architecture
 AUTOSAR and System Timing
 System-level Timing Analysis
 Examples
 Conclusion
10
Timing Data Required
 Response times

for networked control
 Load data


static and transient
to determine buffer sizes and potential message losses
 Performance „slack“

potential for later extensions
11
Timing is Critical Everywhere
Requirements
Requirements Test
Architecture
Exploration
System Test
System Design
Network Timing
Estimation
Module Design
Network Timing
Verification
Module Test
ECU Timing
Estimation
Function Design
SystemTiming
Verification
ECU Timing
Verification
Function Test
12
SW Component Execution
 Standardized RTE eases compiling & linking together
several SW components from different teams/vendors
Vehicle Function
Sensor
Sensor
SWC
Actuator
SWC
SWC1
SWC-1
Sensor SWC
RTE
RTE
BSW
BSW
Sensor
Signal Path / Data Flow
Actuator
Actuator SWC
Actuator
13
Timing Chains and Hand-Over Points
SWC1
RTE
CAN
BSW
RTE
Sensor SWC
RTE
BSW
BSW
RTE
I/O
Actuator
INTRA-ECU
comm.
INTER-ECU
comm.
Sensor
Actuator
SWC
SWC1
Actuator
SWC
BSW
RTE
Sensor
SWC
Sensor
I/O
I/O
Actuator
HOPs
timing chain segments
end-to-end timing chain
14
Runnables and Tasks
SW architecture example: 2 SW components, 6 runnables
runnableA
SW-C 1
runnableY
runnableB
runnableX
runnableZ
runnableC
SW-C2
RTE
BSW
ECU 1
OS
runnableX
OS
OS
Schedule and timing dependencies
runnableZ
runnableZ
runnableC runnableB
runn
ableA
runnableY
15
Conclusion: Timing in AUTOSAR
 Timing is no AUTOSAR objective, but an AUTOSAR
issue
 Hidden timing chains and non-functional dependencies
challenge predictability
 Good methods are required


prohibit nondeterministic timing behavior (race conditions)
applicable across corporate boundaries



different OEMs
different SW-Suppliers
different HW-Suppliers
 Timing analysis required to support design process
16
Outline
 Software Integration and AUTOSAR

AUTomotive Open System Architecture
 AUTOSAR and System Timing
 System-level Timing Analysis
 Examples
 Conclusion
17
Timing Analysis Hierarchy
ECU1
ECU2
gateway 2
ECU3
ECU4
global system timing
gateway 1
ECU6
ECU5
runnableA
SW-CECU
1
1
runnableB
runnableC
runnableY
runnableX
runnableZ
runnable
SW-C2
single component or
network channel
timing
single process timing
18
Compositional Analysis
ECU 1
ECU 2
R2
R1
R3
R4
environment model
local analysis
 Subsystems coupled by streams


parameterized streams
event curves (network calculus)
 Coupling corresponds to
event propagation
 Solve fix point problem
derive output event model
map to input event model
until convergence or
non- schedulability
 Tools available, e.g. SymTA/S, MPA
19
Tool SymTA/S
evolutionary algorithm
• incremental/interactive
• multidimensional
• robustness metrics
search problem
Sensitivity
analysis
Optimization
(Exploration)
formal
compositional
analysis
 Used by several automotive companies for automotive
systems optimization (incl. robustness optimization,
planning of upgrades, ...)
20
SymTA/S Screenshot
21
Runnable Execution Time Analysis
 Code already available


Measurement or tracing - coupling with OTS tools
formal verification – coupling with WCET tools (e.g. aiT)
 Code not yet available/not yet executable

estimated data
need to know sensitivity to errors
22
Outline
 Software Integration and AUTOSAR

AUTomotive Open System Architecture
 AUTOSAR and System Timing
 System-level Timing Analysis
 Examples
 Conclusion
23
Ex 1: Network Analysis
CAN1
CAN2
ECU1
ECU4
ECU2
ECU5
ECU3
ECU6
gateway
ECU8
ECU7
time table
Msg1
CAN3
MO2
CAN 1
MO1
bus IF
host IF
Msgn
host IF
bus IF
bus IF
bus IF
Msg2
buffer
Gateway
24
Priority Queue vs. FIFO in CAN Networks
 Buffering strategy (inside ECU) has huge influence on
Shared FIFO Buffer
network timing
Shared priority ordered buffer
undermines the CAN protocol's priority scheme
priority
high
3 messages
share a FIFO
low
blocking due to
non-preemptiveness
low-priority frames
benefit from FIFO
high-priority frames must
wait for low-priority frames
Screenshots by
25
Ex 2: Reliable CAN Bus Extension
 Problem

CAN bus load high, but need to carry more frames
 Formal analysis


accurate analysis
offset / CAN ID optimization
 Result

reliable room for new frames, higher rates, or error
handling
26
European OEM Example
Message Response Times
90
Response Time (ms)
70
utilization gain
80
Classical response time analysis
60
Realistic response time analysis
with offsets
50
40
No Offsets
Typical Offsets
Optimized Offsets
overload management time-out
30
20
Resp time analysis
with optimized offsets
10
0
0
5
10
15
20
25
30
Message Number (ordered by priority)
27
Sensitivity Analysis
 Problem: uncertain or undefined input data
 SymTA/S: sensitivity analysis of system properties
 Result: available headroom in design
Communication time
Frame 1
Frame 2
Frame 3
Frame 4
Frame 5
Communication rate
Frame 6
Frame 7
Frame 1
Frame 8
Frame 2
Frame 9
Frame 10
Frame 3
Frame 11
Frame 4
Initial
Frame 5
Maximum
Frame 6
Initial
Minimum
28
Outline
 Software Integration and AUTOSAR

AUTomotive Open System Architecture
 AUTOSAR and System Timing
 System-level Timing Analysis
 Examples
 Conclusion
29
Conclusion
 Automotive software standards improve modularity, reuse, and scalability
 Lack of timing model standard which supports reliable
supplier-OEM chains
 Complex and hidden timing effects challenge
predictability
 Appropriate design methods and EDA tools needed
 New generation of analysis and optimization algorithms
cover many mechanisms, nevertheless requires good
design practice
 Similar challenges in multi-core architectures
30