IP and Ethernet in Motor Vehicles

Challenges for the development tool, illustrated by todays 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
todays 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).

April 2012

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 Ethernets, 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].

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

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.

April 2012

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.

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 auto-
motive 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] Nbauer, J., Continental AG: Migration from MOST and FlexRay Based
Networks to Ethernet by Maintaining QoS. 1st Ethernet & IP @ Automo-
tive Technology Day, BMW, Munich, 2011.
[5] Powell, S. R., Broadcom Corporation: Ethernet Physical Layer Alterna-
tives 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.

April 2012

[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-vehicle networks.html.
[7] Vlker, L., BMW AG: One for all, Interoperability from AUTOSAR to
Genivi. 1st Ethernet & IP @ Automotive Technology Day, BMW,
Munich, 2011.

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.

Links:
Vector Solutions for IP and Ethernet:
www.vector.com/vi_ip_ethernet_solutions_en.html
Product information CANoe.IP:
www.vector.com/vi_canoe_ip_en.html

>> Your Contact:

Vectors know-how especially for Smart Charging:

www.vector.com/vi_electric_vehicles_en.html

Germany and all countries, not named below

Vector Informatik GmbH, Stuttgart, Germany, www.vector.com

AFDX is an Airbus registered trademark

France, Belgium, Luxembourg

Vector France, Paris, France, www.vector-france.com
Sweden, Denmark, Norway, Finland,Iceland
VecScan AB, Gteborg, 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

April 2012