Automotive Network Diagnostics with Crash Data Retrieval System

Abstract

The project aims at designing a heavy vehicle crash data retrieval system known as Event Data Recorder (EDR) that also acts as in vehicle network fault analysis and diagnostic system. Like Black Box of airplane, Event Data Recorder (Vehicle Black Box) is used to record information related to accidents so that it can be used to analyze the accident by reconstructing what happened before and after an accident. The system can contribute to constructing safer vehicles, improving the treatment of crash victims, helping insurance companies with their vehicle crash investigations, and enhancing road status in order to decrease the death rate. Vehicle Black Box detects a crash automatically using MEMS inertial sensor, and also records the motion of the vehicle and driver’s actions during a predefined time period before and after the accident. It consists of data collection devices for collecting the information about vehicle status and the driver’s actions, a non-volatile memory device for recording, a microprocessor for controlling the unit and an in vehicle network to collect data from various sensors and actuators located within the vehicle. The vehicle black box (EDR) contains not only a record of what was happening in the last seconds before the impact but also the record after a collision. So the design principle is such that it takes the most recent data values and stores them in buffer with a circular sequence (RAM). When the black box senses the accident, buffer refreshing is suspended and the data before and after accident are transfer to the non volatile memory automatically.

Keywords

CAN, Local Interconnect Network ECU, MEMS, MSSP

INTRODUCTION

According to the World Health Organization, more than a million people in the world die each year because of transportation-related accidents [1]. In order to react to this situation, the black box system draws the first step to solve this problem that crosses national boundaries and threatens the safety and health of people worldwide. Introduced to a part of the United States market, the black box system proved to be efficient [2]. However in the latter case, the system was embedded in the vehicle [3-5]. Therefore, in addition to improving the treatment of crash victims and the road status in order to decrease the death rate, constructing safer vehicles, and helping insurance companies with their vehicle accidents investigations, the main purpose of this paper is to develop a black box system that can be installed to any vehicle all over the world.

Like flight data recorders in aircraft, "black box" technology can now play a key role in motor vehicle crash investigations [6]. A significant number of vehicles currently on the roads contain electronic systems that record information in the event of a crash. That is why it is so important to have recorders that objectively track what goes on in vehicles before, during and after a crash as a complement to the subjective input that is taken usually from victims, eye witnesses and police reports. This system is committed mainly to two approaches. The first one is how to detect and record data from the vehicle. The second is how to present the data recorded to the user in a simplified way. To implement the first approach, some major components and different type of sensors were used. The vehicle parameters recorded include: brake pedal status, accelerator pedal status, vehicle speed, steering angle, time of crash, crash force, direction of crash, warning lights status, vehicle head light status, brake light status and ambient light condition.

Another aim of this project is to design a system to monitor and diagnose automotive networks, by using a knowledgebased diagnostic technique. Fault information from several sources is used to build a knowledge base. Network fault codes and possible causes diagnosed by a diagnostic module are then stored in a database. The codes are helpful for manufacturing and service processes. This new diagnostic system would help reduce numbers of possible fault causes, As a CAN application layer protocol, the SAE J1939 has been developed by the SAE Truck & Bus Control and Communications Network Subcommittee of the Truck & Bus Electrical & Electronic Committee. The purpose of SAE J1939 is to provide an open interconnection system for different electronic systems and allow ECUs to communicate with each other by providing a standard architecture. LIN protocol acts as a sub bus to connect the cheaper systems such as head lights and brake lights. LIN protocol reduces the complexity of the main network and also reduces the overall cost of the system. All the data recorded could be monitored and analyzed from a desktop computer. The user can send special commands to monitor a selected parameter from the recorded data as well as to get the diagnostic codes of various faults occurred in the network.

HARDWARE RESOURCES

The hardware part consists on the sensors and the black box installed into the vehicle. This part mainly collects the status of the sensors and saves it to the microcontroller's EEPROM.

2.1 Sensors

2.1.1 Brake Sensor

The brake sensor is a type of switch implemented in the Vehicle underneath the brake footstep. This switch controls the brake lights. In order to know if the driver pushed the brake during the accident, this switch is connected to the input of the microcontroller.

2.1.2 Lights Sensor

For a particular vehicle, the important lights in the analysis of an accident are the flashers, the brake lights and the rear lights. The rear lights are needed in the analysis to know the direction of the vehicle. The brake lights are needed to show the brake status seen by the driver behind, before the accident. Finally, the flashers will also be useful in the analysis of the accident in order to determine whether the driver has used them properly.

2.2 Digital Processing

In order to control all these sensors and their inputs, a can be used [9]. As prototype a microcontroller is selected to control the System. For this prototype, the main need was a large EEPROM, to enable recording as much data as possible about the accident, and a large amount of inputs. Thus, PIC16F877A was used because it has 8 Kbytes of Flash Program Memory, 368 bytes of Data Memory, 256 bytes EEPROM data memory, 15 interrupts, 8 input channels, 5 1/0 Ports, and many other characteristics.

An integration of electronic systems in a car consists of a number of electronic devices and electronic control units (ECUs) from different suppliers. Up until the late 1990's, the communication between simple devices was mostly achieved by using point-to-point wiring, resulting in bulky, expensive and complicated wiring [2]. The attempt to eliminate wiring difficulties and to improve automotive distributed control systems has become an interesting issue for automotive manufacturers. In the mid 1980s, Robert Bosch GmbH invented a robust automotive control network known as Controller Area Network (CAN). More recently, CAN networks have been popular not only in automotive applications, but also in automation and control applications. This fact is supported by the increasing numbers of ECUs in the vehicles.

However, it is well understood that the automotive manufacturers seldom develop electronic devices themselves. They often outsource this task to different suppliers. Electronic devices from different suppliers are then integrated into vehicle systems by the manufactures. Therefore, test and fault diagnosis of network integration are strongly required to ensure that all devices are able to correctly and reliably interact together as specified. Furthermore, on-board network diagnosis is also needed in order to identify any problems or faults occurring during vehicle operation. Diagnosis of faults in distributed multi- ECUs environment is a challenging task. Faults can result from a number of causes such as the ECU itself, the CAN controller, or the electrical wiring. Moreover, a faulty ECU possibly causes another ECU to be faulty.

DATA TRANSMISSION

3.1 Controller Area Network

CAN is one of the most advanced serial communication protocols used in applications [4]. It is estimated that around 400 million CAN nodes were sold in 2005. In automotive applications, CAN is widely used as a communication protocol for ECUs due to its enhanced features. As a communication protocol, CAN complies with the two bottom layers of the Open Systems Interconnection model (OSI) standardized by the International Standards Organization (ISO). The OSI layer 1 and layer 2 are described in the ISO 11519-2 standard for low speed applications (125 Kbit/sec) and ISO 11898 standard for high speed applications (IMbit/sec) [5]. A CAN communication controller is used by each device to control communication between devices connected on the bus. CAN use an arbitration feature to control access of devices connected on the same bus in order to avoid transmission collision which causes errors in communication. Nonetheless, when errors have occurred, an error management feature is used to detect, handle and confine such errors. For instance, an error frame is sent to signal the devices that errors have been detected on the bus so that the devices ignore the message recently sent. Further details of CAN can be found in [5]. Although CAN has features that tolerate communication faults, permanent and intermittent faults that could not be detected and confined by the error management unit may occur on the bus. Faults could come from any of the parts that form the communication links. For example, if a physical bus connector is intermittently loose, signal levels will fluctuate. This may result in an engine working improperly. The fault, however, could not be easily detected in a service centre. As a result, an automotive network diagnostic system is needed to overcome the problems. In this paper, automotive network diagnosis focusing on the physical layer of CAN and the CAN communication controller is discussed.

The CAN communication protocol is a CSMA/CA protocol. The CSMA stands for Carrier Sense Multiple Access. What this means is that every node on the network must monitor the bus for a period of no activity before trying to send a message on the bus (Carrier Sense). Also, once this period of no activity occurs, every node on the bus has an equal opportunity to transmit a message (Multiple Access). In CAN protocol, a non-destructive bitwise arbitration method is utilized. This means that messages remain intact after arbitration is completed even if collisions are detected. All of this arbitration takes place without corruption or delay of the higher priority message. There are a couple of things that are required to support non-destructive bitwise arbitration. Logic states need to be defined as dominant or recessive. The transmitting node must monitor the state of the bus to see if the logic state.CAN define a logic bit 0 as a dominant bit and a logic bit 1 as a recessive bit. A dominant bit state will always win arbitration over a recessive bit state, therefore the lower the value in the Message Identifier (the field used in the message arbitration process), the higher the priority of the message.

3.2 Message-Based Communication

CAN protocol is a message-based protocol, not an address based protocol. This means that messages are not transmitted from one node to another node based on addresses. Embedded in the CAN message itself is the priority and the contents of the data being transmitted. All nodes in the system receive every message transmitted on the bus (and will acknowledge if the message was properly received). It is up to each node in the system to decide whether the message received should be immediately discarded or kept to be processed. A single message can be destined for one particular node to receive, or many nodes based on the way the network and system are designed.

Another useful feature built into the CAN protocol is the ability for a node to request information from other nodes. This is called a Remote Transmit Request (RTR). This is different from the example in the previous paragraph because instead of waiting for information to be sent by a particular node, this node specifically requests data to be sent to it. For example, a safety system in a car gets frequent updates from critical sensors like the airbags, but it may not receive frequent updates from other sensors like the oil pressure sensor or the low battery sensor to make sure they are functioning properly. Periodically, the safety system can request data from these other sensors and perform a thorough safety system check. The system designer can utilize this feature to minimize network traffic while still maintaining the integrity of the network. One additional benefit of this message-based protocol is that additional nodes can be added to the system without the necessity to reprogram all other nodes to recognize this addition. This new node will start receiving messages from the network and, based on the message ID, decide whether to process or discard the received information.

33 CAN Message Frame Description

3.3.1 Standard Data Frame

In common with all other frames, the frame begins with a Start Of Frame (SOF) bit, which is of the dominant state, which allows hard synchronization of all nodes.

3.3.2 Arbitration field:The SOF is followed by the arbitration field. Arbitration field consisting of 12 bits; the 11-bit identifier and the Remote Transmission Request (RTR) bit. The RTR bit is used to distinguish data frame (RTR bit dominant) from a remote frame (RTR bit recessive).

3.3.3 Control field:

Control field Consisting of six bits; the first bit of this field is the Identifier Extension (IDE) bit which must be dominant to specify a standard frame. The following bit, Reserved Bit Zero (RB0), is reserved and is defined to be a dominant bit by the can protocol. The remaining four bits of the control field are the Data Length Code (DLC) which specifies the number of bytes of data contained in the message.

3.3.4 Data field:

This contains any data bytes that are being sent, and is of the length defined by the DLC above (0-8 bytes).

3.3.5 Cyclic Redundancy Check (CRC) Field

It follows the data field and is used to detect transmission errors. The CRC Field consists of a 15-bit CRC sequence, followed by the recessive CRC Delimiter bit.

3.4 Local Interconnect Network

LIN Protocol was designed by a consortium of European auto manufacturers as a low cost, short distance, low speed network. Designed to communicate changes in switch settings and respond to switch changes, it is intended to communicate events that happen in "human" time (hundreds of milliseconds). This Application Note is not intended to replace or recreate the LIN Protocol Specification. Rather, it is intended to provide a broad overview of the bus and provide a high level look at how it works, how to implement a Slave node PICmicro® device and what it’s designed to do. The complete LIN Protocol Specification is expected to be available. In the last few years few protocols have come up designed with focus on cost efficiency and aimed for use as simple multiplexed electrical systems. One of these protocols is LIN (Local Interconnect Network) and is likely to become a de-facto standard in the automotive industry.

LIN is considered by many automotive companies to be the most prominent contender for simpler multiplexed electrical networks. These include body-electronics applications like control of power window, mirror, wiper, lock, seat and roof, HVAC, lights, lamps and indicators and the dash board instruments. There are many old and reliable as well as new protocols out in the market, which has both advantages and disadvantages as compared to LIN. Most of the protocols are custom or proprietary to the car manufacturers and many of these are gradually being phased out [1]. Examples of proprietary protocols are CCD from Chrysler, BEAN from Toyota, UBP from Ford and UART (ALDL) from GM. Since these protocols are proprietary they will not have the same widespread usage as LIN. The LIN is a serial communication protocol designed to support automotive networks in conjunction with Controller Area Network (CAN). As the lowest level of a hierarchical network, LIN enables cost-effective communication with sensors and actuators when all the features of CAN are not required.

CONCLUSION

The increasing number of electronic devices and networked embedded systems in automotive applications results in high complexity in fault diagnosis and testing process. An automotive network diagnostic system using a knowledgebased technique is proposed. The system monitors and diagnoses automotive networks. The network fault codes and possible causes are then stored in the fault database for manufacturing and service purposes. In the experimental stage, a communication network set-up is conveniently accomplished by CAN bus simulation tools. To obtain a dependable knowledge base, several diagnostic information sources have been considered in building the knowledge base of the system. The Black Box system built can be implemented in any vehicle. As soon as the driver runs the motor, this system will begin saving the events of the corresponding vehicle. The last 21 seconds are always saved in the EEPROM of the Black Box, and in case of an accident, an additional 10 seconds of events after this accident will be saved.

Tables at a glance

Figures at a glance

Figure 1 Figure 2 Figure 3

References

N. Navet et al., "Trends in Automotive Communication Systems", Proceeding of the IEEE, Vol. 93, No.6, June 2005, pp.1204-1223. G. Leen and D. Heffernan, "Digital Networks in Automotive Vehicle", Computer and Control Engineering Journal, 1999, pp. 257-266. J. Leohold, "Communication Requirement for Automotive Systems", 5t Workshop on Factory Communication Systems, 2004. T. Gerke and C. Schanze, "Development and Verification of In-Vehicle Networks in a Virtual Environment", 2005 SAE World Congress, Detroit, Michigan, 2005. W. Lawrenz, CAN System Engineering: From Theory to Practical Applications, Springer-Verlag, New York, 1997.