BGSV Embedded Academy (BEA)

Focused Program to Develop Embedded Competence

BGSV EMBEDDED ACADEMY

Methodological
Technical Competence Process Competence
Competence
T1: Automotive Basics (Sensor,
SW, Mobility Solution) P1: Requirements Engineering
M1: SW Development Lifecycle
T2: Automotive SW Architecture
(AUTOSAR) P2: Design Principles

T3: Embedded Programming P3: Review

M3: Clean Code

T5: Test Overview P4: Safety & Security

Classroom training, Online Self-learning, Live Demo

Purpose: Develop basic general embedded competence
Disclaimer

 This slide is a part of BGSV Embedded Academy (BEA) program and only used for BEA training
purposes.

 This slide is Bosch Global Software Technology Company Limited’s internal property. All rights
reserved, also regarding any disposal, exploitation, reproduction, editing, distribution as well
as in the event of applications for industrial property rights.

 This slide has some copyright images and text, which belong to the respective organizations.
 T2
AUTOMOTIVE SOFTWARE
ARCHITECTURE
Agenda

No Part Duration Trainer Training date

Automotive Software
1 2 Pham Vo Tuan Anh 29-Sep-22
Architecture Intro

2 CAN Protocol 6 Mr. Quan (UIT) 06 & 13 Oct 22

Automotive Diagnostic
3 1.5 Nguyen Kien 20 & 27 Oct 22
Overview

5
CAN
PROTOCOL
Introduction
Vehicle network

7
Introduction
History
Maximum Bitrate Mbit/s

Year

8
Introduction
Characteristics of ‘CAN’
• CAN is a multi-master Bus
• Theoretically No limitation on the number of nodes
• Configuration flexibility - No node addressing
• Prioritization of messages through “Identifiers”
• Multicast reception with the time synchronization
• System wide data consistency
• Guarantee of latency times
• Error detection and error signaling
• Automatic retransmission of corrupted messages
• Temporary errors - permanent failures of nodes and
autonomous switching off defect nodes

9
Characteristics of ‘CAN’

10
Characteristics of ‘CAN’

11
Introduction
CAN in the OSI model

12
CAN Protocol
Physical Layer
➔ Bit rate: up to 1Mbit/s
➔ Bidirectional Dual-wire bus with 40-50m maximum in length
➔ Multi-Master

CAN bus level

Vehicle

Volt
OBD connector

13
CAN Protocol
Relation between Baud Rate and Bus Length

14
CAN Protocol
Bus Access and Arbitration
• Bus access through CSMA with AMP
NODE Arbitration phase
Remainder
A 0 1 0 0

B 0 1 0 1

C 0 1 1 0 Node B looses arbitration

Node C looses arbitration

BUS 0 1 0 0

• Advantages
• No Collision
• Transmission of highest priority message within the latency time

15
CAN Protocol
Message Transfer
Frame Formats
• Standard Frame - 11bit Identifier
• Extended Frame - 29 bit Identifier

Frame Types
• Data Frame
• Remote Frame (not useful)
• Error Frame
• Overload Frame (not useful)

16
 Standard Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field CRC Field ACK End of Inter-
Field
Data Frame Frame mission

RTR
SOF

IDE
11 Bit Identifier DLC (4) 0 to 64 Bits 15 Bits 7 Bits 3 Bits

r0
Bus Idle CRC Delimiter
Ack Slot Bus Idle
Ack Delimiter

17 • Differs only in Arbitration field and Control field

Difference between Standard Frame and Extended Frame
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
Difference between Standard Frame and Extended Frame
18
• Differs only in Arbitration field and Control field
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
19
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
20
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
Frame lỗi gồm:
- Cờ lỗi
- - phần delimiter

23
 Extended Data Frame Format
CAN Protocol Arbitration Field Control Field Data Field
Data Frame

RTR
SOF

SRR
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

IDE

r1
r0
24
CAN Protocol
NHận dữ liệu

Difference between Standard Frame and Extended Frame

25
• Differs only in Arbitration field and Control field
CAN Protocol
Truyền dữ liệu

26
CAN Protocol
Error Frame
Error Frame Format (Active Error Frame)
Error Condition

Uncompleted Error Frame Inter-

Frame mission

6 Bits 0 -6 Bits 8 Bits 3 Bits

Superposition of Error Delimiter

Error Flag

• Error flag can start within the frame that is currently being transmitted

Types of Error flags

• Active Error flag - consists of 6 consecutive ‘dominant’ bit
• Passive Error flag - consists of 6 consecutive ‘recessive’ bit

27
CAN Protocol
Error Handling
The mode of the controller is controlled by two error
counters - the transmit error counter (tx_count) and the
receive error counter (rx_count).

The following rules apply:

➢ The CAN controller is in error active mode if:
tx_count <= 127 AND rx_count <= 127.
➢ Passive mode is used if :
tx_count > 127 or rx_count>127 AND tx_count <= 255.
➢ Bus off is entered if:
tx_count > 255.

28
CAN Protocol
Interframe Spacing
After the transmission of a frame by an Error Active node

Previous Frame Interframe Spacing Next frame

3 Bits

Inter- Bus idle

mission

After the transmission of a frame by an Error Passive node

Previous Frame Interframe Spacing Next frame

3 Bits 8 Bits

Inter- Suspend Bus idle

mission Transmission

29
CAN Protocol
Message Coding
Non-Return-to-Zero coding
• Keeps the frequency of the signal on the bus to minimum.

“1”
“0”

1 1 0 1 0 0 1 1 ………………..

Bit-Stuffing
• Ensures sufficient Recessive and Dominant edges for Re-Synchronization.
Data Stream
1 1 2 3 4 5 6 7 8 9 101 2 3 1 2 1 2 3 4 5 6 1 2

Bit Stream
1 1 2 3 4 5 S 6 7 8 9 10S 1 2 3 1 2 1 2 3 4 5 S 6 1 2

30
A complete CAN bus frame

Source: Wikipedia

31
CAN Protocol
Types of Error Detected in CAN Bus
CRC Error:
• Every node receive the message, Calculate CRC and compare it with Received CRC.

Acknowledge Error:
• Transmitting node send a ACK slot bit as a recessive bit and check for dominant bit to verify reception.

Form Error:
• Generated when any of following bit is detected as a dominant bit where One should not be.
e.g. CRC delimiter, ACK delimiter, End of Frame, Inter Frame Space.

Bit Error:
• Node detect the signal that is opposite of what it send on Bus.

Stuff Error:
• Bit stuffing rule is violated when 6-consecutive bits with the same polarity are detected.
32
Introduction about CAN FD

Main improvement:
• Increase bit rate ( 2,4 … up to 8 Mbit/s)
• Increase payload up to 64 bytes

33
Abbreviation
CAN: Controller Area Network
CAN FD: Controller Area Network Flexible Data-Rate
CSMA: Carrier Sense Multiple Access/ Collision Detection
AMP: Arbitration on Message Priority
OSI: Open Systems Interconnection model
SOF: Start Of Frame
RTR bit: Remote Transmission Request bit
SRR bit: Substitute Remote Request bit
IDE bit: Identifier Extension
DLC: Data Length Code
EOF: End Of Frame
CRC: Cyclic Redundancy Check/ Check sum
ACK bit: Acknowledgment bit
IFS: Inter Frame Space
REC: Receive Error Counter
TEC: Transmit Error Counter

34
Reference
- CAN Specification 2.0 – Bosch

- ISO 11898-2 – High speed CAN

- ISO 11898-2 2015 – CAN FD

- Bit timing calculation: http://www.bittiming.can-wiki.info/

- Return to zero: https://en.wikipedia.org/wiki/Return-to-zero

- None return to zero : https://en.wikipedia.org/wiki/Non-return-to-zero

- CSMA/CD : https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection

35
DIAGNOSIS
OVERVIEW
Trainer Introduction

NGUYEN KIEN

SW Architect – RADAR product

9 years experience in Bosch DA/RADAR development

Bachelor of Engineering – Embedded System

37
Definitions
Diagnosis – What?
“In automotive engineering, Diagnosis is typically used to determine the causes
of symptoms and solutions to issues.”
 symptom(s) – what the user/operator/repairer of the system (vehicle or
whatever) notices;
 fault(s) – the error(s) in the system that result in the symptom(s);
 root cause(s) – the cause(s) of the fault.

Source: Advanced Automotive Fault Diagnosis- Automotive Technology: Vehicle

Maintenance and Repair
TOM DENTON

38
Definitions
Diagnosis – How?[1]
To do Diagnostic, Technician have to know how to use Diagnostic Tools and
Equipment.
Tool and Equipment could be classified into:
 Basic Equipment: such as Multi-meter
 Tracing Tool: like Oscilloscope
 Scanner/Fault Code Readers and Analyzers.

39
Definitions
Diagnosis – How?[2]
 The Equipment shall help technician indicate where is fault occurs in systems.
 In the other word, In Vehicle, Systems should have ability to provide
information in case request.
 This is the motivation of On-board diagnostics (OBD).

 On-board diagnostics (OBD) is a generic term referring to a vehicle’s self-

diagnostic and reporting system. OBD systems give the vehicle owner or a
technician access to information for various vehicle systems.
 OBD system illuminates a warning lamp known as the malfunction indicator
lamp (MIL) or malfunction indicator (MI) on the instrument cluster.

40
Definitions
Diagnosis – How?[3]
 When the fault occurs, the system stores a diagnostic trouble code (DTC), also
store important information of the vehicle when the fault was set.
 A service technician is able to connect a diagnostic scan tool or a code reader
that will communicate with the system and retrieve this information.
 As vehicles and their systems become more complex, the functionality of OBD
is being extended to cover vehicle systems and components that do not have
anything to do with vehicle emissions control: Vehicle body, chassis and
accessories
 OBD systems use a standardized communications port to provide data
 The Communication between Diagnostic Equipment and ECUs through Vehicle
Special Interface for Diagnosis purpose is called Diagnostic Communication.

41
Definitions
States and Events
 Everything about the car is either in a "normal" state or an "abnormal" state.
 Either the car is starting normally or it is not. Either the engine is running
normally or it is not.
 Used in this way, "normal" means acceptable, the way they are supposed to
be, okay. "Abnormal" means not acceptable, not the way they are supposed to
be, not okay.
 The purpose of all automobile repair is to correct abnormal states and restore
the car to its normal state of operation.

42
Definitions
States and Events
 An "event" is when something happens: a spark plug fires, the brakes are
applied, a fuel injector opens, a relay closes.
 An event is a change of state, from one condition to another.
 A "normal event" occurs when something happens just as it is supposed to
happen.
 An "abnormal event" is when something happens that is not supposed to
happen: the engine quits unexpectedly, the car fails to stop when the brakes
are applied.
 All automotive complaints can be described and understood in terms of
abnormal events: some things are happening which are not supposed to
happen, and the driver has noticed them.

43
Diagnosis Uses

 Diagnosis is used to detect the fault in the system.

 Use to read the parameters like WSS signal, SAS signal, YRS signal etc.

 Used for calibration of Steering Angle sensor, Lateral , Longitudinal sensor etc.

 Use to run EOL(End of Line) routines.

 Used for reprogramming.

44
On board and Off board Diagnosis

Normally, the information is exchanged between an on-board ECU and an off-board diagnostic
tester.

45
Diagnosis Protocols
Unified Diagnostic Services (UDS)

46
Diagnosis Protocols
Emissions-related diagnostics (emissions-related OBD)

47
Diagnosis Protocols
ECU(server) – Tester(client) communication

 Tester sends a request\command to ECU, to perform certain action.

 ECU sends a response message to the corresponding request.

48
Request and response
Overview
Positive response Negative Response

 Tester sends a request to perform  Tester sends a request to perform

software reset. software reset.
 ECU returns a positive response.  ECU returns a negative response
indicating software reset can not be
performed.
49
Request and response
Overview

50
Request and response
Overview

Request Positive Response Description

0x00 .. 0x0F 0x40 .. 0x4F OBD in ISO 15031-5 Emissions-related diagnostic services

0x10 .. 0x3E 0x50 .. 0x7E UDS in ISO 14229

0x83 .. 0x87 0xC3 .. 0xC7 KWP2000 in General vehicle diagnostics
0x81.. 0x82 0xC1 .. 0xC2 KWP2000 over K-line in ISO 14230

0xA0 .. 0xB9 0xE0 .. 0xF9 Reverse for OEM

0xBA .. 0xBE 0xFA ..0xFE Reverse for ECU manufacturers

Others Reverse

51
Request and response
Negative response

52
Diagnosis mode

➔ Normal Mode (Default)

➔ Test Mode / Adjustment mode

➔ Reprogramming mode

53
Addressing

Functional Address:
Physical Address:

54
Definitions
Milestones
 1969: Volkswagen introduces the first on-board computer system with
scanning capability, in their fuel-injected Type 3 models.
 1975: Datsun 280Z On-board computers begin appearing on consumer
vehicles, largely motivated by their need for real-time tuning of fuel injection
systems. Simple OBD implementations appear, though there is no
standardization in what is monitored or how it is reported.
 1980: General Motors implements a proprietary interface and protocol for
testing of the Engine Control Module (ECM) on the vehicle assembly line. The
'assembly line diagnostic link' (ALDL) protocol communicates at 160 baud with
Pulse-width modulation (PWM) signalling and monitors very few vehicle
systems.

55
Definitions
Milestones
 1986: An upgraded version of the ALDL protocol appears which communicates
at 8192 baud with half-duplex UART signalling. This protocol is defined in GM
XDE-5024B.
 ~1987: The California Air Resources Board (CARB) requires that all new
vehicles sold in California starting in manufacturer's year 1988 (MY1988) have
some basic OBD capability. These requirements are generally referred to as
"OBD-I", though this name is not applied until the introduction of OBD-II. The
data link connector and its position are not standardized, nor is the data
protocol.
 1988: The Society of Automotive Engineers (SAE) recommends a standardized
diagnostic connector and set of diagnostic test signals.

56
Definitions
Milestones
 ~1994: Motivated by a desire for a state-wide emissions testing program, the
CARB issues the OBD-II specification and mandates that it be adopted for all
cars sold in California starting in model year 1996. The DTCs and connector
suggested by the SAE are incorporated into this specification.
 1996: The OBD-II specification is made mandatory for all cars sold in the
United States.
 2001: The European Union makes EOBD mandatory for all gasoline (petrol)
vehicles sold in the European Union, starting in MY2001 (see European
emission standards Directive 98/69/EC)).

57
UNIFIED
DIAGNOSTIC
SERVICES
Agenda

1. Overview
1. UDS
2. Diagnostic Communication Protocol
3. Related ISO Standards
2. UDS In General
1. Application Layer
2. Session Layer
3. UDS In CAN Implementation

59
Overview
UDS
 (U)nified (D)iagnostic (S)ervices is a diagnostic communication protocol

 UDS is a non-OBD protocol

 Standardized across manufacturers and standards

 Use cases:
 Detect faults in the system
 Read vehicle parameters
 Configuration/Calibration ECUs
 End Of Line Routine
 Reprogramming

60
Overview
Protocol

Protocol: server  client

Positive response Negative response

61
Overview
Related ISO Standards
 Derived and distributed based on OSI model

 UDS specification covers layer 5~7

 Service ID and associated parameters are

contained in the payload of message frame

 Communication protocol covers layer 1~2

62
UDS in General
Application Layer – Services

 Also referred to as Diagnostic Services

 At client side: used to request certain diagnostic functions
 At server side: used to send response data back to client
 6 service primitives are specified
 Service request primitive
 Service request-confirmation primitive
 Service indication primitive
 Service response primitive
 Service response-confirmation primitive
 Service confirmation primitive

63
UDS in General
Application Layer – Request Format
Application Layer Protocol Data Unit (A_PDU)

Protocol Control Service Data Unit (A_SDU)

Information (A_PCI)

Request with only Service ID (SID)

SID Opt. Data

Request with Service ID (SID) and Sub-function (SF)

SID SF Opt. Data

Request with Service ID (SID) and Data ID (DID)

SID DID DID Opt. Data
Request with Service ID (SID), Sub-function (SF) and Data ID
(DID) SID SF DID DID Opt. Data

64
UDS in General
Application Layer – Response Format
Application Layer Protocol Data Unit (A_PDU)

Protocol Control Service Data Unit (A_SDU)

Information (A_PCI)

Positive Response with only Service ID (SID) SID +

0x40
Opt. Data
Positive Response with Service ID (SID) and Sub-function (SF) SID +
0x40
SF Opt. Data
Positive Response with Service ID (SID) and Data ID (DID) SID +
0x40 DID DID Opt. Data
Positive Response with Service ID (SID), Sub-function (SF) SID +
and Data ID (DID) 0x40 SF DID DID Opt. Data
Negative Response 0x7F SID NRC

65
UDS in General
Application Layer – Service ID List

66
UDS in General
Application Layer – Common NRC List
Value Response Code Value Response Code
0x00 positiveResponse 0x10 generalReject
0x11 serviceNotSupported 0x12 subFunctionNotSupported
0x13 incorrectMessageLengthOrInvalidFormat 0x21 busyRepeatRequest
0x22 conditionNotCorrect 0x24 requestSequenceError
0x31 requestOutOfRange 0x33 securityAccessDenied
0x35 invalidKey 0x36 exceedNumberOfAttempts
0x37 requiredTimeDelayNotExpired 0x72 generalProgrammingFailure
0x78 responsePending 0x7E subFunctionNotSupportedInActiveSession
0x7F serviceNotSupportedInActiveSession 0x83 engineIsRunning
0x88 vehicleSpeedTooHight 0x93 voltageTooLow

67
UDS in General
Application Layer –
Server Response
Implementation Rules
 General server response behavior upon receiving a
request from client

 Services with sub-function and without sub-function

are handled differently in next steps

 Service 0x31 (only service with both sub-function

and data ID) are also handled differently

68
UDS in General
Application Layer – Server
Response Implementation
Rules
 General server response behavior upon receiving a
request with sub-function is given in the picture

 There is no general server response behavior for

requests without sub-function

 Server response behavior also depends on addressing

mode (physical/functional) and on whether “suppress-
positive-response” is requested

69
UDS in General
Application Layer – List Of Standardized Services
SID Service Name SID Service Name
Diagnostic & Communication Management
0x10 Diagnostic Session Control 0x11 ECU Reset
0x27 Security Access 0x28 Communication Control
0x3E Tester Present 0x83 Access Timing Parameter
0x84 Secured Data Transmission 0x85 DTC Control Setting
0x86 Response On Event 0x87 Link Control
Data Transmission
0x22 Read Data By Identifier 0x2E Write Data By Identifier
0x23 Read Memory By Address 0x3D Write Memory By Address
0x23 Read Scaling Data By Identifier 0x2C Dynamically Defined Data Identifier
0x2A Read Data By Periodic Identifier
70
UDS in General
Application Layer – List Of Standardized Services
SID Service Name SID Service Name
Stored Data Transmission
0x14 Clear Diagnostic Information 0x19 Read DTC Information
Input Output Control
0x2F Input Output Control By Identifier
Routine
0x31 Routine Control
Upload Download
0x34 Request Download 0x35 Request Upload
0x36 Transfer Data 0x37 Exit Transfer

71
UDS in General
Application Layer – Service $10 – Overview

 Service $10 – Diagnostic Session Control

 A diagnostic session enables a set of services/functions

 Only 1 active diagnostic session at a time

 System starts with default session at power up. Other sessions must be
requested with service $10 to start

72
UDS in General
Application Layer – Service $10 – Request Format

Diagnostic Session Type:

 0x00: reserved  0x05-0x3F: reserved
 0x01: default session  0x40-0x5F: vehicle manufacture specific
 0x02: programming session  0x60-0x7E: supplier specific
 0x03: extended session  0x7F: reserved
 0x04: safety system diagnostic session

73
UDS in General
Application Layer – Service $10 – Positive Response Format

 Diagnostic Session Type  Session Parameter Record

(same as in request format)

74
UDS in General
Application Layer – Service $27 - Overview
Client Server
 Service $27 – Security Access

 Provide a mean to access data/services

 Implement using seed/key relationship

 Formula to calculate key from seed is pre-determined

and known by both client and server

 Access is granted when key calculated by client matches

with that by server

75
UDS in General
Application Layer – Service $27 - Overview
 Security Level
Security Level 1 2 3 … n …
Seed-related sub-function 1 3 5 … 2n-1 …
Key-related sub-function 2 4 6 … 2n …

 Security levels are independent and non-arbitration from each other

 At any moment, only 1 security level can be in unlock state

 Data/services can be assigned to more than 1 security level. Access is granted

when any of those is in unlock state

76
UDS in General
Application Layer – Service $27 – Request Format

 Security Access Data

Record (optional):
information about the
seed

77
UDS in General
Application Layer – Service $27 – Response Format

 Security Access Type in the response is echoed from the request

 Seed length and algorithm is defined by user (usually a random generation algorithm)
 Key length and algorithm is defined by user.
 Seed length and key length are not necessarily be same

78
UDS in General
Application Layer – Service $22/$2E – Overview
 Service $22 – Read Data by Identifier
 Service $2E – Write Data by Identifier

 Data Identifier (DID): 2 byte – mark for an internal location of a data record

 DID along with referred data length and format are pre-defined by user

 Service $2E might involve NVM-related services to store data

 Service $2E might involve certain security check methods

79
UDS in General
Application Layer – Service $22/$2E – Request Format

 Data from multiple DIDs

can be read in 1 single
request
 Maximum number of
DIDs must be pre-
determined

80
UDS in General
Application Layer – Service $22/$2E – Response Format
 For multiple DIDs read request, data is
provided in the response along with the
respective DID

81
UDS in General
Session Layer - Services
 E.g.: transmission/reception of data, setting of protocol parameters
 Primitives: request, indication, confirm

82
UDS in General
Session Layer – Timing
Parameter – P2, P2*, P4

 P2: from receiving of request to start of 1st

response (can be NRC 0x78)
 P2*: from receiving NRC 0x78 to start of next
response (can also be NRC 0x78)
 P4: from receiving of request to start of final
response (cannot be 0x78)
 Note: delay between layers and transmission
medium should be accounted for
 Note: from server side, a max threshold is also
defined for each parameter

83
UDS in CAN Implementation
Application Layer
SID Service Name SID Service Name
Diagnostic & Communication Management
0x10 Diagnostic Session Control 0x11 ECU Reset
0x27 Security Access 0x28 Communication Control
0x3E Tester Present 0x83 Access Timing Parameter
0x84 Secured Data Transmission 0x85 DTC Control Setting
0x86 Response On Event 0x87 Link Control
Data Transmission
0x22 Read Data By Identifier 0x2E Write Data By Identifier
0x23 Read Memory By Address 0x3D Write Memory By Address
0x23 Read Scaling Data By Identifier 0x2C Dynamically Defined Data Identifier
0x2A Read Data By Periodic Identifier
84
UDS in CAN Implementation
Application Layer
SID Service Name SID Service Name
Stored Data Transmission
0x14 Clear Diagnostic Information 0x19 Read DTC Information
Input Output Control
0x2F Input Output Control By Identifier
Routine
0x31 Routine Control
Upload Download
0x34 Request Download 0x35 Request Upload
0x36 Transfer Data 0x37 Exit Transfer

85
 Q&A
86
DIAGNOSTIC
COMMUNICATION
OVER CAN
Agenda

1. Overview
1. Diagnostic over any protocol
2. OSI encapsulation model
2. Diagnostic over CAN
1. Problem
2. Single-frame transmission
3. Multi-frame transmission
4. N_PDU definition
5. Timing parameters

88
Overview
Diagnostic Over Any Protocol
 Diagnostic communication protocols (like UDS) cover the upper
layers (5, 6, 7)

 Communication protocols (like CAN) cover the lower layers (1,

2)

 Diagnostic over <protocol> covers Network layer (3) and

Transport layer (4)

 Diagnostic over <protocol> ensure diagnostic data from upper

layers can be transmitted/received using <protocol>
communication

89
Overview
OSI Encapsulation Model
 Layer header is included in the data before
passing to the adjacent lower layer

 Content of the header is related to the

protocol/format used at that level

 Data and header of Nth-layer will become data

of N-1th-layer

 Header included in the N-layer at sender side

will later be used by same N-layer at receiver
side to process the data

90
Overview
OSI Encapsulation Model
 Terminology:
 SDU – Service Data Unit (payload)
 PCI – Protocol Control Information (header)
 PDU – Protocol Data Unit

 Note:
 Nth-PCU is added by Nth-layer of sender, then removed by Nth-layer of receiver
 Not always all 7 layers are present, processing data or adding header
 For the rest of this document, PDU provided by network layer are denoted as N_PDU, similarly for N_PCI and N_SDU

91
Diagnostic Over CAN
Problem - Overview
 Requirement: ECU must be able to provide Vehicle Identification Number (VIN)
via a diagnostic read service
Example
Tester: 22 F1 90
ECU: 62 F1 90 31 48 47 42 48 34 31 58 4A 4D 4E 31 30 39 31 38 36
(ASCII translation: 1HGBH41XJMN109186)

 Problem:
 VIN according to automotive standard are 17-byte long
 UDS protocol requires 3 more bytes to specify for the service
 CAN protocol only allows 8 bytes in the data field at max

92
Diagnostic Over CAN
Problem – VIN Format

93
Diagnostic Over CAN
Problem – CAN Frame Format

CRC ACK
Arbitration Field Control Field Data Field
Field Field
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0

CANNOT FIT IN???

UDS Protocol VIN Data

Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte
#1 #2 #3 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17
7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
62 F1 90 31 48 47 42 48 34 31 58 4A 4D 4E 31 30 39 31 38 36

94
Diagnostic Over CAN
Single-frame Transmission
 Data can be fitted in single CAN frame

 No segmentation is needed

 Network layer data packet for this case

is call SingleFrame (SF)

95
Diagnostic Over CAN
Multi-frame Transmission
 Data doesn’t fit a single CAN frame

 Network layer segments the data into multiple CAN

frames (FF and CF)
 FirstFrame (FF) contains the total length
 ConsecutiveFrame (CF) contains respective sequence number

 FlowControl is provided by receiver, to adjust the sender

to the network layer capacities of receiver

96
Diagnostic Over CAN Tester ECU
N_PDU Definition – Single Frame
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0
7-0 7-0 7-0 7-0 7-0 7-0 7-0
FT DL
0 3 22 F1 90 x x x x

 FT: Frame Type: 0x0 for Single Frame

 DL: Data Length, maximum 7 for Single Frame

97
Diagnostic Over CAN Tester ECU
N_PDU Definition – First Frame
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0
FF: 10 14 62 F1 90 31 48 47

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte
Byte #1 Byte #2 #3 #4 #5 #6 #7 #8
7-4 3-0 7-4 3-0
7-0 7-0 7-0 7-0 7-0 7-0
FT DL
1 0 1 4 62 F1 90 31 48 47

 FT: Frame Type: 0x1 for First Frame

 DL: total Data Length, maximum 4096 for First Frame
 First Frame contains 1st 6 bytes of total payload

98
Diagnostic Over CAN  FT: Frame Type: 0x3 for Flow Control
N_PDU Definition – Flow Control
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
 FS: Flow State
SOF

EOF
Identifier RTR Res DLC
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Deli Ack Deli  0x0: CTS – continue to send
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0  0x1: WT – wait
 0x2: OVFLW – overflow
N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte
 BS: Block Size
Byte #1
#2 #3 #4 #5 #6 #7 #8  0x00: no more FC needed
7-4 3-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
 0x01..0xFF: max number of CFs can be sent
ST
FT FS BS N/A N/A N/A N/A N/A until the next FC
min
3 0 00 00 x x x x x

 Note: no data for FC  STmin: Separation Time Minimum

 0x00..0x7F: 0..127 ms
 0xF1..0xF9: 100..900 us

99
Diagnostic Over CAN Tester ECU
N_PDU Definition – Flow Control
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0
FF: 10 14 62 F1 90 31 48 47

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte FC: 30 00 00
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
ST
FT FS BS N/A N/A N/A N/A N/A
min
3 0 00 00 x x x x x

100
Diagnostic Over CAN Tester ECU
N_PDU Definition – Consecutive Frame
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0
FF: 10 14 62 F1 90 31 48 47

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte FC: 30 00 00
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0
7-0 7-0 7-0 7-0 7-0 7-0 7-0
FT SN CF: 21 42 48 34 31 58 4A 4D
2 1 42 48 34 31 58 4A 4D
2 2 4E 31 30 39 31 38 36

STmin CF: 22 4E 31 30 39 31 38 36
 FT: Frame Type: 0x2 for Consecutive Frame
 SN: Sequence Number, initial 0x1, range 0x0..0xF

101
Diagnostic Over CAN
N_PDU Definition - Summary

N_PDU
Byte Byte Byte Byte Byte Byte Byte
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
Single Frame 0 DL Data
First Frame 1 DL Data
Consecutive Frame 2 SN Data
Flow Control 3 FS BS Stmin N/A

N_PCI
N_SDU

102
Diagnostic Over CAN Receiver Sender
Timing Parameters
Timing SF
Timeou Performance
Paramet Description
t (ms) (ms)
N_Ar
er
Time for transmission of the
N_As CAN frame (any N_PDU) on 1000 N/A FF
the sender side N_As
Time for transmission of the
N_Ar CAN frame (any N_PDU) on 1000 N/A N_Br
the receiver side FC N_Bs
Time until reception of the
N_Ar
N_Bs 1000 N/A
next FC N_PDU N_Cs
N_Br
Time until transmission of the
N/A
(N_Br + N_Ar) N_Cr CF
next FC N_PDU < (0.9 * N_Bs) N_As
Time until transmission of the (N_Cs + N_As)
N_Cs N/A < (0.9 * N_Cr) N_Cs
next CF N_PDU
N_Cr CF
Time until reception of the
N_Cr 1000 N/A N_As
next CF N_PDU

103
Thank you!

10
4