1April 2012
IP and Ethernet in Motor Vehicles
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 net-
work 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, seg-
mented 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 develop-
ment 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, two-
wire cable (unshielded twisted pair), and in the opinion of various
publications it is suitable for use in the motor vehicle [1], [2], [3].
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 develop-ment 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.
2
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 test-
ing 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 Ether-
net in the motor vehicle – how these measurement tasks present
themselves in product development departments from the perspec-
tive 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 hard-
ware 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 sec-
tions 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 Vid-
eo 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 soft-
ware, 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 mul-tiple points of the Eth-ernet network, ideally via “tee-couplers” with as little time offset as possible and with a common time base.
3April 2012
This is made possible by communication between the vehicle
and charging station over Ethernet on IP based protocols, in stan-
dardization defined in the ISO 15118 standard. The charging sta-
tion communicates with the grid and the vehicle here. For the sys-
tems 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 measure-
ment 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 calibra-
tion over XCP on Ethernet would also be very attractive in produc-
tion vehicles due to its significantly higher measurement data
rates.
5. WLAN and Car2x
Car2x is understood as the external communication between vehi-
cles and the infrastructure. Applications range from convenience
functions to traffic flow optimization and heightened traffic safety
according to the application. The “Audio/Video” and “Control Com-
munication” columns of Table 1 (based on [7] and Vector) show the
protocols used for AVB. There are also protocols for bandwidth res-
ervation 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 develop-
ment at the OEM must validate this service. Since an ECU is used as
the gateway, not only is there great interest in analyzing the trans-
mission 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.
Table 1: IP protocols of auto-motive applications mapped to the OSI reference model (left-side columns) includ-ing administrative functions (right-side columns): Both new protocols (red) and those known from office communica-tions (gray) are used.
4
Technical Article
(driver assistance systems). The technology is already in pre-pro-
duction 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 partici-
pants. The development tool must therefore support these IP-
based 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 measure-ment tool
Table 1 summarizes, by examples, the various application-depen-
dent 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 vehi-
cle. Ethernet in the office field is not the same as Ethernet in the
automotive field. The same applies to the specific Internet proto-
cols 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 data-
base 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 produc-
ers 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). Ideal-ly, all messages of all net-works are transmitted with a common time base.
5April 2012
Figure 3: CANoe.IP supports the development, simulation and testing of embedded systems that communi-cate over IP or Ethernet.
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 net-
worked over gateways will be found just as they now exist. Ethernet
and IP will simply be added. As in the case of the camera applica-
tion, new challenges will arise on all protocol levels in future IP
applications, yet it will be possible to overcome them with suitable
development tools.
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 devel-
opment 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 vari-
ety 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 estab-
lished 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
any network cards existing on a Windows computer. If BroadR-
Reach 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).
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] Nöbauer, 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.
6April 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] 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
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 belowVector Informatik GmbH, Stuttgart, Germany, www.vector.com
France, Belgium, Luxembourg Vector France, Paris, France, www.vector-france.com
Sweden, Denmark, Norway, Finland, IcelandVecScan AB, Göteborg, Sweden, www.vector-scandinavia.com
Great BritainVector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk
USA, Canada, MexicoVector CANtech, Inc., Detroit, USA, www.vector-cantech.com
JapanVector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp
KoreaVector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr
ChinaVector Automotive Technology Co., Ltd., www.vector-china.com
IndiaVector Informatik India Prv. Ltd., Pune, India, www.vector.in
E-Mail [email protected]
Hans-Werner Schaal, Vector studied Communications Engineering at the University of Stuttgart and Electrical & Com-puter Engineering at Oregon State University in Oregon, USA. Mr. Schaal is Business Devel-opment 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.
Figure 4: CANoe.IP with scalable hard-ware interfaces and optional real-time support