Network Traffic Regulator for Diagnostic Messages in Modular Product

(1)

IN

DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS

,

STOCKHOLM SWEDEN 2017

Network Traffic Regulator for

Diagnostic Messages in Modular

Product

(2)

(3)

Network Traffic Regulator for

Diagnostic Messages in Modular

Product

Master of Science in Engineering

Master’s Programme in Computer Science

School of Computer Science and Communication

NIKHIL THAKRAR

thakrar@kth.se

Supervisors: KTH: Arvind Kumar Scania: P¨ar Sundb¨ack

(4)

(5)

Acknowledgements

(6)

Abstract

The aim of this thesis project is to explore a network traffic regulator using bandwidth management techniques that regulates data traffic with the objective to use the network bandwidth to its maximum capacity while ensuring that the network is not overloaded. The bandwidth in the existing network architecture is shared between two co-existing, distinct data flows for on-board communication and diagnostic communication in an in-vehicle network. The diagnostic communication must not interfere with the more critical on-board communication and it should comply with the remaining bandwidth. In the existing solution, fixed delays are imposed on the data traffic which result in a waste of network capacity. The approach presented in this thesis uses two regulation algorithms for different types of diagnostic services. One regulation algorithm is activated for diagnostic services that require data segmentation and multiple data frames to accommodate the transferred data. This algorithm makes use of the Flow Control parameter Separation Time specified in ISO 15765-1:2011 “Road vehicles – Diagnostic communication over Controller Area Network (DoCAN)”. The other algorithm regulates diagnostic services that generate bursts of single frames where data segmentation is not required and it does so using traffic shaping techniques. The results in this thesis show that the network traffic indeed can be regulated for different diagnostic services by using the two mentioned regulation algorithms. The results also show that data is not lost due to high network utilisation and that the bandwidth is used to its maximum capacity without having to impose fixed delays on the network system. The regulator is adaptive in the sense that it can be used for different vehicle configurations with compatible network systems to ensure quality of service and a robust network system.

(7)

Referat

Reglering av n¨

atverkstrafik f¨

or diagnoskommunikation

i en modul¨

ar produkt

(8)

List of Figures

2.1 CAN Data-Flow Model . . . 6

2.2 The fields of Data Frame in extended format . . . 8

2.3 Differences in CAN ID between J1939 and CAN . . . 11

2.4 The structure of 29-bit CAN ID using J1939 . . . 11

2.5 Scania network architecture . . . 13

2.6 OSI model service primitives . . . 16

2.7 Diagnostic request and response messages sent between a client and a server. 16 2.8 Addressing schemes . . . 18

2.9 PCI blocks of different diagnostic frames. . . 19

3.1 The effects of using shaping and policing as bandwidth management func-tions. . . 22

3.2 Token Bucket . . . 22

4.1 Diagnostic access point and CAN interfaces of RTC . . . 25

4.2 Diagnostic access point and two CAN sockets. . . 27

4.3 Bit stuffing example . . . 29

4.4 Base load calculator . . . 34

4.5 Interactive Generator Block (IG) in CANAlyzer . . . 34

4.6 Network architecture with marked egress and ingress network links . . . 36

4.7 Two different shaping algorithms . . . 36

4.8 Read operation data segmentation . . . 38

4.9 Write operation data segmentation . . . 39

4.10 Flow chart of ISO-TP algorithm . . . 41

4.11 Example block of diagnostic request and response . . . 43

4.12 The workings of the Token Bucket algorithm . . . 44

5.1 Bus load comparison: regulator versus CANAlyzer at base load 30% . . . 46

5.4 Modified bus load calculation at base load 30% . . . 48

5.7 Bus load generated by ReadECUIdentification. . . 51

5.8 The total bus load generated by ReadSOPS . . . 52

(11)

5.11 ReadSOPS result graph 1 . . . 59

5.15 WriteSOPS result graph 1 . . . 61

(12)

List of Tables

2.1 7 layers of the OSI model . . . 5

2.2 Bit fields of a CAN Data frame . . . 7

2.3 Cable lengths vs Bit rates . . . 9

2.4 Example of negative response codes and their meaning . . . 17

2.5 Different diagnostic frame types. . . 18

4.1 Maximal CAN frame sizes with varying numbers of data bytes and with bit stuffing . . . 30

4.2 Minimal CAN frame sizes with varying numbers of data bytes and without applying bit stuffing . . . 30

4.3 CAN bit rates and corresponding bit times . . . 31

4.4 CAN analysis of bit rates, transmission times, frame sizes and frequencies 31 4.5 Format of CAN ID when using SocketCAN . . . 32

4.6 Cycle times of a CAN frame of 150 bits and the corresponding generated bus loads . . . 35

4.7 Diagnostic services chosen for analysis . . . 40

5.1 Difference in frame sizes as calculated by RTC and CANAlyzer . . . 48

5.2 ReadECUIdentification sub-services . . . 50

5.3 Generated bus loads of the ReadECUIdentification sub-services . . . 51

5.4 Execution time, frequency (frames/s) and bus load of ReadECUIdentifica-tion with different STmin values . . . 52

5.5 Bus load analysis of ReadECUIdentification using CANAnalyzer with STmin=0 52 5.6 ReadSOPS sub-services . . . 53

5.7 Execution time, frequency (frames/s) and bus load of ReadSOPS with different STmin values . . . 53

5.8 Analysis of ReadSOPS using CANAnalyzer and STmin=0 . . . 54

5.9 WriteSOPS sub-services . . . 55

5.10 Execution time, frequency (frames/s) and bus load of WriteSOPS with different STmin . . . 56

5.11 Analysis of WriteSOPS using CANAnalyzer and STmin=0 . . . 56

5.12 ReadSOPS summarised results . . . 59

5.13 WriteSOPS summarised results . . . 61

(13)

Chapter 1 Introduction

A modern heavy-duty vehicle comprises several Electronic Control Units (ECUs) that are networked together by a bus communication system. ECUs are micro controller-based modules that work according to the input-processing-output principle; they convert input signals to output signals to perform specialised functions in the vehicle. Some examples of ECUs are the Engine Control Module (ECM), Transmission Control Module (TCM), Brake Control Module (BCM), Anti-Lock Braking system (ABS) amongst others. Many functions require multiple input and output signals handled by different ECUs. For in-stance, the input signal containing the information that the vehicle is currently in reverse gear is not only used by TCM, but also by the light control module to switch on the backup light, ECM and ABS. Moreover, in order to prevent emissions from entering the passenger compartment when driving in reverse, the same signal is used to automati-cally switch the air conditioner to air-circulation. There are many functions as the one just described that would not be possible without the ability of the ECUs to exchange data between themselves. This communication is commonly referred to as the on-board communication and as it is very critical for the proper functionality of the vehicle, cer-tain requirements are enforced on the underlying in-vehicle network such as minimum latencies.

(14)

1.1 Problem Description

The on-board communication and the diagnostic communication take place on the same network and the bandwidth must consequently be shared. The on-board communication exerts a load on the network referred to as the base load and it varies in magnitude according to how many ECUs that are included in the network system. The messages that are exchanged between the ECUs are mostly sent periodically according to predefined intervals and they constitute the so called normal network traffic, i.e. what results from normal operation of the vehicle without performing any diagnostic services. Likewise, the diagnostic communication exerts a load on the network, however, in contrast to the base load which is ever-present in the network, the diagnostic bus load is zero during normal usage of the vehicle.

There are a few complications that stem from letting the on-board and the diagnostic communication share the same network. One such complication is that the diagnostic traffic can interfere with the on-board communication by for example starving the latter. To combat this, a decision was made at Scania to assign the lowest priority to diagnostic messages [4]. The communication bus widely used in the automotive industry, including Scania, is called Controller Area Network (CAN). The CAN network schedules messages on a priority basis; in situations where several network messages simultaneously try to transmit on the network bus, the message with the highest priority has precedence over the bus [15]. However, there are situations where a diagnostic message in the absence of other higher-priority messages transmits on the network bus and which generates a considerable amount of network traffic, forcing other messages arriving later to have to wait until the diagnostic communication has terminated. Among the enqueued messages waiting for transmission high-priority messages can also be found.

Another complication is that the capacity of the network bus is limited [24]. If the bus load goes up too high, messages can be dropped and the network consequently enters an erroneous state. This is an undesired outcome as the messages that are dropped would have to be retransmitted and ultimately cause unwanted delays. Furthermore, it is undefined behaviour which messages are discarded during high network utilisation, hence even high-priority messages can get dropped. In order to avoid over-loading the network, a solution of adding fixed delays to diagnostic messages has been implemented. The value of the delay is obtained by looking at a worst case configuration that contains a very large number of ECUs and by measuring how much bandwidth is required for the on-board communication for that configuration. Such a configuration is highly unlikely to ever be produced and the delay is very pessimistic as the big majority of vehicle configurations would require much smaller delays and thus network capacity is wasted.

(15)

restriction on the capacity and where the data flows behave differently in different vehicle configurations is what make Scania vehicles a good case study for developing methods for bus load balancing.

1.2 Research Question

This thesis project aims to devise a method as an answer to the following research ques-tion:

In a network system with two co-existing, distinct traffic flows, how can the network bandwidth be used to its maximum capacity while ensuring that the network is not overloaded and without imposing fixed delays in the network system?

1.3 Purpose

The overall purpose of this thesis project is to develop an alternative approach to using fixed delays, which exploits available bandwidth management techniques for implement-ing a network traffic regulator for diagnostic messages in an in-vehicle network. The objective is to use the network bandwidth to its maximum capacity while ensuring that the network is not overloaded and without imposing delays on the network traffic. One prominent characteristic of the regulator is that it is adaptive in the sense that it can regulate the network traffic for any vehicle configuration. There can be cases where the regulator allows the diagnostic communication to proceed unhindered and at full speed for certain configurations and other cases where the regulator keeps the diagnostic com-munication under tight control.

1.4 Contribution

(16)

Chapter 2 Vehicle Control Communication

System and Diagnostics

This chapter aims to explain the widely used in-vehicle network called Controller Area Network (CAN) as well as how diagnostics on heavy duty vehicles is applied in a network architecture using CAN.

2.1 Bus Communication

A bus is a topology of a communication network that allows several peripherals to be connected over the same set of wires [25]. The advantage of cost and weight savings is what has driven the adaptation of the bus topology as the standard for the communication system used in the automotive industry. Buses are easy to implement and to extend and the failure of one connected node has no negative bearing on the overall system. However, since all of the nodes share the same communication line in a bus system, there is a need of methods for handling and avoiding collisions when two or more nodes are attempting to transmit simultaneously. One disadvantage with the bus architecture is that if a cable breaks it can disable the whole bus network [35]. Currently, a number of different vehicle communication systems are available in the automotive industry and among the established standards the Controller Area Network (CAN) is the most widely used.

2.2 OSI Model

(17)

OSI layers use control information referred to as headers and trailers to communicate with peer layers. Headers and trailers are attached to the data that is passed down from upper layers. The headers, trailers and the data are commonly referred to as Protocol Data Unit (PDU).

Layer Name 7 Application layer 6 Presentation layer 5 Session layer 4 Transport layer 3 Network layer 2 Data Link layer 1 Physical layer

Table 2.1: 7 layers of the OSI model

2.3 Controller Area Network

Controller Area Network, CAN, is an asynchronous, multi-layer serial bus communication protocol that supports real-time distributed control at up to speeds of 1 Mbit/s [27, 32]. CAN was designed by Robert Bosch in the 1980s to provide simple, efficient and robust communications for in-vehicle networks [15, 18]. The CAN protocol has been standardised as ISO 11898 and apart from automotive applications, CAN is also used as a generic embedded communication system for micro-controllers as well as a standardised communication protocol used in industrial control systems [2].

(18)

that are not relevant to them, and by so doing, reduce the bus load at the receiving nodes [11, 18]. Figure 2.1 shows an example of inter-connected ECUs in a CAN network, where node 1 and node n contain filters that match the data sent by node 2. Node 3 simply ignores the data message.

Figure 2.1: CAN Data-Flow Model

The CAN specification describes two different message formats: the standard format (CAN V2.0A), which uses 11 bits for the CAN ID, and the extended format (CAN V2.0B), which uses 29 bits for the CAN ID [18].

Carrier Sense Multiple Access with Collision Detection (CSMA/CD) is a communication protocol used when multiple nodes share the same medium for communication, as in the case of CAN. As the name suggests, the nodes must first “sense”, i.e. read the bit values on the bus and wait for a period of inactivity in order to start the message transmission. Because all nodes have equal rights to transmit messages, there must exist support for Collision Detection (CD). Each node is constantly listening on the network, even the transmitting node itself. This way, if two nodes happen to transmit on the network at the same time, both of them will be aware of the collision. CAN employs a non-destructive bitwise arbitration method to resolve bus access conflicts by using the CAN ID [11, 31]. The CAN bus can have one of the two complementary logical values: recessive or dominant, with the recessive value representing a logical 1 and the dominant value representing a logical 0. During simultaneous transmission of dominant and recessive bits, the resulting bus value will be dominant [31]. The state of the bus thus always reflects the state of the message ID with the highest message priority i.e. with the numerically lowest CAN ID. Each node can determine if it is sending the message with the highest priority and thus continue to transmit on the bus or whether it should stop the transmission and make another attempt the next time the bus is in an idle state [18]. The arbitration method guarantees that neither information nor time is lost during bus transmission, hence the name non-destructive arbitration. Moreover, the transmitted messages in the network can be thought of as sharing a single global priority-based queue and the messages are transmitted according to a fixed priority, non-preemptive scheduling. A blatant drawback with non-non-preemptive scheduling is that in the worst-case scenario, a high priority message may have to wait for a lower priority message to finish transmitting [20].

(19)

having to make any modifications on the remaining ECUs or the CAN network as a whole [17]. One important point to consider is that all nodes share the same bandwidth and the busload of one particular node is the same for all other nodes. Given this characteristic, caution must be taken when adding new nodes to the network.

In order to achieve design and implementation transparency and flexibility, CAN has been structured to represent the physical layer and the data link layer of the OSI model [32]. The scope of the physical layer is the actual transfer of bits between the nodes in the network as well as all the electrical properties; dealing with bit timing, bit encoding/de-coding, and synchronisation. The data link layer has been organised into the sub-layers: Logical Link Control (LLC) and Medium Access Control (MAC). The LLC sublayer provides services for data transfer and for remote data requests, it decides which mes-sages are to be accepted i.e. message filtering and it also provides means for recovery management and overload notifications. The scope of the MAC sub-layer is the transfer protocol, which includes message framing, arbitration, acknowledgement, error detection and signaling. The MAC sub-layer also decides whether the bus is free for a node to start transmitting [15].

The CAN specification describes four different CAN frames with different functions. • Data Frame

• Remote Frame • Error Frame • Overload Frame

The data frames carry the data to be passed from the transmitter to the receivers. A remote frame is transmitted by a node to request the transmission of a data frame from another node in the network. An error frame is transmitted once a bus error has been detected by any node. The overload frame is used to provide for an extra delay between the preceding and the succeeding data or remote frames. The data and the remote frames can be used in the standard as well as the extended frame format.

2.3.1 Data Frame

The data frame consists of 7 different fields, as illustrated by table 2.2. Abbreviation CAN Bit Field

SOF Start of Frame ARB Arbitration Field CTRL Control Field DATA Data Field

CRC Cyclic Redundancy Field ACK Acknowledgement Field EOF End of Frame

(20)

SOF

SOF marks the beginning of a data frame and it consists of a single dominant bit. A network node is only allowed to start transmission when the bus is idle. All nodes have to synchronise to the leading edge caused by the SOF of the node starting the transmission first.

ARB

ARB differs in the standard and the extended format. As previously mentioned, the arbitration field in the standard format consists of 11 bit CAN ID and the extended format consists of 29 bits CAN ID. In the latter, the CAN ID is divided into two sections: Base ID of 11 bits and Extended ID of 18 bits. The Base ID corresponds to the 11 bits ID in the standard format.

Figure 2.2 illustrates an entire CAN frame in the extended format.

Figure 2.2: The fields of Data Frame in extended format

Besides the 29 bits representing CAN ID, the ARB field also consists of three bit flags: RTR (Remote Transmission Request) used to distinguish data frames and remote frames.

For data frames this bit value is dominant.

SRR (Substitute Remote Request). Replaces the RTR bit in the standard CAN frame format as a placeholder.

IDE (Identifier Extension) indicates that there are 18 more bits to follow of the CAN ID.

CTRL

(21)

CRC

The CRC field is 16 bits long and it contains a CRC sequence followed by a CRC Delimiter. The CRC sequence is a cyclic redundancy code of length 15 bits used for error checking and for detecting any accidental changes in the bit stream. The CRC sequence is followed by CRC Delimiter, which consists of a single recessive bit.

ACK

ACK is 2 bits long and it consists of ACK slot and ACK delimiter. The receiving nodes check the consistency of the messages they receive and acknowledge the ones that appear consistent or, conversely, flag for inconsistent messages. The CRC sequence is used by the receivers to verify the consistency of a message. The transmitting node sends the two bits of the ACK field as two recessive bits. The receivers, upon receipt of a valid message, report this to the transmitter by sending a dominant bit during the ACK slot, which effectively overwrites the recessive bit set by the transmitter. As previously discussed, all nodes in the bus participate in each bit as it is being written. The device sending a message is also receiving that message itself, checking each bit as it is being written. If a message is not acknowledged by at least one node in the network, the transmitting node sends out an error flag. A consequence of this practice in the CAN protocol is that a minimum of two nodes must be used to initialise communication on a CAN bus [17]. An interesting consequence of how the acknowledgement is handled is the trade-off be-tween the bit rate and the maximum bus length [17]. Looking at table 2.3, it is apparent that the bit rate decreases as transmission distance increases. The requirement of a node to be able to overwrite a recessive bit in the ACK slot and for the transmitting node to detect this change, is what limits the combination of physical length and the speed of the CAN bus [18].

Bus Length (m) Bit rate (kbps)

40 1000

100 500

200 250

500 100

1000 50

Table 2.3: Cable lengths vs Bit rates

EOF

(22)

2.4 Time synchronization using bit stuffing

The CAN bit stuffing algorithm plays an important role in the protocol time synchroni-sation process, which aims to coordinate the independent clocks in the network nodes. It is used to maintain detectable bit transitions required for proper protocol bit timing by assuring that adequate resynchronisation occurs during the message transfer. Long data lengths may cause problems with synchronisation and thus lead to erroneous bit detection since each node in the network has its own clock generator. Since a long string of recessive or dominant bits would complicate the synchronisation, the CAN protocol inserts one recessive bit after a sequence of 5 consecutive dominant bits or, conversely, one dominant bit after a sequence of 5 consecutive recessive bits to maintain synchronisation. Due to the bit stuffing mechanism, the distance between edges in the bit stream is at most 5 bits [23]. The excess bits are removed after the transfer so that the receiving nodes see the original bit pattern. For example, if a node transmits a message with CAN ID 0x7FF (11111111111), the CAN controller inserts a bit of the opposite logical value “0” after the 5th and the 10th “1”, effectively rendering the identifier of the message as it is being transmitted on the bus to 1111101111101. Out of the CAN bit fields in table 2.2: SOF, ARB, CTRL, DATA and the CRC sequence are coded by the method of bit stuffing [19]. The number of stuffed bits depends on the message content, which consequently means that CAN frames have varying lengths depending on the encompassed data [27].

2.5 J1939 Standard

SAE (Society of Automotive Engineers) developed the J1939 standard on top of the CAN protocol to be used in the heavy-duty truck industry as well as for industries ranging from agriculture, construction, forestry and other off-highway heavy-load machinery [3]. The J1939 standard, in contrast to CAN, covers specifications on the higher layers of the OSI model and by doing so, gives a more specific application. Since the J1939 standard is built on CAN it shares some of CAN’s advantages such as:

• High reliability

• Collision free and bus arbitration methods

• Fault confinement and error detection techniques

J1939 uses the normal fixed addressing and the extended format, which means that all the information regarding addressing is contained in the 29 bits of the CAN ID [12].

2.5.1 J1939 vs. CAN Message Format

(23)

Figure 2.3: Differences in CAN ID between J1939 and CAN

The J1939 header consists of the following fields:

Priority three bit field used for arbitration purposes with values ranging from 0 (0002) to 7 (1112). 0 is the highest possible priority and 7 the lowest

R reserved bit for future purposes. Its value is dominant in the data frame DP Data page, also reserved for future purposes

PDU Format (PF) eight bit field that determines whether the message is to be trans-mitted with a destination address or if the message is to be broadcasted into the network. When PF takes on a value in the interval 0-239, the message is sent to a specific address, PDU 1. If, however, the value is higher, i.e. somewhere between 240-255, the message is broadcasted in the entire network, PDU 2

PDU Specific (PS) eight bit field, whose content is dependant on which PDU type is defined in the PF field. If PDU 1 is used, PS contains the destination address of a single node and is commonly abbreviated as TA for Target Address. In the case of PDU 2, PS represents the Group Extension (GE). The Group extension expands the number of possible broadcast Parameter Groups that can be represented by the identifier.

Source Address (SA) Eight bit field representing the address of the sending CAN node.

The fields: priority, R, DP, PF and PS together form the Parameter Group Number, PGN which uniquely identifies a message’s content.

An example is given to conclude the J1939 standard. The CAN ID: 0x98DA17FA (10011000110110100001011111111010) can be divided into the fields as illustrated by figure 2.4.

(24)

The first three bits are discarded as the identifier only consists of 29 bits. The subsequent three bits represent the message priority: 1102, i.e. 610 in this example. Priority 6 is typically the priority given to CAN frames carrying diagnostic data. PGN takes on the value 0xDA17FA. The value of PF is 0xDA, which is the hexadecimal value for 218 in decimal. Since 218 lies in the interval 0-239, the message is destination specific. PS thus contains the target address, which is 0x17 in this case. The last byte is the source address, 0xFA.

The data field is always 8 bytes in the J1939 standard.

2.6 ECUs

Automotive ECUs have three scopes of functions [25]:

1. According to the application software, ECUs convert digital or analog input signals from sensors to digital or analog output signals to control actuators. Both input and output signals can be transferred via an in-vehicle network, such as CAN. Typical functions provided by the application software include: ignition timing, anti-lock braking, electronic stability control, traction control, air conditioning and so forth. 2. Transmit data to and receive data from other ECUs. This kind of communication

is called on-board communication.

3. Support diagnostic protocols that enable the ECU to process and respond to diag-nostic service requests from an external tester.

2.7 Network Architecture and Diagnostic Access Point

(25)

Coordinator (COO), bridges and filters the information flow between the segments. The bus load on each segment varies in magnitude according to the number of ECUs that are part of the segment and also on how many messages they transmit as part of the on-board communication. The red segment has the highest network load, followed by the yellow and lastly the green segment. Figure 2.5 is just one example of what a particular vehicle configuration at Scania can look like.

Figure 2.5: Scania network architecture

2.8 On-board Diagnostics (OBD)

(26)

2.9 Diagnostic Communication

Thus far, what has been discussed is the data communication between ECUs, i.e. the on-board communication using CAN. Besides the on-board communication, an external tester can communicate with ECUs in form of diagnostics requests and responses, also by using the CAN network. This sort of communication between an external tester and ECUs is referred to as diagnostic communication. The aim of the following paragraphs is to discuss more in-depth the different aspects and the workings of diagnostic communication using CAN.

Diagnostic services assist service technicians in identifying and repairing malfunctions. It reduces the overall repair time and increases service quality and customer satisfaction. State-of-the-art diagnostic systems also provide the capability of reprogramming ECUs by flash-download [33]. Other examples of diagnostic operations are the monitoring of sensors and actuators, detection of shortcuts and cut-offs, management of memory and so forth. The goal is to verify function and performance of electrical and mechanical systems, to ensure that components are fault-free while meeting functional duties, and to accurately identify specific failure modes [12].

Diagnostic communication is only possible if a diagnostic protocol is implemented. For this purpose the ISO-standard ISO 15765-3 “Diagnostic Communication over CAN” [7], abbreviated as DoCAN, was developed. The standard is divided into four parts, each of which specifies the protocol according to the OSI layers. DoCAN specifies the possibility of addressing individual ECUs (physical addressing) or a group of ECUs (functional addressing), the format of diagnostic messages, the transferring of data larger than 8 bytes with segmented CAN frames and the timing of CAN messages for flow control, among other things. The automotive industry has during the years learnt that proprietary bus systems and diagnostic protocols are unrewarding. Vehicle manufacturers and suppliers are instead opting for standardisations; the Unified Diagnostic Services (UDS) protocol was developed with this in mind and it provides the unification demanded by the vehicle manufacturers and suppliers. UDS is a common set of diagnostic services for vehicles using CAN, specified in ISO 15765-3 as well as in ISO 14229-1. Both of the ISO standards are complementary and they together specify the application layer for UDS on CAN. Another example of a standardised diagnostic protocol is the KeyWord Protocol 2000, KWP 2000 [12, 33].

The services in UDS are grouped into functional units as follows [28]: • Diagnostic and communication management

• Data transmission

(27)

Diagnostic and communication management includes, among other things, session man-agement. There exists different types of sessions and each with different levels of privileges to carry out certain types of diagnostic operations. If a tester tries to perform a diagnos-tic service which is not allowed in the current session, the ECU responds with a negative response [28]. Another example of a diagnostic service that falls under the same category is Communication Control; it activates/deactivates sending and receiving of CAN frames to/from ECUs. This increases available bandwidth when for example performing flash programming [28].

Examples of diagnostic services for data transmission are Read Memory By Address and Write Memory By Address [6, 10]. Read Memory By Address allows a tester to request data by specifying a memory address from where the ECU should read out data. Write Memory By Address allows a tester to provide data to be stored in a specified memory address in the ECU’s memory. The ECU only performs the diagnostic operation if the correct session is set.

Stored data transmission allows a tester to read so called Diagnostic Trouble Codes (DTCs) stored in the ECUs. Upload and download makes it possible for a tester to both upload and download files.

In the context of diagnostic communication a tester is sometimes also referred to as a client and ECU as server. These designations are used interchangeably in the report. The client and the server support diagnostic communication using so called diagnostic service primitives, which include: request, indication, response and confirmation. If a tester transmits a message that contains a diagnostic service request an ECU, the diagnostic application will pass the message to the application layer. The application layer, in turn, passes the message to the presentation layer, and so forth all the way down to the physical layer. At the physical layer, the data is relayed on the physical medium and sent across the network to the ECU. The ECU reads the data from the physical medium and passes the data up to the data link layer and so on until it reaches the application software of the ECU. Each layer of the tester communicates with its respective peer layer of the ECU. Figure 2.6 illustrates that there is a logical point-to-point connection between the application layer of the tester (client instance) and the application layer of the ECU (server instance). Step 1: the application layer of the client transmits a request to the transport layer. Step 2: the application layer of the server receives an indication, which also requires performing an operation. Step 3: as soon as the ECU’s application software has processed the indicated request, the response is sent to the transport layer. Step 4: the transport layer transmits the data per confirmation to the tester.

(28)

Figure 2.6: OSI model service primitives

2.9.1 Structure of Diagnostic Services

Diagnostic communication is based on diagnostic requests sent by a tester to one or more ECUs, and diagnostic responses sent by an ECU to a tester. Figure 2.7 illustrates this ex-change of diagnostic data in form of requests and responses. Both requests and responses have well-defined, unique Service Identifiers, SIDs. Besides the SID, the request/response also contain additional data known as data parameters. The protocol specifies which data parameters are mandatory and which are optional for each service [25]. A SID is one byte long and commonly represented as a hexadecimal-coded value. Hence, 256 unique diag-nostic services with values between 0x00 and 0xFF are available. The purpose of the parameters is to describe what the service should do. For example, the diagnostic service with SID 0x10 tells the ECU to change the diagnostic session and the parameter sent along with the SID specifies which diagnostic session to activate.

Figure 2.7: Diagnostic request and response messages sent between a client and a server. A response can be either positive or negative. A positive response is sent by the ECU if its diagnostic function successfully processed the response. The standards prescribe that the response SID should be the corresponding request SID added by 0x40.

Response SID = Request SID + 0x40

(29)

no support for the requested service in the current session, exceeding defined time lim-its, among others. As stipulated by the diagnostic standard, a negative response has a fix negative response SID: 0x7F. A negative response is always accompanied by a byte that represents the reason for the rejection, called the Negative Response Code, NRC [25].

Table 2.4 contains examples of some NRCs and their meaning. NRC Meaning

0x11 The requested service in not supported

0x21 The ECU is temporarily unable to perform the required operation. Repeat the request 0x13 The message length or the format of the request is not valid

0x84 Engine is not running 0x85 Temperature is too high 0x88 Vehicle speed is too high 0x8F Brake pedal not pressed

Table 2.4: Example of negative response codes and their meaning

2.9.2 Addressing Schemes

Addressing is an essential component in diagnostic communication. To send a request to a specific ECU, the tester needs to know the address of the ECU, and conversely, the ECU must know the address of the tester in order to send a response back. The diagnostic protocols use CAN IDs for addressing. Furthermore, there are two ways to address ECUs: physical addressing and functional addressing. Physical addressing involves a 1-to-1 relationship between the tester and the ECU. Both the tester and the ECU have unique IDs and if the tester sends a request to a specific ECU, the ECU will send back a response to where the request originated from. With functional addressing, however, more than one ECU is addressed at the same time. When the tester sends a request to a group of ECUs, responses from more than one ECU are expected, i.e. a 1:n relationship. One advantage of using functional addressing is that the bus load can be reduced on the network as only one service request is needed, as opposed to sending several service request to individual ECUs [25].

(30)

(a) Physical addressing (b) Functional addressing

Figure 2.8: Addressing schemes

2.9.3 Data Segmentation

The CAN specification dictates that a maximum of 8 bytes of data can be sent in a CAN frame. Many times, however, data of larger sizes are exchanged between the tester and the ECUs, and for this purpose a mechanism called data segmentation is provided by the transport and the network layers [25]. Both the tester and the ECU can initiate data segmentation, i.e. both request and response messages that do not fit a single data frame can trigger data segmentation.

There are four different types of diagnostic frames [9], see table 2.5. The frames are specified by so called Protocol Control Information (PCI) blocks that serve to identify the frame type [12]. The PCI bytes are encapsulated in the data field of the CAN frame. The different frame types differ in their content, format and length of PCI bytes. A message containing data that fits a single CAN frame is transferred as a Single Frame (SF) and does not need data segmentation. SF has one PCI byte; the first nibble (bit 7 through 4) contains the frame type identifier: 0 and the second nibble contains the data length in bytes from zero to seven.

Frame Type Frame Type Identifier (hex) Single Frame (SF) 0x00

First Frame (FF) 0x01 Consecutive Frame 0x02 Flow Control (FC) 0x03

Table 2.5: Different diagnostic frame types.

(31)

affirms the FF by sending a Flow Control (FC). The FC contains important information about the capabilities of the receiver that the sender must adhere to, giving the receiver the possibility to control the traffic flow using flow control parameters. FC contains the following three PCI bytes:

Flow status (4 bits) Indicates whether the sender can proceed with the message trans-mission

Block Size (BS) (8 bits) Defines the maximum number of consecutive frames (CFs) the sender is allowed to transmit before the receiver is expected to transmit another FC. If the block size is zero, the transmitter transmits consecutive frames without waiting for further flow controls.

Separation Time (ST) (8 bits) Determines the minimum time slot between the trans-mission of two consecutive frames.

The first nibble in FC contains the frame type identifier: 3. The second nibble contains the flow status. The second PCI byte contains the block size and the third byte contains the separation time. Values from 0x00 to 0x7F determine a separation time from 0 ms to 127 ms. The flow control parameters are necessary to avoid overloading at the receiver’s side in terms of data volumes and time.

Finally, Consecutive Frames (CFs) contain the rest of the segmented diagnostic data. CF has one PCI byte: the first nibble contains the frame type: 2, and the second nibble contains the sequence number between 1 and 15; 1 represents the first CF and 15 is the maximum sequence number (0xFF). If more CFs are needed, the sequence number counter restarts at 0 [12].

(32)

Chapter 3 Bandwidth Management

Bandwidth management is the art of measuring and controlling the traffic on a network link with the aim of avoiding overfilling the network link capacity, which can result in network congestion and an over-all poor network performance. Bandwidth management, besides managing the bandwidth in a network system, also includes managing delays, delay variations (jitter), packet loss, among others [16]. It goes hand-in-hand with the concept of Quality-of-Service (QoS).

3.1 Related Work

(33)

The article explains nicely how traffic shaping can be used as an approach for bandwidth management in a network. The article also mentions the Token Bucket algorithm, which is a potential candidate for a shaping algorithm to be used in the regulator. The following paragraphs delve deeper into the concept of bandwidth management and traffic shaping, as well as the Token Bucket algorithm.

3.2 Traffic Shaping

Below follows a list of the most common network traffic management functions that are commonly used to provide QoS:

Traffic shaping Controls network traffic by buffering and smoothing the output rate to ensure that the traffic conforms to configured limits

Scheduling algorithms Directs the network traffic to various types of queues and ap-plies an algorithm that decides which network package to send into the network next

Congestion avoidance

Policing Limits the rate of the in-coming network traffic. If the traffic exceeds the defined limits, the traffic data is either dropped or remarked and forwarded onto the next network device

Traffic classification Categorises network traffic according to some policy in order to apply QoS techniques to each class of traffic in different ways.

Traffic shaping controls traffic by buffering and smoothing the network traffic before it enters the network with the purpose of adapting the network traffic to configured limits. It is used to prevent overflowing the network links and for preventing network congestion. The shaping algorithms allow users to get the maximum of their allocated bandwidth, without getting disconnected when the network is being heavily utilised [13].

Network traffic that does not confirm to the desired traffic profile is buffered for later transmission to maintain a desired traffic flow profile. Care must be taken that the buffer contains sufficient memory to buffer the excess traffic. Traffic shaping requires a scheduling function for the packets that have been enqueued for later transmission. Examples of scheduling functions are Class Based Weighted Fair Queuing (CBWFQ), Low Latency Queuing (LLQ), and First In First Out (FIFO) queuing. The fact that excess traffic diverging from defined limits are buffered, means that queuing delays can be introduced [14, 16].

(34)

Figure 3.1: The effects of using shaping and policing as bandwidth management functions.

In the following section one of the most famous traffic shaping algorithms; Token Bucket, is explained

Token Bucket

Figure 3.2 shows a schematic illustration of the token bucket algorithm. The algorithm is an analogy of a fix-sized bucket into which tokens are added at a fix rate r. The tokens are usually represented as units of bytes or single packets of fix sizes. If the bucket contains the maximum number of tokens, T Bmax, no more tokens are added to it. An in-coming packet can only be transmitted if the bucket has a sufficient number of tokens in the

(35)

(36)

Chapter 4 Material and Method

This chapter presents the materials that were required for implementing the regulator, including the hardware and the software systems. The chapter also covers the method and the steps that were taken to realise the regulator.

4.1 Network Architecture and Diagnostic Access Point

As mentioned in section 2.7, the network architecture at Scania consists of three main CAN segments: red, yellow, and green. The red segment contains the most talkative ECUs and it puts the highest base load on the network out of all the segments. The ECUs that reside here are responsible for more time critical applications with hard real-time constraints. ECUs with slightly lower real-real-time requirements reside on to the yellow segment. The yellow segment is also highly active and puts a considerable load on the network, but to a lesser degree than the red bus. The green segment puts a low load during normal operation of the vehicle and it is here that the OBD port for diagnostic communication is located.

The Coordinator (COO) is a gateway ECU that lies between the segments. It bridges and filters the information flow between the segments. COO has buffers in which it can save in-coming frames. There is a delta bus load at the COO and the segments can have different bit rates. The segments are unaware of the bus loads in the other segments; the diagnostic tool connected to the green segment is unaware of the bus loads on the yellow and the red segments. Diagnostic data is sent with the highest possible speed on the green segment and COO has to store this traffic in internal buffers as it cannot be written at the same speed to the yellow and the red segments because of the high bus loads there. The buffer in COO is a FIFO type queue with limited capacity and the problem here is that if a lot of diagnostic traffic is generated on the green segment, the buffer will eventually overflow and frames are dropped as a consequence.

(37)

operating in Linux with a real-time kernel and its main purpose is to perform remote diagnostics and data transfer and it has communicative modules for 3G, Bluetooth, WiFi as well as a built-in modem for transferring data between the vehicle and external servers. Such a relocation of the OBD port to the RTC is only possible due to the fact that RTC has more than one CAN interface; one which is used to connect to the yellow CAN segment, and the other can be used for creating an OBD bus. As the yellow segment typically has a considerably higher base load, the COO runs lower risk to overflow its buffers.

Figure 4.1 shows the system architecture of RTC and its CAN interfaces. The CAN controller CAN0 connects the ECU to the yellow CAN segment and effectively to the rest of the CAN network, and CAN1 is used for the OBD bus.

(38)

The RTC uses SocketCAN for the CAN communication.

4.2 SocketCAN

SocketCAN is an implementation of the CAN protocol in the Linux kernel. It uses the Berkeley socket API (the Linux network stack) and abstracts the CAN controller device drivers as network devices, which allow the CAN messages to be passed from the hardware device to the network layer [5]. The CAN socket API has been designed to be as similar as possible to the TCP/IP sockets so that programmers with experience in network programming easily can get started with CAN sockets. The typical Linux system calls like: bind(), read() and write() are also used to communicate with CAN devices. Just like TCP/IP, a socket must initially be opened for communication over a CAN network. There are two CAN protocols to choose from; the raw socket (CAN RAW) protocol and the broadcast manager (BCM). CAN RAW is used for direct point-to-point CAN communication and BCM provides functions for sending periodic CAN messages [5, 22]. The advantage of using CAN RAW is that the content of the CAN frames is left to the application to do as it will. The CAN frames are represented by a C type struct called can frame. The struct contains the data of a valid CAN frame including: the CAN ID, the Data Length Code (DLC) and the data payload. Raw CAN content is required by the regulator for performing more advanced tasks.

The process of creating the sockets for the CAN communication is as followed: • Create a RAW socket on the CAN bus using socket system call

• Get the index of the CAN interface to be used as a reference • Bind the newly created socket to the CAN interface.

After the creation of a socket, standard Linux system calls are used for reading and writing CAN frames.

(39)

Figure 4.2: Diagnostic access point and two CAN sockets.

4.3 Test Bench

This section describes the different hardware and software that were required for the thesis project.

The following hardware were needed: • Two ECUs, including the RTC • Power supply

• Banana plugs to connect the ECUs to create a CAN network

(40)

• CANcaseXL, piece of hardware to be used for the software CANAlyzer

• Logical analyzer, an oscilloscope used to view CAN signals as binary waveforms. An additional ECU, besides RTC, was required to generate diagnostic network traffic and the Instrument Cluster (ICL) was chosen for this purpose. The chosen version of the ICL runs the KWP2000 diagnostic protocol. The main advantage of using ICL is that it is equipped with displays with different lights and signals that make the effects of running diagnostics services more visual.

The developer environment was a virtual machine running Ubuntu. The PC was con-nected to RTC through a USB-to-Ethernet cable and the SSH command (Secure Shell) was used to access the ECU and to execute the application. The application, which includes the access point as well as the regulator, was developed in C++. The SCP com-mand (Secure Copy) was required for transferring the executable and other files between the virtual machine and RTC. VCI is a diagnostic tool that connects a computer to the in-vehicle CAN communication bus through the OBD port using a USB cable. The main objective of a VCI is to translate messages from a format the computer understands to the vehicle’s communication format, CAN in this case.

A special communication module developed by Scania was also required, which handles the diagnostic communication over CAN with a comprehensive high-level API interface to the ECUs. The module also provides communication logs. One advantage of using this module is that it makes the diagnostic communication transparent for the tester by for example hiding the diagnostic protocol used by the ECUs, by taking care of the session transitions as well as unlocking security access whenever necessary. This module is the underlying layer in the current system architecture that receives requests from the diagnostic user application, forwards the requests in correct format via USB to the VCI. It also receives replies from the ECUs and decodes the replies to human readable format, before forwarding the replies back to the user application [30].

CANAlyzer was another essential software that facilitated the implementation of the reg-ulator. CANAlyzer is a software tool for analysing individual ECUs and entire networks, developed by the company Vector [1]. Among the many features the software offers, the most relevant for the thesis are the tracing and monitoring of CAN network traffic and the generated logs with information such as timestamps of when the CAN frames are transmitted as well as the content of the frames. Another indispensable feature was statistics regarding bus utilisation and frequencies of transmitted CAN frames. A piece of hardware called CANcaseXL was required for running CANAlyzer. CANcaseXL is a 32 bit 64MHz micro-controller equipped with two CAN controllers that were connected to the yellow bus and the OBD bus of the RTC, respectively.

4.4 CAN Frame Size and Transfer Time

(41)

sizes and transfer times, as these findings will be relevant for the subsequent sections in the report.

4.4.1 Maximum and Minimum Frame Sizes

Ultimately what decides the frame sizes is how many bits that are inserted as a result of applying bit stuffing [27]. The following bit sequence consisting of 16 bits is studied as an example: 00000111100001111. Figure 4.3a represents the bit sequence without applying bit stuffing. The frame commences with an SOF bit (with value 0) followed by four consecutive 0-value bits. According to the rules of bit stuffing; after five consecutive bits with identical values a bit of the opposite value is inserted, i.e. a 1-value bit in this case. The bit sequence continues with four 1-bits, thus making there a total of five consecutive 1-bits, which is followed by an inserted 0-bit value and so on. Figure 4.3b illustrates the bit stream with stuffed bits, and it can be observed that for the 16 bits, 4 bits are inserted. This example represents the “worst-case” sequence of bit values as each time a bit is inserted a chain reaction occurs of more bits being inserted. The maximum number of stuffed bits can thus be estimated by dividing the length of the message by 4 and by rounding up the result as illustrated by equation 4.1.

(a) Original bit stream

(b) Bit stream with stuffed bits

Figure 4.3: Bit stuffing example

size(bit sequence) 4

(4.1) CAN frames using the extended format with 29 bit CAN ID contain 13 bits that are not encoded with bit stuffing and out of the segments that are encoded with bit stuffing, all bits except the data segment are fix; there are 54 such bits. Hence, the total number of bits in a frame (including stuffed bits) can be obtained by equation 4.2. N ∈ [0, 8] is the length of the data segment in bytes and 67 is the sum of the 13 bits that are not affected by bit stuffing and the 54 bits that are fix.

8N + 67 + d54 + 8N

(42)

As N varies the length of the CAN frame also varies. Table 4.1 shows the result of applying equation 4.2 with different values of N.

N [byte] Total length [bit]

0 81 1 91 2 101 3 111 4 121 5 131 6 141 7 151 8 161

Table 4.1: Maximal CAN frame sizes with varying numbers of data bytes and with bit stuffing

Table 4.2 contains the CAN frame sizes without applying bit stuffing. N [byte] Total length [bit]

0 67 1 75 2 83 3 91 4 99 5 107 6 115 7 123 8 131

Table 4.2: Minimal CAN frame sizes with varying numbers of data bytes and without applying bit stuffing

As previously mentioned in section 2.5, the J1939 protocol used by Scania and other automotive industries, always uses 8 bytes for the data segment. Thus, the maximum size of a CAN frame is 161 bits and the minimum length is 131 bits with N=8. The result of the analysis yields that all frames that are sent into the CAN network (using J1939) always have sizes that lie between 131 and 161 bits.

4.4.2 Transmission time estimation using CAN

(43)

transmission time of individual bits for different bit rates. The bit time is the reciprocal of the bit rate [23].

Bit rate Bit times 1 Mbit/s 1 µs 500 Kbit/s 2 µs 250 Kbit/s 4 µs

Table 4.3: CAN bit rates and corresponding bit times Table 4.4 concludes the results of the analysis.

Bit rate tbit[µs] Size [bit] tframe [s] frequency [frames/s] 250 Kbit/s 4 131 0.0005240 1908.40 161 0.000644 1552.80 500 Kbit/s 2 131 0.0002620 3816.7 161 0.000322 3105.59 1000 Mbit/s 1 131 0.0001310 7633.59 161 0.000161 6211.18

Table 4.4: CAN analysis of bit rates, transmission times, frame sizes and frequencies

Column 3 in table 4.4 contains the transfer times of individual CAN frames. Column 4 contains the values of the maximum and the minimum frequencies with which CAN frames can be transferred.

4.5 Bus load Calculator

(44)

the bus load. In order get exact values of the bus load, however, the exact lengths of the individual CAN frames must be known and the following paragraphs discuss how this can be accomplished.

SocketCAN only provides information about the CAN ID, the DLC and the 8 data bytes. It was discovered that the format of the CAN ID using SocketCAN differs from the CAN specification. This had to be rectified before bit stuffing could be applied to the bit sequences that make up the CAN frames.

4.5.1 Rearrangement of CAN ID

The CAN ID in SocketCAN takes on the format as illustrated in table 4.5. The CAN specification mandates that the CAN ID commences with 11 bits ID (base ID), followed by an SRR and an IDE bit, the remaining 18 bits of the CAN ID (extended ID) and lastly an RTR bit (see figure 2.2). The rearrangement was accomplished by basic bit arithmetic and bit masking, as illustrated by the following code snipped:

b a s e i d m a s k = 0x1FFC0000 ; // 11111111111000000000000000000

b a s e i d = ( ∗ i d & b a s e i d m a s k ) >> (32 −3 −11); e x t e n d e d i d m a s k= 0x3FFFF ; // 111111111111111111

e x t e n d e d i d = ( ∗ i d & e x t e n d e d i d m a s k ) ; newARB = b a s e i d << ( 3 2 − 1 1 ) ;

newARB = newARB | 0 x180000 ; // SRR & IDE : 110000000000000000000

newARB = newARBˆ ( e x t e n d e d i d <<1); // Recessive bit for the RTR bit .

bits Abbreviation Description 0-28 CAN ID 29 bit CAN ID

29 ERR Error Frame Flag 0=data frame, 1=error frame 30 RTR Remote Transmission Request flag, 1 = rtr frame

31 EFF Frame Format Flag, 0=standard 11 bit, 1=extended 29 bit Table 4.5: Format of CAN ID when using SocketCAN

Table 2.2 in section 2.3.1 contains the different fields that together constitute a valid CAN frame. Bit stuffing is applied to the SOF bit, the arbitration field, control field, the data field as well as the CRC sequence. The CRC sequence is not given by SocketCAN and it needs to be calculated as the final step before applying bit stuffing.

4.5.2 CRC Sequence Calculation

(45)

calculated modulo-2, yielding: 1100010110011001. The quotient of the polynomial divi-sion is discarded and the remainder is what becomes the CRC sequence. The correctness of the calculated CRC sequences can be verified by a logical analyzer.

4.5.3 Bit Stuffing Algorithm

The bit stuffing algorithm is straight-forward: loop through the bit sequence and take note of the value of the first bit. A counter variable increments its value each time the consecutive bit has the same value as the previous one. If 5 consecutive bits with the same values have been detected, insert a bit of the opposite value. Otherwise, reset the counter and repeat the steps from the current position in the bit sequence.

4.5.4 Bus Load Calculation

CAN frame sizes are calculated as described above for all in-coming frames at the yellow segment during the period of one second and the sum of the lengths of the frame sizes is stored in a global variable. Figure 4.4 illustrates how the bus load is calculated: the thread pthread busload sleeps during one second and when it awakens takes the sum of the lengths of all the in-coming CAN frames that arrived during that second and calculates the bus load according to equation 4.3:

bus load = Pn

i=1size(framei)

CAN bit rate × 100 (4.3)

Where n is the number of in-coming frames during 1s.

The bus load calculator is supposed to measure the base load and equation 4.3 should only apply to the frames that participate in the on-board communication and not frames belonging to diagnostic communication. A way of classifying the frames as either part of on-board or diagnostic communication was achieved by checking the PGN of the frames as shown in the code snippet below:

bool i s D i a g n o s t i c ( ∗ i d ) { if( ! ( ( ∗ i d ˆ0 x18DA0000)&0x1FFF0000 ) ) { return true; } return false; }

If the result is false, the frame is included in the bus load calculation.

Figure 4.4 portrays all the steps involved for calculating the bus load. Besides calculating the base load, the thread also calculates the available bandwidth according to formula 4.4.

(46)

Figure 4.4: The length of each in-coming CAN frame is calculated and summed during the period of one second. A thread awakens after sleeping for one second and calculates the bus load

Exceeding the maximum threshold causes frames to drop as the maximum capacity of the network is reached. The max threshold is not necessarily reached at 100%, it can be less. This value is further investigated in the subsequent section.

Using CANAlyzer it is possible to generate CAN traffic to decrease/increase the bus load. This feature of CANAlyzer has been used to simulate different vehicle configurations with varying numbers of ECUs in the CAN network. Figure 4.5 shows the Interactive Generator Block (IG) that is used to generate CAN frames in CANAlyzer. By changing the values of the cycle times, the value of the bus load can be increased or decreased in a controlled manner. Table 4.6 contains the bus loads that were obtained by changing the cycle time of a CAN frame consisting of 150 bits using a CAN bit rate of 250 Kbit/s.

Figure 4.5: The Interactive Generator Block (IG) is a feature in CANAlyzer that allows the user to generate CAN frames on the network in a controlled manner.

The bus load values in the table 4.6 were obtained by applying equation 4.5. busload = size(frame)

(47)

Cycle Time [ms] Bus load [%] 1 60 2 30 3 20 4 15 5 12 6 10 10 6 12 5 15 4 20 3

Table 4.6: Cycle times of a CAN frame of 150 bits and the corresponding generated bus loads

4.6 Maximum Threshold

The CAN network bus should never be utilised to such an extent that CAN frames are dropped as a result. By applying the regulation algorithm explored in this thesis project, the diagnostic network traffic is guaranteed to stay within prescribed limits, thus preventing the bus load from reaching such critical limits. As an attempt to find out the value of the critical limit, a series of test was conducted by increasing the base load in steps using table 4.6 and at each step diagnostic services were performed whilst keeping the CAN network and the network bus utilisation under close inspection. The test was conducted with two different diagnostic services that both exert substantial loads on the network. The obtained results are presented in chapter 5 Results.

4.7 Regulation Algorithms

The idea for regulating the diagnostic traffic is to take advantage of the Flow Control parameter STmin and to tweak its value in order to add delays to the diagnostic traffic. Assigning high values to STmin results in less number of diagnostic frames being sent into the network per second, which consequently results in smaller bus loads per second. The job of the regulation algorithm is to assign appropriate values to STmin that yield diagnostic loads that confirm to the available bandwidth. However, FCs are only gener-ated whenever data segmentation occurs and not all diagnostic services are necessarily executed with data segmentation. To circumvent this restriction of the regulator, the Token Bucket algorithm is used.

(48)

part of data segmentation), the flow control parameters can be used to shape the traffic at the ingress link. Hence, it was decided to implement two distinct regulation algorithms; one using Token Bucket for CAN frames at the egress link and the second using the flow control parameters at the ingress link. The latter is referred to as the ISO-TP algorithm in the remaining of the report.

Figure 4.6: A schematic illustration of the network architecture with marked egress and ingress network links

Figure 4.7 illustrates that two distinct regulation algorithms are used and the decision of which algorithm to use depends on the in-coming diagnostic request.

Figure 4.7: Flow chart of the decision of which shaping algorithm to use

(49)

To summarise what has been discussed thus far; Token Bucket is applied at the egress link whenever single frame requests and responses are sent. The ISO-TP algorithm is applied whenever data segmentation occurs at either the egress or the ingress link depending on the diagnostic service.

4.8 ISO-TP Algorithm

The figures 4.8 and 4.9 illustrate how the diagnostic communication can be done in two directions depending on whether the diagnostic service is a read-operation or a write-operation. The idea is to change the value of STmin to add delays whenever the diagnostic traffic flow requires shaping, which is the case whenever the diagnostic load exceeds the available bandwidth. In figure 4.8 we see that the client sends a diagnostic request as a single frame and that the server responds with a first frame, indicating that the response will contain data larger than 8 bytes. This gives the client the possibility of controlling the traffic flow using the flow control fame and its parameters. The server must conform to these paramenters when sending the consecutive frames. Figure 4.9 illustrates that the client is requesting data to be stored in the server’s memory; i.e. the client sends consecutive frames to the server, giving the server the possibility of shaping the data flow using the flow control parameters.

The effects of assigning higher values to STmin are:

• Lower frequencies of CAN frames transmitted per second • Lesser degrees of exerted bus loads per second

• Longer execution times

(50)

(51)

Figure 4.9: Write operation ISO-TP

4.8.1 Data Gathering

(52)

for the different ECUs.

The diagnostic services that were chosen for analysis are presented in table 4.7. These services are referred to as application-layer services and they are further elaborated on in the KWP2000 standard [6]. With the help of Scania’s communication module for diagnostic communication (mentioned in section 4.3) and CANAlyzer, the generated CAN traffic as well as the network bus utilisation can be logged for further analysis.

Service names

ReadECUIdentification ReadValues

ReadSOPS file WriteSOPS file

Table 4.7: The diagnostic services chosen for analysis

The diagnostic services ReadSOSP and WriteSOPS both involve reading and writing so called SOPS files. SOPS, or Scania Onboard Product Specification, is composed of several blocks of data that together form a specification of the vehicle, complete enough to identify and diagnose vehicles in workshops and to program new parameters into the ECUs. These files are typically very large; the SOPS file used in this project is 1.27KB.

From the logs it was discovered that ReadValues differs from the other application-layer services in that it generates a burst of single frame requests and responses. ReadValues reads a variety of different data from the ECU’s memory. A total of 28 read-requests are sent, out of which only one request generates data segmentation. The remaining 27 requests generate single frame responses, which makes the ISO-TP algorithm useless in this case. Hence, it is the job of the Token Bucket algorithm to regulate the diagnostic traffic flow that is generated by ReadValues.

(53)

at the time of choosing a suitable value for STmin.

The new approach instead involved populating the look-up table with information about the bus load distribution of the different application-layer services and not by their in-dividual sub-services, with different values assigned to STmin. For this purpose the execution times of the application-layer service (as a consequence of applying different delays using STmin), as well as the total data volume (i.e. the total number of generated CAN frames) were required. Irrespective of whether delays are applied, the data volume remains constant. By dividing the data volume with the execution times, the average frequencies of CAN frames/s are obtained. From the average frequencies, the average bus loads/s are obtained by applying the equation 4.5 in section 4.5. One underpinning assumption is that the diagnostic load is evenly distributed in time. The execution times and the generated data volumes were obtained from the logs.

There is a step missing in figure 4.7; how does the regulator know whether an in-coming request generates segmented data? This ability of the regulator is integral in the decision making of which traffic shaping algorithm to apply. The chosen approach was to query the look-up table with the SID of the in-coming diagnostic service and if there is a hit, it means that data segmentation is required for the response and that ISO-TP should be used, otherwise Token Bucket is chosen. This is illustrated by 4.10.

(54)

calculating the number of generated frames as well as the corresponding bus loads was developed, and it is discussed in the following section.

4.8.2 Theoretical Calculation of Bus Load

In order to estimate the bus load that a diagnostic service exerts on the network bus, information about the total number of generated CAN frames is required. All services that trigger data segmentation transmit a First Frame that contains information about how much data that is to be transferred referred to as FF DL (Data Length).

1(SF) + 1(FF) + total CFs + total FCs (4.6) total CFs and total FCs are, as their names suggest, the total number of CFs and FCs that are transmitted in the response.

total CFs =        1 if FF DL <= 13 (F F DL−6) 7 if(FF DL-6) mod 7 == 0 j_{(F F DL−6)} 7 k + 1 else (4.7)

If FF dl is less than or equal to 13, only one CF is needed because FF fits 6 data bytes (two bytes are occupied by the PCI block, see section 2.9.3) and CF fits 7 data bytes (1 byte occupied by the PCI block). If FF DL is greater than 13, the two subsequent cases subtract the 6 bytes that are transferred with FF and depending on whether an even number of CFs is required, one additional CF may or may not be needed.

total FCs =      1 if BlockSize == 0 total CF s BlockSize if total CF s BlockSize mod 2 == 0 _{total CF s} BlockSize + 1 else (4.8)

If BlockSize equals 0, only one FC is sent. The value of BlockSize determines how many CFs that can be transmitted in succession before waiting for another FC.

Network Traffic Regulator for Diagnostic Messages in Modular Product

Network Traffic Regulator for

Diagnostic Messages in Modular

Product

Network Traffic Regulator for

Diagnostic Messages in Modular

Product

Master of Science in Engineering

Master’s Programme in Computer Science

School of Computer Science and Communication

NIKHIL THAKRAR

thakrar@kth.se

Acknowledgements

Abstract

Referat

Reglering av n¨

atverkstrafik f¨

or diagnoskommunikation

i en modul¨

ar produkt

Contents

List of Figures

List of Tables

Chapter 1

Introduction

1.1

Problem Description

1.2

Research Question

1.3

Purpose

1.4

Contribution

Chapter 2

Vehicle Control Communication

System and Diagnostics

2.1

Bus Communication

2.2

OSI Model

2.3

Controller Area Network

2.3.1

Data Frame

2.4

Time synchronization using bit stuffing

2.5

J1939 Standard

2.5.1

J1939 vs. CAN Message Format

2.6

ECUs

2.7

Network Architecture and Diagnostic Access Point

2.8

On-board Diagnostics (OBD)

2.9

Diagnostic Communication

2.9.1

Structure of Diagnostic Services

2.9.2

Addressing Schemes

2.9.3

Data Segmentation

Chapter 3

Bandwidth Management

3.1

Related Work

3.2

Traffic Shaping

Chapter 4

Material and Method

4.1

Network Architecture and Diagnostic Access Point

4.2

SocketCAN

4.3

Test Bench

4.4

CAN Frame Size and Transfer Time