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

, STOCKHOLM SWEDEN 2017

Network Traffic Regulator for Diagnostic Messages in Modular Product

NIKHIL THAKRAR

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF COMPUTER SCIENCE AND COMMUNICATION

Network Traffic Regulator forDiagnostic 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 KumarScania: Par Sundback

March 16, 2017

Acknowledgements

I am deeply grateful for the opportunity to conduct my master’s thesis at Scania in theRESD department responsible for Network and Diagnostic Architecture. First, I wouldlike to extend my thanks to my industrial supervisor Par Sundback who wholeheartedlysupported and guided me throughout the thesis project. I also want to thank ArvindKumar, my supervisor at KTH for his guidance and support. The examiner Olov Engwallalso deserves a thanks for supervising the project. I also want to thank my colleaguesand friends from Scania. Finally, I want to thank my family for their continued supportand for always being there for me.

Abstract

The aim of this thesis project is to explore a network traffic regulator using bandwidthmanagement techniques that regulates data traffic with the objective to use the networkbandwidth 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 criticalon-board communication and it should comply with the remaining bandwidth. In theexisting solution, fixed delays are imposed on the data traffic which result in a waste ofnetwork capacity. The approach presented in this thesis uses two regulation algorithms fordifferent types of diagnostic services. One regulation algorithm is activated for diagnosticservices that require data segmentation and multiple data frames to accommodate thetransferred data. This algorithm makes use of the Flow Control parameter SeparationTime specified in ISO 15765-1:2011 “Road vehicles – Diagnostic communication overController Area Network (DoCAN)”. The other algorithm regulates diagnostic servicesthat generate bursts of single frames where data segmentation is not required and itdoes so using traffic shaping techniques. The results in this thesis show that the networktraffic indeed can be regulated for different diagnostic services by using the two mentionedregulation algorithms. The results also show that data is not lost due to high networkutilisation and that the bandwidth is used to its maximum capacity without having toimpose fixed delays on the network system. The regulator is adaptive in the sense thatit can be used for different vehicle configurations with compatible network systems toensure quality of service and a robust network system.

.

Referat

Reglering av natverkstrafik for diagnoskommunikation

i en modular produkt

I detta examensarbete ar malet att utforska en metod for att reglera natverkstrafik genomatt anvanda tekniker inom bandbreddshantering med syfte att utnyttja bandbredden tilldess maximala kapacitet utan att overbelasta natverket. Bandbredden i den nuvarandenatverksarkitekturen delas mellan tva datafloden for onboard kommunikation och diag-nostisk kommunikation. Den diagnostiska kommunikationen far inte pa nagotvis storaonboard kommunkationen och far anpassa sig till den bandbredd som kvarstar. I detexisterande systemet infors fixa fordrojningar i natverkstrafiken vilket medfor ett onodigtsloseri pa natverkskapaciteten och som ocksa medfor att de diagnostiska tjansterna tarlangre tid att utfora. Tillvagagangssattet som presenteras i detta arbete anvander tvaregleringsalgoritmer for olika typer av diagnostiska tjanster. En algoritm anvands fortjanster som kraver datasegmentering och flera dataramar for att skicka data. Den haralgoritmen anvander parametern Separation Time som ar specificerad i ISO standarden15765-1:2011 “Road vehicles – Diagnostic communication over Controller Area Network(DoCAN)”. Diagnostiska tjanster som istallet genererar en skur av enstaka dataramar re-gleras med en traffic shaping algoritm som heter Token Bucket. Resultaten i detta arbetevisar att det gar att reglera natverkstrafiken for olika typer av diagnostiska tjanster genomatt anvanda de tva utvecklade algoritmerna. Resultaten visar ocksa att data inte garforlorat vid hoga natverkslaster och att bandbredden anvands maximalt utan att behovainfora fixa fordrojningar i natverkssystemet. Regleraren ar adaptiv i bemarkelsen att denkan anvandas for alla tankbara fordonskonfigurationer med kompatibelt natverkssystemfor att forsakra quality of service och robusthet.

Contents

1 Introduction 11.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Vehicle Control Communication System and Diagnostics 42.1 Bus Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Time synchronization using bit stuffing . . . . . . . . . . . . . . . . . . . 102.5 J1939 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1 J1939 vs. CAN Message Format . . . . . . . . . . . . . . . . . . . 102.6 ECUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 Network Architecture and Diagnostic Access Point . . . . . . . . . . . . . 122.8 On-board Diagnostics (OBD) . . . . . . . . . . . . . . . . . . . . . . . . 132.9 Diagnostic Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.9.1 Structure of Diagnostic Services . . . . . . . . . . . . . . . . . . . 162.9.2 Addressing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 172.9.3 Data Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Bandwidth Management 203.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Material and Method 244.1 Network Architecture and Diagnostic Access Point . . . . . . . . . . . . . 244.2 SocketCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 CAN Frame Size and Transfer Time . . . . . . . . . . . . . . . . . . . . . 28

4.4.1 Maximum and Minimum Frame Sizes . . . . . . . . . . . . . . . . 294.4.2 Transmission time estimation using CAN . . . . . . . . . . . . . . 30

4.5 Bus load Calculator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.1 Rearrangement of CAN ID . . . . . . . . . . . . . . . . . . . . . . 324.5.2 CRC Sequence Calculation . . . . . . . . . . . . . . . . . . . . . . 32

4.5.3 Bit Stuffing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 334.5.4 Bus Load Calculation . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Maximum Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.7 Regulation Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.8 ISO-TP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.8.1 Data Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.8.2 Theoretical Calculation of Bus Load . . . . . . . . . . . . . . . . 424.8.3 Token Bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Results 455.1 Bus Load Calculation Results . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Data Gathering Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.1 ReadECUIdentification . . . . . . . . . . . . . . . . . . . . . . . . 505.2.2 ReadSOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.3 WriteSOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.4 ReadValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Maximum Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4 Regulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.4.1 ISO-TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4.2 Token Bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Discussion 646.1 Ethics, Social Aspects and Sustainability . . . . . . . . . . . . . . . . . . 65

Bibliography 65

List of Figures

2.1 CAN Data-Flow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 The fields of Data Frame in extended format . . . . . . . . . . . . . . . . 82.3 Differences in CAN ID between J1939 and CAN . . . . . . . . . . . . . . 112.4 The structure of 29-bit CAN ID using J1939 . . . . . . . . . . . . . . . . 112.5 Scania network architecture . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 OSI model service primitives . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Diagnostic request and response messages sent between a client and a server. 162.8 Addressing schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.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 . . . . . . . . . . . . 254.2 Diagnostic access point and two CAN sockets. . . . . . . . . . . . . . . . 274.3 Bit stuffing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Base load calculator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.5 Interactive Generator Block (IG) in CANAlyzer . . . . . . . . . . . . . . 344.6 Network architecture with marked egress and ingress network links . . . 364.7 Two different shaping algorithms . . . . . . . . . . . . . . . . . . . . . . 364.8 Read operation data segmentation . . . . . . . . . . . . . . . . . . . . . . 384.9 Write operation data segmentation . . . . . . . . . . . . . . . . . . . . . 394.10 Flow chart of ISO-TP algorithm . . . . . . . . . . . . . . . . . . . . . . . 414.11 Example block of diagnostic request and response . . . . . . . . . . . . . 434.12 The workings of the Token Bucket algorithm . . . . . . . . . . . . . . . . 44

5.1 Bus load comparison: regulator versus CANAlyzer at base load 30% . . . 465.2 Bus load comparison: regulator versus CANAlyzer at base load 60% . . . 465.3 Bus load comparison: regulator versus CANAlyzer at base load 90% . . . 475.4 Modified bus load calculation at base load 30% . . . . . . . . . . . . . . 485.5 Modified bus load calculation at base load 60% . . . . . . . . . . . . . . 495.6 Modified bus load calculation at base load 90% . . . . . . . . . . . . . . 495.7 Bus load generated by ReadECUIdentification. . . . . . . . . . . . . . . . 515.8 The total bus load generated by ReadSOPS . . . . . . . . . . . . . . . . 525.9 The total bus load generated by WriteSOPS . . . . . . . . . . . . . . . . 555.10 ReadSOPS: exceeding max threshold and dropped frames as consequence 58

5.11 ReadSOPS result graph 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 595.12 ReadSOPS result graph 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 595.13 ReadSOPS result graph 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 605.14 ReadSOPS result graph 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 605.15 WriteSOPS result graph 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 615.16 WriteSOPS result graph 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 625.17 WriteSOPS result graph 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 625.18 WriteSOPS result graph 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 63

List of Tables

2.1 7 layers of the OSI model . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Bit fields of a CAN Data frame . . . . . . . . . . . . . . . . . . . . . . . 72.3 Cable lengths vs Bit rates . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Example of negative response codes and their meaning . . . . . . . . . . 172.5 Different diagnostic frame types. . . . . . . . . . . . . . . . . . . . . . . . 18

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

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

4.3 CAN bit rates and corresponding bit times . . . . . . . . . . . . . . . . . 314.4 CAN analysis of bit rates, transmission times, frame sizes and frequencies 314.5 Format of CAN ID when using SocketCAN . . . . . . . . . . . . . . . . . 324.6 Cycle times of a CAN frame of 150 bits and the corresponding generated

bus loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.7 Diagnostic services chosen for analysis . . . . . . . . . . . . . . . . . . . 40

5.1 Difference in frame sizes as calculated by RTC and CANAlyzer . . . . . 485.2 ReadECUIdentification sub-services . . . . . . . . . . . . . . . . . . . . . 505.3 Generated bus loads of the ReadECUIdentification sub-services . . . . . 515.4 Execution time, frequency (frames/s) and bus load of ReadECUIdentifica-

tion with different STmin values . . . . . . . . . . . . . . . . . . . . . . . 525.5 Bus load analysis of ReadECUIdentification using CANAnalyzer with STmin=0 525.6 ReadSOPS sub-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.7 Execution time, frequency (frames/s) and bus load of ReadSOPS with

different STmin values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.8 Analysis of ReadSOPS using CANAnalyzer and STmin=0 . . . . . . . . 545.9 WriteSOPS sub-services . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.10 Execution time, frequency (frames/s) and bus load of WriteSOPS with

different STmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.11 Analysis of WriteSOPS using CANAnalyzer and STmin=0 . . . . . . . . 565.12 ReadSOPS summarised results . . . . . . . . . . . . . . . . . . . . . . . . 595.13 WriteSOPS summarised results . . . . . . . . . . . . . . . . . . . . . . . 615.14 Token bucket results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 1

Introduction

A modern heavy-duty vehicle comprises several Electronic Control Units (ECUs) that arenetworked together by a bus communication system. ECUs are micro controller-basedmodules that work according to the input-processing-output principle; they convert inputsignals to output signals to perform specialised functions in the vehicle. Some examplesof ECUs are the Engine Control Module (ECM), Transmission Control Module (TCM),Brake Control Module (BCM), Anti-Lock Braking system (ABS) amongst others. Manyfunctions 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 reversegear is not only used by TCM, but also by the light control module to switch on thebackup light, ECM and ABS. Moreover, in order to prevent emissions from entering thepassenger 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 onejust described that would not be possible without the ability of the ECUs to exchangedata between themselves. This communication is commonly referred to as the on-boardcommunication 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 minimumlatencies.

On-Board Diagnostics (OBD) is required by law for the surveillance of emissions-relatedmodules in the vehicle. Vehicle manufacturers are obliged to provide a standardised in-terface to the vehicle in order to connect external test equipments. By connecting suchequipments the status of the various ECUs and lists of Diagnostic Trouble Codes (DTCs)can be accessed. The DTCs help to identify possible malfunctions that must be repairedin the vehicle. The communication between an external test equipment and the vehicle isreferred to as diagnostic communication. As the complexity in the electronic network sys-tems is increasing, the automotive industry is confronted with more complex challenges.To meet these challenges, the diagnostic protocols for the communication between ECUsand external test systems have been re-engineered and enhanced and, today, diagnosticcommunication is applied in the entire process chain including: reprogramming of ECUsoftware by flash download, functional tests of ECU hardware and software amongst oth-ers [25]. Diagnostic communication need not be restricted to only physical connectionsto the vehicle, it can be done remotely by wireless means as well.

1

1.1 Problem Description

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

There are a few complications that stem from letting the on-board and the diagnosticcommunication share the same network. One such complication is that the diagnostictraffic 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 diagnosticmessages [4]. The communication bus widely used in the automotive industry, includingScania, is called Controller Area Network (CAN). The CAN network schedules messageson a priority basis; in situations where several network messages simultaneously try totransmit on the network bus, the message with the highest priority has precedence overthe bus [15]. However, there are situations where a diagnostic message in the absenceof other higher-priority messages transmits on the network bus and which generates aconsiderable amount of network traffic, forcing other messages arriving later to have towait until the diagnostic communication has terminated. Among the enqueued messageswaiting for transmission high-priority messages can also be found.

Another complication is that the capacity of the network bus is limited [24]. If the busload goes up too high, messages can be dropped and the network consequently entersan erroneous state. This is an undesired outcome as the messages that are droppedwould have to be retransmitted and ultimately cause unwanted delays. Furthermore, it isundefined behaviour which messages are discarded during high network utilisation, henceeven 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 valueof the delay is obtained by looking at a worst case configuration that contains a very largenumber of ECUs and by measuring how much bandwidth is required for the on-boardcommunication for that configuration. Such a configuration is highly unlikely to ever beproduced and the delay is very pessimistic as the big majority of vehicle configurationswould require much smaller delays and thus network capacity is wasted.

Scania has a modular-based approach to offer products that are highly customisable andflexible to meet the customers’ requirements and needs. The vehicle configurations canbe very different from one another and as a consequence there does not exist concretemodels, where vehicles belonging to the same model share certain characteristics suchas the same bandwidth requirements. Different configurations utilise the network indifferent degrees and the network utilisation of a configuration can only be measured forthat particular vehicle individual. Two distinct data flows in a network with inherent

2

restriction on the capacity and where the data flows behave differently in different vehicleconfigurations is what make Scania vehicles a good case study for developing methodsfor 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 networkbandwidth be used to its maximum capacity while ensuring that the network is notoverloaded 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 usingfixed delays, which exploits available bandwidth management techniques for implement-ing a network traffic regulator for diagnostic messages in an in-vehicle network. Theobjective is to use the network bandwidth to its maximum capacity while ensuring thatthe network is not overloaded and without imposing delays on the network traffic. Oneprominent characteristic of the regulator is that it is adaptive in the sense that it canregulate the network traffic for any vehicle configuration. There can be cases where theregulator allows the diagnostic communication to proceed unhindered and at full speedfor certain configurations and other cases where the regulator keeps the diagnostic com-munication under tight control.

1.4 Contribution

The main contribution of the thesis is a novel regulating mechanism that can be appliedto any modular product utilising a communication network to assure quality of service aswell as optimised usage of the network bandwidth. The traffic regulator can be configuredto adapt itself to any compatible network environment with the purpose of shaping thetraffic flow to conform to configured limits.

3

Chapter 2

Vehicle Control CommunicationSystem and Diagnostics

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

2.1 Bus Communication

A bus is a topology of a communication network that allows several peripherals to beconnected over the same set of wires [25]. The advantage of cost and weight savings iswhat has driven the adaptation of the bus topology as the standard for the communicationsystem used in the automotive industry. Buses are easy to implement and to extend andthe 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 needof methods for handling and avoiding collisions when two or more nodes are attemptingto transmit simultaneously. One disadvantage with the bus architecture is that if acable breaks it can disable the whole bus network [35]. Currently, a number of differentvehicle communication systems are available in the automotive industry and among theestablished standards the Controller Area Network (CAN) is the most widely used.

2.2 OSI Model

Before diving into the CAN protocol and the concept of diagnostics, the Open SystemInterconnection (OSI) model is briefly described as it is frequently used in the context ofCAN and diagnostics. The OSI model structures the communication system into sevenlayers (see table 2.1), where each layer contains a collection of functions and where eachlayer provides services to the layer above it and receives services from the layer below it.The ISO standards specifying CAN and diagnostics are based on the OSI model [25].

4

OSI layers use control information referred to as headers and trailers to communicatewith peer layers. Headers and trailers are attached to the data that is passed down fromupper layers. The headers, trailers and the data are commonly referred to as ProtocolData Unit (PDU).

Layer Name7 Application layer6 Presentation layer5 Session layer4 Transport layer3 Network layer2 Data Link layer1 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 communicationprotocol 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 androbust communications for in-vehicle networks [15, 18]. The CAN protocol has beenstandardised as ISO 11898 and apart from automotive applications, CAN is also used asa generic embedded communication system for micro-controllers as well as a standardisedcommunication protocol used in industrial control systems [2].

CAN is a peer-to-peer network and it provides multi-master capabilities; all nodes areallowed to access the bus to start transmission. What is referred to as nodes in the CANnetwork are so called Electronic Control Units (ECU). The ECUs are electronic devicesthat control a set of functions within a vehicle. For the rest of the report ECUs and nodesare used interchangeably in the context of CAN communication. CAN is a broadcasttype of bus, which means that all messages that are sent on the network bus are availablesystem-wide, thus providing global data consistency in the system. A consequence of thisis that the nodes lack individual addresses for targeting a specific node [25]. However,the fact that all nodes have equal rights to start transmitting messages does not meanthat their messages share the same inherent importance. In any system some parameterswill change more rapidly than others; eg in a motor vehicle the RPM of the engine willchange far more frequently than the temperature of the engine coolant. The more rapidlychanging parameters need more frequent monitoring and are for this reason usually givenhigher priority. To set the importance level each message is given a unique CAN identifier,abbreviated as CAN ID [12]. The CAN ID serves two purposes beyond simply identifyingthe content of a message (e.g., temperature or shaft position); first, the identifier is usedas a priority to determine which message among those contending for the bus should betransmitted next. Second, the identifier may be used by nodes to filter out messages

5

that are not relevant to them, and by so doing, reduce the bus load at the receivingnodes [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 3simply 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 (CANV2.0B), which uses 29 bits for the CAN ID [18].

Carrier Sense Multiple Access with Collision Detection (CSMA/CD) is a communicationprotocol used when multiple nodes share the same medium for communication, as inthe case of CAN. As the name suggests, the nodes must first “sense”, i.e. read thebit values on the bus and wait for a period of inactivity in order to start the messagetransmission. Because all nodes have equal rights to transmit messages, there mustexist support for Collision Detection (CD). Each node is constantly listening on thenetwork, even the transmitting node itself. This way, if two nodes happen to transmiton the network at the same time, both of them will be aware of the collision. CANemploys a non-destructive bitwise arbitration method to resolve bus access conflicts byusing the CAN ID [11, 31]. The CAN bus can have one of the two complementarylogical values: recessive or dominant, with the recessive value representing a logical 1and the dominant value representing a logical 0. During simultaneous transmission ofdominant and recessive bits, the resulting bus value will be dominant [31]. The state ofthe bus thus always reflects the state of the message ID with the highest message priorityi.e. with the numerically lowest CAN ID. Each node can determine if it is sending themessage with the highest priority and thus continue to transmit on the bus or whetherit should stop the transmission and make another attempt the next time the bus is inan idle state [18]. The arbitration method guarantees that neither information nor timeis 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 globalpriority-based queue and the messages are transmitted according to a fixed priority, non-preemptive scheduling. A blatant drawback with non-preemptive scheduling is that inthe worst-case scenario, a high priority message may have to wait for a lower prioritymessage to finish transmitting [20].

CAN also has a support for hot-plug capability, i.e. it supports changeability whileoperating. Automotive communication systems typically must support this technologyas there may be reasons for adding or removing ECUs and it should be possible without

6

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

In order to achieve design and implementation transparency and flexibility, CAN has beenstructured 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 thenetwork 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 sublayerprovides 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 recoverymanagement and overload notifications. The scope of the MAC sub-layer is the transferprotocol, which includes message framing, arbitration, acknowledgement, error detectionand signaling. The MAC sub-layer also decides whether the bus is free for a node to starttransmitting [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. Aremote frame is transmitted by a node to request the transmission of a data frame fromanother node in the network. An error frame is transmitted once a bus error has beendetected by any node. The overload frame is used to provide for an extra delay betweenthe preceding and the succeeding data or remote frames. The data and the remote framescan 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 FieldSOF Start of FrameARB Arbitration Field

CTRL Control FieldDATA Data FieldCRC Cyclic Redundancy FieldACK Acknowledgement FieldEOF End of Frame

Table 2.2: Bit fields of a CAN Data frame

7

SOF

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

ARB

ARB differs in the standard and the extended format. As previously mentioned, thearbitration field in the standard format consists of 11 bit CAN ID and the extendedformat 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 bitsID 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 frameformat as a placeholder.

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

CTRL

CTRL consists of 6 bits, including the Data Length Code (DLC) consisting of 4 bits andtwo reserved bits: r1 and r0, both with dominant bit values. The DLC tells how manybytes of data that is transferred in the Data Field. The maximum number of data bytesthat can be sent in a data frame is 8 bytes.

8

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 checkingand for detecting any accidental changes in the bit stream. The CRC sequence is followedby 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 nodescheck the consistency of the messages they receive and acknowledge the ones that appearconsistent or, conversely, flag for inconsistent messages. The CRC sequence is used by thereceivers to verify the consistency of a message. The transmitting node sends the two bitsof 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, whicheffectively 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 amessage is also receiving that message itself, checking each bit as it is being written. If amessage is not acknowledged by at least one node in the network, the transmitting nodesends out an error flag. A consequence of this practice in the CAN protocol is that aminimum 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 apparentthat the bit rate decreases as transmission distance increases. The requirement of a nodeto be able to overwrite a recessive bit in the ACK slot and for the transmitting node todetect this change, is what limits the combination of physical length and the speed of theCAN bus [18].

Bus Length (m) Bit rate (kbps)40 1000100 500200 250500 1001000 50

Table 2.3: Cable lengths vs Bit rates

EOF

The data frames are delimited by a sequence of 7 recessive bits, which constitute the Endof Frame (EOF) field of the CAN frame.

9

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 timingby assuring that adequate resynchronisation occurs during the message transfer. Longdata lengths may cause problems with synchronisation and thus lead to erroneous bitdetection since each node in the network has its own clock generator. Since a long stringof recessive or dominant bits would complicate the synchronisation, the CAN protocolinserts one recessive bit after a sequence of 5 consecutive dominant bits or, conversely, onedominant 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 most5 bits [23]. The excess bits are removed after the transfer so that the receiving nodes seethe 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” afterthe 5th and the 10th “1”, effectively rendering the identifier of the message as it is beingtransmitted 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 meansthat 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 CANprotocol to be used in the heavy-duty truck industry as well as for industries ranging fromagriculture, construction, forestry and other off-highway heavy-load machinery [3]. TheJ1939 standard, in contrast to CAN, covers specifications on the higher layers of the OSImodel and by doing so, gives a more specific application. Since the J1939 standard isbuilt 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 allthe information regarding addressing is contained in the 29 bits of the CAN ID [12].

2.5.1 J1939 vs. CAN Message Format

This section elaborates on the differences between the J1939 and CAN protocols regardingthe message format. Figure 2.3 illustrates the differences between the CAN and J1939identifiers; the top row represents the CAN ID of the CAN protocol and the lower rowrepresents the more detailed CAN ID of the J1939 protocol.

10

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 thenetwork. When PF takes on a value in the interval 0-239, the message is sent to aspecific address, PDU 1. If, however, the value is higher, i.e. somewhere between240-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 isdefined in the PF field. If PDU 1 is used, PS contains the destination address of asingle node and is commonly abbreviated as TA for Target Address. In the case ofPDU 2, PS represents the Group Extension (GE). The Group extension expandsthe number of possible broadcast Parameter Groups that can be represented by theidentifier.

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

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 byfigure 2.4.

Figure 2.4: The structure of 29-bit CAN ID using J1939

11

The first three bits are discarded as the identifier only consists of 29 bits. The subsequentthree bits represent the message priority: 1102, i.e. 610 in this example. Priority 6 istypically the priority given to CAN frames carrying diagnostic data. PGN takes on thevalue 0xDA17FA. The value of PF is 0xDA, which is the hexadecimal value for 218 indecimal. Since 218 lies in the interval 0-239, the message is destination specific. PSthus contains the target address, which is 0x17 in this case. The last byte is the sourceaddress, 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 signalsfrom sensors to digital or analog output signals to control actuators. Both input andoutput signals can be transferred via an in-vehicle network, such as CAN. Typicalfunctions provided by the application software include: ignition timing, anti-lockbraking, electronic stability control, traction control, air conditioning and so forth.

2. Transmit data to and receive data from other ECUs. This kind of communicationis 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

The network architecture used at Scania constitutes a number of different ECUs thatcommunicate over three main CAN buses or segments. The ECUs are depicted as whiteboxes in figure 2.5. The CAN segments are colour-coded as red, yellow and green indescending order of criticality. The red bus holds the ECUs that manage time criticalapplications with hard real-time constraints and it is the highest priority bus. For instancethe ECUs on this segment control the power-train; including the Engine ManagementSystem (EMS), and the Gearbox Management System (GMS). Applications with slightlylower real-time requirements are connected to the yellow bus. ECUs that are foundhere are for example the Instrument Cluster (ICL), the All Wheel Drive System (AWD),and the Road Traffic Communicator (RTC). ECUs that manage applications with onlysoft real-time requirements reside on the green CAN segment. The Automatic ClimateControl (CSS) and Auxiliary Heater System are example of ECUs that reside on thegreen segment. The figure further illustrates that there is a diagnostic bus situated onthe green segment. The diagnostic bus has an external port connected to it called theOn-Board Diagnostics (OBD) port, which is used for connecting diagnostic tools to thevehicle. In order for the ECUs residing on the different segments to communicate witheach other, a gateway ECU is required. The gateway ECU, commonly referred to as the

12

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

Figure 2.5: Scania network architecture

2.8 On-board Diagnostics (OBD)

Vehicle manufacturers and suppliers are legally mandated to develop low-emission enginetechnologies [12, 34]. In addition to complying with certain emission standards, vehicleshave to be equipped with supervising systems called On-board Diagnostics (OBD), whichmonitor emission-related components and display when emission standards are not met.This can be done, for example, by alerting the driver with a dashboard light [21, 33].OBD ports are used to access emissions-related information as well as other diagnosticdata in the vehicle by connecting external hardware, commonly referred to as diagnostictool. The OBD port thus becomes the interface to the vehicle through which an externaltester can perform diagnostic services.

13

2.9 Diagnostic Communication

Thus far, what has been discussed is the data communication between ECUs, i.e. theon-board communication using CAN. Besides the on-board communication, an externaltester can communicate with ECUs in form of diagnostics requests and responses, also byusing the CAN network. This sort of communication between an external tester and ECUsis referred to as diagnostic communication. The aim of the following paragraphs is todiscuss more in-depth the different aspects and the workings of diagnostic communicationusing 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 ECUsby flash-download [33]. Other examples of diagnostic operations are the monitoring ofsensors and actuators, detection of shortcuts and cut-offs, management of memory andso forth. The goal is to verify function and performance of electrical and mechanicalsystems, to ensure that components are fault-free while meeting functional duties, andto accurately identify specific failure modes [12].

Diagnostic communication is only possible if a diagnostic protocol is implemented. Forthis 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 ofwhich specifies the protocol according to the OSI layers. DoCAN specifies the possibilityof addressing individual ECUs (physical addressing) or a group of ECUs (functionaladdressing), the format of diagnostic messages, the transferring of data larger than 8 byteswith segmented CAN frames and the timing of CAN messages for flow control, amongother things. The automotive industry has during the years learnt that proprietary bussystems and diagnostic protocols are unrewarding. Vehicle manufacturers and suppliersare instead opting for standardisations; the Unified Diagnostic Services (UDS) protocolwas developed with this in mind and it provides the unification demanded by the vehiclemanufacturers and suppliers. UDS is a common set of diagnostic services for vehicles usingCAN, specified in ISO 15765-3 as well as in ISO 14229-1. Both of the ISO standardsare 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

• Stored data transmission

• Input & output control

• Remote activation of routine

• Upload & download

14

Diagnostic and communication management includes, among other things, session man-agement. There exists different types of sessions and each with different levels of privilegesto 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 negativeresponse [28]. Another example of a diagnostic service that falls under the same categoryis Communication Control; it activates/deactivates sending and receiving of CAN framesto/from ECUs. This increases available bandwidth when for example performing flashprogramming [28].

Examples of diagnostic services for data transmission are Read Memory By Address andWrite Memory By Address [6, 10]. Read Memory By Address allows a tester to requestdata by specifying a memory address from where the ECU should read out data. WriteMemory By Address allows a tester to provide data to be stored in a specified memoryaddress in the ECU’s memory. The ECU only performs the diagnostic operation if thecorrect 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 bothupload and download files.

In the context of diagnostic communication a tester is sometimes also referred to as aclient and ECU as server. These designations are used interchangeably in the report. Theclient and the server support diagnostic communication using so called diagnostic serviceprimitives, which include: request, indication, response and confirmation. If a testertransmits a message that contains a diagnostic service request an ECU, the diagnosticapplication 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 physicallayer. At the physical layer, the data is relayed on the physical medium and sent acrossthe network to the ECU. The ECU reads the data from the physical medium and passesthe data up to the data link layer and so on until it reaches the application softwareof the ECU. Each layer of the tester communicates with its respective peer layer of theECU. Figure 2.6 illustrates that there is a logical point-to-point connection between theapplication 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 thetransport layer. Step 2: the application layer of the server receives an indication, whichalso requires performing an operation. Step 3: as soon as the ECU’s application softwarehas 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.

ISO 15765 distinguishes between the service provided by a layer to the layer above itand the protocol used by the layer to send a message between the peer entities of thatlayer. The reason for this distinction is to make the services, especially the applicationlayer services and the transport layer services, reusable also for other types of networkcommunication protocols besides CAN [9].

15

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 moreECUs, 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 responseshave well-defined, unique Service Identifiers, SIDs. Besides the SID, the request/responsealso contain additional data known as data parameters. The protocol specifies which dataparameters are mandatory and which are optional for each service [25]. A SID is one bytelong 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 theparameters is to describe what the service should do. For example, the diagnostic servicewith SID 0x10 tells the ECU to change the diagnostic session and the parameter sentalong 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 ifits diagnostic function successfully processed the response. The standards prescribe thatthe response SID should be the corresponding request SID added by 0x40.

Response SID = Request SID + 0x40

For example the positive response of a successful change of diagnostic session is 0x50.

If the ECU is not able to perform the requested operation, it sends a negative response.There can be many different reasons for a negative response; insufficient security level,

16

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 hasa fix negative response SID: 0x7F. A negative response is always accompanied by abyte 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 Meaning0x11 The requested service in not supported0x21 The ECU is temporarily unable to perform the required operation. Repeat the request0x13 The message length or the format of the request is not valid0x84 Engine is not running0x85 Temperature is too high0x88 Vehicle speed is too high0x8F 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 toa specific ECU, the tester needs to know the address of the ECU, and conversely, the ECUmust know the address of the tester in order to send a response back. The diagnosticprotocols use CAN IDs for addressing. Furthermore, there are two ways to addressECUs: physical addressing and functional addressing. Physical addressing involves a1-to-1 relationship between the tester and the ECU. Both the tester and the ECU haveunique IDs and if the tester sends a request to a specific ECU, the ECU will send backa 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 agroup 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 onthe network as only one service request is needed, as opposed to sending several servicerequest to individual ECUs [25].

Figure 2.8a portrays physical addressing with 1:1 relation, and figure 2.8b portrays func-tional addressing with a 1:n relation.

17

(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 CANframe. Many times, however, data of larger sizes are exchanged between the tester andthe ECUs, and for this purpose a mechanism called data segmentation is provided by thetransport and the network layers [25]. Both the tester and the ECU can initiate datasegmentation, i.e. both request and response messages that do not fit a single data framecan trigger data segmentation.

There are four different types of diagnostic frames [9], see table 2.5. The frames arespecified by so called Protocol Control Information (PCI) blocks that serve to identifythe 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. Amessage 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 7through 4) contains the frame type identifier: 0 and the second nibble contains the datalength in bytes from zero to seven.

Frame Type Frame Type Identifier (hex)Single Frame (SF) 0x00First Frame (FF) 0x01Consecutive Frame 0x02Flow Control (FC) 0x03

Table 2.5: Different diagnostic frame types.

When the transport protocol detects that a message does not fit a single frame, theframe type First Frame (FF) is generated. It serves as an indication that a segmentedcommunication follows. FF contains two PCI bytes; the first nibble of the first bytecontains the coded value of the frame type: 1, and the second nibble and the subsequentbyte (i.e. total of 4+8=12 bits) represents the data length in bytes, with values rangingfrom 8 through 4095. These bits are often referred to as FF DL. The remaining 6 bytescontain the first 6 bytes of the message data. The receiver of the segmented response

18

affirms the FF by sending a Flow Control (FC). The FC contains important informationabout the capabilities of the receiver that the sender must adhere to, giving the receiverthe possibility to control the traffic flow using flow control parameters. FC contains thefollowing 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) thesender is allowed to transmit before the receiver is expected to transmit anotherFC. If the block size is zero, the transmitter transmits consecutive frames withoutwaiting 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 containsthe flow status. The second PCI byte contains the block size and the third byte containsthe separation time. Values from 0x00 to 0x7F determine a separation time from 0 ms to127 ms. The flow control parameters are necessary to avoid overloading at the receiver’sside 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 nibblecontains the sequence number between 1 and 15; 1 represents the first CF and 15 isthe maximum sequence number (0xFF). If more CFs are needed, the sequence numbercounter restarts at 0 [12].

Figure 2.9: PCI blocks of different diagnostic frames.

19

Chapter 3

Bandwidth Management

Bandwidth management is the art of measuring and controlling the traffic on a networklink with the aim of avoiding overfilling the network link capacity, which can result innetwork 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 theconcept of Quality-of-Service (QoS).

3.1 Related Work

There are no technical publications concerning bandwidth management for in-vehiclenetwork systems using CAN. However, bandwidth management is widely used in othernetwork systems using Ethernet and the methods and techniques employed there can alsobe applied to CAN, with some slight modifications. Among the literature on bandwidthmanagement using the Ethernet protocol, the approach introduced by Rahmani et al. [29]is most relevant to the problem discussed in this thesis. The authors [29] investigate an in-vehicle network architecture based on the Internet Protocol and Ethernet (IP/Ethernet)for real-time audio and video streaming, as well as control messages needed for driverassistance services. Multimedia applications such as audio and video streaming requirelarge amount of network resources in terms of transmission rate and switch buffer sizes.The authors argue that the mechanism of traffic shaping can be applied in order to reducethe required network resources and to increase cost efficiency. The paper mentions a trafficshaping algorithm called Token Bucket (TB), which the authors argue is one of the mostpopular traffic shaping algorithms in the literature. In addition to the TB algorithm, theauthors also present a novel traffic shaping algorithm named Simple Traffic Smoother(STS). STS reduces the peak transmission rate by sending the packets of each pictureframe with a certain time distance between them, as opposed to sending the packets veryclose in succession as a burst into the network. STS stores all the packets of picture framesthat have been received within a pre-defined smoothing interval and sends them into thenetwork equally spaced in time. For more information about the internal workings of theproposed shaping algorithm, the reader is referred to the article [29].

20

The article explains nicely how traffic shaping can be used as an approach for bandwidthmanagement in a network. The article also mentions the Token Bucket algorithm, whichis a potential candidate for a shaping algorithm to be used in the regulator. The followingparagraphs 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 arecommonly used to provide QoS:

Traffic shaping Controls network traffic by buffering and smoothing the output rate toensure 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 networknext

Congestion avoidance

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

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

Traffic shaping controls traffic by buffering and smoothing the network traffic before itenters 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 latertransmission to maintain a desired traffic flow profile. Care must be taken that thebuffer contains sufficient memory to buffer the excess traffic. Traffic shaping requiresa 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 thatexcess traffic diverging from defined limits are buffered, means that queuing delays canbe introduced [14,16].

Shaping is similar to policing, however, the latter differs in one critical way: when thenetwork traffic rate reaches the specified limit, excess traffic is dropped. This is whatgives the appearance of a zig-zag shape in diagram 3.1. Traffic shaping, on the otherhand, puts the excess packets in a queue and schedules them for later transmission [16].This results in a smoother packet output rate.

21

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 isan analogy of a fix-sized bucket into which tokens are added at a fix rate r. The tokens areusually represented as units of bytes or single packets of fix sizes. If the bucket containsthe maximum number of tokens, TBmax, no more tokens are added to it. An in-comingpacket can only be transmitted if the bucket has a sufficient number of tokens in the

Figure 3.2: Token Bucket

22

bucket; if a packet of m bytes arrives, m tokens are removed from the bucket and thepacket is sent to the network. If, however, the bucket contains an insufficient number oftokens at the arrival of a packet, the packet must be buffered until enough tokens havebeen added to the bucket. The maximum size of the buffer is Bmax. Initially, the tokenbucket is full and the buffer is empty, i.e. TB(t)=TBmax and B(t)=0 bytes. The bufferusually follows the FIFO principle; it serves the packets in the order they arrive [8]. Withthis algorithm the output rate varies depending on the size of the burst. Burstiness isused as a measurement of variations in the network traffic flow. The content of the bucketat any instance of time depends on the burstiness of the traffic flow [16].

23

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 methodand 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 mainCAN segments: red, yellow, and green. The red segment contains the most talkativeECUs and it puts the highest base load on the network out of all the segments. TheECUs that reside here are responsible for more time critical applications with hard real-time constraints. ECUs with slightly lower real-time requirements reside on to the yellowsegment. The yellow segment is also highly active and puts a considerable load on thenetwork, but to a lesser degree than the red bus. The green segment puts a low loadduring normal operation of the vehicle and it is here that the OBD port for diagnosticcommunication is located.

The Coordinator (COO) is a gateway ECU that lies between the segments. It bridgesand filters the information flow between the segments. COO has buffers in which it cansave in-coming frames. There is a delta bus load at the COO and the segments can havedifferent 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 theyellow and the red segments. Diagnostic data is sent with the highest possible speed onthe green segment and COO has to store this traffic in internal buffers as it cannot bewritten at the same speed to the yellow and the red segments because of the high busloads there. The buffer in COO is a FIFO type queue with limited capacity and theproblem here is that if a lot of diagnostic traffic is generated on the green segment, thebuffer will eventually overflow and frames are dropped as a consequence.

As a way to tackle this, recommendations were made for a network architecture whichinvolves relocating the OBD-port to the yellow segment in connection to a special-purposeECU called the Road Traffic Communicator (RTC) [26]. RTC is a computer platform

24

operating in Linux with a real-time kernel and its main purpose is to perform remotediagnostics and data transfer and it has communicative modules for 3G, Bluetooth, WiFias 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 RTChas more than one CAN interface; one which is used to connect to the yellow CANsegment, and the other can be used for creating an OBD bus. As the yellow segmenttypically has a considerably higher base load, the COO runs lower risk to overflow itsbuffers.

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

Figure 4.1: Diagnostic access point and CAN interfaces of RTC

25

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 theBerkeley socket API (the Linux network stack) and abstracts the CAN controller devicedrivers as network devices, which allow the CAN messages to be passed from the hardwaredevice to the network layer [5]. The CAN socket API has been designed to be as similaras possible to the TCP/IP sockets so that programmers with experience in networkprogramming easily can get started with CAN sockets. The typical Linux system callslike: bind(), read() and write() are also used to communicate with CAN devices. Justlike 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) protocoland the broadcast manager (BCM). CAN RAW is used for direct point-to-point CANcommunication 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 theapplication to do as it will. The CAN frames are represented by a C type struct calledcan 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 bythe 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 andwriting CAN frames.

Two CAN sockets are opened in the access point for the purpose of relaying CAN networktraffic between the sockets. The sockets are named yellow can and obd can. Figure 4.2shows the basic design of the access point with CAN frames arriving at the yellow segmentand at the OBD segment. The Linux select function is used to check if CAN frames havearrived at any of the two sockets and relays the frames accordingly.

26

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 thethesis project.

The following hardware were needed:

• Two ECUs, including the RTC

• Power supply

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

• Diagnostic tool (VCI: Vehicle Communication Interface) to connect the PC to theCAN system via the OBD port

27

• 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 andthe Instrument Cluster (ICL) was chosen for this purpose. The chosen version of the ICLruns the KWP2000 diagnostic protocol. The main advantage of using ICL is that it isequipped with displays with different lights and signals that make the effects of runningdiagnostics 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, whichincludes 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 betweenthe virtual machine and RTC. VCI is a diagnostic tool that connects a computer to thein-vehicle CAN communication bus through the OBD port using a USB cable. The mainobjective of a VCI is to translate messages from a format the computer understands tothe vehicle’s communication format, CAN in this case.

A special communication module developed by Scania was also required, which handlesthe diagnostic communication over CAN with a comprehensive high-level API interfaceto the ECUs. The module also provides communication logs. One advantage of usingthis module is that it makes the diagnostic communication transparent for the testerby for example hiding the diagnostic protocol used by the ECUs, by taking care of thesession transitions as well as unlocking security access whenever necessary. This moduleis the underlying layer in the current system architecture that receives requests from thediagnostic 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 trafficand the generated logs with information such as timestamps of when the CAN framesare transmitted as well as the content of the frames. Another indispensable feature wasstatistics regarding bus utilisation and frequencies of transmitted CAN frames. A pieceof hardware called CANcaseXL was required for running CANAlyzer. CANcaseXL is a32 bit 64MHz micro-controller equipped with two CAN controllers that were connectedto the yellow bus and the OBD bus of the RTC, respectively.

4.4 CAN Frame Size and Transfer Time

Prior to describing the steps for realising the regulator, an analysis of the CAN buscommunication protocol is necessary with respect to maximum and minimum CAN frame

28

sizes and transfer times, as these findings will be relevant for the subsequent sections inthe 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 ofapplying bit stuffing [27]. The following bit sequence consisting of 16 bits is studied as anexample: 00000111100001111. Figure 4.3a represents the bit sequence without applyingbit stuffing. The frame commences with an SOF bit (with value 0) followed by fourconsecutive 0-value bits. According to the rules of bit stuffing; after five consecutive bitswith 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 consecutive1-bits, which is followed by an inserted 0-bit value and so on. Figure 4.3b illustratesthe bit stream with stuffed bits, and it can be observed that for the 16 bits, 4 bits areinserted. This example represents the “worst-case” sequence of bit values as each time abit is inserted a chain reaction occurs of more bits being inserted. The maximum numberof stuffed bits can thus be estimated by dividing the length of the message by 4 and byrounding 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 notencoded with bit stuffing and out of the segments that are encoded with bit stuffing, allbits except the data segment are fix; there are 54 such bits. Hence, the total number ofbits in a frame (including stuffed bits) can be obtained by equation 4.2. N ∈ [0, 8] is thelength of the data segment in bytes and 67 is the sum of the 13 bits that are not affectedby bit stuffing and the 54 bits that are fix.

8N + 67 + d54 + 8N

4e (4.2)

29

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

N [byte] Total length [bit]0 811 912 1013 1114 1215 1316 1417 1518 161

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

Table 4.2 contains the CAN frame sizes without applying bit stuffing.

N [byte] Total length [bit]0 671 752 833 914 995 1076 1157 1238 131

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

As previously mentioned in section 2.5, the J1939 protocol used by Scania and otherautomotive industries, always uses 8 bytes for the data segment. Thus, the maximumsize of a CAN frame is 161 bits and the minimum length is 131 bits with N=8. The resultof 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

The maximum transmission time can be estimated if the bit rate of the CAN networkbus is known. For this kind of estimation the previously calculated message lengthsare multiplied by the transmission time of one bit, tbit. The CAN protocol allows bitrates up to of 1 Mbit/s, 500 Kbit/s and 250 Kbit/s, among others. Table 4.3 shows the

30

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

Bit rate Bit times1 Mbit/s 1 µs

500 Kbit/s 2 µs250 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 4131 0.0005240 1908.40161 0.000644 1552.80

500 Kbit/s 2131 0.0002620 3816.7161 0.000322 3105.59

1000 Mbit/s 1131 0.0001310 7633.59161 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. Column4 contains the values of the maximum and the minimum frequencies with which CANframes can be transferred.

4.5 Bus load Calculator

Base load refers to the bus load that is exerted by the on-board communication betweenECUs. A key component of the regulator is to know how high the base load is and,today, there exists no support for finding out this value without using external tools likeCANAlyzer. Thus, an implementation of a bus load calculator is required in the RTC.A decision had to be made regarding what temporal spectrum to measure the bus load in.The CAN bit rate is measured in number of bits per second, eg. 1 Mbit/s, 500 Kbit/s, 250Kbit/s etc. CANAlyzer measures the bus load in terms of the ratio of bits that are sentinto the network out of the allowed maximum number of bits each second. The bus loadcalculation in the RTC was also decided to be expressed as the number of bits transferredinto the network out of the maximum number of bits that the network has capacity totransmit each second. At a first glance, a candidate solution would be to keep a counterthat increments its value every time a CAN frame appears at the yellow segment (i.e.every time the select function notifies that a message has arrived at the socket associatedwith the yellow segment) and then each time a second has passed, multiply the counterwith the size of a CAN frame in units of bits and finally divide the result with the bit rate.CAN frames have different sizes as a consequence of applying bit stuffing, as discussedin section 4.4. Hence, the method just described would only yield an average value of

31

the bus load. In order get exact values of the bus load, however, the exact lengths of theindividual CAN frames must be known and the following paragraphs discuss how thiscan 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 CANspecification. This had to be rectified before bit stuffing could be applied to the bitsequences 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 CANspecification mandates that the CAN ID commences with 11 bits ID (base ID), followedby an SRR and an IDE bit, the remaining 18 bits of the CAN ID (extended ID) andlastly an RTR bit (see figure 2.2). The rearrangement was accomplished by basic bitarithmetic and bit masking, as illustrated by the following code snipped:

base id mask = 0x1FFC0000 ; //11111111111000000000000000000

b a s e i d = (∗ id & base id mask ) >> (32−3−11);extended id mask= 0x3FFFF ; //111111111111111111

extended id = (∗ id & extended id mask ) ;newARB = b a s e i d << (32−11);newARB = newARB | 0x180000 ; //SRR & IDE: 110000000000000000000

newARB = newARBˆ( extended id <<1); //Recessive bit for the RTR bit.

bits Abbreviation Description0-28 CAN ID 29 bit CAN ID

29 ERR Error Frame Flag 0=data frame, 1=error frame30 RTR Remote Transmission Request flag, 1 = rtr frame31 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 validCAN frame. Bit stuffing is applied to the SOF bit, the arbitration field, control field, thedata field as well as the CRC sequence. The CRC sequence is not given by SocketCANand it needs to be calculated as the final step before applying bit stuffing.

4.5.2 CRC Sequence Calculation

As discussed in section 2.3.1, the CRC sequence is a cyclic redundancy code of length 15bits. The calculation of the CRC sequence is a polynomial long division. The dividend isthe polynomial whose coefficients are obtained from the bit sequence consisting of SOF,ARB, CNTRL and DATA without any stuffed bits, calculated modulo-2. The divisor isthe generator-polynomial X15 +X14 +X10 +X8 +X7 +X4 +X3 +1, with coefficients also

32

calculated modulo-2, yielding: 1100010110011001. The quotient of the polynomial divi-sion is discarded and the remainder is what becomes the CRC sequence. The correctnessof 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 takenote of the value of the first bit. A counter variable increments its value each time theconsecutive bit has the same value as the previous one. If 5 consecutive bits with thesame values have been detected, insert a bit of the opposite value. Otherwise, reset thecounter 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 yellowsegment during the period of one second and the sum of the lengths of the frame sizesis stored in a global variable. Figure 4.4 illustrates how the bus load is calculated: thethread pthread busload sleeps during one second and when it awakens takes the sum of thelengths of all the in-coming CAN frames that arrived during that second and calculatesthe bus load according to equation 4.3:

bus load =

∑ni=1 size(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 shouldonly apply to the frames that participate in the on-board communication and not framesbelonging to diagnostic communication. A way of classifying the frames as either part ofon-board or diagnostic communication was achieved by checking the PGN of the framesas shown in the code snippet below:

bool i s D i a g n o s t i c (∗ id ){if ( ! ( ( ∗ id ˆ0x18DA0000)&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 calculatingthe base load, the thread also calculates the available bandwidth according to formula4.4.

available bandwidth = max threshold− base load (4.4)

33

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

Exceeding the maximum threshold causes frames to drop as the maximum capacity ofthe network is reached. The max threshold is not necessarily reached at 100%, it can beless. 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 configurationswith varying numbers of ECUs in the CAN network. Figure 4.5 shows the InteractiveGenerator Block (IG) that is used to generate CAN frames in CANAlyzer. By changingthe values of the cycle times, the value of the bus load can be increased or decreased in acontrolled manner. Table 4.6 contains the bus loads that were obtained by changing thecycle 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 allowsthe 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)

Cycle Time× 1000× bit rate× 100 (4.5)

34

Cycle Time [ms] Bus load [%]1 602 303 204 155 126 1010 612 515 420 3

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

4.6 Maximum Threshold

The CAN network bus should never be utilised to such an extent that CAN framesare dropped as a result. By applying the regulation algorithm explored in this thesisproject, the diagnostic network traffic is guaranteed to stay within prescribed limits, thuspreventing the bus load from reaching such critical limits. As an attempt to find out thevalue of the critical limit, a series of test was conducted by increasing the base load insteps using table 4.6 and at each step diagnostic services were performed whilst keepingthe CAN network and the network bus utilisation under close inspection. The test wasconducted with two different diagnostic services that both exert substantial loads on thenetwork. 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 Controlparameter 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 sentinto 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 yielddiagnostic loads that confirm to the available bandwidth. However, FCs are only gener-ated whenever data segmentation occurs and not all diagnostic services are necessarilyexecuted with data segmentation. To circumvent this restriction of the regulator, theToken Bucket algorithm is used.

Figure 4.6 illustrates the out-bound link (egress) and the in-bound link (ingress) of theyellow segment. Traffic shaping algorithms (eg. Token Bucket) can be applied on theegress traffic, i.e. the diagnostic network traffic that originates from the OBD bus. Ingresstraffic, on the other hand, cannot be regulated in the same fashion as it depends entirelyon the configuration of the ECU. However, when the ECU sends consecutive frames (as

35

part of data segmentation), the flow control parameters can be used to shape the traffic atthe 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 flowcontrol parameters at the ingress link. The latter is referred to as the ISO-TP algorithmin the remaining of the report.

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

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

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

That the ISO-TP algorithm is only applied at the ingress link is not the entire truth.Some diagnostic services require read operations and some require write operations. Thetester can issue a diagnostic request to read something from the ECU’s memory; i.e. aread-request. If the requested data does not fit a single frame, data segmentation occursand consecutive frames are sent in direction: ECU to tester, and hence the flow controlframe is sent in direction: tester to ECU. In this case the ISO-TP algorithm is applied atthe ingress link. But there are also requests that require write operations to store data inthe ECU’s memory, and in this case the consecutive frames are sent in direction: testerto ECU, and the flow control frame is sent in direction: ECU to tester. In this case theISO-TP algorithm is applied at the egress link instead.

36

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

4.8 ISO-TP Algorithm

The figures 4.8 and 4.9 illustrate how the diagnostic communication can be done in twodirections 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 diagnostictraffic flow requires shaping, which is the case whenever the diagnostic load exceeds theavailable bandwidth. In figure 4.8 we see that the client sends a diagnostic request as asingle frame and that the server responds with a first frame, indicating that the responsewill contain data larger than 8 bytes. This gives the client the possibility of controllingthe traffic flow using the flow control fame and its parameters. The server must conformto these paramenters when sending the consecutive frames. Figure 4.9 illustrates thatthe client is requesting data to be stored in the server’s memory; i.e. the client sendsconsecutive frames to the server, giving the server the possibility of shaping the data flowusing 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

A necessary component of the ISO-TP algorithm is to know the diagnostic bus loads ex-erted by the diagnostic services so that appropriate values can be assigned to STmin.

37

Figure 4.8: Read operation ISO-TP

38

Figure 4.9: Write operation ISO-TP

4.8.1 Data Gathering

Different diagnostic services generate varying numbers of CAN frames and consequentlyexert varying bus loads on the network. The regulator needs to know the bus loadsthat are exerted by the diagnostic services in order to assign suitable values to STmin.However, the regulator is totally ignorant to what the in-coming CAN frames are andwhich diagnostic services they correspond to. Moreover, the regulator does not know howmuch bus load the services generate. Therefore, this information must be provided bymeans of pre-recorded data, which is referred to as look-up table in the the report. Usingpre-recorded data in this fashion is like a double-edged sword; while speeding up thealgorithm by using pre-recorded data, the data must be maintained and administrated

39

for the different ECUs.

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

Service namesReadECUIdentificationReadValuesReadSOPS fileWriteSOPS file

Table 4.7: The diagnostic services chosen for analysis

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

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

When inspecting the logs in greater detail, it was discovered that each of the application-layer services are broken down into a sequence of smaller services, referred to as sub-services. Each such sub-service consists of a request and a block of data containing theresponse. The question arising now is what the look-up table should actually contain: thediagnostic load of the entire application-layer service, i.e. including all the sub-services, orthe diagnostic loads exerted by the individual sub-services? The initially chosen approachinvolved looking at the individual sub-services and the bus loads they exert. The querykey to the look-up table is the service ID of the individual sub-services and the queryvalue is the corresponding bus loads. However, as the project progressed it became moreand more evident that a complication existed with the chosen approach and it had todo with the fact that the bus load distribution in time cannot be known nor predicted;more than one block of request and responses generated by the individual sub-servicesare sent into the network per second. This becomes evident with the following example:the sub-service 0xAF 03, part of WriteSOPS, generates 67 CAN frames. A CAN networkworking at 250 Kbit/s with 30% available bandwidth has the capacity of sending 75000bits/s whereas 67 CAN frames only amount to an average of 9246 bits. The fact that thebus load distribution in time cannot be predicted complicates for the ISO-TP algorithm

40

at the time of choosing a suitable value for STmin.

The new approach instead involved populating the look-up table with information aboutthe 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 theexecution times of the application-layer service (as a consequence of applying differentdelays using STmin), as well as the total data volume (i.e. the total number of generatedCAN frames) were required. Irrespective of whether delays are applied, the data volumeremains constant. By dividing the data volume with the execution times, the averagefrequencies of CAN frames/s are obtained. From the average frequencies, the averagebus loads/s are obtained by applying the equation 4.5 in section 4.5. One underpinningassumption is that the diagnostic load is evenly distributed in time. The execution timesand 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-comingrequest generates segmented data? This ability of the regulator is integral in the decisionmaking of which traffic shaping algorithm to apply. The chosen approach was to querythe 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 beused, otherwise Token Bucket is chosen. This is illustrated by 4.10.

Figure 4.10: Flow chart of ISO-TP algorithm

As an attempt to facilitate the analysis of the considerably large log files, a method of

41

calculating the number of generated frames as well as the corresponding bus loads wasdeveloped, 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 servicesthat trigger data segmentation transmit a First Frame that contains information abouthow 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 FCsthat are transmitted in the response.

total CFs =

1 if FF DL <= 13(FF DL−6)

7if(FF DL-6) mod 7 == 0⌊

(FF DL−6)7

⌋+ 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 (1byte occupied by the PCI block). If FF DL is greater than 13, the two subsequent casessubtract the 6 bytes that are transferred with FF and depending on whether an evennumber of CFs is required, one additional CF may or may not be needed.

total FCs =

1 if BlockSize == 0total CFsBlockSize

if total CFsBlockSize

mod 2 == 0⌊total CFsBlockSize

⌋+ 1 else

(4.8)

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

As an illustration of how the equations are applied, the block in figure 4.11 is used to cal-culate the number of frames that is generated by the diagnostic request with SID=0xB1.Each row represents one transmitted CAN frame and there is a total of 6 CAN frames.By applying the equations 4.6, 4.7 and 4.8 the same number is acquired. The FF DL(line 2) is 0x19, which equals 25 in decimal representation. When applying equation 4.7,the total number of CFs is 3, which can easily be verified in the figure. Line 3 showsthat BlockSize equals 0x00 (the second byte), and according to equation 4.8 only oneFC is transmitted. Lastly, by using equation 4.6 the total number of generated frames is6.

42

Figure 4.11: Example block of diagnostic request and response

The total generated bus load is calculated using equation 4.9.

busload =total nr generated frames ∗ size(frame)avg

CAN bit rate∗ 100 (4.9)

4.8.3 Token Bucket

Figure 4.7 illustrates what happens when a diagnostic request arrives at the access point;if the diagnostic request does not trigger data segmentation, Token Bucket is chosen asthe traffic shaping algorithm. Expressed differently, Token Bucket is used whenever thereare single frames being sent into the network.

Figure 4.12 illustrates how Token Bucket was implemented in the regulator. There arethree different threads at play: pthread tokenBucket, pthread tbReceiver andpthread sender. One token represents one CAN frame; i.e. if the bucket contains 10tokens, 10 CAN frames are allowed to transmit. The thread pthread tokenBucket is inan infinite loop, where it stays dormant for one second and then awakens to update thenumber of tokens to a value that represent the number of CAN frames that are allowedto be transmitted during one second. This value is calculated by equation 4.10.

Allowed frequency =available bandwidth× bit rate

size(frame)avg × 100(4.10)

Each time a diagnostic request arrives (and after making sure that it does not gen-erate data segmentation) pthread tbReceiver is notified and awakens from its sleep.pthread tbReceiver checks some conditions to see if it can transmit the CAN framedirectly or whether the CAN frame should be buffered. The conditions that must befulfilled in order for pthread tbReceiver to send a CAN frame directly is: the buffershould be empty, there should be at least one token in the bucket and, lastly, no otherCAN frames should be transmitting currently. If one of the these conditions are notfulfilled, the frame is buffered and the thread is pthread sender is notified and awokenfrom its sleep. pthread sender stays awake until all the buffered CAN frames have beentransmitted. Always before transmitting a frame it makes sure that there is a sufficientamount of tokens to consume. If there is an insufficient amount of tokens in the bucket,it tries the next clock cycle of one second when the bucket has been refilled.

43

Fig

ure

4.12

:T

he

wor

kin

gsof

the

Tok

enB

uck

etal

gori

thm

44

Chapter 5

Results

The main objective of the regulator is to make sure that the diagnostic network trafficconforms to the available bandwidth and to optimise the network bandwidth utilisationfor diagnostic communication without imposing fixed delays in the system. In the presentsystem, a delay of 9 ms is imposed whenever performing remote diagnostics through RTC.This delay of 9 ms is to a large extent conservative for many vehicle configurations andit results in an inefficient utilisation of the network bandwidth. With the regulator,however, delays are set in accordance to the network bus capacity. This chapter presentsthe results obtained from conducting the tests and the computations described in theprevious chapter.

5.1 Bus Load Calculation Results

This section presents the results from the bus load calculations in RTC. The obtainedresults are compared to the bus loads measured by CANAlyzer.

The graphs 5.1, 5.2, and 5.3 are the results of the bus load calculations as measuredby the regulator and CANAlyzer at base loads around 30%, 60% and 90%, respectively.It is evident from the figures that the bus load measured by the regulator in RTC isconstantly less than the bus load measured by CANAlyzer. In graph 5.1 the averageerror per second is 0.667, in graph 5.2 the average error per second is 1.246, and lastly ingraph 5.3 the error rate increases to 1.836. It can be observed in the graphs that as thebase load increases, the average error per second also increases.

45

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

Figure 5.2: Bus load comparison: regulator versus CANAlyzer at base load 60%

46

Figure 5.3: Bus load comparison: regulator versus CANAlyzer at base load 90%

The reason for this difference in calculations is likely due to different approaches of howthe CAN frame sizes are calculated. A closer inspection revealed that the regulatorcalculates frame sizes which are always 3 bits less than the frame sizes calculated byCANAlyzer. Table 5.1 presents this observation.

It turns out that CANAlyzer takes the Interframe Space (IFS) between CAN framesinto account when calculating the frame sizes. IFS, according to the CAN standard [15],contains two fields: intermission and bus idle. The intermission field contains threerecessive bits and during the intermission period no node is allowed to transmit. Amessage which is pending for transmission is started in the first bit after the intermissionperiod. When designing the frame size calculation in CANAlyzer, the developers musthave reasoned that as no other node is allowed to transmit during the intermission period,the 3 bits can be regarded as a part of the frame itself. Adopting this approach in theframe size calculator, the obtained bus loads were close to identical as illustrated by thegraphs: 5.4, 5.5 and 5.6.

47

CANAlyzer RegulatorID Frame size ∆size18FEEA17 144 141 318D0FF17 144 141 318FF9617 145 142 318FFD517 145 142 31CDEEE17 145 142 318FD7D17 138 135 318FEE617 140 137 318FF6017 142 139 318FEF517 143 140 318FFFBE6 148 145 318FFFB21 146 143 318FF9617 145 142 318FEF521 139 136 3CFE5A21 146 143 318FEF527 138 135 3CFE5A40 148 145 3

Table 5.1: Difference in frame sizes as calculated by RTC and CANAlyzer

Figure 5.4: Modified bus load calculation at base load 30%

48

Figure 5.5: Modified bus load calculation at base load 60%

Figure 5.6: Modified bus load calculation at base load 90%

49

5.2 Data Gathering Results

This section presents the findings from the analyses of the logs generated by the diagnosticservices as described in section 4.8.1. As previously mentioned, the initial approach wasto administer a look-up table with the bus loads generated by the individual sub-services.However, decisions cannot be made for how the diagnostic traffic should be regulated justby looking at the bus loads generated by the individual sub-services. The distributionof the diagnostic bus load in time cannot be predicted. Instead, another approach wasadopted, which focuses on the application-layer services and the bus loads they exertevery second with different values of STmin. Both versions of the look-up table arepresented in the subsequent sections marked with the headers “Version I” and “VersionII”.

5.2.1 ReadECUIdentification

From the analysis of the logs generated by ReadECUIdentification, it was discovered thatthis application-layer service consists of the following sequence of sub-services:

Sub-service Description0xAF 80 Requests a data table that contains a multitude of different iden-

tifiers for the ICL, including e.g. software and hardware versionnumbers.

0xAF 81 Requests a scaling table needed for interpreting the format of theobtained identifiers

0xB1 00 Reads out the status flash configuration

Table 5.2: ReadECUIdentification sub-services

The actual meaning of the services is of less relevance. What is important, however, is thenumber of CAN frames that are generated when performing readECUIdentification.

Apart from the sub-services in Table 5.2, there are diagnostic requests responsible forchanging sessions that are deliberately ignored for the sake of not over-complicating theanalysis.

Figure 5.7 illustrates the bus load generated by ReadECUIdentification with no delaysusing CANAlyzer. Calculating the area under the graph yields the total diagnostic load:3.97%. The calculation of the bus load by hand from table 5.3 yields 3.42%. As previouslystated, there are other sub-services that are generated like eg. changing the session thathave been ignored and this serves as an explanation to why the bus loads differ.

50

Figure 5.7: Bus load generated by ReadECUIdentification.

Version I

Table 5.3 contains the total number of generated frames for each sub-service as well asthe corresponding diagnostic loads. The values were obtained by applying the equationsdefined in section 4.8.2.

Sub-service FF DL Generated frames Generated bus load [%]0xAF 80 0x109 40 2.210xAF 81 0x5E 16 0.880xB1 00 0x19 6 0.33

Table 5.3: Generated bus loads of the ReadECUIdentification sub-services

Version II

The average execution time and the average data volume of ReadECUIdentification wereobtained by running the service 50 times, and the average frequency as well as the averagebus load were calculated according to the method described in 4.8.1. The results arepresented in table 5.4. Column 1 (STmin) and column 4 (AVG busload/s) contain thevalues to be stored in the look-up table.

To verify the validity of the calculation, the service was run under close inspection usingCANAlyzer and with STmin=0. The results of the analysis is presented in table 5.5.The first and the second column represent the exact frequency and bus load as measuredby CANAlyzer. Column three and four are the lower and the upper bounds of the busload calculated by using the minimum and the maximum CAN frame sizes: 131 and 161bits.

51

STmin AVG data volume AVG exec time [s] AVG fr/s AVG bus load/s0 72 3.616 19.91151921 1.0991 72 3.834 18.77934452 1.0372 72 3.855 18.67702654 1.0315 72 4.108 17.52888578 0.96810 72 4.646 15.49884381 0.856

Table 5.4: Execution time, frequency (frames/s) and bus load of ReadECUIdentificationwith different STmin values

fr/s diagnostic load/s [%] Lower limit [%] Upper limit [%]2 0.11 0.10 0.131 0.06 0.05 0.066 0.34 0.31 0.3962 3.41 3.25 3.99

Table 5.5: Bus load analysis of ReadECUIdentification using CANAnalyzer withSTmin=0. Sum of column 2 yield total bus load=3.92%

5.2.2 ReadSOPS

The application-layer service ReadSOPS is far more extensive in respect to how manyCAN frames that are generated in comparison to ReadECUIdentification.

The area under graph 5.8 equals the total diagnostic load: 215.2%. And the total diag-nostic load as a result of the hand calculation is: 217.8272%

Figure 5.8: The total bus load generated by ReadSOPS

52

Version I

Table 5.6 contains the sub-services that together constitute ReadSOPS. The last columnspecifies how many CAN frames with the same ID and the same value of FF DL aretransmitted into the network.

Sub-service FF DL Generated frames Generated bus load [%] Amount0xAF 01 0x0A 4 0.22880 10xAF 04 0x43 12 0.6624 10xAF 04 0x383 131 7.2312 30

Table 5.6: ReadSOPS sub-services

Version II

The average execution time and the average data volume of ReadSOPS were obtained byrunning the service 50 times, and the average frequency as well as the average bus loadwere calculated according to the method described in 4.8.1. The results are presented intable 5.7. Column 1 (STmin) and column 4 (AVG busload/s) contain the values to bestored in the look-up table.

STmin AVG data volume AVG exec time [s] AVG fr/s AVG bus load/s0 3935 20.889 188.378 10.3981 3935 40.101 98.127 5.4172 3935 40.121 98.078 5.4145 3935 59.419 66.225 3.65610 3935 97.839 40.219 2.220

Table 5.7: Execution time, frequency (frames/s) and bus load of ReadSOPS with differentSTmin values

To verify the validity of the calculation, the service was run under close inspection usingCANAlyzer and with STmin=0. The results of the analysis is presented in table 5.8.The first and the second column represent the exact frequency and diagnostic load/s, asmeasured by CANAlyzer. Column three and four are the lower and the upper bounds ofthe bus load calculated by using the minimum and the maximum CAN frame sizes: 131and 161 bits.

53

fr/s diagnostic load/s [%] Lower limit [%] Upper limit [%]56 3 2.93 3.61193 10 10.11 12.43186 10 9.75 11.98193 10 10.11 12.43186 10 9.75 11.98193 10 10.11 12.43189 10 9.90 12.17190 10 9.96 12.24190 10 9.96 12.24182 9 9.54 11.72193 10 10.11 12.43186 10 9.75 11.98193 10 10.11 12.43184 10 9.64 11.85193 10 10.11 12.43192 10 10.06 12.36187 10 9.80 12.04193 10 10.11 12.43186 9 9.75 11.98192 10 10.06 12.36186 9 9.75 11.98103 5 5.40 6.63

Table 5.8: Analysis of ReadSOPS using CANAnalyzer and STmin=0

It can be seen in table 5.11 that the frequency and the diagnostic loads are not evenlydistributed. Another observations is that the obtained average values of the frequencyand the bus load in table 5.10 are pretty accurate and it can be verified that the averagebus load lies between the allowed lower and upper limits.

5.2.3 WriteSOPS

As can be expected, WriteSOPS also generates a substantial amount of CAN frames.

The area under graph 5.9 equals the total diagnostic load: 221.29%. The total diagnosticload as a result of the hand calculation is: 219%.

54

Figure 5.9: The total bus load generated by WriteSOPS

Version I

Table 5.9 contains the sub-services that together constitute writeSOPS. The last columnspecifies how many CAN frames with the same ID and the same value of FF DL aretransmitted into the network.

Sub-service FF DL Generated frames Generated bus load [%] Amount0xAF 01 0x0A 4 0.2208 10x2E 00 0x0D 4 0.2208 10x2E 00 0x09 4 0.2208 10xAF 03 0x1C4 67 3.6984 59

Table 5.9: WriteSOPS sub-services

Version II

The average execution time and the average data volume of WriteSOPS were obtained byrunning the service 50 times, and the average frequency as well as the average bus loadwere calculated according to the method described in 4.8.1. The results are presented intable 5.10. Column 1 (STmin) and column 4 (AVG busload/s) contain the values to bestored in the look-up table.

To verify the validity of the calculation, the service was run under close inspection usingCANAlyzer and with STmin=0. The results of the analysis is presented in table 5.11.The first and the second column represent the exact frequency and diagnostic load/s, asmeasured by CANAlyzer. Column three and four are the lower and the upper bounds of

55

the bus load calculated by using the minimum and the maximum CAN frame sizes: 131and 161 bits.

STmin AVG data volume AVG exec time [s] AVG fr/s AVG bus load/s0 4055 11.75 345.147 19.0521 4055 22.29 181.84 10.0382 4055 23.80 170.36 9.405 4055 27.35 148.26 8.1810 4055 46.70 86.71 4.78

Table 5.10: Execution time, frequency (frames/s) and bus load of WriteSOPS with dif-ferent STmin

fr/s diagnostic load/s [%] Lower limit [%] Upper limit [%]1 1 0.05 0.06167 9 8.75 10.75390 20 20.44 25.12336 18 17.61 21.64335 18 17.55 21.57347 19 18.18 22.35390 21 20.44 25.12336 18 17.61 21.64335 18 17.55 21.57336 18 17.61 21.64346 18 18.13 22.28392 21 20.54 25.24326 17 17.08 20.9916 1 0.84 1.03

Table 5.11: Analysis of WriteSOPS using CANAnalyzer and STmin=0

It can be seen in table 5.11 that the diagnostic loads are not evenly distributed. Anotherobservations is that the obtained average values of the frequency and the bus load intable 5.10 are quite accurate and it can be verified that the average bus load lies betweenthe allowed lower and upper limits.

5.2.4 ReadValues

No pre-recorded data is required for this application-layer service. As it generates a burstof single frames, Token Bucket is applied.

56

5.3 Maximum Threshold

This section presents the results from conducting the test described in section 4.6 regard-ing the maximum threshold.

Graph 5.10 is the result of executing ReadSOPS when the base load is around 90%. Theaverage diagnostic bus load per second exerted by ReadSOPS is around 10% (with nodelays), which means that the total bus load (i.e. diagnostic bus load + base load) shouldgo up to 100% in theory. The trace labelled Base load represents the measured base loadand the trace labelled Total bus load represents the measured total bus load exerted onthe CAN bus. It can be noted that the total bus load does not reach higher than around97%. When ReadSOPS is started there is a dip in the base load and the reason for this isthat frames are dropped as a consequence of exerting too much load on the network.

There are two outcomes that were not expected from the result; first, only frames fromthe on-board communication were dropped. Further inspection in the matter revealedthat the frames that are dropped are the ones generated by CANAlyzer. The softwaredrops the frames contained in its internal output buffer before they are even transmittedinto the CAN bus, with the error: “XL ERR QUEUE IS FULL”. Second, the expectedoutcome of increasing the base load was an increase of the execution time of the diagnosticservice. According to the CAN specification, the frames with the numerically lowest CANIDs have precedence for transmission on the bus. The frames generated by CANAlyzerto increase the base load had priority 0 whereas the diagnostic frames had priority 6. Thefact that the diagnostic frames would lose the arbitration more frequently is the reasonwhy increased execution times were expected. However, this was not observed in theexperiment and the explanation is the same; that CANAlyzer drops the frames once thetotal bus load reaches critical limits.

It can be observed in graph 5.10 that enough frames are dropped to allow the diagnosticframes to transmit. The base load is 90%, the average diagnostic load is 10% and themaximum total bus load is 97% and, as can be seen in the graph, the base load is loweredby approximately 3% in the duration of ReadSOPS. Another strange phenomenon isthat once ReadSOPS terminates, the base load goes up above the value that it shouldbe for just a short period of time. This happens because CANAlyzer flushes out theframes stored in its output buffer once the total bus load decreases when ReadSOPS hasfinished. The most important finding here is that the maximum allowed bus load on thenetwork is around 97%.

57

Figure 5.10: ReadSOPS: exceeding max threshold and dropped frames as consequence

5.4 Regulator

5.4.1 ISO-TP

The following graphs present the results from applying the ISO-TP algorithm with differ-ent values for maximum threshold. As can be seen in all of the graphs, the total bus loaddoes not exceed the prescribed maximum threshold when the regulator is activated. Itcan also be noted that the peculiar phenomenon described in section 5.3 does not occurthanks to the regulator.

ReadECUID generates such an insignificant bus load per second that regulation was notrequired. However, for readSOPS and writeSOPS the results are presented below

58

ReadSOPS

Table 5.12 summarises the results

Graph base load max threshold available load AVG diagnostic load STmin5.11 90 97 7 5.4 15.12 70 85 15 10.4 05.13 50 55 5 3.7 55.14 60 63 3 2.2 10

Table 5.12: ReadSOPS summarised results

Figure 5.11: ReadSOPS result graph 1

Figure 5.12: ReadSOPS result graph 2

59

Figure 5.13: ReadSOPS result graph 3

Figure 5.14: ReadSOPS result graph 4

Graph 5.11 illustrates that the bus load stays below the maximum threshold of 97%, thusavoiding any frames from being dropped.

The trace named Regulator in graph 5.12 represents the total bus load of ReadSOPSwith the regulator active. Reading out the values from table 5.12, the base load is at70% and the maximum threshold at 85%. ReadSOPS exerts a bus load of 10.4% andas there is enough bandwidth, no delays are added by the regulator. The trace namedFixed delay represents the fixed delay of 9ms that is added with the existing solution.This delay causes unnecessary waste of the network capacity and ReadSOPS takes muchlonger to terminate, as can be seen in the graph.

Graph 5.13 illustrates that the bus load conforms to specified limits with the regulatoractivated. The base load is 50% and the maximum threshold is at 55%. ReadSOPSgenerates an average bus load of 10.4% every second and in order to stay within allowedlimits the regulator adds on a delay of 5ms, which decreases the average bus load to3.7%. The trace named No regulation illustrates what happens in the absence of aregulator.

60

Graph 5.14 shows a similar scenario as graph 5.13, with the difference that the availablebandwidth is much less and the regulator has to choose a bigger delay.

The side effect of the regulating algorithm is that the execution times of the servicesincrease.

WriteSOPS

Table 5.14 summarises the results

Graph base load max threshold available load AVG diagnostic load STmin5.15 85 97 12 10 15.16 71.45 76.6 5.15 4.9 105.17 71.45 91.5 20.05 19.1 05.18 50 59 9 8.2 5

Table 5.13: WriteSOPS summarised results

Figure 5.15: WriteSOPS result graph 1

Graph 5.15 shows that the bus load is kept within the maximum threshold of 97% andthat no frames are dropped.

The trace named Regulator in graph 5.16 represents the total bus load with the regulatoractive. Reading out the values from table 5.14 the available bandwidth is only 5.15%and WriteSOPS generates an average bus load of 19.1% per second. Hence, the regulatorimposes a delay of 10ms to decrease the bus load exerted by WriteSOPS to 4.9%. Thetrace named No regulation shows the behaviour of the bus load when the regulator isinactive.

Graph 5.17 illustrates how wasteful of network bandwidth the fixed delay of 9ms can be.And finally, graph 5.18 shows a similar scenario as graph 5.16 but where a delay of 5msis required for the bus load to behave according to the defined constrictions.

61

Figure 5.16: WriteSOPS result graph 2

Figure 5.17: WriteSOPS result graph 3

5.4.2 Token Bucket

The token bucket algorithm is activated each time a single frame is sent. The diagnosticservice ReadValues generates a burst of single frame requests and responses i.e. withoutdata segmentation. ReadValues generates a bus load which is comparably small for graphsto be any useful. Table 5.14 illustrates how the number of tokens affect the executiontime of the service. Down at only 2 tokens, the execution time is 12.6s. The base loadwas 31.5% during the test runs.

62

Figure 5.18: WriteSOPS result graph 4

Number of tokens Execution times1033 1.44210 2.2135 4.7802 12.587

Table 5.14: Token bucket results

63

Chapter 6

Discussion

The research question that the thesis project aimed to answer was: “In a network systemwith two co-existing, distinct traffic flows, how can the network bandwidth be used to itsmaximum capacity while ensuring that the network is not overloaded and without imposingfixed delays in the network system?”. The answer was to introduce a bus load regulatorwhich ensures that network traffic conforms to the available bandwidth so that the riskof overloading the network is eradicated. In comparison to previous solutions where fixeddelays are imposed on the network, the regulator only introduces delays when necessaryand in accordance to the network bus capacity. From the results it can be seen thatfixed delays result in inefficient utilisation of the network. It can also be seen that whilethe network traffic conforms to specified limits, the bandwidth utilisation is optimisedso that network capacity is not wasted. Regarding whether the bandwidth is used to itsmaximum capacity; the DoCAN protocol supports only fixed values that can be assignedto the STmin parameter in the interval: 0x00 to 0x7F, which correspond to 0-127ms.The bandwidth could potentially be used to a greater maximum had the granularity ofdelays been finer. A finer granularity would effectively have meant that the small gapsbetween the bus load (when using the regulator) and the configured maximum thresholdwould become even smaller.

One prominent feature of the regulator is that it is adaptive and capable of being appliedto any product with a compatible communication network without imposing constrictionson the network configuration. This means that the regulator is suitable for products thathave the ability of being enhanced with further extensions and additional functional-ity, which typically contribute to higher network utilisation. Besides heavy commercialvehicles, examples of areas where the regulator can be applied include industry and ma-rine. Another feature of the regulator is that it can intercept and filter in-coming andout-going traffic and thus be used like a firewall to prevent certain data messages fromentering and/or leaving the network.

In order to use the regulator in a Scania vehicle, an RTC control unit must be availableand the OBD port has to be relocated from its current location to the RTC. Moreover,information about different diagnostic services and the loads they exert on the networkmust be administrated in order for the regulation algorithm to properly shape the networktraffic. The data gathered in the thesis project only covers some of the diagnostic services

64

available in the standard, which is not enough in practise. There are some services thatgenerate varying data loads depending on which ECU is addressed in the network. Theregulator could accommodate such services by decreasing the block size parameter andthus sending more flow control frames. If the bus load is about to exceed the availablebandwidth, the regulator can increase the minimum separation time parameter betweenthe consecutive frames.

The robustness of the regulator can be verified by the results obtained from the ex-periments conducted in the thesis. However, the traffic is only regulated on the yellowsegment of the network architecture. A more thorough solution would be to place theregulator in connection to the coordinator ECU that relays CAN frames between thedifferent segments.

6.1 Ethics, Social Aspects and Sustainability

One could argue that a regulator such as the one developed in this thesis will be of lessrelevance as more powerful and capable network solutions are developed with greaterbandwidth capacities. However, the tendency is that more powerful ECU solutions arebeing devised and used in the industry. More capable ECU systems consequently leadto more data signals being generated and increasingly higher loads being exerted on thenetwork. The tendency is also moving towards using more specialised diagnostic servicesas well as performing diagnostics continuously in the vehicle and to send the diagnosticdata to remote servers, putting further constraints on the bandwidth resources. However,the truth of the matter is that a regulator is not always necessary in all configurations. Forinstance, there can be configurations that require a relatively small amount of bandwidthin which case the regulator would be idle.

The main purpose of the regulator is to safeguard against network overload in any con-figuration. Besides increasingly complex network configurations, another possible causeof overload is specially crafted attacks that flood the network with data traffic with theintent of rendering the ECUs unresponsive; a so called Denial of Service (DoS) attack.DoS attacks can also interfere with on-board messages from adjacent ECUs so that theynever get to transmit on the network bus and thus impairing the real-time, on-boardcommunication. The regulator can help protect against unethical and malicious attackslike the one described and it is without doubt beneficial for society and for the safety ofcivilians.

65

Bibliography

[1] Canalyzer the tool for comprehensive ecu and network analysis.

[2] In-vehicle networking. https://www.nxp.com/files/microcontrollers/doc/

brochure/BRINVEHICLENET.pdf.

[3] J1939 introduction. https://www.kvaser.com/about-can/

higher-layer-protocols/j1939-introduction/.

[4] Par sundback, m.sc.m.e expert engineer, systems achitect diagnostics network anddiagnostic architecture. Interview with Par Sundback.

[5] Readme file for the controller area network protocol family (aka socketcan). https://www.kernel.org/doc/Documentation/networking/can.txt.

[6] Keyword protocol 2000 - part 3 - application layer. 2001.

[7] Road vehicles – diagnostics on controller area networks (can) – part 3: Implementa-tion of unified diagnostic services (uds on can). 2004.

[8] Worst case analysis - network calculus. https://www.net.in.tum.de/pub/

systemperformanz/ss2012/skript/networkcalculus.pdf, 2008.

[9] Road vehicles – diagnostic communication over controller area network (docan) –part 2: Transport protocol and network layer services. 2011.

[10] Road vehicles – unified diagnostic services (uds) – part 1: Specification and require-ments. 2013.

[11] Can protocol tutorial. https://www.kvaser.com/can-protocol-tutorial/, 2014.

[12] The evolution of automotive diagnostic technology. https://www.scribd.com/doc/306095200/Vector-Diagnostics-Seminar, 2014.

[13] Ahmed M AlAdwani, Amjad Gawanmeh, and Sebastien Nicolas. Traffic shapingand delay optimization in demand side management. In Computer Modelling andSimulation (UKSim), 2013 UKSim 15th International Conference on, pages 722–727.IEEE, 2013.

[14] R. Krishan B. Constantine. Traffic management benchmarking. https://tools.

ietf.org/html/rfc7640#section-1.1, 2015.

[15] CAN Bosch. Specification version 2.0. Published by Robert Bosch GmbH (September1991), 1991.

66

[16] Inc Cisco Systems. Quality of service networking. http://docwiki.cisco.com/

wiki/Quality_of_Service_Networking, 2012.

[17] Steve Corrigan. Controller area network physical layer requirements. Technicalreport, 2008.

[18] Robert I Davis, Alan Burns, Reinder J Bril, and Johan J Lukkien. Controller areanetwork (can) schedulability analysis: Refuted, revisited and revised. Real-TimeSystems, 35(3):239–272, 2007.

[19] Bruce Emaus. Beginner’s guide to can development. http://vector.com/portal/medien/cmc/application_notes/AN-AND-1-102_Beginners_Guide_to_CAN_

development.pdf/, 2008.

[20] Mohammad Farsi, Karl Ratcliff, and Manuel Barbosa. An overview of controllerarea network. Computing & Control Engineering Journal, 10(3):113–120, 1999.

[21] P. Fussey and M. Ormerod. On board diagnostics (obd), October 5 2006. US PatentApp. 10/545,513.

[22] M Kleine-Budde. Socketcan–the official can api of the linux kernel. In Proceedings ofthe 13th International CAN Conference (iCC’12), Hambach Castle, Germany CiA,pages 05–17, 2012.

[23] Wolfhard Lawrenz. Can system engineering. From theory to practical applications,New York, 1997.

[24] Jan Lindman. Technical product data, network communication specification.

[25] Christoph Marscholik and Peter Subke. Road Vehicles: Diagnostic Communication:Technology and Applications. University Science Press, 2009.

[26] Maximilian Perzinger. Accesspunkt for ombord diagnos. 2015.

[27] Gyorgy Pilaszy, Gyorgy Racz, and Peter Arato. Communication time estimation inhigh level synthesis. Periodica Polytechnica. Electrical Engineering and ComputerScience, 57(4):99, 2013.

[28] Laszlo Piroska. Diagnostic communication of vehicles. University Lecturehttp://www.bosch.hu/Presentation2008En/Presentation_Debrecen_En_2008_

03_27.pdf, 2008.

[29] Mehrnoush Rahmani, Ktawut Tappayuthpijarn, Benjamin Krebs, Eckehard Stein-bach, and Richard Bogenberger. Traffic shaping for resource-efficient in-vehicle com-munication. Industrial Informatics, IEEE Transactions on, 5(4):414–428, 2009.

[30] Truls Shanwell and Hakan Svensson. Remote diagnostics of heavy trucks throughtelematics. 2013.

[31] SVENSK STANDARD SS-ISO. Road vehicles – controller area network (can) - part2: High-speed medium access unit. 2011.

[32] SVENSK STANDARD SS-ISO. Road vehicles – controller area network (can) -part3: Low-speed, fault-tolerant, medium dependent interface. 2011.

67

[33] Peter Subke. Internationally standardized technology for the diagnostic communi-cation of external test equipment with vehicle ecus. In SAE Technical Paper. SAEInternational, 04 2014.

[34] Paul Vranjes, Marcel Romijn, and Alexander Levin. Connected diagnostics: Part 1issues driving safe connectivity. Technical Report SIG-2015120001, 2015.

[35] Marko Wolf, Andre Weimerskirch, and Christof Paar. Secure in-vehicle communica-tion. In Embedded Security in Cars, pages 95–109. Springer, 2006.

68

www.kth.se