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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, ...)

SymTA/S Screenshot

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

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

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

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

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

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

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

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

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