CAN Ethernet Gateway for Automotive

Applications
Mihai Postolache, Gabriel Neamtu, and Sorin Dumitru Trofin
Faculty of Automatic Control and Computer Engineering
Gheorghe Asachi Technical University of Iasi
Iasi, Romania
E-mail: mpostol@ac.tuiasi.ro
AbstractThis paper presents the design and practical
implementation of a gateway interface between two networks,
CAN and Ethernet. Data packets detected over a network will be
routed to the other network, with the possibility of using various
filters. Since there is no standard yet for this purpose, the paper
also proposes a method to pack one or more CAN messages in an
Ethernet frame. For testing purposes of the interface gateway
and its implementation a series of graphical software tools
running on a PC client have been developed. These tools are able
to send and decode messages using the specified packaging. At
the end of the paper a graphical application demonstrates the
functionality of the gateway implementation and the benefits of
the proposed CAN-Ethernet routing method.

A. Aim and objectives

The main goal of the work was to design and develop a
Ethernet-CAN gateway to be used in automotive applications.
Received CAN messages have to be issued on Ethernet, while
messages received from Ethernet should be visible on the CAN
bus. Due to different format and lengths of data frames
encountered on the two buses [4], a method of packing and
unpacking data had to be established. The usefulness of this
method and the advantages of the proposed solution are
demonstrated using a typical application.
Programming the electronic control unit hardware (ECU)
was done mainly in C, and the application and diagnostic tools
were developed in C# using the .NET Framework from
Microsoft. Also, the CAPL language was used for
programming the interface with the CAN bus.

Keywordsautomotive networks, gateway, embedded systems,

communication protocols.

I.

INTRODUCTION

The main advantage of such a device is that it provides

higher transfer rate inside the car, as well as during production
and service stages. The hardware required for communication
on CAN bus (Controller Area Network) was already
developed, and it was extended with an Ethernet bus interface.

In the automotive industry, as new machinery and system

architectures are added, the need for communication between
these systems increases. Also, there is a tendency to introduce
increasingly more entertainment devices: multimedia systems
and different devices with informative purpose, all of them
having a more complex graphical user interface (i.e. GPS
systems). These devices require relatively high data rates. The
main bus used in cars still is the Controller Area Network bus
(CAN) which does not support a communication rate greater
than 1 Mb/second, as it was not intended for high-traffic in a
peer-to-peer network like Ethernet.

B. Controller Area Network Protocol

The template is used to format your paper and style the text.
All margins, column widths, line spaces, and text fonts are
prescribed; please do not alter them. You may note
peculiarities. For example, the head margin in this template
measures proportionately more than is customary. This
measurement and others are deliberate, using specifications
that anticipate your paper as one part of the entire proceedings,
and not as an independent document. Please do not revise any
of the current designations. CAN protocol is ideal for the
automotive industry for several reasons. One of them would be
that it is a very safe protocol, using a significant number of
methods to detect errors. Also, allocating IDs provides a
priority order, with ID lowest value having the highest priority.
A modern car has around 70 ECUs, without taking into
consideration the many sensors and actuators that need to
communicate with each other.

A solution is already adopted in modern cars using FlexRay

[1], although the price limitations leads to the possibility of
replacing it with Ethernet, first by designing gateways between
the in-vehicle networks and Ethernet TCP/IP [2, 3]. In such an
approach, one of the major electronic control unit (ECU)
central sites is the gateway interface, which is the most
important point of communication between all major buses
inside the car. Today, a modern car is composed of multiple
communication buses (i.e. 6 separate CAN bus, 2 LIN bus, and
possibly FlexRay). The current trend is to include Ethernet
communication as a major thoroughfare, the main reason being
that it is a relatively cheap and very widespread bus that
supports higher transfer rates.

At the data link level, CAN protocol uses broadcast

communication to send messages so that all the nodes in the
network receive them simultaneously. A Collision Detection
Multiple Access / Bitwise Arbitration (CSMA/BA) scheme is

The work was technically supported by the Continental Automotive Iasi,

Romania.

978-1-4799-2228-4/13/$31.00 2013 IEEE

422

message filtering for isolating the traffic between the two

networks.

used to gain access to the two-wire bus via open collector

output transceivers, allowing a non-destructive conflict
resolution between the dominant (0) and recessive (1) bits
simultaneous transmitted. Each transceiver also listen for the
effective bus status, even while transmitting, and allows the
arbitration rule to detect a higher priority transmission and
therefore switch in the receive only mode.

II.

CAN ETHERNET GATEWAY DEVELOPMENT PROCESS

A. Hardware and Software Tools Used

The gateway interface was built on a development board
equipped with the MPC5515S Power PC processor [5], a 32bit, dual-core processor from Freescale integrated with 768 KB
Internal Flash program memory and 48 KB internal RAM data
memory on chip. The application used one of its 6 internal
CAN peripheral modules. Also, one of its 4 SPI ports is
connected to an external full-duplex, buffered (8KB) Ethernet
ENC28J60 chip [6].

The internal structure of CAN data frame is shown in (Fig.

1). It is a relatively short bit-oriented frame, starting with a
Start Of Frame (SOF) delimiter bit which is followed by a 12
or 32 bit identifier and arbitration field, depending on the frame
type used, standard or extended, respectively. A control field is
used mainly to specify the length of the next field, the data
field (0-8 bytes), followed by the CRC and Acknowledge fields
and terminated by the end delimiter of frame (EOF).

A CANCaseXL to USB debugging tool [7] was used for

interfacing a real CAN bus with a virtual one, developed in
CANoe. This module was very useful for viewing and
generating messages and also to simulate the presence and
behaviour of a real CAN network consisting of several virtual
CAN nodes. CANoe has its own programming language called
CAPL, as well as an IDE for developing graphical user
interfaces used to facilitate a simulation of a real in-vehicle
CAN network.

Fig. 1. Fig. 1. CAN data frame format

Messages in CAN networks are sent as one or more data

frames and do not carry any address of the destination node.
Receiving nodes have filters to decide the acceptance or
discarding of a received data frame.

The Freescale CodeWarrior Integrated Development

Environment was used to develop the firmware, and WinIDEA
was used with the iSystem IC3000 debugger connected through
a JTAG interface to the Power PC processor.

C. The Ethernet Network Protocol

Unlike CAN frames, Ethernet frames are much longer (up
to 1500 bytes of useful data) and are addressed to a specific
network node. The format of an Ethernet frame can be seen in
Fig. 2.

As monitoring software tools CANoe from Vector

Informatik GmbH was used to communicate with CANCaseXL
for interfacing the gateway to the CAN bus, while Wireshark
was used for viewing and analysing all the messages
circulating on the Ethernet cable, regardless of protocol.

The Medium Access Control (MAC) address is a 6-byte

field used to uniquely identify an Ethernet node. This address is
used to mark Ethernet packets: if the last bit of the most
significant byte is 0, then the destination is unicast type, used
as an indication that the recipient is a single device. Although
in the earlier stages of Ethernet several devices were connected
to the same Ethernet cable, with the risk of collision for their
packets, now all the Ethernet networks are point-to-point, so no
collisions can occur. In the payload field of the Ethernet frame
other headers will be added to the upper transport and network
protocols.

The firmware of the gateway interface was built on top of a

C/TCP-IP stack from Micrium running on the multitasking
operating system C/OS-II ported on the host processor.
B. Development of the CAN driver
Since the CAN communication is essential in the gateway
implementation, and because no ready-made set of functions
was available to ensure at least a minimum of functionality, the
CAN driver was built from scratch. The host processor has 6
CAN modules integrated on chip, each with 64 configurable
message buffers. A FIFO queue was implemented and used for
receiving the asynchronous messages. This queue is filled
inside the reception interrupt, and cleared when the user task
extracts the messages for analysis.

Thus, the large differences between the two types of

networks can be easily observed. At the beginning the routing
of all CAN messages on the Ethernet trunk was considered,
although in the end the developed CAN driver supports

Fig. 2. The Ethernet Frame

423

An init function use the input parameter which is the

address of the CAN module to be initialized and sets up its
general registers, installs interrupt handlers, and puts the CAN
module in the normal operation mode. It should be called
before any other CAN driver service call.
The bus speed setting function uses the address parameters
of the CAN module and sets up the new desired
communication speed in bits / second.
The filter setting function gets as input parameters the
address of the CAN module, an input vector containing filter
masks for the specified number of CAN buffers, and a boolean
value indicating if standard or extended CAN frames are
expected. It returns the number of message buffers successfully
configured. After calling this function, CAN messages
satisfying the filter condition will be received in the FIFO
queue and can be retrieved by user application tasks.

Fig. 4. CAN frame captured during CAN driver tests

The transmission function tries to use a message buffer

from the specified CAN module, in order to send a CAN frame
completely specified by its ID, a bit indicating whether the ID
is extended or not, the number of bytes of data and a pointer to
the memory area containing that data.
The interrupt handler is the piece of software that identifies
the message buffer that generated the interrupt and extracts its
message and fills in the FIFO queue.

C. TCP/IP Stack and Ethernet controller integration

The communication stack used C/TCP-IP is specially built
for easy integration in a multitasking environment such as the
operating system C/OS-II. The stack was adapted for use with
the ENC28J60 Ethernet controller using a set of functions for
NIC functionality based on the Ethernet controller driver via
SPI.

These are the basic functions that underpin the CAN driver.
In addition, a set of functions used for setting buffers to
automatically answer to remote frames was written.

A read command to an internal register of the Ethernet

controller, which returns the data read at 4 Mb/second SPI
clock speed is shown in Fig. 5.

However, these functions were not used yet because the

integrated CAN modules only allow automatic answering of
remote frames, and not their detection. Thus, they cannot be
transmitted over on Ethernet under the current hardware
configuration.

The software TCP/IP stack is needed as the standalone

Ethernet controller does not have an implementation of other
upper level OSI protocols in hardware. Since the gateway will
use the UDP and TCP transport protocols, which in turn use
other services (ICMP, ARP), TCP/IP stack implementation is
one of the most important part of the gateway application. The
integration of the Ethernet controller has been developed
through a set of functions for setting its Network Interface Card
functionality.

For testing purposes a CAN-CAN gateway was built and

tested, and the results can be seen in Fig. 3. CAN data frames
were of 8 bytes long, 4000 frames/second in one way, and
4000 frames/second in the other. Also, in Fig. 4 a capture of
CAN data frame transmission on the CAN bus during the CAN
driver tests is presented.

An interrupt handler notifies the TCP/IP stack when NIC

received a new packet or when a transmission operation just
finished.

Fig. 5. Testing communication via SPI to the Ethernet controller

Fig. 3. CAN to CAN gateway mode used for testing CAN

424

Standard
ID

ID LEN ID-MSB
1
4
3

Extended ID LEN
ID
1
4

unused
3

DATA

ID-LSB
8
unused
3

ID-MSB
5

ID-MID1
8

ID-MID2
8

DATA

ID-LSB
8

Fig. 6. Packing scheme of CAN messages

The transmit task on Ethernet is launched periodically and

extracts CAN messages arrived in the FIFO circular queue
from the CAN driver, wraps them using the method described
in Figure 3 and forwards the packed data on the Ethernet side
using TCP, UDP, or both, depending on the configuration of
the application. The polling rate of de FIFO queue may be
established at compile time and is calculated depending on the
CAN transmission rate so that the FIFO queue should never
overflow. Flowchart of the transmit task can be seen in Fig.8.

The read data packet function reads from the received data
buffer memory to download new packages, considering the
overcome of the memory buffer area and return to the base
address.
The send data packet function puts data to be sent in the
transmission memory buffer for the data packet to be sent.
Additional bytes representing transmission options are added
and the transmission is started.
D. Packing and unpacking CAN messages in Ethernet packets
Due to the large differences between packet sizes, schemes
for packing and unpacking several CAN messages in an
Ethernet packet have to be implemented [4], and the method
used is shown in Fig. 6.

Ethernet
Receive
Task

Receive Ethernet
packet

For example, a CAN message may take from 2 to 10 bytes

in the case of a standard ID, or from 5 to 13 bytes in the case of
extended ID. Several blocks of bytes structured as in Fig. 6
may be grouped together to form the Ethernet frame payload.
At reception one can easily detect how many bytes per message
are charged by analyzing the first byte of each structured
group. Thus, decoding the CAN messaged is not a problem.

Blocking
wait

E. The main function and routing tasks of the gateway

The last step was writing the main application and the
routing tasks. On the Ethernet side of the application sockets
programming was used for accessing TCP and UDP ports.

Yes

Buffer
empty?

Blocking
wait

No

Unpacking Ethernet
frame
Send CAN messages

Fig. 7. Ethernet Receive task

Ethernet
Transmit
Task

The main function initializes the CAN communication and

the operating system, creates the initialization task and starts
the operating system.

Blocking
wait

An initialization task is used to start up the TCP/IP stack.

This cannot be done from the main function because the
operating system has to be already turned on. After initializing
the stack, which includes initialization of SPI communication
and Ethernet controller NIC, the IP address of the gateway is
set to be used for all communication service later on. At
compile time a conditional compiling option decide if code is
generated for a TCP, UDP or both initialization function calls.
These functions create tasks for Ethernet packets transmission
and reception. In addition, TCP initialization function puts the
gateway to wait in an infinite loop for new connection requests
to occur.

Blocking
wait

Yes

FIFO
empty?

No

Packing CAN
messages
Send Ethernet packet

Fig. 8. Ethernet Transmit task

III.

TEST APPLICATION FOR IN-VEHICLE MONITORING,

DIAGNOSIS AND CONTROL

An application that makes use of the hardware and software

resources described previously was built in order to illustrate
the performance and facilities of the proposed CAN-Ethernet
interface. For this purpose a graphical tool was created in
CANoe that simulates the in-vehicle connection, diagnosis and
control (Fig. 9).

The receive task on the Ethernet side enters in an infinite

loop, waiting for incoming packets on the Ethernet side to
appear. When a packet is received successfully, it decodes and
forwards it on the CAN side, then resumes waiting. Flowchart
of the receive task can be seen in Fig. 7.

425

Fig. 9. In-vehicle connection, diagnosis and control using the CAN-Ethernet gateway

While the application (and thus the socket behind it) is

connected, it can send and receive messages to and from the
network car. When using TCP, the online/offline state is real,
with the guarantee that one can receive messages from the car.
When using UDP protocol, this does not apply because of its
non-connection oriented feature.

Since the implementation of the concept of a real car would

be too complex and expensive, a CANoe simulation created to
mimic communication taking place in a real car was used.
Messages from this virtual in-vehicle car are transmitted on a
real CAN bus to the actual gateway interface. The user will
connect to the simulated car using a graphical interface via
Ethernet (User Ethernet Gateway CAN Car), thus being
able to carry out specific tasks such as diagnosis, monitoring or
preset of specific parameters of the car network.

Thus, even if the application indicates that it is connected,

this only means that the internal socket listens for packages on
the selected port and it is ready to send packets on the same
port. It can thus try to send packets to a non-existent
destination, without being able to find out about that. However,
because a car reports different values at regular intervals, one
can still see whether or not a UDP link is active.

When the application program starts the necessary internal

variables are initialized with the default values required for a
proper connection to the gateway. Using the connection
parameters menu, these default values may be changed so that
the application can be connected to any IP and port specified
by user.

Any Ethernet packet received is first unpacked. After

unpacking one or more CAN messages will result. For each of
these messages the ID is checked. If the ID has a known value,
than the corresponding parameter is updated. If the received ID
is unknown, then it is passed in a separate window with
unrecognized IDs where they may be inspected and decoded
manually by the user.

First, the application must establish a connection to the

simulated car network. Depending on the protocol chosen, this
means to establish a TCP connection or to assign a port to the
UDP socket and start listening for messages on that port. User
can view the connection status in the lower left corner of the
main graphics window.

426

In a similar manner, there are two types of messages that

may be transmitted: with IDs that are meaningful or irrelevant
to the application. The first type of message will be sent
automatically with the appropriate ID when the user changes
values in the graphical controls of the application. The other
posts have to be set manually in a distinct window provided for
this purpose.
IV.

[2]

[3]

[4]

CONCLUSIONS AND FURTHER WORK

The proposed solution for CAN-Ethernet gateway has a

number of strengths with great potential for further
development due to its higher transfer rate, the low price, and
of multiple applications that become possible due to the large
spread of Ethernet. Practically any CAN network applications
can be redesigned to extend their functionality over an Ethernet
network. The application example presented in the previous
section is only as one of many possible applications that could
be implemented adding interactivity between the in-vehicle
CAN network and a TCP/IP client or to improve
manufacturing and testing processes.

[5]
[6]
[7]

Due to the much higher transfer rate all the in-vehicle CAN
buses may be simultaneously accessible from outside. Thus, a
diagnostic program designed to check each parameter of all
buses could be useful for both for service stations and even the
car owner through its personal laptop.
Applications to update the firmware are easy to implement,
thus avoiding recall a large number of vehicles in service
stations for software errors. Each manufacturer could make
available on their website the latest firmware, then each client
may download it and update its own car firmware.
One can include one or more internal Ethernet buses to
meet the need for larger packages and high transfer rates
required by new devices. This includes in particular
applications which are uncritical from the safety and reliability
point of view, but where the information flow is high, such as
in the area of information-entertainment (infotainment).
Further work will be done to improve the gateway
implementation using an Ethernet controller with TCP/IP
implemented in hardware so that the memory required by the
TCP/IP stack and the processing time of host controller with
the TCP/IP code execution to decrease.
Also, the gateway firmware may be improved to perform
routing in several CAN bus simultaneously. This is already
enabled in the actual software implementation, but was not
tested in our experiments due to the memory limitations.
One can also change the program to allow connections with
multiple sockets simultaneously and to include the PPPoE
protocols that make possible connection using routers.
Finally, use of communication protocols specific to web
pages could enable access to the CAN network via Internet,
using Ethernet cable or a Wi-Fi protocol.
REFERENCES
[1]

Jang, K., Park, I. Han, J. et al., Design framework for FlexRay network
parameter optimization, International Journal of Automotive
Technology, Vol. 12, issue 4, pp.589-597, 2011

427

Zinner, H., Noebauer, J., Gallner, T. et al., Application and realization

of gateways between conventional automotive and IP/Ethernet-based
networks, Proceedings of the 48th ACM/EDAC/IEEE Design
Automation Conference (DAC), pp. 1-6, 2011
Yu, H., Qin, G.H., Liu, Y., Chen, Y.H., Implementation of an IP-based
in-vehicle gateway, version 6, World Automation Congress
(WAC) Puerto Vallarta, Mexico City, 2012
Kern, A. Reinhard, D., Streichert, Th., Gateway strategies for
embedding of automotive CAN-frames into Ethernet-packets and vice
versa, 24th International Conference on Architecture of Computing
Systems, Milano, 2011, in Architecture Of Computing Systems - ARCS
2011, in Lecture Notes in Computer Science, Volume 6566, pp. 259270, 2011
MPC5510 Reference Manual, Freescale Semiconductor, 2012
ENC28J60 Data Sheet Stand-Alone Ethernet Controller with SPI
Interface, Microchip, 2004
Vector Informatik GmbH, CANcaseXL/log Manual, 2013.