Extracting Controller Area Network Data for Reliable Car Communications

Huaqun Guo, Jun Jie Ang, and Yongdong Wu

Abstract Networked Electronic Control Units (ECUs) are increasingly being deployed in automobiles to realize various functions and Controller Area Network (CAN) is deployed for the communications among ECUs. Our primary objective is to build both hardware and software that interface and communicate directly with CAN network and extract CAN messages for reliable car communications. The hardware is a circuit board that is capable of capturing CAN signals released from an automobile. The software will be both the firm-wares programmed for the two microcontrollers found on the circuit board, as well as the Graphical User Interface on the PC that enables users to control the functionalities of automobile via a few simple clicks of the buttons. With the help of these developed components, CAN messages can be used for reliable car communications, for example, reliable traffic information routing. Tests and trials of the completed board are also carried out to ensure that the system is performing decently well.

I. INTRODUCTION In recent years, control systems of cars have moved from the analog to the digital domain. In particular, x-by-wire systems are appearing and drive research efforts of the whole automotive industry for the recent decade. Electronic Control Units (ECUs) are increasingly being deployed in automobiles to controls one or more electrical subsystems to realize the various functions. When a driver drives a car, there are many signals that are passed between the various ECUs embedded inside the car. Output signals from an ECU contain information about the current state of the car as the driver interacts continuously with the car. A modern automobile can consists of up to 70 ECUs [1, 2], sensing and taking tabs of the various parameters of the automobile. This rapid and complex exchange of signals ensures the proper functioning of the car. The Controller Area Network (CAN) protocol was thus introduced to alleviate the problem of sending these signals efficiently, in the form of structured message frames called CAN messages. With the advent of Vehicular Ad-Hoc Network that allows vehicles within reasonable proximity to connect
Huaqun Guo is with the Institute for Infocomm Research, A*STAR, 1 Fusionopolis Way, #21-01 Connexis (South Tower), Singapore 138632 (phone: +65 64082042; fax: +65 64669302; e-mail: guohq@i2r.astar.edu.sg). Jun Jie Ang was with Department of Electrical & Computer Engineering, the National University of Singapore, 2 Engineering Drive 4, Singapore 117576. (e-mail: u0407715@alumni.nus.edu.sg) Yongdong Wu is with the Institute for Infocomm Research, A*STAR, 1 Fusionopolis Way, #21-01 Connexis (South Tower), Singapore 138632 (email: wydong@i2r.a-star.edu.sg)

wirelessly to one another via an ad-hoc manner, vehicles are able to share information about their current states to others. But how is this information, CAN messages tapped from the various ECUs, useful at all? Here, our project presents an approach to harness the availability of such information to solve some of the problems vehicular networks set out to solve, as can be seen in [3]. One example is to using extracted CAN messages from automobiles to establish the reliable route for messages to take in order to reach its destination. We propose a scenario where many cars are traveling along a highway (Fig. 1). Cars that will turn right will signal right, hence effectively dividing the cars into 2 groups. If the CAN messages that govern the signaling lights are collected and then sent to other cars still traveling along this highway. These contemporaries are thus now wiser in constructing the reliable route to relay their messages, as they can exclude all cars belonging to the other group cars that are exiting the highway. In this scenario, the top most vehicle will choose the left solid arrow routing path for the information propagation since according to the received CAN data it knows that the immediate vehicle at right dotted arrow path is going to turn away.

Reliable path Not Reliable path

Right Turn Signal

Fig. 1. Reliable routing on car communications using CAN data

978-1-4244-3504-3/09/$25.00 2009 IEEE

1027

Having seen the bigger picture, we now focus on the constructing solutions that have the capabilities of extracting the needed CAN messages from an automobile [4]. The remainder of this paper is organized as follows: The background is presented in the next section. We present our hardware design in Section III, while firmware design and software graphical user interface are presented in Section IV and Section V respectively. Section VI presents the experimental testing of our system. Finally we conclude the results in Section VII. II. BACKGROUND A. A CAN Simulator A CAN Simulator, which rightly mimics a real automobile, was provided to experiment on. The board exposes the underlying CAN bus which connects the various ECUs found onboard the Simulator. Furthermore, in an attempt to study the effect of CAN messages on real automobile, faults are to be inserted into the Simulator. The CAN Simulator, shown in Fig. 2, is commercially available from LD Didactic GmbH [5]. It is offered as a training aid to teach the functionalities of networked systems in vehicles, primarily the principle of CAN bus data transfer among various ECUs. The components (i.e. the various lights, wipers, dashboard, steering unit, etc) found onboard are original vehicle parts from an automobile. What that was replicated however, were essentially only the lighting and the comfort sub-systems of the automobile. The lighting subsystem controls the various signal lights, which includes the left and right signal lights, the high and low beam, brake lights, license plate light and rear lights, and is normally under control by the steering electronic unit. The comfort sub-system in this case includes only the windscreen wiper and a fault detection system that detects anomalies upon vehicle ignition and thereafter warns the user on a LCD screen on the main dashboard. Thus, we can treat that the task of an ECU is to govern the functionalities of a given sub-system. More importantly, the Simulator exposes the underlying CAN bus that carries the messages from one subsystem to another. B. Controller Area Network In the early 1980s, engineers at Bosch evaluated existing serial bus systems regarding their possible use in passenger cars and found that none of the available network protocols were able to fulfill the requirements of the automotive. In February of 1986, CAN was born: at the SAE (Society of Automotive Engineers) congress in Detroit, the new bus system developed by Bosch was introduced as Automotive Serial Controller Area Network. Historical facts and rationales for the CAN protocol are discussed in more detail in [6, 7, 8]. Controller Area Network (CAN) is a serial data communications bus for real-time applications. Figure 3 shows that the CAN network topology follows the bus

network topology, which gives it the advantage of easily adding new CAN nodes to an existing network. Furthermore, the standardization of the protocol means all ECUs will conform to the CAN standards while transmitting data. Note that in the figure all CAN nodes are fitted with a mandatory transceiver chip that connects it to the CAN bus.

Fig. 2. The CAN Simulator.

CAN is based on the broadcast communication mechanism. This means that all nodes can "hear" all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages. Therefore, CAN is based on a message-oriented transmission protocol. Every message has a message identifier, which is unique within the whole network since it defines the priority of the message.

Fig. 3. The CAN network topology.

1028

Table I lists some CAN messages that are used in the Simulator.
TABLE I. CAN MESSAGES

III. HARDWARE DESIGN A. Overall System Design The project can be largely divided into three parts: the design and fabrication of hardware main board, programming of firmware and design of a GUI. Fig. 5 gives a block diagram of the overall design of the system. Debugging Terminal CAN Simulator CAN Serial Port Main Board USB GUI PC

Functions 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Left turn signal Right turn signal High Beam Wiper Hi Wiper Lo
Wiper int. approx 17 seconds interval Wiper int. approx 15 seconds interval

Message Identifier 2C1 2C1 2C1 2C1 2C1 2C1 2C1 2C1 2C1 2C1 2C1 2C1 531 531 531 531 531

Data 010080 020080 080080 000880 000580 000281 000285 000289 00028D 000580 000090 0000A0 0100 0300 0700 2000 0040

ACK 3A55 6FF0 191C 33BE 5054 420D 1AC2 360A 6EC5 5054 67D6 116F 01BD 4C68 125B 2955 365E

Wiper int. approx 6 seconds interval Wiper int. approx 3 seconds interval Wiper continuous
Washer motor pos. 1 Washer motor pos. 2

Fig. 5. System block diagram.

Small light on
Head light on Lo

Head light on Hi Reverse light on Brake light on

Figure 4 shows how the ECU for steering column electronics that controls the sensing of the signal handler of a car interacts with the lightings control system ECU.

Essentially, the main board is the one that is receiving input signals from the Simulator via the CAN interface. These signals are passed via the USB port to the PC. A GUI program resides on the PC that processes the signals received from the main board, or instructs the main board to send various CAN messages back to the Simulator. It is also worth mentioning that the main board can connects to a debugging terminal via a serial port which was used by the authors for debugging purposes when designing the main board. The debugging terminal is since then not used by the end users. B. Circuit Boards Figure 6 shows the completed main board that consists of the dsPIC30F4012 and the 18F2455 chips. The specifications of both chips are found in [9] and [10] respectively. The dsPIC30F4012 chip contains one CAN stack which provides the capability for the board to interpret CAN signals extracted from the Simulator. Furthermore, transceiver chips (MCP2551) are required to connect the main board itself to the CAN bus. The extra MCP2515 chip (surface mountable, not shown in figure) provides a second CAN interface to the main board. Thus, the main board can access two CAN buses at any one time. Lastly, the RS232 serial port interface can be clearly seen in the figure, which transfers core dumps to a terminal that aids in debugging during the design process. The 18F2455 chip is responsible maintaining the USB connection from the main board to the PC. It is a popular chip that contains a USB stack that makes USB deployment relatively easier. Data are transferred between the two chips via the SPI interface.

CAN Bus

Fig. 4. Overview of how CAN in the Simulator works

First, the driver interacts with his car by signaling left on the signal handler. The ECU for steering column electronics responds by sending a CAN message along the CAN bus with the encoded information, signing the message off with its message identifier (2C1-03-010008). Next, at the receiving end, the lightings system ECU is configured to accept messages with this certain message ID. Finally, the lightings system decodes the information and triggers on the left signal light on the automobile.

1029

Fig. 8. Interfaces on the main board. Fig. 6. Completed Main board.

The main board is then treated as just like another ECU that is attached to the Simulator, as shown in Fig. 7.

Yes

Yes CAN Bus Yes

Fig. 7. Main board connected as an ECU to CAN bus

IV. FIRMWARE DESIGN The main board is made up chiefly of two main chips, the dsPIC30F4012 and the 18F2455 chip. The former chip takes care of receiving and sending of CAN messages in or out of the main board. The latter chip takes care of implementing the USB port that connects the main board to the PC. The relationships between the chips and the interfaces between them can be summarized in Fig. 8. When data are transferred from the PC to the main board via the USB port, the 18F2455 chip is the one that first receives this data. Figure 9 indicates the simplified system flow chart of the algorithm in the 18F2455 chip. The dsPIC30F4012 provides the main CAN interface in interfacing with the Simulator. Most importantly, the chip contains a main table that records all information obtained from the received CAN data from the Simulator, as well as user-defined CAN data from the GUI that are used to control the functionalities on the Simulator. When a CAN message is received, an interrupt is raised which sets a flag to copy the information contained inside the CAN message to the main table. The simplified system flow chart of the algorithm in the dsPIC30F4012 chip is given in Fig. 10.

Fig. 9. System flowchart for 18F2455 chip.

Yes

Yes

Yes

Fig. 10. System flowchart for dsPIC30F4012 chip.

1030

V. SOFTWARE GRAPHICAL USER INTERFACE The GUI (Fig. 11), coded in Visual Basic .Net, is able to interface with the main board via the USB port. This section discusses the various functions developed specifically to control the Simulator. Manual tab: allows users to input manually CAN messages into the Simulator. Command Control: gives users control over various functionalities of the Simulator with the simple clicks of buttons. For example, it is possible to send a signal left CAN message, which causes the left signal lights on the Simulator to light up. Faults: insert physical faults into the Simulator. Bus monitor: allows the monitor of all CAN messages that are transferring on the CAN bus at any one instant. Connection options: Provides setup options for the users.

logo is mounted onto the wiper server motor). The wiper motor rotates successfully after the CAN message is inserted.

Fig. 12. Using the GUI to control the Simulator.

The final test tests if CAN data from the Simulator can be successfully retrieved from the Simulator board. The bus monitor tab monitors all CAN messages that are transferring on the CAN bus at any one instant. In order to update the messages to reflect the latest CAN messages received by the main board, the user does so by pressing on the refresh button. The user can also sort the data according to the various header fields. Figure 13 shows the GUI successfully retrieves a list of CAN messages from the Simulator during a test run with the system.

Fig. 11. The GUI developed.

VI. DEPLOYMENT AND TESTING OF PROJECT In order to test and verify the functionalities of the developed project, the system was deployed and trialed together with the Simulator. Several aspects of the system were tested, but due to space constraint, only a couple of these tests will be the subject of discussion in this section. A video of the whole test process was also taken, of which several screenshots from this video are provided here. Fig. 12 shows the inserting of CAN messages using Command Control in the GUI. From top right and counter clockwise: 1) the signal lights were shown to be initially off. 2) The GUI was used to insert CAN messages to test the left signal lights. 3) After inserting the CAN message, the signal lights lit up. 4) Next, the wiper was also tested (note that the

Fig. 13. The GUI tabulates the list of retrieved CAN messages from the Simulator.

1031

VII. CONCLUSIONS The paper presents our project that successfully extract CAN data from automobile. It presents the details of building
both hardware and software that interface and communicate directly with CAN network embedded in the automobile. The

extracted CAN messages from automobiles can be used to establish the reliable route for messages to take in order to reach its destination. In the future works, we will look into the prospects of integrating the system with an embedded info-security system for vehicular networks which was presented in [11] and forward CAN data for reliable car communications.

ACKNOWLEDGMENT Authors would like to thank Mr Yam Meng Lim, Mr Teng Koon Tay, and Mr Paul Soon Seng Yuen from the Institute of Technical Education College West (Ang Mo Kio campus, Automotive Technology, School of Engineering) for their valuable technical knowledge on automotives, and their support for the project test. REFERENCES
Heffernan, D., & Leen, G. (2008, September). ICT based research at Limerick contributes to automotive drive-by-wire technology. Available: http://www.irishscientist.ie/2002/contents.asp?contentxml=02p237b.x ml&contentxsl=is02pages.xsl [2] Vasilash, G. S. (2005, May). Hardware-in-the-loop: assuring performance & quality by combining the real & the virtual. Testing. Automotive Design & Production. Gardner Publications, Inc. Available: http://findarticles.com/p/articles/mi_m0KJI/is_/ai_n13784131 [3] Saleh Yousefi, Mahmound Siadat Mousavi, Mahmood Fathy, Vehicular Ad Hoc Netoworks (VANETs): Challenges and Perspectives, in Proc. 6th International Conference on Intelligent Transport System (ITS) Telecommunications, 2006 [4] Jun Jie Ang, Car-to-Car Integrated Security Communication, Bachelor thesis, Dept. Elect. & Comp. Eng., National University of Singapore, 2008. [5] Leybold-Didactic GmbH. (2005, August). Automotive Technology System. Available: http://www.leybold-didactic.de/pdf/t3_e.pdf [6] Texas Instruments. (2008, July). Introduction to the Controller Area Network (CAN). Available: http://focus.tij.co.jp/jp/lit/an/sloa101a/sloa101a.pdf [7] CAN in Automation (CiA). Controller Area Network (CAN). Available: http://www.can-cia.org/ [8] Robert Bosch Gmbh. Controller Area Network (CAN). Available: http://www.semiconductors.bosch.de/en/20/can/index.asp [9] Microchip Technology Inc. (2007). dsPIC30F4011/4012 Data Sheet High performance Digital Signal Controllers. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/70135E.pdf [10] Microchip Technology, Inc. (2007). PIC18F2455/2550/4455/4550 Data Sheet. Available: http://www.microchip.com [11] Huaqun Guo, Lek Heng Ngoh, Yongdong Wu, Lian Hwa Liow, Choon Hwee Kwek, Feng Tao, and Jun Jie Ang, Embedded InfoSecurity Solutions for Vehicular Networks, in Proc. Third International Conference on Communications and Networking in China (CHINACOM08), Hangzhou, China, August 25-27, 2008. [1]

1032