8/10/2019 06688995.pdf

1/6

422

CAN Ethernet Gateway for AutomotiveApplications

Mihai Postolache, Gabriel Neamtu, and Sorin Dumitru TrofinFaculty of Automatic Control and Computer Engineering

Gheorghe Asachi Technical University of IasiIasi, Romania

E-mail: mpostol@ac.tuiasi.ro

Abstract This paper presents the design and practicalimplementation of a gateway interface between two networks,CAN and Ethernet. Data packets detected over a network will berouted to the other network, with the possibility of using variousfilters. Since there is no standard yet for this purpose, the paperalso proposes a method to pack one or more CAN messages in an

Ethernet frame. For testing purposes of the interface gatewayand its implementation a series of graphical software toolsrunning on a PC client have been developed. These tools are ableto send and decode messages using the specified packaging. Atthe end of the paper a graphical application demonstrates thefunctionality of the gateway implementation and the benefits ofthe proposed CAN-Ethernet routing method.

Keywordsautomotive networks, gateway, embedded systems,communication protocols.

I. I NTRODUCTION In the automotive industry, as new machinery and system

architectures are added, the need for communication betweenthese systems increases. Also, there is a tendency to introduceincreasingly more entertainment devices: multimedia systemsand different devices with informative purpose, all of themhaving a more complex graphical user interface (i.e. GPSsystems). These devices require relatively high data rates. Themain bus used in cars still is the Controller Area Network bus(CAN) which does not support a communication rate greaterthan 1 Mb/second, as it was not intended for high-traffic in a

peer-to-peer network like Ethernet.

A solution is already adopted in modern cars using FlexRay[1], although the price limitations leads to the possibility ofreplacing it with Ethernet, first by designing gateways betweenthe in-vehicle networks and Ethernet TCP/IP [2, 3]. In such anapproach, one of the major electronic control unit (ECU)central sites is the gateway interface, which is the mostimportant point of communication between all major busesinside the car. Today, a modern car is composed of multiplecommunication buses (i.e. 6 separate CAN bus, 2 LIN bus, and

possibly FlexRay). The current trend is to include Ethernetcommunication as a major thoroughfare, the main reason beingthat it is a relatively cheap and very widespread bus thatsupports higher transfer rates.

The work was technically supported by the Continental Automotive Iasi,Romania.

A. Aim and objectivesThe 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, whilemessages received from Ethernet should be visible on the CAN

bus. Due to different format and lengths of data framesencountered on the two buses [4], a method of packing andunpacking data had to be established. The usefulness of thismethod and the advantages of the proposed solution aredemonstrated using a typical application.

Programming the electronic control unit hardware (ECU)was done mainly in C, and the application and diagnostic toolswere developed in C# using the .NET Framework fromMicrosoft. Also, the CAPL language was used for

programming the interface with the CAN bus.

The main advantage of such a device is that it provideshigher transfer rate inside the car, as well as during production

and service stages. The hardware required for communicationon CAN bus (Controller Area Network) was alreadydeveloped, and it was extended with an Ethernet bus interface.

B. Controller Area Network ProtocolThe 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 templatemeasures proportionately more than is customary. Thismeasurement and others are deliberate, using specificationsthat anticipate your paper as one part of the entire proceedings,and not as an independent document. Please do not revise anyof the current designations. CAN protocol is ideal for theautomotive industry for several reasons. One of them would bethat it is a very safe protocol, using a significant number ofmethods 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 intoconsideration the many sensors and actuators that need tocommunicate with each other.

At the data link level, CAN protocol uses broadcastcommunication to send messages so that all the nodes in thenetwork receive them simultaneously. A Collision DetectionMultiple Access / Bitwise Arbitration (CSMA/BA) scheme is

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

8/10/2019 06688995.pdf

2/6

423

used to gain access to the two-wire bus via open collectoroutput transceivers, allowing a non-destructive conflictresolution between the dominant (0) and recessive (1) bitssimultaneous transmitted. Each transceiver also listen for theeffective bus status, even while transmitting, and allows thearbitration rule to detect a higher priority transmission andtherefore switch in the receive only mode.

The internal structure of CAN data frame is shown in (Fig.1). It is a relatively short bit-oriented frame, starting with aStart Of Frame (SOF) delimiter bit which is followed by a 12or 32 bit identifier and arbitration field, depending on the frametype used, standard or extended, respectively. A control field isused mainly to specify the length of the next field, the datafield (0-8 bytes), followed by the CRC and Acknowledge fieldsand terminated by the end delimiter of frame (EOF).

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

Messages in CAN networks are sent as one or more dataframes and do not carry any address of the destination node.Receiving nodes have filters to decide the acceptance ordiscarding of a received data frame.

C. The Ethernet Network ProtocolUnlike CAN frames, Ethernet frames are much longer (up

to 1500 bytes of useful data) and are addressed to a specificnetwork node. The format of an Ethernet frame can be seen inFig. 2.

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

field used to uniquely identify an Ethernet node. This address isused to mark Ethernet packets: if the last bit of the mostsignificant byte is 0, then the destination is unicast type, usedas an indication that the recipient is a single device. Althoughin the earlier stages of Ethernet several devices were connectedto the same Ethernet cable, with the risk of collision for their

packets, now all the Ethernet networks are point-to-point, so nocollisions can occur. In the payload field of the Ethernet frameother headers will be added to the upper transport and network

protocols.

Thus, the large differences between the two types ofnetworks can be easily observed. At the beginning the routingof all CAN messages on the Ethernet trunk was considered,

although in the end the developed CAN driver supports

message filtering for isolating the traffic between the twonetworks.

II. CAN ETHERNET GATEWAY DEVELOPMENT PROCESS

A. Hardware and Software Tools UsedThe gateway interface was built on a development board

equipped with the MPC5515S Power PC processor [5], a 32- bit, dual-core processor from Freescale integrated with 768 KBInternal Flash program memory and 48 KB internal RAM datamemory on chip. The application used one of its 6 internalCAN peripheral modules. Also, one of its 4 SPI ports isconnected to an external full-duplex, buffered (8KB) EthernetENC28J60 chip [6].

A CANCaseXL to USB debugging tool [7] was used forinterfacing a real CAN bus with a virtual one, developed inCANoe. This module was very useful for viewing andgenerating messages and also to simulate the presence and

behaviour of a real CAN network consisting of several virtualCAN nodes. CANoe has its own programming language calledCAPL, as well as an IDE for developing graphical userinterfaces used to facilitate a simulation of a real in-vehicleCAN network.

The Freescale CodeWarrior Integrated DevelopmentEnvironment was used to develop the firmware, and WinIDEAwas used with the iSystem IC3000 debugger connected througha JTAG interface to the Power PC processor.

As monitoring software tools CANoe from VectorInformatik GmbH was used to communicate with CANCaseXLfor interfacing the gateway to the CAN bus, while Wiresharkwas used for viewing and analysing all the messagescirculating on the Ethernet cable, regardless of protocol.

The firmware of the gateway interface was built on top of aC/TCP-IP stack from Micrium running on the multitaskingoperating system C/OS-II ported on the host processor.

B. Development of the CAN driverSince the CAN communication is essential in the gateway

implementation, and because no ready-made set of functionswas available to ensure at least a minimum of functionality, theCAN driver was built from scratch. The host processor has 6CAN modules integrated on chip, each with 64 configurablemessage buffers. A FIFO queue was implemented and used forreceiving the asynchronous messages. This queue is filledinside the reception interrupt, and cleared when the user taskextracts the messages for analysis.

Fig. 2. The Ethernet Frame

8/10/2019 06688995.pdf

3/6

8/10/2019 06688995.pdf

4/6

425

Fig. 6. Packing scheme of CAN messages

The read data packet function reads from the received data buffer memory to download new packages, considering theovercome of the memory buffer area and return to the baseaddress.

The send data packet function puts data to be sent in thetransmission memory buffer for the data packet to be sent.Additional bytes representing transmission options are addedand the transmission is started.

D. Packing and unpacking CAN messages in Ethernet packets

Due to the large differences between packet sizes, schemesfor packing and unpacking several CAN messages in anEthernet packet have to be implemented [4], and the methodused is shown in Fig. 6.

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

E. The main function and routing tasks of the gateway

The last step was writing the main application and therouting tasks. On the Ethernet side of the application sockets

programming was used for accessing TCP and UDP ports.

The main function initializes the CAN communication andthe operating system, creates the initialization task and startsthe operating system.

An initialization task is used to start up the TCP/IP stack.This cannot be done from the main function because theoperating system has to be already turned on. After initializingthe stack, which includes initialization of SPI communicationand Ethernet controller NIC, the IP address of the gateway isset to be used for all communication service later on. At

compile time a conditional compiling option decide if code isgenerated for a TCP, UDP or both initialization function calls.These functions create tasks for Ethernet packets transmissionand reception. In addition, TCP initialization function puts thegateway to wait in an infinite loop for new connection requeststo occur.

The receive task on the Ethernet side enters in an infiniteloop, waiting for incoming packets on the Ethernet side toappear. When a packet is received successfully, it decodes andforwards it on the CAN side, then resumes waiting. Flowchartof the receive task can be seen in Fig. 7.

The transmit task on Ethernet is launched periodically andextracts CAN messages arrived in the FIFO circular queuefrom the CAN driver, wraps them using the method describedin Figure 3 and forwards the packed data on the Ethernet sideusing TCP, UDP, or both, depending on the configuration ofthe application. The polling rate of de FIFO queue may beestablished at compile time and is calculated depending on theCAN transmission rate so that the FIFO queue should neveroverflow. Flowchart of the transmit task can be seen in Fig.8.

Fig. 7. Ethernet Receive task

Fig. 8. Ethernet Transmit task

III. TEST APPLICATION FOR I N-VEHICLE MONITORING , DIAGNOSIS AND CONTROL

An application that makes use of the hardware and softwareresources described previously was built in order to illustratethe performance and facilities of the proposed CAN-Ethernetinterface. For this purpose a graphical tool was created inCANoe that simulates the in-vehicle connection, diagnosis andcontrol (Fig. 9).

Ethernet

ReceiveTask

Receive Ethernet packet

Bufferempty?

Blockingwait

Yes No Unpacking Ethernetframe

Send CAN messages

Blockingwait

EthernetTransmit

Task

FIFOempty?

Blockingwait

Yes No Packing CANmessages

Send Ethernet packet

Blockingwait

ID1

ID-MSB3

LEN4

ID-LSB8

StandardID

ID1

ExtendedID

unused3

LEN4

ID-MSB5

unused3

unused3

ID-MID18

ID-MID28

ID-LSB8

DATA

DATA

8/10/2019 06688995.pdf

5/6

426

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

Since the implementation of the concept of a real car would be too complex and expensive, a CANoe simulation created tomimic communication taking place in a real car was used.Messages from this virtual in-vehicle car are transmitted on areal CAN bus to the actual gateway interface. The user willconnect to the simulated car using a graphical interface viaEthernet (User Ethernet Gateway CAN Car), thus beingable to carry out specific tasks such as diagnosis, monitoring or

preset of specific parameters of the car network.

When the application program starts the necessary internalvariables 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 thatthe application can be connected to any IP and port specified

by user.

First, the application must establish a connection to thesimulated car network. Depending on the protocol chosen, thismeans to establish a TCP connection or to assign a port to theUDP socket and start listening for messages on that port. Usercan view the connection status in the lower left corner of themain graphics window.

While the application (and thus the socket behind it) isconnected, it can send and receive messages to and from thenetwork 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 itsnon-connection oriented feature.

Thus, even if the application indicates that it is connected,this only means that the internal socket listens for packages onthe selected port and it is ready to send packets on the same

port. It can thus try to send packets to a non-existentdestination, without being able to find out about that. However,

because a car reports different values at regular intervals, onecan still see whether or not a UDP link is active.

Any Ethernet packet received is first unpacked. Afterunpacking one or more CAN messages will result. For each ofthese messages the ID is checked. If the ID has a known value,than the corresponding parameter is updated. If the received IDis unknown, then it is passed in a separate window withunrecognized IDs where they may be inspected and decodedmanually by the user.

8/10/2019 06688995.pdf

6/6

427

In a similar manner, there are two types of messages thatmay be transmitted: with IDs that are meaningful or irrelevantto the application. The first type of message will be sentautomatically with the appropriate ID when the user changesvalues in the graphical controls of the application. The other

posts have to be set manually in a distinct window provided forthis purpose.

IV. CONCLUSIONS AND FURTHER WORK The proposed solution for CAN-Ethernet gateway has a

number of strengths with great potential for furtherdevelopment due to its higher transfer rate, the low price, andof multiple applications that become possible due to the largespread of Ethernet. Practically any CAN network applicationscan be redesigned to extend their functionality over an Ethernetnetwork. The application example presented in the previoussection is only as one of many possible applications that could

be implemented adding interactivity between the in-vehicleCAN network and a TCP/IP client or to improvemanufacturing and testing processes.

Due to the much higher transfer rate all the in-vehicle CAN buses may be simultaneously accessible from outside. Thus, adiagnostic program designed to check each parameter of all

buses could be useful for both for service stations and even thecar owner through its personal laptop.

Applications to update the firmware are easy to implement,thus avoiding recall a large number of vehicles in servicestations for software errors. Each manufacturer could makeavailable on their website the latest firmware, then each clientmay download it and update its own car firmware.

One can include one or more internal Ethernet buses tomeet the need for larger packages and high transfer ratesrequired 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 asin the area of information-entertainment (infotainment).

Further work will be done to improve the gatewayimplementation using an Ethernet controller with TCP/IPimplemented in hardware so that the memory required by theTCP/IP stack and the processing time of host controller withthe TCP/IP code execution to decrease.

Also, the gateway firmware may be improved to performrouting in several CAN bus simultaneously. This is alreadyenabled in the actual software implementation, but was nottested in our experiments due to the memory limitations.

One can also change the program to allow connections withmultiple 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.

R EFERENCES [1] Jang, K., Park, I. Han, J. et al., Design framework for FlexRay network

parameter optimization, International Journal of AutomotiveTechnology, Vol. 12, issue 4, pp.589-597, 2011

[2] Zinner, H., Noebauer, J., Gallner, T. et al., Application and realizationof gateways between conventional automotive and IP/Ethernet-basednetworks, Proceedings of the 48th ACM/EDAC/IEEE DesignAutomation Conference (DAC), pp. 1-6, 2011

[3] Yu, H., Qin, G.H., Liu, Y., Chen, Y.H., Implementation of an IP-basedin-vehicle gateway, version 6, World Automation Congress(WAC) Puerto Vallarta, Mexico City, 2012

[4] Kern, A. Reinhard, D., Streichert, Th., Gateway strategies forembedding of automotive CAN-frames into Ethernet-packets and vice

versa, 24th International Conference on Architecture of ComputingSystems, Milano, 2011, in Architecture Of Computing Systems - ARCS2011, in Lecture Notes in Computer Science, Volume 6566, pp. 259-270, 2011

[5] MPC5510 Reference Manual, Freescale Semiconductor, 2012[6] ENC28J60 Data Sheet Stand-Alone Ethernet Controller with SPI

Interface, Microchip, 2004[7] Vector Informatik GmbH, CANcaseXL/log Manual, 2013.