IP and Ethernet in Motor Vehicles

IP and Ethernet in Motor Vehicles Challenges for the development tool, illustrated by today s applications Until just a few years ago, the prevailing opinion was that Ethernet would never be used for in-vehicle applications, with the exception of diagnostic access. Soon, however, camera-based driver assistance systems will be the first applications to utilize Ethernet technology as a system network. This presents new challenges to automotive OEMs, suppliers and development tool producers, because the Internet Protocol and Ethernet represent a new network technology for motor vehicles. Nonetheless, many of the issues can already be solved. After the debut of the CAN bus in the Mercedes S-Class in 1991, the LIN, MOST and FlexRay bus systems also became established in the motor vehicle. Today, CAN continues to be used in automotive network architectures in all domains (from powertrain to body). LIN bus technology is ideal for simple and cost-effective data exchange of noncritical signals in the convenience area. Where bandwidths and real-time requirements run into limitations, CAN is replaced by FlexRay or MOST in cases where it is economically justifiable. In today s vehicles, one often finds all of the named bus systems, segmented and networked via gateways. Motivation for Ethernet Ethernet has long been an established standard technology in office communications, industrial engineering (ODVA standards, Ethernet/IP and ProfiNet) and in the aerospace industry (AFDX ). In the automotive field, Ethernet had already proven itself in the vehicle for diagnostic access. In recent years, other use areas have increasingly been discussed in automotive research and development departments, because Ethernet s, scalable bandwidth and flexibility spoke strongly in its favor. Nonetheless, a suitable and economical wiring technology was lacking for the motor vehicle. Currently, the main drivers for Ethernet usage in the vehicle are camera-based driver assistance systems. In camera applications in the vehicle, LVDS technology (Low Voltage Differential Signaling) has been used until now. The shielded cable that is generally used there does indeed assure electromagnetic compatibility, but it is expensive by industry measures, and it is very impractical to install in the motor vehicle. Most recently, a physical layer is available that offers full-duplex transmission at 100 Mbit/s on a CAN-like, twowire cable (unshielded twisted pair), and in the opinion of various publications it is suitable for use in the motor vehicle [1], [2], [3]. 1

Technical Article Requirements of an IP development tool First, known requirements of previous bus systems still apply to the development tool. Initially, what is required is a detailed protocol analysis with stimulation option that extends to script-based testing with automatic generation of test reports. The user also expects that the market-proven multibus capability will of course be extended to include Ethernet and IP, so that dependencies between events on different bus systems can be studied. Currently, for example, there is interest in correlation between LIN and CAN, and in the future interest will be between CAN and IP. As previously, in protocol analysis the user needs easy symbolic access to all relevant application signals as well as the ability to further process them in any desired way logically and graphically. However, there will also be new requirements, which on the one hand are imposed by the bus physics and on the other by the wide variety of IP protocols. The article explains based on the current camera example and four other application areas of IP and Ethernet in the motor vehicle how these measurement tasks present themselves in product development departments from the perspective of the system manager, and which special requirements result for the development tool. 1. Camera Ethernet as system network A camera-based driver assistance system at BMW will be the first production implementation in the motor vehicle to utilize IP and Ethernet as the system network in the vehicle [1]. OEMs and suppliers will use the new BroadR-Reach physical layer to save on weight and costs compared to currently used LVDS technology [1], [4], [5]. BroadR-Reach will be licensed by other producers [6]. An example of a camera system network is shown in Figure 1 together with potential measurement points. As an alternative, it would also be possible to connect all cameras directly via a switch. As in bus systems used so far in the motor vehicle, the data traffic must be observed, analyzed and compared time-synchronously at various points in the network. Therefore, the measurement hardware must initially support the current bus physics (e.g. BroadR- Reach), but must also be open to future physical layers. Desirable are multi-channel taps via tee-couplers, which disturb the system network as little as possible in monitoring. The tee-coupler should also be capable of injecting errors to validate system functionality. Beyond analysis tasks, stimulation or even simulation of entire sections of the network is also required (remaining bus simulation). This poses certain challenges on the measurement hardware. In the camera application, there are heightened requirements related to time synchronization and Quality of Service (QoS) [4]. They should be addressed by protocol extensions of the Audio Video Bridging standard (AVB) [7]. Now that manufacturers have appeared to reach agreement on the bit transmission layer (OSI Layer 1), standardization is being sought in higher layers as well for cost and testing reasons. If only because of the different protocols used in the camera application, there are new requirements for the measurement software, so that any desired signals from the payload of the various, some quite complex, protocols can be presented and manipulated Figure 1: Reliable analysis of camera-based driver assistance systems requires monitoring the data traffic at multiple points of the Ethernet network, ideally via tee-couplers with as little time offset as possible and with a common time base. 2

according to the application. The Audio/Video and Control Communication columns of Table 1 (based on [7] and Vector) show the protocols used for AVB. There are also protocols for bandwidth reservation and other network management protocols (Table 1, four columns on the right). These and other protocols listed in the table were added based on the application cases considered below. 2. Diagnostic access Using Diagnostics over IP (DoIP) technology, it is possible to centrally flash all ECUs connected to the various bus systems via high-performance Ethernet access (Figure 2). System development at the OEM must validate this service. Since an ECU is used as the gateway, not only is there great interest in analyzing the transmission of diagnostic data in the various connected bus systems, but on the IP side as well. Relevant protocols are ISO 13400 and IPv4, and possibly IPv6 as represented in Table 1. 3. Electric refueling station Smart Charging Smart Charging goes far beyond simply plugging into a household electrical outlet. The electric vehicle to be charged is connected to the electrical grid via a charging station. Charging processes do not simply start up; first, the need to charge is communicated. Delaying individual charging processes by fractions of a minute can avoid overloads of the grid. The connected vehicles can also be used as storage media, and electrical provider billing can be automated. This is made possible by communication between the vehicle and charging station over Ethernet on IP based protocols, in standardization defined in the ISO 15118 standard. The charging station communicates with the grid and the vehicle here. For the systems manager at the automotive OEM, communication between the car and the charging station is quite important. A detailed analysis and validation of the protocols is absolutely essential to safeguard the charging process. The development tool must also support these protocols (Table 1, Smart Grid column). 4. Calibration, debugging, flashing For many years now, Ethernet has been used with the XCP measurement and calibration protocol to calibrate, debug and flash ECUs in development. However, Ethernet access is no longer provided in the production vehicle for cost reasons. Therefore, calibration and reprogramming are currently performed using the existing working protocol (e.g. CCP or XCP on CAN). However, if Ethernet makes its way into the vehicle in the near future, measurement and calibration over XCP on Ethernet would also be very attractive in production vehicles due to its significantly higher measurement data rates. 5. WLAN and Car2x Car2x is understood as the external communication between vehicles and the infrastructure. Applications range from convenience functions to traffic flow optimization and heightened traffic safety Table 1: IP protocols of automotive applications mapped to the OSI reference model (leftside columns) including administrative functions (right-side columns): Both new protocols (red) and those known from office communications (gray) are used. 3

Technical Article (driver assistance systems). The technology is already in pre-production development, and standardization is quite advanced. It is IP-based, and the IEEE 802.11p standard is used as the physical layer. From the perspective of the systems manager measurement technology interest in Car2x applications extends to beyond the boundary of the individual vehicle to a number of other vehicles and RSUs (Roadside Units) in the near environment. The ECU to be evaluated not only communicates with bus systems located in the vehicle, but also over the air interface with other traffic participants. The development tool must therefore support these IPbased standards as well. In addition, other requirements arise in the high-frequency range (WLAN in the 5 GHz band). New variety of protocols for applications and measurement tool Table 1 summarizes, by examples, the various application-dependent transmission layers and protocols, which the development tool must support simply based on cases occurring so far. Some of the protocols used in the area of office communications are found here, while many others may be omitted, and certain others are added. The table shows in light gray those protocols that can be adopted from office communications. Those added due to the new automotive application are shown in red. The measurement system has the task of resolving all relevant protocols and placing all network events in a causal relationship (correct sequence). Here it is desirable to be able to represent all bus domains with a common time base and with sufficient precision. Validation of IP production projects As the evaluation of the above application cases demonstrates, causality or even time analysis extending over multiple bus systems make it difficult to impossible to utilize standard Ethernet tools from office communications for multi-bus applications in the vehicle. Ethernet in the office field is not the same as Ethernet in the automotive field. The same applies to the specific Internet protocols that are used. They differ in type and complexity, depending on the application as significantly as the requirements of the physical layer differ. A suitable engineering format is important in representing the signal structure of the protocols in the development tool and in generating the embedded code. DBC format is the commonly used engineering format for CAN, while FIBEX is commonly used for FlexRay. However, the DBC format is no longer adequate as a database format for the new Ethernet and IP based system network. From the perspective of tool suppliers, it would be helpful if OEMs could agree on a common engineering format. Suitable candidates would be FIBEX 4.0 and AUTOSAR System Description formats. Experience from other industrial fields indicates that tool producers would provide suitable development tools for analysis and code generation soon thereafter. Outlook for vehicle networks In-vehicle use of CAN is expected to continue much longer than ten years into the future, while all of the other bus systems discussed here will be used for at least ten years. Nonetheless, applications Figure 2: In validation of DoIP at a gateway, it is important to represent the data traffic both on the DoIP side (to left of the gateway) and on all connected bus systems (to right of the gateway). Ideally, all messages of all networks are transmitted with a common time base. 4

will increasingly tend towards the use of IP and Ethernet due to growing requirements with regard to bandwidth, flexibility and cost-effectiveness. In upcoming years, multiple bus systems networked over gateways will be found just as they now exist. Ethernet and IP will simply be added. As in the case of the camera application, new challenges will arise on all protocol levels in future IP applications, yet it will be possible to overcome them with suitable development tools. any network cards existing on a Windows computer. If BroadRReach is used, or if it should also be possible to inject errors, then in the future a device of the new VN56xx product line could be used as a hardware interface (Case 2). This significantly improves time synchronism between the IP channels and with other bus systems. If real-time behavior is required, CANoe.IP could be operated together with the real-time hardware VN8900 in the future, which of course works seamlessly with the VN56xx interface hardware (Case 3). Outlook for IP development tools In the automotive field, development tools conceptualized for IP continue to be advisable. On the one hand, they must support all protocol levels, but on the other they must also fit into the typical industry tool landscape. Suppliers are especially called upon to provide suitable development tools for validation of product development projects at the OEM. Naturally, this includes support and ideally tool producer assistance product introduction as well. Today, Option IP, which is based on the proven CANoe simulation and test tool from Vector Informatik, already covers the described requirements for an Ethernet development tool. With its wide variety of Ethernet-specific functions and multibus capability, CANoe.IP can help to reduce development time, allowing valuable resources to be used more effectively on the application side (Figure 3). CANoe.IP for automotive network development offers the same development convenience as is already the standard for the established CAN, LIN, MOST and FlexRay bus systems. The development tool exhibits a high degree of scalability and basically offers three interface options (Figure 4). In the simplest Case 1, it works with Translation of a German publication in Elektronik automotive, 4/2012 Literature: [1] Bogenberger, R., BMW AG: IP & Ethernet as potential mainstream automotive technologies. Product Day Hanser Automotive. Fellbach, 2011. [2] Neff, A., Matheeus, K, et al.: Ethernet & IP as application vehicle bus in use scenario of camera-based driver assistance systems [German lecture]. VDI Reports 2132, Electronics in the motor vehicle. Baden-Baden, 2011. pp. 491-495. [3] Streichert, T., Daimler AG: Short and Longterm Perspective of Ethernet for Vehicle-internal Communications. 1st Ethernet & IP @ Automotive Technology Day, BMW, Munich, 2011. [4] Nöbauer, J., Continental AG: Migration from MOST and FlexRay Based Networks to Ethernet by Maintaining QoS. 1st Ethernet & IP @ Automotive Technology Day, BMW, Munich, 2011. [5] Powell, S. R., Broadcom Corporation: Ethernet Physical Layer Alternatives for Automotive Applications. 1st Ethernet & IP @ Automotive Technology Day, BMW, Munich, 2011. Figure 3: CANoe.IP supports the development, simulation and testing of embedded systems that communicate over IP or Ethernet. 5

[6] NXP Develops Automotive Ethernet Transceivers for In-Vehicle Networks November 09, 2011, www.nxp.com/news/press-releases/2011/11/ nxp-develops-automotive-ethernet-transceivers-for-in-vehiclenetworks.html. [7] Völker, L., BMW AG: One for all, Interoperability from AUTOSAR to Genivi. 1st Ethernet & IP @ Automotive Technology Day, BMW, Munich, 2011. Links: Vector Solutions for IP and Ethernet: www.vector.com/vi_ip_ethernet_solutions_en.html Hans-Werner Schaal, Vector studied Communications Engineering at the University of Stuttgart and Electrical & Computer Engineering at Oregon State University in Oregon, USA. Mr. Schaal is Business Development Manager for the Open Networking product line at Vector Informatik GmbH. Previously, he worked in various industries as development engineer, project leader and product manager in the test tools area for several network technologies. Product information CANoe.IP: www.vector.com/vi_canoe_ip_en.html Vector s know-how especially for Smart Charging: www.vector.com/vi_electric_vehicles_en.html AFDX is an Airbus registered trademark >> Your Contact: Germany and all countries, not named below Vector Informatik GmbH, Stuttgart, Germany, www.vector.com France, Belgium, Luxembourg Vector France, Paris, France, www.vector-france.com Sweden, Denmark, Norway, Finland, Iceland VecScan AB, Göteborg, Sweden, www.vector-scandinavia.com Great Britain Vector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk USA, Canada, Mexico Vector CANtech, Inc., Detroit, USA, www.vector-cantech.com Japan Vector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp Korea Vector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr China Vector Automotive Technology Co., Ltd., www.vector-china.com India Vector Informatik India Prv. Ltd., Pune, India, www.vector.in E-Mail Contact info@vector.com Figure 4: CANoe.IP with scalable hardware interfaces and optional real-time support 6