AN ADAPTIVE DATA REDUCTION PROTOCOL FOR FUTURE IN-VEHICLE NETWORKS

Transcription

1 AN ADAPTIVE DATA REDUCTION PROTOCOL FOR FUTURE IN-VEHICLE NETWORKS By PRAVEEN KUMAR RAMESH RAMTEKE THESIS Submitted to the Graduate School of Wayne State University, Detroit, Michigan in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE 2005 MAJOR: ELECTRICAL ENGINEERING Approved by: Syed Masud Mahmud September 08, 2005 Advisor Date

2 ACKNOWLEDGEMENTS I would like to take this opportunity to sincerely thank my advisor Dr. Syed Masud Mahmud for being an outstanding mentor and constantly supporting my endeavors over the duration of my Masters degree. I also express my deep appreciation towards Dr. Pepe Siy and Dr. Feng Lin for being extremely professional in reviewing this research work and guiding me throughout its completion. I feel indebted to many of my friends at Wayne State University and also in India who have helped me in more than one way during this period. My heart felt gratitude to all of them. And finally, I would like to thank my family back home for always being a constant source of support. Without their hard work, I would not have been here in the first place. i

3 CONTENTS 1 INTRODUCTION 1 2 LITERATURE REVIEW Controller Area Network(CAN) Start of Frame (SOF) Arbitration Field Control Field Data Field CRC (Cyclic Redundancy Check) Field ACK (Acknowledge) Field End of Frame (EOF) Field Available Data Reduction Techniques Simple Huffman Coding Arithmetic Coding Higher Order Arithmetic Coding Textual Substitution Coding Command Data Stream Coding A Generalized Data Reduction Algorithm Data Compression Process.16 ii

4 2.3.2 Data Decompression Process 16 3 PROPOSED DATA REDUCTION ALGORITHM Data Reduction Technique Data Compression Non-Adaptive Data Reduction Adaptive Data Reduction Data Decompression 26 4 RESULTS AND DISCUSSIONS Case 1: Transient and Steady State Operation Case 2: Hard Braking or Deceleration CONCLUSIONS FUTURE WORK...42 REFERENCES...44 ABSTRACT...46 AUTOBIOGRAPHICAL STATEMENT...48 iii

5 LIST OF TABLES Table 1: Distribution of messages among nodes in the simulation model 32 Table 2: Gain in the values of performance parameters in comparison to the case when no DR was applied to the system..40 iv

6 LIST OF FIGURES Figure 1: Projected growth in the number of processors per vehicle 1 Figure 2: Increase in processing power/average vehicle...2 Figure 3: Structure of a CAN node 5 Figure 4: Standard CAN DATA Frame.6 Figure 5: CAN message ARBITRATION Field...8 Figure 6: CAN message CONTROL Field...9 Figure 7: CAN message CRC Field...9 Figure 8: CAN message ACK Field...10 Figure 9: Automotive Body Network..11 Figure 10: Automotive multiplexing system consisting of n number of ICM s...15 Figure 11: Data field of a CAN message showing various signal fields within the message. Each row indicates a data byte and each column indicates a bit. Some signals within the data field occupy more than a byte where as some others occupy one byte or less..20 Figure 12: Data field format of delta-compressed message of Figure Figure 13: Adaptive data-reduction algorithm 25, 26, 27 v

7 Figure 14: Data-decompression process..29 Figure 15: Data-decompression algorithm..30 Figure 16: Simulation model consisting of 5 CAN nodes...31 Figure 17: Message transmission rate (MTR) comparison..33 Figure 18: Bus load Comparison.34 Figure 19: Average message length (ALM) comparison 35 Figure 20: Variation of different signals during transient and steady state 36 Figure 21: Message transmission rate (MTR) comparison during hard braking.37 Figure 22: Bus load comparison during hard braking 38 Figure 23: Average message length (ALM) comparison during hard braking...39 Figure 24: Variation of different signals during hard braking or deceleration...40 vi

8 1 INTRODUCTION As automakers are incorporating more and more advanced features into vehicles, there is a growing need for enhanced processing power. S. Channon and P. Miller [1] estimate that the number of microprocessors per vehicle will increase exponentially as shown in Figure 1. It is evident that by the end of year 2010, the number of microprocessors in any high-end vehicle will be 250. Figure 1. Projected growth in the number of processors per vehicle Also, the application areas that demand more processing power are active safety systems, infotainment (TV, Video, gaming and navigation systems), and drive-by-wire systems. Figure 2 elaborates this observation. Additionally, functional integration of individual sensors will be necessary for applications such as collision avoidance. These additional vii

9 functionalities can be achieved by increasing the number of nodes or Electronic Control Modules (ECM s), sensors and actuators that can exchange data among various other nodes in the network. Figure 2. Increase in processing power/average vehicle However, the data traffic over the high-speed communication bus, like Controller Area Network (CAN), will increase significantly with the increase in the number of ECM s. Another important requirement would be to communicate data between the various ECM s in real time for safety-critical applications. Failure to communicate data within a given period of time may lead to degradation in system performance and may put the occupant s life in danger. 2

10 In order to address the bandwidth concerns and eliminate message latencies, datareduction (DR) techniques have been developed which communicate large amounts of data in a short period of time, consuming very less bandwidth. DR techniques have been applied extensively for the task of image compression (e.g. MPEG, JPEG), data compression and digital data transmission. Due to the safety-critical nature of automotive multiplexing system, selection of an optimum data-reduction technique is imperative to ensure proper system performance. An optimum DR technique can be characterized as the one that consumes the least network bandwidth and has zero message latency. This thesis work deals with the development of an adaptive data reduction (ADR) algorithm for next-generation of automotive in-vehicle networks based on the CAN protocol. The organization of the work is as follows. Chapter 2 presents the literature survey; giving a brief overview of the popular in-vehicle networking protocol namely CAN and highlighting previous research in the area of DR techniques for automotive in-vehicle networks. Chapter 2 also explains in detail one DR algorithm which has significant relevance to the proposed DR algorithm. Chapter 2 also discusses the drawbacks of the previously proposed DR techniques and. Chapter 3 explains the proposed DR algorithm in detail and Chapter 4 presents the performance of the proposed DR algorithm through simulation results. Chapter 5 presents the conclusions and Chapter 6 discusses some future work. 3

11 2 LITERATURE SURVEY This chapter presents an overview of one of the most popular and widely used in-vehicle networking protocol namely Controller Area Network (CAN) since the proposed DR technique is based on the CAN protocol. The chapter also discusses some of the available DR techniques for automotive in-vehicle networks and highlights their inherent drawbacks. 2.1 CONTROLLER AREA NETWORK (CAN) CAN is a high-speed, serial communication protocol which supports distributed real-time control and was designed by Robert Bosch GmbH in the early eighties. CAN finds applications in various fields of engineering including industrial automation, agriculture, aerospace and automotive electronics. The Bosch 2.0 specification defines the CAN protocol and operates mainly through the data-link layer of the ISO/OSI model. The CAN protocol has been sub-divided into three different layers namely, 1. The object layer 2. The transfer layer and 3. The physical layer The object layer and the transfer layer emulate all functions of the data-link layer of the ISO/OSI model. Figure 3 below depicts the different layers of the protocol controller and the function performed by each as outlined by Bosch [7]. 4

12 Object Layer: - Messages filtering - Message and status Handling Transfer Layer - Fault Confinement - Error Detection and Signaling - Message Validation - Acknowledgment - Arbitration - Message Framing - Transfer Rate and Timing Physical Layer - Signal Level and Bit Representation - Transmission Medium Figure 3. Structure of a CAN node Some of the salient features of CAN for which it is highly used in automotive applications are 1. Prioritization of messages 2. Guarantee of latency times 5

13 3. Configuration flexibility 4. Multicast reception with time synchronization 5. System wide data consistency 6. Multimaster 7. Error detection and signaling 8. Automatic retransmission of corrupted messages 9. Distinction between temporary errors and permanent failures of nodes and automatic switching off of defective nodes. 10. High bit rates of up to 1 Mbps Information between various ECU s in an in-vehicle CAN network is communicated in the standard CAN message format which is shown in Figure 4 below. Inter frame Space Inter frame Space or Overload Frame DATA FRAME SOF Control Field Data Field CRC Field EOF Arbitration Field ACK Field Figure 4. Standard CAN DATA Frame 6

14 The length of this message may vary depending on the number of data bytes in the data field; however, the format of the message is fixed. Logic levels on the CAN bus is identified as dominant being a 0 or recessive being a 1. When a dominant and a recessive bits are transmitted simultaneously on the bus by different nodes, the resulting bus state is dominant (Wired-AND implementation). Within any CAN network, data is transmitted using four different frame types. 1. A DATA frame, which communicates data between a transmitter and one or more receivers. 2. A REMOTE Frame is transmitted by a node to request the transmission of a DATA frame with the same identifier. 3. An ERROR Frame is transmitted by any node on the network detecting an error condition. 4. OVERLOAD Fame is used to provide a time delay in the communication between a fast transmitter and a slow receiver. The various fields within a CAN DATA frame are, SOF (Start of Frame) SOF indicates the start of a DATA or a REMOTE frame. It is represented by a single dominant bit Arbitration Field 7

15 The arbitration field consists of the 11-bit identifier and 1-bit RTR (Remote Transmit Request) bit. The identifier defines the priority of the message. Lower the value of the identifier, higher its priority. When two nodes on the bus try to transmit a message simultaneously, the bus access conflict is resolved by a bit wise arbitration of the identifier and the message with a higher priority (lower value of the identifier) wins the access to the bus. During the transmission of a DATA and a REMOTE frame with the same identifier, the DATA frame prevails over the REMOTE frame. ARBITRATION FIELD SOF 11-Bit IDENTIFIER RTR Bit Figure 5. CAN message ARBITRATION Field Control Field The CONTROL field consists of six bits. Two bits (r0 and r1) are reserved for future expansion and they are sent as dominant. Four of the six bits (DLC3-DLC0) form the Data length Code (DLC), which indicates the number of bytes in the following data field. The DLC varies between 0 (dddd) and 8 (rddd) where d= dominant and r= recessive DATA Field 8

16 The DATA field carries the data to be transferred within the DATA frame. The admissible number of bytes in the DATA field varies between 0 and 8. CONTROL FIELD r1 r0 DLC3 DLC2 DLC1 DLC0 Reserved Bits Data Length Code (DLC) Figure 6. CAN message CONTROL Field CRC (Cyclic Redundancy Check) Field The CRC field consists of a 15-bit CRC sequence followed by a 1-bit CRC delimiter. The CRC delimiter is sent as a recessive bit. CRC FIELD 15-Bit CRC Sequence CRC Delimiter 9

17 Figure 7. CAN message CRC Field ACK (Acknowledge) Field This field is two bits long and consists of an ACK slot and an ACK delimiter. CRC Field ACK FIELD ACK Slot ACK Delimiter Figure 8. CAN message ACK Field Any node transmitting a message sends two recessive bits in the ACK field. Any node on the network which receives a valid message flips the bit in the ACK slot to a dominant bit indicating to the transmitter that it received a valid message End of Frame (EOF) Field Every DATA and REMOTE frame is delimited by a flag sequence consisting of seven recessive bits. 10

18 In automotive electronics, engine control units, sensors, actuators and ABS systems are interconnected using a high-speed CAN bus with bit rates of up to 1 Mbps. Figure 9 below illustrates one such high-speed network interconnecting the various control units within a vehicle. The figure 9 shows two types of busses in an automotive body network [12]. The high speed CAN bus (in blue) forms the backbone of the entire network handling safety-critical components like brakes, ABS, power train controls, climate control and the instrument cluster. The LIN (Local Interconnect Network) sub-bus handles low-speed non safety-critical features like mirrors and power windows. Due to its widespread acceptance in the automotive industry, the proposed DR algorithm is based on the CAN protocol. The following section discusses some previously developed DR techniques for automotive in-vehicle networks and highlights their inherent drawbacks. We also discuss one DR algorithm in detail since the proposed algorithm exploits some key capabilities of the same. 11

19 Figure 9. Automotive Body Network, (Courtesy: Hans Christian von der Wense, Introduction to Local Interconnect Network (LIN), Motorola, Munich, Germany, March 2000) 2.2 AVAILABLE DATA REDUCTION TECHNIQUES Many DR techniques have been investigated for automotive multiplexing environment. Michael et al. applied various state-of-the-art data-compression algorithms to automotive multiplexing in an experimental vehicle [3]. From their studies, Kempf et al. [2] and Michael et al. [3] recognized six data reduction algorithms, which could be applied to automotive multiplexing environment. 12

20 1) Simple Huffman coding; 2) Adaptive Huffman coding; 3) Arithmetic coding; 4) Higher order arithmetic coding; 5) Textual substitution coding and 6) Command data stream reference coding [3] Simple Huffman Coding Huffman coding assigns a relatively shorter bit sequence to the symbols having a high frequency of occurrence, and a longer bit sequence to the symbols having a low frequency of occurrence. The main limitation of Huffman coding is the requirement of keeping a copy of the probability table at each node in the automotive multiplexing system. Additionally, one or more bit reversals during data transmission can cause a loss of synchronization at the receiving end. Adaptive Huffman coding is the extension of Huffman code in which the Huffman tree is adjusted on the fly based on the previously seen data Arithmetic Coding In arithmetic coding, first the frequency of each symbol is determined. Once the probability of occurrence of each symbol is known, a range of real numbers is assigned to each symbol. The length of this range is equal to the probability of the symbol. For example, if the symbol has a probability 0.1, then the assigned range of numbers will be 13

21 [0.0 to 0.1]. Following the arithmetic algorithm, a message consisting of a stream of symbols can be represented by a single floating-point number [4] Higher Order Arithmetic Coding An extension of arithmetic coding is higher order arithmetic coding, in which the probability of each incoming symbol is calculated on the basis of the context in which the symbols were previously encountered. After determining these probabilities, encoding of arithmetic coding is used. A higher order arithmetic coding scheme requires a large amount of memory at each node [4] Textual Substitution Coding In a textual substitution algorithm, variable length strings of symbols are encoded into a single token. This token is used as an index to a phrase dictionary maintained at the receiving end [5] Command Data Stream Coding The above mentioned data-compression algorithm has been used to devise another algorithm, CDSR coding. The CDSR coding scheme is especially designed for automotive multiplexing application. In the CDSR scheme, a reference dictionary is maintained at each node in the multiplexing system. When a message is generated, the reference dictionary at the transmitting side is referred, and a token is generated instead of the actual message. This token indicates the position of the first symbol in the transmitted message and the message length. A copy of the message available at the receiving end is located with the help of the transmitted token. Kempf and Strenzal 14

22 further investigated the application of common data-stream coding and proposed a communication protocol to overcome the drawback associated with it [2]. Among all six data-compression algorithms, simple Huffman coding and common datastream coding are two promising candidates for automotive multiplexing [3]. The major drawback of all the DR techniques was that they could only be applied to textdata classes in automotive body electronics [3]. 2.3 A Generalized Data Reduction Algorithm Misbahuddin et al.[6] proposed a generalized data-reduction algorithm that could be applied to all data classes found in automotive multiplexing environment. The algorithm is based on the SAE J1939 protocol [7]. This algorithm uses the fact that some of the bytes in the data field of the J1939 message remain constant over a period of time and that many of them change slowly [8]. For example, car speed, wheel speed, gas level, gear position etc. Also, these messages are sent at periodic intervals of time. For example, wheel speed data may be sent every 5 milliseconds and gas level may be indicated every 500 milliseconds. The bit reserved by SAE for future use or R bit in the protocol data unit (PDU) within the J1939 message is used to indicate data compression. The R bit is set to 1 and 0 to indicate compression and no compression, respectively. Each intelligent control module (ICM) in the multiplexing system consists of a transmit buffer (T_BUF) and a receive buffer (R_BUF). This configuration is illustrated in figure 10 below. 15

23 T_BUF R_BUF T_BUF R_BUF Node - 1 Node - n Figure 10. Automotive multiplexing system consisting of n number of ICM s Each ICM keeps a copy of the most recently transmitted message in the T_BUF and a copy of the most recently received message in the R_BUF. Suppose an ICM transmits a message ri every t time units. The transmitting ICM keeps a copy of message ri in its T_BUF. The next time the ICM transmits a message ri after t time units, the ICM compares the data field of the previous ri, saved in the T_BUF, with the current message being transmitted. In the event that two or more of the data bytes of the current transmitted message are of same magnitude as of the message in T_BUF, the transmitting ICM realizes that few of the data bytes have been repeated. The transmitter then initiates a series of steps outlined below, to implement data compression Data Compression Process 16

24 1. The transmitter sets the R bit or data compression bit (DCB) in the PDU to The transmitter prepares a compression code (CC) to indicate repeated bytes in the recently transmitted message. 3. Each bit in the CC indicates a data byte in the message. The bits in the CC are set to 1 or 0 to indicate a repeated byte or non-repeated byte in the message, respectively. For example, if byte 3 in the message is repeated then bit 3 in CC is set to 1 and so on. 4. The non-repeated bytes are concatenated after the CC in the data field of the message being transmitted over the bus. At the receiver, the ICM keeps a copy of the most recently received message in its R_BUF to perform decompression. The following steps are involved in data decompression process at the receiving end Data Decompression Process 1. The receiver checks the DCB of the received message. 2. If DCB is 1, then the receiver treats the first byte in the data field of the received message as the CC. 3. The receiver retrieves the repeated data bytes by indexing through the R_BUF and fetching bytes whose corresponding bits in the CC have a value 1. For example, byte 3 is fetched if bit 3 in CC is 1. 17

25 4. The entire message is recreated using the repeated bytes from R_BUF and nonrepeated bytes from the received message. This algorithm works very well when data bytes within the message remain constant with high probabilities. However, in real life situations, one or more parameters in the message may fluctuate at low rates. For example, during braking, car speed may decrease at a constant rate say 8 miles/sec 2, or during acceleration the speed may increase at 4 miles/sec 2. Under such conditions, the above protocol would transmit the entire length of the data bytes used to represent the particular parameter even though the change in value of the parameter is very less. In the worst-case scenario, if all the parameters in the message change by small amounts, the algorithm would transmit all the eight bytes of the message without leading to any DR. This is highly undesirable since it would lead to high bus utilization and consumption of unnecessary bandwidth. To overcome this drawback of the previous DR algorithm, we present an Adaptive Data- Reduction (ADR) algorithm. The algorithm is designed to be compatible with the CAN protocol since CAN is the standard protocol used in many present-day automobiles [9]. However, the algorithm can be applied to any SAE J1939 protocol with slight changes in the software. The following section presents the details of the adaptive-data reduction algorithm. 3 PROPOSED DATA REDUCTION ALGORITHM The proposed ADR algorithm consists of two parts 18

26 Non-Adaptive data-reduction Adaptive data-reduction The ADR algorithm encompasses some of the desirable features of the DR algorithm presented in [6] with some notable changes. 1. The R bit or DCB is ignored. 2. The data field of CAN message is divided into signal fields of varying lengths instead of data bytes. This means that individual signal values in the messages can cross byte boundaries or can be contained in less than one byte. Point 2 above springs from the fact that all signal values in a message cannot be contained in one byte. For example, on the one hand, engine RPM requires 16 bits and on the other hand, gear position can be indicated using just 3 bits. A clear understanding of the data field format of the CAN message can be obtained from Figure 11. The engine control module generates this message. Engine speed or RPM occupies two data bytes within the message and engine temperature occupies 7 bits. The following sections explain the details of the ADR technique. 3.1 DATA REDUCTION TECHNIQUE 19

27 An automotive multiplexing system consists of many nodes interconnected between each other using a high-speed bus. The nodes contain sensors, which periodically communicate to send the change in some parameter values to the Electronic Control Unit (ECU), which in turn ensures optimum operation of the entire vehicle by actuating certain precise operations based on the input parameter values. Additionally, each node transmits and receives a fixed set of messages [10]. We have made the following assumptions for the DR algorithm. 1. All messages in the system have their compressed version whose individual signal field lengths (in bits) are predefined based on the periodic message transmission rate and rate of change of the signal parameter. 2. The identifiers of the compressed messages differ from the identifiers of their original counterparts by a value of minus one. For example, if the identifier of a normal CAN message is 20, then, the identifier of its compressed version would be Each CAN node in the network consists of two buffers called TX_BUF and RX_BUF to store the transmitted and received messages respectively. The TX_BUF and RX_BUF consist of two fields. One field stores the 11-bit (or 29-bit) identifier of the CAN message and another stores its 8-byte data field. 20

28 Figure 11. Data field of a CAN message showing various signal fields within the message. Each row indicates a data byte and each column indicates a bit. Some signals within the data field occupy more than a byte where as some others occupy one byte or less Data Compression Each CAN node in the network transmits messages at fixed intervals of time depending on the nature of the message being sent. Let us assume that the transmitting unit of each node transmits messages every t time units where value of t may vary depending on the specific application. A safety critical message will have a very low value for the period t when compared to a non-safety critical message. 21

29 Assume that a CAN node transmits a message ci at time m. At time m, a copy of the sent message ci is stored in the TX_BUF of the transmitting node. When the next ci is being transmitted at time m + t time units, a comparison is made between the data fields of the message stored in TX_BUF at time m with that of the current message being transmitted at time m + t. Depending on the content of the new message, two types of DR techniques can be applied. 1. Non- adaptive DR 2. Adaptive DR Let us explore the two techniques further Non-Adaptive Data Reduction This technique is applied for the case when none of the bytes in the data field of the new message ci at time m + t, change their value since their previous transmission at time m. In such a situation, the entire message at time m + t is not transmitted. The receiving node in the network assumes the most recent value of the message ci as the current value of the message. However, this technique has a drawback. In the event that none of the signal fields in the message ci change their value over a long period of time, the transmitting node will not transmit the message ci until it changes its value. To overcome this shortcoming, a copy of the most recent message ci is transmitted to the receiving node at every y intervals of time where y>>t. The value of y again depends on the safetycritical nature of the message. In the event of sudden and rapid changes in value of the 22

30 signals, for example, during hard braking or hard acceleration, normal transmission of CAN messages over the bus resumes till a steady state is reached Adaptive Data-Reduction Adaptive DR is based on the technique of delta modulation or differential pulse code modulation (DPCM) [11] that is widely used in the area digital communications. It is based on the principle that instead of sending the absolute value of a signal at each time instant, only the changes in the signal values from one time instance to another (delta) are transmitted. To achieve data reduction, the first byte in the data field of the CAN message is used to indicate delta compression. This byte is called the delta compression code (DCC). In the ADR technique, if one or more signal fields in the message ci transmitted at time m + t change their value since their previous transmission at time m, the transmitting node executes the following series of steps. 1. The transmitting node computes a delta compression code (DCC). A value of 1 in the DCC indicates the delta change in the value of the signal rather than the absolute value. A value of 0 in DCC indicates no change in the value of the signal. 2. Since a copy of the message transmitted at time m is stored in TX_BUF, the transmitting node computes differences (deltas) in the value of the corresponding signals in TX_BUF at time m with that at time m + t. 23

31 3. The compressed version of the original CAN message having an identifier whose value is one less than the value of the identifier of the original message is encoded with the delta signal values. 4. The delta-compressed CAN message carrying the delta signals is sent over the CAN bus to the receiving node. 5. In the event that the value of a delta signal exceeds the length of the assigned field, the absolute values of all the signals (i.e. the original CAN message) are transmitted rather than the delta-compressed version of the message. This assumption is based on the fact that a drastic change in the value of a particular signal could reflect a critical condition in which case it would be necessary to communicate absolute values of all signals within the message. The entire data-compression process is depicted using the flow chart of Figure 13. Figure 12 shows the format of the data field of the delta-compressed message of Figure 11. The engine module generates this particular message. The first eight bits of the data field are the DCC. The signals within the delta-compressed message occupy half the number of bytes when compared to the original message of Figure

32 Figure 12. Data field format of delta-compressed message of Figure

33 Begin Yes Is it the first message? No Store message in TX_BUF Compare current message at time m + t with message a t time m. B A Yes Change? N o No Send entire CAN message onto the bus Do not send message onto the bus Yes Message not transmitted for a period y? Figure 13. Adaptive data-reduction algorithm 26

34 B Store message in TX_BUF Is value of delta signal > length of assigned delta field? Yes No A Transmit entire CAN message with absolute values of all signals. Figure 13. Adaptive data-reduction algorithm continued 3.2 Data Decompression The receiving node in the system decompresses the delta-compressed CAN message sent by the transmitter. The following series of steps are executed to perform datadecompression. Assuming that a delta-compressed message Dci is received, 27

35 A Prepare Delta compression code (DCC) Prepare delta-compressed message with DCC and delta signals. Figure 13. Adaptive data-reduction algorithm continued. 1. The receiving node checks the identifier of the CAN message Dci. If the message is a delta-compressed message, the first byte in the data field of the message is treated as the DCC. 2. The receiver then fetches a copy of the most recently received ci from the RX_BUF. 3. The DCC acts as an index to the corresponding signal fields within the deltacompressed message. For example, a value of 1 in the first bit position of the DCC means that the first signal field within the message is a delta signal of the first signal field within the message ci from RX_BUF. This delta signal is either 28

36 added to or subtracted from the corresponding signal field within the message ci from RX_BUF to get the new value of the signal. 4. A value of 0 in the DCC means that the corresponding signal has not changed its value since the previous transmission. The absolute value of this signal is fetched from the previous ci in RX_BUF. 5. The receiver reconstructs all the signals within the message in a similar fashion. 6. The receiver then updates the RX_BUF with this new message, overwriting the previous ci. The first row in figure 14 shows the mapping of the bits in the DCC of the received deltacompressed message. The second row is the delta-compressed message Dci, which holds delta values of all signal fields within any given message. Third row is the most recent copy of the message ci from the RX_BUF. A value of 1 in DCC indicates that the corresponding fields of Dci contain the delta values. In this example, delta signals corresponding to a 1 in DCC are -4, 7 and -5. These delta values are then added to the corresponding signal fields of the previous message ci in RX_BUF. All other signal fields within the new message retain previous values from the ci in RX_BUF. The RX_BUF is then updated with this new message. 29

37 The data-decompression process is illustrated graphically below DCC Dci Previous ci from RX_BUF New message ci in RX_BUF Figure 14. Data-decompression process The entire data decompression process is depicted in the flow chart of Figure 15. The following section presents simulation results for the presented ADR algorithm. 30

38 Begin Yes Is it the first message? Store message in RX_BUF No Check identifier of the message No Delta compressed message? Yes Reconstruct CAN message by adding delta signals in Dci to previous ci in RX_BUF based on DCC and Fetch non-repeated signal fields from previous ci in RX_BUF Figure 15. Data-decompression algorithm 31

39 4 RESULTS AND DISCUSSIONS A simulation program has been developed to analyze the performance of the adaptive DR algorithm. The main performance parameters considered are the bus load, message transmission rate (MTR) and the average length of messages (ALM). The simulation model consists of five CAN nodes each of which transmits a predefined set of messages. The distribution of messages among the five nodes is shown in Table 1. Their corresponding periodic transmission rates are also included. N1 N2 N3 CAN Bus N4 N5 Figure 16. Simulation model consisting of 5 CAN nodes. The simulation model consisting of 5 CAN nodes is shown in Figure 16. Each of the nodes numbered N1 to N5 consists of the TX_BUF and the RX_BUF to store the transmitted and received messages, respectively. 32

40 Table 1. Distribution of messages among nodes in the simulation model All message ID s on the left of the message ID column are the ID s of the deltacompressed message. The simulation has been developed to monitor the behavior of the system during three operating conditions. 1. During transient operation of the system i.e. during engine start and acceleration. 2. During steady-state operation i.e. under cruise control, and 3. During hard braking or deceleration. We will further analyze the performance of the system under these three operating conditions. For the sake of comparison, we will consider the cases when no DR was 33

41 applied and when non-adaptive and adaptive data-reduction techniques were applied under the three operating conditions. Bus-load, the number of data frames per second or MTR and the average length of messages or ALM have been monitored to evaluate the performance of the ADR algorithm. We will first analyze the system performance under the transient and steady-state conditions. 4.1 CASE 1: TRANSIENT AND STEADY-STATE OPERATION The graphs of Figure 17 through Figure 19 compare the simulation results for the system under transient and steady-state, with no DR and when non-adaptive DR is applied. The variation in the MTR is compared in Figure 17 shown below. Figure 17. Message transmission rate (MTR) comparison 34

42 In the transient state, which lasts for sixty seconds after start of simulation, the MTR reaches a peak value of 138 frames per second at time T1 for both the cases, i.e. when no DR is performed and when non-adaptive DR is performed. After the transient period, the system reaches the steady state where all the signals reach a constant value. During the steady state, there is a considerable decrease in the MTR for the case when non-adaptive DR is applied. The MTR falls to 44 frames/second at time T2 reducing the number of message transmissions by 50 in comparison to the case where no DR is used. This gives a compression ratio of 53% over the case when no DR was applied. Figure 18. Bus load Comparison The variation in the bus-load is compared in Figure 18 above. During the transient state, the variation in bus-load is the same for the cases when no DR is performed and when non-adaptive DR is performed. Notable gain in the parameter is made during the steady- 35

43 state operation where majority of the signals do not vary rapidly from one instance to another and hence the message is not repeated unless there is significant change in its value since the previous transmission. During the steady-state operation, the peak busload at time T2 reduced from 18.55% to 7.98% giving a total bandwidth saving of 56% when compared to the case where no DR was applied. Figure 19. Average message length (ALM) comparison Figure 19 above Compares the average lengths of the messages (ALM) transmitted between various nodes during the simulation. The ALM remained constant over majority of the simulation run for the two cases when no DR was applied and when non-adaptive DR was applied. However, as the system approached the steady state, minute reductions in the ALM were observed for the case when non-adaptive DR was applied. This is due 36

44 to the fact that as the system reached the steady state, the small variations in the signals were transmitted in the delta-compressed messages. Figure 20. Variation of different signals during transient and steady state The variation of different signals within a message (in this case engine data) during transient and steady state is shown in Figure 20 above. 37

45 4.2 CASE 2: HARD BRAKING OR DECELERATION The performance of the ADR algorithm during the condition of hard braking or deceleration can be analyzed from the graphs of Figure 21 through Figure 23. The variation in MTR during hard braking with no DR and with ADR is compared in Figure 21 below. During hard braking, the behavior of the system is similar to the behavior during the transient state. The MTR reaches its peak value of 138 frames/second and 137 Figure 21. Message transmission rate (MTR) comparison during hard braking 38

46 frames per second at the instance when the brake is applied at time T2, when no DR and when ADR is applied, respectively. There is no significant reduction in the MTR for the case when ADR is applied since the periodic rate of transmission of the delta-compressed messages is similar to the transmission rates of their uncompressed counterparts. After the period of braking, the system again goes to the steady state. The variation in bus-load is compared in Figure 22 below. The application of brake leads to the transmission of the delta-compressed messages and hence, the peak bus-load at time T2 increases slightly to a value of 16.97%. A total bandwidth saving of 43% was gained in comparison to the case where no DR was applied. Figure 22. Bus load comparison during hard braking 39

47 Figure 23 Compares the ALM for the cases when no DR is applied and when ADR is applied. There is a decrease in ALM when ADR is applied since the delta-compressed messages having a smaller duration are transmitted during the application of brakes. The ALM decreases to a value of 0.2 ms at time T2 when brakes are applied giving a total reduction of (( )/ 0.30)*100= 33% in the ALM when compared to the case when no DR was applied. Figure 23. Average message length (ALM) comparison during hard braking The variation of different signals within a message (in this case engine data) during hard braking or deceleration state is shown in Figure 24 below. 40

48 Figure 24. Variation of different signals during hard braking or deceleration Table 2 summarizes the percentage gain in the values of various performance parameters with the application of non-adaptive and ADR algorithms. % decrease in bus load % decrease in MTR % decrease in ALM Non-adaptive DR 56% 53% 0% Adaptive DR 43% 0% 33% 41

49 Table 2. Gain in the values of performance parameters in comparison to the case when no DR was applied to the system 5 CONCLUSIONS The performance of an adaptive data-reduction algorithm for future in-vehicle networking applications has been presented. The algorithm is based on the CAN protocol and uses the fact that some of the signals within a CAN message do not change their value from one transmission time instance to another. Another observation is that some of the signal values change by small amounts i.e. during cruise control or deceleration. The algorithm exploits the above two observations to decrease the amount of data traffic to be transmitted over the CAN bus. In the first case, the algorithm refrains from transmitting the repeated messages during successive transmitting instances and in the second case, the algorithm transmits only the delta-change in the value of signals from one transmitting instance to another. The ADR algorithm generates a DCC to indicate signals whose corresponding delta values have been transmitted. A dynamic event-based simulation has been developed to analyze the performance of the presented ADR algorithm. The simulation of the algorithm has shown promising results in terms of the reduction in the values of important parameters like message transmission rate (MTR), bus-load and average length of messages (ALM). The reduction in the values of these parameters enables us to cater to the bandwidth requirements of new nodes into the network to provide advanced features like infotainment and active safety etc., without increasing the overall cost of the system. 42

50 6 FUTURE WORK The proposed adaptive data reduction algorithm can handle errors on the CAN bus effectively. In the condition of an error on the bus, all nodes transmitting deltacompressed messages terminate the transmission of delta-compressed messages and transmit the uncompressed version of the messages starting from the next transmitting instance. This way, no node will ever lose track of the messages it was supposed to receive. However, a condition can occur where the error can occur on a node and not on the bus. The CAN protocol being a broadcast protocol, guarantees the recipient of the message that everyone else has received the same message. This might not be the scenario when some of the nodes within the network are faulty. Let us consider one scenario here. Assuming that there are three nodes on the network and one of them (node 3) is faulty. Node 1 sends out a delta value of 20 at time t1. At this time nodes 2 and 3 receive this value of 20 at time t1 (neglecting the transmitting time). After the reception of the delta compressed message at time t1, node 3 goes down but node 2 still acknowledges the reception of a correct message. Now, at time t2, node 1 sends out a delta value of 30. Node 2 will compute the new value as the sum of the previous value i.e. 20 and current value of 30 at time t2. The effective value 50 is the new value of the parameter. However, since node 3 is faulty and has gone down, it will not receive this value of 30 at time t2. It still has a value of 20 from the previous transmission at time t1 as the current value, totally unaware of the current transmission at time t2. When node 3 comes up at a later time, it will consider the current value of the parameter as 20 where as its actual value should have been 50. When node 1 transmits another delta value of say 50 at time t3, node 2 will compute the value of the parameter as the sum of its current value 43

51 which is 50 and the delta value at time t3 i.e. 50 giving an effective and correct value of the parameter as 100. However, node 3 would compute the value of the same parameter as the sum of its current value which is 20 and the delta value at time t3 i.e. 50 resulting in an effective value of 70 which would be erroneous. This type of fault condition is known as a Byzantine error problem[13-16]. To implement the above proposed adaptive data reduction algorithm, fault-tolerance has to be incorporated in the system which becomes imperative for safety critical applications. Future work in this area would be directed towards exploring different techniques which would make the above protocol fault-tolerant. 44

52 REFERENCES 1. S. Channon and P. Miller, The requirements of future in-vehicle networks and an example implementation, SAE paper G. G. Kempf and K. Strenzl, Robust adaptive data compression for peak-load reduction in automotive multiplexing systems, SAE paper , pp G. G. Kempf, M. J. Eckrich, and O. J. Rumpf, Data reduction in automotive multiplexing systems, SAE paper , pp M. Nelson and J.-L. Gailly, The Data Compression Book, 2nd ed, NY: M&T Books, M. Alister, Word-Based Text Compression, Software Practice and Experience. New York: Wiley, 1989, vol. 19/2, pp S. Misbahuddin, S. M. Mahmud and N. Al-Holou, Development and performance analysis of a Data-Reduction algorithm for automotive multiplexing, IEEE Trans. on Vehicular Technology, Vol. 50, No.1, pp Recommended practice for serial control and communications vehicle network (Class C), SAE draft J1939, SAE recommended practice, Vehicle application layer,, SAE J1939/71, Aug Bosch, CAN specification Ver 2.0, Robert Bosch GmbH, Stuttgart, Germany, R. Masaki et al., Development of class C multiplex control IC,,SAE paper ,

53 11. Bill Waggener, "Pulse Code Modulation Techniques: With Applications in Communications and Data Recording (Electrical Engineering)," Kluwer Academic Publishers, 15 January, Hans Christian von der Wense, Introduction to Local Interconnect Network (LIN), Motorola, Munich, Germany, March Rodrigo Rodrigues and Barbara Liskov, Byzantine Fault Tolerance in Long-Lived Systems, MIT Computer Science and Artificial Intelligence Laboratory, L. Lamport, R. Shostak and M. Pease, The Byzantine Generals Problem. ACM Transactions on Prog. Lang. and Systems, 4(3), July K. Tindell, A. Burns, and A. Wellings, Calculating Controller Area Network (CAN) message response times, In Proceedings of the IFAC Workshop on Distributed Computer Control Systems, Toledo, Spain, September 1994, IFAC. 46

54 ABSTRACT AN ADAPTIVE DATA REDUCTION PROTOCOL FOR FUTURE IN-VEHICLE NETWORKS By PRAVEEN KUMAR RAMESH RAMTEKE September 2005 ADVISOR: Dr. Syed Masud Mahmud MAJOR: Electrical Engineering DEGREE: Master of Science The demand for drive-by-wire, pre-crash warnings, telematics and many new features will require very high bandwidth from future in-vehicle networks. One straightforward solution to satisfy the bandwidth requirements of future vehicle networks would be to use a higher bandwidth bus or to use multiple busses. However, the use of a higher bandwidth bus would increase the cost of the network. Similarly, the use of multiple busses would increase the cost and the complexity of the wiring. Hence, neither option is viable solution for satisfying the requirements of high bandwidth. Another option would be the development of a higher layer protocol to reduce the amount of data to be transferred. The higher layer protocol could be acceptable provided it does not increase the message latencies for real time safety-critical applications. The cost of the protocol will be marginal since it will require minor changes in the software and no additional hardware. The amount of data can be reduced in various ways. For example, when cruise 47

55 control of the vehicle is activated, the vehicle speed will be almost the same from one time instant to another time instant. Thus, the electronic control module responsible for sending the vehicle speed can send only one bit instead of the actual speed to inform the recipients that the speed did not change. Similarly, when the change in speed is very small, the electronic control module can send only the amount of change using only a few bits rather than the actual speed using many bits. The protocol can also be made adaptive by allowing it to select different message formats for different conditions of the vehicle. For example, when the vehicle is in the idle state, the message format can be different from the format when it is moving at 60 mph or higher. This work explains the adaptive data reduction protocol in detail and compares its performance with that of a nonadaptive protocol. 48

56 AUTOBIOGRAPHICAL STATEMENT I received my Bachelors degree in Electronics & Communication Engineering from VTU University, Karnataka, India. I have been working in the area of In-Vehicle Networking for the past two years under Dr Syed Masud Mahmud as part of the Intelligent Vehicles and Transportation Systems (IVTS) group at the ECE department, Wayne State University. Over the duration of 2 years as an M.S student, I have pursued my research study in the area of automotive in-vehicle networking protocols namely CAN and TTCAN. I have published 3 technical papers in the related areas of data reduction techniques for invehicle networking protocols namely CAN and fault-tolerant TTCAN system. I formulated and designed various algorithms for the software and hardware architectures for future in-vehicle networks. One of the significant contributions of my thesis work is the development of an adaptive data reduction algorithm for future in-vehicle networks running on the CAN bus. In 2005, I was a lead member of the Wayne State University Formula SAE electrical team. During this period, I designed and implemented the entire electrical system architecture for the formula SAE car. The architecture also incorporated a CAN-based data acquisition system consisting of 5 nodes which ran on a 500 kbps bus. I am currently working as an Electrical Engineer with Inalfa Roof Systems in Auburn Hills, MI. My other interests include traveling, basketball and music. 49

57 PUBLICATIONS 1 Praveen R. Ramteke and Syed Masud Mahmud An Adaptive Data-Reduction Protocol for the Future In-Vehicle Networks, accepted for publications in the 2005 SAE Transactions on Passenger Cars: Electrical and Electronic Systems. 2 Praveen R. Ramteke and Syed Masud Mahmud An Adaptive Data-Reduction Protocol for the Future In-Vehicle Networks, Proc. of the SAE 2005 World Congress, April 11-14, 2005, Detroit, Michigan, USA, Paper Number: Praveen R. Ramteke, Aakash Arora and Dr. Syed Masud Mahmud, Feasibility of Using Vehicles Power Line as a Communication Bus, Proc. of the 4th Annual Intelligent Vehicles Systems Symposium of National Defense Industries Association (NDIA), National Automotive Center and Vetronics Technology, June 22-24, 2004, Traverse City, Michigan. 4 Aakash Arora, Praveen R. Ramteke, Dr. Syed Masud Mahmud, A Fault Tolerant Time Triggered Protocol For Drive-by-Wire Systems, Proc. of the 4th Annual Intelligent Vehicles Systems Symposium of National Defense Industries Association (NDIA), National Automotive Center and Vetronics Technology, June 22-24, 2004, Traverse City, Michigan. 50