remote diagnostics of heavy trucks through telematics694754/fulltext01.pdf · remote diagnostics of...

Remote Diagnostics of Heavy Trucksthrough Telematics

TRULS SHANWELLHAKAN SVENSSON

Master’s Degree ProjectStockholm, Sweden August 2013

Remote Diagnostics of Heavy Trucks throughTelematics

TRULS SHANWELLHÅKAN SVENSSON

Stockholm 2013

Master of Science Thesis MMK 2013:69 MDA 458KTH Industrial Engineering and Management

Machine DesignSE-100 44 STOCKHOLM

Master of Science Thesis MMK 2013:69 MDA458

Remote Diagnostics of Heavy Trucks throughTelematics

Truls Shanwell, Håkan SvenssonApproved Examiner Supervisor2013-12-18 Martin Törngren Lei Feng

Commissioner Contact personScania CV AB Jonas Biteus

AbstractVehicle diagnostics is getting more and more sophisticated as the num-ber and complexity of on-board computers grow. The use of computeraided diagnostics has become an integral part of repair and maintenance,but it is still almost exclusively used with the PC physically connectedto the vehicle or at least very close by a few meters.

Web based services in ”in-vehicle-infotainment”1 (IVI) has grown rapidlyover the last couple of years and as vehicle diagnostics belongs to IVI,it is natural for it to strive towards the web. This thesis has been car-ried out with the aim to investigate and demonstrate the possibility ofremote diagnostics, meaning vehicle diagnostics over the internet. Ithas been done with the perspective of real-time user interaction2. Thereport describes the diagnostic system as it is today, proposes changesneeded for the adaptation towards the internet, discusses performanceover mobile networks and guides the reader through the development ofa remote diagnostics application run over 3G.

This thesis shows that it is possible to run a diagnostic applicationover the internet without sacrificing functionality and still retaining agood user experience. The difficulties of remote diagnostics has shownnot to lie in performance, but in safety, security and managing a largefleet, which belongs to future work to solve.

1Solutions and applications for automobiles ranging from entertainment to navigation andmaintenance, as defined by Accenture [1].

2In this sense real-time addresses the users feeling of instant response.

Examensarbete MMK 2013:69 MDA 458

Fjärrdiagnostik av Tunga Lastbilar överTelematik

Truls Shanwell, Håkan Svensson

Godkänt Examinator Handledare2013-12-18 Martin Törngren Lei Feng

Uppdragsgivare KontaktpersonScania CV AB Jonas Biteus

SammanfattningFordonsdiagnostik blir mer och mer sofistikerad i takt med att anta-let och komplexiteten hos inbyggda fordonsdatorer växer. Datorstödddiagnos med hjälp av en PC som kör en diagnosapplikation är en nyc-kelfaktor inom reparation och underhåll.

Allt eftersom att utvecklingen inom web-baserade tjänster har vuxitunder senare år har även fordonstillverkare börjat undersöka vilka web-baserade tjänster som kan byggas in i deras fordon. Ett intresseområdeär fjärrdiagnostik, dvs diagnos-kommunikation över internet. Scania harnyligen lanserat en web-baserad tjänst för fordonsdiagnos, där använda-ren kan beställa en utläsning av felkoder på ett fordon av nyare modell,och sedan få resultatet presenterat i en webläsare. Dock så erbjuder dennuvarande tjänsten endast begränsad funktionalitet jämfört med vadsom är möjligt med diagnosapplikationen som används då ett fordontas in till en verkstad.

Den här rapporten presenterar en arkitektur som gör det möjligt attutföra samma typer av operationer över trådlöst WAN som idag endastgörs med diagnosverktyget anslutet till fordonet via usb-kabel eller lokalwifi. En stor del av detta arbete har inneburit att utveckla en plattformsom prototyp för att demonstrera systemet.

Acknowledgments

We would like to take the opportunity to thank our supervisor Jonas Biteus andthe department of YSPX at Scania CV AB for their continuous support duringthis master thesis. We want to thank our supervisor Lei Feng at KTH who hasbeen of great help to us, always making himself reachable even at short notice. Wewould also like to extend our thanks to our examiner Martin Törngren for his helpof making this thesis possible.

iii

List of Notations

3G Third Generation, page 18

4G Fourth Generation, page 18

ABS Anti Brake Lock System, page 4

AEBS Advanced Emergency Brake System, page 4

AWD All Wheel Drive System, page 7

CC Cruise Control, page 4

CSS Automatic Climate Control, page 7

CTL Computational Tree Logic, page 25

DTC Diagnostic Trouble Code, page 1

ECU Electronic Control Unit, page 6

EDGE Enhanced Data Rates for GSM Evolution, page 18

EMS Engine Management System, page 7

ESC Electronic Stability Control, page 4

GMS Gearbox Management System, page 7

GPS Global Positioning System, page 1

ICL Instrument Cluster, page 7

IV I In-Vehicle Infotainment, page 1

LTE Long Term Evolution, page 18

MIL Malfunction Indicator Light, page 9

OBD On-Board Diagnostics, page 1

OSI Open Systems Interconnection, page 10

v

ACKNOWLEDGMENTS

QoS Quality of Service, page 16

QoS Quality of Service, page 54

RRC Radio Resource Controller, page 18

RTT Round Trip Time, page 17

TCTL Timed Computational Tree Logic, page 25

V CI Vehicle Communication Interface, page 1

WWAN Wireless Wide Area Network, page 18

vi

List of Figures

1.1 Basic diagnostics setup, with wired connection and wireless respectively 2

2.1 Generic CAN bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Scania CAN bus topology . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Mapping of the diagnostics over CAN standard into the OSI model

(Permission for publication obtained from SIS Förlag AB, www.sis.se,08-555 523 10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Future system overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Property checking queries . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 beaglebone platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 beaglebone CAN bus cape . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 VCI software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 The architecture of SocketCAN . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Flow chart of the diagnostic API written in C . . . . . . . . . . . . . . . 415.2 CAN application input/output message format . . . . . . . . . . . . . . 425.3 VCI+ top level initialization . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 VCI+ data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.5 VCI+ diagnostic application architecture . . . . . . . . . . . . . . . . . 455.6 Proposed test script written in XML . . . . . . . . . . . . . . . . . . . . 475.7 Back-office server architecture . . . . . . . . . . . . . . . . . . . . . . . . 485.8 Sequence diagram of the VCI+ to back-office communication . . . . . . 505.9 Sequence diagram of the VCI+ to back-office communication . . . . . . 50

A.1 Graphical user interface of the VCI+ diagnostic application . . . . . . . 62

vii

Contents

Acknowledgments iii

List of Notations vi

List of Figures vii

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.5 Scope and Delimitation . . . . . . . . . . . . . . . . . . . . . 51.2.6 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Pre-study 72.1 Current System Architecture . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Controller Area Network (CAN) . . . . . . . . . . . . . . . . 72.1.2 On-Board Diagnostics . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Vehicle Communication Interface . . . . . . . . . . . . . . . . 92.1.4 Diagnostics Over CAN . . . . . . . . . . . . . . . . . . . . . . 102.1.5 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.6 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.7 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.8 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . 112.1.9 Diagnostic Application Layer . . . . . . . . . . . . . . . . . . 12

2.2 Vehicle diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Readouts of diagnostic trouble codes . . . . . . . . . . . . . . 122.2.2 Unit calibration . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 Unit configuration . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Firmware update . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.5 Workshop tests . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.6 Streaming sensor data . . . . . . . . . . . . . . . . . . . . . . 13

viii

2.3 SCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 SDP3 XCOM C-Dev . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 The New Diagnostic Application . . . . . . . . . . . . . . . . . . . . 15

2.7.1 The Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7.2 The Need of a New VCI . . . . . . . . . . . . . . . . . . . . . 162.7.3 VCI+ Functionality . . . . . . . . . . . . . . . . . . . . . . . 16

2.8 Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 Internet Connection in Depth . . . . . . . . . . . . . . . . . . . . . . 18

2.9.1 Mobile Internet Service Provider . . . . . . . . . . . . . . . . 182.9.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9.3 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.10 Transport Layer Protocols . . . . . . . . . . . . . . . . . . . . . . . . 212.10.1 Transmission Control Protocol (TCP) . . . . . . . . . . . . . 212.10.2 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . 212.10.3 On Transport Protocols . . . . . . . . . . . . . . . . . . . . . 21

2.11 Envisioning the Future System . . . . . . . . . . . . . . . . . . . . . 22

3 Further Areas of Research 253.1 Modeling the UDS Protocol . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 The UPPAAL Software . . . . . . . . . . . . . . . . . . . . . 253.1.2 Computational Tree Logic . . . . . . . . . . . . . . . . . . . . 253.1.3 Property Checking with UPPAAL . . . . . . . . . . . . . . . 263.1.4 UDS Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.5 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Static Analysis of C-Application . . . . . . . . . . . . . . . . . . . . 293.2.1 Clang Scan-Build . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 Splint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Design 334.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . . 344.2.2 SocketCan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.3 Programming languages . . . . . . . . . . . . . . . . . . . . . 37

5 Implementation 395.1 CAN Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.2 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.3 Unix Socket Interface (input/output) . . . . . . . . . . . . . . 405.1.4 Vehicle Input / Output . . . . . . . . . . . . . . . . . . . . . 42

5.2 VCI+ Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

ix

CONTENTS

5.2.1 Application Initialization . . . . . . . . . . . . . . . . . . . . 425.2.2 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.3 Diagnostics Application . . . . . . . . . . . . . . . . . . . . . 445.2.4 Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . 475.2.5 Communication Protocol . . . . . . . . . . . . . . . . . . . . 485.2.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Retrospect 536.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Bibliography 57

A Appendix A 61

B Appendix B 63

C Appendix C 73

x

Chapter 1

Introduction

Over the last two decades the vehicle industry has increased its focus towards de-veloping more intelligent systems. A growing number of embedded computers andsensors are integrated in vehicles, providing new features in safety, entertainment,luxury and more. One of the more recent trends within the automotive industryis vehicle internet connectivity and In-vehicle Infotainment (IVI). While the areaof vehicle mechanics is very mature, the IVI area is much less developed. It has alarge unexplored market and is very rapidly expanding [1]. An important part ofIVI is vehicle service and maintenance which is the area treated in this report.

1.1 Background

As new technologies develop the complexity of vehicles grow. New software andhardware are frequently introduced and can often be different between models, whyworkshop mechanics face increasing difficulties in troubleshooting and repairing ve-hicles.

For this and other reasons, repair and maintenance on heavy vehicles has becomedependent on computer aided diagnostics. A simple description of diagnostics is,the ability of obtaining faults that the truck has registered during operation, whichcome in the form of Diagnostic Trouble Codes (DTC) together with Freeze Framesof the system state at that moment. It also includes the ability to manipulate differ-ent properties of the truck e.g. changing the state of different actuators and readingsensor values to see that they react accordingly. An important part of diagnosticsis workshop tests, where the vehicle goes through a predefined set of operations onwhich its performance is evaluated. This is not the whole story of computer aideddiagnostics but it will suffice for now.

These tests are carried out by connecting a PC to a Vehicle Communication In-terface (VCI), which is a gateway or translator between the computer and the vehi-cle’s communication protocols. The VCI is plugged into an On-Board-Diagnostics

1

CHAPTER 1. INTRODUCTION

(OBD) port on the vehicle, which enables communication with its internal system.Through this connection it is possible to e.g. run diagnostics tests, calibrate com-ponents, read and interpret Diagnostic Trouble Codes and more.

In the traditional setup used today, the computer is either connected to the vehicleby wire, or through a wireless access point, see Figure 1.1. This means that thecomputer running the diagnostic application must be in a proximity of the vehicleunder diagnosis, which imposes significant restrictions on the system. Diagnosticsof a faulty vehicle is only possible if a repairman comes out to the site, or if thevehicle is in a workshop.

Figure 1.1. Basic diagnostics setup, with wired connection and wireless respectively

It would be a considerable benefit to enable this type of diagnostics over a longer,remote distance. Making it possible to connect to a vehicle and run diagnostic testsand other diagnostic applications at any time, or more importantly, regardless of thevehicle’s physical location. Picture a truck running on a highway when the driverexperiences a malfunction. If remote diagnostics was possible the truck could bediagnosed at its current location, without waiting for a repairman to come to thesite or needing to drive or get towed to a workshop.

Scania wants to improve its vehicle diagnostics system and provide a whole rangeof new diagnostics features. The ideal system would analyze all vehicles and collecttheir run-time data. Based on this information it would predict and recommendadequate maintenance and service intervals. It would find sources of failure andadjust them with calibration and software updates without requiring the driversattention, in best case before the driver even noticed something was wrong. Duringroadside failures it would be possible to remotely run diagnostic tests, and basedon the result the system would be able to determine the source of failure and rec-ommend proper repair actions. It would further compile a list of spare parts andrepair instructions for the nearest workshop.

2

1.2. PURPOSE AND DEFINITIONS

Apart from road vehicles, Scania also manufactures GENset units (electric gen-erators powered by a combustion engine) that often operate in very remote envi-ronments, with limited network infrastructure and connectivity. As these GENsetsare stationed in very remote locations, maintenance and repair becomes very expen-sive. Repairmen needs to travel long distances, multiple times, both to investigateand to bring proper tools and spare parts. This application would benefit greatlyfrom remote diagnostics and monitoring, which would enable live monitoring ofstate of health and performance and greatly ease repair and maintenance.

In the logistic business sector, failing vehicles mean large costs for owners. It istherefore essential for a company like Scania to provide efficient repair and ser-vice methods. Although reducing the cost of repair and spare parts is important,costs related to downtime and penalty fees for late goods can often be even moreimportant[2].

Political legislation also drive manufacturers to increased awareness and effective-ness, both on requirements for environment and traffic safety. A standstill due toa failing truck is a good example of a dangerous situation that should always beavoided[3].

1.2 Purpose and Definitions

1.2.1 Sustainability

Scania, as any other vehicle manufacturer puts a significant effort into reducingthe environmental footprint of their products, and vehicle maintenance techniquesare an integral component of this improvement process[4]. Optimal fuel efficiencyis an important part to reduce costs for Scania’s customers, and in order to en-sure maximum fuel efficiency, all major systems in the vehicle must function asintended. Stricter emission legislation requires more advanced and sophisticatedsystems to deal with pollution treatment. For heavy trucks, advanced systems havebeen developed to reduce emissions in order to meet the Euro 6 standard, and inthe distributed systems that controls the power-train and its accessories, correctfunctionality is usually dependent not only on one subsystem but on several.

Being able to perform remote diagnostics not only opens the possibility for trou-bleshooting on an already confirmed malfunction, but also for remote data miningand back office analysis of vehicle run-time data. With an efficient analysis appli-cation, a vehicle could be repaired before suffering a major breakdown. Also, thedata of each unit can be collected and used for fleet management in a diagnosticpurpose, making it possible to single out individuals with abnormal run-time data.

Being able to detect anomalies in an early stage to prevent a fault that affects fuel

3


consumption will not only save fuel, but also reduce the number of extensive repairscarried out at workshops, which will lead to reduced amount of changed spare partsand other consumption parts usually associated with a workshop repair, such as oilsand other fluids.

1.2.2 Safety

Reduced emissions is only one factor that drives the evolution towards larger andmore complex systems. Safety features of modern vehicles also depends more andmore on distributed systems and software to function properly. Today, cars aswell as trucks and buses rely on a number of distributed safety systems such asairbag systems, Electronic Stability Control(ESC), Anti Brake Lock System (ABS),and newer features such as Advanced Emergency Braking Systems (AEBS). Also,a number of other features such as Cruise Control (CC) and electronic park breakare connected with safety, since a malfunction in this type of system can be directlyhazardous.

Faults subject to electrical or software failures are quite often intermittent, meaningthat the user of the vehicle experiences a fault that occurs only on particular occa-sions, usually under certain conditions that can be hard to identify or reproduce,or just appear plain randomly. This can make troubleshooting difficult, especiallyin cases where the symptom cannot be reproduced at the time vehicle is at theworkshop. Under these circumstances, where no or unsatisfactory information canbe collected from DTCs and other error logs, the workshop might have to take aguess of what part might be cause of the fault and replace it without knowing if thevehicle is ok. Or simply send it out to the customer again for an attempt to col-lect more information about the error conditions. By realizing remote diagnostics,the workshop would be able to connect to the vehicle as soon as the costumer areexperiencing problems, to run a diagnostic session when the symptoms are present.

1.2.3 Purpose

The purpose of this thesis is to investigate and demonstrate ways of running thesame diagnostic application that are run locally in workshops today, over a remotedistance. The remote connectivity will be obtained through mobile services with3G as reference. This thesis will also define limitations of this service, propose asystem architecture and create a prototype to demonstrate this functionality.

1.2.4 Goals

The following goals have been set for this project:

• A remote diagnostic test should provide the same result as if it was connectedby wire as the setup is today.

4

1.2. PURPOSE AND DEFINITIONS

• The results should bring clarity to the possibilities and limitations of remotediagnostics.

• The results should bring understanding to critical factors and bottlenecks inremote diagnostics.

• The solution should be fully compatible with all Scania vehicles.• User interaction with the vehicle should give the user a perception of real-time

i.e. fast response time.• Minimize application specific data on the vehicle diagnostic device i.e. aim

for a thin client application.

1.2.5 Scope and Delimitation

The following conditions was agreed on during the initial weeks of the project.

• No Scania specific hardware was to be used, which means that new hard-ware was to be selected and used for the development of the new diagnosticsapplication. The reason for this decision was that this would give more in-dependence and flexibility from current Scania applications. There were alsoreasons to believe that it would speed up the development process because itwould not be dependent on adequate collaboration with other departments.

• It was decided that the diagnostic application shall communicate with thevehicle through the OBD port and not by any other means.

• None of the available code for the current diagnostic application were foundsuited to be used on the new platform. It was agreed that it came with toohigh complexity and too much work to decide which parts was actually usefulto the implementation.

• The research will only treat the connection with one vehicle at a time.• Some diagnostic operations require a higher level of authentication given by

a USB-key, these functions will be disregarded in the application and thesolution will not regard the integration of this authentication.

• Demonstrating new functionality is of highest priority. All other aspects willhave lower priority in the prototype and will be treated if the time allows forit.

• The remote connectivity will be displayed with a 3G connection, hence remotewill be regarded as all geographical positions with an available 3G connection.

• With internet communication, security is a highly relevant factor that needsto be thoroughly investigated by itself, however security issues will not beaddressed in this thesis.

• The matter of safety and whether it is appropriate to run these diagnostictests when the truck is outside the test operators line of sight, and that thevehicle may be situated in dangerous environments will not be regarded.

5


The prototype that is one of the aims of this thesis should consist of an embed-ded platform that can be connected to the OBD port of the vehicle. It shouldpreferably be small and lightweight, and should be able to run a client applicationcommunicating over an internet WWAN connection.

1.2.6 Method

Very few requirements were known at the start of the project, the basis of theproject is better described as a set of ideas. Therefore it took some time to clarifywhat was really wanted and to what extent it was feasible to achieve. The projectstarted with an extensive research on solutions to this problem and by delving intothe current system used at Scania. After the initial research, the development pro-cess took the shape of an iterative methodology although no textbook procedurewas applied. Weekly meetings with the supervisor was used as checkpoints and thehalf-time presentation as an important milestone. Swiftly changing requirementshampered long term planning and it was found to be best to stick to an iterativemethod with short development cycles. Another reason why many formal proce-dures were omitted was the small group size and that both authors were deeplyinvolved with each others work. The question of what was feasible to achieve tookvery long to answer, why design and implementation often was done concurrently.

A first prototype was created to test key functionality of the application, but itwas completely remade during the following iteration. Every new feature was ver-ified in three steps, first the hardware was connected to another computer playingthe role of a truck. Next it was tested on a rig, a collection of Electronic ControlUnits (ECU) combined to simulate certain properties of a vehicle. The final verifi-cations was done on full scale Scania trucks. Features were tested on step one andtwo very frequently, but were only subject to step three if the feature was assessedas properly working.

The work effort has been divided between the two authors during the course ofthe project. As for the implementation part, Håkan has implemented a low levelCAN API, while Truls has been developing the VCI+ application and the clientand server communication.

The report has been written in a common effort, except for chapter 3 where theauthors describes their individual research topics separately; static analysis of thesource code for the low level CAN API by Håkan, and modeling of the diagnosticstandard by Truls.

6

Chapter 2

Pre-study

2.1 Current System Architecture

The diagnostic system contains several parts, from the diagnostic user applicationto the internal workings of the truck itself. This section has the aim to explain theseparts and how they fit together to form the current system. Every Scania truck usesa Controller Area Network (CAN) for the majority of its internal communication,and it is through that medium that diagnostic requests are sent into the truck. Letus therefore start by briefly explaining a general CAN network.

2.1.1 Controller Area Network (CAN)

Controller Area Network (CAN) was developed by BOSCH and is a serial commu-nications protocol over a bus architecture, it uses message broadcast and is multi-mastered. CAN is created for broadcast of short messages that can be read by allconnected nodes simultaneously, which replaces point to point communication[5].CAN efficiently supports distributed real-time control, with a very high level ofsecurity[6]. [5] is a good introduction to CAN provided by Texas instruments. Fig-ure 2.1 shows a simple example of a CAN topology. The CAN bus consists of twowires, CAN-High and CAN-Low and is terminated by 120ohm resistors.

The CAN bus layout in Scania vehicles is shown in Figure 2.2. Scania vehicleshave three main CAN buses, red, yellow and green, which are interconnected by acoordinator gateway.

The red bus holds ECUs that manage time critical applications with hard real-time constraints and is the highest priority bus. For example the ECUs on thisbus controls the power-train e.g. the Engine Management System (EMS) and theGearbox Management System (GMS).

Applications with slightly lower real-time requirements are connected to the yellowbus. You will find the instrument cluster (ICL) and the All Wheel Drive System

7

CHAPTER 2. PRE-STUDY

Figure 2.1. Generic CAN bus

Figure 2.2. Scania CAN bus topology

(AWD) on this bus.

8

2.1. CURRENT SYSTEM ARCHITECTURE

ECUs that manage applications with only soft real-time requirements reside onthe green CAN bus, to which Automatic Climate Control (CSS) and the AuxiliaryHeater System belongs.

Messages that travel in-between buses must go through the coordinator. The mes-sage priority will then be decided by their origin i.e. messages from the red bus willbe handled before messages from the yellow and green bus.

It is important to note that the diagnostic bus is connected to the green bus, whichgives diagnostic requests the lowest priority. This bus has an external port calledthe On-Board Diagnostics (OBD) port for connecting external diagnostics tools.

2.1.2 On-Board Diagnostics

The OBD port is a way for external hardware to communicate with the truck’sinternal system, in this case the CAN bus. Generally, OBD refers to a vehicle’sability to make self diagnosis and present the errors found to a user of a diagnostictool, often a workshop technician[7].

The first OBD system appeared with the advent of Electronic Control Units (ECUs)in vehicles and early systems usually featured only a simple Malfunction IndicatorLight (MIL). During the past twenty years, OBD has evolved into a much higherlevel of functionality allowing more advanced diagnostics with a much greater detail.

OBD functionality is driven by legislation. These undergo constant change, andare dependent on geographical location e.g. the European Union names the stan-dard EOBD and in America the corresponding standard is OBD-II[8]. OBD is builtupon several standards from SAE and ISO, which covers everything from physicalup to application layer requirements[7].

It is common for modern vehicles to display OBD warning messages to the driveron a display if a malfunction occurs.

2.1.3 Vehicle Communication Interface

A VCI is a tool with the purpose of connecting an external computer to the vehiclethrough its OBD port, thus acting as gateway towards the internal communicationbus(es). In today’s diagnostics application, Scania uses two different versions of VCI.

The older - VCI2 - connects a computer to an OBD port through a wired con-nection over USB. One objective of VCI2 is to translate messages from a format thecomputer can use to the vehicles communication format, which it does by emulatingCAN over USB. But it also has the role of acting as a CAN node. This means thatit manages the data link layer and physical layer towards the CAN bus, specified in

9


ISO11898.

A newer generation of VCI, VCI3, has the exact same functionality as VCI2. Butinstead of providing a wired interface over USB, it is equipped with a WiFi accesspoint for short distance wireless communication, as shown in Figure 1.1.

2.1.4 Diagnostics Over CAN

So far the communication system of the truck as well as the means of connecting acomputer to that system has been discussed. Before moving on to describing howthe current diagnostics application has been implemented, let us first go throughthe standardized way of running diagnostic commands over CAN.

The Unified Diagnostic Services (UDS) protocol is a common set of services forvehicles using CAN, specified in the ISO 15765 standard. The standard is dividedinto four parts, each of which specifies the protocol according to the different layersdefined in the Open Systems Interconnection (OSI) model, as can be seen in Fig-ure 2.3. The diagnostic protocol specifies certain timing windows for which different

Figure 2.3. Mapping of the diagnostics over CAN standard into the OSI model(Permission for publication obtained from SIS Förlag AB, www.sis.se, 08-555 523 10)

diagnostic messages are expected to arrive within, the format of the diagnostic mes-sages, sequences and much more. These are defined in the applicable OSI layersaccording to the figure.

2.1.5 Physical Layer

Just as the title implies, the physical layer defines the physical properties includingphysical shape of connectors, electrical properties of the bus and the nodes connectedto it, topology and much more. This is manufacturer dependent.

10

2.1. CURRENT SYSTEM ARCHITECTURE

2.1.6 Data Link Layer

The second lowest layer is defined by the ISO 11898 standard for high speed CANcommunication (up to 1Mbit/s). It states the physical requirements on the CANbus, such as resistance, capacitance and voltage levels, to ensure that the perfor-mance of the bus is good enough to handle bit-timing related properties.

2.1.7 Network Layer

Most timing requirements are specified in the Network layer, and often features aperformance requirement and a timeout value. Performance requirements are thegeneral requirements, but for certain circumstances with high bus load, the time-out values that are higher, allows the diagnostic functions to operate even in thisconditions. Some timing parameters does not only specify an upper boundary formaximum time in which the message is expected to arrive but also a lower bound-ary, i.e. the minimum time before a message can be sent. If the message does notarrive within the specified time window, the communication fails.

One example is the “minimum separation time” (STmin) parameter, which is sentin flow control frames. These frames are used for sending messages that have to befragmented into several CAN frames. The STmin parameter states the time thathas to pass between each of these individual frames, and allows the receiver to exe-cute other tasks with higher priority before receiving consecutive frames. The flowcontrol frame also contains other information, such as when the next flow controlcan be expected, and if it is clear to start sending consecutive frames, or if thesender has to wait for a new flow control.

Basic operations such as reading DTCs and freeze frames require the diagnosticinterface to be able to receive segmented messages. In a similar manner, the receiv-ing ECU should be able to receive segmented messages.

The example above describes what features typically are described on the networklayer - the composition or layout of individual frames and the timing requirements.

2.1.8 Application Layer

The application layer defines mainly sequences of messages and the mapping ofthem into certain diagnostic services available in different diagnostic sessions bycombining sequences and application timing parameters. Every diagnostic operationhave to be initiated by the opening of a diagnostic session. There exists differenttypes of sessions, each with a different level of privileges to carry out certain typesof operations. The session with the lowest level of privileges is called standardsession. This section is very restricted in terms of what actions the user is allowedto perform. For instance, the user cannot manipulate any configuration in anyECU, or perform operations to control any actuator on the vehicle. The number of

11


sessions are manufacturer specific, and can be changed at any point. After openinga diagnostic session, a timer is started and if there is no other message sent withina specific time frame, the session times out and has to be opened again to be ableto continue. The different diagnostic services available on the different sessions canbe specified either by the application layer or the diagnostic application.

2.1.9 Diagnostic Application Layer

The diagnostic application level describes features implemented by the manufac-turer. This layer is characterized by workshop tests and other services related tomanufacturer specific components or procedures on the vehicle such as settings,calibration, etc.

2.2 Vehicle diagnostics

The following section describes the different types of operations that can be under-taken with modern vehicle diagnostics.

2.2.1 Readouts of diagnostic trouble codes

This is the most fundamental operations that can be done with a diagnostic tool.DTCs concerning emission systems are also regulated by legislations, imposing man-ufactures to incorporate this functionality. DTCs are set in an ECU when certainmeasured sensor values are breaking their corresponding upper or lower referencethresholds[9]. Along with a DTC is also follows a so called freeze frame, which areassociated values of sensor data that was measured at the time when the DTC wastriggered. The freeze frames could hold important information in order to pinpointthe cause of failure.

2.2.2 Unit calibration

Some electronic units require calibration after they have been replaced. One exam-ple of such a unit is the steering wheel module that has to calibrate the steeringwheel sensor after replacement.

2.2.3 Unit configuration

Some electronic control units common for different type of models need to be con-figured according to the specific features of the model to which it is fitted. Sametype of ECUs can be fitted on vehicle models with slightly different hardware spec-ifications, and for the ECU to make correct assumptions and calculations, differentconfiguration parameters need to be set.

12

2.3. SCOMM

2.2.4 Firmware update

Even though rigorous tests are a part of the development process for all vehiclemanufacturers, bugs and unforeseen conditions still causes faulty behavior to appearafter a product has entered the market. Firmware updating makes it possible tocorrect such errors without replacing the electronic unit.

2.2.5 Workshop tests

Workshop tests are manufacturer specific tests designed to check the operation ofcertain components in the vehicle. The duration of a workshop test can span froma single second up to several minutes, from just an activation of a single componentto controlling several of the vehicle’s main components such as the engine andgearbox. During this sequence, the vehicle receives instructions from the diagnostictool. Typically, the tool monitors sensor data during the test, and report the resultof the test if it completes, or abort the test if something fails. Advanced workshoptests are carefully crafted and engineered by a dedicated department at Scania,followed by rigorous testing. The ECUs in the vehicle should have built in protectionmechanisms so that the tool cannot manipulate the vehicle in a way that could behazardous (like putting the vehicle in gear when the engine is running), but stillsafety need to be taken into highest regard during the design of these tests.

2.2.6 Streaming sensor data

Another feature in diagnostic applications allows the user to monitor sensor datain real time. Different types of sensor data can be seen simultaneously on the samescreen, something that experienced diagnostic mechanics can make use of to discoveranomalies.

2.3 SCOMM

From this point, the parts of the current system that will be described lies on acomputer running the diagnostic application, which is connected to a VCI. Startingwith the Scania Communication application (SCOMM), which is an API used byall higher level applications. SCOMM contains all functionality for the diagnosticcommunication and handles ECU specific methods, communication according to thediagnostic UDS protocol described in the preceding section. It decodes and presentsdata and DTCs in readable form, handles authorization for different diagnosticsessions, logging and more. SCOMM is the underlying layer in the current systemarchitecture that receives requests from the diagnostic user application, forwardsthem in correct format according to the standard via USB bus to the VCI, andsubsequently receives replies from the vehicle and decodes it into human readableinformation before forwarding it back to the user application[10].

13


2.4 SDP3 XCOM C-Dev

SDP3, XCOM and C-Dev are diagnostic user applications developed by Scania. Themain application used in Scania workshops is SDP3, which includes an extensiveGUI and predefined operations towards the vehicle. XCOM and C-dev are createdfor developers and provide greater detail and freedom to manipulate the vehicle, butare less user friendly. All three applications utilizes SCOMM to get model specificinformation about the connected vehicle.

2.5 Summary

Lets summarize the current diagnostic system with two examples.

A repairman is performing computer aided diagnostics on a malfunctioning truck ina workshop. He uses SDP3 to specify a diagnostic command. The command goesthrough SCOMM where it is translated to a set of diagnostic instructions equiva-lent to the SDP3 command, but written according to the ISO15765 specification.SCOMM includes several layers of functionality and performs authentication andretreives vehicle specific information from databases. Finally the set of diagnosticcommands are sent to the VCI, which translates them and sends them on the vehi-cle’s CAN bus. The message travels to its destination ECU(s) and the reply goesthe same way back but in the opposite direction.

The same repairman executes a workshop test from SDP3. This test requires sev-eral steps of manipulation and readouts from the vehicle and after each send/receiveloop, the program must decide the next action based on the response. The com-munication path looks the same as in the previous example, but the intent of thisexample is to clarify that each decision for next instruction is decided in SDP3,meaning that for every cycle in the workshop test the data must travel through alllayers of the system.

2.6 Related Work

A similar system of that discussed in this thesis was presented in[11]. The authorspropose a communication protocol for relaying CAN frames over internet. Themethod is suggesting a capsulation of CAN messages into data-grams with a threebyte header, relaying them on to the internet. The authors suggests that diagnosticservices such as diagnostic read-out and CAN monitoring applications can actuallybe performed over internet, based on tests they have made. However, these testsdoes not address the problems that arises in cases when the connection is poor andlatency is high. If the diagnostic application would depend on access to low latency3G/4G, time and place would be a deciding factor about if it would be possible torun the diagnosis or not. In particular, commands that requires sending and re-

14

2.7. THE NEW DIAGNOSTIC APPLICATION

ceiving of consecutive frames would most likely be failing due to the short timeoutsbetween each frame, as would manufacturer designed test sequences where activa-tion and testing of physical actuators and sensors depends on immediate response.This thesis aims to propose a system with full functionality, at the same time notdependent on the reliability of the speed and latency of the communication betweenthe database and user application in one end, and the vehicle in the other. Conse-quently, another approach needs to be taken.

An implementation of a similar system was carried out at Scania in 2008, usingan ECU that today is fitted on most Scania vehicles called C200[10]. It was basedon a legacy system for remote diagnostics called Step. The purpose of the thesiswas to suggest and implement a system with similar functionality as Step, but withdatabases residing on the back-office server instead of on the vehicle. The systemswere not aimed at implementing full diagnostic functionality, such as workshop test-ing. The round trip time from that a request has been made from a user until theanswer arrives (which is an important aspect in this work) is not stated. Currently,Scania are using a system that resembles the suggested one, called Scania RemoteDiagnostics, a web based application that communicates with the vehicle throughthe C200. The diagnostic interaction are limited to readouts of DTCs and associ-ated freeze frames, and the response time for a diagnostic request for this system istypically above 5 minutes.

Other studies such as [12] and [13] are addressing software downloading to vehi-cle ECUs from a safety and performance perspective respectively. There are manypapers that discloses vehicles connected to WWAN, but we have not been able tofind other papers that discuss real-time remote diagnostics in the same context asthis thesis.

2.7 The New Diagnostic Application

The main goal of this thesis is to study and realize how to keep full SDP3 function-ality when running a diagnostics application over remote distance. This section willtreat some of the difficulties that arise and aspects to consider when creating thenew system.

2.7.1 The Internet

The ability of connecting to a remote vehicle is today limited to the use of a thirdparty Internet Service Provider (ISP). This implies giving up the control of thevehicle-to-operator communication to a third party, which in turn removes the pos-sibility to guarantee the real-time properties that are needed in the diagnostic ap-plication. Grigorik [14] writes:

15


“The architecture of our IP networks is based on a best effort deliverymodel, which makes no guarantees about end-to-end performance”

This makes it impossible to run the application as it is designed today, by onlyrouting the communication over the internet. Instead there is need for significantchanges in the design.

2.7.2 The Need of a New VCI

First of all the VCI needs to be connected to the internet by a mobile networkprovider. Preferably it should be able to switch between several network services,much like a cellular phone for it to be able to provide the best connectivity in thecurrent location. These features cannot be provided by the VCI2 and -3 designsused today, for they have a limited predefined set of functions and connectors. Itis therefore necessary to create a new VCI+ with extended functionality. But whatfunctionality does the VCI+ need?

The problem could be solved by creating a very extensive VCI+ and put the entirediagnostic application including databases and logic on it. SCOMM is however de-pendent on the .NET framework and has inherited its portability issues. However,the main reason why this is not appropriate is the continuous update of diagnosticfunctions. Hence the need for fast and easy update of diagnostic databases. Puttingthese databases on the VCI+ would demand ongoing updates on each VCI+ on ev-ery vehicle, whenever a diagnostic definition is revised. There are several reasonswhy this should be avoided, including large unnecessary data transmissions, dataduplication and more.

Instead, a new design requires that the old systems functionality is split up intotwo parts, one put on the VCI+ and the other on the server, with the internetjoining them together.

2.7.3 VCI+ Functionality

A couple of features were identified to be necessary on the VCI+. Similar to VCI2and -3, the basic CAN communication physical layer ISO11898 is required. Thestandard for diagnostic communication ISO15765 with its real-time requirementsmust be implemented.

Another needed feature regards the ability of running functional tests as in SDP3.The old method of running diagnostic tests requires direct communication betweenthe vehicle and SDP3 in every request-response cycle. The timing requirements ofthe diagnostic tests must still be fulfilled, but the accuracy of them deteriorate overthe internet, why QoS cannot be guaranteed and the method becomes unsuitable.The consequence is that the entire test instruction must lie on the VCI+, logic anddecision tree included.

16

2.8. RESPONSE TIME

Let us list the functions that are needed so far on the VCI+ before moving on:

• Internet connectivity through mobile services• CAN data link layer as specified in ISO11898• Diagnostics on Controller Area Networks as specified in ISO15765• A new solution enabling diagnostic tests to be run despite timing uncertainties

of the setup

In addition:

• Logging of diagnostic traffic• Live monitoring of a parameter. This means a subscribing function where a

parameter readout is specified and the VCI+ creates a high speed periodicalrequest. The result must then reach the operator as fast as possible

• Auxiliary functions for facilitating the above functionality

2.8 Response Time

Keeping a feeling of user real-time in the application is a main target of this thesis.But what does people really perceive as an instant response?

According to [15] there are three important upper limits on user perception whenit comes to application performance:

• 0.1 second: The user feels that the system is reacting instantaneously• 1.0 second: The user will notice the delay but her flow of thought stays unin-

terrupted. She begins to lose the feeling of operating directly on the data• 10 seconds: About the limit for keeping the user’s attention focused on the

dialogue. Longer delays, will make the user want to perform other tasks whilewaiting for the computer to finish.

Note:

• For delays between 2-10 seconds it is good to provide some feedback indicatingwhen the process is expected to be done, at least by using a “busy” indicationor something that suggests that the computer is still operating on the data

• When the delay exceeds 10 seconds, it is good practice to show the progressas percentage done in a progress bar [16].

The application performance will be evaluated by investigating the round-trip-time(RTT) of a single, simple, UDS-command. This means, measuring the elapsed timefrom the point where the operator sends the diagnostic request, until the result isdisplayed on the screen. A reasonable goal according to the above limits for humanperception is 1 second RTT.

17


2.9 Internet Connection in Depth

In the following we will look into the network connection while keeping the perspec-tive of user real-time. Grigorik [14] uses two parameters when studying performancein this aspect:

• Latency: The time from the source sending a packet to the destination receiv-ing it.

• Bandwidth: Maximum throughput of a logical or physical communicationpath.

This section will omit deeper reasoning about bandwidth. The diagnostic applica-tion uses very small messages and this significantly reduces its importance. It mightbe of importance during transfer of larger diagnostic tests or logs, but such reviewis outside the scope of this thesis. Instead it will focus on latency.

2.9.1 Mobile Internet Service Provider

A vehicle stranded in a remote location will neither have access to Ethernet nora WiFi connection. It is solely dependent on a WWAN internet connection e.g.EDGE, 3G, 4G. There is a significant difference in network performance amongthese different stages in the evolution of mobile networks. The available connectionwill of course affect the real-time user experience.

A 3G connection will be used as a reference in further discussions of mobile net-works. The general building blocks of the different networks are very similar and agood reason to look closer on 3G is its vast geographical coverage and reasonableperformance. Ericsson predicts that 85% of the worlds population will have 3Gaccess by 2017[17].

3G is a very broad term. According to the original definition, a 3G network needonly provide bandwidth peak rates at 200 Kbit/s. But the recent LTE can providedown-link data rates as high as 300 Mbit/s while still residing under the term 3G(usually referred to as 3.9G, for it to be the last step before 4G) [14]. The evolutionhas had high impact on latency as well, reducing it significantly during every paststage of mobile technology [18].

It is not possible to affect the inner workings of the 3G network provider, one mustaccept the prevailing conditions or simply find a better service provider. However,it is still important to understand how it works, to be able to create applicationsthat maximizes the performance of the services available.

2.9.2 Latency

The following section includes several extracts from, and is mainly based on infor-mation from [14], which is recommended for the reader interested in the topic.

18

2.9. INTERNET CONNECTION IN DEPTH

Ethernet connected devices have a direct physical connection to the internet whichis why they are always connected or “always-on” 1. WiFi uses radio and lacks thisimmediate connection, it does instead emulate “always-on” with the aid of differentmethods making the performance impairment unnoticeable.

Radio communication requires a lot of power and the power in mobile devices arevery limited. In fact, on an average smart mobile phone, the power consumptionof the radio is only exceeded by the display when it is active. For a mobile deviceto have “always-on” properties, it must always have an active radio. This woulddramatically decrease the battery lifetime, why it is unwanted. Consequently, thereis a tradeoff between network efficiency and power consumption (battery life).

Mobile radio towers simultaneously serves significant more clients than a WiFirouter. The shared resources are limited and connected devices are expensive, whichis another reason against an ”always-on” policy.

Mobile networks use something called a Radio Resource Controller (RRC) whichschedules all the traffic on the network. If a mobile device wants to send data itmust first ask the RRC for resources and wait until the RRC has assigned a channelfor it. If there is incoming data on the network, the RRC will tell the device to startlisten for an incoming message, hence no data is received or transmitted before thishandshake.

A device has different radio states, each corresponding to different power con-sumptions and transmission capabilities. The radio state defines how the deviceis connected to the network and is decided by the RRC. Generally there are threetypes of states and even though details differ between network versions, this simpledescription will suffice:

• Idle: Lowest power state - the device listens only to control traffic and has nonetwork resources.

• Connected: High power state - the network resources are assigned to thedevice and receive and transmit operations are possible.

• Dormant: Intermediate state - does not exist for all versions. Network capa-bilities vary, but the time Dormant to Connected is always shorter than Idleto Connected.

A device that has not been engaging in network activity for some time will be in theidle state. It must always ask the RRC to enter the connected state before it maysend or receive any data. This negotiation may include several messages between

1The device in use is permanently connected to the internet and is ready to instantaneouslyreact to user input or an incoming data packet [14]

19


the device and radio tower and represents a major part of the network latency, es-pecially for the older 3G versions and below.

A timer then decides when to go to the dormant state and further back into idle.The timer is reset by network activity and the device may return to connected fromdormant if new network activity occurs.

There are also other latencies in the mobile communications network. Withoutgoing into detail, the main sources of network latency can be summarized to:

• Control-plane latency: as discussed earlier, the RRC negotiation contributesto the overall network latency by up to 100 ms for LTE but may extend toseveral seconds for early versions of 3G.

• User-plane one way latency: the time starting when a device begins to trans-mit a message and ends when the radio tower has received the full message.Relatively short addition of a few milliseconds.

• Backbone and Core network latency: the total latency that accumulatesthrough the mobile service providers logic and infrastructure e.g. client ac-count management and protection. This is entirely dependent on the networkprovider.

• The message reaches the Internet

There are also other delays of more random nature that may or may not add to theoverall latency depending on circumstance. Examples of these are: radio conditions,packet loss, user density, mobility pattern (changing radio tower) and the offeredtraffic [19].

2.9.3 Countermeasures

What can be done to reduce latency? It is important that the VCI+ has the pos-sibility to connect to a range of different generations of networks. One reason isgeographical coverage. But the real-time experience is highly dependent on themobile network performance, why it is always in interest to strive towards the bestand newest connection available. This implies switching hardware when new radiodevices are available.

Control-plane latency is a one time cost during data transfer because it is onlyneeded during communication initialization. Once the device is in connected, it willremain there until timeout. The VCI+ will be powered by the vehicles battery, whyit does not hold the same power limitations as regular mobile devices. For shortestresponse time, the devices should be held in a connected state during the entirediagnostic session. This can be done simply by performing periodic radio networkactivity preventing a timeout.

20

2.10. TRANSPORT LAYER PROTOCOLS

2.10 Transport Layer Protocols

The network performance of the internet service provider is a key factor when itcomes to latency. But there is still the choice of transport protocol for the applica-tion, this choice may also affect latency and may work better or worse in combinationwith the available network.

There are two main branches of transport layer protocols, namely connection ori-ented communication and connectionless communication. These are represented bythe most important and commonly used protocols, TCP and UDP respectively. Forthe reader unfamiliar with these protocols may look for a detailed description in[20].

2.10.1 Transmission Control Protocol (TCP)

A good introduction to TCP can be found in [14], from which this short descriptionis taken:

“TCP provides an effective abstraction of a reliable network run-ning over an unreliable channel, hiding most of the complexity of net-work communication from our applications: retransmission of lost data,in-order delivery, congestion control and avoidance, data integrity, andmore. When you work with a TCP stream, you are guaranteed that allbytes sent will be identical with bytes received, and that they will arrivein the same order to the client. As such, TCP is optimized for accuratedelivery, rather than a timely one.”

It is a very rich protocol full off functionality to simplify application level design,which is why many of the applications running over the internet use TCP.

2.10.2 User Datagram Protocol (UDP)

UDP is often referred to as the “null-protocol” for its very limited featuristics. It isknown for omitting functionality rather than adding to it. [20] describes it as:

“UDP is basically an application interface to IP. It adds no reliabil-ity, flow-control, or error recovery to IP. It simply serves as a multiplex-er/demultiplexer for sending and receiving datagrams”

This protocol is especially suited for applications with small messages were dataloss can be tolerated. Examples of such applications includes online gaming andVoIP.

2.10.3 On Transport Protocols

The reason for including a short descriptions of these protocols is because the ap-plication in VCI+ will need both for its functionality. Instructions need reliability,

21


and fast updates are important for the user experience.

TCP functions that most often makes the protocol very useful, may have a neg-ative impact on performance. This regards areas such as flow-control, congestionavoidance, congestion control, reliable- and in-order packet delivery.

The application as it is envisioned will make use of very short messages fitted inonly a single TCP packet, so it is difficult to assess to what extent TCP would addto the overall latency. Investigating the best suited transport protocol is outsidethe scope of this thesis, but it is very important to keep in mind in the continuedwork.

However, TCP sessions require a three-way handshake before a communication isestablished. For this reason, it is essential to keep the TCP connection alive duringthe diagnostic session to avoid unnecessary latency.

TCP has a relatively large header which forms a large contribution to the over-all packet size when sending small messages. This would normally not generate anoticeable addition to latency, but with the increased loss rates of radio communi-cation it may prove to have an impact although probably very small.

2.11 Envisioning the Future System

An architectural overview of the targeted future system is shown in Figure 2.4. Itshows the different parts that constitutes the new system.

22

2.11. ENVISIONING THE FUTURE SYSTEM

Figure 2.4. Future system overview

23

Chapter 3

Further Areas of Research

3.1 Modeling the UDS Protocol

For the purpose of getting a deeper understanding of the diagnostics standard ithas been modeled in the model checking tool UPPAAL®.

3.1.1 The UPPAAL Software

From the creators own definition:

Uppaal is an integrated tool environment for modeling, simulationand verification of real-time systems, developed jointly by Basic Researchin Computer Science at Aalborg University in Denmark and the Depart-ment of Information Technology at Uppsala University in Sweden. Typ-ical application areas include real-time controllers and communicationprotocols in particular, those where timing aspects are critical[21].

For the reader not familiar with this software, there is a very good introductionhere [22].

The reasons for working with the UPPAAL software were the time critical proper-ties of the standard, the visual representation UPPAAL simulation provides and itsverification possibilities.

Before showing the actual modeling let us first go through the fundamentals offormal verification.

3.1.2 Computational Tree Logic

Temporal Logic regards the study of time i.e. to describe a system and its propertiesin terms of time. Lets say there is a system A. A has a set of properties that mayvary in time, sometimes a property is true and sometimes it is not and studying thestate of A over time can be done with temporal logic.

25

CHAPTER 3. FURTHER AREAS OF RESEARCH

It might be of interest to ask if some property of A is always true, or if it is evenpossible that it will ever be true. Answers to these questions of future can be ob-tained by Computational Tree Logic (CTL), which is in the class of temporal logic.CTL is a branching-time logic which considers paths of the future. The differentpossible futures can be visualized as branches of a tree and any one of them maybe the one realized.

3.1.3 Property Checking with UPPAAL

Further, Timed CTL (TCTL) is CTL with clock constraints [23]. UPPAAL usesa subset of TCTL and just as TCTL it uses path formulae and state formulae.A state formula describes individual states without looking at the behavior of amodel. Path formulae looks at paths and traces of the model and can be dividedinto three properties, reachability, safety and liveness. The temporal operators usedin UPPAAL are:

• A - for all paths• E - there exists a path• G - for all states in a path, written “[ ]” in UPPAAL• F - there exists a state in a path, written “<>” in UPPAAL

Lets define p and q as local properties. There are five legal queries in UPPAAL[24], see Figure 3.1 for a graphical representation:

• A[ ]p - for all paths, p is true for all reachable states i.e. p is invariably true,this is a safety property

• E<>p - there exists a path where at least one reachable state holds p true,this is a reachability property

• A<>p - for all paths there exists a reachable state where p holds true i.e. pis inevitably true, this is a liveness property

• E[ ]p - there exists a path where p is true for all states i.e. p is potentiallyalways true, this is a safety property

• p → q - if p becomes true, q will inevitably become true, this is a livenessproperty

The local properties p and q may assume values of: automata location, data guard,clock guard, p or q, not p and p imply q. For example p → q is the same asA[ ](p imply A<>q) i.e. for all paths, if p is true, q is inevitably true. There willbe more examples in the model verification section.

26

3.1. MODELING THE UDS PROTOCOL

Figure 3.1. Property checking queries

27


3.1.4 UDS Models

The model consist of the ISO15765-2 standard that describes the network layers inthe communication. This layer is similar for both client and server. It also includesmodels of the ISO15765-3 session layer, one describing the client and one the server,due to differences in session handling. In this case the VCI+ is the client and thevehicle ECU is the server. No space of this section will be given to explain thestandard, there is simply no room for a sufficient explanation, why these modelsshould be interpreted with the help of the ISO15765 documents.

Due to copyright and license claims the model with UPPAAL had to be omittedfrom this report.

3.1.5 Results and Discussion

The original intent when creating this model was to extend it beyond the standard.To include a larger part of the entire VCI+ application. However, this part wasfound to be unsuitable for modeling. The reason is that the development of thisproduct is in an early exploratory phase and no formal requirements have yet to bedefined, which would have complicated the verification. Thus the model became agood way of visualizing the standard for a deeper understanding, but served unfor-tunately no further use.

However, all the queries that was formulated passed their test, suggesting thatthe model was accurate according to the properties tested. Although there is al-ways the risk that important properties were left out.

There was also the intent of using the model for performance evaluation. Thiswould have required thorough measurements to be of real use and was left out dueto time limitations.

28

3.2. STATIC ANALYSIS OF C-APPLICATION

3.2 Static Analysis of C-Application

The VCI remote platform should be able to operate without having any interactionfrom the user except of that through the back-office application. This requires aflexible and reliable system that is able to handle various sources of errors, such aswrong input, absence or delay of input either from the back-office side or the vehicleside, corrupted settings and data, failed system calls etc.

One way of avoiding bugs are to ensure that best practices are being used, andthis can be checked by means of static analysis tools (SAT). Static code analysisrefers to an analysis of source code without executing it, in contrast to dynamicanalysis, which checks the code during runtime[25]. Dynamic checks are often moreextensive and time consuming, and static code analysis is therefore considered to bea good method to use from an early stage in the development of a new project. Thereare a number of tools available for static analysis C source code, both commercialand open source[26]. Although static analysis prevents many common errors suchas uninitialized parameters, dereferencing of uninitialized pointers, dynamic allo-cation of memory and more, there are still many types of errors that usually goeswithout notation from a SAT, such as concurrency errors, both in single threadedand multithreaded applications[25].

3.2.1 Clang Scan-Build

The first analyzer that was tried out was Clang scan-build. Clang is a compiler thatprovides an alternative to GCC, and comes with a number of accessories includingthe static code analyzer called Clang scan-build.

Scan-build is run at compile time, and rendered two warnings for the project, one ofwhich was due to an assignment of a variable to zero at the beginning of main loop,which was never read until it was assigned to another value. The second warningaddressed a more serious flaw, namely an attempt to make a bit-wise OR assign-ment to a member of a data structure that has not yet been assigned a value. Theconversion within the socketCAN API is generally to clear the data in structuresafter declaration using the memset() system call. Although this did not clear thewarning, the only option was to assign the member the value of zero before bit-wiseOR assignment.

3.2.2 Splint

With Clang scan-build only generating two warnings, it seemed necessary to tryother static analyzers, at least for benchmarking purposes. The second candidatewas Splint, a successor to LCLint, a tool for statically checking C programs forsecurity vulnerabilities and programming mistakes[27].

29


Method

First, the project was developed and compiled so that no warnings were generatedwith the -Wall warning level. The application was also tested, so that it worked asintended in all aspects. After this, Splint was applied. The first attempts to runSplint on the source code was not successful. After some research, the answer wasfound in a discussion mailing list for Splint [28]

”Splint fails to compile code for the Linux kernel largely because itdoes not have some gcc specific features that the kernel code relies on.Defining a list of FLAGS for splint that gcc defines by default helps withthis.”

The author of the input on the referred web page also suggested a layout for amakefile to be able to run Splint on Linux, that with a few modifications, made itpossible to run Splint on the source code for this project. The first successful exe-cution with Splint was done without using any flags for the purpose of suppressingwarnings. This yielded 153 warnings for the entire application. The Splint manualstates that using Splint without any flags “will produce a large number of warnings”.Commonly, the -weak flag is given as an argument for a less strict warning level[27].

Classification of Warnings

The main bulk of warnings were generated from assignments or comparisons wherethe right hand value and left hand value had different types. There were mainlythree different data types that were involved, __u8, int and unsigned int. The__u8 data type is an 8 bit unsigned integer defined by the Linux Kernel libraries(corresponding to unsigned character).. This is because the underlying data type(unsigned char) is being considered by Splint. The warnings occur even when doingcomparisons where the right side value is a number, not a variable. For instance,the expression CAN_frame→data[0] == 0x03will yield a warning, because Splintexpects an unsigned character to appear as a right side value. As with the previouscategory of warnings, one solution is to cast the expressions that generates a warn-ing to the same type, e.g. the example above would be CAN_frame→data[0] ==(__u8)0x03. In this project, the warning is suppressed with a flag instead.

The second most frequent type of warnings referred to ignored return values fromfunctions. Warnings for omitted return values can serve as a reminder to checkfunctions that are important for the application to function properly, such as somesystem calls and calls to various APIs. However,there are many functions that uti-lizes the return value such as user defined routines, as well as library calls thatreturns an int but the result is not crucial for the application, such as the printf()call. In order to avoid these warnings without suppressing them with a flag, a castwith (void) can be made to every such function call. The trade-off with such anapproach is that the readability of the code decreases when applying too much am-bient code for error checking or casting around every function call. On the other

30

3.2. STATIC ANALYSIS OF C-APPLICATION

hand, a function where a failing call would require error handling could be missed ifthe flag to ignore return messages is to be applied. There exists one suppressing flagfor every type of return value, which gives the developer freedom to choose whichtypes of return values to not be considered by Splint.

Another warning is related to the use of sprintf(), which Splint warns is subjectto possible overflow, and advice is to use snprintf() instead. The latter functiontakes one extra parameter compared to the first function, namely the length of thestring that is be written to the source. The idea of snprintf() is that the developershould keep track of how many characters that can be written to the string, if thelength of the input string is unknown. If the number of characters in the inputstring exceeds the length-of-message parameter, the excessive characters in the in-put string are discarded and only the characters within the boundary are writtento the destination string, thus avoiding overflow. In this application, the length ofthe input string are always known in advance in places where sprintf() is used. Thebuffer size of the destination source is also guaranteed to be big enough to hold themaximum number of consecutive frames that can arrive as one message. Thus, thesprintf() warning seems unjustified for this application. One observation that wasmade with regards to the sprintf() warning is that Splint did not warn where thestrcpy() function was used instead of strncpy().

Some false negatives are generated due to missing c99 extensions in Splint. In thisproject, it could be seen on the format specifiers used in the printf() and scanf()family functions, e.g. %hhx or %z for 8-bit unsigned hex and size_t respectively.

A number of warnings were also generated from sections of code that was takenfrom manuals for different APIs, such as the setup for posix threads and unixsockets. These warnings have not been analyzed in this project. Due to the in-compatibility with C99 standards and warnings generated from parts of code thatare following examples of manuals for the library APIs, 4 out of 153 warnings re-mained after modification of the code. All warnings before correction are presentedin appendix B and warnings remaining after correction are presented in appendix C.

A warning of relevance particularly in embedded systems was generated from codewhere boolean operations are applied on non-boolean types. The usage of booleanoperators on other types is very often seen (it appears to be common practice) inapplications that are written for systems such as personal computers. However, thispractice is discouraged in embedded systems with safety critical properties. Thereare a number of subsets in C for embedded systems, and one of the most commonis MISRA-C.Boolean operations, that are used like in the expression “if( !function())”, where function() returns an int, will generate a warning. The correct expressionhere would be “if( function() == 0 )” instead.

31


MISRA C

Motor Industry Software Reliability Association (MISRA) has defined a standardwith a set of guidelines for development of software for critical systems, calledMISRA C. This standard was originally intended for the UK automotive industry,but has after its release been utilized worldwide in other areas subject to safetycritical software development, such as medical industry, aerospace, telecoms andothers [29].

MISRA-C 2004 consists of 121 mandatory rules and 20 advisory rules. One ofthe ambitions for this individual research has been to get the C application to com-ply with the MISRA-C 2004 standard, but since there are no free static analyzersavailable that supports the MISRA-C subset, it was not possible to verify if the codeactually did comply. Some big corporations involved in embedded software devel-opment have implemented their own static analyzers, that incorporates MISRA-Cas well as naming conventions for data types and methods[25].

32

Chapter 4

Design

This chapter will describe which design choices have been made and the rationalebehind them.

4.1 Hardware

At first a unit already fitted in Scania Vehicles today, the C200, was considered asa platform for the prototype. However, to be able to develop a system with goodprototyping possibilities and independence from current solutions and support fromother departments on Scania, this option was abandoned. After some consideration,it was decided that the platform should have properties that satisfies:

• Small footprint• WWAN• Support for CAN hardware and drivers• Support for full IP stack• Ethernet connectivity• USB connectivity• Reasonable price

Different hardware alternatives were reviewed based on these criteria. Looking foralternatives on the internet was a somewhat tedious task, as it was not fully spec-ified what the project should be able to achieve at the time. In addition, it wasdifficult to assess some important aspects for different platforms, such support forhardware modules, maturity and online support through user communities. Aftersome research and recommendations from staff at the KTH mechatronics depart-ment, the Beaglebone emerged as the most sensible choice.

The Beaglebone is a small development platform featuring a AM335x 720MHz ARMCortex-A8 processor and 256MB of RAM, see Figure 4.1. It is delivered with a 4GBSD-card with a pre-installed Ångström Linux image. Connectivity includes a stan-

33

CHAPTER 4. DESIGN

dard USB port, mini USB, Ethernet as well as expansion headers for add-on units.A number of expansion boards referred to as capes are available, including one forCAN. See a CAN bus cape in Figure 4.2. In this prototype, the setup constitutedthe Beaglebone together with the Beaglebone CANbus Cape. A mobile phone con-nected to the usb port served as a 3G dongle. With the attachable CANcape, the

Figure 4.1. beaglebone platform

Beaglebone satisfies nearly all of the set prerequisites, with the exception of builtin WWAN hardware. Among the different platforms reviewed however, none hadbuilt in hardware modules for both CAN and WWAN. Similar platforms includethe Beagleboard, Pandaboard and the Raspberry Pi, but these platforms have aslightly different niche towards media applications, and none provided support forCAN in the same portable manner as the Beaglebone.

4.2 Software

4.2.1 Software Architecture

In a real industrial application with a VCI of this kind, entire fleets would be com-municating with a back office server. In this thesis, scaling was never taking intoaccount in this aspect. The back office server was merely implemented since it wasnecessary part for demonstrating the work, and was never considered an integralpart of the objective.

34

4.2. SOFTWARE

Figure 4.2. beaglebone CAN bus cape

For the design of the software on the VCI itself, the aim was to create an ar-chitecture that would be a realistic approach for an industrial design. As eachindividual vehicle would be independent of the fleet, scaling issues should not beapplicable to the VCI software. Modularity however was an important point ofconsideration, since the platform should be able to perform many tasks of differentcharacter. Considering the two input-outputs the platform would have, a naturalpoint of separation seemed to be between two main modules, one acting as inter-face to the CAN bus and one interface towards the internet. This way, one modulewould function as the a lower level API (the CAN bus interface, henceforth referredto as the CAN application), translating the requests from the user into instructionsto the vehicle’s CAN bus, and the other module would function as a "user-level"application (the internet interface, henceforth referred to as the VCI+ application).Figure 4.3 presents a simple overview of the VCI architecture.

4.2.2 SocketCan

SocketCAN is an open source API for CAN implemented in the Linux kernel. It isbased on the existing networking subsystem of Linux, added alongside other proto-cols such as TCP/IP as displayed in Figure 4.4

The socketCAN API is the official CAN API for Linux[30] and makes it possible toset up a CAN application in a similar manner to an internet server using traditionalsockets. Compared to many other CAN drivers available for Linux, SocketCAN isnot designed specifically for any particular hardware module. System calls used for

35

CHAPTER 4. DESIGN

Figure 4.3. VCI software architecture

Figure 4.4. The architecture of SocketCAN

36

4.2. SOFTWARE

network and socket programming in Linux have the same functionality for Sock-etCAN as for the usual internet protocols. Setting baud-rates and other settingsis done with the ip(8) suite, in this case by means of a script. Together with theCANbus Cape, the socketCAN API makes CAN work out of the box on beaglebone.Adding to this, SocketCAN has a good documentation and many implementationexamples, which are easy to find on the internet.

4.2.3 Programming languages

The first software moduele, the CAN application, is written in C, which has greatsupport in Linux with its standard libraries including socketCAN. The rationalebehind the choice of C is mainly due to that SocketCAN is written in C, as is thebulk of the Linux kernel. Support for socketCAN was also implemented in Python3.3, which made Python a candidate along with C while reviewing alternative lan-guages. However, it proved to be difficult to find documentation and examples forsocketCAN in Python. The good documentation for SocketCAN in the C program-ming language together with the freedom that comes with the huge standard libraryfor C in the Linux kernel made C the language of choice.

The other software module, the VCI+ application, is the layer that the user interactswith via the internet, and also implements all functionality that is needed for theVCI to respond accordingly to commands sent through the back office server. Sincethe VCI+ application needs to be able to carry out several tasks asynchronously,a threaded or multi-process application is necessary. In this case, the threadingapproach was used. Threads have the advantage over multiple processes that theyimpose significant less overhead in the OS during spawning and execution, and theyalso share the same memory space which makes inter communication between asyn-chronous tasks easier[31]. Since an iterative method was applied as working process,and because it became clear that the client application would have multiple pro-cesses, a language with object oriented features and extensive libraries was sought.At the same time, it should be easy enough to understand and work with. Withthis in mind, the decision landed in Python. As with the C, both authors had pre-vious knowledge of these programming languages from earlier projects, which alsofavoured Python. Python is considered a high level language scripting language,with a clear syntax and object oriented semantics[32].

37

Chapter 5

Implementation

This chapter will describe the functionality built in to the software during thedevelopment process.

5.1 CAN Application

5.1.1 Operation

The CAN application has two TX/RX communication channels, one being a Unixsocket that communicates with the VCI+ application and one CAN socket thatcommunicates with the vehicle. Briefly explained, the task of this module is toreceive a string from the VCI+ application, and to package the data into the properdata structures utilized by SocketCAN. In addition, by analyzing the input data itdetermines what type of messages are to be sent on the CAN bus, populates theCAN frames and controls the flow sequence of messages according to the diagnosticstandard. Although having implemented just the basics of the diagnostic standardto meet the requirements for this project, the source code contains around 2000 linesof code. The bulk of the execution is synchronous, but to be able to maintain thethe diagnostic session open while waiting for input from the VCI+ application, theECU in the vehicle that is being addressed have to receive a frame every 4th second,a frame referred to as "tester present" which was described in chapter two. For thispurpose, two Posix threads have been implemented, one main thread handling theprimary execution flow and one child, handling only the “tester present” frames.In order for the threads not to write to the CAN bus or common variables at thesame time, a mutex has been implemented. The “tester present” or child thread isconstantly running, but when the main thread is using the CAN socket, the mutexblocks the child thread. When the main thread has looped through its main loopand waits for input on the Unix Socket, the mutex is unlocked, and the child is freeto use the CAN socket until the main thread receives another input on the UnixSocket. The main thread and the child thread share a struct of common variables,of which one member is the socket, one member is the ID for the ECU that is being

39

CHAPTER 5. IMPLEMENTATION

addressed and third one is a flag that informs the child if a new ECU ID has beenset.

5.1.2 Error Handling

The main loop is just made out of very few function calls in order to create a higherlevel of abstraction. In these top level functions the flow sequences of the standardresides. The code inside a top level function represents the middle abstraction layer.No direct system calls or string manipulations are made here. The middle layer onlycontains mid level function calls, and it is inside this functions the lower layer re-sides, where actual operations on data are carried out. The lower layer functionsanalyzes the input data, manipulate strings and invokes system calls to the Linuxkernel and the SocketCAN API. The purpose of this design is that if an error occurs,the execution should be aborted and return a specific error number by unwindingto the main loop, which subsequently calls an error handle function. After this, theprogram should take action depending on the nature of the error that occurred. Inmost cases, the program will return to the start of the main loop, waiting for a newmessage to arrive on the Unix socket.

Several error handling mechanisms have been added, such as checking that onlycorrect characters are given as input, that the length field corresponds to the actuallength of the message, and timeouts for reading CAN sockets to mention some.Each individual error is defined as a unique number that is passed to the errorhandler, which forwards an error message over the internal unix socket to the VCI+application and decides how to handle the error.

A simplified flow chart over the logic in the CAN application is presented in Fig-ure 5.1. In order to reduce complexity and size, operations such as error handling,low level operations like string modifications, most of the diagnostic standard andthe second thread are not depicted. The three possible input modes are representedby a three character long string, where “ext” is for exit, “kwp” is for a single kwpcommand, and “str” is for continuous streaming of data. If any other combinationof characters resides in this field, an error is returned over the unix socket and theprogram returns to the start of the main loop.

5.1.3 Unix Socket Interface (input/output)

The VCI+ application communicates with the CAN application through a string ina certain format. Figure 5.2 depict these strings. The input format of this stringis represented by the upper figure and the output by the lower figure. The lengthof all fields in a string is always fixed, except for the data field which has arbitrarylength. The Length field should specify the total length of the string minus the four

40

5.1. CAN APPLICATION

Figure 5.1. Flow chart of the diagnostic API written in C

characters for the length field itself. The rationale behind the chosen design of inputis that it should be easy to read for a human e.g. when the traffic is being printedfor debugging purposes, but also easy to handle in the application. The separationby commas between the mode field and the CAN ID field, as well as between theCAN ID and the Data field makes it possible to easily implement varying length

41


Figure 5.2. CAN application input/output message format

of fields, since the parsing of the input string is handled by pointer arithmetic thatrecognizes the separating commas. The length field is used for error check andredundancy check.

5.1.4 Vehicle Input / Output

The socketCAN API for raw sockets handles independent CAN frames, with a datafield consisting of a list of eight unsigned integers, each with a size of 8 bits, whichcorresponds to the maximum allowed size of the data field in one CAN frame.Every message that arrives from the VCI+ application bound for the vehicle willbe converted from string to integers, and vice verse in the other direction.

5.2 VCI+ Application

The VCI+ application has its CAN functionality in the center, but it needs othersupporting functions as well. The VCI+ application can be divided into three areas:

• Diagnostics: includes communication to the CAN API, routines for executingdiagnostic tests, logging of diagnostic communication and more.

• File management: includes supporting functions for diagnostic tests e.g. filetransfer, file removal and fetching a list of files currently available in thedesignated directory.

• Communication: TCP and UDP connectivity, session control, watchdog etc.

5.2.1 Application Initialization

The VCI+ architecture is shown in Figure 5.3 which also displays the programsinitialization path.

The execution starts in the image center with the coordinator thread. This isthe core thread of the application. It is the only thread spawned by main and re-sponsible for creating and maintaining all other parts of the application.

42

5.2. VCI+ APPLICATION

Figure 5.3. VCI+ top level initialization

There are four threads for file management each responsible for one function, seethe green boxes. These threads are spawned by the coordinator on request by theoperator, they execute once and terminates on completion.

The coordinator creates a TCP manager which is responsible for communicationwith the server. In turn the TCP manager spawns four threads. TCP send, re-sponsible for formatting and relaying the message over a socket. TCP receive waitsfor incoming messages and formats it for further use. A watchdog thread which isresponsible for determining whether the connection is alive. Finally a send threadthat periodically signals to the server that the VCI+ is still active. These threadsare spawned on a new connection and terminated when the connection closes.

A CAN manager is also created by the coordinator, but the CAN functionalitywill be treated later on in this section.

5.2.2 Data Flow

Let us look at data flow and how the internal communication works in the applica-tion. Figure 5.4 shows the same image but the arrows now mark the data path.

One can see that no communication goes through the TCP and CAN managers,they are only used in session control. Instead the data is relayed straight to the

43


Figure 5.4. VCI+ data flow

active threads. Data may only be exchanged between threads in two ways, eitherduring initialization passed as parameters, or passed on a queue.

All messages goes through the coordinator, whether they are incoming or outgoingfrom the VCI+. The function of the coordinator is to relay data to the right recip-ient and monitor active tasks. Every time a new thread or object is created by thecoordinator, it is given a reply queue on which all messages created on the VCI+ isput on.

The architecture was designed to remove any polling. All threads wait for a block-ing queue or in some cases a blocking socket. When a job is ready, it performs itstask and return to the blocking position, which means that a thread is only awakewhen it has an actual task to perform.

5.2.3 Diagnostics Application

The CAN functionality has somewhat been revealed in earlier figures, but there aremore going on behind the Send and Receive threads. Figure 5.5 shows an architec-tural image of the diagnostics application.

44


Figure 5.5. VCI+ diagnostic application architecture

The figure reveals that much is revolving around the CAN Send thread, whichuses three additional resources for its functionality. The test utilities provide func-tions for running diagnostic tests. The log utilities enable logging of diagnosticcommunication, and the subscribe utilities sets up a new communication path tothe server over an UDP connection for fast response. Lets explain the functionalityin terms of a few scenarios.

Sending an UDS command

The operator sends a diagnostic KWP command that is relayed to CAN Send fromthe coordinator. CAN send identifies the command as an ordinary KWP command,checks if logging is active and sends the message to the CAN API as a string throughan internal socket. A message is received in CAN Receive and forwarded to CANSend. CAN Send identifies the message as a reply to a KWP command, logs itif active and sends a reply back to the coordinator which eventually reaches theoperator.

Running a Diagnostic Test

The operator sends the name of a diagnostic test that is available in the VCI+repository. CAN Send gets the message and identifies it as a command for startinga new diagnostic test. The file-name is sent to the test utilities which loads the test

45


and executes the first instruction. The instruction is sent as a status update to theoperator, logged if active and sent to the CAN API. A response is received in CANReceive, forwarded to CAN Send and identified as a reply from a running test. Thereply is sent to the operator, logged if active and sent to the test utilities to repeatthe loop, which continues until the test is finished or aborted.

Starting a Subscription on a Parameter Readout

Again the operator sends an instruction to make a subscription on a diagnosticreadout. This instruction is in the form of a single KWP command. The CANSend activates the subscription by calling the subscribe utilities which in turn cre-ates a new UDP link. The message is forwarded to the CAN API which handles thesubscribe mechanism. CAN Receive will get continuous messages from the CANAPI until the subscription is terminated. Each are sent to the CAN Send, passedfurther to the subscribe utils and sent on a UDP socket to the server.

This is the only communication path that does not go through the coordinator. Go-ing through the coordinator would require a certain message format which greatlyincrease the overhead on the message. In subscription mode it is not critical that ev-ery message is successfully transmitted, instead speed is the critical factor, why theuse of UDP. It is worth to note that there is no logging available on the subscriptiontraffic.

A New Protocol for Diagnostic Tests

It has been explained why the traditional way of running diagnostic tests is notpossible in the new system. A new protocol for running diagnostic tests remotelyhas been created for demonstration purposes. [10] proposed an XML script basedmethod that would also be satisfying in this application, but no design solutionswere revealed, hence a new protocol was created according to the functionality de-scribed earlier.

The proposed protocol describes a test in a customized form of a state machinewritten in XML, see a sample script in Figure 5.6. Standardized ways of writingstate-machines in XML was found, but they were too rich and complex and it wasdecided to create a new simple protocol that only included the essential few partsneeded.

Every state includes two types of entries, kwp and reply. There is only one kwpentry for each state, which includes the kwp instruction intended for the vehicle.Every state also specifies one or more reply tags that contain instructions and logicfor creating a decision based on the reply, its attributes are:

• <id>: is the number that the response is compared to when looking for amatch.

46


Figure 5.6. Proposed test script written in XML

• <operator>: defines how the comparison should be done.• <ref>: reference value for comparison.• <wait>: a timing variable, specifying the time to wait before executing the

next command.• <true>: specifies the next state if the comparison holds true.• <false> specifies the next state if the comparison holds false.

A diagnostic test starts in state 1 where the ECU identifier and kwp instructionis retrieved under the kwp tag. The test remains in state 1 while running thisinstruction. When a reply is received the test utility goes through the differentreply tags specified in state 1, looking for a match. If a match is found, the nextstate is retrieved. If there is no match, the test is aborted. The next state may alsobe specified to finished or failed on which it is ended.

5.2.4 Server Architecture

A back-office server with an interactive Graphical User Interface (GUI) was createdfor demonstration purposes, its architecture is shown in Figure 5.7.

The structure of the server is very similar to that of the VCI+. It has a coor-dinator which initializes the remaining parts of the application. The coordinatoris also responsible for passing messages to and from the GUI. A snapshot of theGUI is shown in Appendix A. There are four options under ”available commands”:download file, upload file, remove file and CAN command. Choosing CAN com-mand results in four additional options. To send a regular KWP or UDS command,start a diagnostic test, start a subscription of a parameter readout, or to select anddeselect logging of the diagnostic communication. There are also lists for tests andlogs available on the VCI+ and server, which can be updated at will. There is alsoa list of predefined KWP commands along with other elements seen in the figure.What the figure lacks is a graph that pops up when requesting a subscription that

47


Figure 5.7. Back-office server architecture

creates a live representation of the parameter value.

5.2.5 Communication Protocol

A communication protocol was established between the VCI+ and server, contain-ing a message specification, ethics and rules for the diagnostic session.

The VCI+ acts only as a client in the prototype system. This implies that theback office may not call on the VCI+, and that merely the VCI+ initializes contact.This is mainly due to a lack of a static IP address on the VCI+ side in the exper-imental setup. It is however quite simple to obtain static IP addresses by specialarrangements with a mobile network provided, for an additional fee. Although itwould be questionable - with the IPv4 addressing used today - to obtain static IPaddresses for several hundred thousand potential future clients, the current solutionseems like a reasonable design decision. There are also positive effects on a safetyperspective with having the VCI+ as a client only with dynamic IP addressing,for it becomes more difficult to find the address of a specific vehicle and to furtherestablish contact for a malicious third party unit.

48


Additionally, it is neither possible for the server to do any direct manipulationof the VCI+ and may thereby not directly upload or download files from the VCI+.The server may only request a defined set of operations for the VCI+ to perform.When a file is downloaded to the VCI+, it is the VCI+ that fetches the file, afterbeing instructed so by the server. A positive effect is that this pattern generates thesame type of execution path for all instructions. Although it makes some operationstake a little longer.

Routines for session control were included to determine if the session is active andprovide counter measurements if the connection is lost. This was done with two ele-ments, a watchdog and a periodic send function for automatically sending messagesto notifying presence. When a connection is established, a watchdog timer is startedin the server and every time a new message is received the timer resets. A timeouttriggers the server to disconnect and it starts to listen for new clients. The VCI+starts a timer controlling a periodic sender, sending a specific message notifying theserver that it is still connected. This is done regardless of other messages being sentat the same time. The watchdog and sender should exist on both server and VCI+,so that e.g. the VCI+ could halt all activity when the connection is lost, or try toreconnect if messages are absent. Though keep in mind that the prototype was onlytested during controlled circumstances and this extra functionality were judged ashindering during testing.

The back-office server and its operator is the master during the diagnostic sessionand the VCI+ is always ready to process new instructions. Every process is startedby a request from the server, whereupon the VCI+ immediately acknowledges therequest. Feedback is sent back to the server as soon as it becomes available, untilthe process is finished. Figure 5.8 shows a communication dialogue when the serverrequests the execution of a diagnostic test.

The operator requests the execution of a test that is already residing in the VCI+test repository (1.). The request is acknowledged (2.), the test is loaded and thefirst diagnostic instruction is extracted. This instruction is first sent to the vehicle(3.) and then a status message is constructed and sent to the server (4.). (5.) areply from the vehicle is received, processed and a new instruction is sent to thevehicle. This time both the reply and the new instruction is sent to the operator.This continues until the test sequence is finished.

5.2.6 Testing

The general verification a test was setup to measure the RTT for single packages,sent from a server to the beaglebone. Since the RTT for a message on the CANbus was already known, the CAN API was replaced with a server that echoed themessages once the client application sent them over the Unix socket connection.

49


Figure 5.8. Sequence diagram of the VCI+ to back-office communication

The setup for the test can be seen in Figure 5.9. Packets from the server was timestamped upon transmission and reception, and the RTT was calculated from thedifferential between the two time stamps.

Figure 5.9. Sequence diagram of the VCI+ to back-office communication

50


The ambition was to test out different types of connections, such as LTE, HSPA+,HSDPA, EDGE, but as the equipment that connected the beaglebone to internetwas limited to a smart-phone, and thus it was not possible to set the type of connec-tion manually. During the test, the connection kept altering between HSPA+ andHSDPA. This was also possible to see in the results, although the type of connectionwas not the only parameter that seem to have affected the RTT; other applicationsthat were running at the mobile phone, consuming bandwidth and processing powermay have added some extra delay as well.

The tests indicated a clear threshold around 2 seconds after which the radio towerclosed the open connection. If the packets were sent later than this limit after thepreceding packet, the RTT increased significantly - typically in the magnitude ofseveral hundred percent. At best, an RTT of around 0.4 seconds was noted, andworst case, when a new connection was to be made, delays up to as large as fiveseconds could be seen.

51

Chapter 6

Retrospect

6.1 Results

This thesis had a very practical orientation and its main result was the implemen-tation described in the previous chapter. It was demonstrated at Scania on a fullscale vehicle. The functions that was shown has a direct connection to goals statedin the introduction. The platform is connected by the ODB port which makes itinherently usable in all trucks. Every piece of information of a diagnostic test iscontained in a script which is sent to the VCI+ and run without modification, whichremoves the need for any vehicle specific data on the platform.

The ability of providing the same functionality as the current system was exhibitedthrough two scenarios. These scenarios included readouts of DTC’s and the execu-tion of customized diagnostic tests. The first one merely sweeped the gauges of theinstrument clusters, while the second activated different valves in the gearbox, readthe position of the associated piston, and if it was not properly actuated the testfailed. This was considered to be a good representation of what was stated in thegoal.

There was one part of the demonstration setup that was not consistent with theoriginal architecture, namely the internet connection of both VCI+ and server. TheVCI+ was running on an Angström build which did not have support for connectingthe 3G dongle at hand. However, running it on Ubuntu would provide the properconnectivity, but the support for socketCAN and the CANcape for the beaglebonewas uncertain. It was possible for a mobile phone to provide internet with Angstromrunning, which became the adopted solution. As consequence, there was no possi-bility of controlling the type of connection used e.g. HSPA+, HSDPA, 3G, Edgeand so on. Another issue was obtaining a pulic static ip-address at Scania. Thiswas solved by running the server on a 3G dongle, which was of course a setback. Itresulted in both sides running on a mobile connection which meant that both sideswould be affected by the limitations of that type of connection, further increasing

53

CHAPTER 6. RETROSPECT

the latency and reducing the quality of the demonstration.

The real-time responsiveness in the application was demonstrated by subscribingon the accelerator pedal position. The VCI+ triggered a readout once every 100 msand immediately forwarded the message to the server, which added it to a graph.The live streaming of data gave the appearance of real-time. If one was to observechanges in the graph while pumping the gas pedal, the time delay was hardly no-ticeable. However, when sending regular commands with varying and longer timebetween each call, the latency increased.

6.2 Conclusion

The works of this master thesis ended in a result that satisfies the goals set on theproject. Except for the one regarding real-time user experience, which cannot beconsidered fully achieved when the response time sometimes exceeds one second.Improvements will however be discussed in the following section. The intent ofthe prototype was to demonstrate essential diagnostic functionality which it didsuccessfully.

6.3 Discussion

First of all as stated before, the result is only a first prototype with the main pur-pose of investigating and demonstrating new functionality. This means that manyimportant aspects such as QoS has been neglected, see the delimitation section.The heavy emphasis on demonstrating functionality came with a side effect. Theresulting code is not flexible enough to account for larger changes or expansion i.e.it will be hard to make large changes to the system without rewriting substantialparts of the source code. One can argue though that this was not a requirement inthe first place.

An attempt was made to test the latency increase induced by the Control-PaneLatency and to find out at which time the radio state changes. During this test theserver was connected to a regular public ip-address, which it was not during thedemonstration. The VCI+ was however still connected through a mobile phone.The test first showed signs of increased latency after a few seconds of radio silence,which indicated a change in radio state. After a while the tests started to givemore stochastic results and the original pattern was gone. There were two majorflaws in the test which we believe to be the origin of this. First, it was not possibleto control other applications that was concurrently running on the phone. Theseapplications may have used the radio for their own interest and thereby breakingradio silence, making our results erroneous. We also noticed that the connectiontype changed between HSPA+, HSDPA and 3G during the test sequence, whichmakes the individual results incomparable. Due to time limitations, these flaws

54

6.4. FUTURE WORK

could not be corrected why the test results was rendered inconclusive.

However, the response times that was achieved during the test was most oftenbelow one second, especially for test cases where the time between calls were short.The latency could however reach several seconds in more unusual cases. The goal ofa one second or less response time could therefore not be satisfied. Even though thisreport did not manage to provide formal evidence of the affects of Control-PlaneLatency, it is still our belief that controlling the radio state correctly would leadto a significant performance improvement. That can be done simply by sendingmessages in a high enough frequency, keeping the connection active.

The larger variances in latency experienced during the test is not likely only aproduct of Control-Plane Latency. Its origin can reside in a multitude of reasons,several of them mentioned in the chapter on mobile communications. But there wasno attempt to determine the cause of this variation.

The subscription method displayed very short delays in its message transmission.It used UDP as transport protocol and the messages were much smaller than theregular command messages that was sent over TCP. It is possible that a part ofthe latency difference can be explained by the change in transport protocol. It wasour hope to investigate if there were any performance differences between transportprotocols, but in the end there was simply not enough time. Message size is lesslikely to have affected latency, for all messages fitted into a single package and theywere also very small when taking the loss rate of mobile communication into account.

Our result showed that it is technically possible to perform the requested function-ality over a remote distance. The main problems and limitations in this applicationlies outside of what has been studied in this thesis. These problems regard safety,security and scalability among other. Solutions in these areas may have significantimpact on overall latency, encryption and secure data transfer to name one.

6.4 Future Work

This thesis seems to have created more questions than it answers and many of thesequestions were unknown at the project start. The future work lies partly in answer-ing these questions of performance stated in the previous section. More importantis perhaps to continue working on the product specification to determine what isreally sought, which this thesis has helped exploring.

The questions of safety, security and scalability is essential to address before areal product specification can be made.

The VCI+ is not limited to serving only as a diagnostics tool with the functionality

55

CHAPTER 6. RETROSPECT

supported in today’s systems. Further research areas include all the comprehensivetopics mentioned in the background, specifically how this type of tool can best beused to facilitate those services.

This prototype platform serves as a great tool for testing ideas of new function-ality and there are certainly many applications we have not thought of in which itcan be handy.

56

Bibliography

[1] Accenture. In-vehicle infotainment "a view of the european market-place", 03 2010. URL http://www.accenture.com/us-en/Pages/insight-in-vehicle-infotainment-european-marketplace-summary.aspx.

[2] Mattias Nyberg. Ansökan inom ffi - transporteffektivitet, iris - prognostiseratindividuellt underhållstöd grundat på systematiserad kunskap om komponen-ters tillstånd i inhomogena fordonsflottor. Internal Scania document, 2010.

[3] Mattias Nyberg. Ansökan inom ffi – transporteffektivitet, guided integratedremote and workshop diagnostics. Internal Scania document, 2013.

[4] SCANIA CV AB. Sustainability - reducing vehicle impacts, 2013. URL http://www.scania.com/sustainability/towards-sustainable-transport/reducing-vehicle-impacts/road-safety/.

[5] Steve Corrigan. Introduction to the controller area network (can). Technicalreport, Texas Instruments, 2002.

[6] Unknown. Bosch can specification version 2.0. Technical report, Robert BoschGmbH, 1991.

[7] On-board diagnostics. Wikipedia. Retrieved 2013-06-19.

[8] Volkswagen AG. Vw service training. Self study programme 315.

[9] Greg Vrana. Analytic technology: Diagnose what ails your auto. EDN, 46(28):37, 2001.

[10] Anders Björkman. Architecture for a remote diagnosis system used in heavy-duty vehicles. Master’s thesis, Linköping University, 2008.

[11] Tore Risch Mathias Johanson, Lennart Karlsson. Relaying controller area net-work frames over wireless internetworks for automotive testing applications.Systems and Network Communications, pages 1–5, 2009. doi: 10.1109/ICSNC.2009.68.

57

http://www.accenture.com/us-en/Pages/insight-in-vehicle-infotainment-european-marketplace-summary.aspx



http://www.scania.com/sustainability/towards-sustainable-transport/reducing-vehicle-impacts/road-safety/



BIBLIOGRAPHY

[12] Syed Masud Mahmud Irina Hossain. Analysis of a secure software upload tech-nique in advanced vehicles using wireless links. In Intelligent TransportationSystems Conference, pages 1010–1015, 2007. doi: 10.1109/ITSC.2007.4357797.

[13] Moon Ho Hwang Irina Hossain, Syed Masud Mahmud. Performance evaluationof mobile multicast session initialization techniques for remote software uploadin vehicle ecus. In Vehicular Technology Conference Fall, pages 1–5, 2010. doi:10.1109/VETECF.2010.5594419.

[14] Ilya Grigorik. High Performance Browser Networking. O’Reilly, 2012.

[15] Jakob Nielsen. Usability Engineering. Morgan Kaufmann, 1993.

[16] Brad A. Myers. The importance of percent-done progress indicators forcomputer-human interfaces. pages 11–17, 1985. doi: 10.1145/1165385.317459.

[17] Eric Savitz. Ericsson: 85 Forbes, 2012. URL:http://www.forbes.com/sites/ericsavitz/2012/06/05/ericsson-sees-85-global-3g-wireless-coverage-by-2017-50-4g-coverage.

[18] 3g. Wikipedia. Retrieved 2013-06-20.

[19] P. Arlos and M. Fiedler. Influence of the packet size on the one-way delayon the down-link in 3g networks. In Wireless Pervasive Computing (ISWPC),2010 5th IEEE International Symposium on, pages 573–578, 2010. doi: 10.1109/ISWPC.2010.5483732.

[20] Lydia Parziale et. al. Tcp/ip tutorial and technical overview. Technical report,IBM, 2006.

[21] http://www.uppaal.org/. Webpage. Retrieved 2013-06-27.

[22] Kim G. Larsen Gerd Behrmann, Alexandre David. A tutorial on uppaal 4.0.Technical report, Aalborg University, 2006.

[23] Timed automata and tctl. http://www.seas.upenn.edu/ lee/09cis480/lec-part-2-ta-tctl-zones-il.pdf. Retrieved 2013-06-29.

[24] Insup Lee. Uppaal tutorial. http://www.seas.upenn.edu/ lee/09cis480/lec-part-4-uppaal-input.pdf. Retrieved 2013-06-20.

[25] Mark Bradley, Franck Cassez, Ansgar Fehnker, Thomas Given-Wilson, andRalf Huuck. High performance static analysis for industry. Electronic Notes inTheoretical Computer Science, 289:3 – 14, 2012. ISSN 1571-0661. doi: http://dx.doi.org/10.1016/j.entcs.2012.11.002. URL http://www.sciencedirect.com/science/article/pii/S1571066112000722. <ce:title>Third Workshopon Tools for Automatic Program Analysis (TAPAS’ 2012)</ce:title>.

58

http://www.sciencedirect.com/science/article/pii/S1571066112000722

http://www.sciencedirect.com/science/article/pii/S1571066112000722

[26] G. Chatzieleftheriou and P. Katsaros. Test-driving static analysis tools insearch of c code vulnerabilities. In Computer Software and Applications Con-ference Workshops (COMPSACW), 2011 IEEE 35th Annual, pages 96–103,2011. doi: 10.1109/COMPSACW.2011.26.

[27] Splint manual. http://www.splint.org/manual/, . Retrieved 2013-06-29.

[28] . http://www.cs.virginia.edu/pipermail/splint-discuss/2005-January/000531.html.

[29] P. Burden et. al. Misra-c:2004, guidelines for the use of the c language incritical systems. Technical report, The Motor Industry Software ReliabilityAssociation, 2004.

[30] Marc Kleine-Budde. Socketcan -the official can api of the linux kernel.iCC, 2012. URL: http://www.can-cia.org/fileadmin/cia/files/icc/13/kleine-budde.pdf.

[31] URL http://www.ibm.com/developerworks/library/l-posix1/index.html. Retrieved 2013-06-30.

[32] URL http://www.ibm.com/developerworks/library/l-python5/index.html. Retrieved 2013-06-30.

59

http://www.ibm.com/developerworks/library/l-posix1/index.html

http://www.ibm.com/developerworks/library/l-posix1/index.html

http://www.ibm.com/developerworks/library/l-python5/index.html

http://www.ibm.com/developerworks/library/l-python5/index.html

Appendix A

Appendix A

61

APPENDIX A. APPENDIX A

Figure A.1. Graphical user interface of the VCI+ diagnostic application62

Appendix B

Appendix B

********************************************************************* Errors due to incompatible types********************************************************************

can_RXhandling.c:65:12: Operands of >= have incompatible types (__u8, int):FC_handler->separationTime_min >= 0x00

can_RXhandling.c:65:58: Operands of <= have incompatible types (__u8, int):FC_handler->separationTime_min <= 0x7F

can_RXhandling.c:66:33: Incompatible types for * (__u8, int):FC_handler->separationTime_min * 1000

To make char and int types equivalent, use +charint.can_RXhandling.c:68:16: Operands of >= have incompatible types (__u8, int):

FC_handler->separationTime_min >= 0xF1can_RXhandling.c:68:62: Operands of <= have incompatible types (__u8, int):

FC_handler->separationTime_min <= 0xF9can_RXhandling.c:69:9: Assignment of __u8 to __u32:

FC_handler->sleepTime = FC_handler->separationTime_min

can_RXhandling.c:126:9: Assignment of __u8 to unsigned int:data_strlen = (CAN_frame->data[0] << 8)

can_RXhandling.c:136:35: Format argument 1 to sprintf (%.4d) expects intgetsunsigned int: data_strlen + 8 + 2 + data_strlen / 16

To ignore signs in type comparisons use +ignoresignscan_RXhandling.c:136:32: Corresponding format code

main.c:429:2: Assignment of int to __u8: CAN_frame2.data[0] = 0x02main.c:430:2: Assignment of int to __u8: CAN_frame2.data[1] = 0x3Emain.c:431:2: Assignment of int to __u8: CAN_frame2.data[2] = 0x02can_RXhandling.c:152:13: Operands of == have incompatible types (__u8,

int):CAN_frame->data[0] == 0x03

63

APPENDIX B. APPENDIX B

can_RXhandling.c:152:43: Operands of == have incompatible types (__u8,int):

CAN_frame->data[1] == 0x7Fcan_RXhandling.c:152:73: Operands of == have incompatible types (__u8,

int):CAN_frame->data[3] == 0x78

can_RXhandling.c:167:20: Incompatible types for * (__u8, int):(CAN_frame->data[0]) * 2

can_RXhandling.c:168:45: Format argument 1 to printf (%d) expects int gets__u8: CAN_frame->data[0]

can_SEThandling.c:79:5: Assignment of int to __u8: CAN_frame->can_dlc = 8

can_TXhandling.c:56:2: Assignment of int to __u8: CAN_frame->data[0] = len/ 2

can_TXhandling.c:189:5: Assignment of int to __u8:CAN_frame->data[0] = CF_number

can_TXhandling.c:226:8: Operands of > have incompatible types (__u8, int):FC_handler->blockSize > 0

print_handling.c:25:18: Format argument 1 to printf (%2x) expects unsignedint

gets __u8: CAN_frame->data[i]

print_handling.c:40:17: Format argument 1 to printf (%x) expects unsignedint

gets __u8: CAN_frame->data[i]

can_RXhandling.c:155:9: Assignment of int to unsigned int:writepos = receive_FF(TxRxBuffer, CAN_frame, CANsock_pollptr,

CAN_socket)can_RXhandling.c:156:16: Return value type unsigned int does not match

declaredtype int: writepos

Type of parameter is not consistent with corresponding code in formatstring.

(Use -formattype to inhibit warning)

can_RXhandling.c:175:35: Format argument 1 to sprintf (%.4d) expects intgets

unsigned int: data_strlen + 2 + 8

can_RXhandling.c:196:9: Return value type unsigned int does not matchdeclared

type int: writepos

64

can_RXhandling.c:210:28: Format argument 1 to sscanf (%4d) expects int *gets

unsigned int *: &data_strlen

can_RXhandling.c:222:62: Format argument 1 to printf (%d) expects int getsunsigned int: frameiter

can_RXhandling.c:222:83: Format argument 3 to printf (%d) expects int getsunsigned int: data_strlen

can_RXhandling.c:229:37: Format argument 1 to printf (%d) expects int getsunsigned int: frameiter

can_TXhandling.c:99:39: Format argument 1 to sprintf (%.3x) expectsunsigned

int gets int: RxStringLength

print_handling.c:24:11: Operands of < have incompatible types (int,arbitraryunsigned integral type): i < sizeof((CAN_frame->data)) /sizeof((CAN_frame->data[0]))

print_handling.c:39:11: Operands of < have incompatible types (int,arbitraryunsigned integral type): i < sizeof((CAN_frame->data)) /sizeof((CAN_frame->data[0]))

main.c:123:5: Assignment of arbitrary unsigned integral type to int:len_unix = ((size_t)(((struct sockaddr_un *)0)->sun_path) +strlen((&adr_unix)->sun_path))

unix_socket_handler.c:31:64: Format argument 1 to printf (%d) expects intgets

unsigned int: length_of_message

unix_socket_handler.c:46:24: Format argument 1 to sprintf (%.4d) expectsint

gets unsigned int: length_of_message

can_TXhandling.c:48:5: Assignment of size_t to int: len = strlen(arg)To allow arbitrary integral types to match any integral type, use+matchanyintegral.

unix_socket_handler.c:29:2: Assignment of size_t to unsigned int:length_of_message = strlen(buffer)

unix_socket_handler.c:33:27: Function send expects arg 3 to be size_t getsunsigned int: length_of_message

unix_socket_handler.c:45:2: Assignment of size_t to unsigned int:

65


length_of_message =strlen(global_error_message)

unix_socket_handler.c:48:27: Function send expects arg 3 to be size_t getsunsigned int: length_of_message

main.c:316:76: Function setsockopt expects arg 5 to be socklen_t getssize_t:

sizeof((CAN_filter))

can_RXhandling.c:65:12: Comparison of unsigned value involving zero:FC_handler->separationTime_min >= 0x00

An unsigned value is used in a comparison with zero in a way that iseither a

bug or confusing. (Use -unsignedcompare to inhibit warning)

************************************************************************ Errors due to ignored return value***********************************************************************

can_RXhandling.c:185:9: Return value (type int) ignored:data2string(TxRx...

can_RXhandling.c:210:5: Return value (type int) ignored:sscanf(TxBuffer,...

can_SEThandling.c:59:5: Return value (type int) ignored:sscanf(filter_se...

can_SEThandling.c:77:5: Return value (type int) ignored: sscanf(can_id, ...can_RXhandling.c:141:9: Return value (type int) ignored:

data2string(TxRx...can_TXhandling.c:67:6: Return value (type int) ignored: sscanf(single_da...can_TXhandling.c:74:2: Return value (type int) ignored: printSentFrame(C...can_TXhandling.c:103:9: Return value (type int) ignored:

sscanf(first_dat...can_TXhandling.c:108:5: Return value (type int) ignored:

printSentFrame(C...error_handling.c:56:4: Return value (type int) ignored: send_unix_error(...error_handling.c:61:4: Return value (type int) ignored: send_unix_error(...error_handling.c:66:4: Return value (type int) ignored: send_unix_error(...error_handling.c:72:4: Return value (type int) ignored: send_unix_error(...error_handling.c:77:4: Return value (type int) ignored: send_unix_error(...

66

error_handling.c:82:4: Return value (type int) ignored: send_unix_error(...error_handling.c:87:4: Return value (type int) ignored: send_unix_error(...can_TXhandling.c:130:9: Return value (type int) ignored: sscanf(fc_frame

...can_TXhandling.c:137:5: Return value (type int) ignored:

printSentFrame(C...main.c:117:5: Return value (type int) ignored: unlink(pth_unix)main.c:145:2: Return value (type int) ignored: ioctl(CAN_socket...main.c:148:5: Return value (type int) ignored: setsockopt(CAN_s...main.c:230:3: Return value (type int) ignored: sscanf(RxBuffer,...main.c:345:5: Return value (type int) ignored: close(CAN_socket)main.c:346:17: Return value (type int) ignored: close(sck_unix)main.c:347:17: Return value (type int) ignored: unlink(pth_unix)main.c:291:4: Return value (type int) ignored: pthread_mutex_lo...main.c:306:5: Return value (type int) ignored: set_CAN_filter(s...main.c:358:5: Return value (type int) ignored: pthread_mutex_un...main.c:372:5: Return value (type int) ignored: pthread_mutex_un...main.c:382:5: Return value (type int) ignored: pthread_mutex_un...main.c:393:6: Return value (type int) ignored: setsockopt(CAN_s...main.c:444:3: Return value (type unsigned int) ignored: sleep(1)main.c:450:3: Return value (type int) ignored: pthread_mutex_lo...main.c:455:4: Return value (type int) ignored: set_CAN_ID(Threa...main.c:463:3: Return value (type int) ignored: pthread_mutex_un...main.c:464:3: Return value (type unsigned int) ignored: sleep(4)can_TXhandling.c:231:9: Return value (type int) ignored:

send_CF(RxBuffer...can_TXhandling.c:193:13: Return value (type int) ignored:

sscanf(cf_datafr...can_TXhandling.c:196:9: Return value (type int) ignored:

usleep(FC_handle...

********************************************** Errors due to missing c99 compatibility*********************************************

can_TXhandling.c:67:46: Unrecognized format code: %2hhxcan_TXhandling.c:103:48: Unrecognized format code: %2hhxcan_TXhandling.c:130:40: Unrecognized format code: %2hhxcan_TXhandling.c:193:48: Unrecognized format code: %2hhxprint_handling.c:56:44: Unrecognized format code: %.2hhx

********************************************** Overflow warnings for sprintf*********************************************

67


error_handling.c:33:5: Buffer overflow possible with sprintf. Recommendusing

snprintf instead: sprintferror_handling.c:40:5: Buffer overflow possible with sprintf. Recommend

usingsnprintf instead: sprintf

can_RXhandling.c:136:9: Buffer overflow possible with sprintf. Recommendusing

snprintf instead: sprintfcan_TXhandling.c:99:5: Buffer overflow possible with sprintf. Recommend



snprintf instead: sprintfcan_RXhandling.c:177:6: Buffer overflow possible with sprintf. Recommend



snprintf instead: sprintfprint_handling.c:56:9: Buffer overflow possible with sprintf. Recommend


unix_socket_handler.c:46:2: Buffer overflow possible with sprintf.Recommend

using snprintf instead: sprintf

********************************************************* Errors due to boolean operators on nonboolean types********************************************************

main.c:257:7: Operand of ! is non-boolean (int): !strncmp(splitter, "ext",3)

main.c:260:12: Operand of ! is non-boolean (int): !strncmp(splitter,"kwp", 3)

main.c:263:12: Operand of ! is non-boolean (int): !strncmp(splitter,"str", 3)

can_routines.c:178:7: Operand of ! is non-boolean (int):!poll(UNIXsock_pollptr, 1, 0)

can_RXhandling.c:40:8: Test expression for if not boolean, type int:poll(CANsock_pollptr, 1, 5)

can_RXhandling.c:101:8: Test expression for if not boolean, type int:poll(CANsock_pollptr, 1, 5)

can_RXhandling.c:114:8: Test expression for if not boolean, type__u8:CAN_frame->data[0] & 0x10

can_RXhandling.c:117:12: Test expression for if not boolean, type__u8:CAN_frame->data[0] & 0x20

68

can_RXhandling.c:236:12: Test expression for if not boolean, typeint:poll(CANsock_pollptr, 1, 5)

can_TXhandling.c:52:5: Test expression for if not boolean, type int: len %2

can_TXhandling.c:181:34: Variable recursive_call initialized to typeboolean,expects char: false

can_TXhandling.c:230:9: Assignment of boolean to char: recursive_call =true

can_TXhandling.c:238:9: Assignment of boolean to char: recursive_call =true

can_TXhandling.c:242:5: Assignment of boolean to char: recursive_call =false

can_TXhandling.c:223:9: Operands of == have incompatible types (char,boolean): recursive_call == false

The operand of a boolean operator is not a boolean. Use +ptrnegate toallow ! to be used on pointers. (Use -boolops to inhibit warning)

main.c:297:7: Test expression for if not boolean, type int:strncmp(splitter, id_holder, 8)

main.c:448:8: Test expression for while not boolean, type int: 1

*************************************************************************** Errors due to usuage of noninitialized variables**************************************************************************

main.c:177:23: Passed storage &child1 not completely defined:pthread_create (&child1, ...)

main.c:177:32: Null storage passed as non-null param:pthread_create (..., NULL, ...)

main.c:257:15: Possibly null storage splitter passed as non-null param:strncmp (splitter, ...)

main.c:250:14: Storage splitter may become null

main.c:297:15: Possibly null storage splitter passed as non-null param:strncmp (splitter, ...)

main.c:281:15: Storage splitter may become nullmain.c:336:28: Passed storage &res not completely defined:

pthread_join (..., &res)main.c:354:29: Possibly null storage splitter passed as non-null param:

state2_routine (splitter, ...)main.c:322:15: Storage splitter may become null

main.c:354:72: Passed storage FC_handler contains 4 undefined fields:flowStatus, blockSize, separationTime_min, sleepTime

main.c:354:85: Passed storage CANsock_pollptr[0] contains 1 undefinedfield:

reventsmain.c:369:29: Possibly null storage splitter passed as non-null param:

69


state3_routine (splitter, ...)main.c:322:15: Storage splitter may become null

main.c:369:72: Passed storage UNIXsock_pollptr[0] contains 1 undefinedfield:

reventsmain.c:393:53: Null storage passed as non-null param:

setsockopt (..., NULL, ...)

main.c:148:52: Null storage passed as non-null param:setsockopt (..., NULL, ...)

***************************************************************** Errors from code examples in linux posix manual****************************************************************

main.c:120:5: Assignment of int to char:strncpy(adr_unix.sun_path, pth_unix, sizeof(adr_unix.sun_path) -1)[sizeof(adr_unix.sun_path) - 1] = 0

main.c:124:52: Function bind expects arg 3 to be socklen_t gets int:len_unix

main.c:149:59: Function bind expects arg 3 to be socklen_t gets size_t:sizeof((CAN_addr))

main.c:177:45: Cast from non-function pointer type (void *) to functionpointer([function (struct thread_data *) returns void *] *):(void *)&tester_present

A pointer to a function is cast to (or used as) a pointer to void (orvice

verse). (Use -castfcnptr to inhibit warning)

main.c:177:38: Function pthread_create expects arg 3 to be [function (void*)

returns void *] * gets void *: (void *)&tester_present

can_routines.c:116:57: Null storage passed as non-null param:setsockopt (..., NULL, ...)

70

main.c:469:8: Null storage returned as non-null: (NULL)Function returns a possibly null pointer, but is not declared using/*@null@*/ annotation of result. If function may return NULL, add

/*@null@*/annotation to the return value declaration. (Use -nullret to inhibit

warning)

**************************************************************************** MISC errors***************************************************************************

main.c:50:59: Global global_condition_var.__data.__mutex initialized tonull

value: global_condition_var.__data.__mutex = (void *)0

error_handling.c:22:10: Argument to exit has implementation definedbehavior: 1

The argument to exit should be 0, EXIT_SUCCESS or EXIT_FAILURE (Use-exitarg

to inhibit warning)

main.c:166:5: Array element poller[0] used before definitionAn rvalue is used that may not be initialized to a value on some

executionpath. (Use -usedef to inhibit warning)

main.c:442:8: Suspected infinite loop. No value used in loop test(Thread_data, Thread_data->new_id) is modified by test or loop body.

This appears to be an infinite loop. Nothing in the body of the loop orthe

loop test modifies the value of the loop test. Perhaps the specificationof a

function called in the loop body is missing a modification. (Use-infloops to

inhibit warning)

main.c:469:8: Unreachable code: return (NULL)This code will never be reached on any possible execution. (Use

-unreachableto inhibit warning)

error_handling.h:83:6: Variable exported but not used outsideerror_handling:

71


global_error_messageA declaration is exported, but not used outside this module. Declaration

canuse static qualifier. (Use -exportlocal to inhibit warning)

main.c:47:7: Function exported but not used outside main: tester_presentmain.c:470:1: Definition of tester_present

main.c:49:17: Variable exported but not used outside main:global_write_mutex

72

Appendix C

Appendix C

main.c: (in function main)main.c:188:45: Cast from non-function pointer type (void *) to function

pointer([function (struct thread_data *) returns void *] *):(void *)&tester_present

A pointer to a function is cast to (or used as) a pointer to void (orvice

verse). (Use -castfcnptr to inhibit warning)main.c:388:27: Passed storage &res not completely defined:

pthread_join (..., &res)Storage derivable from a parameter, return value or global is not

defined.Use /*@out@*/ to denote passed or returned storage which need not be

defined.(Use -compdef to inhibit warning)

main.c: (in function tester_present)main.c:531:2: Unreachable code: pthread_exit(NULL)

This code will never be reached on any possible execution. (Use-unreachable

to inhibit warning)error_handling.h:47:6: Variable exported but not used outside

error_handling:global_error_message

A declaration is exported, but not used outside this module. Declarationcan

use static qualifier. (Use -exportlocal to inhibit warning)

73

remote diagnostics of heavy trucks through telematics694754/fulltext01.pdf · remote diagnostics of...

Documents