Automotive Networks Are New Busses and Gateways the Answer or Just Another Challenge? ESWEEK Panel Oct. 3, 2007

Transcription

1 Automotive Networks Are New Busses and Gateways the Answer or Just Another Challenge? ESWEEK Panel Oct. 3, 2007

2 Automotive Networks complex networks hundreds of functions 50+ ECUs (Electronic Control Unit) networked functions many suppliers 55 ECUs & 7 Buses with Gateways source DaimlerChrysler heterogeneous why is this so complicated? R. Ernst, TU Braunschweig 2

3 Network is subject to diverging requirements communication periodic communication (control engineering) event triggered communication data rates from few kbit/s to > 10Mbit/s (entertainment) real-time guaranteed throughput max. end-to-end latencies safety different safety levels entertainment comfort function active front steering x-by-wire source BMW defined by SIL levels - IEC (automotive ISO26262) R. Ernst, TU Braunschweig 3

4 cost Network is subject to different cost targets different volumes few thousand to several million cars cost of model updates and special model editions different cost budgets feature dependent - engine controller interior light safety level dependent different price/performance high end feature (luxury) commodity feature (low end) R. Ernst, TU Braunschweig 4

5 Wide scope of technical solutions in one network CAN the traditional bus, defined in 1983, still dominant today packet based, variable frame length CSMA/CD, static priority arbitration ranges from 125kbit/s up to 1Mbit/s (ISO ) FlexRay covers wide range of communication requirements, upcoming two parts: static segment using TDMA based protocol, fixed slot assignment dynamic segment with prioritization 10 Mbit/s, higher cost than CAN, used in first cars (BMW) LIN - low cost, single wire, single master, up to 20kbit/s, round-robin, power ctrl. MOST optical ring bus, 24Mbit/s R. Ernst, TU Braunschweig 5

6 CAN Bus applications low-speed: typically body electronics high-speed: typically powertrain, chassis LIN: typically for simpler peripheral ECUs, e.g. door (central locking, power window ) MOST: for multimedia applications in high-end cars (in mid-priced cars, CAN is used also for media traffic) FlexRay: to replace high-speed CAN when 500kBit/s not enough + for safety-critical applications + as backbone R. Ernst, TU Braunschweig 6

7 Typical network today component and function sharing needs bus coupling example: wheel rotation sensor CAN ECU4 ECU 5 diagnosis Central Gateway ECU 3 ECU 1 ECU 2 MOST CAN GW ECU LIN ECU 6 ECU 7 R. Ernst, TU Braunschweig 7

8 Network topology evolution timing, cost, function increasingly difficult alternative topologies investigated ECU7 CAN 2 ECU 8 Serial line FlexRay Backbone? Gateway DCU1 DCU2 DCU3 ECU 3 ECU 6 ECU9 ECU 2 ECU1 ECU 5 ECU4 ECU 10 ECU 11 CAN 1 FlexRay CAN 3 LIN? LSCAN???? R. Ernst, TU Braunschweig 8

9 Network influenced by design process organizational structure OEM defines bus topology and physical constraints supplier defines ECUs (clients) and subnets protocol parameters by contract design process network is defined early in the design process network planning cannot be based on executable code must consider tradeoff individual car product line (platform) must consider legacy functions function integration and network verification need verifiable specifications efficient methods and tools R. Ernst, TU Braunschweig 9

10 The V process model Requirements Requirements Test System Design System Test Module Design Module Test Function Design Function Test R. Ernst, TU Braunschweig 10

11 Software different application models periodic execution automata based, event driven models diagnosis software (C programs) no coherent model on the application language level commercial tools e.g. Matlab/Simulink manually optimized combined with generated code code from multiple sources (OEM, supplier, 3rd party) growing efforts to find common run-time environment AUTOSAR R. Ernst, TU Braunschweig 11

12 AUTOSAR Methodology SW-Components (SW-C) encapsulate the applications Source: Virtual Functional Bus (VFB) communication mechanisms interface to Basic SW Runtime Environment (RTE) VFB implementation on a specific ECU Basic Software (BSW) infrastructural functionality on an ECU R. Ernst, TU Braunschweig 12

13 Communication and timing chains in AUTOSAR or or SWC SWC1 Actuator SWC Actuator INTER-ECU comm. INTRA-ECU comm. or I/O BSW RTE or SWC RTE BSW CAN BSW RTE SWC1 RTE Actuator SWC I/O I/O BSW RTE Actuator HOPs AUTOSAR has an important influence on the network what will be the impact on network design? Currently, AUTOSAR has no coherent timing model ongoing projects (e.g. TIMMO) will AUTOSAR entail a corresponding network initiative? R. Ernst, TU Braunschweig 13

14 The panel Industry Bernd Hedenetz, DaimlerChrysler AG, Germany Gernot Spiegelberg, Siemens VDO Automotive AG, Germany Marek Jersak, Symtavision GmbH, Germany Academia Hermann Kopetz, TU Wien, Austria Alberto Sangiovanni-Vincentelli, UC Berkeley, USA Introduction & Moderation Rolf Ernst, TU Braunschweig, Germany R. Ernst, TU Braunschweig 14

15 Some questions are the current protocols, architectures, design methods, and tools appropriate? What innovations are most urgently needed? who shall develop the networks in the future, the OEM or a 1st tier supplier? What would be the consequence for the design process? Do we need interoperable network service standards, e.g. as a complement to AUTOSAR? Will there be a unified automotive internet protocol that eventually dominates all communication in a car? How will future car-to-car communication be included in the automotive network strategy if it shall be used for real-time applications, such as in driver assistance systems? R. Ernst, TU Braunschweig 15