Master Thesis Ketan Bavalia

7/25/2019 Master Thesis Ketan Bavalia

1/89

Technische Universitt Chemnitz

Faculty of Computer Science

Master Thesis

CONCEPT AND IMPLEMENTATION OF A UNIVERSAL

UDS API FOR MODULAR USE IN TEST

ENVIRONMENTS FOR VEHICLE COMMUNICATION

TESTS

Masters of Science in Automotive Software Engineering

Prof. Dr. Wolfram Hardt Dr. Ariane Heller

Professor Professor

Supervisor 1 Supervisor 2

MSc. Stefan Bogner

Supervisor at Bertrandt Ingenieurbro GmbH


2/89

Declaration

I declare that I have prepared the master thesis "Concept and implementation of a universal

UDS API for modular use in test environments for vehicle communication tests" without

illegal help. I also declare that contributions by other authors which are used in the thesisor led to the ideas behind the thesis are properly referenced in written form.

By respecting the data protection policy of Bertrandt Ingenieurbro GmbH, no confidential

content of Bertrandt Ingenieurbro GmbH is being used in this thesis work.

I am aware that a master thesis, developed under guidance, is part of the examination and

may not be commercially used or transferred to a third party.

Ingolstadt, June 11, 2015 Ketan Bavalia


3/89

Lock Flag

This master thesis contains confidential information and data. Publication, release or dupli-

cation in parts or in the whole without the written consent of the company is not permitted.

Furthermore, disclosure of the information to anyone other than the examination board oreditors is not authorized.

Ketan BavaliaIngolstadt, June 11, 2015


4/89

Acknowledgement

First of all, I am grateful to my Guru Pramukh Swami Maharaj for everything good happenin my life. I would like to express my gratitude to my Prof. Dr. Wolfram Hardt and Dr.Ariane Heller from Technische Universitt Chemnitz for the support and guidance on the

way of master thesis.

I consider it an honour to work with Mr. Stefan Bogner from Bertrandt AG, who hasintroduced me to the topic. It is with immense gratitude that I acknowledge his support,help, useful comments, remarks and engagement through the learning process of this masterthesis.

I am indebted to many colleagues and friends who have technically supported me with newideas and suggestions to make my work better. A special thanks to Mr. Marc Schilhaneck.I thank Mr. Christian Gehrke for sharing insights of his work which was related to myresearch work.

I would like to thank my loved ones and my parents, who have supported me throughoutentire process by keeping me passionate for my goal. I will be grateful for their love andblessings.

Thank you.


5/89

Abstract

The networking of control devices is well advanced in a modern automobile. To ensuresecure communications with each other and to prevent mistakes due to communication error,protocol tests are performed at the physical and data link layer level. In a modern car the

diagnosis of the electronic devices (e.g. reading/deleting fault memory entries) is done with astandardized communication protocol (UDS - Unified Diagnostic Services). Modern controlunits have this diagnostic capabilities to detect this communication error among others.This data is provided for a guided troubleshooting the vehicle via a defined interface. In thiscommunication test detection mechanisms are specifically stimulated and read afterwards.In order to read or delete these entries, a diagnosis query is performed on the basis of thediagnostic protocol UDS.

The diagnostic requests are currently performed with a diagnostic service of bus analysissoftware Vector CANoe. This service requests can be performed directly on CAN but forthe diagnosis of other bus systems a software gateway is used. The maintenance required and

the error rate of the software gateways is very high and should be replaced in the future.Furthermore, additional bus systems can be integrated only with great effort. Therforethe main aim of the master thesis was to develop a concept for univesal UDS API andafterwards implementation of that concept using CAPL programming for modular use intest environments for vehicle communication testing.


6/89

Contents

Abstract iv

1 Introduction 11.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Structure of master thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Basics 52.1 Vehicle networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 CAN Control Area Network . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 ISO-Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.4 FlexRay TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Overview on automotive diagnosis . . . . . . . . . . . . . . . . . . . . 182.2.2 UDS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 UDS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.4 Open Diagnostic Data Exchange . . . . . . . . . . . . . . . . . . . . . 26

3 State of the art 28

4 Concept 324.1 Modification of the ISO/OSI model . . . . . . . . . . . . . . . . . . . . . . . . 324.2 System Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Modular design of the API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4 Concept realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Implementation 425.1 Software component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1 CANoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.1.2 CAPL Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.3 Structure of a CAPL program. . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3 Implementation of the ISOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4 FRTP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5 Interaction of APIs functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.6 Documenting API using Doxygen . . . . . . . . . . . . . . . . . . . . . . . . . 61

v


7/89

6 Validation 636.1 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2.1 Unexpected Frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.2.2 Flow Control parameter test. . . . . . . . . . . . . . . . . . . . . . . . 68

6.2.3 Timeout behaviour test . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2.4 FlexRay Transport Protocol Test . . . . . . . . . . . . . . . . . . . . . 73

7 Summary and future work 757.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

List of abbreviations 77

List of Figures 78

List of Tables 80

Bibliography 81


8/89

1 Introduction

This chapter goes for presenting a reasonable understanding of the purpose for the devel-opment of the master thesis topic Concept and implementation of a universal UDS APIfor modular use in test environments for vehicle communication tests. It gives a brief ideaabout the organization of the thesis. Knowing the problem statement and the goal of thethesis, it also gives an agreeable understanding of the category of the master thesis comesdown under.

1.1 Motivation

Today diagnostics are having a fundamental impact from designing through productionto service. In last few years vehicle diagnostics is experiencing a fast development. Theamount of Electronic Control Units (ECUs) in cars has been rising gradually and is closing100 control units in a vehicle. At the same time, the unpredictability and the capacitiesof an ECU and vehicle system is also increasing fundamentally. Test and verification ofdiagnostic and control functions are important to certify that diagnostic communicationworks reliably.

The growth and presentation of new diagnostic concepts and diagnostic solutions offer sub-

stantial potential for automotive Original Equipment Manufacturers (OEMs) and suppliersfor realizing efficiency. Electronic Control Unit (ECU) is one of the most critical elements inthe automotive area (or in todays vehicle). Thus, without a diagnostic standard, it is hardto calibrate and maintain the ECUs because only the developers have expert knowledge oftheir ECUs [UDSP].

Implementations of the diagnostics protocol varies from OEM to OEM. In spite of such awide differences, all ECUs are obliged to become suitable for common diagnostics standardsso they demonstrate the same conduct and give regular interfaces.

For that the developer needs to develop a system that assists large portion of the diagnostic

standard defined that called the Unified Diagnostic Services (UDS) protocol. UDS protocolwas characterized by the International Organization for Standardization (ISO) standard incontext to support different diagnostics standard. [ASOF] Diagnostics communication willbe utilized when exact information is essential or it permits a basic and reasonable accessto the black-box ECU.

At last diagnostics is connected differently in the technology area, development and pro-duction stage in a few applications, whether they be in development of communications, of

1


9/89

1.2. PROBLEM STATEMENT CHAPTER 1. INTRODUCTION

ECU functions, of flash functions or in Hardware-in-the-Loop (HiL) and in the integrationof ECUs.

1.2 Problem Statement

A gateway receives CAN frame from tester and transmits this frame to the target bu andresponses are transmitted from the ECU to the tester via gateway in the reverse way asshown in figure1.1. There may be some frame change happen in the gateway for example

Fig.: 1.1: Software gateway routing the diagnostics request between CAN bus and target bus(FlexRay)

length of the frame by adding or removing the padding bytes or conversion of CAN identifierto the FlexRay target address.

For the diagnostics of the FlexRay ECU, first of all diagnostic services must send to thesoftware gateway from the tester. Then software gateway has to route the packet to theFlexRay target address as shown below in figure 1.2. Therefore software gateway convertsCAN ID to the FlexRay source address and target address using conversion formula. Becauseof this conversion takes place between CAN ID and FlexRay addresses, FlexRay providesexpected result with delay. Consequently sometime ECU will not give an exact result withgateway such as time out error due to gateway delay.

2


10/89

1.3. STRUCTURE OF MASTER THESIS CHAPTER 1. INTRODUCTION

Fig.: 1.2: Time delay occurs during gateway transfers frame

1.3 Structure of master thesis

This master thesis subdivides mainly into two parts: on the one hand, the thesis aims fora concept development of the universal UDS API. On the other hand, to implement theselected UDS services using a developed concept. Since this thesis does not fall under thecategory of a formal proof, the reliability of the concept and implementation is proven byprocessing of various test cases with focus on respective test criteria. Hence this masterthesis falls under concept development and implementation of concept.

This master thesis is divided into several chapters, which handle different topics. The struc-ture of the thesis is as follows:

The first chapter gives a brief introduction, motivation and objectives of the thesis. Addi-tionally a short explanation about problem statement. It also gives a view about which typeof this thesis work.

The second chapter provides a prerequisite knowledge to understand the work in later chap-ters. It explains the fundamentals of the modern bus architecture and bus protocols. Thechapter further gives the explanation of the transport protocol and a brief introduction tothe Open Diagnostic Data Exchange (ODX) file. It also talks about the diagnostic pro-tocol applied in the todays vehicle. This section represents how diagnostics performed inthe vehicle. And Unified Diagnostic Services (UDS) protocol explained in more detail withdiagnostic request and response message structure.

Chapter three gives the state of the art or the current industry scenario/problems. It providesan explanation of how currently diagnostic request performed by software gateway.

Chapter four provides the key architectural and implementation background informationfor concept development and structure of the modular UDS Application Program Interface(API).

In chapter five, ISO-TP implementation and FlexRay TP implementation procedures arediscussed. It also gives an overview of the Vector CANoe tool and techniques.

3


11/89

1.3. STRUCTURE OF MASTER THESIS CHAPTER 1. INTRODUCTION

Chapter six covers the different test cases like unexpected frames, flow control parametertest and timeout behaviour test for validation of transport protocol implementation modulein CAPL API. These test cases are explained with screenshots from CANoe trace window.

The final chapter discusses the summary of the thesis and ideas on further research possi-

bilities are mentioned.

The chapter/headings are divided in up to three levels, e.g. 2.3.4. First usage of an abbre-viation is written along with its full form. The caption of a figure or a table briefly explainsit.

4


12/89

2 Basics

The following chapter provides the necessary fundamentals for the thesis. For better under-standing of the thesis and following topic some basics required on the CAN protocol, FlexRayprotocol, ISO-TP, FlexRay-TP and UDS protocol which are part of my thesis work. Theseare briefly explained in the following chapter. At the end of the chapter brief introduction ofOpen Diagnostic Data Exchange (ODX) format which gives an overview about the processchain with ODX database.

2.1 Vehicle networking

The first networking vehicles appeared in the early 1990s on the market, all control deviceswere connected via a single bus system. With the addition of other electronic systemsand as more and more control units have been installed the bus load increased and it wasnecessary to integrate additional buses into the vehicle. The bus architecture was more orless resulting from the desire for the shortest possible wiring and random installation of thecontrol devices. After the systems have become increasingly prone to error by the collisionin ECU communication and the increasing complexity, adopted from the 2000s a structuredarchitecture, in which the ECUs are grouped according to application area and the individualbus systems were coupled together via a central gateway. This architecture has survived until

today. Figure2.1 schematically illustrates the bus architecture of a vehicle.

In a modern vehicle a number of different bus system is used. The mentioned bus systems areCAN (Controller Area Network), FlexRay, LIN (Local Interconnect Network) and MOST(Media Oriented Systems Transport). Each of these systems has been designed for a specialcase of application. The essential part of this thesis is CAN bus and FlexRay, which areexplained in Chapter2.1.1in more detail. The other bus systems are discussed only brieflyhere.

LIN is a low-cost bus system and was developed as a low cost alternative to CAN. It ismainly used to connect sensors and actuators to a control device. In this case, the controller

acts as a bus master and all other members as slaves. As can be seen in figure2.1, is thebus master himself is usually associated with another bus so that LIN is designed as a puresub-bus. The maximum data rate from LIN is 20 kbit/s in comparison to other systems verylow. Therefore LIN is mainly used in the field of comfort electronics, where no high datarates are required, for example for seat and door control units [ZiSch].

MOST has been specially developed for the infotainment bus system. Typically, MOSTis used in networking radio, navigation system,telephone, internet connection and driver

5


13/89

2.1. VEHICLE NETWORKING CHAPTER 2. BASICS

Fig.: 2.1: Modern Vehicle architecture[ZiSch]

information system. In these applications the requirement of real-time capability is less andtransmission security in the foreground, but rather a high data rate. A special feature ofMOST is the ring structure and the optical transmission using optical fibers [ZiSch].

Ethernet is currently used by some car manufacturers (BMW) for diagnostic purposes in

order to connect a diagnostic tester to the gateway of the vehicle (see figure2.1). There arealso efforts to use Ethernet long-term in automobiles, for example, as a substitute for MOSTor FlexRay. Ethernet-based systems are currently still in development and are not availablein production vehicles.

2.1.1 CAN Control Area Network

The CAN bus was one of the first bus that has established over a large area in the automotivesector. CAN was developed to reduce the amount of wiring in the vehicle by Robert Boschand standardized internationally later by ISO ([ISO11898-1] - [ISO11898-5]). CAN definethe layers 1 and 2 (physical layer and data link layer) of the OSI layer model. [ZiSch]

Properties of CAN:

Real time communication is possible

Flexibility in the configuration

Multicast reception with time synchronization

Multimaster transmission

6


14/89


Error detection and signaling

System wide data consistency

Layers of CAN

Physical LayerPhysical layer mainly concern with physical signaling specially bit timing, bit encoding andsynchronization. It is also responsible for physical medium connection and interfaces. InCAN up to 1 Mbit/s for high-speed CAN (CAN-C, ISO standard 11898-2) or 125 Kbit/s witha low speed CAN bus (CAN-B, ISO 11898-2) can be achieved. Both types of bus use twotwisted wires (CAN high (CAN-H) and CAN Low (CAN-L)) and identify the current levelby differential voltage between the individual wires. That result in a higher susceptibility tointerference is achieved. In high speed CAN a difference of 2 volts corresponds to a dominantsignal. If both lines have the same voltage, this corresponds to recessive signal. The lowspeed CAN uses different voltage levels for transmission. Thereby the incompatibility can

be explained with high speed CAN. A dominant signal corresponds to the low speed CAN avoltage difference of 2.2 V. A difference of 5 V corresponds to a recessive signal. [ZiSch]

Data Link Layer: Bus access and arbitrationCarrier Sense Multiple Access/Collision Resolution (CSMA/CR) method is used for CANbus access. A CAN message has no source or target address, but unique message identifiers.CAN messages are broadcast so each participant can in principle receive any message. Eachnode is free to start the transmission of its message. The message begins with start offrame bit followed by an identifier. At the same time, it is checked whether the signal levelon the bus corresponding to the bit being sent. If this is not the case, it means that atthe same time another node sends a message with a higher priority. When several nodes

start the transmission, the system responds by applying wired-and arbitration to stop theconflicts over bus access. Based on the message identifier, a CAN node can decide whetherthe message with the highest priority (lowest binary value of the identifier) or not. Thehighest priority message is assigned first bus access. The process of deciding which messageis sent on the bus is called arbitration. [ZiSch]

Figure 2.2 shows an example of the process of arbitration. ECU 1 and ECU 2 transmitsimultaneously. Until the sixth bit both message identifiers are the same, the sixth bit isdominant at ECU 1 and recessive at ECU 2. The message of ECU 1 is therefore higherpriority. ECU 2 detects this by comparing the signal level on the bus with the transmittedbit and terminates the transfer.

CAN message format

For data transfer on the CAN bus, a message frame is made. It includes the data to betransmitted in a characterized sequence. Figure 2.3 illustrates the structure of a CANframe.

7


15/89


Fig.: 2.2: Bit arbitration [ZiSch]

Fig.: 2.3: CAN Frame structure [ZiSch][SPAS]

HeaderThe start bit marks the beginning of a new frame and is always dominant. The messageidentifier (priority of the message) is amounts to 11 bits in the standard format or 29 bits

in the extended format. After that 7 control bits are sent that contains the message length(Data length Code (DLC)). The header has an overall length of 19 or 37 bits depending onwhich type of message identifier is used.[ZiSch]

PayloadHere the actual data content of the CAN message is transmitted. A message length can bebetween 0 and 8 bytes. The exact length of the data to be transmitted is previously specifiedin the header as DLC. [ZiSch]

8


16/89


TrailerAfter a payload a Cycle Redundancy Check (CRC) is transmitted with the length of 15 bits.This is used to check whether it has come to bit errors during transmission. Then the ACKslot follows. The receiver acknowledges that the frame is received correctly by sending adominant bit in the ACK slot. Then sender checks whether the message was transmitted

correctly. The conclusion of CAN frame is the End of Frame (EOF) field. It indicates theend of the message and end of bit stuffing. This ACK and EOF field has a length of 10 bits.By combining CRC with ACK and EOF trailer results in a total length of 25 bits. [ZiSch]

2.1.2 ISO-Transport Protocol

The ISO 15765-2 standard defines a transport protocol (ISO-TP) that allows a segmentedtransmission of messages [ISOTP11]. The ISO transport protocol is on the fourth layer(transport layer) of the OSI layer model. The CAN-Bus only allows a transfer of 8 bytes ofuser data per frame. The ISO TP defined a transmission method that allows to send up to4095 bytes via the CAN-bus. For this, the messages to be sent are segmented and individual

CAN frames divided[ISO15765-2].

In the following section we focus on transport protocol. After a short introduction, firstconsider the transport protocol for CAN.

Function Overview

This section2.1.2describes the basic functions of the transport protocol for unacknowledgedsegmented/unsegmented data transfer (USDT/UUDT). The following functions must besupported by the transport protocol:

SegmentationThe primary task of the transport protocol is to transfer messages which cannot be trans-mitted as a single Protocol Data Unit (PDU) due to their length. Messages which containmore data than can be transmitted within a single PDU are segmented by means of thetransport protocol and divided into multiple, separate PDUs. This procedure can also beimplemented on the data link layer. The segmentation of the message must then be carriedout in PDUs of the corresponding data link protocol. [VWTP]

Flow controlThe flow control mechanism of the transport protocol is used to configure the sender tomatch the properties of the receiver (timing, available receive buffer, readiness to receive).

[VWTP]

Error detectionThe error detection mechanism of the transport protocol informs the higher-level softwarelayers on the receiver side about the successful or unsuccessful receipt of a message. This pre-vents incorrect or incomplete messages from being forwarded to an application. [VWTP]

9


17/89


Fig.: 2.4: ISO-TP message structure[ZiSch]

ISO-TP Message Structure

ISO-TP defines different types of message. An ISO-TP message is also referred to as Pro-tocol Data Unit. Here four different types of PDU are defined as shown in figure 2.4:

Single Frame (SF) is used when the message length is less than or equal to 7 bytes becausethe first byte is used for Protocol Control Information (PCI). With single frame first fourbits of the PCI byte are set to 0. The four least significant bits of this byte contain the datalength of the payload.

If diagnostic message is bigger than 7 bytes, segmentation is required. A First Frame (FF)indicates the beginning of a segmented transmission. The length of the entire message inthe four least significant bits of the first byte and the entire second byte is specified. Sothere are 12 bits available for the data length (DL) specification. So the valid values of DLare from 8 to 0xFFF (4095) for normal addressing. In addition the header, the first framecontains the first six bytes of the diagnostic message.

10


18/89


The Consecutive Frame (CF) transports the individual segments of a segmented message.The transport protocol on the receiver side assembles all the consecutive frames and transfersthe complete message to the higher level protocol layer after correctly receiving all theconsecutive frame PDUs. On the receiver side the Sequence Number (SN) is used to detectthe errors or to compile the segments. The low nibble (0. . . 3 bits) of the PCI byte indicates

the SN. The valid values are 0 to 0xF.

The Flow Control (FC) frame is sent by the receiving node to transmitting node for flowcontrol of the transmission. The flow control frame contains 3 bytes which together forma PCI. The first byte begins in the upper four bits with value of 3, indicates that there isflow control. In the four least significant bits of the first byte shows a Flow Status (FS).Thus the transmitter to receiver can signal whether a segmented transmission Clear To Send(CTS), Wait or Overflow. The second byte BS stands for Block Size and shows how manyconsecutive frames need to be sent in one block. The last byte STmin shows the minimumseparation time between consecutive frames to be noticed. [ISO15765-2]

An ISO-TP frame is always 8 bytes long and unneeded bytes filled with the padding byte0xAA or 0x55 [VWTP].

Structure of the message transfer

There are two data transfer methods of ISO TP: single frame data transmission and mul-tiple data transmission [VWTP]. The figure2.5 shows the single frame data transmission(Unacknowledged Unsegmented Data Transfer). In a CAN frame, there is a maximum of8 data bytes of user data. The data length of the ISO TP message can reach a maximumof 4095 bytes. If an ISO TP message length exceeds the data length of 8 data bytes, theUDS message must be segmented. The data transfer with segmentation is called multiple

frame transmission (Unacknowledged Segmented Data Transfer). The figure2.6shows theISO-TP multiple frame transmission.

Fig.: 2.5: ISO-TP single frame data transmission[VWTP]

11


19/89


Fig.: 2.6: ISO-TP multiple frame transmission[VWTP]

Error HandlingBoth the transmitter and receiver monitor the data transmission with a timer. The receivermonitors the time required by the transmitter for sending a Consecutive Frames. If thistakes long time, the transmission is aborted and data already transmitted are discarded.Similarly the transmitter monitors the time for the receiver to send the flow control frame.

12


20/89


Again the transmission is aborted and data already transmitted are discarded if a time outis detected. The maximum waiting time for a frame is one second. [VWTP]

In addition to timing errors, errors in the message structure must be recognized. If anerroneous PDU is detected the frame is ignored or if a transmission is in progress, cancelled

it. Possible errors in the message structure are: incorrect sequence number in consecutiveframes, invalid message length, and invalid flow status in the flow control frame or an invalidPDU type. [VWTP]

Unexpectedly arriving frames are always ignored, with the exception of single frame andphysically addressed first frame. Functionally addressed first frame, consecutive frame andflow control are always ignored.[VWTP]

2.1.3 FlexRay

This section will explain the fundamentals of FlexRay.

CAN is suitable for data exchange between electronic control units for most applicationswithin a car, however it has some restraints.

Fig.: 2.7: FlexRay Logo [FLXC]

Latency cannot be predicted due to theevent-driven media access and it is not guar-anteed that a low priority message is sent atall. Moreover, the bandwidth of CAN is lim-ited to 1 Mbit/s. A redundant design whichis mandatory by law for new techniques asX-by-wire (X = Brake, Steer) is not pro-vided as well. These restrictions were main

reason to found the FlexRay Consortium in2000 by BMW, Daimler-Benz, Motorola andPhilips.

Another great feature of FlexRay is a band-width of 10 Mbit/s on two separate chan-nels. The channels can be used to send redundant messages in order to increase the safetyof the system or to double the bandwidth by sending two different messages.

Since FlexRay is a deterministic vehicle bus a node is only allowed to send in its defined timeslots contrary to the event-driven CAN. FlexRay overcomes these restrictions by dividing

the medium into static and dynamic time slots. FlexRay is subdivided into communicationcycles based on a common global time base called Macrotick (MT). The next pages hand astep by step introduction into FlexRay and details on the most important parts.

The figure2.8 illustrates the structure of the four parts of a FlexRay cycle: static (red) anddynamic (green) segment, symbol window (yellow) and Network Idle Time (NIT) (white).The static and dynamic segments are used for communication purposes. Time DivisionMultiple Access (TDMA) grants the media access within the static segment.

13


21/89


A minislot routine is used within the optional dynamic segment. The symbol window andNIT have organizational reasons: the optional symbol window is reserved for transferringsymbols within the network, e.g., the Media Access Test Symbol (MTS) for testing thefunctionality of bus guardians. However, the feature is unused in most current applications.The NIT is mandatory and the bus is silent. As figure2.8 illustrates, the NIT is used for

offset correction in every fourth slot.

FlexRay messages are packed within frames. The rough segmentation is in header, actualpayload and Cyclic Redundancy Code (CRC)-trailer which is visible in the figure2.8. Eachframe is followed by the Channel Idle Delimiter (CID).

static dynamic SW NIT static dynamic SW NIT static dynamic SW NIT static dynamic SW NIT

Cycle [2n+0] Cycle [2n+1] Cycle [2n+2] Cycle [2n+3]

slot

1

slot

2

slot

3

slot

4

slot

n-1

slot

n

header payload trailer CID

gdNumberOfStaticSlots

Static Frame

gdStaticSlot

gdActionPointOffset

n

+1

n

+2

n

+3

dynamic

slot n+4

n

+5

n

+6

n

+x

variable Duration

gdMinislotActionPointOffset

header payload trailer DTS CID

Dynamic Frame

gNumberOfMinislots

Symbol

Window

Media TestSymbol

CID

gdSybolWindow

gdActionPointOffset

cdCAS = 30bit

Network

Idle Time

channelidle

offset correc-tion segment

gdOffsetCorrectionStart

Synchronization

gdNIT

Fig.: 2.8: FlexRay TDMA Structure[VFPR]

Static Segment

Every node participating in the FlexRay cluster gets one or more timeslots in which thenode is allowed to send. This routine is called TDMA, and is used within the static segment.The number of static slots is configured by variable gNumberOfStaticSlots. The scheduleis defined in a Field Bus Exchange Format (FIBEX)-file and cannot be changed duringruntime. The static segment is optimized on the availability of bandwidth on a certaintime. A channel unique Frame-ID identifies a frame corresponding to the timeslot number

14


22/89


in which the frame is sent. For instance a frame has the ID 1 will be sent only in slot 1.The slots within the static segment are synchronous on both channels. A node must send inits assigned slot, however, it has the possibility to send a null frame, i.e., the payload is setto a bit spring of zeros. The payload length, however, remains unchanged. Nullframes areindicated in the header. Receiving nodes do not further process nullframes. All messages in

the static segment must have a common length.[MaRa] [SPAS]

Fig.: 2.9: Static Segment[MaRa]

Dynamic Segment

The dynamic segment is optimized on fully utilizing the bandwidth. The segment is splitinto minislots shorter than timeslots in the static segment. Minislots can be configured usinggNumberOfMinislots. The consecutive numbering of minislots follows up the static segment.The dynamic slot counter is incremented every minislot as long as neither node transmitsa message. The frame-ID of the message and dynamic slot counter must match in orderto send a frame. If a node sends a message, a dynamic slot lasts for as many minislots asnecessary and the dynamic slot counter is incremented afterward. A DTS (Dynamic TrailingSequence) is appended to the frame in order to end the transmission simultaneously with aminislot. Regardless of the utilization the dynamic segment has a fixed, determined lengthto ensure a constant and deterministic cycle time. Messages can only be sent if they fit in

the remaining minislots within the cycle. [MaRa][SPAS]

Figure 2.11 illustrates the static and dynamic segments and the respective media access.The dynamic segment in this example consists of 8 minislots. The red message on channelB cannot be sent since the message lasts longer than the remaining number of minislots.FlexRay does not provide an automated transmission repeat with a higher priority, i.e., witha lower frame ID within the next dynamic segment. This must be organized within FIBEX.

15


23/89


Fig.: 2.10: Dynamic Segment[MaRa]

On the basis of cycle multiplexing the Slot-ID for nodes in the dynamic segment can changeevery cycle. Thus the transmission priority of the respective messages differs as well.

B

B C

A D

E

F

G 7

6 11

Slot 1 Slot 2 Slot 3 Slot 4 Slot 5

Minislots

14

10

Fig.: 2.11: Flexray Static and Dynamic Segments with Media Access [IXXF]

2.1.4 FlexRay TP

Flexray Transport protocol is compatible with ISO 15765-2, the transport protocol for CAN

which was described in previous section 2.1.2. Since only the modifications and extensionsare shown in comparison with ISO-TP in this section2.1.4. The message format was slightlymodified from ISO-TP for CAN. In contrast to CAN, where the transmitter and receiveraddress is mapped to the CAN message identifier, the address information in FlexRay mustbe transmitted within the message as shown in figure 2.13.

The known CAN single, consecutive and flow control frames were modified for FlexRay.There are segmented and unsegmented transmissions with and without confirmation.

16


24/89


Fig.: 2.12: FlexRay transport protocol[ZiSch]

Fig.: 2.13: PDU format of FlexffRay TP [ZiSch]

The figure2.14shows the format of the PCI parameter for the FlexRay transport protocol.The SF extended and FF extended is extension of the SF and FF with enlarged data length,in which the following numbers of data bytes are transmitted. It allows larger data blockso that unsegmented message (SF Extended) with FlexRay transport protocol, it is able torepresent significantly longer message up to 246 byte of data length. The protocol overhead ismaximum 8 byte. Therefore the maximum payload that can be transmitted by one FlexRayPDU is up to 246 byte. FlexRay transport protocol uses approximately the equal protocolmechanisms as the ISO-TP. And with segmented message (FF Extended + CF) able torepresent total data length of 4 GB compared with CAN is only 4 KB. [ZiSch]

17


25/89

2.2. DIAGNOSTIC CHAPTER 2. BASICS

Fig.: 2.14: Format of the PCI fields[ZiSch]

2.2 Diagnostic

This chapter will help the reader to acquire a basic understanding of diagnostic protocol.The first section summarizes overview on automotive diagnosis. The following sectionsexplain the structure and content of diagnostic protocol in detail. This includes diagnosticrequest-response structure and addressing methods.

2.2.1 Overview on automotive diagnosis

Automotive diagnostics is the entire field of investigation and testing to determine the pres-ence or absence of problems in an automobile, and if there are problems, to determine theirproblems and causes. Automotive diagnostics communication is information exchange be-tween vehicle electronics and testing devices. It is relevant to all ECUs and tester systems.It is like reading/writing into memory of ECU and interface with other programs in theECU.

There are two types of automotive diagnosis: 1) On-Board diagnosis 2) Off-Board diagnosis

On-Board diagnosis (Self Diagnosis)On-board diagnosis is a generic term referring to a vehicles self-diagnostic and reportingcapability. Nowadays, in on-board diagnosis built in function of ECUs used for self-diagnosisand to monitor sensors and actuators. Virtually all modern vehicles include an ECU. Whenthe ECU detects a problem it cannot fix, it trips the malfunction indicator lamp and storesa trouble code for later retrieval that points the mechanic toward possible systems or mech-anisms involved. [MaSu]

The On-Board Communication describes the communication between control units and canbe divided into three main areas.

18


26/89


1. High speed (High speed CAN, FlexRay)

2. Low speed (Low speed CAN, LIN)

3. Multimedia (MOST)

Off-Board diagnosis (Service diagnosis)The off-board diagnosis, however, describes the communication between the controller andexternal tester. Off-board communication is also called diagnostic communication becauseit uses a special diagnostic communication protocol. [MaSu] In contrast to the on-boardcommunication with CAN or FlexRay in which each control unit sends its information toall, in the off-board communication the diagnostic tester always starts communication. Itsends a request such as: "Are there emission related fault in the system?" or "What is the oiltemperature?". This request so called diagnostic request goes to one or more control devices.These answers with the appropriate diagnostic responses. So there is a clear role: the testerasks and ECU response. This communication principle known as the Request/Response

method, see figure2.15.

Fig.: 2.15: Off-board communication[EMOT]

Specific diagnostic devices (testing tools) combined with measurement technology, remainingbus simulation and databases. Therefore off-board diagnosis is enhanced diagnosis. Off-board diagnosis can be roughly applied into three parts.

1. Workshop and emission related tests

2. End Of Line (EOL) and Flashing

3. Application (Can Calibration Protocol (CCP) and Universal Measurement and Cali-bration Protocol (XCP))

Before the introduction of the Diagnostics on CAN (ISO 15765), diagnostic communicationwas based on the K-line (Key Word Protocol (KWP) ISO 14230). Today, the diagnosticprotocol UDS (ISO 14229-1 - Unified Diagnostic Services) is widely accepted and estab-lished. UDS provides the unification demanded by vehicle manufacturers and suppliers, anddisplaces the proprietary protocols step by step. UDS is broadly accepted as the diagnosticprotocol in current vehicle developments.

19


27/89


2.2.2 UDS Protocol

Unified Diagnostic Services (UDS) is a communications protocol that is used for diagnosticservices in the automobile. It describes the layers 5 and 7 of the OSI layer model (sessionlayer and application layer). The UDS protocol is standardized in ISO 14229 international.

UDS is independent of the underlying bus system, most commonly it is implemented onCAN and ISO-TP. The implementation of UDS on CAN and ISO-TP is described in ISO15765-3 and is also called "UDS on CAN". [ISO15765-3]

UDS specifies the communication between the diagnostic tester and vehicle ECU. The rela-tionship between the tester and the control unit is a client-server relationship. The controldevice (server) offers a variety of diagnostic services provided by the tester (client) may berequested.

Diagnostics Communication Principle

ECU diagnostic communication using UDS protocol is becoming significant in automotivediagnostic application. The basic principle of diagnostics communication in UDS protocol isrequest/response method. The diagnostic tester sends a request to one or more ECUs andECU sends a positive or negative response. [ISO14229]

Figure2.16explained request-response method. Where parameter P1 indicates the interbytetime for ECU response, P2 indicates the time between end of Tester request and start ofECU response, P3 means time between the end ECU response and start of the next testerrequest or between ECU responses during multiple response mode and P4 point out interbytetime for tester request.

Fig.: 2.16: Diagnostics communication principle[EMOT]

Addressing Method

In general the diagnostics messages are exchanged via the bus where ECU is connected. Forthis reason the destination type of diagnostic messages must be specified. There are twotypes of addressing modes available.

Physical Addressing of ECU (1:1):In the physical addressing mode, unique request and response CAN IDs for each ECUs in the

20


28/89


system. Tester communicates with one only ECU at a time. (Point to point communication).Physical addressing is illustrated by an example with diagnostic tester and n number ofcontrol devices as shown in figure 2.17. Here it can be seen only requested ECU1 (0x7E0)is responded to the tester.

Fig.: 2.17: Physical addressing mode[VWUDS]

Functional Addressing of ECU (1:n):Tester communicates with more than one ECU. Each ECU sends response serially to thetester (Point to multi point communication). In functional addressing tester sends request toall ECU (ECU# 1, ECU# 2, ECU# n-1, ECU# n) as explained in figure 2.18and responsefrom all ECUs which support the request to the tester.

Fig.: 2.18: Functional addressing mode[VWUDS]

For a functional addressing, the request CAN ID will be same for all the ECUs in a givensystem but response CAN IDs will be unique for each ECUs (same as physical).

UDS request and response format

Request format:In request message first byte is called a Service Identifier (SID) to distinguish the various

21


29/89


diagnostic services and the tasks to be done. The remaining bytes contain parameters anddata.[ISO14229]

RequestLength

Service ID SubserviceID

Data 1 Data 2 Data 3 Data 4 Data 5

Example: 02 10 01where 02 indicate the request length and 10 and 01 indicate the serviceID and subservice ID respectively.

Positive Response Format:The ECU responds to a diagnostic query with either a positive or negative response. Thepositive response in the first byte contains the SID again. This is basically the bit 6 set.Mathematically, this corresponds to an addition of 0x40 to SID. [ISO14229]

ResponseLength

Service ID+ 0x40

SubserviceID

Data 1 Data 2 Data 3 Data 4 Data 5

Example: 02 50 01

Negative Response Format:If the request transmitted to the ECU is incorrect the ECU sends negative response. TheNegative Response Message is usually a three-byte message: The first byte is always 0x7F.The second byte contains a copy of the SID and the last byte of the so-called response code.This describes the error. [ISO14229]

ResponseLength

7F Service ID Negative ResponseCode (NRC)

Request: 03 10 02 00Negative Response: 03 7F 10 13

ECU response 03 7F 10 13 where 7F means it is negative response, 10 is SID and 13 indicatesthe incorrect message length (NRC).

The error code of the response is an encoding that represents a justification of the negativeresponse.

2.2.3 UDS Services

Application layer services are usually referred to as diagnostic services. The application layerservices are used in client-server based systems to perform functions such as test, inspection,monitoring or diagnosis of on-board vehicle servers. [ISO15765-3]

The services can be divided in to following functional groups: Diagnostics and Communi-cation management, Data Transmission, Stored Data Transmission, Input/Output Control,

22


30/89


Remote Activation of Routine and Upload/Download. The following table2.1shows a listof diagnostics services of UDS.

FunctionGroup

SID UDS Service Description

Diagnostics andCommunication

Management

0x100x3E0x270x280x850x870x86

DiagnosticSessionControlTesterPresent

SecurityAccessCommunicationControl

ControlDTCSettingLinkControl

ResponseOnEventService

ControlDiagnostic Session

andBus Communication

Data

Transmission

0x220x230x2E0x3D

0x2A0x2C

ReadDataByIdentifierReadMemoryByAddressWriteDataByIdentifier

WriteMemoryByAddress

ReadDataByPeriodicIdentifierDynamicallyDefineDataIdentifier

Read and write ofmeasured values

and ECU data

Stored DataTransmission

0x140x19

Clear DTCRead DTC

Read and writethe DTC code

Upload/Download

0x340x350x360x37

RequestDownloadRequestUpload

TransferDataRequestTransferExit

Read and writelarge data blocks

Table 2.1: List of diagnostics services of UDS [ISO14229]

Diagnostic Session

To protect services from unauthorized access, UDS also specifies different sessions. In eachsession, a tester only requests specific set of diagnostics services to ECU. The different ses-sions are the Default Session (0x01), Programming Session (0x02), and Extended DiagnosticSession (0x03). In addition to this vehicle manufacturer implement further manufacturerspecific sessions. For VW / Audi, these are the "End-of-Line Session (0x40)" and the "De-velopment Session (0x4F)".[VWUDS] [SUNX]

The DiagnosticSessionControl service is applied to allow different diagnostic sessions in the

ECU. A diagnostic session energizes a specific set of diagnostic services and/or functionalityin the ECU. In the "Default Session simple services are available such as reading and eras-ing trouble code or retrieving system data. ECU always starts the default diagnosis sessionwhen you powered up. The "Extended Diagnostic Session" also offers services that affectthe system performance, such as overwriting of system parameters. In the "programmingsession no data can be read from the control unit, but the flashing of the control device ispossible. The VW-specific "End-of-Line Session" offers services for parameterizing and cali-

23


31/89


brating the ECU. This session is only used in the production. The "Development Session" isintended for development purposes, it allows all UDS services offered by server [VWUDS].

Read Data By Identifier (RDBI) (0x22)

This service is used to read out data from the system. The data type involved is de-scribed in more detail in the client request and within the system response, by means ofthe RecordDataIdentifier parameter. The clients request can contain either one or moreRecordDataIdentifier parameters (each 2 bytes). The data to be issued by the system in-cludes digital/analog input and output signals (measured values), system status information,identification data as well as other internal system data. [SUNX]

Message structureTable2.2 shows the request message for reading out data with the identifier. The serviceidentifier is set to 0x22. The 2-byte "Record Data Identifier" (data identifier) are defined byautomobile manufacturers. At VW Group data identifiers are defined for data addressing

in a specification. The function of the request packed the UDS-Request message and passesthe request message to the transmission function of ISO-TP.

Name SID Req SID Record Data Identifier Record Data Identifier(1 Byte) (1 Byte) (1 Byte)

Value 0x22 XX XX

Table 2.2: Request message of the Read Data By Identifier [ISO14229]

Table2.3shows the positive response. The service identifier (SID) is defined with 0x62 (0x40

+ 0x22). The data identifier (Record Data Identifier) is equal to the data identifier of therequest message.

Name Positive Res SID Record Data Identifier Data Record(1 Byte) (1 Byte)

Value 0x62 XX Byte1...ByteK

Table 2.3: Positive response message of the Read Data By Identifier [ISO14229]

Table2.4shows the negative response of the read data by identifier. The service identifierof the response (ResSID) is specified with 0x7F and the service identifier of the request

(ReqSID) is defined with 0x22. The list of error code is already defined in table2.7.

Name Negative Res SID Read Data By Identifier ReqID Error Code(1 Byte) (1 Byte) (1 Byte)

Value 0x7F 0x22 0x22,0x31 or 0x33

Table 2.4: Negative response message of the Read Data By Identifier[ISO14229]

24


32/89


Data identifiers are addressing parameters that are defined by ISO, VW AG, Audi AG orother car manufacturers. Data can be stored in a memory in the address that is addressedby a particular data identifier. A data identifier has a length of 2 bytes.

Read DTC (RDTC) (0x19)

Table 2.5 shows the request message to read the diagnostics trouble codes. The serviceidentifier is set to 0x19. It used to read the errors or notes that have occurred or beendetected. The error code type 0x02 means that read the corresponding error code by statusmask. The DTC status mask describes the states of the error code. [SUNX]

Name Req SID DTC Information Type DTC Mask Record(1 Byte) (1 Byte) (1 Byte)

Value 0x19 02 XX

Table 2.5: Request message of the Read DTC [ISO14229]

With this UDS service the client can request diagnostic information stored in a non-volatilememory (notes/errors) of a server including current status information. Table 2.6 shows thepositive response of ReadDTCByStatusMask.

#1 Read DTC Information Positive Resp SID 0x59

#2 Report Type 0x02

#3 DTC Status Availability Mask XX

Group of DTC

#4 DTC#1 HighByte XXDTC#1 MiddleByte XX

DTC#1 LowByte XX

Group of DTC#n DTC#m HighByte XX

DTC#m MiddleByte XXDTC#m LowByte XX

Table 2.6: Response message of the Read DTC[ISO14229]

Error Handling

If a UDS request is not answered within 500ms from the server, it is repeated. A requestis sent while a maximum of three times. The client receives no response after the thirdrepetition; an error message is passed to the application. [VWUDS]

If the server due to high load not be able to process the request, then server (ECU) requireto send the request Busy repeat request with negative error code (0x21). The client thensends the same request again after some time. [VWUDS]

25


33/89


If a request is received correctly, but still server can not be sent positive response, the serversends a negative response with error code Response pending (0x78). This indicates theclient that the request is currently being processed and the final answer will be delayed[VWUDS]. Table2.7 shows definition of the error code.

Hex Description12 Sub Function Not Supported13 Incorrect Message Length Or Invalid Format21 Busy-Repeat Request22 Conditions Not Correct31 Request Out Of Range33 Security Access Denied35 Invalid Key36 Exceed Attempts7F Service Not Supported In Active Diagnostic Session78 Busy- Response Pending

Table 2.7: List of negative response code [ISO14229]

2.2.4 Open Diagnostic Data Exchange

Vehicle systems, particularly ECU systems are getting more and more complicated. Ad-ditionally diagnostics requirements are also expanding respectively. Therefore diagnosticsefforts have been increasing in production, development and service area. The diagnosticfunctionality using diagnostic description formats is difficult to control for manufacturingdiagnostic specification, ECU supplier diagnostic specification, and development diagnosticspecification. Since the need of standardized description format for diagnostics, configura-

tion and flash programming data is crucial. Therefore Association for Standardization inAutomation and Measuring Systems (ASAM) created a standardization of process, data andtool over the manufacturers, suppliers and tool vendors.

What is ODX?

ODX stands for Open Diagnostics data eXchange and is standardized data format forexchange of vehicle diagnostic data. It was specified by ASAM and is also in ISO 22901standardized.

The ODX format is used to describe all the data needed for vehicle diagnostics consistency

and to enable a standardized data exchange between vehicle manufacturer and system suppli-ers. ODX used Extensive Markup Language (XML) for implementation format.[ASAM]

Figure2.19shows the process chain with an ODX database. The central database containsall vehicle-related diagnostic data. The basic diagnostic data of a vehicle are specified bythe vehicle manufacturer. [ASAM]

26


34/89


Fig.: 2.19: Process chain with ODX [ASAM]

The different development departments of the manufacturer can access these and forwardthem to the system supplier if necessary. The system supplier in return provide diagnosticdata in ODX format of their systems to the vehicle manufacturer, the one maintains it intothe database. [ASAM]

In production, the ODX data for end-of-line testing and parameterization and calibrationof systems are used. In the service area data used for troubleshooting and diagnosis ofdefective vehicles. All subsequent software updates in the workshops are possible withODX. [ASAM]

27


35/89

3 State of the art

The subject of the automotive diagnostic has been rigorously researched in the past decade.In this chapter literature representing the current state of the art will be reviewed.

The current state of the art of vehicle diagnosis

Nowadays, most of the vehicles ECU are diagnosable. With the help of vehicle diagnosticerror of the control units can be determined quickly. For this purpose, protocols have been

developed. These protocols describe the mechanisms and requirements for vehicle diagnos-tics, for example: UDS, OBD, KWP 2000, SAE, ODX, OTX (Open test sequence exchange)and MVCI (Modular Vehicle Communications Interface). With the help of ODX a databasefor diagnosis is defined. In this database, the vehicle diagnostics standard are described.MVCI standardized communication interfaces. SAE protocols define the bus interfaces forvehicle diagnostics. The OBD-2 diagnostic sockets of vehicles allow access to ECUs. To real-ize the access VCIs (Vehicle Communication Interface) have been developed. The VCIs, forexample: MTS 6516 and MTS 6520 that allow connection between the host computer andbuses of the vehicles. The Bosch VCI "MTS 6516" supports both the SAE J2534 interfaceand the ISO 22900-2 Diagnostic Protocol Data Unit (D-PDU) API[Bosch]. The Bosch VCI"MTS 6520" is developed in MVCI standard [Bosch]. For example iDEX and VAS 5163 are

used as a diagnostic software on a computer. iDEX (Intelligent Diagnostic Environment forODX) is a diagnostic software and was developed by the company "Berner and Mattner"for Audi AG. Now iDEX is further developed by Bertrandt. This software offers the fol-lowing options: ECU Identification, Read/Clear diagnostic trouble code, Flashing, Readmeasured value blocks, Access authorization, and Actuator test[BeMa].

VAS 5163 is a diagnostic development tool for Volkswagen. This software allows vehiclediagnostic functions for example: identification of the control devices, reading and deletingof the error memory, encoding and reading of the measured values [Soft]. This vehiclediagnostic software is also used in workshops. Workshop processes are divided into steps:Order acceptance and service and repair procedure [Konr]. A diagnosis software is used

in step "Service and Repair Procedure" for determining the electronic service information[Konr]. The electronic service information include for example: technical information ofthe control devices, vehicle diagnostic information and repair instructions [Konr]. With thisdiagnostic software the diagnostic tasks can be solved, but to carry out the tasks a computerand a VCI is also required.

28


36/89

CHAPTER 3. STATE OF THE ART

Current situation at Bertrandt

The diagnostics request are currently performed with a diagnostics service of bus analysissoftware Vector CANoe. This service request can be performed directly on CAN bus byusing a software gateway for the diagnostics of other bus system like FlexRay bus.

Fig.: 3.1: Current Situation

Here software gateway is used for diagnosis of ECU. By applying software gateway, testercan communicate easily to each ECU. The challenge for the software gateway is to route thepacket to the requested ECU in the correct time.

Diagnostics on ISO-TP on FlexRayCANoe supports a large number of features for the improvement of diagnostics in ECUs andvehicles overall. All features are accessible on the CAN bus with ISO transport protocol.At the same time, not all features are accessible on non CAN bus system and not everytransport protocol is supported. A diagnostics gateway can adapt CAN diagnostics featuresfor other bus system in most of situations. [TPLAH]

A diagnostics communication on FlexRay bus is based on the FlexRay own transport protocolas defined in section 2.4. Since transport protocol ISO compliant behaves and communicatesa FlexRay ECU via the gateway to an external ISO-TP tester.

On FlexRay, PDUs (Protocol Data Units) are exchanged between the communication part-ners. The definition of PDU such as name and position in the FlexRay communicationmatrix defines.

This section defines only

1. Structure of the PDU with specific addressing

2. Routing between CAN and FlexRay via the gateway with specific addressing adaption

FlexRay ISO-TP PDU for DiagnoseFor diagnostic communication normal addressing method is used as defined in section 2.5.2.The FlexRay ISO TP PDU includes a data length of 12 bytes. The first data byte targetaddress is specifically extended for FlexRay. This is the destination address, so the receiverof the PDU. The second data byte source address is also specifically extended for FlexRay.

29


37/89


The second byte is the sender of the PDU. The actual ISO-TP data are in the data bytes4...12.

Fig.: 3.2: FlexRay ISO-TP PDU for diagnose [TPLAH]

Routing ISO TP Communication CAN-FlexRay-CANIn an ISO-TP communication between FlexRay ECU and CAN Tester, the CAN ID aremapped to the target/source addresses as follows:

The target address or source address of the gateway route as a diagnosis is 0x10. The targetand source addresses of the control units based on the following formula: Target address =Request CAN ID 0x700 [TPLAH].

ISO TP Communication from CAN to FlexRay

Fig.: 3.3: Example CAN-FlexRay Routing[TPLAH]

ISO TP Communication from FlexRay to CAN

Fig.: 3.4: Example FlexRay-CAN Routing[TPLAH]

30


38/89


The response CAN ID mapped if the target address of the gateway is 0x10 addressed fordiagnosis. Response CAN-ID = Source address + 0x76A [TPLAH]

From the current situation, the pros and cons of the software gateway are concluded intable3.1 and therefore it can be determined that software gateway needs to be replaced in

future.

Advantage Disadvantage

Able to reuse CAN implementation forFlexRay ISO-TP test

Additional work required because ofmodifications in K-Matrix, FIBEX fileduring I-Step (Integration step) in soft-ware gatewayMaintenance effort and the error rateof the software gateway are very highOther bus system can be integrated

only with great effortNot possible to change the addresswhile CANoe run

Table 3.1: Advantage and disadvantage of software gateway

31


39/89

4 Concept

After the detailed description of the necessary fundamentals and current situation, the fol-lowing section describes the concept in detail. This section discusses the universal UDSAPI concept without software gateway according to OSI layer. This section closes with anexemplary realization of selected UDS service.

4.1 Modification of the ISO/OSI model

Figure 4.1 explains that there is a logical link between the application layer of the tester(client) and the application layer of the ECU (server). They support diagnostic communica-tion using diagnostic requests and responses, which are virtually moved from their originalvertical position to a horizontal one.

Fig.: 4.1: Diagnostic communication from the perspective of the OSI moedl [MaSu]

The communication between the subordinated layers has no relevance for the specificationof diagnostic services. Usually, not all layers of the OSI model are used for diagnosticcommunication. Often, three or four layers are sufficient to accomplish diagnostic commu-nication.[MaSu]

32


40/89

4.1. MODIFICATION OF THE ISO/OSI MODEL CHAPTER 4. CONCEPT

Individual protocols have to be specified for each layer which is involved, such as protocolsfor the transport layer, also referred to as transport protocols [MaSu]. Some vehicle man-ufacturers and suppliers specified proprietary protocols for specific layers of the OSI modelsuch as Volkswagen proprietary transport protocol VW Transport protocol.

So off board communication that called communication between the ECUs and diagnostictester is explained in figure 4.2 as per OSI layer. By the ISO/OSI reference model, thedistribution of tasks in communication between ECU and tester is shown in below figure4.2.

Fig.: 4.2: Protocol stack according to ISO/OSI layer model [EMOT]

The diagnostic protocol describes the layer 7 (Application Layer). Application Layer presentsUDS services for example Read Data By Identifier. Diagnostics message varies in thelength; if the UDS message does not fit into the single message then transport protocolbreaks up a long UDS message into segments that can be transported over bus network.

On controller side, the message is received at the level of the transport protocol layer andeach segmented messages are reconstructed to get back the original message. The ECU willthen give the response and this is again segmented by transport layer. At the tester sidethis process is in reverse order.

33


41/89

4.2. SYSTEM REQUIREMENTS CHAPTER 4. CONCEPT

4.2 System Requirements

The purpose of creation of this thesis is to develop a universal UDS API that should be ableto send diagnostic request without software gateway. Figure4.3 illustrates the conceptualdesign of the different bus module. The desired situation is to send the request directly to

the ECU from tester and also receive response from ECU in reverse order in a same way.

Second requirement for fulfilling desired situation is that API should be expandable andmodular so in future someone can develop further this existed API. It is possible to make thecustomizable UDS API by creating various bus module for particular bus such as FlexRaymodule and LIN module for FlexRay and LIN bus, respectively. Second most importantthing is transport protocol that makes API more dynamic. It could be done by applyingdistinct transport protocol module according to bus system. For instance Flexray transportprotocol applies only for FlexRay bus so one can make further expandable if new version ofFlexRay transport protocol is released in future.

Fig.: 4.3: Desired Situation Fig.: 4.4:Current Situation

4.3 Modular design of the API

The aim of this thesis is to develop a concept for a universal UDS Application ProgrammingInterface (API) that can send a UDS request to different bus systems for example ControllerArea Network (CAN), FlexRay, Local Interconnect Network (LIN) and Ethernet. For this

purpose, first of all a concept have to be set up for a modular design of the API. Eachmodule is available for a particular bus system and should be expandable in retrospect withother modules/bus systems.

Figure4.5shows the modular design of the universal UDS API. The different modules canbe seen as per ISO/OSI layer. Every module has been described in detail step by step inthe following section.

34


42/89

4.3. MODULAR DESIGN OF THE API CHAPTER 4. CONCEPT

Fig.: 4.5: Modular design of the universal UDS API

CAPL API:CANoe contains a CAPL Browser which can use as an alternative to a normal text editorto create CAPL programs. The CAPL language allows writing programs for individualapplications. For example, in the development of network nodes, the problem often arisesthat the remaining bus nodes are not available yet for tests. The system environment canbe emulated with the help of CAPL, e.g. the data traffic of all remaining stations can beemulated.

With CAPL one can also write programs to analyze data traffic which are adapted to problemor programs for a gateway a connection element between two buses so that data canbe exchanged between different buses. The universal UDS API is written with the help of

CAPL programme.

Transport Protocol Module:Transport protocol module splits the data from diagnostics module (long data blocks) intosmall blocks which can be transmitted to respective bus system (CAN, LIN, FlexRay andEthernet). It transmits data via different transport protocol as per different bus system intwo ways. First one is single frame transmission in which data fit into one CAN frame.Another one is multiple frame transmission where transmission of data do not fit into one

35


43/89


CAN frame and therefore have to be send step by step. Two example has been taken for

Fig.: 4.6: Transport protocol module process

explanation of transport protocol module process. Diagnostic module shall send a Read DataBy Identifier request to the network. Diagnostic request data 0x22 0xA1 0x93 values areovergiven to transport protocol module. Transport protocol module will be used single frametransmission because transmission of short data which fit into one CAN frame. The secondexample represents the case of multiple frame transmission where diagnostic request haveto be send step by step because of long response. Therefore basic mechanism of transportprotocol applied here. First sender transmits FF PDU, in response receiver responds with aFlow Control frame and informs the sender about BS and STmin. After receiving FC fromreceiver sender transmits data with CF and it stops transmission after block size.

Transport protocol module adds TP related protol data see below example. There is datalength 03 filled by transport protocol module. Also it fills padding byte with predefinedvalue when PDU has unused byte.

Example: single frame transmission (normal addressing)

Time CAN ID Data bytes2.084300 715 03 22 A1 93 xx xx xx xx

Example: multiple frame transmission (UDS service 22hex ReadDataByIdentifer)

36


44/89


2.093219 77F 10 1762 A1 93 45 56 5F2.093953 715 300000xx xx xx xx xx2.112942 77F 2141 69 72 62 61 56 572.112942 77F 2231 30 42 50 41 56 572.112942 77F 2332 35 30 xx xx xx xx

715 = CAN ID: sent by tester77F = CAN ID: sent by ECU1 = first frame0 17= number of data byte (17hex = 23dec)62 A1 . . . 5F = data byte (UDS data)3 = flow control frame0 = continue to send (tester shall start transmission of data)00 = block size: 00 = no flow control shall be used00= STmin (time between two CF) Shall be >0ms if ECU can not handle 100 % busload2 = consecutive frame1= sequence counter: mechanism for the receiver to check that no CAN message was lost41..57 = data2 = sequence counter increased by 131..57 = data3 = sequence counter increased by 132..30 = dataxx..xx = padded by TP module

UDS protocol moduleApplication layer services are usually referred to as diagnostic services. The application layerservices are used in client-server based systems to perform functions such as test, inspection,monitoring or diagnosis of on-board vehicle servers.

The flow diagram is represented how requested UDS service gives the answer shown in figure4.7. The UDS service request take up the decision one by one on based of service identifier,message length, and sub-function. For instance, if tester sends a request message 03 22 F189 AA AA AA AA, ECU response will be 07 62 F1 89 30 31 30 35. Negative responsemessage of request out of range is 03 7F 22 31 AA AA AA AA.

DisturbanceDisturbance module is intended for transport protocol conformity testing. It supports to val-idate the transport protocol that are used. This is achieved by possible protocol parameterssuch as invalid message length, invalid PCI type, incorrect flow status in terms of corruptframes and unexpected frames.

For example check that controller ignores the single frame with invalid CAN data lengthless than 8 (incomplete frames). Here tester sends a single frame with frame length of 7,03 22 F1 A3 AA AA AA (DLC=7). The electronic control unit must not respond to therequest.

37


45/89


Fig.: 4.7: Process of performing UDS service at application layer

Another example with unexpected first frame while receiving, first tester sends a long requestto the electronic control unit. After the first long request is fully received, the tester sendsanother request (First Frame) immediately.

10 09 22 F1 87 F1 87 F1 (API: long request)

38


46/89


30 0F 05 AA AA AA AA AA (FC from electronic control unit)

10 09 22 A3 F1 89 F1 (API: unexpected first frame request)

Bus Interface:Bus interface connects a PC or notebook to a bus system (CAN,LIN,FlexRay and Ethernet).From the figure4.8,the general bus interface can be seen for the following bus systems CAN,FlexRay, LIN and automotive Ethernet those are going to apply in UDS API that makes iteasy to use bus interface from the Vector CANoe. There one can assign bus specific channelsand ports to send or receive messages on the bus.

In this thesis ECU was connected with bus interface hardware VN7600 FlexRay Interfacefrom Vector. The table4.1 displays following standard Vector hardware for bus interfaces.

These are ideally suited with Vectors CANoe.

Fig.: 4.8: Access to the bus interface

Bus system Interface Connection

CAN/FlexRay VN7600 USBLIN VN1600 USB

CAN/LIN CANboardXL PCIEthernet VN5610 USB

CAN/LIN CANcardXL PCMCIACAN/LIN/FlexRay VN8900 USB

Table 4.1: Vector hardwares for bus interface

Bus interfaces hardware are also provide by different manufacturer such as ETAS, PEAKSystem, Softing and so on.

39


47/89

4.4. CONCEPT REALIZATION CHAPTER 4. CONCEPT

4.4 Concept realization

Figure4.9 explains how concept flows using different test modules of API. Example of UDSservice "Read DTC Information 19 Hex" has been illustrated step by step.

Fig.: 4.9: concept realization with Read DTC information service

Summary

This chapter has contributed concept approach information to implement the universal UDS

API that can send UDS request directly to ECU without a software gateway. All abovediscussed approaches contribute to an API for ECU diagnostic communication as shown infigure4.10. The UDS services are carried out in UDS API through APIs transport protocolmodule and it sends the request message. The received message is interpreted on the APIand returned as readable answer. This approach is basically the same in all services.

40


48/89

4.4. CONCEPT REALIZATION CHAPTER 4. CONCEPT

Fig.: 4.10: Block diagram of UDS API

41


49/89

5 Implementation

After the detailed descriptipn of the necessary fundamentals and concept development, thefollowing section describes the ISOTP protocol and FRTP protocol implemtation using Com-munication Access Programming Language (CAPL) programming in detail. This section alsodiscusses the simulation tool CANoe.

5.1 Software component

In the following section the software component is described. This includes the measure-ment and simulation software CANoe, which controls the bus interface for the simulation ofcomplete bus systems. The implementation of the simulation is implemented using C-likeprogramming language CAPL.

5.1.1 CANoe

The measurement and simulation software CANoe developed by the company Vector. Itprovides comprehensive functions that are frequently used by vehicle manufacturers andtheir suppliers in the entire development process of networks or individual control units inautomotive vehicles. CANoe provides engineering support in the areas of analysis, simulationand diagnostic testing.

As briefly mentioned above, CANoe allows simulations of various bus systems, includingtheir subscribers. A configuration contains all simulated bus systems. The simulation ofthe participants on the bus systems is realized by so-called CAPL node. CAPL is a specialevent-driven programming of the vector.

In CANoe the following windows are available for the simulation and analysis.

1. Simulation setup: In the Simulation Setup, the overall system is displayed graphicallywith networks, devices and all network nodes. All options for parameterizing theSimulation Setup are selected in this window.

2. Simulation window: The tree structure of CANoe is displayed in simulation setupwindow. The tree structure is configuration of all bus systems and their hierarchalsettings with CANoe

3. Measurement Setup: The data flow is displayed graphically in the Measurement Setup.All options for parameterizing the Measurement Setup are selected in this window.

4. Graphics Window: Chronological signal charts are graphically displayed in the Graph-ics Window. The display is in an X-Y diagram along the time axis.

42


50/89

5.1. SOFTWARE COMPONENT CHAPTER 5. IMPLEMENTATION

Fig.: 5.1: CANoe configuration windows

5. CAN statistics window: The Statistics Window displays statistics about bus activitiesduring measurement. This window can be inserted into the Measurement Setup viathe shortcut menus of the relevant function blocks (bus statistics etc.). All bus eventsthat arrive at the input of the Measurement Setup block are evaluated for this purpose.If a database is assigned to the channel, statistics can also be evaluated individuallyfor each available bus node.

6. Write Window: Information on the progress of the measurement are output here.Write instructions from CAPL programs appear in this window.

7. Trace Window: The purpose of the Trace Window is to record bus activities duringmeasurement. All the messages received at the input of a Trace block are displayed aslines of text in the Trace Window.

5.1.2 CAPL Browser

CAPL is a part of a CANoe. CAPL browser is provided as a development environment byVector. CAPL browser is an easy-to-use tool for creating and modifying CAPL programs.

43


51/89


Using CAPL Browser, CAPL programs can be written for stimulating, simulating, testingand diagnostics. CAPL programs are added in CANoe as CAPL program nodes. Eventhandlers serve as an input in CAPL, with which external events can be responded (e.g. thearrival of certain messages).

Fig.: 5.2: CAPL Browser

Figure5.2 shows the opened CAPL programs distributed among the individual tabs. Thedisplay of the individual CAPL program is divided into a Navigator and a Text Editor.

1. Text editor: The entire source code of the CAPL program is displayed in the TextEditor and it can be edited there. You can declare variables and implement eventhandlers and functions there. The Navigator displays the structure of the file asa tree view. The following categories may be present: Test functions, Test cases,Test procedures, User defined functions, Includes, Variables and Event handlers (eventprocedures)

2. Navigator: Navigator is used to navigate the desired sections in source code quickly andeasily (e.g. an event handler).The CAPL Browser monitors the symbols, i.e. databasesymbols, diagnostic parameters, system and environment variables are updated auto-matically if changes are made.

3. CAPL function explorer: All available predefined functions and event handlers aredisplayed in the CAPL Function Explorer. They can be inserted into an opened CAPLprogram using drag and drop.

4. Output window: Compiler messages on the currently active program are displayed inthe output window

44


52/89


5.1.3 Structure of a CAPL program

CAPL program consist of two parts:

Declaration of global variables

Declaration of user defined functions and event procedures

Global variables

In the Browser, global variables are declared in the Variables section. The data typesDWORD, LONG, WORD, INT, BYTE and CHAR can be used analogously to their usein the C programming language. The data types FLOAT and DOUBLE are synonymsand designate 64 bit floating point numbers conforming to the IEEE standard. CAN/LINmessages to be transmitted on the bus by the CAPL program are declared with message.

A timer event is created with timer or msTimer. The timer does not begin to run until it

has been started in a on timer event procedure. After the timer has elapsed the associatedevent procedure is called. A variable of the type timer can only be accessed by the predefinedfunctions setTimer and cancelTimer.

Event procedures:CAPL is an event-controlled programming language; special event handlers (event proce-dures) are always executed when a specific event (e.g. pressing a button) occurs. In theCANoe environment, it is primarily bus events, e.g. the sending of a specific signal, whichoccur. For this reason, the CAPL Browser offers a large number of predefined event handlersfor bus events.

CAN event procedureon messageThe event procedure on message is called on the receipt of a valid CAN message.on message 0x783 {output(this);};The procedure on message 0x783 will be called up when a message with the identifier 0x783is received.

FlexRay event procedureon frPDU

This procedure is called when a PDU with the corresponding name is received.

Declaration of user defined functions

CAPL functions are used among other things to modularize code for repeated use, and toform interfaces. The syntax is C-like, but there are a number of supplemental features notincluded in C:

A missing result type is interpreted as void

45


53/89

5.2. EXPERIMENTAL SETUP CHAPTER 5. IMPLEMENTATION

An empty parameter list is permitted as in C++

Overloading of functions (i.e. multiple functions with the same name but differentparameter lists) is possible as in C++

A parameter check is performed as in C++ Arrays of arbitrary dimension and size may be passed

CAPL Include files

An Include file can be integrated directly in the code of the CAPL program. It is treatedsimilar to a function library. An include file has to be programmed in the same programminglanguage as the main CAPL program.

CAPL Include files are not simply included as text include. All variables and functions thatare included via the Include files will be available as global variables and functions.

In CAPL any number of Include files can be inserted in the Include program section via thesyntax #include:includes{#include"inclFile1.CIN"#include"inclFile2.CIN"#include"inclFile3.CIN"}The name of the Include file is freely selectable. In the example above the extension .CINis used. The Include file has to be a syntactic correct CAPL program. This means: - The

Include file consists of a sequence of sections, e.g. variables, on message etc. - The Includefile can include other files.

5.2 Experimental Setup

This experimental setup is quite similar to the simulation view in CANoe. In addition to thepure simulation also bus communication can be monitored from real systems with CANoe.To monitor the communication on a real bus additional hardware is required, which makesthe connection between the computer and the bus system. This bus interface hardware alsocomes from Vector Company. There are various models available in market with differentfeatures and bus interface. During this thesis has been working with the VN7600 interface.

This was connected via USB to the computer. It has shown from figure that ECU has beenconnected to the tester (PC) through Vector bus interface hardware.

46


54/89

5.3. IMPLEMENTATION OF THE ISOTP CHAPTER 5. IMPLEMENTATION

Fig.: 5.3: Experimental setup

5.3 Implementation of the ISOTPThe universal UDS API has a modular design and consists of different modules for differentfunctionality such as UDS module for various diagnostic services, CANTP and FRTP fortransport protocol layer. These modules are programmed as a .can and .cin file in theAPI. The structure of the API as an illustration represented in figure 5.4. These individualmodules are associated with important functions and these functions has been wriiten in amodules .cinfile. A detailed description of the modules and functions can be found in thefollowing section.

Fig.: 5.4: API Structure

This section mainly aims at describing the different stages of the ISOTP protocol implemen-tation and the subsequent steps in detail. This is done with the help of a potocol parametercalculation. It should also be noted that, this chapter only focuses on the implemetationand not the verification of the ISOTP implementation.

ISOTP transport protocol parameter calculation

47


55/89

5.3. IMPLEMENTATION OF THE ISOTP CHAPTER 5. IMPLEMENTATION

PDU-Type FC PCI Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 Byte7 Byte8

FlowControl 0 0 1 1 FS BS STmin 0xAA 0xAA 0xAA 0xAA 0xAA

Table 5.1: Structure of a Flow Control PDU [VWTP]

Flow Status Meaning

0 Continue To Send (CTS)The CTS Flow Control parameter signals the sender to con-tinue the transfer of CF PDUs. The receiver signals thesender that it is ready to receive the number of CF PDUsspecified in the BlockSize (BS).

1 Wait (WT)The WT FlowControl parameter signals the sender to waitbefore transferring any further CF PDUs. The transmis-sion of further CF PDUs continues after receiving a CTS FCPDU.

2 Overflow (OVFLW)With the OVFLW Flow Control parameter, the receiver sig-nals the sender to ca

Master Thesis Ketan Bavalia

Documents

Transcript of Master Thesis Ketan Bavalia