2. Automotive Software Integration
Razvan Racu, Arne Hamann, Rolf Ernst
Technical University of Braunschweig
Kai Richter

3. Outline Software Integration and AUTOSAR AUTOSAR and System Timing
AUTomotive Open System Architecture
AUTOSAR and System Timing
System-level Timing Analysis
Examples
Conclusion

4. Automotive Integration Challenges
Complexity
Hundreds of functions
50+ ECUs
Networked control
Many suppliers
Heterogeneous
Integration challenges are key
Risks: reliability, quality, liability
Meeting target SOP
Development and production cost
55 ECUs & 7 Buses of 4 types with Gateways
source: Daimler-Chrysler

5. 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

6. Source: www.autosar.org: Status Oct. 2005
AUTOSAR Consortium
Source: Status Oct. 2005

7. Source: www.autosar.org
AUTOSAR Methodology
Source:
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

8. 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

9. SW Components and Runnables
atomic components with respect to mapping
provided by one supplier
Runnables
atomic components with respect to execution
attached to different OS Tasks
BSW
RTE
Sensor SWC
SW-C 1
runnableA
runnableB
runnableC

10. Outline Software Integration and AUTOSAR AUTOSAR and System Timing
AUTomotive Open System Architecture
AUTOSAR and System Timing
System-level Timing Analysis
Examples
Conclusion

11. Timing Data Required Response times Load data Performance „slack“
for networked control
Load data
static and transient
to determine buffer sizes and potential message losses
Performance „slack“
potential for later extensions

12. Timing is Critical Everywhere
Requirements
Requirements Test
Architecture
Exploration
System- Timing
Verification
System Design
System Test
Network Timing Estimation
Network Timing Verification
Module Design
Module Test
ECU Timing Estimation
ECU Timing Verification
Function Design
Function Test

13. SW Component Execution
Standardized RTE eases compiling & linking together several SW components from different teams/vendors
Vehicle Function
Actuator
Actuator SWC
SWC1
Sensor
SWC
SWC-1
BSW
RTE
Sensor SWC
Signal Path / Data Flow

14. Timing Chains and Hand-Over Points
Actuator
Actuator SWC
SWC1
Sensor
SWC
INTER-ECU
comm.
INTRA-ECU
comm.
Sensor
I/O
Sensor SWC
CAN
SWC1
RTE
Actuator
SWC
I/O
Actuator
I/O
BSW
RTE
RTE
BSW
BSW
RTE
BSW
RTE
HOPs
timing chain segments
end-to-end timing chain

15. Runnables and Tasks
SW architecture example: 2 SW components, 6 runnables
ECU 1
SW-C2
runnableZ
BSW
RTE
SW-C 1
runnableA
runnableB
runnableC
runnableX
runnableY
Schedule and timing dependencies OS
runnableZ OS
runnableZ OS
runnableX
runnableC
runnableB
runn ableA
runnableY

16. 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

17. Outline Software Integration and AUTOSAR AUTOSAR and System Timing
AUTomotive Open System Architecture
AUTOSAR and System Timing
System-level Timing Analysis
Examples
Conclusion

18. Timing Analysis Hierarchy
ECU1
ECU2
gateway 2
global system timing
ECU3
ECU4
gateway 1
ECU5
ECU6
ECU 1
SW-C2
SW-C 1
runnableY
runnableA
single component or
network channel
timing
runnableB
runnableX
runnableC
runnableZ
runnable
single process timing

19. Compositional Analysis
ECU 1
ECU 2 R2 R3 R1 R4
environment model
local analysis
Subsystems coupled by streams
parameterized streams
event curves (network calculus)
Coupling corresponds to event propagation
Solve fix point problem
Tools available, e.g. SymTA/S, MPA
derive output event model
map to input event model
until convergence or non- schedulability

20. Tool SymTA/S
evolutionary algorithm
incremental/interactive
multidimensional
robustness metrics
search problem
Optimization
(Exploration)
Sensitivity
analysis
formal
compositional
analysis
Used by several automotive companies for automotive systems optimization (incl. robustness optimization, planning of upgrades, ...)

21. SymTA/S Screenshot

22. 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

23. Outline Software Integration and AUTOSAR AUTOSAR and System Timing
AUTomotive Open System Architecture
AUTOSAR and System Timing
System-level Timing Analysis
Examples
Conclusion

24. Ex 1: Network Analysis Gateway time table Msg1 Msg2 CAN 1 MO1 Msgn
bus IF
host IF
bus IF
MO2
bus IF
buffer
host IF
Gateway
bus IF

25. Priority Queue vs. FIFO in CAN Networks
Buffering strategy (inside ECU) has huge influence on network timing
Shared FIFO Buffer undermines the CAN protocol's priority scheme
Shared priority ordered buffer
high
priority
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

26. 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

27. European OEM Example Classical response time analysis
Realistic response time analysis
with offsets
Resp time analysis
with optimized offsets

28. Sensitivity Analysis Problem: uncertain or undefined input data
SymTA/S: sensitivity analysis of system properties
Result: available headroom in design
Frame 1
Frame 2
Frame 3
Frame 4
Frame 5
Frame 6
Frame 7
Frame 8
Frame 11
Frame 10
Frame 9
Communication time
Initial
Maximum
Communication rate
Initial
Minimum
Frame 1
Frame 2
Frame 3
Frame 4
Frame 5
Frame 6

29. Outline Software Integration and AUTOSAR AUTOSAR and System Timing
AUTomotive Open System Architecture
AUTOSAR and System Timing
System-level Timing Analysis
Examples
Conclusion

30. Conclusion
Automotive software standards improve modularity, re-use, 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