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 Contactinfo@vector.com

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