Vector Diagnostics Seminar

Automotive Diagnostics Development
A Technical Seminar
Topics:
The Evolution of Automotive Diagnostic Technology
Legislative Considerations
Diagnostic Standards So Many to Choose From
ECU Addressing Who am I Talking Too?
Unlocking the Secrets of ISO 15765-2 Transport Protocol
Understanding UDS (ISO 14229)
Running UDS on Different Buses (J1939, Ethernet, FlexRay, etc.)
ODX What it is, and What it isnt
An ECU Diagnostic Development Process from A to Z
The Future of Diagnostic Technology
The Evolution of Automotive Diagnostic Technology
June, 2014
2013 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V 0.01
2013-11-25
Agenda
Slide: 2
Basic Concepts A Visit to the Doctor
Something is wrong with the car but what?

Ask questions and run tests
ECUs know their own health
ECUs can communicate this information
Isolate the problem
Make the fix

Repair (replace) failing part(s)
Is the problem gone?

Go back and repeat questions and tests
Clean bill of health?
Slide: 5
But How Does it Know??

Onboard Diagnostics
Self tests are executed in parallel to actual system operation
Faults are detected and logged internally
Internal test routines are available for single-shot execution
Functionality created to interface with off-board diagnostic tools
Slide: 6
Why Do We Need It?
Slide: 7
Slide: 8
Today: Its not brain surgery, but its close.
Slide: 9
Goals and Benefits

Goals
Verify function and performance of electrical & mechanical systems
Ensure components are fault free while meeting functional duties
Accurately identify specific failure modes
Benefits
Vehicle delivered from assembly plant to dealer in working order
Vehicle serviced correctly and on time during first visit to dealer
Accurately identify smallest necessary fix
Proper operation of emissions control systems
Reduced operational and warranty costs

Good
A/D
Fail
Slide: 10
Who Cares?
Slide: 11
Applications and Users Engineering

ECU development (test implementation and functionality)
Vehicle integration (verify interaction with other ECUs)
Calibration (monitor/calibrate performance, hot/cold trips)
Testing (proving grounds, component and vehicle durability testing)
EMC testing (electro-magnetic compatibility with rest of vehicle & FCC)
Slide: 12
Applications and Users Manufacturing
EOL testing (verify vehicle was built correctly and in working order)
Flash programming (program ECU at supplier or on assembly line)
Configuration and calibration (configure ECU on assembly line)
Repair bay (identify failures and verify repairs)
Audit bay (verify quality and compliance)

Slide: 13
Applications and Users Service
In-service emissions testing
Troubleshoot customer complaints
Identify failures and warrantee issues
Verify repairs
Flash re-programming updates

Slide: 14
Evolution, or Revolution?
Slide: 15
Implementation Concept How Does It Work?

ECU communicates with offboard test device

1. Tester asks a question
2. ECU responds
Client-server relationship
Tester is client
ECU is server
ECU only speaks when
spoken to
Diagnostic messaging only
happens when tester is
present
Not part of normal mode
ECU-to-ECU messaging
Slide: 16
Evolutionary History Point-to-Point Links
Proprietary point-to-point links (start in early 1980s)

Implied address tin cans on a string model
Simple UART-based line drivers
Simple send-a-byte/get-a-byte protocols
Everything was proprietary
Still hanging on in production
Slide: 17
Evolutionary History Point-to-Point Links (continued)
Standardized point-to-point links (start in early 1990s)

Logically addressed telephone party-line model
Still UART-based line drivers
More powerful send-a-message/get-a-message protocols
Standardized regulations and tools began to appear
ISO-9141 (K-line) becomes global standard
Still in wide use
Slide: 18
Evolutionary History Multiplexed Data Links
Proprietary multiplexed networks (start in late 1980s)

Logically addressed Ethernet model with collision arbitration
Network carries non-diagnostic messages between ECUs
Back to proprietary protocols and interface hardware
Industry diverged
Lack of standardization precluded use with legislated diagnostics
Still hanging on in production
Slide: 19
Evolutionary History Multiplexed Data Links (continued)
Standardized multiplexed networks (start in mid 1990s)

Industry standard network hardware
Industry standard protocols
Industry standard tools
Rapidly replacing all previous vehicle network types
Industry and regulatory convergence is here
Slide: 20
Legislative Considerations
June, 2014
V 0.01
2013-11-25
OBD What are Legislated Diagnostics?
OBD On-Board Diagnostics or Legislated Diagnostics

Emissions-related diagnostics required by the government

Standardized networks, protocols and test tools
Meet the requirements or pay a fine
All OEMs selling vehicles in the US must comply
Enhanced Diagnostics Non-legislated Diagnostics

Every OEM defines their own enhanced diagnostics strategy

Proprietary protocol, data dictionary and application
Driven by quality and warranty, not the government
Covers entire vehicle not just emissions
Slide: 2
Legislative Groups Whos Driving?

CARB (California Air Resources Board)
Earliest driver of emissions legislation for air quality improvement
EPA (US Environmental Protection Agency

Typically adopts CARB standards
EU (European Commission)
Fairly loose in early years, recently more stringent
Other Countries
See following tables
Slide: 3
Taken from Dave Ferris (GM Emission Compliance & Certification) presentation at the SAE 2013 On-Board Diagnostics Symposium
Slide: 4
Taken from Dave Ferris (GM Emission Compliance & Certification) presentation at the SAE 2013 On-Board Diagnostics Symposium
Slide: 5
Standards Organizations Whos Driving?
SAE (Society of Automotive Engineers)

Primarily a US activity
Most sensitive to EPA and CARB requirements
Most sensitive to US industry participants
More focus on global topics, as legislation goes global
ISO
ISO specific global driver
Sensitive to US, but also UN, EU and future legislation
Sensitive to all industry participants worldwide
Slide: 6
Legislative Considerations Diagnostic Communications

US California Air Resources Board (CARB)
CARB California Code of Regulations (CCR) 1968.2 (Vehicles < 14000 lbs.)
CARB CCR 1971, Engine Manufacturer Diagnostics (EMD), (Vehicles > 14000 lbs.)
CARB CCR 1971.1, OBD System Requirements for 2010 and later Model-Year Heavy-Duty Engines (HD-OBD)
US Environmental Protection Agency (EPA)

EPA, Title 40, CFR 86.8005-4, CFR 86.005-17, CFR 86.1806-05
Typically follows CARB legislation
EU European Commission (EC)

EURO 3, 4, 5, 6, etc.= pass cars & light duty vehicles. EURO III, IV, V, VI, etc. = HD vehicles
UN/ECE Regulation Nbr. 83/2008 (light duty regs)
UN/ECE Regulation Nbr. 49/2008 (heavy duty regs)
Diagnostic Communications Requirements Summary:

CCR 1968.2 (LD)
SAE J1979
CCR 1971.1 (HD)
SAE J1979 or SAE J1939
UN/ECE Reg 83/2008 (LD)
ISO 15031-4 (SAE J1979)
UN/ECE Reg 49/2008 (HD)
ISO 27145-3 or SAE J1939-73
Slide: 7
Legal Requirements
Necessity of Diagnostics in Motor Vehicles
EOBD (European On Board Diagnostics)
MIL
Cars, gasoline starting 2000

Cars, diesel
Trucks
US OBD (US On Board Diagnostics)
Cars & Class 1-7 Trucks

(OBDII ISO9141, J1850, CAN)
Cars & Class 1-7 Trucks (CAN only required)

Trucks (Class 8)
Model Year
96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13
Source: www.obd-2.de
Slide: 8
Legal Requirements
OBD-II connector (SAE J1962)
PIN
Function
Discretionary
Bus positive line of SAE J1850
Discretionary
Chassis ground
Signal ground
CAN_H line of ISO 15765-4
K line of ISO 9141-2 and ISO 14230-4
Discretionary
Discretionary
10
Bus negative line of SAE J1850
11
Discretionary
12
Discretionary
13
Discretionary
14
CAN_L line of ISO 15765-4
15
L line of ISO 9141-2 and ISO 14230-4
16
Permanent positive voltage
OBD-II connector
Slide: 9
Diagnostic Standards So Many to Choose From
June, 2014
V 0.01
2013-11-25
Dazed & Confused
Slide: 2
Diagnostic Standards
Open Standards
ISO 15765 Diagnostics on CAN
ISO 15031 Diagnostics for Emissions Related

Systems (Incorporates; J1930, J1962, J1978, J1979,
J2012, J2186)
UDS (ISO 14229) Unified Diagnostic Services
KWP2000 (ISO 14230) Key Word Protocol 2000
SAE J2534 Pass-Thru Flash Programming
ODX (ISO 22901) Open Diagnostic Data Exchange
WWH-OBD (ISO 27145) World-wide Harmonized

OBD
MVCI (ISO 22900) Multi Vehicle Communications

Interface
OEM Standards
GM GMW3110
Ford GGDS and MDX
Chrysler KWP2000, UDS, DDT, DPRS
Plus Toyota, FIAT, VW, Daimler, Porsche, BMW
Coming Soon
Slide: 3
Typical Diagnostic Standards: Car/Truck SAE/ISO

Current Standards:
SAE
ISO
Manf Specific
Pass Car & LD

Veh
(KWP & UDS)
J1930
J1962
J1978
J1979
J2012
J2186
J2284
J2411
J2534
ISO 11898 (5 parts)

ISO 15765(4 parts)
ISO 14230 (4 parts)
ISO 14229 (1 part)
ISO 15031 (7 parts)
ISO 22900 (3 parts)
ISO 22901 (2 parts)
ISO 27145 (4 parts)
Several
MD & HD Veh
(J1939)
J1939 (12 parts)

J2403
ISO 27145 (4 parts)
Several
In some cases multiple standards will be mixed on the same vehicle

Slide: 4
Diagnostic Standards: Past Present - Future

Pass Car & LD Veh
MD & HD Veh
Past
ISO9141
J1850
J1708
J1587
Present
J1930
J1962
J1978
J1979
J2012
J2186
J2284
J2411
J2534
ISO11898
ISO15765
ISO14230
ISO14229
ISO15031
ISO22901
J1939
J2403
Future
ISO27145 (WWH OBD) ??
J1939 ??
ISO27145 (WWH OBD) ??
Slide: 5
Apples to Apples
OSI
Layer
MD & HD Standards &

OBD Legislated
Pass Car & LD

Standards
Pass Car & LD OBD

Legislated
Diagnostic
Connector
SAE J1939-13
ISO 15031-3
ISO 15031-3
(SAE J1962)
(SAE J1962)
Application
SAE J1939-71/73
SAE J1939-81
ISO 15765-3
ISO 14229-1
ISO 15031-5
Presentation
User Defined
ISO 15031-5
(GMW3110, GGDS, KWP2000, etc.)
(SAE J1979)
Session
ISO 15765-3
Transport
Protocol
ISO 15765-2
ISO 15765-2
Network
Layer
SAE J1939-31
ISO 15765-2
ISO 15765-4
Data Link
SAE J1939-21
ISO 11898-1
ISO 15765-4
Physical Layer
SAE J1939-11/15
User Defined
ISO 15765-4
(J2284, J2411, ISO11898-2/3, etc.)
(ISO 11898-2)
N/A
(ISO 11898-1)
(SAE J1979)
(ISO 11898-1)
Slide: 6
Passenger Car Diagnostic Standard Reference Hierarchy
ISO 15765
2
CAN-Specific
Non-CAN / Generic
ISO 14229
ISO 15031
(UDS)
evolved
from
ISO 14230
H A R M
J1930
(KWP2000)
J1962
O N
J1978
I Z
J1979
E D
J2012
J2186
SAE Recommended Practice
Slide: 7
General
Diagnostics - International Standards (Introduction Dates)
1996
ISO 9141
CARB Requirements for Interchange of

Digital Information
1999
ISO 14230
Keyword Protocol 2000
1999
ISO/DIS 15765
Diagnostics on CAN based on KWP2000
2001
ISO 15031
Communication for emissions-related

diagnostics
2005
ISO 15765
Diagnostics on CAN based on UDS
2006
ISO/DIS 14229-1
Unified Diagnostic Services (UDS)
Slide: 8
TLAs of UDS & ISO 15765

DID = Data ID
DLC = Diagnostic Link Connector
DLC = Data Length Code
DTC = Diagnostic Trouble Code
ECM = Engine Control Module
ECU = Electronic Control Module
FTB = Failure Type Byte
KWP = Key Word Protocol (ISO 14230)
LID = Local ID
MIL = Malfunction Indicator Lamp
NRC = Negative Response Code
OBD = On Board Diagnostics
PCI = Protocol Control Information
PID = Parameter ID (similar to DID or LID)
SID = Service ID
UDS = Unified Diagnostic Services
Slide: 9
Quote to ponder
The good thing about standards is that there
are so many to choose from Keith Kreft
J1962
J2186
Slide: 10
ECU Addressing Who Am I Talking Too?
June, 2014
V 0.01
2013-11-25
Physical Interface
Many Possibilities
CAN
K-Line
ABS
Engine
Client
(Tester)
Diagnostic
Connector
Gear
CAN
ECU 2
TVTuner
Navi
X-by-Wire
Powertrain
IC
ECU 1
Flexray
Gateway
Multimedia
MOST
Comfort
CDPlayer
Telephone
CAN
Door
Roof
Seat
AC
BC
Sensor/Aktor
Sensor
Sensor
LIN
Actor
Slide: 2
Directing the Diagnostic Traffic
How does the tester get a diagnostic

message to a single ECU, anywhere on the
network, or to a group of ECUs on the
network?
Slide: 3
CAN Message Structure
11 bit or 29 bit
Slide: 4
Directing the Diagnostic Traffic

CAN IDs
Can use either 11-bit or 29-bit
Most automotive applications use 11-bit
Each ECU has two primary CAN IDs for diagnostics

one for physical (point-to-point) requests from tester
one for responses back to the tester
Each ECU will also support one/more functional CAN IDs for
broadcast messages from the tester
The tester has to know the CAN IDs for every ECU
Slide: 5
Standard CAN Format: 11-Bit Identifier

Typically usage for diagnostics: ECU Identification

Target ECU ID or Functional Request ID for diagnostic requests (source address

not required since KWP & UDS only allow one diagnostic tester on the bus at
one time)
Source ECU ID for diagnostic responses
Most OEMs have their own ID assignment standards

Identifier "identifies" the message and includes message priority
Identifier 0 is highest priority message
Slide: 6
Addressing Types
Possibilities Typically Based on CAN ID Range
Physical addressing (1:1)

Receiver known
One controller addressable
CU 3
Tester
Functional addressing (1:n)

CU 1
CU 3
Broadcast
Receiver unknown
Multiple ECUs addressable
Tester
CU 2
Slide: 7
Addressing Schemes
Normal addressing
Addressing information complete in CAN-ID
Two CAN IDs per ECU: Sending/Receiving

2n(+1)
Minimal protocol overhead
B
A
C
Extended addressing
Addressing information in first data byte
Only one CAN-ID for all requests,

one additional CAN-ID per node for
response (n+1)
Multiple bus systems
Elevated protocol overhead (1/8)
Slide: 8
Addressing Schemes
Normal fixed addressing (29 Bit CAN ID Only)

Addressing information complete in CAN-ID
Predefined structure of CAN ID

2n(+1)
J1939 uses this scheme
A
C
B
Mixed addressing
Addressing information in CAN-ID and in

in first data byte for the subnet

2n(+1)
Prio
00
Id
Mask
Tgt
Addr
7 Byte
(PCI +
Data)
address
extension
11 or 29 bit CANId
Src
Addr
address
extension
7 Byte
(PCI +
Data)
Slide: 9
Addressing scheme
Overview
Normal
Addressing
11-bit
CAN
ID
29-bit
CAN
ID
11
bit
Normal Fixed
Addressing
8Byte
(PCI+Data)
Prio
29
bit
Extended
Addressing
8Byte
(PCI+Data)
TA = Target Address
SA = Source Address
0
0
PGN
T
A
11
bit
T
A
7Byte
(PCI+Data)
29
bit
T
A
7Byte
(PCI+Data)
S
A
8Byte
(PCI+Data)
Mixed Addressing
11
bit
Prio
A
E
0
0
7Byte
(PCI+Data)
PGN
T
A
S
A
A
E
7Byte
(PCI+Data)
AE = Address Extension
SA = Source Address
Slide: 10
Automotive Diagnostic Communication Model

For the diagnostic standards
ISO14230 (KWP)
ISO14229 (UDS)
The ECU only speaks when spoken to

Listens for requests from tester

Provides diagnostic data only on request
Never sends a diagnostic request
After assembly may never be used again
Off-board
tester
ECU 1
ECU 1-Perform this task

I did it, heres the results
The tester runs the whole show

ECU 2
Must request data it wants

Must know ID of ECU to get data from
ECUs provide data requested
Does not listen to normal bus traffic
Slide: 11
Addressing Scheme
Off-board
tester
Each ECU has at least two

diagnostic CAN IDs (simplified)
one/more for requests from tester
one for responses to tester
BC 400
200
The tester must

know the CAN IDs

for every ECU

on every vehicle
from every OEM
it is working with.
208
BC 400
201
ECU 1
ECU 2
209
BC 400
202
ECU 3
20A
Slide: 12
Unlocking the Secrets of the ISO 15765-2 Transport Protocol
June, 2014
V 0.01
2013-11-25
A Quick Review of the CAN Data Field
Slide: 2
My data is longer than 8 bytes now what?
VIN #
1 B 3 H B 4 8 A 0 9 D 1 2 3 4 5 6
8 CAN Data Bytes

? ? ? ? ? ? ? ?
Slide: 3
Transport Protocol
The tasks of the transport protocol may be summarized as follows:
Segmentation and reassembly of data blocks larger than those

that can be transported per message in the underlying Data Link
Layer (Example: CAN
Only 8 bytes in one message)
Control of the data flow of individual messages
Error detection
Slide: 4
Possible Types of Data Transport
sender
UUDT
Unacknowledged Unsegmented Data Transfer
Example: A CAN message (max. 8 bytes)
receiver
Data
AUDT
Acknowledged Unsegmented Data Transfer
Example: Application protocols (ping pong)
Data
Ack.
USDT
Unacknowledged Segmented Data Transfer
Data
Example: ISO 15765-2
Data
ASDT
Acknowledged Segmented Data Transfer
Example: MCNet, Volkswagen TP 2.0
Data
Data
Ack.
Slide: 5
ISO15765-2 How Does the Transport Protocol Work?
USDT CAN Frame Structure

Data Area
SOF
ID
DLC
CRC
PCI
ACK
application data
First byte(s) of data area are used to indicate TP frame type

Official name is Network Protocol Control Information
Common name is PCI
Remaining data bytes carry application (diagnostic) data
Slide: 6
ISO15765-2 PCI Determines Frame Type
USDT CAN Frame Structure

Data Area
SOF
ID
DLC
X
PCI
CRC
ACK
application data
PCI is first byte(s) of data area

PCI bits 7-4 (upper nibble) indicate frame type
0 = single frame
1 = first frame
2 = consecutive frame
3 = flow control frame
4F are invalid and not used
Slide: 7
ISO 15765-2
Message Types
The following message types are available for data transport:

First Frame (FF)

>
Consecutive Frame (CF)

>
Second part through nth part of a segmented message
Single Frame (SF)

>
First part of a segmented message
For transport of unsegmented messages
Flow Control (FC)

>
Acknowledgment from the receiver
Slide: 8
ISO 15765-2
Summary
1 2 3 4 5 6 a n s p o r
P r
o t
24 Bytes
o c o l M C
First Frame (FF)
I S O
T r
a n s p o r
P r
o t
o c o
l M C
Flow Control (FC)

STmin
Flow Control (FC)

Focus Here
(upper nibble)
Slide: 9
TP in the Context of an ECU
Application
Diagnostics
Interaction
Layer
Network
Management
Transport
Layer
Data Link Layer
Hardware
Common Implementation Error: Passing partial information to next higher

layer, before full message content received (e.g. UDS service/subfunction
evaluated before full message received).
Slide: 10
ISO 15765-2
Single Frame Transfer
1 2 3
Single Frame (SF)
3 Bytes
I S O
Single Frame (SF)
SF 0 3
Trace View
data
Single Frame TPCI
single frame
DL
data length
Slide: 11
ISO 15765-2
Multiple Frame Transfer
The task of the transport protocol is to transport data from Node A

to Node B
There may be an underlying Layer 2 protocol that cannot accept all

of the data to be transported in a single message (Example: CAN)
A
1
I S
2 O
3 4 T
5 6
r a n s p o r
P r o t o c o l M C
24 Bytes
Slide: 12
ISO 15765-2
First Frame
1 2 3 4 5 6 a n s p o r
P r
o t
First Frame (FF)
o c o l M C
24 Bytes
I S O
T r
First Frame (FF)
FF
1 0
18
data
data length
12 bit
4095 bytes max.
First Frame TPCI
Bit
first frame
Byte 1
XDL
XDL
extended data length
Slide: 13
ISO 15765-2
Flow Control
1 2 3 4 5 6 a n s p o r
P r
o t
First Frame (FF)
o c o l M C
24 Bytes
I S O
T r
Flow Control (FC)
Flow Control (FC)
FC 3 0
02
14
separation time (STmin) in ms
minimum send interval betw. CFs
0x00 = send as fast as possible
block size* (BS)
no. of CFs until next FC
Flow Control TPCI
flow control
FS
flow state:
0
1
*block
clear to send
wait
size = 0x00: no further FC
Slide: 14
ISO 15765-2
Consecutive Frame
1 2 3 4 5 6 a n s p o r
P r
o t
o c o l M C
I S O
T r
a n s p o r
P r
o t
o c
First Frame (FF)
24 Bytes
Flow Control (FC)

0
CF 2 1

STmin
CF
2 2
data
Consecutive Frame TPCI
SN
consecutive frame
sequence number:
0x0 to 0xF
counts CFs
Slide: 15
ISO 15765-2
Flow Control
1 2 3 4 5 6 a n s p o r
P r
o t
o c o l M C
First Frame (FF)
24 Bytes
I S O
T r
a n s p o r
P r
o t
o c
Flow Control (FC)
Flow Control (FC)

0
FC 3 0

02
14
STmin
Flow Control (FC)
separation time (STmin) in ms

minimum send interval betw. CFs
block size (BS)
no. of CFs until next FC
Flow Control TPCI
flow control
FS
flow state:
0
1
clear to send
wait
Slide: 16
ISO 15765-2
Consecutive Frame
1 2 3 4 5 6 a n s p o r
P r
o t
o c o l M C
I S O
T r
a n s p o r
P r
o t
o c o
l M C
First Frame (FF)
24 Bytes
Flow Control (FC)

0
CF 2 3

STmin
data
Flow Control (FC)

Consecutive Frame TPCI
unacknowledged
t
SN
consecutive frame
sequence number:
0x0 to 0xF
counts CFs
Slide: 17
ISO 15765-2
Summary
1 2 3 4 5 6 a n s p o r
P r
o t
o c o l M C
First Frame (FF)
24 Bytes
I S O
T r
a n s p o r
P r
o t
o c o
l M C
Flow Control (FC)

STmin
Flow Control (FC)

Slide: 18
ISO 15765-2
Timing in the Transport Protocol
sender
receiver
N_As
N_Br
N_Bs
N_Ar
N_Cs
N_Cr
N_As
Slide: 19
10
Understanding UDS (ISO 14229)
June, 2014
V 0.01
2013-11-25
ISO 14229 in a Nutshell
Paraphrased from the ISO 14229 abstract:

ISO 14229:2006 specifies a set of data link independent

diagnostic services, which allow a diagnostic tester (client)
to control diagnostic functions in an on-vehicle Electronic
Control Unit (server).
It specifies services that allow the client to stop, or

resume, non-diagnostic messaging on the data link.
It does NOT apply to non-diagnostic messaging.
It does NOT specify implementation requirements.
It applies to a single client that may be temporarily, or

permanently, connected to the vehicle diagnostic data link
and several servers connected directly, or indirectly.
Slide: 2
ISO 14229 Diagnostic Services
What is a diagnostic service?

A kind of a task for an ECU to execute on command
Each service is defined by a request/response message pair
Test device sends service request message to ECU
ECU sends service response message to test device
This is the client/server communication model we discussed
Lets look at this model in a network example
Slide: 3
KWP/UDS Diagnostic Communication Model

Two similar diagnostic standards
ISO14229 (UDS)
ISO14230 (KWP)
The ECU only speaks when spoken to

Listens for service requests from tester

Provides diagnostic data only on request
Never sends a diagnostic request
Not used for normal control operations
Off-board
tester
ECU 1
ECU1-Perform this task (service ID)

ECU1 I did it, heres the results
The tester runs the whole show

ECU 2
Must request data it wants

Request data from single ECU ID..
Or send functional request (broadcast)
ECUs provide data requested
Slide: 4
ISO14229 Diagnostic Service Example

Service 22 ReadDataByIdentifier
The most basic and intuitive service
Tester is asking ECU for some piece of data
Lets ask for the engine speed
Tester sends request message (hex bytes) 22 F4 0C

22 = ReadDataByIdentifier service request identifier (SID)
F40C = Engine Speed data identifier (DID)
ECU sends response message 62 F4 0C 0F A0

62 = ReadDataByIdentifier service response identifier (SID)
F40C = Engine Speed data identifier (DID)
0FA0 = engine speed data value (0x0FA0 = 1000 RPM)
Slide: 5
ISO14229 Service Identifiers (SIDs)

Every service has a one-byte numeric identifier associated with it
This one-byte number is known as the service identifier or SID
The SID and the name of the service can be used interchangeably
The SID is the first byte of the request message
The first byte of the positive response message = SID + 0x40
From our previous engine speed example:

The ReadDataByIdentifier service has an SID of 0x22
You can refer to the service as either:

ReadDataByIdentifier
Service 22
- or
The first byte of the request message is 0x22 (the SID)
The first byte of the pos response msg is 0x62 (the SID + 0x40)
Slide: 6
UDS Standard vs. OEM Implementation
OEM Application of UDS
OEM specific data &

implementation
requirements
UDS Standard
Standardized Data
Standardized Data
Communication Services
Slide: 7
UDS Request Formats
There
Requests with Service ID only (e.g. SID 84)

SID
Opt. Data
Requests with Service ID and Subfunction

SID
are 4 different types of UDS requests
Requests with Service ID and Data ID

ID
SID
Opt. Data
SF
Opt. Data
Requests with Service ID, Subfunction and Data ID

SID
SF
ID
Opt. Data
Slide: 8
ISO14229 Service Subfunctions
What is a service subfunction?

Services indicate the kind of task, but not always the exact task
Subfunctions are specific tasks a service can perform
The subfunction is always the first byte after the SID
Not all services have subfunctions (service 22 does not)
But some do (service 11 does)
Slide: 9
ISO14229 Services with Subfunctions

Which services have subfunctions?
10 DiagnosticSessionControl
11 EcuReset
19 ReadDTCInformation
27 SecurityAccess
31 - RoutineControl
3E TesterPresent
There is no rhyme or reason to it.
85 ControlDTCSetting
It is pretty much arbitrary and you
just have to know which is which.
And which ones dont?
14 ClearDiagnosticInformation
22 ReadDataByIdentifier
23 ReadMemoryByAddress
24 ReadScalingDataByIdentifier
2A ReadDataByPeriodicIdentifier
2C DynamicallyDefineDataIdentifier
2F InputOutputControlByIdentifier
Slide: 10
Protocol Service Values
Slide: 11
The Positive Response
recessive
dominant
Request
(Client)
TPCI
22
F1
8C
00
00
00
00
01
E2
40
00
+ 0x40 DID for some

parameter
Response
(Server)
TPCI
62
F1
8C
Parameter data
Slide: 12
The Negative Response
What if the request is invalid, or the ECU cannot

perform the request?
Request
by test
tool
SID-RQ
Parameter 1
Parameter 2
Parameter 3
xx
Optional
Optional
Optional
Negative
Response
by ECU
SID-NR
Parameter 1
Parameter 2
0x7F
SID-RQ
Neg. Res. Code
Slide: 13
ISO14229 Negative Responses Codes (NRC)

For every reason an ECU can have for rejecting a request, there is an NRC

10
11
12
13
14
21
22
24
25
26
31
33
35
36
37
70
71
72
73
78
generalReject
serviceNotSupported
subFunctionNotSupported
incorrectMessageLengthOrInvalidFormat
responseTooLong
busyRepeatRequest
conditionsNotCorrect
requestSequenceError
noResponseFromSubnetComponent
failurePreventsExecutionOfRequestedAction
requestOutOfRange
securityAccessDenied
invalidKey
exceedNumberOfAttempts
requiredTimeDelayNotExpired
uploadDownloadNotAccepted
transferDataSuspended
generalProgrammingFailure
wrongBlockSequenceCounter
requestCorrectlyReceived-ResponsePending

7E subFunctionNotSupportedInActiveSession
7F serviceNotSupportedInActiveSession
81 rpmTooHigh
82 rpmTooLow
83 engineIsRunning
84 engineIsNotRunning
85 engineRunTimeTooLow
86 temperatureTooHigh
87 temperatureTooLow
88 vehicleSpeedTooHigh
89 vehicleSpeedTooLow
8A throttle/PedalTooHigh
8B throttle/PedalTooLow
8C transmissionRangeNotInNeutral
8D transmissionRangeNotInGear
8F brakeSwitch(es)NotClosed
90 shifterLeverNotInPark
91 torqueConverterClutchLocked
92 voltageTooHigh
93 voltageTooLow
Slide: 14
Request / Response Behavior
A tester (Client) sends a Request to an ECU.

If it is possible to respond to the request the ECU (Server) sends a positive
response, else a negative response)
Tester
ECU
Example (UDS):
OR
Request: Read Engine speed

(0x22 00 41)
Pos.Res: Engine speed = 1200 rpm
(0x62 00 41 04 B0 )
or
Neg.Res: General reject
(0x7F 22 10)
Slide: 15
Overview of Protocol Services
Initial Focus
Slide: 16
Excerpt from ISO 14229-1

DiagnosticSessionControl 0x10
Data byte
Request
Cvt
Hex Value
Mnemonic
#1
Parameter Name
DiagnosticSessionControl
Request Service Id
10
STDS
#2
sub-function = [
diagnosticSessionType ]
00-FF
LEV_
DS_
Hex
Response
Cvt
Mnemonic
00
ISOSAEReserved
ISOSAERESRVD
01
defaultSession
DS
02
programmingSession
PRGS
03
extendedDiagnosticSession
EXTDS
Data byte
Description
Cvt
Hex Value
Mnemonic
Response Service Id
50
STDSPR
#2
diagnosticSessionType
00-FF
DS_
#3
:
#n
sessionParameterRecord[] #1 = [
data#1
:
data#m ]
00-FF
:
00-FF
SPREC_
DATA_1
:
DATA_m
#1
Parameter Name
C
:
C
Slide: 17
PDU Parameter Conventions
Type
Name
Mandatory
The parameter can be present in the A_PDU, based on

Conditional certain criteria (e.g. subFunction/parameters within the
A_PDU).
Selection
Description
The parameter has to be present in the A_PDU.
Indicates, that the parameter is mandatory (unless

otherwise specified) and is a selection from a parameter
list.
User option The parameter may or may not be present, depending on

dynamic usage by the user.
NOTE The "<Service Name> Request Service Id" marked as 'M' (Mandatory),
shall not imply that this service has to be supported by the server. The 'M' only
indicates the mandatory presence of this parameter in the request A_PDU in
case the server supports the service.
Slide: 18

Example - DiagnosticSessionControl
Request
02
10
02
xx
xx
xx
xx
xx dont care
xx
DiagnosticSessionType - ProgrammingSession
Request - DiagnosticSessionControl
TPCI - SingleFrame
Pos.Response
02
50
02
xx
xx
xx
xx
xx
Pos.Response (SID + 0x40)
TPCI - SingleFrame
Neg.Response
03
7F
10
22
xx
xx
xx
xx
NRC Type Conditions not correct

Neg.Response
TPCI - SingleFrame
Slide: 19

EcuReset 0x11
Request
Data
byte
Parameter Name
Hex
Value
11
ER
00-FF
LEV_
RT_
#1
EcuReset Request Service Id
#2
sub-function = [
resetType ]
Hex
Response
Cvt
Mnemonic
Cvt
Mnemonic
00
ISOSAEReserved
ISOSAERESRVD
01
hardReset
HR
02
keyOffOnReset
KOFFONR
03
softReset
SR
04
enableRapidPowerShutDown
RPSD
Description
05
disableRapidPowerShutDown
DRPSD
Parameter Name
Data
byte
Cvt
Hex
Value
Mnemonic
ERPR
#1
EcuReset Response Service Id
51
#2
resetType
00-FF
RT_
#3
powerDownTime
00-FF
PDT
Slide: 20
10

Example - ECU Reset
Request
02
11
03
xx
xx
xx
xx
xx dont care
xx
ECUReset Type - SoftReset

Request - ECUReset
TPCI - SingleFrame
Pos.Response
02
51
03
xx
xx
xx
xx
xx
ECUReset Type - SoftReset

TPCI - SingleFrame
Neg.Response
03
7F
11
22
xx
xx
xx
xx

ECUReset
Neg.Response
TPCI - SingleFrame
Slide: 21

ClearDiagnosticInformation 0x14
Request
Response
Parameter Name
Cvt
Hex
Value
#1
ClearDiagnosticInformation Request Service Id
14
CDTCI
#2
#3
#4
groupOfDTC[] = [
groupOfDTCHighByte
groupOfDTCMiddleByte
groupOfDTCLowByte ]
M
M
M
00-FF
00-FF
00-FF
GODTC_
HB
MB
LB
Data
byte
Mnemonic
Data
byte
Parameter Name
Cvt
Hex
Value
Mnemonic
#1
ClearDiagnosticInformation Positive Response

Service Id
54
CDTCIPR
Slide: 22
11

Example - ClearDiagnosticInformation
Request
04
14
00
00
00
xx
xx
xx dont care
xx
Group of DTC
Request - ClearDiagnosticInformation
TPCI - SingleFrame
Pos.Response
01
54
xx
xx
xx
xx
xx
xx

TPCI - SingleFrame
Neg.Response
03
7F
14
22
xx
xx
xx
xx

ClearDiagnosticInformation
Neg.Response
TPCI - SingleFrame
Slide: 23

ReadDataByIdentifier 0x22
Request
Cvt
Hex
Value
Mnemonic
#1
ReadDataByIdentifier Request Service Id
22
RDBI
#2
#3
dataIdentifier[] #1 = [
byte#1 (MSB)
byte#2 ]
M
M
00-FF
00-FF
DID_
B1
B2
U
U
00-FF
00-FF
DID_
B1
B2
Parameter Name
Cvt
Hex
Value
Mnemonic
#1
ReadDataByIdentifier Response Service Id
62
RDBIPR
#2
#3
dataIdentifier[] #1 = [
byte#1 (MSB)
byte#2 ]
M
M
00-FF
00-FF
DID_
B1
B2
data#k ]
M
:
U
00-FF
:
00-FF
DREC_
DATA_1
:
DATA_m
:
#n-1
#n
Response
Parameter Name
Data
Byte
dataIdentifier[] #m = [
byte#1 (MSB)
byte#2 ]
Data
Byte
#4
:
#(k-1)+4
:
dataRecord[] #1 = [
data#1
:
Slide: 24
12

Example 1- ReadDataByIdentifier
Request
03
22
F1
86
xx
xx
xx
xx
xx dont care
Data Identifier - ActiveDiagnosticSession

Request - ReadDataByIdentifier
TPCI - SingleFrame
Pos.Response
04
62
F1
86
02
xx
xx
xx
Data Identifier - ActiveDiagnosticSession
TPCI - SingleFrame
Neg.Response
03
7F
22
22
xx
xx
xx
xx

ReadDataByIdentifier
Neg.Response
TPCI - SingleFrame
Slide: 25

Example 2- ReadDataByIdentifier
Request
05
22
01
0A
01
10
xx
xx
xx dont care
2x Data Identifier
Request - ReadDataByIdentifier
TPCI - SingleFrame
Pos.Response
07
62
01
0A
55
01
10
66
Data Identifier 2 + data

Data Identifier 1 + data
TPCI - SingleFrame
Slide: 26
13

WriteDataByIdentifier 0x2E
Request
Data Byte
#1
#2
#3
#4
:
#m+3
Parameter
Cvt
Hex Value
Mnemonic
2E
WDBI
dataIdentifier[] = [
byte#1 (MSB)
byte#2 ]
M
M
00-FF
00-FF
DID_
HB
LB
dataRecord[] = [
data#1
:
data#m ]
M
:
U
00-FF
:
00-FF
DREC_
DATA_1
:
DATA_m
Cvt
Hex Value
Mnemonic
6E
WDBIPR
M
M
00-FF
00-FF
DID_
HB
LB
WriteDataByIdentifier Request
Service Id
Response
Data Byte
#1
#2
#3
Parameter
WriteDataByIdentifier Response
Service Id
dataIdentifier[] = [
byte#1 (MSB)
byte#2 ]
Slide: 27

Example - WriteDataByIdentifier
Request
07
2E
F2
90
57
30
4C
30
xx dont care
data
Data Identifier ECU Software Level
Request - WriteDataByIdentifier
TPCI - SingleFrame
Pos.Response
03
6E
F2
90
xx
xx
xx
xx
Data Identifier ECU Software Level

TPCI - SingleFrame
Neg.Response
03
7F
2E
22
xx
xx
xx
xx

WriteDataByIdentifier
Neg.Response
TPCI - SingleFrame
Slide: 28
14
Session & Security Management
Some diagnostic features should not be easily accessible.

Examples:
I/O Control
Flash Programming
Writing ECU Configuration Information
How are these protected?

By using special sessions or security
Slide: 29
Session Management
ECUs can support several sessions
Typical ECU sessions are: Default Session, Extended Session and

Programming Session
Some diagnostic services can only be executed in a special

session
Sessions can support different timing parameters
As a result of a diagnostic service a state transition can be

effected
Normally an ECU starts in default session after power on
Slide: 30
15
Session Management
Example
Power On
K
To change a session into an ECU

the protocol service 0x10
DiagnosticSessionControl is used
Parameter
Default Session:
0x10 01
Programming Session:
0x10 02
Extended Session:
0x10 03
Slide: 31
Security Access
Some diagnostic data or services can be restricted due to safety

reasons. To get access to these ECUs a Seed&Key process is used.
Tester
ECU
Calc Key
Compare Key
If (Key = Key)
unlock ECU
Slide: 32
16
ISO14229 Service 19 ReadDTCInformation
The most valuable and frequently used service

Tester asks the ECU for its state of health and any observed failures
Failures are specified with a three-byte identifier called a DTC
DTC = Diagnostic Trouble Code
Allows tester to read fault-related data stored in ECU memory

This is the very foundation of all vehicle diagnostics
ECUs monitor their own state of health with diagnostic monitors
These monitors generate a lot of data
This data is stored indefinitely in the ECUs non-volatile memory
Testers can recall this data at a later time during testing and service
When ECU diagnoses itself with a failure, it stores a DTC
Slide: 33
ISO14229 Service 19 ReadDTCInformation

Available sub functions of service 19:
01 reportNumberOfDTCByStatusMask
02 reportDTCByStatusMask
03 reportDTCSnapshotIdentification
04 reportDTCSnapshotRecordByDTCNumber
05 reportDTCSnapshotRecordByRecordNumber
06 reportDTCExtendedDataRecordByDTCNumber
07 reportNumberOfDTCBySeverityMaskRecord
08 reportDTCBySeverityMaskRecord
09 - reportSeverityInformationOfDTC
0A reportSupportedDTC
0B reportFirstTestFailedDTC
0C reportFirstConfirmedDTC
0D reportMostRecentTestFailedDTC
0E - reportMostRecentConfirmedDTC
0F reportMirrorMemoryDTCByStatusMask
10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber
11 reportNumberOfMirrorMemoryDTCByStatusMask
12 reportNumberOfEmissionsOBDDTCByStatusMask
13 reportEmissionsOBDDTCByStatusMask
14 reportDTCFailedDetectionCounter
15 reportDTCWithPermanentStatus
16 reportDTCExtDataRecordByRecordNumber
17 reportUserDefMemoryDTCByStatusMask
18 reportUserDefMemoryDTCSnapshotRecordByDTCNumber
19 - reportUserDefMemoryDTCExtDataRecordByDTCNumber
Slide: 34
17
ISO14229 Service 19 Example

Lets suppose we want to know what DTCs are problems right now
Tester sends request message 19 02 08
19 = ReadDTCInformation service request identifier (SID)
02 = reportDTCByStatusMask mode (19 has many different modes)
08 = confirmedDTC status mask (just DTCs whose status = failed)
ECU sends response message 59 02 08 06 20 13 8A
59 = ReadDTCInformation service response identifier (SID)
02 = reportDTCByStatusMask mode
08 = confirmedDTC status mask
062013 = DTC Generator Control Circuit circuit open
8A = status mask for DTC 062013
Slide: 35
ISO14229 Diagnostic Trouble Codes (DTCs)
ECUs communicate their failures via three-byte numeric identifiers

This number is known as a diagnostic trouble code or DTC
Root DTC
The first two bytes (16 bits) of the DTC
Identifies the ECU component that has failed
The upper two bits of the root identify the major system
>
00 = P-code for Powertrain
>
01 = C-code for Chassis
>
10 = B-code for Body
>
11 = U-code for Network (I dont get it either)
FTB Failure Type Byte

The last byte (8 bits) of the DTC
Identifies the failure mode detected by the ECU
Slide: 36
18
ISO14229 (UDS) Diagnostic Trouble Code
DTC
Byte 1
Byte 2
Byte 3
Root SAE Code Number
FTB
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
5th Character of SAE Code (0-F)

4th Character of SAE Code (0-F)
3rd Character of SAE Code (0-F)
2nd Character of SAE Code (0,1,2,3)
1st Character of SAE Code (P,C,B,U)
Slide: 37
ISO14229 DTC Failure Type Bytes

What failure type bytes are there?
A lot!
Consult ISO15031-6 for the complete list
What does the failure type byte tell me?

Exactly how the component specified by the root DTC failed
This ties in with the FMEA activity Failure Mode Engineering Analysis
What failure modes can a component exhibit?
There is probably an FTB pre-defined that meets your needs
Example FTBs from ISO15031-6

4B over temperature
72 actuator stuck open
7B low fluid level
Slide: 38
19
ISO14229 FTBs and Wiring Faults

Wiring faults are the most common type of failure
Wiring is difficult to install properly
Little or no protection from pulling, bending, cutting, interference
Common wiring failures and their Failure Type Bytes (FTBs)

11 circuit short to ground

12 circuit short to battery

line exposed to ground - voltage pulled low
line exposed to power - voltage pulled high
13 open circuit
line broken - resistance is infinite
Open circuit accounts for most failures and deserves attention

Slide: 39
ISO14229 DTC Status Byte
DTCs have status information associated with them

There are eight independent states possible
Each state is represented as a bit in a status byte
Bit 7 warningIndicatorRequest
Bit 6 testNotCompletedThisMonitoringCycle
Bit 5 testFailedSinceLastClear
Bit 4 testNotCompletedSinceLastClear
Bit 3 confirmedDTC
Bit 2 pendingDTC
Bit 1 testFailedThisMonitoringCycle
Bit 0 testFailed
Slide: 40
20
ISO14229 DTC Status Byte Example
Lets go back to our service 19 example...

Tester sends request message 19 02 08
19 = ReadDTCInformation service request identifier (SID)
02 = reportDTCByStatusMask mode
We want to read just the DTCs with a specific status
Could be any number of DTCs coming back in response
08 = confirmedDTC status mask

In this case, we want just those that are confirmed failures
08 = 0000 1000; bit 3 confirmedDTC = 1, all others = 0
Slide: 41
ISO14229 DTC Status Byte Example (continued)
Lets go back to our service 19 example...

ECU sends response message 59 02 08 06 20 13 8A
59 = ReadDTCInformation service response identifier (SID)
02 = reportDTCByStatusMask mode (echoed from request)
08 = confirmedDTC status mask (echoed from request)
062013 = DTC Generator Control Circuit circuit open
8A = status mask for DTC 062013

8A = 1000 1010
>
Bit 7 warningIndicatorRequested = 1
>
Bit 3 confirmedDTC = 1
>
Bit 1 testFailedThisMonitoringCycle = 1
>
So, not only is the DTC confirmed,

but it continues to fail and is illuminating the engine lamp
Slide: 42
21
Reprogramming
For reprogramming the following services are relevant
85
Control DTC Setting (to enable/disable DTC

setting)
28
Communication Control: enable/disable

normal bus communication for ECUs
34
Request Download
36
Transfer Data (transfers data)
37
Request Transfer Exit
Slide: 43
Periodic Reading
2A
SF
ID Read Data By Periodic Identifier
The service
starts periodic sending of data by the ECU.
The following subfunctions are supported
SF
Description
01
Send At Slow Rate
02
Send At Medium Rate
03
Send At Fast Rate
04
Stop
Slide: 44
22
Suppress Positive Response Message Indicator Bit
Tester
SF
MSB
SID
7
MSB
Description
Positive Response - not suppressed
Positive Response - suppressed
Only applies to subfunctions, not services, DIDs or any other ID
Setting SPRMIB to 1 is the same as adding 0x80 to the subfunction
Only suppresses positive response, not negative response
Slide: 45
ISO14229 SPRMIB Example

First, without using the SPRMIB
Tester sends request message 85 01
85 = ControlDTCSetting service request identifier (SID)
01 = on, the subfunction
ECU sends response message C5 01

C5 = ControlDTCSetting service response identifier (SID)
01 = on, the subfunction
Now, lets set the SPRMIB to 1

Tester sends request message 85 81
85 = ControlDTCSetting service request identifier (SID)
81 = on, the subfunction with the SPRMIB (upper bit) set to 1
ECU turns DTC setting on, but does not send a positive response
Slide: 46
23
ISO14229 Service 2F InputOutputControlByIdentifier

Some DIDs represent I/O values
I/O devices and values are also DIDs
I/O DIDs can be controlled by testers
Control modes
02 = freezeCurrentState
Hold the DID at its current value
For inputs this means ignore incoming changes
For outputs this means locking the value
03 = shortTermAdjustment
Temporarily control the DID value
For inputs this means substituting for the incoming value
For outputs this means overriding the control algorithm
00 = returnControlToEcu
Slide: 47
ISO14229 Service 2F Example
Lets suppose we want to control the cabin fan

Tester sends request message 2F 9B 1D 03 64
2F = InputOutputCotnrolByIdentifier service request identifier (SID)
9B1D = Cabin Fan Speed data identifier (DID)
03 = shortTermAdjustment (temporary override/control)
64 = Cabin Fan Speed data value (0x64 = 100rpm)
ECU sends response message 6F 9B 1D 03 64

6F = WriteDataByIdentifier service response identifier (SID)
9B1D = Cabin Fan Speed data identifier (DID)
03 = shortTermAdjustment (temporary override/control)
64 = Cabin Fan Speed data value (0x64 = 100rpm)
Slide: 48
24
ISO14229 Service 3E TesterPresent
Doesnt do anything, but helps manage diagnostic applications

Some diagnostic services have persistent behavior, like:
Diagnostic session changes via Service 10
Security access changes via Service 27
Controlling DTC setting via Service 85
Output device control via Service 2F
Routines run via Service 31
These services must be actively supervised by the tester

They drive behavior outside the normal operations of the ECU
If the tester should lose contact with the ECU, the service must stop
TesterPresent allows the tester to stay in touch with the ECU,

but doesnt cause the ECU to do anything extra
Slide: 49
ISO14229 Service 3E Example

Tester sends request to stop setting DTCs 85 02
Temporary state that only makes sense during test procedure
But what if the tester is accidentally disconnected?
The ECU can not stay in this mode forever
How does the ECU know how long to continue?
There is a timeout on all such persistent services
If ECU stops getting requests, it must assume the tester disconnected
Left unsupervised by the tester, the ECU must stop all persistent services
Tester sends a TesterPresent request 3E 00

There is nothing more for the ECU to do but continue not setting DTCs
The tester send yet another TesterPresent message 3E 00

The ECU continues not setting DTCs
This can go on for as long as the tester wants it to continue

Slide: 50
25
ISO14229 Service 3E TesterPresent
Some important timing parameters:

P2 = Maximum time to start response after message sent
P2 Ext = Additional time allowed for response to start, after a NRC 0x78
is received
S3 = Maximum time allowed in non-default session without some type of
message activity from the tester (0x3E Tester Present, or other
message)
NRC 0x78 = Negative Response Code transmitted if need more time to
respond
Slide: 51
ISO14229DiagnosticSessionControl
ISO14229
Service 10 DiagnosticSessionControl
Revisited
Session Transitions with S3 timeout

start
2
3
4
5
0
1
default
Session
extended
programming
10 02
Diagnostic
Session
Session
Slide: 52
26
Running UDS on Different Bus Types
June, 2014
V 0.01
2013-11-25
UDS is Designed to Work on Multiple Bus Types
From ISO 14229-1:
Slide: 2
ISO 14229 Restructured
Part 1: Specification and requirements
Part 2: Session layer services
Part 3: Unified diagnostic services on CAN implementation

(UDSonCAN)
Part 4: Unified diagnostic services on FlexRay implementation

(UDSonFR)
Part 5: Unified diagnostic services on Internet Protocol

implementation (UDSonIP)
Part 6: Unified diagnostic services on K-Line implementation

(UDSonK-Line)
Part 7: Unified diagnostic services on Local Interconnet Network

(UDSonLIN)
Slide: 3
Coexistence of UDS & J1939
Slide: 4
UDS/KWP Message Compared to J1939 Message

Single Frame Message
J1939
Cyclic Diagnostic Messages (e.g. DM1)
- or -
Tester
ECU
[[Prio + Request PGN + Dest Addr + Src Addr] [Requested PGN]]
[[Prio + Requested PGN + Dest Addr + Src Addr] [PGN Data]]
UDS/KWP
[[Target ID] [Requested Service + Requested Data]]
ECU
Tester
[[Source ID] [Requested Service ID + Requested Data]]
(Services can be data requests, fault code

requests, output control, special test requests,
security access, reprogramming requests, etc.)
Slide: 5
J1939 and ISO15765 Coexistence on the same CAN bus
There 2 are ways defined to allow for ISO 15765 communication to occur on
a J1939 bus
One way is using J1939 PGNs. The structure of the CAN ID is exactly the
same as any other J1939 message
There are 4 reserved J1939 PGNs for this purpose:

0x00CD00 Mixed Addressing Functional
0x00CE00 Mixed Addressing Physical
0x00DA00 Normal fixed addressing Physical
0x00DB00 Normal fixed addressing Functional
Note that these PGNs are Destination Specific and both data page bits are
zero!
In current projects within Deere this method is used, with PGN 0x00DA00
Slide: 6
J1939 and ISO15765 Coexistence
The second way formats the CAN ID in a way that will not interfere with any
other CAN IDs on the J1939 Network
The two Data Page bits (EDP and DP) are set to 1. Differentiates these
messages from any other on the network to avoid conflicts.
Everything else in the CAN ID is particular to ISO-15765 definition
Note that the Source Address and Destination Address fields shown here are
NOT the same as the J1939 Source and Destination Addresses!
There are other means defined in ISO17565 to use both 11 bit and 29 bit
CAN IDs which are not compatible with J1939. These might be used in
automobile networks for example.
Slide: 7
J1939 DMs Compared to UDS Services

J1939 Diagnostic Message:
DM1 Active DTCs
Similar UDS Service:

$19 $02 Report DTCs by Status
DM2 Previously Active DTCs
DM3 Clear/Reset DTCs
$14 Clear DTCs
DM4 Freeze Frame Data
$19 $05 Report Freeze Frame
DM5 Diagnostic Readiness
$19 $01 Report # DTCs by Status
DM6 Pending DTCs
DM7 Command Non-Cont Test
$31 $01 Start Routine
DM8 Results for Non-Cont Test
$31 $03 Routine Results
DM9 O2 Sensor Test Results
$31 $03 Routine Results
DM10 Non-Cont Tests Supported
- No Equivalent -
DM11 Clear/Reset Active DTCs
$14 Clear DTCs
DM12 Emissions Related Active DTCs
DM13 Start/Stop Broadcast Messages
$28 Communication Control
DM14 Memory Access Request
$23 Read Memory by Address
DM15 Memory Access Response
$63 Pos Response to $23
DM16 Binary Data Transfer
$36 Transfer Data
Slide: 8
ODX What It Is, and What It Isnt
June, 2014
V 0.01
2013-11-25
History Lesson
# Diagnostic Trouble Codes:
1984 Chevrolet Cavalier
15
1987 Cadillac Allante
84
1990 Buick Riviera
82
2006 Volkswagen Jetta
~2,000
2008 Chrysler T&C
~1200
The average vehicle today has 20+ ECUs

Slide: 4
Data Complexity
Example: Yesterday
1 OEM
10 Model Lines
50 Fault Codes per Model Line
= 500 Fault Code Entries
If supporting 10 OEMs:
5,000 Fault Codes to Manage

(data from 10 different sources)
Example: Today
1 OEM
10 Model Lines
1,200 Fault Codes per Model Line
= 12,000 Fault Code Entries
120,000 Fault Codes to Manage

(data from 10 different sources)
Not to mention:
PIDs, DIDs, SIDs, CPIDs, Sessions, NRCs, PRCs, FTBs, Seeds,
Keys, Freeze Frame Data, Monitor Data, ECU Config Data
Slide: 5
Definition
What is ODX?
Open Diagnostic data eXchange
Slide: 6
What ODX is Not!!
ODX is Not ... a protocol
ODX is Not ... the same as ODS
ODX is Not the same as OTX
ODX is Not ... for ECU flash data only
ODX is Not ... being mandated (at this time)
Slide: 7
What is ODX?
Data format for exchange of diagnostic data
Development within ASAM & is now an ISO standard

Jointly developed with ISO (International Standards

Organization) ISO22901-1
ASAM = Association for Standardisation of Automation and

Measuring Systems
Slide: 8
Motivation
Objectives of ODX
Data reuse in Development, Production, Service
Use diagnostic data for specification, test, software generation
Vehicle diagnostics
Machine readable
Harmonize tools, methods and know-how

Identical data
in different
departments
Service
01001001
AND
Authoring
Tester
Validation
Identical data
in different tools
Manufacturing
Development
PDF/RTF
Slide: 9
Scope of ODX
Components of the standard
Joint ASAM/ISO working group
Components of the standard
UML Model
XML Schema
Textual
Description
Checker Rules
Slide: 10
Use Cases
Releases
Diagnostic Layer Container
Vehicle Info Spec
Comparam Spec
Multiple ECU Jobs
Flash Data
2004 ODX 2.0.0
2006 ODX 2.1.0
Incompatibilities
2005 ODX 2.0.1
2008 ODX 2.2.0
Maintenance release of ODX 2.0.0
Function Dictionary
Ecu Configuration
Rework of Functional Addressing
Improved UDS support
ISO 22901-1
Slide: 11
Use Cases
MCD-2D and MCD-3D
Tester-Application
ASAM MCD-3D API

ISO 22900-3
ASAM MCD-2D
ODX
ISO 22901-1
D PDU API
ISO 22900-2
Hardware Interface
ISO 22900-1
Source: ASAM e.V.
Slide: 12
Practical Application
Client
Server
(Off-Board Tester)
Diagnostic
Data
Required Information
ODX
Which ECUs? Access?
VEHICLE-INFO-SPEC
Communication parameters?
COMPARAM-SPEC
Which services are available?
DIAG-LAYER-CONTAINER
How are functions distributed across ECUs?
FUNCTION-DICTIONARY
How to change ECU configuration options?
ECU-CONFIG
What data to flash to ECU?
FLASH
What jobs require simultaneous

communication with multiple ECUs?
MULTIPLE-ECU-JOB-SPEC
Slide: 13
ODX Catagories
Defined by the Data Model
Jobs
ODX-M
Function oriented
diagnostics
ODX-FD
ECU configuration
ODX-E
Flash data
ODX-F
Vehicle access
ODX-V
Communication
parameter libraries
Diagnostic
services and jobs
.PDX files:
Contains one or several odx files
Zip file, but with extension .pdx
ODX-C/-CS
ODX-D
Off-board
Tester
Slide: 14
ODX Files
One ODX file contains exactly one ODX category

odx-c (COMPARAM-SPEC)
odx-d (DIAG-LAYER-CONTAINER)
odx-f (FLASH)
odx-m (MULTIPLE-ECU-JOB)
odx-v (VEHICLE-INFO-SPEC)
odx-e (ECU-CONFIG)
odx-fd (FUNCTION-DICTIONARY)
odx (usable for any category)
Slide: 15
Hint: PDX files (Packed ODX)
ODX files
In any case one ODX file contains exactly one ODX-CATEGORY
File extensions for each category are suggested
PDX files
Contains one or several odx files.
Intention: PDX represents ECU or vehicle
Zip file, but with extension .pdx
May contain additional files: Picture, text, java code
Must contain a file index.xml which contains the content of the

package.
Slide: 16
ODX in Practice
Authoring guidelines
ODX supports many use cases of

diagnostic data.
High complexity
Tools support different sub-sets
Common approach:
Definition of ODX sub-set

relevant for the process-save
data exchange
= Authoring guideline
Checker Tool
Sub-set supported by
tool A
Sub-set relevant
for data
exchange
between the
tools A and B
Sub-set supported by
tool B
ODX standard
Slide: 17
ODX in Vector Tools
Slide: 18
An ECU Diagnostic Development Process from A to Z
June, 2014
V 1.0
2013-10-04
Agenda
> Requirements Engineering

ECU Software
Diagnostic Testers
Diagnostic Development Process
An Exemplary Tool Chain
Summary
Slide: 2/26
Requirements Engineering
Risks
Requirements unclear or misleading

Room for (mis-) interpretation
Additional need to readjust, results in increased efforts and delay
Requirements incomplete
One single requirement not comprehensive
In its entirety, i.e. requirements missing
Additional need to readjust, results in increased efforts and delay
Requirements too concrete or solution-oriented in the

beginning
Solution space is restricted without a need (e. g. prevents reuse)
Slide: 3/26
Formalization
Data formats for requirements need flexibility

One format covering many different domains
Everything needs to gets in (often no specification quality)
Little restrictions, little formalization
Use Domain specific specification formats for requirements

documentation? No!
Too formal
Too precise
Focused on one domain, inappropriate for others
Differentiate requirements and domain specific specifications!

Slide: 4/26
Agenda
> ECU Software
Diagnostic Testers
Summary
Slide: 5/26
ECU Software
AUTOSAR
AUTOSAR = AUTomotive Open System ARchitecture
Hardware abstraction
Well-defined interfaces
Standardized behavior of basic software
Standardized data exchange formats
Harmonized methodology for automotive software development
Supports model based function development
Scalable over all classes of vehicles and ECU
Considers safety requirements according to ISO 26262
Slide: 6/26
ECU Software
AUTOSAR
Reuse of functions in different vehicles

Vehicle A
Vehicle B
Hardware
Topology
Function Library
Seat Adjustment A
Software
Configuration
Seat Adjustment B
Lighting
Seat Heating
Air Conditioning
Distributed
System
ECU Extract
of System
Description
Slide: 7/26
ECU Software
AUTOSAR
ECU
SWC1
SWC2
80 BSW modules in 3 layers

Service Layer
RTE
ECU Abstraction Layer
AUTOSAR BSW
Microcontroller
Complex
Device
Drivers
Microcontroller
Abstraction Layer
Slide: 8/26
ECU Software
AUTOSAR
Diagnostics is part of Basic Software (BSW)

System / Memory /
Diagnostic Communication Manager (DCM)

Handles diagnostic protocol (UDS and/or OBDII)
Assembles any request information
Configured with ECU Configuration Description
Diagnostic Event Manager (DEM)

Handles fault memory (UDS and/or OBDII)
Manages retention of faults and snapshot data
Provides API to fault memory, e.g. for DCM
Function Inhibition Manager (FIM)

Deactivates selected functions in case of active faults
Manages substitute functions
Prevents inherited faults
FIM
DEM
DCM
PDU
Router
Bus TP
Communication Hardware
Abstraction
Bus
IF
Communication Drivers
Bus
Driver
Slide: 9/26
Agenda
ECU Software
> Diagnostic Testers
Summary
Slide: 10/26
Diagnostic Testers
Working for multiple vehicles lines (and their ECUs)
Usually generic and data driven
Based on standardized APIs (SAE PassThru, ISO D-PDU-API,

ISO MVCI)
Diagnostic data contains all information relevant for vehicle

and ECU diagnostics
Diagnostic communication: Protocol, settings, ...
Diagnostic services: Semantics, structure, content, ...
Diagnostic data: Meaning, interpretation, units, ...
Diagnostic trouble codes: Meaning, related snapshot data, ...
Security mechanisms
All in different languages and localization
Slide: 11/26
Diagnostic Testers
Huge amount of data requires efficient mechanisms for

data minimization, e.g. by avoiding redundancies
Runtime format for tester parameterization
Often binary (performance and encryption)
Often vehicle manufacturer-specific, often tool-vendor-specific
Contents often generated from ODX (ISO 22901-1)
Original data format, used in engineering

Mostly XML based
Often vehicle manufacturer-specific, often tool-vendor-specific,

e.g. FORD MDX or Vector CDD
Often exported to ODX (ISO 22901-1) for data exchange
Slide: 12/26
Agenda
ECU Software
Diagnostic Testers
> Diagnostic Development Process
Summary
Slide: 13/26

Iterations
Requirements
Specifications
Tester
Data
Tester
ECU
Configuration
Diagnostic
Communication
ECU
Slide: 14/26
ECUC
Requirements
ODX
Tester Data Supply
ECU Software Configuration
Data Format
Slide: 15/26
Program
Engineer/Manager
Project
Engineer/Manager
System
Architect
Many People involved
Function
Engineers/Managers
System
Engineer/Manager
Integration
Engineer/Manager
Manufacturing/Service
Engineers/Managers
7 ECU Config.
OEM
Supplier
Slide: 16/26

Requirements for a Tool Chain
You get each and every requirements into your system,

requirements are domain spanning including diagnostics.
It shall be possible to reuse data from earlier process steps.
The tool chain shall support the iterative process, i.e. data
is changing, causes changes in related data.
Requirements shall be traceable.
If a requirement item is already formal, it shall be possible

to generate the corresponding specification item.
Slide: 17/26
Agenda
ECU Software
Diagnostic Testers
> An Exemplary Tool Chain
Summary
Slide: 18/26

DaVinci
Configurator
Pro
ECU Software
Any Tester
IBM DOORS
Export
Import
Export
ODX
CDD
Requirements
Diag Tester
CANdelaStudio
Specification
CANoe
CANape
Indigo
CANoe.DiVa
a
Validation
Slide: 19/26

Diagnostic Requirements
DaVinci
Configurator
Pro
Engineer and manage requirements

for all domains in one system,
including diagnostics
ECU Software
Any Tester
ODX
IBM DOORS
CDD
Requirements
Diag Tester
CANdelaStudio
Specification
CANoe
CANape
Indigo
CANoe.DiVa
a
Validation
Slide: 20/26
10

Diagnostic Specification
Import and export requirements
Generate diagnostic objects from

requirements
DaVinci
Configurator
Pro
ECU Software
(Re-)Synchronize requirements with

specification
Any Tester
ODX
IBM DOORS
Diag Tester
CANdelaStudio
CDD
Requirements
Specification
Compare and merge data
Import and Export from/to ODX
Multi-language feature
CANoe
CANape
Indigo
CANoe.DiVa
a
Validation
Slide: 21/26

ECU Software, here: Basic Software Generation
Import CDD or ODX, generate ECUC.
Merge updated specification

with latest configuration
DaVinci
Configurator
Pro
ECU Software
Any Tester
IBM DOORS
Export
Import
ODX
Export
CDD
Requirements
Diag Tester
CANdelaStudio
Specification
Generate Basic Software and RTE
Put the software into the ECU with vFlash
CANoe
CANape
Indigo
CANoe.DiVa
a
Validation
Slide: 22/26
11

Diagnostic Validation
DaVinci
Configurator
Pro
Generate test cases based on

diagnostic data
ECU Software
Execute test cases in CANoe

Any Tester
ODX
IBM DOORS
CDD
Requirements
Diag Tester
CANdelaStudio
Specification
Analyze test results in Report View:

Filter, group and comment failed tests.
CANoe
CANape
Indigo
CANoe.DiVa
a
Validation
Slide: 23/26

Use Diagnostic Tester
DaVinci
Configurator
Pro
CANoe: Test, simulate, analyze network

+ integrated diagnostic tester
CANape: Measure and calibrate a system

+ integrated diagnostic tester
ECU Software
Any Tester
IBM DOORS
Export
Import
Export
ODX
CDD
Requirements
Diag Tester
CANdelaStudio
Specification
Indigo: Easy-to-use diagnostic tester
CANoe
CANape
Indigo
CANoe.DiVa
a
Validation
Slide: 24/26
12
Summary
A seamless process and concerted tools are key factors for

the efficient and effective development of vehicle diagnostics.
The efficiency of subsequent process steps depends on the

quality of the initial requirements.
Different diagnostic use cases result in rather different data

models and formats.
Neither ODX nor AUTOSAR ECUC are suitable to document

and manage requirements.
AUTOSAR ECUC and ODX complement one another, neither of

them can cover the subject and purpose of the other.
An efficient tool chain supports data reuse and (re-)

synchronization.
The Vector diagnostic tool chain already covers these features.

Slide: 25/26
Thank you for your attention.
For detailed information about Vector and our products please have a look at:
www.vector.com
Authors:
Dr. Klaus Beiter, Christoph Rtz
Vector Informatik GmbH
Ingersheimer Str. 24
70499 Stuttgart
Slide: 26/26
13
The Future of Diagnostic Technology
June, 2014
V 0.01
2013-11-25
UDS Implementation Trends
All European car makers already switched to UDS standard

The American market is diversified:

The first car with broad UDS implementation is on the street

since 2004.
Most OEMs have moved, or are moving, to UDS
The Asian market is less certain

Some OEMs change, some seem to just wait and see...
Slide: 2
Where is Diagnostics Heading?

More Complexity?
More Standards?
More legislation?
More Cooperation Between OEMs?
Worldwide Harmonization?
What about the end customer?

Is there a point of diminishing

returns?
Are automobiles becoming like VCRs?
Can technicians keep up?
Slide: 3
Hot Topics in Diagnostics Today

Access to vehicle data by aftermarket plug-in tools

I/M Stations
Insurance dongles
Personal data loggers / telematics systems
Multiple testers on the bus simultaneously
CAN ID support for more than 8 legislated ECUs
Differences in legislative requirements between:

Pass car & trucks
US, EU & Rest of World
DOIP (ISO 13400)
CAN FD impact on diagnostic specs
Security of vehicle data & functionality
Right to Repair laws
Prognostics
Slide: 4
CAN FD
Slide: 6
What is CAN-FD?
CAN-FD (proposed to be ISO 11898-7) is a serial communications

protocol similar to and compatible with ISO 11898-1
Designed as a higher bandwidth network compatible with CAN
Supports dual bit rates within a message

Arbitration-Phase same bit rate as standard CAN
Data-Phase sub-multiple of controller clock rate
Supports larger data lengths than standard CAN

Offers increased data transmission efficiency
Transmit/receive up to 64 bytes/message
Slide: 7
What is CAN-FD?
Differences from CAN are limited to CAN-FD controller hardware

Usable with existing CAN transceivers up to 2-3 Mbit/sec
Legacy SW usable
Data field up to 8 bytes in length
System cost similar to standard CAN
Progressively introduce CAN-FD nodes into standard networks

First commercial silicon to be available at end of 2012

Dual rate clock, DLC 8
Slide: 8
Why CAN-FD?
CAN networks reached practical maximums of data transfer
Many CAN buses have reached 50%-95%+ bus load level
Standard CAN messages contain 50% overhead

Standard CAN ~ 129 bits/message for 64 bits of data*
Extended CAN ~ 154 bits/message for 64 bits of data*
At a given bus load only ~40-50% of the bandwidth is used to

exchange useful data
Other protocols have much higher data throughput rate

Ethernet UDP ~64K bytes/datagram, 64 bytes overhead (ipV4)
FlexRay 254 bytes/frame, 8 bytes of overhead

* - excluding stuff bits
Slide: 9
Why CAN-FD?
Current CAN bus speeds 1Mbit/sec

Limited by physical characteristics of in-vehicle wiring

Most auto networks 500Kbit/sec
J1939 networks = 250Kbit/sec
Other buses run much faster

Ethernet 10Mbits/sec +
FlexRay 5-10 Mbits/sec (more if 2 channels are used)
CAN bus speed also limited due to the In-Frame Response (IFR)
mechanism
ACK generation delay in CAN controller
Propagation delay through the transceiver
Propagation delay over wire
Slide: 10
Basic Concepts
CAN-FD is similar to standard CAN and can be configured to fit

transparently into an existing CAN network
All of the advantages of CAN are available in CAN-FD

Message prioritization, guaranteed latency times, flexible

configuration, multi-master, multicast capability, error detection &
signaling, automatic retransmission on error
Tools will be modified to work with CAN-FD

Tool infrastructure remains similar to CAN minimizing learning curve
CANalyzer/CANoe upgrade in process (Service Pack) target 12/2012
Physical layer is similar

Additional consideration must be given to topology when using

higher data rates
Slide: 11
Basic Concepts
Summary:
CAN-FD is superset of CAN that:
Maintains CAN arbitration scheme
Maintains ACK scheme
Has mode that conforms with CAN 2.0 and ISO11898-1
And adds:
Higher data bit rates
Larger data fields (up to 64 bytes)
Larger CRC polynomials to handle larger data fields
Maintains compatibility with physical layer of standard CAN

Slide: 12
Data Frame
CRC
0..64
15
ACK
11
Data
ACK Delimiter
DLC
CRC Delimiter
RTR
r1
Identifier
r0
SOF
CAN
Base Data frame*
EOF
ITM
CRC
0..512
17 / 21
ACK Delimiter
Data
ACK
DLC
CRC Delimiter
ESI
BRS
11
r0
EDL
r1
SOF
Identifier
IDE
CAN-FD
Base Data Frame*
EOF
ITM
Arbitration Phase
Data Phase
Arbitration Phase
(fixed data rate)
(flexible data rate)
(fixed data rate)

* - Excludes stuff bits
Slide: 13
Proposed ISO 15765-2 Changes for CAN FD

N_PCI bytes
N_PDU name
Byte #1
Bits 7 4
Bits 3 0
SingleFrame
(SF)
(CAN_DL 810) a
00002
SF_DL
SingleFrame
(SF)
(CAN_DL > 810)b
00002
00002
FirstFrame (FF)
(FF_DL 409510) a
00012
FirstFrame (FF)
(FF_DL > 409510) a,c
00012
00002
ConsecutiveFrame
(CF)a
00102
SN
FlowControl (FC) a
00112
FS
Byte #2
Byte #3
Byte #4
Byte #5
Byte #6
SF_DL
FF_DL
0000 00002
BS
FF_DL
STmin
N/A
N/A
N/A
NOTE
Shaded cells are not utilized for PCI information, but depending on the PDU, they might be utilized
for payload data.
a
CAN CLASSIC or CAN FD
CAN FD only
Messages larger than 409510 bytes shall use an escape sequence where the lower nibble of data byte 1
and all bits in byte 2 are set to 0 (invalid length). This signifies to the network layer that the value of FF_DL
is determined based on the next 32 bits in the frame (byte 3 is the MSB and byte 6 the LSB)
c
Slide: 14
Thank you for your attention.
For detailed information about Vector

and our products please have a look at:
www.vector.com
Author:
Jeff Craig
Vector CANtech, Inc.
Email: jeff.craig@vector.com
Slide: 15

Vector Diagnostics Seminar

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Vector Diagnostics Seminar

Diunggah oleh

Hak Cipta:

Format Tersedia

Automotive Diagnostics Development

The Evolution of Automotive Diagnostic Technology

Basic Concepts A Visit to the Doctor

Something is wrong with the car but what?

ECUs know their own health

ECUs can communicate this information

Isolate the problem

Make the fix

Repair (replace) failing part(s)

Is the problem gone?

Go back and repeat questions and tests

Clean bill of health?

But How Does it Know??

Self tests are executed in parallel to actual system operation

Faults are detected and logged internally

Internal test routines are available for single-shot execution

Functionality created to interface with off-board diagnostic tools

Why Do We Need It?

Today: Its not brain surgery, but its close.

Goals and Benefits

Verify function and performance of electrical & mechanical systems

Ensure components are fault free while meeting functional duties

Accurately identify specific failure modes

Vehicle delivered from assembly plant to dealer in working order

Vehicle serviced correctly and on time during first visit to dealer

Accurately identify smallest necessary fix

Proper operation of emissions control systems

Reduced operational and warranty costs

Applications and Users Engineering

ECU development (test implementation and functionality)

Vehicle integration (verify interaction with other ECUs)

Calibration (monitor/calibrate performance, hot/cold trips)

Testing (proving grounds, component and vehicle durability testing)

EMC testing (electro-magnetic compatibility with rest of vehicle & FCC)

Applications and Users Manufacturing

Flash programming (program ECU at supplier or on assembly line)

Configuration and calibration (configure ECU on assembly line)

Repair bay (identify failures and verify repairs)

Audit bay (verify quality and compliance)

Applications and Users Service

In-service emissions testing

Troubleshoot customer complaints

Identify failures and warrantee issues

Flash re-programming updates

Implementation Concept How Does It Work?

ECU communicates with offboard test device

Evolutionary History Point-to-Point Links

Proprietary point-to-point links (start in early 1980s)

Implied address tin cans on a string model

Simple UART-based line drivers

Simple send-a-byte/get-a-byte protocols

Everything was proprietary

Still hanging on in production

Evolutionary History Point-to-Point Links (continued)

Standardized point-to-point links (start in early 1990s)

Logically addressed telephone party-line model

Still UART-based line drivers

More powerful send-a-message/get-a-message protocols

Standardized regulations and tools began to appear

ISO-9141 (K-line) becomes global standard

Still in wide use

Evolutionary History Multiplexed Data Links

Proprietary multiplexed networks (start in late 1980s)