Keyword Protocol 2000

Implementation of Diagnostic Services

Recommended Practice

Status: Version 1.5

Date: October 1, 1997

This document is based on the International Standard ISO

14230 - 3 Keyword Protocol 2000 and has been further
developed to meet automotive manufacturer's and
electronic system supplier's requirements by the
"Keyword Protocol 2000 Task Force". It is based on
mutual agreement between the following companies:
• Adam Opel AG
• AISIN AW CO., Limited Japan
• Audi AG / Volkswagen AG
• BMW AG
• Daimler-Benz AG
• debis Systemhaus GmbH
• DELCO Electronics Europe
• DSA Daten und Systemtechnik GmbH
• ETAS GmbH & Co. KG
• FEV Motorentechnik GmbH & Co. KG
• GenRad Europe Ltd.
• GM Europe GmbH Service Technology Group Int’l Operations
• Hella KG
• Isuzu Motors Ltd.
• Kelsey-Hayes
• LucasVarity
• MAN Nutzfahrzeuge AG
• Mecel AB
• Robert Bosch GmbH
• Saab Automobile AB
• Siemens AG
• Softing GmbH
• VDO Adolf Schindling AG
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

THIS PAGE INTENTIONALLY LEFT BLANK

Page: 2 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Table of Content

1 - SCOPE .........................................................................................................................11

2 - NORMATIVE REFERENCE .........................................................................................12

2.1 - ISO standards .....................................................................................................................................................12

2.2 - Other standards..................................................................................................................................................12

3 - DEFINITIONS AND ABBREVIATIONS ........................................................................13

3.1 - Terms defined in other standards .....................................................................................................................13

3.1.1 - ISO definitions ..............................................................................................................................................13
3.1.2 - SAE definitions .............................................................................................................................................13

3.2 - Terms defined by this document .......................................................................................................................13

3.2.1 - Service Identifier value convention table ......................................................................................................13
3.2.2 - Definitions used in this document .................................................................................................................13

3.3 - Abbreviations defined in this document ...........................................................................................................14

3.3.1 - Summary of service mnemonic .....................................................................................................................14
3.3.2 - Summary of negative response code mnemonic............................................................................................14
3.3.3 - Summary of parameter mnemonic.................................................................................................................15

4 - CONVENTIONS............................................................................................................17

4.1 - Service description convention..........................................................................................................................17

4.1.1 - Parameter definition ......................................................................................................................................17
4.1.2 - Message data bytes........................................................................................................................................17
4.1.3 - Message description ......................................................................................................................................19
4.1.4 - Message flow examples.................................................................................................................................19
4.1.5 - Implementation example ...............................................................................................................................19

4.2 - Functional unit table ..........................................................................................................................................20

4.3 - Service Identifier value summary table ............................................................................................................21

4.4 - Response Code value summary table................................................................................................................23

5 - GENERAL IMPLEMENTATION RULES ......................................................................30

5.1 - Parameter definitions.........................................................................................................................................30

5.2 - Functional and physical addressed service requests........................................................................................30

5.3 - Message flow examples of physical/functional addressed services.................................................................31

5.3.1 - Physical addressed services...........................................................................................................................31
5.3.2 - Functional addressed services .......................................................................................................................35

5.4 - Data Scaling ........................................................................................................................................................37

5.4.1 - Data Scaling Purpose ....................................................................................................................................37
5.4.2 - Data Scaling Table Structure.........................................................................................................................37

6 - DIAGNOSTIC MANAGEMENT FUNCTIONAL UNIT ...................................................39

Page: 3 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.1 - StartDiagnosticSession service ..........................................................................................................................40

6.1.1 - Parameter definition ......................................................................................................................................40
6.1.2 - Message data bytes........................................................................................................................................41
6.1.3 - Message description ......................................................................................................................................42
6.1.4 - Message flow example ..................................................................................................................................42
6.1.5 - Implementation example of startDiagnosticSession......................................................................................43

6.2 - StopDiagnosticSession service ...........................................................................................................................45

6.2.1 - Parameter Definition .....................................................................................................................................45
6.2.2 - Message Data Bytes ......................................................................................................................................45
6.2.3 - Message description ......................................................................................................................................45
6.2.4 - Message flow example ..................................................................................................................................45
6.2.5 - Implementation example of stopDiagnosticSession ......................................................................................45

6.3 - SecurityAccess service........................................................................................................................................47

6.3.1 - Parameter definition ......................................................................................................................................47
6.3.2 - Message data bytes........................................................................................................................................47
6.3.3 - Message description ......................................................................................................................................49
6.3.4 - Message flow example ..................................................................................................................................49
6.3.5 - Implementation example of securityAccess ..................................................................................................49

6.4 - TesterPresent service .........................................................................................................................................51

6.4.1 - Parameter definition ......................................................................................................................................51
6.4.2 - Message Data Bytes ......................................................................................................................................51
6.4.3 - Message description ......................................................................................................................................51
6.4.4 - Message flow example ..................................................................................................................................52
6.4.5 - Implementation example of testerPresent......................................................................................................52

6.5 - EcuReset service .................................................................................................................................................52

6.5.1 - Parameter definition ......................................................................................................................................52
6.5.2 - Message data bytes........................................................................................................................................53
6.5.3 - Message description ......................................................................................................................................53
6.5.4 - Message flow example ..................................................................................................................................53
6.5.5 - Implementation example of ecuReset............................................................................................................53

6.6 - ReadEcuIdentification service...........................................................................................................................54

6.6.1 - Parameter definition ......................................................................................................................................54
6.6.2 - Message data bytes........................................................................................................................................56
6.6.3 - Message description ......................................................................................................................................56
6.6.4 - Message flow example ..................................................................................................................................56
6.6.5 - Implementation example of readECUIdentification......................................................................................57

7 - DATA TRANSMISSION FUNCTIONAL UNIT ..............................................................60

7.1 - ReadDataByLocalIdentifier service..................................................................................................................61

7.1.1 - Parameter definition ......................................................................................................................................61
7.1.2 - Message data bytes........................................................................................................................................61
7.1.3 - Message description ......................................................................................................................................62
7.1.4 - Message flow example ..................................................................................................................................62
7.1.5 - Implementation example of readDataByLocalIdentifier ...............................................................................62

7.2 - ReadDataByCommonIdentifier service............................................................................................................63

7.2.1 - Parameter definition ......................................................................................................................................63
7.2.2 - Message data bytes........................................................................................................................................63
7.2.3 - Message description ......................................................................................................................................64
7.2.4 - Message flow example ..................................................................................................................................64
7.2.5 - Implementation example of readDataByCommonIdentifier..........................................................................64

7.3 - ReadMemoryByAddress service .......................................................................................................................64

Page: 4 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.3.1 - Parameter definition ......................................................................................................................................64

7.3.2 - Message data bytes........................................................................................................................................65
7.3.3 - Message description ......................................................................................................................................65
7.3.4 - Message flow example ..................................................................................................................................65
7.3.5 - Implementation example of readMemoryByAddress ....................................................................................65

7.4 - DynamicallyDefineLocalIdentifier service .......................................................................................................66

7.4.1 - Parameter definition ......................................................................................................................................66
7.4.2 - Message data bytes........................................................................................................................................67
7.4.3 - Message description ......................................................................................................................................70
7.4.4 - Message flow examples.................................................................................................................................70
7.4.5 - Implementation example of dynamicallyDefineLocalIdentifier ....................................................................70

7.5 - WriteDataByLocalIdentifier service.................................................................................................................77

7.5.1 - Parameter definition ......................................................................................................................................77
7.5.2 - Message data bytes........................................................................................................................................77
7.5.3 - Message description ......................................................................................................................................78
7.5.4 - Message flow example ..................................................................................................................................78
7.5.5 - Implementation example of set Vehicle Identification Number (VIN) .........................................................78

7.6 - WriteDataByCommonIdentifier service...........................................................................................................79

7.6.1 - Parameter definition ......................................................................................................................................79
7.6.2 - Message data bytes........................................................................................................................................79
7.6.3 - Message description ......................................................................................................................................80
7.6.4 - Message flow example ..................................................................................................................................80
7.6.5 - Implementation example of Reset Learned Values .......................................................................................80

7.7 - WriteMemoryByAddress service ......................................................................................................................80

7.7.1 - Parameter definition ......................................................................................................................................80
7.7.2 - Message data bytes........................................................................................................................................80
7.7.3 - Message description ......................................................................................................................................81
7.7.4 - Message flow example ..................................................................................................................................81
7.7.5 - Implementation example of writeMemoryByAddress...................................................................................81

7.8 - SetDataRates service ..........................................................................................................................................82

8 - STORED DATA TRANSMISSION FUNCTIONAL UNIT ..............................................82

8.1 - ReadDiagnosticTroubleCodes service ..............................................................................................................82

8.2 - ReadDiagnosticTroubleCodesByStatus service ...............................................................................................83

8.2.1 - Parameter definition ......................................................................................................................................83
8.2.2 - Message data bytes........................................................................................................................................90
8.2.3 - Message description ......................................................................................................................................90
8.2.4 - Message flow example ..................................................................................................................................91
8.2.5 - Implementation example of readDiagnosticTroubleCodesByStatus .............................................................91

8.3 - ReadStatusOfDiagnosticTroubleCodes service ...............................................................................................95

8.3.1 - Parameter definition ......................................................................................................................................95
8.3.2 - Message data bytes........................................................................................................................................96
8.3.3 - Message description ......................................................................................................................................96
8.3.4 - Message flow example ..................................................................................................................................96
8.3.5 - Implementation example of readStatusOfDiagnosticTroubleCodes..............................................................97

8.4 - ReadFreezeFrameData service..........................................................................................................................98

8.4.1 - Parameter definition ......................................................................................................................................98
8.4.2 - Message data bytes......................................................................................................................................100
8.4.3 - Message description ....................................................................................................................................101
8.4.4 - Message flow example ................................................................................................................................101

Page: 5 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

8.4.5 - Implementation example of readFreezeFrameData.....................................................................................101

8.5 ClearDiagnosticInformation service .................................................................................................................105

8.5.1 - Parameter definition ....................................................................................................................................105
8.5.2 - Message data bytes......................................................................................................................................105
8.5.3 - Message description ....................................................................................................................................105
8.5.4 - Message flow example ................................................................................................................................106
8.5.5 - Implementation example of clearDiagnosticInformation ............................................................................106

9 - INPUTOUTPUT CONTROL FUNCTIONAL UNIT ......................................................106

9.1 - InputOutputControlByLocalIdentifier service..............................................................................................107

9.1.1 - Parameter definition ....................................................................................................................................107
9.1.2 - Message Data Bytes ....................................................................................................................................108
9.1.3 - Message description ....................................................................................................................................109
9.1.4 - Message flow example ................................................................................................................................109
9.1.5 - Implementation example of "Desired Idle Adjustment"..............................................................................109

9.2 - InputOutputControlByCommonIdentifier service........................................................................................113

9.2.1 - Parameter definition ....................................................................................................................................113
9.2.2 - Message data bytes......................................................................................................................................115
9.2.3 - Message description ....................................................................................................................................115
9.2.4 - Message flow example ................................................................................................................................115
9.2.5 - Implementation examples............................................................................................................................115

10 - REMOTE ACTIVATION OF ROUTINE FUNCTIONAL UNIT ...................................116

10.1 - StartRoutineByLocalIdentifier service.........................................................................................................120

10.1.1 - Parameter definition ..................................................................................................................................120
10.1.2 - Message data bytes....................................................................................................................................120
10.1.3 - Message description ..................................................................................................................................121
10.1.4 - Message flow example ..............................................................................................................................121
10.1.5 - Implementation example of "Input/output signal intermittent test routine"...............................................121

10.2 - StartRoutineByAddress service ....................................................................................................................121

10.2.1 - Parameter definition ..................................................................................................................................121
10.2.2 - Message data bytes....................................................................................................................................121
10.2.3 - Message description ..................................................................................................................................122
10.2.4 - Message flow example ..............................................................................................................................122
10.2.5 - Implementation example of "Input/output signal intermittent test routine"...............................................122

10.3 - StopRoutineByLocalIdentifier service..........................................................................................................123

10.3.1 - Parameter definition ..................................................................................................................................123
10.3.2 - Message data bytes....................................................................................................................................123
10.3.3 - Message description ..................................................................................................................................124
10.3.4 - Message flow example ..............................................................................................................................124
10.3.5 - Implementation example of "Input/output signal intermittent test routine"...............................................124

10.4 - StopRoutineByAddress service .....................................................................................................................124

10.4.1 - Parameter definition ..................................................................................................................................124
10.4.2 - Message data bytes....................................................................................................................................124
10.4.3 - Message description ..................................................................................................................................125
10.4.4 - Message flow example ..............................................................................................................................125
10.4.5 - Implementation example of "Input/output signal intermittent test routine" (IOSITR) ..............................125

10.5 - RequestRoutineResultsByLocalIdentifier service .......................................................................................126

10.5.1 - Parameter definition ..................................................................................................................................126
10.5.2 - Message data bytes....................................................................................................................................126

Page: 6 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

10.5.3 - Message description ..................................................................................................................................126

10.5.4 - Message flow example ..............................................................................................................................126
10.5.5 - Implementation example of "Input/output signal intermittent test routine"...............................................127

10.6 - RequestRoutineResultsByAddress service ...................................................................................................128

10.6.1 - Parameter definition ..................................................................................................................................128
10.6.2 - Message data bytes....................................................................................................................................128
10.6.3 - Message description ..................................................................................................................................128
10.6.4 - Message flow example ..............................................................................................................................128
10.6.5 - Implementation example of "Input/output signal intermittent test routine"...............................................128

11 - UPLOAD DOWNLOAD FUNCTIONAL UNIT ...........................................................129

11.1 - RequestDownload service ..............................................................................................................................130

11.1.1 - Parameter definition ..................................................................................................................................130
11.1.2 - Message data bytes....................................................................................................................................130
11.1.3 - Message description ..................................................................................................................................131
11.1.4 - Message flow example ..............................................................................................................................131
11.1.5 - Implementation example of "requestDownload".......................................................................................131

11.2 - RequestUpload service ...................................................................................................................................131

11.2.1 - Parameter definition ..................................................................................................................................131
11.2.2 - Message data bytes....................................................................................................................................132
11.2.3 - Message description ..................................................................................................................................132
11.2.4 - Message flow example ..............................................................................................................................132
11.2.5 - Implementation example of "requestUpload" ...........................................................................................132

11.3 - TransferData service......................................................................................................................................133

11.3.1 - Parameter definition ..................................................................................................................................133
11.3.2 - Message data bytes....................................................................................................................................133
11.3.3 - Message description ..................................................................................................................................133
11.3.4 - Message flow example ..............................................................................................................................134
11.3.5 - Implementation example of "transferData" ...............................................................................................134

11.4 - RequestTransferExit service .........................................................................................................................134

11.4.1 - Parameter definition ..................................................................................................................................134
11.4.2 - Message data bytes....................................................................................................................................134
11.4.3 - Message description ..................................................................................................................................135
11.4.4 - Message flow example ..............................................................................................................................135
11.4.5 - Implementation example of "requestTransferExit" ...................................................................................135

12 - KEYWORD PROTOCOL 2000 EXTENDED SERVICES .........................................139

12.1 - EscapeCode service ........................................................................................................................................139

12.1.1 - Parameter definition ..................................................................................................................................139
12.1.2 - Message data bytes....................................................................................................................................139
12.1.3 - Message description ..................................................................................................................................139
12.1.4 - Message flow example ..............................................................................................................................140
12.1.5 - Implementation example of "escapeCode(manufacturerSpecificServiceId)"............................................140

13 - APPLICATION EXAMPLES .....................................................................................141

13.1 - Description of the on-vehicle ECUs ..............................................................................................................141

13.2 - Fast initialisation and physically addressed communication ......................................................................141

13.3 - ReadDataByLocalIdentifier response message and termination of communication ................................142

Page: 7 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

13.4 - SecurityAccess, data transfer and modification of timing parameters ......................................................142

14 - IMPLEMENTATION OF ECU MEMORY PROGRAMMING .....................................144

14.1 - Standardised ECU memory programming...................................................................................................144

14.1.1 - Standardised ECU memory programming initialisation description .........................................................144
14.1.2 - Standardised ECU memory programming initialisation message flow .....................................................144
14.1.3 - Example of ECU memory programming data transfer description............................................................145
14.1.4 - Example of ECU memory programming data transfer message flow........................................................146
14.1.5 - Program Vehicle Identification Number (VIN) into ECU memory........................................................... 147
14.1.6 - Standardised ECU memory programming termination description...........................................................147
14.1.7 - Standardised ECU memory programming termination message flow .......................................................147

14.2 - Example of ECU flash memory programming.............................................................................................148

14.2.1 - Example of timing analysis of ECU flash memory programming .............................................................148

15 - REVISION HISTORY LOG .......................................................................................155

Page: 8 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Introduction
This document is based on the International Standard "ISO 14230-3 Road Vehicles - Diagnostic Systems Keyword
Protocol 2000 Part 3: Implementation". Changes are indicated by changing the font from "Arial" to "Times New
Roman"!

The Keyword Protocol 2000 Part 3 Implementation Recommended Practice has been established in order to define
common requirements for the implementation of diagnostic services for diagnostic systems. The figure below shows the
"Hierachy of Documents" and indicates the level of commonality between the documents.

I S O 1 4 2 2 9 R o a d V e h ic le s - D ia g n o s t ic S y s t e m s
( I n t e r n a t io n a l S t a n d a r d ) IS O 1 4 2 2 9

D ia g n o s t ic S e r v i c e s

I m p le m e n t a t i o n o f
D ia g n o s t i c S e r v ic e s

I S O 1 4 2 3 0 R o a d V e h ic le s - D ia g n o s t ic S y s t e m s
K e y w o r d P r o t o c o l 2 0 0 0 ( I n t e r n a t io n a l S t a n d a r d )

IS O 1 4 2 3 0 - 1 IS O 1 4 2 3 0 - 2 IS O 1 4 2 3 0 - 3 IS O 1 4 2 3 0 - 4
K ey w o rd P ro to co l 2 0 0 0 K e y w o rd P ro to c o l 2 0 0 0 K e y w o rd P ro to c o l 2 0 0 0 K e y w o rd P ro to co l 2 0 0 0
R e q u ir e m e n t s F o r
P h y s ic a l L a y e r D a ta L i n k L a y e r Im p le m e n ta tio n E m i s s io n R e la te d S y s t e m s

1 0 0 % ca rry o v er S u b se t S u b se t 1 0 0 % ca rry o v er
+ +
m o r e d e t a il m o r e d e t a il

V D A 1 4 2 3 0 K e y w o r d P r o t o c o l 2 0 0 0 R e c o m m e n d e d P r a c t ic e
IS O 1 423 0 - 1 K ey w o rd P ro to co l 2 0 0 0 K ey w o rd P ro to co l 2 0 0 0 IS O 1 4 2 3 0 - 4
K e y w o rd P ro to c o l 2 0 0 0 D a ta L i n k L a y e r Im p le m e n ta tio n K e y w o rd P ro to co l 2 0 0 0
R e q u ir e m e n t s F o r
P h y sic a l L a y e r R e c o m m e n d e d P r a c ti c e R e c o m m e n d e d P r a c t ic e E m i s s io n R e la te d S y s t e m s

sa m e o r su b set m o r e d e t a i l/ m o r e d e t a i l/ 1 0 0 % ca rry o v er
sa m e /su b se t sa m e /su b se t

K e y w o r d P r o t o c o l 2 0 0 0 ( V e h ic le M a n u f a c t u r e r S p e c if ic a t io n )
P a rt 1 P a rt 2 P a rt 3 IS O 1 4 2 3 0 - 4
P h y s ic a l L a y e r b a s e d o n K e y w o rd P ro to co l 2 0 0 0
D a t a L in k L a y e r b a s e d o n I m p le m e n ta ti o n o f S e r v ic e s
R e q u ir e m e n t s F o r
K W P 2000 K W P 2000 based on K W P 20 00 E m i s s io n R e la te d S y s t e m s

P r o j e c t s p e c i fi c P r o j e c t s p e c i fi c P r o j e c t s p e c i fi c 1 0 0 % c a r r y o v e r , if
su b set su b set su b set sy ste m is E O B D
a n d /o r O B D II
r e le v a n t

K e y w o r d P r o t o c o l 2 0 0 0 ( P r o j e c t S p e c if ic a t io n )
P a rt 1 P a rt 2 P a rt 3 IS O 1 4 2 3 0 - 4
P h y sic a l L a y e r D a ta L in k L a y e r P r o j e c t s p e c if i c K e y w o rd P ro to co l 2 0 0 0
R e q u ir e m e n t s F o r
P ro je c t sp e c ific P r o j e c t s p e c if i c Im p le m e n ta tio n o f S e rv ic e s E m i s s io n R e la te d S y s t e m s

Figure 0 - Hierachy of Documents

• The ISO 14229 Diagnostic Services (International Standard) document specifies common requirements for the
implementation of diagnostic services.
• The ISO 14230 Keyword Protocol 2000 (International Standard) documents specify the requirements of the
"Physical Layer, Data Link Layer and Implementation of Diagnostic Services" in three (3) different documents.

Page: 9 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

• The Keyword Protocol 2000 (Part 3 Implementation Recommended Practice) documents are based on the
International Standard ISO 14230 and therefore fully compatible. The Keyword Protocol 2000 - Physical Layer,
Data Link Layer, and the Implementation documents are a "subset with additional detail based on mutual
agreement between all companies listed on the cover sheet of this document".
• The Keyword Protocol 2000 (Vehicle Manufacturer Specification) document is based on the Part 3
Implementation Recommended Practice document. The Part 1 Physical Layer, Part 2 Data Link Layer, and the
Part 3 Implementation of Services documents shall specify more detail or the same or a subset of the Part 3
Implementation Recommended Practice.
• The Keyword Protocol 2000 (Project Specification) document (e.g. Engine Management) is based on the
vehicle manufacturer specification document. The document of the system supplier specifies system and customer
specific Part 1 Physical Layer, Part 2 Data Link Layer and Part 3 Implementation details (e.g. datastreams,
diagnostic trouble codes, input/output controls, etc.).

The Part 3 Implementation Recommended Practice is based on the Open System Interconnection (O.S.I.)
Basic Reference Model in accordance with ISO 7498 which structures communication systems into seven
layers. When mapped on this model, the services used by a diagnostic tester and an Electronic Control Unit
(ECU) are broken into:

• Diagnostic services (layer 7),

• Communication services (layers 1 to 6)

Mapping of the Diagnostic Services and Keyword Protocol 2000 onto the OSI model is shown below. ISO 14230 will
consist of the following parts, under the general title Road vehicles - Diagnostic systems - Keyword Protocol 2000:

• Part 1: Physical Layer

• Part 2: Data Link Layer, Error Handling, Byte Arbitration
• Part 3: Implementation of Diagnostic Services

A p p lic a tio n
D ia g n o s tic D a ta

S e rvic e .re q u e s t S e rv ic e .re s p o n s e

S e rv ic e D e fin itio n
S e rvic e .c o n firm a tio n S e rvic e .in d ic a tio n

A p p lic a tio n L a ye r D ia g n o s tic S e rv ic e s

(L a y e r 7 )
s e ria l s e ria l s e ria l s e ria l Im p le m e n ta tio n
...
d a ta lin k 1 d a ta lin k 2 d a ta lin k 3 d a ta lin k n (P a rt 3 )

P re s e n ta tio n L a y e r (L a y e r 6 ) L a y e r 6 to 3
S e s s io n L a ye r (L a y e r 5 ) a re n o t d e fin e d
T ra n s p o rt L a y e r (L a y e r 4 ) w ith in th e d ia g n o s tic
N e tw o rk L a ye r (L a ye r 3 ) s e rv ic e d o c u m e n t

D a ta L in k L a ye r
(L a y e r 2 ) D a ta L in k L a ye r
(P a rt 2 )

P h y s ic a l L a y e r
(L a y e r 1 ) P h y s ic a l L a ye r
(P a rt 1 )

Figure 1 - Mapping of the Diagnostic Services and Keyword Protocol 2000 on the OSI Model

Page: 10 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

1 - Scope
The KWP 2000 Part 3 Implementation Recommended Practice specifies the requirements for the Keyword Protocol
2000 data link by which one or several on-vehicle Electronic Control Units are connected to an off-board tester in order
to perform diagnostic functions.

The KWP 2000 Part 3 Implementation Recommended Practice specifies additional detail to some sections of ISO 14230
Keyword Protocol 2000.

It consists of three parts:

• Part 1: Physical Layer

• Part 2: Data Link Layer, Error Handling, Byte Arbitration
• Part 3: Implementation of Diagnostic Services

This part of ISO 14230 specifies the requirements of the implementation of the Diagnostic Services specified
in ISO 14229, including:

• Byte encoding and hexadecimal values for the service identifiers,

• Byte encoding for the parameters of the diagnostic service requests and responses,
• Hexadecimal values for the standard parameters.

The vehicle environment to which this standard applies may consist of:

• a single tester which may be temporarily connected to the on-vehicle diagnostic data link and
• several on-vehicle Electronic Control Units connected directly or indirectly.

See figure 2 below.

within the scope Vehicle 1 within the scope Vehicle 2

of the proposal of the proposal
ECU ECU

ECU ECU
Tester Tester
Gatew ay ECU ECU

may or m ay not be
ECU ECU
within the scope
of the proposal

In vehicle 1, the ECUs are connected by an internal data link and indirectly connected to the
diagnostic data link through a gateway. This docum ent applies to the diagnostic com m unications
over the diagnostic data link; the diagnostic com m unications over the internal data link m ay conform
to this document or to another protocol.
In vehicle 2, the ECUs are directly connected to the diagnostic data link.
Figure 2 - Vehicle diagnostic architecture

Page: 11 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

2 - Normative reference
2.1 - ISO standards
The following standards contain provisions which, through reference in this text, constitute provisions of this
document. All standards are subject to revision, and parties to agreement based on this document are
encouraged to investigate the possibility of applying the most recent editions of the standards listed below.
Members of ISO maintain registers of currently valid International Standards.

ISO 7498-1:1984 Information processing systems - Open systems interconnection - Basic

reference model

ISO TR 8509:1987 Information processing systems - Open systems interconnection -

Conventions of services

ISO 4092:1988/ Road vehicles - Testers for motor vehicles -

Cor.1:1991 Vocabulary Technical Corrigendum 1

ISO 9141-2:1994 CARB Requirements for Interchange of Digital Information

ISO 14229:1996 Road Vehicles - Diagnostic Systems

Diagnostic Services Specification

ISO/DIS 14230-1:1996 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 1: Physical Layer

ISO/DIS 14230-2:1996 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 2: Data Link Layer, Error Handling

ISO/DIS 14230-3:1996 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 3: Implementation

ISO/WD 14230-4:1996 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 4: Requirements for Emission Related Systems

Note: All documents which are of the status “Draft International Standard” are marked “DIS”!
All documents which are of the status “Working Draft” are marked “WD”!

2.2 - Other standards

KWP 2000 Data Link Layer Keyword Protocol 2000 Data Link Layer Recommended Practice

SAE J1587 Joint SAE/TMC Electronic Data Interchange Between Microcomputer

Systems in Heavy-Duty Vehicle Applications

SAE J1930 E/E Systems Diagnostic Terms, Definitions, Abbreviations & Acronyms

SAE J1978 OBD II Scan Tool

SAE J1979 E/E Diagnostic Test Modes

SAE J2012 Diagnostic Trouble Code Definitions

SAE J2186 E/E Diagnostic Data Link Security

SAE J2190 Enhanced Diagnostic Test Modes

Page: 12 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

3 - Definitions and abbreviations

3.1 - Terms defined in other standards
3.1.1 - ISO definitions
This document makes use of terms defined in the ISO 14229 Diagnostic Services Specification document.
3.1.2 - SAE definitions
This document makes use of terms defined in the SAE J1930 E/E Systems Diagnostic Terms, Definitions,
Abbreviations & Acronyms document.
3.2 - Terms defined by this document
3.2.1 - Service Identifier value convention table
The following chart indicates the different ranges of service identifier values, which are defined in SAE J1979, Keyword
Protocol 2000 by the vehicle manufacturer or by system supplier.

Service Identifier Service type Where defined

Hex Value (bit 6)
00 - 0F Request reserved by SAE J1979
10 - 1F
20 - 2F Request (bit 6 = 0) reserved by KWP 2000 Part 3
30 - 3E
3F Not Applicable reserved by document
40 - 4F Response reserved by SAE J1979
50 - 5F Positive Response
60 - 6F to Services ($10 - $3E)
70 - 7E (bit 6 = 1) reserved by KWP 2000 Part 3
7F Negative Response
80 Request 'ESC' - Code
81 - 8F Request (bit 6 = 0) reserved by KWP 2000 Part 2
90 - 9F Request (bit 6 = 0) reserved for future exp. as needed
A0 - B9 Request (bit 6 = 0) defined by vehicle manufacturer
BA - BF Request (bit 6 = 0) defined by system supplier
C0 Positive Resp. 'ESC' - Code reserved by KWP 2000 Part 3
C1 - CF Positive Response (bit 6 = 1) reserved by KWP 2000 Part 2
D0 - DF Positive Response (bit 6 = 1) reserved for future exp. as needed
E0 - F9 Positive Response (bit 6 = 1) defined by vehicle manufacturer
FA - FF Positive Response (bit 6 = 1) defined by system supplier
Table 3.2.1 - Service Identifier value convention table (SAE J1979, KWP 2000)

KWP 2000 Part 3 = ISO 14230-3 Keyword Protocol 2000 Part 3: Implementation
KWP 2000 Part 2 = ISO 14230-2 Keyword Protocol 2000 Part 2: Data Link Layer

Service identifier values "$00 - $0F" and "$40 - $4F" are reserved to be defined in SAE J1979 which currently
only includes functionally addressed services. The service identifier values which are defined in this
document are indicated by bold font.
There is a one-to-one correspondence between request messages and positive response messages, with "bit
6" of the service identifier hex value indicating the service type.
3.2.2 - Definitions used in this document
The "default timing" shall always reference the timing parameter values as initiated by the keybytes sent by the server
(ECU) at the start of the communication. The timing parameter values and possible keybytes are specified in the KWP
2000 Part 2 Data Link Layer Recommended Practice.

Page: 13 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

3.3 - Abbreviations defined in this document

3.3.1 - Summary of service mnemonic
Mnemonic Service Name Mnemonic Service Name
ATP accessTimingParameter RTE requestTransferExit
CDI clearDiagnosticInformation RU requestUpload
DDLI dynamicallyDefineLocalIdentifier SA securityAccess
EC escCode (KWP 2000 only) SPC stopCommunication
ER ecuReset SPDS stopDiagnosticSession
IOCBLI inputOutputControlByLocalIdentifier SPRBA stopRoutineByAddress
J1979M SAE J1979 Diagnostic Test Modes SPRBLI stopRoutineByLocalIdentifier
RD requestDownload STC startCommunication
RDBCI readDataByCommonIdentifier STDM startDevelopmentMode
RDBLI readDataByLocalIdentifier STDS startDiagnosticSession
RDTCBS readDTCByStatus STRBA startRoutineByAddress
REI readEcuIdentification STRBLI startRoutineByLocalIdentifier
RFFD readFreezeFrameData TD transferData
RMBA readMemoryByAddress TP testerPresent
RRRBA requestRoutineResultsByAddress WDBLI writeDataByLocalIdentifier
RRRBLI requestRoutineResultsByLocalIdentifier WMBA writeMemoryByAddress
RSODTC readStatusOfDTC
Table 3.3.1 - Summary of service mnemonic
3.3.2 - Summary of negative response code mnemonic
Mnemonic Negative Response Code Name Mnemonic Negative Response Code Name
B-RR busy-RepeatRequest IDT improperDownloadType
BTDCE blockTransferDataChecksumError IK invalidKey
CNCORSE conditionsNotCorrectOrRequestSequenceErr IUT improperUploadType
CNDNOBR canNotDownloadNumberOfBytesRequested RCR-RP requestCorrectlyReceived-ResponsePending
CNDTSA canNotDownloadToSpecifiedAddress RNC routineNotComplete
CNUFSA canNotUploadFromSpecifiedAddress ROOR requestOutOfRange
CNUNOBR canNotUploadNumberOfBytesRequested RTDNE requiredTimeDelayNotExpired
DNA downloadNotAccepted SAD-SAR securityAccessDenied-SecurityAccessRequested
ENOA exceedNumberOfAttempts SFNS-IF subFunctionNotSupported-invalidFormat
GR generalReject SNS serviceNotSupported
IAIBT illegalAddressInBlockTransfer SNSIADM serviceNotSupportedInActiveDiagnosticMode
IBCDBT incorrectByteCountDuringBlockTransfer TA transferAborted
IBCIBT illegalByteCountInBlockTransfer TS transferSuspended
IBTT illegalBlockTransferType UNA uploadNotAccepted
Table 3.3.2 - Summary of negative response code mnemonic

Page: 14 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

3.3.3 - Summary of parameter mnemonic

Mnemonic Parameter Name Mnemonic Parameter Name
AEWORA abnormalExitWithOutResultsAvailable EM_ encryptingMethod
AEWRA abnormalExitWithResultsAvailable EOLSSM endOfLineSystemSupplierMode
AG AllGroups EOLVMM endOfLineVehicleManufacturerMode
AM_ accessMode EROTAN exhaustRegulationOrTypeApprovalNum.
ASCII American Standard Code for Info. Interchg F formula
BCD binaryCodedDecimal FCS freezeCurrentState
BDTC_ BodyDTC FFNR_ freezeFrameNumber
BG BodyGroup GODI_ groupOfDiagnosticInformation
BMRWM bitMappedReportedWithMask GODTC_ groupOfDTC
BMRWOM bitMappedReportedWithOutMask INP initialisationParameter
BTC-NB blockTransferComplete-NextBlock IO_ identificationOption
CDDDLI clearDynamicallyDefinedLocalIdentifier IOCO_ inputOutputControlOption
CDTC_ ChassisDTC IOLI_ inputOutputLocalIdentifier
CG ChassisGroup IRV_ identificationRecordValue
CM_ compressionMethod KEY key
CO_ controlOption LODTCAS_ listOfDTCAndStatus
CS_ controlStatus LORV_ listOfRecordValues
DBLI defineByLocalIdentifier LTA longTermAdjustment
DBMA defineByMemoryAddress MA_ memoryAddress
DCM_ diagnosticMode MNROBL maximumNumberOfBlockLength
DDDLI_ dynamicallyDefinedLocalIdentifier MS_ memorySize
DFI_ dataFormatIdentifier NEWORA normalExitWithOutResultsAvailable
DNM_ definitionMode NEWRA normalExitWithResultsAvailable
DTC_ Diagnostic Trouble Code NO no
DTCFS_ DTCFaultSymptom NODTCD noDTCDetected
DTCM-I DTCMaturing-Intermittent NODTCS noDTCStored
DTCNP DTCNotPresent NROBOP numberOfBytesOfParameter
DTCP DTCPresent NRODTC_ numberOfDTC
DTCSS_ DTCStorageState NRODTCS numberOfDTCStored
DTCRF_ DTCReadinessFlag OBDIIM onBoardDiagnosticMode II Mode
DTCTCFFS DTCThatCausedFreezeFrameStored OFF off
DTM-SDM defaultMode-StandardDiagnosticMode ON on
ECO executeControlOption P packet
ECUAM ECUAdjustmentMode PD programmingDate
ECUDM ECUDevelopmentMode PDTC_ PowertrainDTC
ECUIDT ECUIdentificationDataTable PG PowertrainGroup
ECUIP_ ECUIdentificationParameter PIDDDLI_ positionInDynamicallyDefinedLocalId.
ECUIST ECUIdentificationScalingTable PIRLI_ positionInRecordLocalIdentifier
ECUPM ECUProgrammingMode PO powerOn
ECUVCM ECUVariantCodingMode POWMC powerOnWhileMaintainingCommunicat.

Page: 15 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Mnemonic Parameter Name Mnemonic Parameter Name

PT periodicTransmissions SSECUHVN systemSupplierECUHardwareVersionNum
RA_ routineAddress SSECUSN systemSupplierECUSoftwareNumber
RAMI_ recordAccessMethodIdentifier SSECUSVN systemSupplierECUSoftwareVersionNum.
RBD reservedByDocument SSS systemSupplierSpecific
RBDTC requestByDTC STA shortTermAdjustment
RBLI requestByLocalIdentifier TESTC testComplete
RC_ responseCode TESTNC testNotComplete
RCI_ recordCommonIdentifier TPI timingParameterIdentifier
RCS reportCurrentState TREP_ transferResponseParameter
RCTECU returnControlToECU TRTP_ transferRequestParameter
RELI_ routineLocalIdentifier UC unCompressed
RETO_ routineExitOption UCMS unCompressedMemorySize
RETS_ routineExitStatus UE unEncrypted
REYO_ routineEntryOption NCG NetworkCommunicationGroup
REYS_ routineEntryStatus USN unSignedNumeric
RI_ recordIdentification VMS vehicleManufacturerSpecific
RIOC reportInputOutputConditions VIN vehicleIdentificationNumber
RIOCP reportInputOutputCalibrationParameter(s) VMECUHN vehicleManufacturerECUHardwareNum.
RIOS reportInputOutputScaling WLS_ warningLampState {DTC}
RLI_ recordLocalIdentifier Y yes
RLI_ASI recordLocalIdentifier_AfersalesServiceId
RP recordParameter
RRD_ responseRequired
RRS_ routineResults
RSD requestSeed
RS resetStatus
RM_ resetMode
RSCOTSN repairShopCodeOrTesterSerialNumber
RTD resetToDefault
RV_ recordValue
SAA securityAccessAllowed
SEED seed
SEV stateEncodedVariable
SFP signedFloatingPoint
SK sendKey
SN signedNumeric
SNOET systemNameOrEngineType
SODTC-RT statusOfDTC-Request
SODTC_ statusOfDTC
SSD systemSupplierData
SSECUHN systemSupplierECUHardwareNumber
Table 3.3.3 - Summary of parameter mnemonic (cont’d)

Page: 16 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

4 - Conventions
This document is guided by the conventions discussed in the OSI Service Conventions (ISO/TR 8509) as
they apply to the diagnostic services. These conventions define the interactions between the service user and
the service provider. Information is passed between the service user and the service provider by service
primitives, which may convey parameters.
4.1 - Service description convention
This section defines the layout used to describe the diagnostic services. It includes:
• Parameter Definition
• Message Data Bytes
• Message Description
• Message Flow Example
• Implementation Example
4.1.1 - Parameter definition
This section defines the use and the values of parameters used by the service.
4.1.2 - Message data bytes
The definition of each message includes a table which lists the parameters of its primitives: request/indication
("Req/Ind"), response/confirmation ("Rsp/Cnf") for positive or negative result. All have the same structure.
The first table (refer to section 4.1.2.1) describes the request message, the second table (refer to section
4.1.2.2) the positive response message and the third table (refer to section 4.1.2.3) the negative response
message. Thus, only a positive or a negative response message may be used; both are listed in separate
tables because the list of parameters differ between positive and negative response messages.
4.1.2.1 - Request message
The following table shows a general service table structure and its syntax.

Type Parameter Name *) Hex Value Mnemonic

Header Format Byte M xx FMT

Bytes Target Byte C1) xx TGT
Source Byte C1) xx SRC
Length Byte C2) xx LEN
<ServiceId> <Service Name> Request Service Identifier M xx SN
<Parameter <List of parameters> = [ C3) xx=[ PN
Type> <Parameter Name> xx
: : :
<Parameter <Parameter Name>] xx]
Type>
CS Checksum Byte M xx CS
Table 4.1.2.1 - Request message

*) Cvt. = Convention; This column specifies the convention of each type used in a message.

Page: 17 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

C1) Condition 1: The header bytes "Target" and "Source" depend on the content of the "Format Byte" which
is specified in the ISO 14230-2 (KWP 2000 Part 2: Data Link Layer) document. Both either exist or do
not exist in the header of each message.

C2) Condition 2: The header byte "Length" depends on the content of the "Format Byte" which is specified in
the ISO 14230-2 (KWP 2000 Part 2: Data Link Layer) document.

C3) Condition 3: These parameters may be either mandatory (M) or user optional (U), depending on the
individual message.

The content of each message table shown in bold font is defined in the document ISO 14230-2 (KWP 2000
Part 2: Data Link Layer).

Table content description:

• Under the <Service Name> Request Message are listed the parameters specific to the service
request/indication.
• Under the <Service Name> Positive Response Message are listed the parameters specific to the
service response/confirmation in case the requested service was successful.
• Under the <Service Name> Negative Response Message are listed the parameters specific to the
service response/confirmation in case the requested service has failed or could not be completed in time.

For a given primitive, the presence of each parameter is described by one of the following values:
• M: mandatory;
• U: user option; the parameter may or may not be supplied, depending on dynamic usage by the user;
• C: conditional; the presence of the parameter depends upon other parameters within the service;
• S: mandatory (unless specified otherwise) selection of a parameter from a parameter list;
4.1.2.2 - Positive response message
A positive response message shall be sent by the server if it is able to completely perform the requested
actions.

Type Parameter Name *) Hex Value Mnemonic

Header Format Byte M xx FMT

Bytes Target Byte C1) xx TGT
Source Byte C1) xx SRC
Length Byte C2) xx LEN
<ServiceId> <Service Name> Positive Response Service Identifier M xx SNPR
<Parameter <List of parameters> = [ C3) xx=[ PN
Type> <Parameter Name> xx
: : :
<Parameter <Parameter Name>] xx]
Type>
CS Checksum Byte M xx CS
Table 4.1.2.2 - Positive response message

Page: 18 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

4.1.2.3 - Negative response message

A negative response message shall be sent by the server if it is not able to completely perform the requested
actions.

Type Parameter Name *) Hex Value Mnemonic

Header Format Byte M xx FMT

Bytes Target Byte C1) xx TGT
Source Byte C1) xx SRC
Length Byte C2) xx LEN
<ServiceId> negativeResponse Service Identifier M 7F NR
<ServiceId> <Service Name> Request Service Identifier M xx SN
<Parameter responseCode=[ M xx=[ RC_...
Type> KWP2000ResponseCode { section 4.4 }, 00-8F,
manufacturerSpecific] 90-FF]
CS Checksum Byte M xx CS
Table 4.1.2.3 - Negative response message
4.1.3 - Message description
This section provides a description of the actions performed by the client and the server which are specific to
the KWP 2000 data link.
The response condition is service specific and defined separately for each service.
4.1.4 - Message flow examples
This section provides message flow descriptions presented in a table format. Time relates to the table in a
top to bottom sequence. The table consists of three columns:
• column 1: includes the relevant inter-message timing which is specified in the document ISO 14230-2
(KWP 2000 Part 2: Data Link Layer). The message shall be started within the relevant inter-message
timing.
• column 2: includes all requests sent by the client to the server
• column 3: includes all responses sent by the server to the client
• The reading entry of the message flow table always starts with the first item in the time column "P3" (1st
column) followed by a request message of the client (2nd column). The next entry is the timing parameter
"P2" (1st column) for the server to send the positive or negative response message (3rd column).

For simplification all messages are described without any identifiers and/or data values. Details of messages
are always specified in the section: Message data bytes.

time client (Tester) server (ECU)

P3 <Service Name> Request[...]
P2 <Service Name> PositiveResponse[...]
Table 4.1.4 - Message flow example of physical addressed service

Note: Above message flow example is not documented for each service. Only services, which call for more
detailed message flow description shall have their own message flow section.
4.1.5 - Implementation example

4.1.5.1 - Test specification

This section specifies the test conditions to perform the service shown in the section 4.1.5.2 - Message flow.

Page: 19 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

4.1.5.2 - Message flow

This section specifies the message flow of an example which is related to the service specified in above main section.
STEP#1 service name(...)
time Client (tester) Request Message Hex
P3 service name.ReqSId[ xx
data byte#2
:
data byte#m]

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 service name.PosRspSId[ xx negativeResponse Service Identifier 7F
recordValue#1 xx service name.ReqSId[ xx
: : responseCode { refer to section 4.4 }] xx
recordValue#m] xx
return(main) return(responseCode)

4.2 - Functional unit table

The intention of specifying functional unit tables is to group similar Keyword Protocol 2000 services into a
functional unit. The definition of each functional unit includes a table which lists its services.

Functional Unit Description

Diagnostic Management This functional unit includes Keyword Protocol 2000 services which are
used to realize diagnostic management functions between the client
(tester) and the server (ECU).

Data Transmission This functional unit includes Keyword Protocol 2000 services which are
used to realize data transmission functions between the client (tester) and
the server (ECU).

Stored Data Transmission This functional unit includes Keyword Protocol 2000 services which are
used to realize stored data transmission functions between the client
(tester) and the server (ECU).

Input / Output Control This functional unit includes Keyword Protocol 2000 services which are
used to realize input / output control functions between the client (tester)
and the server (ECU).

Remote Activation of Routine This functional unit includes Keyword Protocol 2000 services which are
used to realize remote activation of routine functions between the client
(tester) and the server (ECU).

Upload / Download This functional unit includes Keyword Protocol 2000 services which are
used to realize upload / download functions between the client (tester) and
the server (ECU).

Table 4.2 - Keyword Protocol 2000 functional units

Page: 20 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

4.3 - Service Identifier value summary table

The purpose of the "Service Identifier value summary table" is to provide an overview about all services
specified/referenced in this document. The table is designed to assist system designers at a very early stage in the
development of a new system with self diagnostic capabilities and serial interface to select the appropiate diagnostic
services for the system to be developed without studying the entire document.

The different symbols used in the table shall indicate the level of importance of each diagnostic service based on the
diagnostic mode enabled.

The header of the "Service Identifier value summary table" does build a reference between the parameter
diagnosticMode (columns 3 through 6) of the startDiagnosticSession service. In addition, the header line "Security
Access Required" has been added. The "YES/NO" per column shall indicate, which diagnosticMode shall be followed
by a securityAccess service. The parameter accessMode of the securityAccess service may have different levels of
security for seed and key creation/manipulation.

• The left column of the following table lists all services of the Diagnostic Services Specification.
• The 1st column specifies the Mnemonic of the service.
• The 2nd column indicates which services of the ISO 14230 Keyword Protocol 2000 are included in the KWP 2000
Part 3 Implementation Recommended Practice document.
• The 3rd column specifies the services of the "defaultMode, OBD II Mode, standardDiagnosticMode,
ECUAdjustmentMode, and ECUVariantCodingMode" which are recommended to be implemented in each
server (ECU) if the electronic system supports the functionality of these services. Those ECUs which comply with
the CARB requirements which must be compliant to SAE J1979 E/E Diagnostic Test Modes shall support the
header/frame for each service as specified in the Keyword Protocol 2000 Part 2 Data Link Layer Recommended
Practice.
• The 4th column specifies the services of the "ECUProgrammingMode," which shall be implemented to program
the memory (e.g. flash) of the server (ECU).
• The 5th column specifies the services of the "ECUDevelopmentMode" which may be implemented during the
development of the electronic system.
• The 6th column assigns the KWP 2000 Implementation "Request Hex Value".
• The 7th column assigns the KWP 2000 Implementation "Positive Response Hex Value". The positive response
service identifier values are built from the request service identifier values by setting
"bit 6 = 1".
• The 8th column indicates if a "negative response message (ServiceId = $7F)" shall be supported by the server
(ECU).
• The 9th column includes the "section number" of each service.
• The 3rd, 4th and 5th column specify, in addition to above description, the
"endOfLineVehicleManufacturerMode and endOfLineSystemSupplierMode". Those diagnostic modes are
recommended to be used for end of line testing at the system supplier site (e.g. ECU testing) or vehicle end of line
testing at the vehicle manufacturer site (e.g. vehicle testing).

Page: 21 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

The header of the table indicates default / standardDiag. / OBD II / ECUAdjustment / ECUVariantCoding - Mode
which diagnosticMode (session) ê
enables which set of Diagnostic ECUProgrammingMode
Services. ê
ECUDevelopmentMode
ê
endOfLineVehicleManufacturerMode, endOfLineSystemSupplierMode
ê ê ê
Column Number 1 2 3 4 5 6 7 8 9
Security Access Required NO YES YES
Diagnostic Service Name Mnemonic KWP Default / ECU ECU Req. Pos. Neg. Section
(3.3.1) 2000 Std. Diag. / Prog Dev. Value Rsp. Rsp. No.
Part No OBD II Md. Mode Mode Value Value
startCommunication STC ]
2,] ¨ ¨ ¨ 81 C1 7F ]
5.1,]
testerPresent TP 3 ¨ ¨ ¨ 3E 7E 7F 6.4
stopCommunication SPC ]
2,] ¨ ¨ ¨ 82 C2 7F ]
5.2,]
readEcuIdentification REI 3 u u u 1A 5A 7F 6.6
readDTCByStatus RDTCBS 3 u u 18 58 7F 8.2
clearDiagnosticInformation CDI 3 u u 14 54 7F 8.5
SAE J1979 Diag. Test Modes J1979M 3 n 00-0F 40-4F 7F 12.2
accessTimingParameters ATP ]
2,]    83 C3 7F ]
5.3,]
startDiagnosticSession STDS 3  u u 10 50 7F 6.1
readDataByLocalIdentifier RDBLI 3  u 21 61 7F 7.1
dynamicallyDefineLocalId. DDLI 3   2C 6C 7F 7.4
inputOutputCtrlByLocalId. IOCBLI 3   30 70 7F 9.1
startRoutineByLocalIdentifier STRBLI 3    31 71 7F 10.1
stopRoutineByLocalIdentifier SPRBLI 3    32 72 7F 10.3
req.RoutineResultsByLocalId. RRRBLI 3    33 73 7F 10.5
writeDataByLocalIdentifier WDBLI 3    3B 7B 7F 7.5
readFreezeFrameData RFFD 3   12 52 7F 8.4
ecuReset ER 3    11 51 7F 6.5
readStatusOfDTC RSODTC 3 ‚ ‚ 17 57 7F 8.3
readDataByCommonId. RDBCI 3 ƒ ƒ 22 62 7F 7.2
stopDiagnosticSession SPDS 3 u 20 60 7F 6.2
securityAccess SA 3 ‚ ‚ 27 67 7F 6.3
requestDownload RD 3 u u 34 74 7F 11.1
requestUpload RU 3  u 35 75 7F 11.2
transferData TD 3 u u 36 76 7F 11.3
requestTransferExit RTE 3 u u 37 77 7F 11.4
startRoutineByAddress STRBA 3 u 38 78 7F 10.2
stopRoutineByAddress SPRBA 3 u 39 79 7F 10.4
req.RoutineResultsByAddress RRRBA 3 u 3A 7A 7F 10.6
readMemoryByAddress RMBA 3 u 23 63 7F 7.3
writeMemoryByAddress WMBA 3 u 3D 7D 7F 7.7
writeDataByCommonId. WDBCI 3 ‚ ‚ 2E 6E 7F 7.6
inputOutputCtrlByCommonId. IOCBCI 3   2F 6F 7F 9.2
escCode (KWP 2000 only) EC 3 80 C0 7F 12.1
readDiagnosticTroubleCodes - 13 53 7F 8.1
setDataRates - 26 66 7F 7.8
Table 4.3 - Service Identifier value summary table
] Communication services are specified in the document ISO 14230-2 KWP 2000 Part 2: Data Link Layer!
¨ Service shall be implemented in order to be able to start, maintain, and stop communication!
u Essential service in this diagnostic mode!
n Essential service in this diagnostic mode if ECU supports OBD II requirements!
 Selection of service is vehicle manufacturer/project specific; the data content is project specific!
‚ Selection of service requires additional detail to be specified by vehicle manufacturer/system supplier; the data
content/structure and/or method is project specific!
ƒ Service shall be reserved mainly for legislative purposes (e.g. emission related test data; future EOBD)!

Page: 22 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

4.4 - Response Code value summary table

The following table lists and assigns hex values for all response codes used in KWP 2000.
Part 3: Implementation Recommended Practice addition:
The KWP 2000 Part 3 Implementation Recommended Practice has included each negative response code definition to
reduce the number of documents which are referenced. The abbreviation "RC_" is used in combination with each
"Mnemonic" to clearly identify the name of the response code.
Note: The use of (a) negative response message(s) by the server (ECU) shall be in case the server (ECU) can not
respond with a positive response message on a client (tester) request message. In such case the server (ECU)
shall send one of the response codes listed below as specified in figure 3.
The figure below specifies the server (ECU) behaviour on a client (tester) request message. This figure shows the logic
as specified in the description of the response codes and to be implemented in the server (ECU) and client (tester) as
appropriate.

Start of service

NO
V alid M ess age? N o R espons e M ess age

Y ES

R equest M ess age NO

supported?

Y ES

cas e #1
YE S R C = $78
E xtended P 2
tim ing w indow ?

NO

cas e #2
YE S R C = $23
Serv ice in
progres s ?

NO
Pos itiv e R es pons e NO
cas e #3
M es sage R eady ? YE S R C = $21
Serv er bus y ?

YE S
NO

cas e #4
YE S R C = $10
G eneral rejec t?

NO

R C = $xx

N egativ e R es pons e N egativ e R es ponse

M es s age R C = $10, M es s age R C = $23, N egativ e R es pons e
general rejec t routineN otC om plete M es sage R C = $11,
s erv ic eN otS upported or
N egativ e R es ponse N egativ e R es pons e R C = $12,
N egativ e R es pons e
P ositiv e R esponse M es s age M ess age R C = $21, M es s age R C = $78,
M ess age R C = $xx s ubFunc tionN otSupported
bus yR epeatR eques t res pons ePending

End of service

Figure 3 - Server (ECU) positive and negative response message behaviour

Page: 23 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex Value Definition of Response Code Mnemonic

00 reservedByDocument RBD
This value shall not be used as a response code.
Table 4.4.0 - Reserved response code
Hex Value Definition of Response Code Mnemonic
10 generalReject GR
The service is rejected but the server (ECU) does not specify the reason of the rejection.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code if no other response code is available which properly indicates the
rejection. It is up to the scan tool manufacturer to define the reaction of the client (tester) in case this response code is sent by the
server (ECU). If a repetition of the request message is performed the number of repetitions shall be limited by the scan tool
manufacturer to a certain value to prevent deadlock states.
Table 4.4.1 - Definition of response code 10 - generalReject
Hex Value Definition of Response Code Mnemonic
11 serviceNotSupported SNS
This response code indicates that the requested action will not be taken because the server (ECU)
does not support the requested service.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message with a service
identifier which is either unknown (not a KWP 2000 Service Identifier) or not supported by the server (ECU).
Table 4.4.2 - Definition of response code 11 - serviceNotSupported
Hex Value Definition of Response Code Mnemonic
12 subFunctionNotSupported-invalidFormat SFNS-IF
This response code indicates that the requested action will not be taken because the server (ECU)
does not support the arguments of the request message or the format of the argument bytes do not
match the prescribed format for the specified service.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message with a known and
supported service identifier but with "sub parameters“ which are either unknown or not supported or have an invalid format. It is
recommended that the client (tester) shall not repeat the identical request message.
Table 4.4.3 - Definition of response code 12 - subFunctionNotSupported-invalidFormat
Hex Value Definition of Response Code Mnemonic
21 busy-repeatRequest B-RR
This response code indicates that the server (ECU) is temporarily too busy to perform the
requested operation. In this circumstance repetition of the "identical request message" or "another
request message" shall be performed by the client (tester). This response code shall be returned
for example while a server (ECU) is in the process of clearing stored DTC(s) information or
fetching information.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message at a time when the
server (ECU) is busy with internal processing not related to the current request message. It is recommended that the client (tester)
shall repeat the request message within the P3 timing window.
Table 4.4.4 - Definition of response code 21 - busy-RepeatRequest

Page: 24 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Hex Value Definition of Response Code Mnemonic

22 conditionsNotCorrectOrRequestSequenceError CNCORSE
This response code indicates that the requested action will not be taken because the server (ECU)
prerequisite conditions are not met. This request may occur when sequence sensitive requests are
issued in the wrong order.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a known and supported request
message at a time where the server (ECU) has expected another request message because of a predefined sequence of services. A
typical example of occurence is the securityAccess service which requires a sequence of messages as specified in the message
description of this service.
Table 4.4.5 - Definition of response code 22 - conditionsNotCorrectOrRequestSequenceError
Hex Value Definition of Response Code Mnemonic
23 routineNotComplete RNC
This response code indicates that the request message was properly received by the server (ECU)
and the routine, which has been initiated by the request message is already in process, but not yet
completed. The server (ECU) knows in advance that the processing time is greater than the P2
timing window. The successful execution and completion of the request message will not be
indicated by a positive response message. In case the client (tester) repeats the request message
the server (ECU) shall "not reinitiate the task" if the initial task has not been completed!
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a clearDiagnosticInformation request
message and if the server (ECU) is still clearing the diagnostic information and will not be finished before the timing parameter
value of P2max is reached. In this particular case the server (ECU) shall send the negative response message with this response
code. In case the client (tester) "repeats the identical request message the server (ECU) shall not restart the
clearDiagnosticInformation routine". It is recommended to sent the next request message close to the timing parameter value of
P3max. This increases the amount of time available to the server (ECU) to finish the routine.
Table 4.4.6 - Definition of response code 23 - routineNotComplete
Hex Value Definition of Response Code Mnemonic
31 requestOutOfRange ROOR
This response code indicates that the requested action will not be taken because the server (ECU)
detects the request message contains a data byte(s) which attempt(s) to substitute (a) value(s)
beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only
defined to 100).
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message including data
bytes to adjust a variant which does not exist (invalid) in the server (ECU). This response code shall be implemented for all
services which allow the client (tester) to write data or adjust functions by data in the server (ECU). The communication timing is
not affected!
Table 4.4.7 - Definition of response code 31 - requestOutOfRange
Hex Value Definition of Response Code Mnemonic
33 securityAccessDenied-securityAccessRequested SAD-SAR
This response code indicates that the requested action will not be taken because the server's
(ECU's) security strategy has not been satisfied by the client (tester).
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code if one of the following cases occur:
• the test conditions of the server (ECU) are not met
• the required message sequence e.g. startDiagnosticSession, securityAccess is not met
the client (tester) has sent a request message which requires an unlocked server (ECU)
Table 4.4.8 - Definition of response code 33 - securityAccessDenied-securityAccessRequested

Page: 25 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex Value Definition of Response Code Mnemonic

35 invalidKey IK
This response code indicates that security access has not been given by the server (ECU) because
the key sent by the client (tester) did not match with the key in the server's (ECU's) memory. This
counts as an attempt to gain security. The server (ECU) shall remain locked!
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a securityAccess request message
with the sendKey and Key parameter where the key value does not match the key value stored in the server's (ECU's) memory.
The server (ECU) shall increment ist internal securityAccessFailed counter.
Table 4.4.9 - Definition of response code 35 - invalidKey
Hex Value Definition of Response Code Mnemonic
36 exceedNumberOfAttempts ENOA
This response code indicates that the requested action will not be taken because the client (tester)
has unsuccessfully attempted to gain security access more times than the server's (ECU's) security
strategy will allow. Refer to message description of the securityAccess service definition.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a securityAccess request message
with the sendKey and Key parameter where the key value does not match the key value stored in the server's (ECU's) memory
and the number of attempts (securityAccessFailed counter value) have reached the server's (ECU's) securityAccessFailed
calibration value.
Table 4.4.10 - Definition of response code 36 - exceedNumberOfAttempts
Hex Value Definition of Response Code Mnemonic
37 requiredTimeDelayNotExpired RTDNE
This response code indicates that the requested action will not be taken because the client's
(tester's) latest attempt to gain security access was initiated before the server's (ECU's) required
timeout period had elapsed.
The communication timing is not affected by this response code!
Example: An invalid Key requires the client (tester) to start over from the beginning with a securityAccess service. If the security
protection algorithm is not passed after "X" failed attempts ("X" = specified in the server's (ECU's) memory), all additional
attempts are rejected for at least "Y" seconds ("Y" = specified in the server's (ECU's) memory). The "Y" second timer shall begin
with the "X" failed attempt or upon a power/ignition cycle or reset of the server (ECU) to ensure a security lockout after all
power interruptions.
Table 4.4.11 - Definition of response code 37 - requiredTimeDelayNotExpired
Hex Value Definition of Response Code Mnemonic
40 downloadNotAccepted DNA
This response code indicates that an attempt to download to a server's (ECU's) memory cannot be
accomplished due to some fault conditions.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a requestDownload request message
which the server (ECU) can not accept and the failure can not be described with another negative response code.
Table 4.4.12 - Definition of response code 40 - downloadNotAccepted
Hex Value Definition of Response Code Mnemonic
41 improperDownloadType IDT
This response code indicates that an attempt to download to a server's (ECU's) memory cannot be
accomplished because the server (ECU) does not support the type of download being attempted.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a requestDownload request message
with transferRequestParameters which are unknown to the server (ECU) and therefore will not be supported.
Table 4.4.13 - Definition of response code 41 - improperDownloadType

Page: 26 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Hex Value Definition of Response Code Mnemonic

42 canNotDownloadToSpecifiedAddress CNDTSA
This response code indicates that an attempt to download to a server's (ECU's) memory cannot be
accomplished because the server (ECU) does not recognize the target address for the download as
being available.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a requestDownload request message
with transferRequestParameters which includes a memory address which can not be downloaded to.
Table 4.4.14 - Definition of response code 42 - canNotDownloadToSpecifiedAddress
Hex Value Definition of Response Code Mnemonic
43 canNotDownloadNumberOfBytesRequested CNDNOBR
This response code indicates that an attempt to download to a server's (ECU's) memory cannot be
accomplished because the server (ECU) does not recognize the number of bytes for the download
as being available.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a requestDownload request message
with transferRequestParameters which includes a value in the uncompressedMemorySize parameter which does not fit with the
number of bytes expected for this download by the server (ECU).
Table 4.4.15 - Definition of response code 43 - canNotDownloadNumberOfBytesRequested
Hex Value Definition of Response Code Mnemonic
50 uploadNotAccepted UNA
This response code indicates that an attempt to upload from a server's (ECU's) memory cannot be
accomplished due to some fault conditions.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent an requestUpload request message
which the server (ECU) can not accept and the failure can not be described with another negative response code.
Table 4.4.16 - Definition of response code 50 - uploadNotAccepted
Hex Value Definition of Response Code Mnemonic
51 improperUploadType IUT
This response code indicates that an attempt to upload from a server's (ECU's) memory cannot be
accomplished because the server (ECU) does not support the type of upload being attempted.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent an requestUpload request message
with transferRequestParameters which are unknown to the server (ECU) and therefore will not be supported.
Table 4.4.17 - Definition of response code 51 - improperUploadType
Hex Value Definition of Response Code Mnemonic
52 canNotUploadFromSpecifiedAddress CNUFSA
This response code indicates that an attempt to upload from a server's (ECU's) memory cannot be
accomplished because the server (ECU) does not recognize the target address for the upload as
being available.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a requestUpload request message
with transferRequestParameters which includes a memory address which can not be uploaded from.
Table 4.4.18 - Definition of response code 52 - canNotUploadFromSpecifiedAddress

Page: 27 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex Value Definition of Response Code Mnemonic

53 canNotUploadNumberOfBytesRequested CNUNOBR
This response code indicates that an attempt to upload from a server's (ECU's) memory cannot be
accomplished because the server (ECU) does not recognize the number of bytes for the upload as
being available.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a requestUpload request message
with transferRequestParameters which includes a value in the uncompressedMemorySize parameter which does not fit with the
number of bytes expected for this upload by the server (ECU).
Table 4.4.19 - Definition of response code 53 - canNotUploadNumberOfBytesRequested
Hex Value Definition of Response Code Mnemonic
71 transferSuspended TS
This response code indicates that a data transfer operation was halted due to some fault.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message with incorrect
data. In such case this response code shall be sent if no other response code matches the situation..
Table 4.4.20 - Definition of response code 71 - transferSuspended
Hex Value Definition of Response Code Mnemonic
72 transferAborted TA
This response code indicates that a data transfer operation was halted due to some fault, but will
not be completed later.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message with data which
require the server (ECU) to abort the data transfer.
Table 4.4.21 - Definition of response code 72 - transferAborted
Hex Value Definition of Response Code Mnemonic
74 illegalAddressInBlockTransfer IAIBT
This response code indicates that the starting address included in a request message is either out of
range , protected, the wrong type of memory for the receiving data, or cannot be written to for
some reason.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message with an
memoryAddress which is in conflict with the memoryAddresses supported by the server (ECU).
Table 4.4.22 - Definition of response code 74 - illegalAddressInBlockTransfer
Hex Value Definition of Response Code Mnemonic
75 illegalByteCountInBlockTransfer IBCIBT
This response code indicates that the number of data bytes included in the request message is
either more than the request message can accommodate, requires more memory than is available
at the requested starting address, or cannot be handled by the software.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message with an amount of
data which does not fit with the number of bytes expected for this data transfer.
Table 4.4.23 - Definition of response code 75 - illegalByteCountInBlockTransfer
Hex Value Definition of Response Code Mnemonic
76 illegalBlockTransferType IBTT
This response code indicates that the transferRequestParameter(s) included in the transferData
request message is (are) not valid for this application.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a transferData request message with
transferRequestParameter(s) which include invalid/illegal parameter values for the requested data transfer.
Table 4.4.24 - Definition of response code 76 - illegalBlockTransferType

Page: 28 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Hex Value Definition of Response Code Mnemonic

77 blockTransferDataChecksumError BTDCE
This response code indicates that the data checksum calculated for the transferData messages does
not agree with the expected value.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has completed the data transfer to the server
(ECU) and the server (ECU) has computed a data checksum from the data transfer which is different than the one internally
stored.
Table 4.4.25 - Definition of response code 77 - blockTransferDataChecksumError
Hex Value Definition of Response Code Mnemonic
78 reqCorrectlyRcvd-RspPending (requestCorrectlyReceived-ResponsePending) RCR-RP
This response code indicates that the request message was received correctly, and that any
parameters in the request message were valid, but the action to be performed may not be
completed yet. This response code can be used to indicate that the request message was properly
received and does not need to be re-transmitted, but the server (ECU) is not yet ready to receive
another request.
This response code shall only be used in a negative response message if the server (ECU) will
not be able to receive further request messages from the client (tester) within the P3 timing
window. This may be the case if the server (ECU) does data processing or executes a routine
which does not allow any attention to serial communication.
The following description specifies the communication timing method: This response code shall
manipulate the P2max timing parameter value in the server (ECU) and the client (tester). The
P2max timing parameter is set to the value [in ms] of the P3max timing parameter. In addition,
the client (tester) shall disable the testerPresent service. As soon as the server (ECU) has
completed the task (routine) initiated by the request message it shall send either a positive or
negative response message (negative response message with a response code other than $78)
based on the last request message received. When the client (tester) has received the positive
response message which has been preceeded by the negative response message(s) with this
response code, the client (tester) and the server (ECU) shall reset the P2 timing parameter to the
previous P2 timing value. In addition, the client (tester) shall re-enable the testerPresent service.
The client (tester) shall not repeat the request message after the reception of a negative
response message with this response code!
The communication timing is affected if this response code is used (refer to section 4.4.1 in
KWP 2000 Part 2: Data Link Layer Recommended Practice)!
Example: A typical example where this response code may be used is when the client (tester) has sent a request message which
includes data to be programmed or erased in flash memory of the server (ECU). If the programming/erasing routine (usually
executed out of RAM) routine is not able to support serial communication while writing to the flash memory the server (ECU)
shall send a negative response message with this response code. As soon as the data are programmed or erased in flash memory
the server (ECU) shall send a positive response message (or negative response message but not RC_78).
Table 4.4.26 - Definition of response code 78 - reqCorrectlyRcvd-RspPending (requestCorrectlyReceived-ResponsePending)
Hex Value Definition of Response Code Mnemonic
79 incorrectByteCountDuringBlockTransfer IBCDBT
This response code indicates that the number of data bytes that was expected to be sent was not
the same as the number of data bytes received.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent the requestTransferExit request
message which indicates to the server (ECU) that the client (tester) will not send any further data bytes but the number of data
bytes expected by the server (ECU) does not match the number of data bytes sent by the client (tester).
Table 4.4.27 - Definition of response code 79 - incorrectByteCountDuringBlockTransfer

Page: 29 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex Value Definition of Response Code Mnemonic

80 serviceNotSupportedInActiveDiagnosticMode SNSIADM
This response code indicates that the requested action will not be taken because the server (ECU)
does not support the requested service in the diagnostic mode (session) currently active.
The communication timing is not affected by this response code!
Example: The server (ECU) shall send this response code in case the client (tester) has sent a request message
(requestDownload) which e.g. is only supported in the programming mode (session) but the server (ECU) is in a diagnostic mode
(session) which does not support this service.
Table 4.4.28 - Definition of response code 80 - serviceNotSupportedInActiveDiagnosticMode
Hex Value Definition of Response Code Mnemonic
81 - 8F reservedByDocument RBD
This range of values shall be reserved for diagnostic service implementation related future
response code definitions.
90 - F9 vehicleManufacturerSpecific VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument RBD
This value shall not be used as a response code.
Table 4.4.29 - Reserved ranges of response codes

5 - General implementation rules

5.1 - Parameter definitions
The following rules in regard to parameter definitions shall apply:
• The subsequent sections (from section 6. to the end of the document except for the last section) define
the services of each functional unit. In these sections, the service structure makes reference to
parameters, in order to describe the allowable values for such parameters. The parameters of general
purpose are defined in the Diagnostic Services Specification document. Parameters which are specific
to a functional unit are described in the corresponding section.
• This document lists and defines response codes and values. Negative response codes are specified in
section 4.4. Other response codes may be reserved either for future definition by this document or for the
system designer's specific use.
• This document specifies the parameters which shall be used within each KWP 2000 service.
• The sequence of parameters within a service shall not be changed during an implementation.
• This document specifies the parameter memoryAddress based on a three (3) byte address (High Byte,
Middle Byte and Low Byte). Additional bytes of specifying the memoryAddress (e.g. memory type
identifier, larger address range) may be implemented and is the responsibility of the vehicle manufacturer.
This applies to all services which use the memoryAddress parameter.
5.2 - Functional and physical addressed service requests
Two (2) different addressing methods are specified in KWP 2000 to send a service request to a server(s).
• Functional addressing with a three byte header is used by the client if it doesn't know the physical address
of the server that shall respond to a service request or if more than one (1) server can respond to the
request.
• Functional addressing with a one byte header is not possible.
• Physical addressing with a three byte header shall always be a dedicated message to one server. The
header of the service request message indicates (target address) which server shall respond to the
service request message.
• Physical addressing with a one byte header is possible.
• Functional and Physical addressing methods are specified in detail in the document ISO 14230-2 (KWP
2000 Part 2: Data Link Layer).
• The data link shall always be initialized prior to sending any of the KWP 2000 services.

Page: 30 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

5.3 - Message flow examples of physical/functional addressed services

5.3.1 - Physical addressed services

5.3.1.1 - Physical addressed service with positive/negative response message

The table below shows a typical service request followed by a positive response message and a service
request followed by a negative response message.

time client (Tester) server (ECU)

P3 <Service Name> Request[...]
P2 <Service Name> PositiveResponse[...]
P3 <Service Name> Request[...]
P2 <Service Name> NegativeResponse[RC]
P3 <Service Name> Other Request[...]
P2 <Service Name> Other PositiveResponse[...]
Table 5.3.1.1 - Message flow example of physical addressed service
5.3.1.2 - Physical addressed service with periodic transmissions
The table below shows a message flow which describes a physical addressed service request with multiple
positive response messages { PT = periodicTransmissions }.

time client (Tester) server (ECU)

P3 <startDiagnosticSession> Request[PT]
P2 <startDiagnosticSession> PositiveResponse#1[PT]
P2 :
P2 <startDiagnosticSession> PositiveResponse#k[...]
P3* <Service Name> Request A[...]
P2 <Service Name> PositiveResponse A#1[...]
P2 :
P2 <Service Name> PositiveResponse A#m[...]
P3* <Service Name> Request B[...]
P2 <Service Name> PositiveResponse B#1[...]
P2 :
P2 <Service Name> PositiveResponse B#n[...]
P3* <stopDiagnosticSession> Request
P2 OR <stopDiagnosticSession> PositiveResponse
P3* <startDiagnosticSession> Request[...] OR
P2 <startDiagnosticSession> PositiveResponse[...]
P3 <Service Name> Request C[...]
P2 <Service Name> PositiveResponse C[...]
Table 5.3.1.2 - Message flow example of physical addressed service with periodic transmissions

P3* : The values of the "P3*" timing parameters shall be less than the value of "P2min" in order to allow the
client (tester) to send a new request message (refer to section 4.4.1.3 in KWP 2000 Part 2: Data Link Layer
Recommended Practice).

Above message flow describes a physical addressed service request with the periodic transmission mode
enabled. The request message is followed by multiple positive response messages from the physically
addressed server. The periodically transmitted response messages are terminated by the client with a
stopDiagnosticSession request message send to the server which has been initiated within the "P3*" timing
window.

Page: 31 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

5.3.1.3 - Physical addressed service and negative response message(s) with "routineNotComplete
($23)" and "busy-RepeatRequest ($21)"
The table below shows a message flow which describes a physical addressed service request followed by a
negative response message with the response code set to "routineNotComplete ($23)".

Time client (Tester) server (ECU)

P3 <Service Name> Request[...] { server has started routine! }
P2 <Service Name> NegativeResponse[routineNotComplete ($23)]
P3 <Service Name> Request[...]
P2 <Service Name> NegativeResponse[busy-RepeatRequest ($21)]
: :
P3 <Service Name> Request[...]
P2 <Service Name> NegativeResponse[busy-RepeatRequest ($21)]
P3 <Service Name> Request[...] { server has stopped routine! }
P2 <Service Name> PositiveResponse[...]
OR
P2 <Service Name> NegativeResponse[RC ≠ busy-RepeatRequest ($21)]
Table 5.3.1.3 - Physical addressing and negative response with "routineNotComplete ($23)" and
"busy-RepeatRequest ($21)"
Above message flow example is based on a request message from the client which cause the server to
respond with a negative response message including the negative response code "routineNotComplete
($23)". This response code indicates that the request message was properly received by the server and the
routine/task/function (initiated by the request message) is in process, but not yet completed. If the client
repeats or sends another request message the server shall "not reinitiate the task" (in case of the same
request message) if the initial task has not been completed. The server shall send another negative response
message with the response code "busy-RepeatRequest ($21)". The negative response message shall be
sent on each request message as long as the server has not yet completed the initial routine/task/function. If
the server has finished the routine/task/function it shall respond with either a positive response message or a
negative response message with a response code not equal to "busy-RepeatRequest ($21)".
The communication timing is not affected!

Applications which may require above message flow are:

• clearDiagnosticInformation,
• execution of routines
• securityAccess

Page: 32 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

5.3.1.4 - Physical addressed service with "server can not send a positive response within required
timing"

5.3.1.4.1 - Physical addressed service and negative response message with "reqCorrectlyRcvd-
RspPending ($78) within Normal or Extended Timing"
The table below shows a message flow which describes a physical addressed service request followed by a
negative response message with the response code set to "requestCorrectlyReceived-ResponsePending".
time client (Tester) server (ECU)
P3 <Service Name> Request[...]
P2 <Service Name> NegRsp#1[reqCorrectlyRcvd-RspPending ($78)]
:
P2* <Service Name> NegRsp#n[reqCorrectlyRcvd-RspPending ($78)]
P2* <Service Name> PositiveResponse[...]
P3 <Service Name> Other Request[...]
P2 <Service Name> Other PositiveResponse[...]
Table 5.3.1.4.1 - Example of physical addressing and negative response with "reqCorrectlyRcvd-RspPending
($78)"
P2* : P2min to P3max (refer to section 4.4.1 in ISO 14230-2 KWP 2000 Part 2: Data Link Layer Recommended
Practice)

Above message flow example is based on a request message from the client which cause the server to
respond with one or multiple negative response message including the negative response code
"requestCorrectlyReceived-ResponsePending ($78)".
This response code indicates that the request message was received correctly, and that any parameters in
the request message were valid, but the action to be performed may not be completed yet. This response
code can be used to indicate that the request message was properly received and does not need to be
retransmitted, but the server is not yet ready to receive another request.
The negative response message may be sent once or multiple times within a service if required by the
server!
During the period of (a) negative response message(s) the testerPresent service shall be disabled in the
client!
This response code shall only be used in a negative response message if the server will not be able to
receive further request messages from the client within the P3 timing window. This may be the case if the
server does data processing or executes a routine which does not allow any attention to serial
communication.

Note: The communication timing method is specified in section "4.4.1 Timing exceptions" in the ISO 14230-
2 Keyword Protocol 2000 Part 2: Data Link Layer Recommended Practice!

Applications which may require above message flow are:

• clearDiagnosticInformation
• execution of routines
• transferData request messages including up to 255 data bytes
• Flash EEPROM or EEPROM memory programming

Page: 33 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

5.3.1.4.2 - Physical addressed service with "server can not send a positive response within Default
Timing"
The table below shows a message flow which describes a physical addressed service request followed by a
positive response message sent with previously modified timing.

time client (Tester) server (ECU)

P3 startDiagnosticSession.Request[...]
P2 startDiagnosticSession.PosRsp[...]
P3 accessTimingParameters.Request[readLimits]
P2 accessTimingParameters.PosRsp[readLimits, P2-P4]
P3 accessTimingParameters.Request[setValues, P2-P4]
P2 { e.g. P2max = $F2 (18850 ms) } accessTimingParameters.PosRsp[setValues]
{ Modified Timing is active! } { Modified Timing is active! }
P3 <Service Name> Request[...]
P2 <Service Name> PositiveResponse[...]
P3 <stopDiagnosticSession> Request
P2 OR <stopDiagnosticSession> PositiveResponse
P3 <startDiagnosticSession> Request[...] OR
P2 <startDiagnosticSession> PositiveResponse[...]
{ Default Timing is active! } { Default Timing is active! }
P3 <Service Name> Request[...]
P2 <Service Name> PositiveResponse C[...]
Table 5.3.1.4.2 - Physical addressing and modified timing with accessTimingParameters service

P3, P2 : New timing parameter values are active!

Above message flow example describes the method of modifying the timing parameter values in the server
and the client by using the accessTimingParameters service as specified in the ISO 14230-2 Keyword
Protocol 2000 Part 2: Data Link Layer Recommended Practice.
This method shall be used in case a server does not support a negative response message with the
response code "requestCorrectlyReceived-ResponsePending ($78)".

Page: 34 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

5.3.2 - Functional addressed services

5.3.2.1 - Functional addressed service with positive/negative response message

The table below shows a message flow example which describes a functional addressed service request
followed by response messages of multiple servers (ECU#1, ECU#2 ... ECU#n).

time client (Tester) server (ECU)

P3 <Service Name> Request[...] { functional }
P2 <Service Name> PositiveResponse[...] {ECU#1}
P2 <Service Name> NegativeResponse[...] {ECU#2}
: :
P2 <Service Name> PositiveResponse[...] {ECU#n}
P3 <Service Name> Other Request[...]{ functional }
P2 <Service Name> Other PositiveResponse[...] {ECU#1}
P2 <Service Name> Other NegativeResponse[...] {ECU#2}
: :
P2 <Service Name> Other PositiveResponse[...] {ECU#n}
Table 5.3.2.1 - Message flow example of functional addressed service

Above message flow example is based on a functional request message sent by the client. An unknown
number of servers has been initialized previously (e.g. fast initialisation by wake up pattern) which send
positive and negative response messages.
5.3.2.2 - Functional addressed service and negative response message(s) with
"routineNotComplete ($23)" and "busy-RepeatRequest ($21)"
The table below shows a message flow which describes a functional addressed service request followed by a
negative response message with the response code set to "routineNotComplete ($23)" from one (1) of three
(3) server. All other servers send positive response messages.

time client (Tester) server (ECU)

P3 <Service Name> Request[...] { functional } { server has started routine! }
P2 <Service Name> NegRsp[routineNotComplete ($23)] {ECU#1}
P2 <Service Name> PositiveResponse[...] {ECU#2}
P2 <Service Name> PositiveResponse[...] {ECU#3}
P3 <Service Name> Request[...] { functional }
P2 <Service Name> NegRsp[busy-RepeatRequest ($21)] {ECU#1}
P2 <Service Name> PositiveResponse[...] {ECU#2}
P2 <Service Name> PositiveResponse[...] {ECU#3}
P3 <Service Name> Request[...] { functional } { server has stopped routine! }
P2 <Service Name> PositiveResponse[...] {ECU#1}
P2 <Service Name> PositiveResponse[...] {ECU#2}
P2 <Service Name> PositiveResponse[...] {ECU#3}
Table 5.3.2.2 - Functional addressing and negative response with "busy-RepeatRequest ($21)"

Page: 35 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Above message flow example is based on a functional request message from the client which cause one
server (ECU#1) to respond with a negative response message including the negative response code
"routineNotComplete ($23)". The other servers (ECU#2, ECU#3) send a positive response message.
The response code indicates that the request message was properly received by the server and the
routine/task/function (initiated by the request message) is in process, but not yet completed. If the client
repeats or sends another functional request message the server shall "not reinitiate the task" (in case of the
same request message) if the initial task has not been completed. The server shall send another negative
response message with the response code "busy-RepeatRequest ($21)". The negative response message
shall be sent on each functional request message as long as the server has not yet completed the initial
routine/task/function. If the server (ECU#1) has finished the routine/task/function, it shall respond with either
a positive response message or a negative response message with a response code not equal to "busy-
RepeatRequest ($21)".
The communication timing is not affected!

Applications which may require above message flow are:

• clearDiagnosticInformation,
• execution of routines
• securityAccess
5.3.2.3 - Functional addressed service and negative response message with " reqCorrectlyRcvd-
RspPending ($78)"
The table below shows a message flow example which describes a functional addressed request message
followed by a negative response message with the response code set to "requestCorrectlyReceived-
ResponsePending" from one server (ECU#1) and positive response messages from the other servers
(ECU#2, ECU#3).

time client (Tester) server (ECU)

P3 <Service Name> Req[...]
P2 { Functional } <Service Name> NegRsp#1[reqCorrectlyRcvd-RspPendg ($78)] {ECU#1}
P2* <Service Name> PositiveResponse[...] {ECU#2}
P2* <Service Name> PositiveResponse[...] {ECU#3}
P2* <Service Name> NegRsp#2[reqCorrectlyRcvd-RspPendg ($78)] {ECU#1}
P2* :
P2* <Service Name> NegRsp#n[reqCorrectlyRcvd-RspPendg ($78)] {ECU#1}
P2* <Service Name> PositiveResponse[...] {ECU#1}
P3 <Service Name> Req[...]
{ Functional }
P2 <Service Name> PositiveResponse[...] {ECU#1}
P2 <Service Name> PositiveResponse[...] {ECU#2}
P2 <Service Name> PositiveResponse[...] {ECU#3}
Table 5.3.2.3 - Example of functional addressing and negative response with
"reqCorrectlyRcvd-RspPending ($78)"

P2* : P2min to P3max (refer to section 4.4.1 in ISO 14230-2 KWP 2000 Part 2: Data Link Layer Recommended
Practice)

Above message flow example is based on a request message from the client which cause the server to
respond with one or multiple negative response message including the negative response code
"requestCorrectlyReceived-ResponsePending". This response code indicates that the request message was
received correctly, and that any parameters in the request message were valid, but the action to be
performed may not be completed yet. This response code can be used to indicate that the request message
was properly received and does not need to be retransmitted, but the server is not yet ready to receive
another request. The negative response message may be sent once or multiple times within a service if
required by the server! During the period of (a) negative response message(s) the testerPresent service shall
be disabled in the client!

Page: 36 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

This response code shall only be used in a negative response message if the server will not be able to
receive further request messages from the client within the P3 timing window. This may be the case if the
server does data processing or executes a routine which does not allow any attention to serial
communication.

Note: The communication timing method is specified in section "4.4.1 Timing exceptions" in the ISO 14230-
2 Keyword Protocol 2000 Part 2: Data Link Layer Recommended Practice!

Applications which may require above message flow are:

• clearDiagnosticInformation
• execution of routines
• transferData request messages including up to 255 data bytes
• Flash EEPROM or EEPROM memory programming
5.4 - Data Scaling
5.4.1 - Data Scaling Purpose
The purpose of data scaling is to enable the client (tester) to convert "raw data" which are retrieved from the server
(ECU) into engineering units or ECU identification data (e.g. ECU Hardware Part Number: 90357412). The scaling data
are contained in Data Scaling Tables. Those always have the same structure and are an extension of the scaling
definition described in the SAE J2190 document. The use of Data Scaling Tables is vehicle manufacturer specific.
5.4.2 - Data Scaling Table Structure
The table below specifies the general structure of a scaling table.

Type Description Cvt Hex Value

scalingTableRecordValue=[
Offset scalingOffset#1 M xx
Identifier parameter identification#1 M xx
: : : :
Identifier parameter identification#k C xx
DataValue scalingByte#1.1 M xx
: : : :
DataValue scalingByte#1.m C xx
: : : :
Offset scalingOffset#n M xx
Identifier parameter identification#n.1 M xx
: : : :
Identifier parameter identification#n.k C xx
DataValue scalingByte#n.1 M xx
: : : :
DataValue scalingByte#n.m C xx
OffsetEOT scalingOffset#n {End of Table}] M FF
Table 5.4.2.1 - General scaling table structure

C = condition: parameter only exists if it requires more than 1 byte.

Above scaling table specifies the general structure of scaling tables referenced by this document. Each parameter scaling
structure starts with a scalingOffset, one or multiple parameter identification bytes (#1 to #k) and ends with one or
multiple scaling bytes (#1.1 to #1.m). In case the ECU consists of e.g. two (2) micro controllers and therefore each has
its own softwarte identification is possible to use the identificationOption “systemSupplierECUSoftwareNumber” and
e.g. “systemSupplierECUSoftwareVersionNumber” twice (one for each micro controller). This configuration is
described in section 6.6.5.2. The following is a specification of each parameter type used in the scaling table.
5.4.2.1 - ScalingOffset
The scalingOffset (SO_) is of type offset and is used to build a linked list of scaling structures referenced by a single
identificationOption. The ScalingOffset = 'FF' indicates an EOT (End of Table).

Page: 37 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

5.4.2.2 - Parameter Identifier

The parameter identifier is used to identify a specific parameter by its unique number which may consist of a single byte
or multiple bytes. The following are parameter identifiers which are specified in this document:

• identificationOption (refer to section 6.6.1)

• recordLocalIdentifier (refer to section 7.1.1)
• recordCommonIdentifier (refer to section 7.2.1)
• dynamicallyDefinedByLocalIdentifier (refer to section 7.4.1)
• recordAccessMethodIdentifier (refer to section 8.4.1)
• inputOutputLocalIdentifier (refer to section 9.1.1)
• inputOutputCommonIdentifier (refer to section 9.2.1)
• startRoutineByLocalIdentifier (refer to section 10.1.1)
• stopRoutineByLocalIdentifier (refer to section 10.3.1)
• requestRoutineResultsByLocalIdentifier (refer to section 10.5.1)
5.4.2.3 - ScalingByte
The scalingByte (SB_) consists of one byte (high and low nibble). The high nibble defines the type of information
which is used to represent the parameter. The low order nibble defines the number of bytes used to represent the
parameter in a datastream.
5.4.2.3.1 - ScalingByte High Nibble
Encoding of Description of Data Type Cvt Mnemonic
High Nibble
0000 unSignedNumeric (1 to 4 bytes): U USN
($0x) This encoding uses a common binary weighting scheme to represent a value by mean of discrete
incremental steps. One byte affords 256 steps; two bytes yields 65536 steps, etc.
0001 signedNumeric (1 to 4 bytes): U SN
($1x) This encoding uses a two's complement binary weighting scheme to represent a value by mean of
discrete incremental steps. One byte affords 256 steps; two bytes yields 65536 steps, etc.
0010 bitMappedReportedWithOutMask U BMR
($2x) Bit mapped encoding uses individual bits or small groups of bits to represent status. For every bit WOM
which represents status, a corresponding mask bit is required as part of the parameter definition.
The mask indicates the validity of the bit for particular applications. This type of bit mapped
parameter does not contain a second byte; which contains the validity mask.
Note: "Reported without mask" specifies, that during current data transmission no mask byte is
included in the current data stream.
0011 bitMappedReportedWithMask U BMR
($3x) Bit mapped encoding uses individual bits or small groups of bits to represent status. For every bit WM
which represents status, a corresponding mask bit is required as part of the parameter definition.
The mask indicates the validity of the bit for particular applications. This type of bit mapped
parameter contains two bytes; one representing status and one containing the validity mask.
Note: "Reported with mask" specifies, that during current data transmission the mask byte is
included in the current data stream.
0100 binaryCodedDecimal U BCD
($4x) Conventional Binary Coded Decimal encoding is used to represent two numeric digits per byte.
The upper nibble is used to represent the most significant digit (0 - 9), and the lower nibble the
least significant digit (0 -9).
Note: Diagnostic Trouble Codes are of type BCD and described in the SAE J2012 document.
0101 stateEncodedVariable (1 byte) U SEV
($5x) This encoding uses a binary weighting scheme to represent up to 256 distinct states. An example
is a parameter which represents the status of the Ignition Switch. Codes "00", "01", and "03" may
indicate ignition off, locked, run, and start, respectively. The representation is always limited to
one (1) byte.
Table 5.4.2.3.1 - Encoding of High Nibble of ScalingByte

Page: 38 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Encoding of Description of Data Type Cvt Mnemonic

High Nibble
0110 ASCII (1 to 15 bytes for each scalingByte) U ASCII
($6x) Conventional ASCII encoding is used to represent up to 128 standard characters MSB = logic 0.
An additional 128 custom characters may be represented with the MSB = logic 1.
0111 signedFloatingPoint (ANSI / IEEE Std 754 - 1985) U SFP
($7x) Floating point encoding is used for data that needs to be represented in floating point or scientific
notation. Standard IEEE formats shall be used.
1000 packet U P
($8x) Packets contain multiple data values, usually related, each with unique scaling. Scaling
information is not included for the individual values.
1001 formula (1 byte) U F
($9x) The formulas referenced by the identifiers $00 - $7F are reserved by this document. The formulas
referenced by the identifiers $80 - $FF are vehicle manufacturer specific.
1010 - 1111 reservedByDocument M RBD
($Ax - $Fx) Reserved by this document for future definition.
Table 5.4.2.3.1 - Encoding of High Nibble of ScalingByte (cont'd)
5.4.2.3.2 - ScalingByte Low Nibble
Encoding of Description of Low Nibble Cvt Mnemonic
Low Nibble
0000 - 1111 numberOfBytesOfParameter in current data stream referenced by a parameter identifier U NROBOP
($x0 - $xF) This range of values specifies the number of data bytes in a data stream referenced by a parameter
identifier. The length of a parameter is defined by the scaling byte(s) which is always preceeded
by a parameter identifier (one or multiple bytes). If multiple scaling bytes follow a parameter
identifier the length of the data referenced by the parameter identifier is the summation of the
content of the low nibbles in the scaling bytes.
e.g. VIN is identified by a single byte parameter identifier and followed by two scaling bytes. The
length is calculated up to 17 data bytes. The content of the two low nibbles may have any
combination of values which add up to 17 data bytes.
Table 5.4.2.3.2 - Encoding of Low Nibble of ScalingByte

6 - Diagnostic Management functional unit

The services provided by this functional unit are described in table 6:

Service name Description

startDiagnosticSession The client requests to start a diagnostic session with a server(s).
stopDiagnosticSession The client requests to stop the current diagnostic session.
SecurityAccess The client requests to unlock a secured server.
TesterPresent The client indicates to the server(s) that it is still present.
EcuReset The client forces the server(s) to perform a reset.
ReadEcuIdentification The client requests identification data from the server(s).
Table 6 - Diagnostic Management functional unit

Page: 39 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.1 - StartDiagnosticSession service

6.1.1 - Parameter definition
• The parameter diagnosticMode (DCM_) (also called diagnostic session) is used by the startDiagnosticSession
service to select the specific behaviour of the server(s). The following diagnostic modes are specified in this
document:
Part 3 Implementation Recommended Practice addition:
Hex Description Cvt Mnemonic
00 - 7F reservedByDocument M RBD
This range of values is reserved by this document for future definition.
80 reservedByDocument M RBD
This value is reserved by this document for future definition.
81 defaultMode-StandardDiagnosticMode-OBDIIMode U DT-SD-
This diagnosticMode enables all Keyword Protocol 2000 services specified in Table 4.3 column 3 OBDIIM
"defaultMode, standardDiagnosticMode, OBDIIMode". This diagnosticMode is active after the
initialisation has been successfully completed between client (tester) and server (ECU). No
startDiagnosticSession with the diagnosticMode set to "defaultMode" is required after initialisation.
This diagnosticMode may be overwritten by other sessions specified in this section. The services
enabled in this diagnostic mode (if supported by the server (ECU) provide most of all functions
required in a repair shop environment. This diagnosticMode enables all SAE J1979 CARB OBDII
related services (in SAE documents services are called "test modes") if the server (ECU) is OBD II
compliant. The data content of SAE J1979 specified messages shall not be changed or modified or
used differently than specified in the SAE J1979 Recommended Practice. All SAE J1979 messages
shall use the Keyword Protocol 2000 header when the OBDIIMode is supported by the server
(ECU) and the client (tester).
Note: The CARB bit in the address information field of the format byte shall not be set to '1' (refer
to KWP 2000 Part 2 Data Link Layer Recommended Practice)!
82 PeriodicTransmissions U PT
This diagnosticMode enables all Keyword Protocol 2000 services which are supported in the
periodicTransmissions diagnostic mode session. The selection of Keyword Protocol 2000 services
is vehicle manufacturer specific. In this session the server (ECU) shall send the response message
periodically with current data (updated data) based on the client (tester) request message. The
communication of the periodicTransmissions is specified in Keyword Protocol 2000 Part 2: Data
Link Layer Recommended Practice.
83 endOfLineVehicleManufacturerMode U EOLVMM
This diagnosticMode enables all Keyword Protocol 2000 services and other vehicle manufacturer
specific services as required by the vehicle manufacturer to be used at the end of the vehicle
assembly line. The selection of Keyword Protocol 2000 services is vehicle manufacturer specific
and is specified in Table 4.3 column 3, 4, and 5 "all services are supported".
84 endOfLineSystemSupplierMode U EOLSSM
This diagnosticMode enables all Keyword Protocol 2000 services and other system supplier
specific services as required by the system supplier to be used during production of the ECU. An
example of using this diagnosticMode is a stand alone ECU on board test in the system supplier's
factory. The selection of Keyword Protocol 2000 services is vehicle manufacturer specific and is
specified in Table 4.3 column 3, 4, and 5 "all services are supported".
85 ECUProgrammingMode U ECUPM
This diagnosticMode enables all Keyword Protocol 2000 services specified in Table 4.3 column 4
"ECU Programming Mode". These services support the memory programming of a server (ECU).
86 ECUDevelopmentMode U ECUDM
This diagnosticMode enables all Keyword Protocol 2000 services specified in Table 4.3 column 5
"ECU Development Mode". These services support the development and application/calibration
of a server (ECU).
87 ECUAdjustmentMode U ECUAM
This diagnosticMode enables all Keyword Protocol 2000 services specified in Table 4.3 column 3
"Standard Diagnostic Mode". These services support the adjustment of functions like "Idle
Speed, CO Value, etc." in the server's (ECU's) memory.
Table 6.1.1 - Definition of diagnosticMode Values (cont'd)

Page: 40 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Hex Description Cvt Mnemonic

88 ECUVariantCodingMode U ECUVCM
This diagnosticMode enables all Keyword Protocol 2000 services specified in Table 4.3
column 3 "Standard Diagnostic Mode". These services support the variant coding of the
server (ECU) application. An example of using this diagnosticMode is to program the "country
code" or another "variant of equipment" in the server's (ECU's) memory.
89 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document for future definition.
Table 6.1.1.1 - Definition of diagnosticMode Values (cont'd)
• The user optional parameter baudrateIdentifier (BI_) shall be used to change the baudrate in the server (ECU) and
the client (tester) after the completion of the positive response message. The following table includes
baudrateIdentifiers which reference a specific baudrate.
Hex Description Cvt Mnemonic
00 reservedByDocument M RBD
This value is reserved by this document for future definition.
01 PC9600Baud U PC9600
This value specifies the standard PC baudrate of 9.6 KBaud.
02 PC19200Baud U PC19200
This value specifies the standard PC baudrate of 19.2 KBaud.
03 PC38400Baud U PC38400
This value specifies the standard PC baudrate of 38.4 KBaud.
04 PC57600Baud U PC57600
This value specifies the standard PC baudrate of 57.6 KBaud.
05 PC115200Baud U PC115200
This value specifies the standard PC baudrate of 115.2 KBaud.
06 specificBaudrate U SB
The baudrate will be transmitted within the conditional data field of the service and will be
interpreted as a 3 byte unsigned numeric raw value containing the baudrate which shall become
active after a positive response message from the server (ECU).
07 - 7F reservedByDocument M RBD
This range of values is reserved by this document for future definition.
80 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document for future definition.
Table 6.1.1.2 - Definition of baudrateIdentifier Values
6.1.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 startDiagnosticSession Request Service Id M 10 STDS
#2 diagnosticMode=[ refer to table 6.1.1 ] M xx DCM_...
#3 baudrateIdentifier=[ refer to table 6.1.1.2 ] U xx BI_
specificBaudrate = [ C
#4 baudrate (High Byte) xx BR_
: baudrate (Middle Byte) xx :
#6 baudrate (Low Byte)] xx :
Table 6.1.2.1 - StartDiagnosticSession Request Message

C = condition: Baudrate value is only present if optional baudrateIdentifier = specificBaudrate is used!

Page: 41 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 startDiagnosticSession Positive Response Service Id S 50 STDSPR
#2 diagnosticMode=[ refer to table 6.1.1.1 ] M xx DCM_...
#3 baudrateIdentifier=[ refer to table 6.1.1.2 ] U xx BI_
Table 6.1.2.2 - StartDiagnosticSession Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 startDiagnosticSession Request Service Id S 10 STDS
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.1.2.3 - StartDiagnosticSession Negative Response Message
6.1.3 - Message description
The messages specified above are used to enable different diagnostic modes in the server.
A diagnostic mode (session) shall only be started if communication has been established between the client
and the server. For more detail how to start communication refer to the document ISO 14230-2 (KWP 2000
Part 2: Data Link Layer Recommended Practice).

• If no diagnostic session has been requested by the client after startCommunication a default session shall
be automatically enabled in the server. The default session shall support at least the following services:
"stopCommunication service" ISO 14230-2 (KWP 2000 Part 2: Data Link Layer Recommended Practice)
"testerPresent service" ISO 14230-3 (KWP 2000 Part 3: Implementation Recommended Practice)
Refer to table 4.3 Service Identifier value summary table
• If a diagnostic session has been requested by the client which is already running, the server shall send a
positive response message.
• Whenever a new diagnostic session is requested by the client, the server shall first send a
startDiagnosticSession positive response message before the new session becomes active in the server.
If the server sends a negative response message with the startDiagnosticSession request service
identifier the current session shall continue.
• There shall be only one session active at a time. A diagnostic session enables a specific set of KWP 2000
services which shall be defined by the vehicle manufacturer. A session can enable vehicle manufacturer
specific services which are not part of this document.

Part 3 Implementation Recommended Practice addition:

• The default timing parameters and the default baudrate (10.4 KBaud) in the server (ECU) shall be active while the
default session is running.
• The server (ECU) and the client (tester) shall reset their timing parameters to the values initialised within the
initialisation sequence. The timing parameter values shall be according to the keybytes sent by the server (ECU). The
new timing becomes active after the successful completion of the positive response message of this service.
• Some diagnostic sessions in a server (ECU) require a successful security access sequence in order to support/perform
secured functions. In such case the following sequence of services shall be required:
Q startDiagnosticSession(diagnosticMode) service
R securityAccess(...) service
• The default timing parameters and the default baudrate (10.4 KBaud) in the server (ECU) shall be active after a
successful startDiagnosticSession with the defaultMode-StandardDiagnosticMode-OBDIIMode diagnosticMode
parameter value and the baudrateIdentifier parameter NOT included in the request message if another session and
baudrate was previously active.
6.1.4 - Message flow example
See message flow examples of a Physically Addressed Service in section 5.3.1.1 and a Functionally
Addressed Service in section 5.3.2.1.

Page: 42 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

6.1.5 - Implementation example of startDiagnosticSession

6.1.5.1 - Test specification to enable "ECUProgrammingMode"

This section specifies the conditions to enable the ECUProgrammingMode ($85) in the server (ECU).
6.1.5.2 - Message flow

6.1.5.2.1 - Message flow startDiagnosticSession with ECUProgrammingMode

STEP#1 startDiagnosticSession(DM_ECUPM)
time Client (tester) Request Message Hex
P3 startDiagnosticSession.ReqSId[ 10
diagnosticMode = ECUProgrammingMode] 85

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 startDiagnosticSession.PosRspSId[ 50 negativeResponse Service Identifier 7F
diagnosticMode = ECUProgrammingMode] 85 startDiagnosticSession.ReqSId[ 10
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

6.1.5.2.2 - Message flow startDiagnosticSession with ECUProgrammingMode and high speed

baudrate
This message flow shows an example of how to change the baudrate of the server (ECU) to high speed when for
example the diagnostic session "ECUProgrammingMode" is started (any other diagnostic mode can also be used). An
additional (user optional) parameter "baudrateIdentifier" is included in the request message which shall inform the
server (ECU) about the baudrate to communicate with after the positive response message has been sent by the server
(ECU).

Note: This example assumes that a "Point to Point" communication has been established between a server (ECU) and
a client (tester). The parameter baudrateIdentifier used in the startDiagnosticSession request message specifies
the baudrate to become active.

Step#1 describes the startDiagnosticSession service to be used to switch to a high speed baudrate of 115.2KBaud.
STEP#1 startDiagnosticSession(DM_ECUPM, BI_PC115200)
time Client (tester) Request Message Hex
P3 startDiagnosticSession.ReqSId[ 10
diagnosticMode = ECUProgrammingMode 85
baudrateIdentifier] 05

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 startDiagnosticSession.PosRspSId[ 50 negativeResponse Service Identifier 7F
diagnosticMode = ECUProgrammingMode 85 startDiagnosticSession.ReqSId[ 10
baudrateIdentifier] 05 responseCode { refer to section 4.4 }] xx
{ server and client switch to new baudrate }
goto STEP#2 return(responseCode)

After completion of the positive response message the new baudrate of 115.2 KBaud becomes active. If a negative
response with the startDiagnosticSession responseServiceId has been received by the client (tester) both, the server
(ECU) and the client (tester) shall proceed with the standardised KWP 2000 baudrate of 10.4 Kbaud.

Page: 43 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Step#2 describes the startDiagnosticSession service to be used to switch to the standard baudrate of 10.4 KBaud. In this
case no baudrateIdentifier parameter shall be used in the request message.
Note: Instead of starting a new diagnostic session in order to switch to the standard baudrate of 10.4 kBaud, a
stopDiagnosticSession service can be used!
STEP#2 startDiagnosticSession(DM_DT_SD_OBDIIM)
time Client (tester) Request Message Hex
P3 startDiagnosticSession.ReqSId[ 10
diagnosticMode = defaultMode-StandardDiagnosticMode-OBDIIMode] 81

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 startDiagnosticSession.PosRspSId[ 50 negativeResponse Service Identifier 7F
diagnosticMode = defaultMode- 81 startDiagnosticSession.ReqSId[ 10
StandardDiagnosticMode-OBDIIMode] responseCode { refer to section 4.4 }] xx
{ server and client switch to 10.4 kBaud }
return(main) return(responseCode)

6.1.5.2.3 - Message flow startDiagnosticSession with ECUProgrammingMode and a specific baudrate

This message flow shows an example of how to change the baudrate of the server (ECU) to a specific one when for
example the diagnostic session "ECUProgrammingMode" is started (any other diagnostic mode can also be used).

Note: This example assumes that a "Point to Point" communication has been established between a server (ECU) and
a client (tester).

Step#1 describes the startDiagnosticSession service to be used to switch to a user defined baudrate of 150 KBaud.
STEP#1 startDiagnosticSession(DM_ECUPM, BI_SB)
time Client (tester) Request Message Hex
P3 startDiagnosticSession.ReqSId[ 10
diagnosticMode = ECUProgrammingMode 85
baudrateIdentifier=specificBaudrate 06
baudrate (High Byte) { 150 Kbaud } 02
baudrate (Middle Byte) { “ } 49
baudrate (Low Byte) { “ }] F0

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 startDiagnosticSession.PosRspSId[ 50 negativeResponse Service Identifier 7F
diagnosticMode = ECUProgrammingMode 85 startDiagnosticSession.ReqSId[ 10
baudrateIdentifier] 06 responseCode { refer to section 4.4 }] xx
{ server and client switch to new baudrate }
goto STEP#2 of section 6.1.5.2.2 return(responseCode)

After successful completion of the positive response message the new baudrate of 150 KBaud becomes active. If a
negative response with the startDiagnosticSession responseServiceId has been received by the client (tester) both, the
server (ECU) and the client (tester) shall proceed with the standardised KWP 2000 baudrate of 10.4 Kbaud.
6.1.5.2.4 - Message flow startDiagnosticSession with periodicTransmissions
This message flow is specified in KWP 2000 Part 2: Data Link Layer Recommended Practice because of its impact
in the communication within KWP 2000.

Page: 44 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

6.2 - StopDiagnosticSession service

6.2.1 - Parameter Definition
This service shall not use any parameter definition.
6.2.2 - Message Data Bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 stopDiagnosticSession Request Service Id M 20 SPDS
Table 6.2.2.1 - StopDiagnosticSession Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 stopDiagnosticSession Positive Response Service Id S 60 SPDSPR
Table 6.2.2.2 - StopDiagnosticSession Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 stopDiagnosticSession Request Service Id S 20 SPDS
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.2.2.3 - StopDiagnosticSession Negative Response Message
6.2.3 - Message description
The messages specified above are used to disable the current diagnostic mode in the server.
The following implementation rules shall be followed:
• A diagnostic session shall only be stopped if communication has been established between the client and
the server and a diagnostic session is running.
• If no diagnostic session is running the default session is active (see startDiagnosticSession). The default
session cannot be disabled by a stopDiagnosticSession service.
• If the server has sent a stopDiagnosticSession positive response message it shall have stopped the
current diagnostic session, that is, perform the necessary action to return to a state in which it is able to
restore its normal operating conditions. Restoring the normal operating conditions of the server may
include the reset of all the actuators controlled if they have been activated by the client during the
diagnostic session being stopped and resuming all normal algorithms of the server.
• If the server has sent a stopDiagnosticSession positive response message it shall have re-locked the
server if it was unlocked by the client during the diagnostic session.
• If a stopDiagnosticSession has been requested by the client and the default session is already running the
server shall send a positive response message and immediately reset all timing parameters.
• The client shall send a stopDiagnosticSession request message before disabling communication via a
stopCommunication service but only if a startDiagnosticSession request message has been sent
previously.
• If the server sends a negative response message with the stopDiagnosticSession request service
identifier the active session shall be continued.
• A stopDiagnosticSession service shall also be used to disable vehicle manufacturer specific diagnostic
sessions.
Part 3 Implementation Recommended Practice addition:
• The server (ECU) and the client (tester) shall reset their timing parameters to the values initialised within the
initialisation sequence. The timing parameter values shall be according to the keybytes sent by the server (ECU). The
new timing becomes active after the successful completion of the positive response message of this service.
6.2.4 - Message flow example
See message flow examples of a Physically Addressed Service in section 5.3.1.1 and a Functionally
Addressed Service in section 5.3.2.1.
6.2.5 - Implementation example of stopDiagnosticSession

6.2.5.1 - Test specification stopDiagnosticSession

This section specifies the conditions to disable the diagnosticMode currently active in the server (ECU). The server
(ECU) shall automatically enable the defaultMode-StandardDiagnosticMode.

Page: 45 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.2.5.2 - Message flow

STEP#1 stopDiagnosticSession()
time Client (tester) Request Message Hex
P3 stopDiagnosticSession.ReqSId 20

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 stopDiagnosticSession.PosRspSId 60 negativeResponse Service Identifier 7F
stopDiagnosticSession.ReqSId[ 20
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

Page: 46 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

6.3 - SecurityAccess service

6.3.1 - Parameter definition
• The parameter accessMode (AM_) is used in the securityAccess service. It indicates to the server the
step in progress for this service, the level of security the client wants to access and the format of seed and
key. Values are defined in the table below for requestSeed and sendKey.

Hex Description Cvt Mnemonic

00 reservedByDocument M RBD
This value is reserved by this document.
01 requestSeed M RSD
RequestSeed with the level of security defined by the vehicle manufacturer.
02 sendKey M SK
SendKey with the level of security defined by the vehicle manufacturer.
03, requestSeed U RSD
05, 07 - 7F RequestSeed with different levels of security defined by the vehicle manufacturer.
04, sendKey U SK
06, 08 - 80 SendKey with different levels of security defined by the vehicle manufacturer.
81 - FA vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FB - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document.
Table 6.3.1.1 - Definition of accessMode values
• The values of the parameter key are not defined in this document.
• The parameter securityAccessStatus (SAS_) may be used to receive the status of the server security
system. The value is defined in the table below.
Part 3 Implementation Recommended Practice addition:
• The values of the parameter seed are not defined in this document except for the values
"$00...00" (all numbers are $00) which indicates to the client (tester) that the server (ECU) is not locked and
"$FF...FF" (all numbers are $FF) which shall not be used because this value may occur if the server’s (ECU’s)
memory has been erased.

Hex Description Mnemonic

34 SecurityAccessAllowed SAA
Table 6.3.1.2 - Definition of securityAccessStatus value
6.3.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 SecurityAccess Request#1 Service Id M 27 SA#1
#2 accessMode=[ M xx=[ AM_...
requestSeed: shall be an odd number greater 01,
than $01 if additional levels of security are 03,
supported, ($01 default), :
7F,
vehicleManufacturerSpecific, 81-F9,
systemSupplierSpecific] FB-FD]
Table 6.3.2.1 - securityAccess Request#1 Message

Page: 47 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 SecurityAccess Positive Response#1 Service Id S 67 SA#1PR
#2 accessMode=[ M xx=[ AM_...
requestSeed: shall be an odd number greater 01,
than $01 if additional levels of security are 03,
supported, ($01 default), :
7F,
vehicleManufacturerSpecific, 81-F9,
systemSupplierSpecific] FB-FD]
#3 seed#1 (High Byte) C xx SEED
: : : :
#n seed#m (Low Byte) C xx
Table 6.3.2.2 - securityAccess Positive Response#1 Message

C = condition: accessMode must be set to "requestSeed".

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse#1 Service Id S 7F NR
#2 SecurityAccess Request Service Id S 27 SA
#3 ResponseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.3.2.3 - SecurityAccess Negative Response#1 Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 SecurityAccess Request#2 Service Id M 27 SA#2
#2 accessMode=[ M xx=[ AM_...
sendKey: shall be an even number one greater 02,
than accessMode in request#1 if additional levels 04,
of security are supported, ($02 default) :
80,
vehicleManufacturerSpecific, 82-FA,
systemSupplierSpecific] FC-FE]
#3 key#1 (High Byte) C xx KEY
: : : :
#n key#m (Low Byte) C xx
Table 6.3.2.4 - SecurityAccess Request#2 Message

C = condition: accessMode must be set to "sendKey".

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 securityAccess Positive Response#2 Service Id S 67 SA#2PR
#2 accessMode=[ M xx=[ AM_...
sendKey: shall be an even number one greater 02,
than AccessMode in request#1 if additional 04,
levels of security are supported, ($02 default) :
80,
vehicleManufacturerSpecific, 82-FA,
systemSupplierSpecific] FC-FE]
#3 securityAccessStatus=[securityAccessAllowed] M 34 SAA
Table 6.3.2.5 - SecurityAccess Positive Response#2 Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse#2 Service Id S 7F NR
#2 securityAccess Request Service Id S 27 SA
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.3.2.6 - SecurityAccess Negative Response#2 Message

Page: 48 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

6.3.3 - Message description

This mode is intended to be used to implement the data link security measures defined in SAE J2186 (E/E
Data Link Security).
• The client shall request the server to "unlock" itself by sending the service securityAccess request#1. The
server shall respond by sending a "seed" using the service securityAccess positive response#1. The client
shall respond by returning a "key" number back to the server using the service securityAccess request#2.
The server shall compare this "key" to one internally stored. If the two numbers match, then the server
shall enable ("unlock") the client's access to specific KWP 2000 services and indicate that with the service
securityAccess positive response#2. If upon two (2) attempts of a service securityAccess request#2 by the
client, where the two keys do not match, then the server shall insert a ten (10) second time delay before
allowing further attempts.
• The ten (10) second time delay shall also be required before the server responds to a service
securityAccess request#1 from the client after server power-on.
• If a device supports security, but is already unlocked when a securityAccess request#1 is received, that
server shall respond with a securityAccess positive response#1 service with a seed of "$00 00". A client
shall use this method to determine if a server is locked by checking for a non-zero seed.
• The security system shall not prevent normal diagnostic or vehicle communications between the client and
the servers. Proper "unlocking" of the server is a prerequisite to the client's ability to perform some of the
more critical functions such as reading specific memory locations within the server, downloading
information to specific locations, or downloading routines for execution by the controller. In other words,
the only access to the server permitted while in a "locked" mode is through the server specific software.
This permits the server specific software to protect itself from unauthorized intrusion.
• Servers which provide security shall support reject messages if a secure mode is requested while the
server is locked.
• Some servers could support multiple levels of security, either for different functions controlled by the
server, or to allow different capabilities to be exercised. These additional levels of security can be
accessed by using the service securityAccess requests#1 and #2 with an accessMode value greater than
the default value. The second data byte of the "requestSeed" shall always be an odd number, and the
second data byte of the service to "sendKey" shall be the next even number.
Part 3 Implementation Recommended Practice addition:
• Some diagnostic sessions in a server (ECU) require a successful security access sequence in order to support/perform
secured functions. In such case the following sequence of services shall be required:
Q startDiagnosticSession(diagnosticMode) service {section 6.1.1}
R securityAccess(...) service
The accessMode parameters of the securityAccess service depend on the diagnosticMode enabled (session started) in
the server (ECU).
6.3.4 - Message flow example
time client (Tester) server (ECU)
P3 securityAccess.Request#1[...]
P2 securityAccess.PositiveResponse#1[...]
P3 securityAccess.Request#2[...]
P2 securityAccess.PositiveResponse#2[...]
Table 6.3.4.1 - Message flow example of securityAccess services

Note: In case of a securityAccess negative response#1 it is the vehicle manufacturer's responsibility to

decide how to proceed.
6.3.5 - Implementation example of securityAccess

6.3.5.1 - Test specification securityAccess

This section specifies the conditions to be fulfilled to successfully unlock the server (ECU) if in a "locked“ state:
requestSeed = $01; sendKey = $02; seed = $3675; key = $C98B {e.g. 2's complement of seed value }
If the server sends negative response messages the client (tester) and the server (ECU) shall follow the rules specified in
section 6.3.3 Message description.

Page: 49 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.3.5.2 - Message flow

6.3.5.2.1 - Message flow if server (ECU) is in a "locked" state (seed ≠ $0000)

STEP#1 securityAccess(AM_RSD)
time Client (tester) Request Message Hex
P3 securityAccess.ReqSId[ 27
accessMode = requestSeed] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 securityAccess.PosRspSId[ 67 negativeResponse Service Identifier 7F
accessMode = requestSeed 01 securityAccess.ReqSId[ 27
seed (High Byte) 36 responseCode { refer to section 4.4 }] xx
seed (Low Byte)] 75
goto STEP#2 return(responseCode)

STEP#2 securityAccess(AM_SK, KEY)

time Client (tester) Request Message Hex
P3 securityAccess.ReqSId[ 27
accessMode = sendKey 02
key (High Byte) { 2's complement of seed } C9
key (Low Byte) { 2's complement of seed }] 8B

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 securityAccess.PosRspSId[ 67 negativeResponse Service Identifier 7F
accessMode = sendKey 02 securityAccess.ReqSId[ 27
securityAccessAllowed] 34 responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

6.3.5.2.2 - Message flow if server (ECU) is in an "unlocked" state (seed = $0000)

STEP#1 securityAccess(AM_RSD)
time Client (tester) Request Message Hex
P3 securityAccess.ReqSId[ 27
accessMode = requestSeed] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 securityAccess.PosRspSId[ 67 negativeResponse Service Identifier 7F
accessMode = requestSeed 01 securityAccess.ReqSId[ 27
seed (High Byte) 00 responseCode { refer to section 4.4 }] xx
seed (Low Byte)] 00
return(main) return(responseCode)

Page: 50 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

6.4 - TesterPresent service

6.4.1 - Parameter definition
• The parameter responseRequired (RRD_) is used in the testerPresent request message. It indicates to
the server whether a response message is required or not. Values for this parameter are defined in the
table below:

Hex Description Cvt Mnemonic

00 reservedByDocument M RBD
This value is reserved by this document.
01 Yes N/A Y
This parameter shall not be implemented in the KWP 2000 Part 3 Implementation
Recommended Practice!
The server shall send a response on the request message.
02 No N/A NO
This parameter shall not be implemented in the KWP 2000 Part 3 Implementation
Recommended Practice!
The server shall not send a response on the request message.
03 - 7F reservedByDocument M RBD
This range of values is reserved by this document for future definition.
80 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA – FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document for future definition.
Table 6.4.1 - Definition of responseRequired values
6.4.2 - Message Data Bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 TesterPresent Request Service Id M 3E TP
Table 6.4.2.1: testerPresent Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 testerPresent Positive Response Service Id S 7E TPPR
Table 6.4.2.2: testerPresent Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 testerPresent Request Service Id M 3E TP
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.4.2.3 - testerPresent Negative Response Message
6.4.3 - Message description
This service shall be used to indicate to a server that the client is present. This service is required in the
absence of other KWP 2000 services to prevent servers from automatically returning to normal operation and
stop communication.

The following rules shall be followed:

• The presence of this service shall keep communication active between client and server.
• The presence of this service shall indicate that the system should remain in a diagnostic mode of
operation.

Page: 51 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.4.4 - Message flow example

Time client (Tester) server (ECU)
P3 testerPresent.Request
P2 testerPresent.PositiveResponse
Table 6.4.4 - Message flow example of testerPresent services
6.4.5 - Implementation example of testerPresent

6.4.5.1 - Test specification testerPresent

This section specifies the conditions to be fulfilled at the client (tester) before it sends a testerPresent request message to
the server (ECU).
Condition client (tester): if (timer(P3timeout) == Hex(P3max) - Hex(01)) then testerPresent.req;
6.4.5.2 - Message flow

STEP#1 testerPresent()
time Client (tester) Request Message Hex
P3 testerPresent.ReqSId 3E

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 testerPresent.PosRspSId 7E negativeResponse Service Identifier 7F
testerPresent.ReqSId[ 3E
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

6.5 - EcuReset service

6.5.1 - Parameter definition
• The parameter resetMode (RM_) is used by the ecuReset request message to describe how the server
has to perform the reset. Values are defined in the table below:
Hex Description Cvt Mnemonic
00 reservedByDocument M RBD
This value is reserved by this document.
01 powerOn M PO
This value identifies the powerOn resetMode which shall be a simulated powerOn
reset which most ECUs perform after ignition OFF/ON cycle. When the ECU
performs the reset the client (tester) shall be prepared to re-establish
communication.
02 powerOnWhileMaintainingCommunication N/A POWMC
This parameter shall not be implemented in the KWP 2000 Part 3 Implementation
Recommended Practice!
This value identifies the powerOn resetMode which shall be a simulated powerOn reset
which most ECUs perform after ignition OFF/ON cycle. When the ECU performs the
reset the server (ECU) shall maintain the communication with the client (tester).
03 – 7F reservedByDocument M RBD
This range of values is reserved by this document for future definition.
80 resetStatus U RS
This value identifies the resetStatus parameter which shall indicate to the server (ECU) that
it shall send the resetStatus parameter in the positive response message. This parameter
shall be project specific.
81 – F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document.
Table 6.5.1.1 - Definition of resetMode values

Page: 52 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

• The parameter resetStatus (RS_) is used by the ecuReset positive response message to provide
information about the status of the reset(s). Format and length of this parameter are vehicle manufacturer
specific.

Hex Description Mnemonic

xx ... xx resetStatus RS
This parameter shall report resetStatus information. It is the vehicle manufacturer's
responsibility to define the type and format of the data value(s).
Table 6.5.1.2 - Definition of resetStatus value
6.5.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 ecuReset Request Service Id M 11 ER
#2 resetMode= [ refer to table 6.5.1.1 ] M xx RM_...
Table 6.5.2.1 - ecuReset Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 ecuReset Positive Response Service Id S 51 ERPR
#2 resetStatus#1 { refer to table 6.5.1.2 } U xx RS
: : : :
#n resetStatus#m { refer to table 6.5.1.2 } U xx
Table 6.5.2.2 - ecuReset Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 ecuReset Request Service Id M 11 ER
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.5.2.3 - ecuReset Negative Response Message
6.5.3 - Message description
This service requests the server to effectively perform an ECU reset based on the content of the resetMode
parameter value. It is the vehicle manufacturer's responsibility to define whether the positve response
message shall be sent before or after the resetMode is executed.

A possible implementation would be to report the number of resets performed by the server(s) after the last
full power down / power up cycle (key off/on).
6.5.4 - Message flow example
See message flow examples of a Physically Addressed Service in section 5.3.1.1 and a Functionally
Addressed Service in section 5.3.2.1.
6.5.5 - Implementation example of ecuReset

6.5.5.1 - Test specification ecuReset

This section specifies the conditions to be fulfilled to successfully perform an ecuReset service in the server (ECU).
Condition of server (ECU): ignition = on, system shall not be in an operational mode (e.g. if the system is an engine
management, engine shall be off);
Note: The server (ECU) shall send an ecuReset positive response message before the server (ECU) performs the
resetMode. The server (ECU) will not send any further response messages based on request messages which
may be sent by the client (tester). The client (tester) shall re-establish communication with the server (ECU) by
sending a new initialisation sequence after a timeout (ECU power on self test) to be specified by the system
supplier. If the resetMode is set to powerON the client (tester) shall behave the same as having received a
stopCommunication positive response message!

Page: 53 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.5.5.2 - Message flow

STEP#1 ecuReset(RM_PO)
time Client (tester) Request Message Hex
P3 ecuReset.ReqSId[ 11
resetMode = powerOn] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 ecuReset.PosRspSId 51 negativeResponse Service Identifier 7F
ecuReset.ReqSId[ 11
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

6.6 - ReadEcuIdentification service

6.6.1 - Parameter definition
Part 3 Implementation Recommended Practice addition:
• The parameter identificationOption (IO_) is used by the readEcuIdentification request message to describe the kind
of identification data requested by the client (tester). Either the parameter ECUIdentificationDataTable ($80) or at
least one of the parameters in the range of $82 -$9F shall be implemented in the server (ECU) for identification
purposes. Values are defined in the table below.
The identificationOption table consists of six (6) columns and multiple lines.
• The 1st column (Hex) includes the "Hex Value" assigned to the identificationOption specified in the 2nd column.
• The 2nd column (Description) specifies the identificationOption.
• The 3rd column (Source of Identification) includes the source of the identification data for this
identificationOption.
• The 4th column (Programmable) specifies if the identificationOption is programmable.
• The 5th column (Cvt) is the convention column which specifies whether the identificationOption is "M"
(mandatory) or "U" (User Optional).
• The 6th column (Mnemonic) specifies the mnemonic of this identificationOption.

M = mandatory, U = user optional, N/A = Not Applicable

Hex Description Source Prog. Cvt Mnemonic
of Id.
80 ECUIdentificationDataTable system N/A U ECUIDT
This value shall cause the server (ECU) to report the ECU identification data supplier
table in the readECUIdentification positive response message. The
information contained in the ECUIdentificationTable shall be identified by
the identificationOption numbers '$82 - $9F'. The data values shall be of the
format specified in section 5.4 Data Scaling.
81 ECUIdentificationScalingTable system YES U ECUIST
This value shall cause the server (ECU) to report the ECU identification supplier
scaling table in the readECUIdentification positive response message. The
data content of the ECUIdentificationScalingTable depends on the
identification data (length and format) being implemented in the ECU
Identification Data Table which shall be reported if the identificationOption
parameter is set to ECUIdentificationDataTable. The scaling data shall be of
the format specified in section 5.4 Data Scaling.
82 - 85 reservedByDocument U RBD
This range of values is reserved by this document for future definition.
86 - 89 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use. The
scaling data shall be of the format specified in section 5.4 Data Scaling.
8A - 8F systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use. The scaling
data shall be of the format specified in section 5.4 Data Scaling.
Table 6.6.1: Definition of identificationOption values

Page: 54 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Hex Description Source Prog. Cvt Mnemonic

of Id.
90 VIN (Vehicle Identification Number) vehicle YES U VIN
This value shall cause the server (ECU) to report the VIN in the manufact
readECUIdentification positive response message. The data content shall be
specified by the vehicle manufacturer. The data values shall be of the format
specified in section 5.4 Data Scaling. If the VIN is not programmed in the
ECU's memory those locations shall be either padded with '$00' or '$FF'.
91 vehicleManufacturerECUHardwareNumber vehicle NO U VMECUHN
This value shall cause the server (ECU) to report the vehicle manufacturer manufact
ECU hardware number (e.g. Part Number of ECU) in the
readECUIdentification positive response message. The data content shall be
ECU specific and be the responsibility of the vehicle manufacturer. The data
values shall be of the format specified in section 5.4 Data Scaling.
92 systemSupplierECUHardwareNumber system NO M SSECUHN
This value shall cause the server (ECU) to report the system supplier ECU supplier
hardware number in the readECUIdentification positive response message.
The data content shall be ECU specific and be the responsibility of the
system supplier. The data values shall be of the format specified in section
5.4 Data Scaling.
93 systemSupplierECUHardwareVersionNumber system NO U SSECUHVN
This value shall cause the server (ECU) to report the system supplier ECU supplier
hardware version number in the readECUIdentification positive response
message. The data content shall be ECU specific and be the responsibility of
the system supplier. The data values shall be of the format specified in
section 5.4 Data Scaling.
94 systemSupplierECUSoftwareNumber system NO M SSECUSN
This value shall cause the server (ECU) to report the system supplier ECU supplier
software number in the readECUIdentification positive response message.
The data content shall be ECU specific and be the responsibility of the
system supplier. The data values shall be of the format specified in section
5.4 Data Scaling.
95 systemSupplierECUSoftwareVersionNumber system NO U SSECUSVN
This value shall cause the server (ECU) to report the system supplier ECU supplier
software version number in the readECUIdentification positive response
message. The data content shall be ECU specific and be the responsibility of
the system supplier. The data values shall be of the format specified in
section 5.4 Data Scaling.
96 exhaustRegulationOrTypeApprovalNumber vehicle NO U EROTAN
This value shall cause the server (ECU) to report the exhaust regulation or manufact
type approval number (valid for those systems which require type approval)
in the readECUIdentification positive response message. The data content
shall be ECU specific and be the responsibility of the vehicle manufacturer.
The data values shall be of the format specified in section 5.4 Data Scaling.
97 systemNameOrEngineType vehicle NO U SNOET
This value shall cause the server (ECU) to report the system name or engine manufact
type in the readECUIdentification positive response message. The data
content shall be ECU specific and be the responsibility of the vehicle
manufacturer. The data values shall be of the format specified in section 5.4
Data Scaling.
98 repairShopCodeOrTesterSerialNumber repair YES U RSCOTSN
This value shall cause the server (ECU) either to report the repair shop code shop
or to report the tester's serial number if the ECU's memory has been
previously re-programmed by the service tester. The data values shall be of
the format specified in section 5.4 Data Scaling.
Table 6.6.1: Definition of identificationOption values (cont'd)

Page: 55 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex Description Source Prog Cvt Mnemonic

of Id.
99 ProgrammingDate prog. YES U PD
This value shall cause the server (ECU) to report the programming date equipm.
when the software/calibration was programmed into the server (ECU).
Format and scaling shall be one of the following: unsigned numeric, ASCII,
BCD. The sequence of the date in the record shall be: Year, Month, Day.
The scaling data shall be of the format specified in section 5.4 Data Scaling.
9A - 9F vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific
use. The scaling data shall be of the format specified in section 5.4 Data
Scaling.
Table 6.6.1: Definition of identificationOption values (cont'd)

• The parameter identificationRecordValue (IRV_) is used by the readEcuIdentification positive response message to
provide the identification data and/or scaling data to the client (tester). The content of the identification record is not
defined in this document and is vehicle manufacturer specific.
6.6.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readEcuIdentification Request Service Id M 1A REI
#2 identificationOption=[ refer to table 6.6.1 ] M 80-9F IO_
Table 6.6.2.1 - readEcuIdentification Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readEcuIdentification Positive Response Service Id S 5A REIPR
identificationRecordValue=[ xx=[ IRV_...
#2 identificationOption=[refer to table 6.6.1] M 80-9F, IO_...
#3 ECUIdentificationParameter#1 C xx, ECUIP_...
: : : : :
#n ECUIdentificationParameter#m] C xx] ECUIP_...
Table 6.6.2.2 - ReadEcuIdentification Positive Response Message

C = condition: parameter depends on identificationOption value!

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 readEcuIdentification Request Service Id M 1A REI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 6.6.2.3 - ReadEcuIdentification Negative Response Mssage
6.6.3 - Message description
Part 3 Implementation Recommended Practice addition:
The readECUIdentification request message requests identification data from the server (ECU). The type of
identifcation data requested by the client (tester) shall be identified by the identifcationOption parameter. The server
(ECU) sends an identification data record included in the readEcuIdentification positive response message. The format
of the identification data shall be according to section 5.4 - Data Scaling. The first parameter of the positive response
message shall always be the repetition of the identificationOption of the request message. This is required because the
identificationOptions "ECUIdentificationDataTable" and "ECUIdentificationScalingTable" may include multiple
identificationOptions based on the definition of the vehicle manufacturer. The identification data included in the positive
response message shall be of the types specified in table - 6.6.1.
6.6.4 - Message flow example
See message flow examples of a Physically Addressed Service in section 5.3.1.1 and a Functionally
Addressed Service in section 5.3.2.1.

Page: 56 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

6.6.5 - Implementation example of readECUIdentification

6.6.5.1 - Test specification of readECUIdentification

This section specifies the conditions to be fulfilled to perform a readECUIdentification service. The client (tester) may
request identification data at any time independent of the status of the server (ECU).

The table below lists an example of ECU identification data.

• The 1st column (ECU Identification Option Description) describes the ECU identification option.
• The 2nd column (ECU Identification Data) includes the ECU identification data as they shall be displayed in the
client (tester).
• The 3rd column (ECU Identification Scaling) includes the ECU identification scaling table data. This column is
broken into five (5) additional columns for more detailed explanation.

ECU Identification Option ECU Identification ECU Identification Scaling Data

Description Data (as displayed) (Hex)
Scaling Scaling id- Scaling Data
Data Offset Opt. Type Length
VIN (Vehicle Identification Number) W0L000043MB54132 04 90 6F 62 04 90 $6x=ASCII $xF+$x2=17
6
vehicleManufacturerHardwareNumber 90254861 GD 03 91 6B 03 91 $6x=ASCII $xB=11
systemSupplierECUHardwareNumber 10433 03 92 02 03 92 $0x=USN $x2=2
systemSupplierECUSoftwareNumber (µP 1) 33456 03 94 02 03 94 $0x=USN $x2=2
systemSupplierECUSoftwareVersionNr (µP 1 03 95 01 03 95 $0x=USN $x1=1
1)
systemSupplierECUSoftwareNumber (µP 2) 53129 03 94 02 03 94 $0x=USN $x2=2
systemSupplierECUSoftwareVersionNr (µP 3 03 95 01 03 95 $0x=USN $x1=1
2)
exhaustRegulationOrTypeApprovalNumber B94001 03 96 66 03 96 $6x=ASCII $x6=6
systemNameOrEngineType X20XEV 03 97 66 03 97 $6x=ASCII $x6=6
repairShopCodeOrTesterSerialNumber 6359984 03 98 03 03 98 $0x=USN $x3=3
programmingDate (YYYY-MM-DD) 1994 09 11 03 99 44 03 99 $4x=BCD $x4=4
Table 6.6.5.1 - Example of ECU identification data

• Message flow STEP#1 shows a readECUIdentification request message which is sent to the server (ECU) with the
identificationOption set to ECUIdentificationScalingTable. The server (ECU) shall send a positive response message
if it supports the identificationOption. The identificationOption is specified in section 6.6.1.
• Message flow STEP#2 shows a readECUIdentification request message which is sent to the server (ECU) with the
identificationOption set to ECUIdentificationDataTable. The server (ECU) shall send a positive response message if
it supports the identificationOption.
• Message flow STEP#3 shows a readECUIdentification request message which is sent to the server (ECU) with the
identificationOption set to VIN. The server (ECU) shall send a positive response message if it supports the
identificationOption.

Page: 57 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

6.6.5.2 - Message flow

STEP#1 readECUIdentification(IO_ECUIST)
time Client (tester) Request Message Hex
P3 readECUIdentification.ReqSId[ 1A
identificationOption = ECUIdentificationScalingTable] 81

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readECUIdentification.PosRspSId[ 5A negativeResponse Service Identifier 7F
identificationOption = ECUIdentificationScalingTable 81 readECUIdentification.ReqSId[ 1A
ScalingOffset { pointer position + $04 } 04 responseCode { refer to section 4.4 }] xx
VIN 90
ScalingByte#1 { ASCII, 15 data bytes } 6F
ScalingByte#1. { ASCII, 2 data bytes } 62
ScalingOffset { pointer position + $03 } 03
vehicleManufacturerHardwareNumber 91
ScalingByte#1 { ASCII, 11 data bytes } 6B
ScalingOffset { pointer position + $03 } 03
systemSupplierECUHardwareNumber 92
ScalingByte#1 { unsigned numeric, 2 data bytes } 02
ScalingOffset { pointer position + $03 } 03
systemSupplierECUSoftwareNumber { µP 1 } 94
ScalingByte#1 { unsigned numeric, 2 data bytes } 02
ScalingOffset { pointer position + $03 } 03
systemSupplierECUS/WVersionNumber { µP 1 } 95
ScalingByte#1 { unsigned numeric, 1 data bytes } 01
ScalingOffset { pointer position + $03 } 03
systemSupplierECUSoftwareNumber { µP 2 } 94
ScalingByte#1 { unsigned numeric, 2 data bytes } 02
ScalingOffset { pointer position + $03 } 03
systemSupplierECUS/WVersionNumber { µP 2 } 95
ScalingByte#1 { unsigned numeric, 1 data bytes } 01
ScalingOffset { pointer position + $03 } 03
exhaustRegulationOrTypeApprovalNumber 96
ScalingByte#1 { ASCII, 6 data bytes } 66
ScalingOffset { pointer position + $03 } 03
SystemNameOrEngineType 97
ScalingByte#1 { ASCII, 6 data bytes } 66
ScalingOffset { pointer position + $03 } 03
repairShopCodeOrTesterSerialNumber 98
ScalingByte#1 { unsigned numeric, 3 data bytes } 03
ScalingOffset { pointer position + $03 } 03
ProgrammingDate (YYYY-MM-DD) 99
ScalingByte#1 { BCD, 4 data bytes } 44
ScalingOffset { End of Table }] FF
goto STEP#2 return(responseCode)

Page: 58 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

STEP#2 readECUIdentification(IO_ECUIDT)
time Client (tester) Request Message Hex
P3 readECUIdentification.ReqSId[ 1A
identificationOption = ECUIdentificationDataTable] 80

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readECUIdentification.PosRspSId[ 5A negativeResponse Service Identifier 7F
identificationOption = ECUIdentificationDataTable 80 readECUIdentification.ReqSId[ 1A
VIN {W} 57 responseCode { refer to section 4.4 }] xx
VIN {0} 30
VIN {L} 4C
VIN {0} 30
VIN {0} 30
VIN {0} 30
VIN {0} 30
VIN {4} 34
VIN {3} 33
VIN {M} 4D
VIN {B} 42
VIN {5} 35
VIN {4} 34
VIN {1} 31
VIN {3} 33
VIN {2} 32
VIN {6} 36
Vehicle Manufacturer Hardware Number {9} 39
Vehicle Manufacturer Hardware Number {0} 30
Vehicle Manufacturer Hardware Number {2} 32
Vehicle Manufacturer Hardware Number {5} 35
Vehicle Manufacturer Hardware Number {4} 34
Vehicle Manufacturer Hardware Number {8} 38
Vehicle Manufacturer Hardware Number {6} 36
Vehicle Manufacturer Hardware Number {1} 31
Vehicle Manufacturer Hardware Number { } 20
Vehicle Manufacturer Hardware Number {G} 47
Vehicle Manufacturer Hardware Number {D} 44
System Supplier ECU Hardware Number { 10433 } 28
System Supplier ECU Hardware Number C1
System Supplier ECU S/W Number µP 1 { 33456 } 82
System Supplier ECU S/W Number µP 1 B0
System Supplier ECU S/W Version No µP 1 {1} 01
System Supplier ECU S/W Number µP 2 { 53129 } CF
System Supplier ECU S/W Number µP 2 89
System Supplier ECU S/W Version No µP 2 {1} 01
Exhaust Regulat. / Type Approval Number {B} 42
Exhaust Regulat. / Type Approval Number {9} 39
Exhaust Regulat. / Type Approval Number {4} 34
Exhaust Regulat. / Type Approval Number {0} 30
Exhaust Regulat. / Type Approval Number {0} 30
Exhaust Regulat. / Type Approval Number {1} 31
Engine Name {X} 58
Engine Name {2} 32
Engine Name {0} 30
Engine Name {X} 58
Engine Name {E} 45
Engine Name {V} 56
Repair Shop Code/Tester Serial No. { 6359984 } 61
Repair Shop Code/Tester Serial No. 06
Repair Shop Code/Tester Serial No. 60
Programming Date { 1994-09-11 } 19
Programming Date 94
Programming Date 09
Programming Date 11
return(main) return(responseCode)

Page: 59 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

STEP#3 readECUIdentification(IO_VIN)
time Client (tester) Request Message Hex
P3 readECUIdentification.ReqSId[ 1A
identificationOption = VIN] 90

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readECUIdentification.PosRspSId[ 5A negativeResponse Service Identifier 7F
identificationOption = VIN 90 readECUIdentification.ReqSId[ 1A
VIN {W} 57 responseCode { refer to section 4.4 }] xx
VIN {0} 30
VIN {L} 4C
VIN {0} 30
VIN {0} 30
VIN {0} 30
VIN {0} 30
VIN {4} 34
VIN {3} 33
VIN {M} 4D
VIN {B} 42
VIN {5} 35
VIN {4} 34
VIN {1} 31
VIN {3} 33
VIN {2} 32
VIN { 6 }] 36
return(main) return(responseCode)

7 - Data Transmission functional unit

The services provided by this functional unit are described in table 7:

Service name Description

ReadDataByLocalIdentifier The client requests the transmission of the current value of a record with access
by record local identifier.
ReadDataByCommonIdentfier The client requests the transmission of the current value of a record with access
by recordCommonIdentifier.
ReadMemoryByAddress The client requests the transmission of a memory area.
DynamicallyDefineLocalIdentifier The client requests to dynamically define local identifiers that may subsequently
be accessed by record local identifier.
WriteDataByLocalIdentifier The client requests to write a record accessed by record local identifier.
WriteDataByCommonIdentifier The client requests to write a record accessed by record common identifier.
WriteMemoryByAddress The client requests to overwrite a memory area.
SetDataRates This service is not part of the KWP 2000 Part 3 Implementation Recommended
Practice and shall therefore not be implemented!
Table 7 - Data Transmission functional unit

Page: 60 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.1 - ReadDataByLocalIdentifier service

7.1.1 - Parameter definition
• The parameter recordLocalIdentifier (RLI_) in the readDataByLocalIdentifier request message identifies
a server specific local data record. This parameter shall be available in the server's memory. The
recordLocalIdentifier value shall either exist in fixed memory or temporarily stored in RAM if defined
dynamically by the service dynamicallyDefineLocalIdentifier.

Part 3 Implementation Recommended Practice addition:

• The recordLocalIdentifier table consists of four (4) columns and multiple lines.
• The 1st column (Hex) includes the "Hex Value" assigned to the recordLocalIdentifier specified in the 2nd column.
• The 2nd column (Description) specifies the recordLocalIdentifier.
• The 3rd column (Cvt) is the convention column which specifies whether the recordLocalIdentifier is "M"
(mandatory) or "U" (User Optional).
• The 4th column (Mnemonic) specifies the mnemonic of this recordLocalIdentifier.

M = mandatory, U = user optional

Hex Description Cvt Mnemonic
00 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
01 - 7F recordLocalIdentifier U RLI_
This range of values shall be reserved to reference datastreams implemented in the server
(ECU) upon the vehicle manufacturer's request.
80 - 9F identificationOption M/U IO_
This range of values shall be reserved for server (ECU) identifiation option information
(refer to section 6.6.1).
A0 - EF recordLocalIdentifier U RLI_
This range of values shall be reserved to reference datastreams implemented in the server
(ECU) upon the vehicle manufacturer's request.
F0 - F9 dynamicallyDefinedLocalIdentifier U DDDLI_
This range of values shall be reserved to identify the datastream(s) of an ECU(s). It is
permitted that an ECU shall have multiple datastreams for different diagnostic sessions or
purposes.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 7.1.1 - Definition of recordLocalIdentifier values

• The parameter recordValue (RV_) is used by the readDataByLocalIdentifier positive response message to provide
the data record identified by the recordLocalIdentifier to the client (tester). The user optional recordValues shall
include ECU specific input, internal and output data.
7.1.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readDataByLocalIdentifier Request Service Id M 21 RDBLI
#2 recordLocalIdentifier=[ refer to table 7.1.1 ] M xx RLI_...
Table 7.1.2.1 - readDataByLocalIdentifier Request Message

Page: 61 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readDataByLocalIdentifier Positive Response Service Id S 61 RDBLIPR
#2 recordLocalIdentifier=[ refer to table 7.1.1 ] M xx RLI_...
#3 recordValue#1 M xx RV_...
: : : : :
#n recordValue#m U xx RV_...
Table 7.1.2.2 - readDataByLocalIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 readDataByLocalIdentifier Request Service Id M 21 RDBLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 7.1.2.3 - readDataByLocalIdentifier Negative Response Message
7.1.3 - Message description
The readDataByLocalIdentifier request message requests data record values from the server identified by a
recordLocalIdentifier. The server sends data record values via the readDataByLocalIdentifier positive
response message. The format and definition of the recordValues shall be vehicle manufacturer specific.
RecordValues shall include analog input and output signals, digital input and output signals, internal data and
system status information if supported by the ECU.
7.1.4 - Message flow example
See message flow examples of a Physically Addressed Service in section 5.3.1.1 and a Functionally
Addressed Service in section 5.3.2.1.
7.1.5 - Implementation example of readDataByLocalIdentifier

7.1.5.1 - Test specification readDataByLocalIdentifier

The service readDataByLocalIdentifier is supported without any restriction by the server (ECU).
The recordLocalIdentifier example includes a datastream with multiple input signals, internal ECU parameters and
output signals. Each parameter is abbreviated with "RV_" in the beginning and followed by the abbreviation specified in
SAE J1930 like "B+" (Battery Positive Voltage) or "TPS" (Throttle Position Sensor).
7.1.5.2 - Message flow

7.1.5.2.1 - Message flow with record#10

STEP#1 readDataByLocalIdentifier(RLl_RECORD#10)
time Client (tester) Request Message Hex
P3 readDataByLocalIdentifier.ReqSId[ 21
recordLocalIdentifier=record#10] 0A

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDataByLocalIdentifier.PosRspSId[ 61 negativeResponse Service Identifier 7F
recordLocalIdentifier=record#10 0A readDataByLocalIdentifier.ReqSId[ 21
RV_B+ { Battery Positive Voltage } 8C responseCode { refer to section 4.4 }] xx
RV_ECT { Engine Coolant Temperature } A6
RV_TPS { Throttle Position Sensor } 66
RV_O2SB1 { Oxygen Sensor Bank 1 } A0
RV_... xx
: :
RV_...] xx
return(main) return(responseCode)

Page: 62 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.2 - ReadDataByCommonIdentifier service

7.2.1 - Parameter definition
• The parameter recordCommonIdentifier (RCI_) in the readDataByCommonIdentifier service identifies a
data record which is supported by multiple servers.
• The parameter recordValue (RV_) is defined in section 7.1.1.
Part 3 Implementation Recommended Practice addition:
• The recordCommonIdentifier table consists of four (4) columns and multiple lines.
• The 1st column (Hex) includes the "Hex Value" assigned to the recordCommonIdentifier specified in the 2nd
column.
• The 2nd column (Description) specifies the recordCommonIdentifier.
• The 3rd column (Cvt) is the convention column which specifies whether the recordCommonIdentifier is "M"
(mandatory) or "U" (User Optional).
• The 4th column (Mnemonic) specifies the mnemonic of this recordCommonIdentifier.
M = mandatory, U = user optional
Hex Description Cvt Mnemonic
0000 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
0001 - EFFF recordCommonIdentifier U RCI_
This range of values shall be reserved to reference parameters implemented in the server
(ECU) upon the vehicle manufacturer's request.
F000 - FFFE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FFFF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 7.2.1 - Definition of recordCommonIdentifier values
7.2.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readDataByCommonIdentifier Request Service Id M 22 RDBCI
#2 recordCommonIdentifier (High Byte) M xx RCI_
#3 recordCommonIdentifier (Low Byte) M xx
Table 7.2.2.1 - readDataByCommonIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readDataByCommonIdentifier Positive Response Service Id S 62 RDBCIPR
#2 recordCommonIdentifier (High Byte) M xx RCI_
#3 recordCommonIdentifier (Low Byte) M xx
#4 recordValue#1 M xx RV_...
: : : : :
#n recordValue#m U xx RV_...
Table 7.2.2.2 - readDataByCommonIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 readDataByCommonIdentifier Request Service Id M 22 RDBCI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 7.2.2.3 - readDataByCommonIdentifier Negative Respons Message

Page: 63 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

7.2.3 - Message description

The readDataByCommonIdentifier request message requests data record values from the server(s) identified
by a common recordCommonIdentifier. The server(s) send data record values via the
readDataByCommonIdentifier positive response message. The format and definition of the recordValues
shall be vehicle manufacturer specific. RecordValues shall include analog input and output signals, digital
input and output signals, internal data and system status information if supported by the ECU(s).
7.2.4 - Message flow example
See message flow example of Physically Addressed Service in section 5.3.1.1 and Functionally Addressed
Service in section 5.3.2.1.
7.2.5 - Implementation example of readDataByCommonIdentifier

7.2.5.1 - Test specification readDataByCommonIdentifier

The service readDataByCommonIdentifier is supported without any restriction by the server (ECU).
This example requests the parameter "Battery Positive Voltage" (B+) by referencing the data by a
recordCommonIdentifier. The identifier may be built from the SAE J1979 specification. Each PID in the SAE J1979
consists of a single byte PID. In this example the SAE J1979 PID is preceeded by a high byte which includes '$00'.
Each parameter is abbreviated with "RV_" in the beginning and followed by the abbreviation specified in SAE J1930
like "B+" (Battery Positive Voltage).
7.2.5.2 - Message flow

STEP#1 readDataByCommonIdentifier(RCI_B+)
time Client (tester) Request Message Hex
P3 readDataByCommonIdentifier.ReqSId[ 22
recordCommonIdentifier { High Byte } = Battery Positive Voltage 00
recordCommonIdentifier { Low Byte } = Battery Positive Voltage] 10

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDataByCommonIdentifier.PosRspSId[ 62 negativeResponse Service Identifier 7F
recordCommonIdentifier { High Byte }{ B+ } 00 readDataByCommonIdentifier.ReqSId[ 22
recordCommonIdentifier { Low Byte } { B+ } 10 responseCode { refer to section 4.4 }] xx
RV_B+ { B+ = 13.8 V (resolution: 100mV)}] 8A
return(main) return(responseCode)

7.3 - ReadMemoryByAddress service

7.3.1 - Parameter definition
Part 3 Implementation Recommended Practice addition:
• The parameter memoryAddress (MA_) in the readMemoryByAddress request message identifies the start address in
the server's memory. If the server supports a "16 bit" wide address range the high byte of the memoryAddress shall
be used as a memoryIdentifier. The memoryIdentifier shall be vehicle manufacturer/system supplier/project specific.
• The parameter memorySize (MS_) specifies the number of bytes to be read starting at a specified memory address in
the server's memory.

Page: 64 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.3.2 - Message data bytes

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readMemoryByAddress Request M 23 RMBA
#2 memoryAddress (High Byte) M xx MA_...
#3 memoryAddress (Middle Byte) M xx
#4 memoryAddress (Low Byte) M xx
#5 MemorySize M xx MS_...
Table 7.3.2.1 - ReadMemoryByAddress Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readMemoryByAddress Positive Response S 63 RMBAPR
#2 recordValue#1 M xx RV_...
: : : : :
#n recordValue#m U xx RV_...
Table 7.3.2.2 - ReadMemoryByAddress Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 readMemoryByAddressRequest Service Id M 23 RMBA
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 7.3.2.3 - ReadMemoryByAddress Negative Response Message
7.3.3 - Message description
The readMemoryByAddress request message requests memory data from the server identified by the parameters
memoryAddress and memorySize.
The server sends data record values via the readMemoryByAddress positive response message. The format and
definition of the recordValues shall be vehicle manufacturer specific. RecordValues shall include analog input and
output signals, digital input and output signals, internal data and system status information if supported by the ECU.
7.3.4 - Message flow example
See message flow example of Physically Addressed Service in section 5.3.1.1.
7.3.5 - Implementation example of readMemoryByAddress

7.3.5.1 - Test specification readMemoryByAddress

The service in this example is not limited by any restriction of the server (ECU). The client (tester) reads three (3) data
bytes from the server's (ECU's) external RAM cells starting at memory address $204813.
7.3.5.2 - Message flow

STEP#1 readMemoryByAddress(MA_..., MS_...)

time Client (tester) Request Message Hex
P3 readMemoryByAddress.ReqSId[ 23
memoryAddress { High Byte } 20
memoryAddress{ Middle Byte } 48
memoryAddress{ Low Byte } 13
memorySize] 03

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readMemoryByAddress.PosRspSId[ 63 negativeResponse Service Identifier 7F
externalRAMCell#1 00 readMemoryByAddress.ReqSId[ 23
externalRAMCell#2 46 responseCode { refer to section 4.4 }] xx
externalRAMCell#3] FB
return(main) return(responseCode)

Page: 65 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

7.4 - DynamicallyDefineLocalIdentifier service

7.4.1 - Parameter definition
Part 3 Implementation Recommended Practice addition:
• The parameter dynamicallyDefinedLocalIdentifier (DDDLI_) (range of values as specified in table 7.1.1: $F0 -
$F9) in the dynamicallyDefineLocalIdentifier request message identifies a new data record which has been defined
by the client (tester) in the request message. The new data record shall be read with the readDataByLocalIdentifier
service using the dynamicallyDefinedLocalIdentifier ($F0 - $F9) as a recordLocalIdentifier parameter value.
• The parameter definitionMode (DNM_) in the dynamicallyDefineLocalIdentifier request message
specifies the method of how the data record is defined. Values are defined in the table below:
Part 3 Implementation Recommended Practice addition:
The definitionMode table consists of three (3) columns.
• The 1st column (Hex) includes the "Hex Value" assigned to the definitionMode.
• The 2nd column (Description) specifies the definitionMode.
• The 3rd column (Mnemonic) specifies the mnemonic of this definitionMode.

Hex Description Cvt Mnemonic

00 reservedByDocument M RBD
This value is reserved by this document for future definition.
01 defineByLocalIdentifier U DBLI
The purpose of local identifiers is to reference a unique parameter of a server (ECU). If the
server (ECU) supports recordLocalIdentifiers this definitionMode shall be used to create a
dynamicallyDefinedLocalIdentifier data record.
02 defineByCommonIdentifier U DBCI
The purpose of common identifiers is to reference a unique parameter with the same value
known by multiple servers (ECUs).
03 defineByMemoryAddress U DBMA
The purpose of a memory address as an identifier is to reference a parameter in the memory of
a server (ECU).This definitionMode may be used if local identifiers are not supported by the
server (ECU).
04 clearDynamicallyDefinedLocalIdentifier U CDDDLI
The purpose of this definition mode is to clear a dynamicallyDefinedLocalIdentifier data
record which has been previously defined in the server (ECU).
05 - 7F reservedByDocument M RBD
This range of values is reserved by this document for future definition.
80 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document for future definition.
Table 7.4.1 - Definition of definitionMode values (cont'd)

• The parameter recordLocalIdentifier (RLI_) is defined in section 7.1.1.

• The parameter recordCommonIdentifier (RCI_) is defined in section 7.2.1.
• The parameter memorySize (MS_) in the dynamicallyDefineLocalIdentifier request message identifies the
number of bytes of data identified in the recordLocal/CommonIdentifier and readMemoryByAddress
service.
• The parameter memoryAddress (MA_) in the dynamicallyDefineLocalIdentifier request message
identifies the start address of a data record in the server's memory.

Page: 66 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Part 3 Implementation Recommended Practice addition:

• If the server (ECU) supports a "16 bit" wide address range the high byte of the memoryAddress shall be included as
the memoryIdentifier.The definition of this value is vehicle manufacturer or system supplier specific.
• The parameter positionInDynamicallyDefinedLocalIdentifier (PIDDDLI_) in the dynamicallyDefineLocal-
Identifier request message identifies the data record position in the dynamically defined data record (first
possible PIDDDLI=1, the byte after the ServicId and RLI). The dynamically defined data record is defined as the
readDataByLocalIdentifier positive response message using the dynamicallyDefinedLocalIdentifier ($F0 - $F9) as a
recordLocalIdentifier parameter value.
• The parameter positionInRecordLocalIdentifier (PIRLI_) in the dynamicallyDefineLocalIdentifier request message
identifies the data record position in the readDataByLocalIdentifier positive response message
(recordLocalIdentifier parameter value NOT $F0 - $F9) (first possible PIRLI=1, the byte after the ServiceId and
RLI).
• The parameter positionInRecordCommonIdentifier (PIRCI_) in the dynamicallyDefineLocalIdentifier request
message identifies the data record position in the readDataByCommonIdentifier positive response message
(first possible PIRLI=1, the byte after the ServicId and RCI).
7.4.2 - Message data bytes

7.4.2.1 - Message data bytes - definitionMode = defineByLocalIdentifier

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 dynamicallyDefineLocalIdentifier Request Service Id M 2C DDLI
#2 dynamicallyDefinedLocalIdentifier M xx DDDLI_...
#3 definitionMode=[defineByLocalIdentifier]#1 M 01 DBLI
#4 positionInDynamicallyDefinedLocalIdentifier#1 M xx PIDDDLI_...
#5 memorySize#1 M xx MS_...
#6 recordLocalIdentifier#1 M xx RLI_...
#7 positionInRecordLocalIdentifier#1 M xx PIRLI_...
#8 definitionMode=[defineByLocalIdentifier]#2 C 01 DBLI
#9 positionInDynamicallyDefinedLocalIdentifier#2 C xx PIDDDLI_...
#10 memorySize#2 C xx MS_...
#11 recordLocalIdentifier#2 C xx RLI_...
#12 positionInRecordLocalIdentifier#2 C xx PIRLI_...
: : : : :
#n-4 definitionMode=[defineByLocalIdentifier]#m C 01 DBLI
#n-3 positionInDynamicallyDefinedLocalIdentifier#m C xx PIDDDLI_...
#n-2 memorySize#m C xx MS_...
#n-1 recordLocalIdentifier#m C xx RLI_...
#n positionInRecordLocalIdentifier#m C xx PIRLI_...
Table 7.4.2.1 - DynamicallyDefineLocalIdentifier Request Message; definitionMode=defineByLocalIdentifier
C = condition: parameter is only present if dynamicallyDefinedLocalId consists of more than one data record.

Description of Table 7.4.2.1 - DynamicallyDefineLocalIdentifier Request Message;

definitionMode= defineByLocalIdentifier
This message is used by the client (tester) to dynamically define a local identifier accessable with the
readDataByLocalIdentifier service with the recordLocalIdentifier (RLI = $F0 - $F9). If the definitionMode parameter is
set to defineByLocalIdentifier the following procedure shall be followed:
The parameter positionInDynamicallyDefinedLocalIdentifier shall specifiy the record starting position in the record
referenced by the parameter dynamicallyDefinedLocalIdentifier. The record specified may be a "1 byte" parameter (e.g.
Engine Coolant Temperature) or a multiple byte record representing many parameters (e.g. analog and discrete inputs).
The parameter memorySize shall specify the number of data bytes which start at the PIDDDLI and is referenced by the
parameter recordLocalIdentifier.
The parameter positionInRecordLocalIdentifier shall specifiy the data record position in the
readDataByLocalIdentifier positive response message which is stored in the server's (ECU's) memory. The request
message may consist of multiple definitions of the same definitionMode.

Page: 67 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

7.4.2.2 - Message data bytes - definitionMode = defineByCommonIdentifier

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 dynamicallyDefineLocalIdentifier Request Service Id M 2C DDLI
#2 dynamicallyDefinedLocalIdentifier M xx DDDLI_...
#3 definitionMode=[defineByCommonIdentifier]#1 M 02 DBCI
#4 positionInDynamicallyDefinedLocalIdentifier#1 M xx PIDDDLI_...
#5 memorySize#1 M xx MS_...
#6 recordCommonIdentifier#1 (High Byte) M xx RCI_...
#7 recordCommonIdentifier#1 (Low Byte) M xx
#8 positionInRecordCommonIdentifier#1 M xx PIRCI_...
#9 definitionMode=[defineByCommonIdentifier]#2 C 02 DBCI
#10 positionInDynamicallyDefinedLocalIdentifier#2 C xx PIDDDLI_...
#11 memorySize#2 C xx MS_...
#12 recordCommonIdentifier#1 (High Byte) C xx RCI_...
#13 recordCommonIdentifier#1 (Low Byte) C xx
#14 positionInRecordCommonIdentifier#1 C xx PIRCI_...
: : : : :
#n-5 definitionMode=[defineByCommonIdentifier]#m C 02 DBCI
#n-4 positionInDynamicallyDefinedLocalIdentifier#m C xx PIDDDLI_...
#n-3 memorySize#m C xx MS_...
#n-2 recordCommonIdentifier#m (High Byte) C xx RCI_...
#n-1 recordCommonIdentifier#m (Low Byte) C xx
#n positionInRecordCommonIdentifier#m C xx PIRCI_...
Table 7.4.2.2 - DynamicallyDefineLocalIdentifier Request Message; definitionMode=defineByCommonIdentifier
C = condition: parameter is only present if dynamicallyDefinedLocalId consists of more than one data record.

Description of Table 7.4.2.2 - DynamicallyDefineLocalIdentifier Request Message;

definitionMode= define-ByCommonIdentifier
This message is used by the client (tester) to dynamically define a local identifier accessable with the
readDataByLocalIdentifier service with the recordLocalIdentifier (RLI=$F0-$F9). If the definitionMode parameter is set
to defineByCommonIdentifier the following procedure shall be followed:
The parameter positionInDynamicallyDefinedLocalIdentifier shall specifiy the record starting position in the record
referenced by the parameter dynamicallyDefinedLocalIdentifier. The record specified may be a "1 byte" parameter (e.g.
Engine Coolant Temperature) or a multiple byte record representing many parameters (e.g. analog and discrete inputs).
The parameter memorySize shall specify the number of data bytes which start at the PIDDDLI and is referenced by the
parameter recordCommonIdentifier.
The parameter positionInRecordCommonIdentifier shall specifiy the data record position in the
readDataByCommonIdentifier positive response message which is stored in the server's (ECU's) memory. The request
message may consist of multiple definitions of the same definitionMode.

Page: 68 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.4.2.3 - Message data bytes - definitionMode = defineByMemoryAddress

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 dynamicallyDefineLocalIdentifier Request Service Id M 2C DDLI
#2 dynamicallyDefinedLocalIdentifier M xx DDDLI_...
#3 definitionMode=[defineByMemoryAddress]#1 M 03 DBMA
#4 positionInDynamicallyDefinedLocalIdentifier#1 M xx PIDDDLI_...
#5 memorySize#1 M xx MS_...
#6 memoryAddress#1 (High Byte) M xx MA_...
#7 memoryAddress#1 (Middle Byte) M xx
#8 memoryAddress#1 (Low Byte) M xx
#9 definitionMode=[defineByMemoryAddress]#2 C 03 DBMA
#10 positionInDynamicallyDefinedLocalIdentifier#2 C xx PIDDDLI_...
#11 memorySize#2 C xx MS_...
#12 memoryAddress#2 (High Byte) C xx MA_...
#13 memoryAddress#2 (Middle Byte) C xx
#14 memoryAddress#2 (Low Byte) C xx
: : : : :
#n-5 definitionMode=[defineByMemoryAddress]#m C 03 DBMA
#n-4 positionInDynamicallyDefinedLocalIdentifier#m C xx PIDDDLI_...
#n-3 memorySize#m C xx MS_...
#n-2 memoryAddress#m (High Byte) C xx MA_...
#n-1 memoryAddress#m (Middle Byte) C xx
#n memoryAddress#m (Low Byte) C xx
Table 7.4.2.3 - DynamicallyDefineLocalIdentifier Request Message; definitionMode=defineByMemoryAddress
C = condition: parameter is only present if dynamicallyDefinedLocalId consists of more than one data record.

Description of Table 7.4.2.3 - DynamicallyDefineLocalIdentifier Request Message;

definitionMode= defineByMemoryAddress
This message is used by the client (tester) to dynamically define a local identifier accessable with the
readDataByLocalIdentifier service with the recordLocalIdentifier (RLI=$F0-$F9). If the definitionMode parameter is set
to defineByMemoryAddress the following procedure shall be followed:
The parameter positionInDynamicallyDefinedLocalIdentifier shall specifiy the data record position in the record
referenced by the parameter dynamicallyDefinedLocalIdentifier. The record specified may be a "1 byte" parameter (e.g.
Engine Coolant Temperature) or a multiple byte record representing many parameters (e.g. analog and discrete inputs).
The parameter memorySize shall specify the number of data bytes which start at the PIDDDLI and is referenced by the
memoryAddress in the server's memory.
The request message may consist of multiple definitions of the same definitionMode.
7.4.2.4 - Message data bytes - clearDynamicallyDefinedLocalIdentifier
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 dynamicallyDefineLocalIdentifier Request Service Id M 2C DDLI
#2 dynamicallyDefinedLocalIdentifier M xx DDDLI_...
#3 definitionMode=[clearDynamicallyDefinedLocalIdentifier] M 04 CDDDLI
Table 7.4.2.4 - DynamicallyDefineLocalIdentifier Request Message;
definitionMode=clearDynamicallyDefinedLocalIdentifier

Page: 69 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Description of Table 7.4.2.4 - DynamicallyDefineLocalIdentifier Request Message;

definitionMode= clearDynamicallyDefinedLocalIdentifier
This service is used by the client to clear a dynamicallyDefinedLocalIdentifier. The definitionMode parameter
is set to clearDynamicallyDefinedLocalIdentifier. This request message shall free up the server's memory
which is used to create a dynamicallyDefinedLocalIdentifier data record.

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 dynamicallyDefineLocalIdentifier Positive Response SId M 6C DDLIPR
#2 dynamicallyDefinedLocalIdentifier M xx DDDLI_...
Table 7.4.2.5 - DynamicallyDefineLocalIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 dynamicallyDefineLocalIdentifierRequest Service Id M 2C DDLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 7.4.2.6 - DynamicallyDefineLocalIdentifier Negative Response Message
7.4.3 - Message description
Part 3 Implementation Recommended Practice addition:
The message description for each definition mode is specified in the sections 7.4.2.1, 7.4.2.2, 7.4.2.3, and 7.4.2.4.
Note: It shall not be possible to modify an already existing dynamically defined data record referenced by a local
identifier.
This specification does not support and allow a mixture of different definitionModes to be combined within a
dynamically defined data record referenced by the same local identifier.
It shall be possible to define multiple dynamicallyDefinedLocalIdentifiers with different definitionModes.
7.4.4 - Message flow examples
The following message flow example shows a dynamicallyDefineLocalIdentifier service including the definitionMode
parameter defineByLocalIdentifier. The dynamically defined data record is then read by a readDataByLocalidentifier
service.

time client (Tester) server (ECU)

P3 dynamicallyDefineLocalId.Request[...]
P2 dynamicallyDefineLocalId.PositiveResponse [...]

P3 readDataByLocalId.Request[...]
P2 readDataByLocalId.PositiveResponse[...]
Table 7.4.4.1 - Message flow example of dynamicallyDefineLocalIdentifier service followed by a
readDataByLocalIdentifier service
7.4.5 - Implementation example of dynamicallyDefineLocalIdentifier

7.4.5.1 - Test specification for dynamicallyDefineLocalIdentifier (defineByLocalIdentifier)

The service in this example is not limited by any restriction of the server (ECU). The client (tester) supports a feature of
allowing the service technician to select display parameters which he needs for a specific test (e.g. engine warm up test).
• Engine Coolant Temperature (RV_ECT)
• Engine Speed (RV_ES)
• Throttle Position Voltage (RV_TP)

Page: 70 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

This table specifies a readDataByLocalIdentifier message referenced by the recordLocalIdentifier (RLI = $01) which is
used to dynamically create a new data record which includes only a few small data records out of the entire message.
Header Service RLI PIRLI PIRLI: PIRLI PIRLI: $0F -$11 PIRLI PIRLI: $15 CS
Id $01 - $06 $07 $08 - $0E RV_ES $12 - $14 RV_TP
RV_ECT
$xx - $xx $61 $01 $xx - $xx $8C $xx - $xx $0060FE $xx - $xx $30 $xx
Table 7.4.5.1.1 - Data record referenced by RLI = $01 of the readDataByLocalIdentifier message
The client (tester) shall either dynamically create the information specified in the table 7.4.5.1.2 (based on technician
parameter selection) or the information may be preprogrammed in the memory of the client (tester). The table
information is required to create the dynamicallyDefineLocalIdentifier request message(s).
Definition of the dynamicallyDefinedLocalIdentifier ($F0) with the definitionMode defineByLocalIdentifier (DNM_DBLI)
Parameter Name definition positionInDynamically memory recordLocal positionInRecord
Mode DefinedLocalIdentifier Size Identifier LocalIdentifier
(RV_) (DNM_) (PIDDDLI) (MS_) (RLI_) (PIRLI)
Engine Coolant Temperature {RV_ECT} $01 $01 1 byte $01 $07
Engine Speed {RV_ES} $01 $02 3 bytes $01 $0F
Throttle Position Voltage {RV_TP} $01 $05 1 byte $01 $15
Table 7.4.5.1.2 - Data to create the dynamicallyDefineLocalIdentifier request message(s)
Within KWP 2000 the dynamicallyDefineLocalIdentifier service is used to assign a dynamically defined localIdentifier
"$F0" to above three (3) parameters which are accessed by a readDataByLocalIdentifier service. The client (tester)
defines the value "$F0" (refer to table 7.1.1) for this localIdentifier which identifies a new record consisting of the above
three (3) parameters selected by the service technician.
7.4.5.2 - Message flow

7.4.5.2.1 - Message flow with single request message

The service technician has selected the record values "Engine Coolant Temperature" (ECT), "Engine Speed" (ES)
and "Throttle Position" (TP) in the client (tester) as the parameters to be dynamically defined with the
dynamicallydefineLocalIdentifier service in the server's (ECU's) memory.
STEP#1 dynamicallyDefineLocalIdentifier(..., RLI_ECT, ..., RLI_ES, ..., RLI_TP)
time Client (tester) Request Message Hex
P3 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
dynamicallyDefinedLocalIdentifier (DDLI) F0
definitionMode=defineByLocalIdentifier (DBLI) 01
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 01
memorySize (MS) 01
recordLocalIdentifier=(RLI of datastream which includes EngineCoolantTemperature) 01
positionInRecordLocalIdentifier (PIRLI) 07
definitionMode=defineByLocalIdentifier (DBLI) 01
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 02
memorySize (MS) 03
recordLocalIdentifier=(RLI of datastream which includes EngineSpeed ) 01
positionInRecordLocalIdentifier (PIRLI) 0F
definitionMode= defineByLocalIdentifier (DBLI) 01
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 05
memorySize (MS) 01
recordLocalIdentifier=(RLI of datastream which includes ThrottlePosition) 01
positionInRecordLocalIdentifier (PIRLI)] 15

Page: 71 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 dynamicallyDefineLocalIdentifier.PosRspSId[ 6C negativeResponse Service Identifier 7F
dynamicallyDefinedLocalIdentifier] F0 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
responseCode { refer to section 4.4 }] xx
goto STEP#2 return(responseCode)

Page: 72 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.4.5.2.2 - Message flow readDataByLocalIdentifier with RLI = $F0

After completion of the dynamicallyDefinedRecordLocalIdentifier (RLI_F0) the new record shall be read by the client
(tester). The client (tester) sends a readDataByLocalIdentifier request message with the recordLocalIdentifier set to '$F0'
to read the values of the three (3) parameters defined previously.
STEP#2 readDataByLocalIdentifier(RLI_F0)
time Client (tester) Request Message Hex
P3 readDataByLocalIdentifier.ReqSId[ 21
recordLocalIdentifier = dynamicallyDefinedRecordLocalIdentfier(RLI_F0)] F0

time Server (ECU) Positive Response Message PIDDDLI Hex Server (ECU) Negative Response Message Hex
P2 readDataByLocalIdentifier.PosRspSId[ 61 negativeResponse Service Identifier 7F
RLI_F0 { recordLocalIdentifier } F0 readDataByLocalIdentifier.ReqSId[ 21
RV_ECT { Engine Coolant Temperature } 01 8C responseCode { refer to section 4.4 }] xx
RV_ES { Engine Speed } 02 00
RV_ES { Engine Speed } 03 60
RV_ES { Engine Speed } 04 FE
RV_TP { Throttle Position }] 05 30
return(main) return(responseCode)

7.4.5.3 - Test specification for dynamicallyDefineLocalIdentifier (defineByCommonIdentifier)

The service in this example is not limited by any restriction of the server (ECU). The client (tester) supports a feature of
allowing the service technician to select display parameters which he needs for a specific test (e.g. O2 Sensor Bank 1
test).
• O2 Sensor Bank 1 (RV_O2SB1)
• O2 Integrator Bank 1 (RV_O2IB1)
• Engine Speed (RV_ES)
This table specifies three (3) readDataByCommonIdentifier messages referenced by three (3) different
recordCommonIdentifiers which are used to dynamically create a new data record.
Header ServiceIdentifier (SID) recordCommonId (RCI_) PIRLI: $01 CS
$xx - $xx $62 $0108 $8C (RV_O2SB1) $xx
$xx - $xx $62 $0105 $22 (RV_O2IB1) $xx
$xx - $xx $62 $0102 $0060FE (RV_ES) $xx
Table 7.4.5.3.1 - Data record referenced by three different RCI of three different readDataByCommonIdentifier messages
The client (tester) shall either dynamically create the information specified in the table 7.4.5.1.2 (based on technician
parameter selection) or the information may be preprogrammed in the memory of the client (tester). The table
information is required to create the dynamicallyDefineLocalIdentifier request message(s).
Definition of the dynamicallyDefinedLocalIdentifier ($F1) with the definitionMode defineByLocalIdentifier (DNM_DBLI)
Parameter Name definition positionInDynamically memorySize recordCom- positionInRecord
Mode DefinedLocalIdentifier monIdenti- Common-
(RV_) (DNM_) (PIDDDLI) (MS_) fier (RCI_) Identifier(PIRLI)
O2 Sensor Bank 1{RV_O2SB1} $02 $01 1 byte $0108 $01
O2 Integrator Bank 1{RV_O2IB1} $02 $02 1 byte $0105 $01
Engine Speed {RV_ES} $02 $03 3 bytes $0102 $01
Table 7.4.5.3.2 - Data to create the dynamicallyDefineLocalIdentifier request message(s)
Within KWP 2000 the dynamicallyDefineLocalIdentifier service is used to assign a dynamically defined localIdentifier
"$F1" to above three (3) parameters which are accessed by a readDataByLocalIdentifier service.
The client (tester) defines the value "$F1" (refer to table 7.1.1) for this localIdentifier which identifies a new record
consisting of the above three (3) parameters selected by the service technician.

Page: 73 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

7.4.5.4 - Message flow

7.4.5.4.1 Message flow with single request message

The service technician has selected the record values "O2 Sensor Bank 1" (O2SB1), "O2 Integrator Bank 1"
(O2IB1) and "Engine Speed" (ES) in the client (tester) as the parameters to be dynamically defined with the
dynamicallydefineLocalIdentifier service in the server's (ECU's) memory.
STEP#1 dynamicallyDefineLocalIdentifier(..., RCI_O2SB1, ..., RCI_O2IB1, ..., RCI_ES)
time Client (tester) Request Message Hex
P3 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
dynamicallyDefinedLocalIdentifier (DDLI) F1
definitionMode=defineByCommonIdentifier (DBCI) 02
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 01
memorySize (MS) 01
recordCommonIdentifier=O2 Sensor Bank 1 (RCI) {High Byte} 01
recordCommonIdentifier=O2 Sensor Bank 1 (RCI) {Low Byte} 08
positionInRecordCommonIdentifier (PIRCI) 01
definitionMode=defineByCommonIdentifier (DBCI) 02
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 02
memorySize (MS) 01
recordCommonIdentifier=O2 Integrator Bank 1 (RCI) {High Byte} 01
recordCommonIdentifier=O2 Integrator Bank 1 (RCI) {Low Byte} 05
positionInRecordCommonIdentifier (PIRCI) 01
definitionMode=defineByCommonIdentifier (DBCI) 02
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 03
memorySize (MS) 03
recordCommonIdentifier=Engine Speed (RCI) {High Byte} 01
recordCommonIdentifier= Engine Speed (RCI) {Low Byte} 02
positionInRecordCommonIdentifier (PIRCI)] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 dynamicallyDefineLocalIdentifier.PosRspSId[ 6C negativeResponse Service Identifier 7F
dynamicallyDefinedLocalIdentifier] F1 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
responseCode { refer to section 4.4 }] xx
goto STEP#2 return(responseCode)

7.4.5.4.2 - Message flow readDataByLocalIdentifier with RLI = $F1

After completion of the dynamicallyDefinedRecordLocalIdentifier (RLI_F1) the new record shall be read by the client
(tester). The client (tester) sends a readDataByLocalIdentifier request message with the recordLocalIdentifier set to '$F1'
to read the values of the three (3) parameters defined previously.
STEP#2 readDataByLocalIdentifier(RLI_F1)
time Client (tester) Request Message Hex
P3 readDataByLocalIdentifier.ReqSId[ 21
recordLocalIdentifier = dynamicallyDefinedRecordLocalIdentfier(RLI_F1)] F1

time Server (ECU) Positive Response Message PIDDDLI Hex Server (ECU) Negative Response Message Hex
P2 readDataByLocalIdentifier.PosRspSId[ 61 negativeResponse Service Identifier 7F
RLI_F1 { recordLocalIdentifier } F1 readDataByLocalIdentifier.ReqSId[ 21
RV_O2SB1 { O2 Sensor Bank 1 } 01 8C responseCode { refer to section 4.4 }] xx
RV_O2IB1 { O2 Integrator Bank 1 } 02 22
RV_ES { Engine Speed } 03 00
RV_ES { Engine Speed } 04 60
RV_ES { Engine Speed }] 05 FE
return(main) return(responseCode)

Page: 74 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.4.5.5 - Test specification for dynamicallyDefineLocalIdentifier (defineByMemoryAddress)

The service in this example is not limited by any restriction of the server (ECU). The client (tester) supports a feature of
allowing the service technician to select display parameters which he needs for a specific test (e.g. RAM Content test).
• RAM Variable#1
• RAM Variable#2
This table specifies two (2) readDataByMemoryAddress messages referenced by two (2) different memoryAddress
paramter values which are used to dynamically create a new data record.
Header ServiceIdentifier (SID) recordValue (RV_) checksum (CS)
$xx - $xx $63 $45 {MA_ = $01DD22} $xx
$xx - $xx $63 $A7 {MA_ = $01AA33} $xx
Table 7.4.5.5.1 - Data record referenced by two different memory addresses of two different readDataByMemoryAddress messages
The client (tester) shall either dynamically create the information specified in the table 7.4.5.1.2 (based on technician
parameter selection) or the information may be preprogrammed in the memory of the client (tester). The table
information is required to create the dynamicallyDefineLocalIdentifier request message(s).
Definition of the dynamicallyDefinedLocalIdentifier ($F2) with the definitionMode defineByLocalIdentifier (DNM_DBLI)
Parameter Name definition positionInDynamically memorySize memoryAddress
Mode DefinedLocalIdentifier
(RV_) (DNM_) (PIDDDLI) (MS_) (MA_)
RAM Variable#1{RV_RAMVAR1} $03 $01 1 byte $01DD22
RAM Variable#2{RV_RAMVAR2} $03 $02 1 byte $01AA33
Table 7.4.5.5.2 - Data to create the dynamicallyDefineLocalIdentifier request message(s)
Within KWP 2000 the dynamicallyDefineLocalIdentifier service is used to assign a dynamically defined localIdentifier
"$F2" to above two (2) parameters which are accessed by a readDataByLocalIdentifier service.
The client (tester) defines the value "$F2" (refer to table 7.1.1) for this localIdentifier which identifies a new record
consisting of the above two (2) parameters selected by the service technician.
7.4.5.6 - Message flow

7.4.5.6.1 - Message flow with single request message

The service technician has selected the memoryAddress values "RAM Variable#1" (RAMV1), " RAM Variable#2"
(RAMV2) in the client (tester) as the parameters to be dynamically defined with the dynamicallydefineLocalIdentifier
service in the server's (ECU's) memory.
STEP#1 dynamicallyDefineLocalIdentifier(..., MA_ RAMV1, ..., MA_ RAMV1)
time Client (tester) Request Message Hex
P3 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
dynamicallyDefinedLocalIdentifier (DDLI) F2
definitionMode=defineByMemoryAddress (DBMA) 03
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 01
memorySize (MS) 01
memoryAddress=RAM Variable#1 (MA) {High Byte} 01
memoryAddress=RAM Variable#1 (MA) {Middle Byte} DD
memoryAddress=RAM Variable#1 (MA) {Low Byte} 22
definitionMode=defineByMemoryAddress (DBMA) 03
positionInDynamicallyDefinedLocalIdentifier (PIDDDLI) 02
memorySize (MS) 01
memoryAddress=RAM Variable#2 (MA) {High Byte} 01
memoryAddress=RAM Variable#2 (MA) {Middle Byte} AA
memoryAddress=RAM Variable#2 (MA) {Low Byte}] 33

Page: 75 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 dynamicallyDefineLocalIdentifier.PosRspSId[ 6C negativeResponse Service Identifier 7F
dynamicallyDefinedLocalIdentifier] F2 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
responseCode { refer to section 4.4 }] xx
goto STEP#2 return(responseCode)

7.4.5.6.2 - Message flow readDataByLocalIdentifier with RLI = $F2

After completion of the dynamicallyDefinedRecordLocalIdentifier (RLI_F2) the new record shall be read by the client
(tester). The client (tester) sends a readDataByLocalIdentifier request message with the recordLocalIdentifier set to '$F2'
to read the values of the two (2) RAM variables defined previously.
STEP#2 readDataByLocalIdentifier(RLI_F2)
time Client (tester) Request Message Hex
P3 readDataByLocalIdentifier.ReqSId[ 21
recordLocalIdentifier = dynamicallyDefinedRecordLocalIdentfier(RLI_F2)] F2

time Server (ECU) Positive Response Message PIDDDLI Hex Server (ECU) Negative Response Message Hex
P2 readDataByLocalIdentifier.PosRspSId[ 61 negativeResponse Service Identifier 7F
RLI_F2 { recordLocalIdentifier } F2 readDataByLocalIdentifier.ReqSId[ 21
RV_RAMVAR1 { RAM Variable#1 } 01 45 responseCode { refer to section 4.4 }] xx
RV_RAMVAR2 { RAM Variable#2 }] 02 A7
goto STEP#3 return(responseCode)

7.4.5.6.3 - Message flow of deleting the dynamically defined recordLocalIdentifier

The client (tester) shall erase the dynamicallyDefinedRecordLocalIdentifier. After successful completion of this service
the client (tester) may create a new record of parameters referenced by a dynamicallyDefinedLocalIdentifier.
This example deletes the dynamically defined recordLocalIdentifier "$F2".
STEP#3 dynamicallyDefineLocalIdentifier(RLl_F2, CDDDLI)
time Client (tester) Request Message Hex
P3 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
dynamicallyDefinedLocalIdentifier (RLI_F2) F2
definitionMode= clearDynamicallyDefinedLocalIdentifier (CDDDLI)] 04

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 dynamicallyDefineLocalIdentifier.PosRspSId[ 6C negativeResponse Service Identifier 7F
dynamicallyDefinedLocalIdentifier] F2 dynamicallyDefineLocalIdentifier.ReqSId[ 2C
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

Page: 76 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.5 - WriteDataByLocalIdentifier service

7.5.1 - Parameter definition
Part 3 Implementation Recommended Practice addition:
• The parameter recordLocalIdentifier (RLI_) is defined in section 7.1.1. In addition, some values of the parameter
identificationOption shall be referenced by a recordLocalIdentifier by this service.

The recordLocalIdentifier table consists of four (4) columns and multiple lines.
• The 1st column (Hex) includes the "Hex Value" assigned to the recordLocalIdentifier specified in the 2nd column.
• The 2nd column (Description) specifies the recordLocalIdentifier.
• The 3rd column (Cvt) is the convention column which specifies whether the recordLocalIdentifier is "M"
(mandatory) or "U" (User Optional).
• The 4th column (Mnemonic) specifies the mnemonic of this recordLocalIdentifier.

M = mandatory, U = user optional

Hex Description Cvt Mnemonic
00 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
01 - 7F recordLocalIdentifier U RLI_
This range of values shall be reserved to reference datastreams implemented in the server
(ECU) upon the vehicle manufacturer's request.
80 - 9F identificationOption M/U IO_
This range of values shall be reserved for server (ECU) identifiation option information (refer
to section 6.6.1).
A0 - EF recordLocalIdentifier U RLI_
This range of values shall be reserved to reference datastreams implemented in the server
(ECU) upon the vehicle manufacturer's request.
F0 - F9 dynamicallyDefinedLocalIdentifier U DDDLI_
This range of values shall be reserved to identify the datastream(s) of an ECU(s). It is
permitted that an ECU shall have multiple datastreams for different diagnostic sessions or
purposes.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 7.5.1 - Definition of recordLocalIdentifier values

• The parameter recordValue is defined in section 7.1.1.

7.5.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 writeDataByLocalIdentifier Request Service Id M 3B WDBLI
#2 recordLocalIdentifier=[ refer to table 7.5.1 ] M xx RLI_...
#3 recordValue#1 M xx RV_...
: : : : :
#n recordValue#m M xx RV_...
Table 7.5.2.1 - WriteDataByLocalIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 writeDataByLocalIdentifier Positive Response Service Id S 7B WDBLIPR
#2 recordLocalIdentifier=[ refer to table 7.5.1 ] M xx RLI_...
Table 7.5.2.2 - WriteDataByLocalIdentifier Positive Response Message

Page: 77 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 writeDataByLocalIdentifier Request Service Id M 3B WDBLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 },] M xx=[00-FF] RC_...
Table 7.5.2.3 - WriteDataByLocalIdentifier Negative Response Message
7.5.3 - Message description
The writeDataByLocalIdentifier service is used by the client to write recordValues (data values) to a server.
The data are identified by a recordLocalIdentifier. It is the vehicle manufacturer's responsibility that the server
conditions are met when performing this service.
Possible uses for this service are:
• Clear non-volatile memory
• Reset learned values
• Set option content
• Set Vehicle Identification Number (VIN)
• Change calibration values
7.5.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1.
7.5.5 - Implementation example of set Vehicle Identification Number (VIN)

7.5.5.1 - Test specification set Vehicle Identification Number (VIN)

The service in this example shall only be used if the system is not operational. The client (tester) shall write the VIN
data to the server (ECU) by using the writeDataByLocalIdentifier service. The server (ECU) shall send a positive
response message after it has successfully programmed the data in EEPROM or FLASH memory.
7.5.5.2 - Message flow

STEP#1 writeDataByLocalIdentifier(RLI_VIN, RV_VIN#1, ... , RV_VIN#17)

time Client (tester) Request Message Hex
P3 writeDataByLocalIdentifier.ReqSId[ 3B
recordLocalIdentifier = identificationOption(VIN) 90
VIN#1 { W } 57
VIN#2 { 0 } 30
VIN#3 { L } 4C
VIN#4 { 0 } 30
VIN#5 { 0 } 30
VIN#6 { 0 } 30
VIN#7 { 0 } 30
VIN#8 { 4 } 34
VIN#9 { 3 } 33
VIN#10 { M } 4D
VIN#11 { B } 42
VIN#12 { 5 } 35
VIN#13 { 4 } 34
VIN#14 { 1 } 31
VIN#15 { 3 } 33
VIN#16 { 2 } 32
VIN#17 { 6 }] 36

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 writeDataByLocalIdentifier.PosRspSId[ 7B negativeResponse Service Identifier 7F
recordLocalIdentifier = VIN] 90 writeDataByLocalIdentifier.ReqSId[ 3B
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

Page: 78 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

7.6 - WriteDataByCommonIdentifier service

The purpose of common identifiers is to reference a unique parameter with the same value across multiple servers
(ECUs) within a vehicle or at the vehicle manufacturer.
7.6.1 - Parameter definition
Part 3 Implementation Recommended Practice addition:
• The recordCommonIdentifier table consists of four (4) columns and multiple lines.
• The 1st column (Hex) includes the "Hex Value" assigned to the recordCommonIdentifier specified in the 2nd
column.
• The 2nd column (Description) specifies the recordCommonIdentifier.
• The 3rd column (Cvt) is the convention column which specifies whether the recordCommonIdentifier is "M"
(mandatory) or "U" (User Optional).
• The 4th column (Mnemonic) specifies the mnemonic of this recordCommonIdentifier.
M = mandatory, U = user optional
Hex Description Cvt Mnemonic
0000 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
0001 - EFFF recordCommonIdentifier U RCI_
This range of values shall be reserved to reference parameters implemented in the server
(ECU) upon the vehicle manufacturer's request.
F000 - FFFE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FFFF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 7.6.1 - Definition of recordCommonIdentifier values

• The parameter recordValue is defined in section 7.1.1.

7.6.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 writeDataByCommonIdentifier Request Service Id M 2E WDBCI
#2 recordCommonIdentifier (High Byte) [ refer to table 7.6.1 ] M xx RCI_
#3 recordCommonIdentifier (Low Byte) M xx
#4 recordValue#1 M xx RV_...
: : : : :
#n recordValue#m M xx RV_...
Table 7.6.2.1 - WriteDataByCommonIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 writeDataByCommonIdentifier Positive Response Service Id S 6E WDBCIPR
#2 recordCommonIdentifier (High Byte) [ refer to table 7.6.1 ] M xx RCI_
#3 recordCommonIdentifier (Low Byte) M xx
Table 7.6.2.2 - WriteDataByCommonIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 writeDataByCommonIdentifier Request Service Id M 2E WDBCI
#3 responseCode=[ KWP2000ResponseCode { section 4.4 } ] M xx=[00-FF] RC_...
Table 7.6.2.3 - WriteDataByCommonIdentifier Negative Response Message

Page: 79 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

7.6.3 - Message description

The writeDataByCommonIdentifier service is used by the client to write recordValues (data values) to a
server. The data are identified by a recordCommonIdentifier. It is the vehicle manufacturer's responsibility
that the server conditions are met when performing this service.
Possible uses for this service are:
• Clear non-volatile memory
• Reset learned values
• Set option content
7.6.4 - Message flow example
See message flow examples of a Physically Addressed Service in section 5.3.1.1 and a Functionally
Addressed Service in section 5.3.2.1.
7.6.5 - Implementation example of Reset Learned Values

7.6.5.1 - Test specification of Reset Learned Values (RLV)

The client (tester) shall command one or multiple server(s) (ECU(s)) to reset the learned values in non volatile memory
by using the writeDataByCommonIdentifier service. The server(s) (ECU(s)) shall send a positive response message after
it (they) has (have) successfully reset the non volatile memory.
7.6.5.2 - Message flow

STEP#1 writeDataByCommonIdentifier(RCI_RLV)
time Client (tester) Request Message Hex
P3 writeDataByCommonIdentifier.ReqSId[ 2E
recordCommonIdentifier = resetLearnedValues (High Byte) 10
recordCommonIdentifier = resetLearnedValues (Low Byte)] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 writeDataByCommonIdentifier.PosRspSId[ 6E negativeResponse Service Identifier 7F
recordCommonIdentifier (High Byte) 10 writeDataByCommonIdentifier.ReqSId[ 2E
recordCommonIdentifier (Low Byte)] 01 responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

7.7 - WriteMemoryByAddress service

7.7.1 - Parameter definition
• The parameter memoryAddress (MA_) is defined in section 7.3.1.
• The parameter memorySize (MS_) is defined in section 7.3.1.
• The parameter recordValue (RV_) is defined in section 7.1.1.
7.7.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 writeMemoryByAddress Request Service Id M 3D WMBA
#2 memoryAddress (High Byte) M xx MA_...
#3 memoryAddress (Middle Byte) M xx
#4 memoryAddress (Low Byte) M xx
#5 MemorySize M xx MS_...
#6 recordValue#1 M xx RV_...
: : : : :
#n recordValue#m U xx RV_...
Table 7.7.2.1 - WriteMemoryByAddress Request Message

Page: 80 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 writeMemoryByAddress Positive Response S 7D WMBAPR
#2 memoryAddress (High Byte) M xx MA_...
#3 memoryAddress (Middle Byte) M xx
#4 memoryAddress (Low Byte) M xx
Table 7.7.2.2 - WriteMemoryByAddress Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 writeMemoryByAddress Request Service Id M 3D WMBA
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 7.7.2.3 - WriteMemoryByAddress Negative Response Message
7.7.3 - Message description
The writeMemoryByAddress service is used by the client to write recordValues (data values) to a server. The
data are identified by the server's memoryAddress and memorySize. It is the vehicle manufacturer's
responsibility that the server conditions are met when performing this service.
Possible uses for this service are:
• Clear non-volatile memory
• Reset learned values
• Set option content
• Set Vehicle Identification Number (VIN)
• Change calibration values
7.7.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1.
7.7.5 - Implementation example of writeMemoryByAddress

7.7.5.1 - Test specification writeMemoryByAddress

The service in this example is not limited by any restriction of the server (ECU). The client (tester) writes seven (7) data
bytes to the server's (ECU's) serial EEPROM at the memory address $30FF13.
7.7.5.2 - Message flow

STEP#1 writeMemoryByAddress(MA_..., MS_..., RV_#1 ... RV_#07)

time Client (tester) Request Message Hex
P3 writeMemoryByAddress.ReqSId[ 3D
memoryAddress { High Byte } 30
memoryAddress { Middle Byte } FF
memoryAddress { Low Byte } 13
memorySize 07
recordValue#1 11
recordValue#2 22
recordValue#3 33
recordValue#4 44
recordValue#5 55
recordValue#6 66
recordValue#7] 77

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readMemoryByAddress.PosRspSId 7D negativeResponse Service Identifier 7F
memoryAddress { High Byte } 30 readMemoryByAddress.ReqSId[ 3D
memoryAddress { Middle Byte } FF responseCode { refer to section 4.4 }] xx
memoryAddress { Low Byte } 13
return(main) return(responseCode)

Page: 81 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

7.8 - SetDataRates service

Part 3 Implementation Recommended Practice addition:
This service is not part of the KWP 2000 Part 3 Implementation Recommended Practice and shall therefore not
be implemented!

The purpose of the service setDataRates is to schedule (a) message(s) for periodic repetition by the server(s) (ECU(s)).
The scheduling of (a) message(s) is in contradiction with the definitions of KWP 2000 Part 2 Data Link Layer
Recommended Practice and therefore not supported.

Note: The main purpose to repeat server messages (client (tester) does not send a new request) is to increase the data
refresh rate of the retrieved data and to enable a "free running mode" in the server (ECU). Adjusting the
server's (ECU's) timing parameters to minimum values will increase the refresh rate of retrieved data:
• P1= inter byte time of ECU response
• P2= inter message time of tester request and ECU response or two ECU responses
• P3= inter message time of ECU responses and start of new tester request
• P4= inter byte time of tester request

8 - Stored Data Transmission functional unit

The services provided by this functional unit are described in table 8:

Service name Description

ReadDiagnosticTroubleCodes This service is not part of the KWP 2000 Part 3 Implementation Recommended
Practice and shall therefore not be implemented!
ReadDiagnosticTroubleCodesBy- The client requests from the server the transmission of both, number of DTC
Status and values of the diagnostic trouble codes depending on their status.
ReadStatusOfDiagnosticTrouble- The client requests from the server the transmission of the number of DTC,
Codes values and status of the diagnostic trouble codes.
ReadFreezeFrameData The client requests from the server the transmission of the value of a record
stored in a freeze frame.
ClearDiagnosticInformation The client requests from the server to clear all or a group of the diagnostic
information stored.
Table 8 - Stored Data Transmission functional unit

8.1 - ReadDiagnosticTroubleCodes service

This service is not part of the KWP 2000 Part 3 Implementation Recommended Practice and shall therefore not
be implemented!
The purpose of the service readDiagnosticTroubleCodes is to read diagnostic trouble codes from the server's (ECU's)
memory. This service is not implemented because the same information, besides additional diagnostic trouble codes
information (e.g. statusOfDTC), is contained in the service readDiagnosticTroubleCodesByStatus.

Page: 82 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

8.2 - ReadDiagnosticTroubleCodesByStatus service

8.2.1 - Parameter definition

8.2.1.1 - Request parameter definition

Hex Description Cvt Mnemonic

00 requestIdentifiedBCDDTCAndStatus (SAE J2012 format) C1 RIDTCAS
This value is used by the client (tester) to indicate to the server(s) (ECU(s)) that the
server(s) (ECU(s)) shall respond with all diagnostic trouble codes (DTCs) in BCD
format which have been identified to cause a problem at the time of the request.
01 requestSupportedBCDDTCAndStatus (SAE J2012 format) C1 RSUDTC
This value is used by the client (tester) to indicate to the server(s) (ECU(s)) that the AS
server(s) (ECU(s)) shall respond with all supported diagnostic trouble codes
(DTCs) in BCD format regardless of their status. Even, if no DTC is stored (no DTC
causes a problem at the time of the request) the server (ECU) shall report all DTCs
which are supported. This allows the client (tester) to test the DTCReadinessFlag in
the statusOfDTC parameter of each supported DTC.
02 requestIdentified2ByteHexDTCAndStatus ($0000 - $FFFF) C2 RI2BHDT
This value is used by the client (tester) to indicate to the server(s) (ECU(s)) that the CAS
server(s) (ECU(s)) shall respond with all diagnostic trouble codes (DTCs) in 2 byte
hex format which have been identified to cause a problem at the time of the
request.
03 requestSupported2ByteHexDTCAndStatus ($0000 - $FFFF) C2 RS2BHDT
This value is used by the client (tester) to indicate to the server(s) (ECU(s)) that the CAS
server(s) (ECU(s)) shall respond with all supported diagnostic trouble codes
(DTCs) in 2 byte hex format regardless of their status. Even, if no DTC is stored
(no DTC causes a problem at the time of the request) the server (ECU) shall report all
DTCs which are supported. This allows the client (tester) to test the
DTCReadinessFlag in the statusOfDTC parameter of each supported DTC.
04 - EF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
F0 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier use.
FF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 8.2.1.1.1 - Definition of statusOfDTC values in a request message

C1 = condition: This parameter shall be used if the server (ECU) supports SAE J2012 BCD formatted DTCs.
C2 = condition: This parameter shall be used if the server (ECU) supports 2 Byte Hex formatted (2 byte
unsigned numeric) DTCs ($0000 - $FFFF).

• The parameter groupOfDTC (GODTC_) is used by the readDiagnosticTroubleCodeByStatus and

readStatusOfDiagnosticTroubleCode services to select the functional group of DTC or to access a specific DTC.
Format of this parameter is vehicle manufacturer specific.

8.2.1.1.1 Function groups according to SAE J2012 (DTC Definitions Recommended Practice)

Specific standard values are POWERTRAIN, CHASSIS, BODY, NETWORK COMMUNICATION, ALL (ALL = all
vehicle systems). These are the function groups used in SAE Recommended Practice J2012 - Diagnostic Trouble Codes.
This parameter is of type BCD (Binary Coded Decimal). The table below specifies the possible values for this
parameter.

Page: 83 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex requestByFunction requestByDTC Description Cvt Mnemonic

0000 K Powertrain Group: engine and transmission M PG
0001 - 3999 K Powertrain DTCs M PDTC_...
4000 K Chassis Group M CG
4001 - 7999 K Chassis DTCs M CDTC_...
8000 K Body Group M BG
8001 - B999 K Body DTCs M BDTC_...
C000 K Network Communication Group M NCG
C001 - F999 K Network Communication DTCs M NCDTC_...
FF00 K All Groups M AG
Table 8.2.1.1.1.2 - Definition of groupOfDTC and range of DTC numbers

• groupOfDTC = requestByFunction: The parameter groupOfDTC shall be used to identify different DTC groups.
The most significant bits of the high nibble of the high byte are used to "requestByFunction" and are encoded
using the same convention as diagnostic trouble codes are reported. For requestByFunction, the second two bits of
the high nibble of the high byte are '00', and the low nibble of the high byte includes zeroes. This translates to the
following function groups for DTC requests.

High Byte Low Byte Description

High Nibble Low Nibble High Nibble Low Nibble Hex
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0=P 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0000 Powertrain: engine and transmission
0 1=C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4000 Chassis
1 0=B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8000 Body
1 1=U 0 0 0 0 0 0 0 0 0 0 0 0 0 0 C000 Network Communication
1 1=A 1 1 1 1 1 1 0 0 0 0 0 0 0 0 FF00 All groups
Table 8.2.1.1.1.1 - Definition of function groups of the parameter groupOfDTC
Note: $FF00 is defined as the function group to request DTC information for all functions.

8.2.1.1.2 Vehicle Manufacturer defined function groups according to 2 Byte Hex DTC format

Hex requestByFunction requestByDTC Description Cvt Mnemonic

K Powertrain Group: engine and transmission M PG
K Powertrain DTCs M VMS_PDT
C_...
to K Chassis Group M VMS_CG
be K Chassis DTCs M VMS_CDT
C_...
determined K Body Group M VMS_BG
by K Body DTCs M VMS_BDT
C_...
Vehicle K Network Communication Group M VMS_NCG
Manufacturer K Network Communication DTCs M VMS_NCD
TC_...
FFFF K All Groups M VMS_AG
Table 8.2.1.1.2.1 - Definition of Vehicle Manufacturer defined groupOfDTC and range of 2 Byte Hex DTC numbers
8.2.1.2 - Response parameter definition
Part 3 Implementation Recommended Practice addition:

Page: 84 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

• The parameter numberOfDTC (NRODTC_) is used by the readDiagnosticTroubleCodesByStatus and

readStatusOfDiagnosticTroubleCodes services to indicate how many DTCs of the group specified in the request
have been stored by the server(s) ECU(s). A specific standard value is noDTCStored.

Hex Description Cvt Mnemonic

00 noDTCStored M NODTCS
This value indicates to the client (tester) that the server(s) (ECU(s)) does not have
any DTC stored.
01 - FF numberOfDTCStored M NRODTCS
This range of values indicates to the client (tester) that the server(s) (ECU(s)) has
(have) stored DTC(s).
Table 8.2.1.2.1 - Definition of numberOfDTC values

• The parameter listOfDTCAndStatus (LODTCAS_...) is used by the readDiagnosticTroubleCodesByStatus positive

response message to report diagnostic trouble codes (DTCs) and status information. If the parameter statusOfDTC
in the request message is set to “requestIdentifiedDTC And Status”, the ECU reports those DTCs which have been
identified at the time of the request, independent of their status. If the parameter statusOfDTC in the request message
is set to “requestSupportedDTCAndStatus”, the ECU reports all supported DTCs, independent of their status. The
listOfDTCAndStatus parameter is of the type "record" and shall include multiple DTCs with status information if
DTCs have been identified by the server(s) (ECU(s)). If no DTC has been identified (the parameter numberOfDTC =
'$00') by the server(s) (ECU(s)) at the time of the request and the parameter statusOfDTC in the request message is
set to “requestIdentifiedDTCAndStatus” the server(s) (ECU(s)) shall not include the parameter listOfDTCAndStatus
in the positive response message. Refer to table 8.2.2.2 for more detailed information.
The parameter Diagnostic Trouble Code (DTC) is used by the server (ECU) to report system failures by a two (2)
byte number. The format of a DTC is specified by the vehicle manufacturer.

If the SAE J2012 format is chosen, the 2 bytes are coded as shown in th example below:
Example of DTC "P0130" O2 Sensor Circuit Malfunction (Bank 1, Sensor 1) (SAE J2012)
High Byte Low Byte
High Nibble Low Nibble High Nibble Low Nibble
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0

P 0 1 3 0

• The parameter statusOfDTC (SODTC_...) is used by the server(s) (ECU(s)) in the positive response message to
provide status information for each DTC.

Hex Description Cvt Mnemonic

xx statusOfDTC-Response M SODTC
The parameter statusOfDTC (SODTC) is used by the server(s) (ECU(s)) in the positive response -RE
message to report status information about each DTC, which has been identified at the time of
the request, independent of their status.
Table 8.2.1.2.2 - Definition of statusOfDTC values in the response message

Page: 85 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

The state diagram of the statusOfDTC-Response_DTCStorageState parameter shall provide more detail about the
possible DTCStorageState conditions in the server's (ECU's) memory. The two bits shown in the figure are bit 6 and 5 of
the statusOfDTC-Response parameter.

'00'
'00'
noDTCDetected at
'01' time of request
'10'

DTCNotPresent
at time of DTCMaturing-
request Intermittent at
time of request
DTCPresent
'01' at time of '10'
'11' '11'
request

Clear DTC Info

Figure 4 - State diagram of DTCStorageState

Page: 86 of 160
KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Bit Description of statusOfDTC-Response Mnemonic

3,2,1, DTCFaultSymptom DTCFS_
0 This bit field is state encoded and represents sixteen (16) different diagnostic trouble code fault
symptom states. Basic fault symptom states are: '0000b', '0001b', '0010b', '0100b', and '1000b'.
'0000' = "no fault symptom available for this DTC" ZERO
E.g. This fault symptom shall be used if the DTC identified does not require any additional
fault symptom (defective EEPROM).
'0001' = "above maximum threshold" ABOVE
E.g. This fault symptom is similar to the "High Input" (P0123) or "High Voltage" (P0132) or
"Too Rich" (P0171) fault symptom as defined in SAE J2012.
'0010' = "below minimum threshold" BELOW
E.g. This fault symptom is similar to the "Low Input" (P0122), "Low Voltage" (P0131), "Too
Lean" (P0123) fault symptom as defined in SAE J2012.
'0100' = "no signal" NOSIGNAL
E.g. This fault symptom is similar to the "Range/Performance" (P0116) or "No Activity"
(P0134) fault symptom as defined in SAE J2012.
'1000' = "invalid signal" INVALID
E.g. This fault symptom is similar to the "Incorrect Ratio" (P0730) fault symptom (P0731) as
defined in SAE J2012.
'$x3, $x5, $x6, $x7, $x9, $xA, $xB, $xC, $xD, $xE, $xF'' = "vehicle manufacturer specific fault
symptoms"
Any combination of bits result in a vehicle manufacturer specific fault symptom.
E.g. These fault symptoms shall be used if none of the above basic fault symptoms apply to
the DTC identified.
4 DTCReadinessFlag DTCRF_
This bit indicates whether the diagnostic trouble code test conditions have been met during a driving
cycle since the last successful clearDiagnosticInformation service. This bit allows for one bit to be
available for service which indicates that the diagnostic test for a DTC has been completed, since DTC
information was cleared.
'0' = "testComplete for this DTC TESTC
'1' = "testNotComplete for this DTC TESTNC
E.g. The DTCReadinessFlag of a kickdown switch of an Automatic Transmission Controller will only
be set to the testComplete status if the kickdown switch is activated (full throttle) and if all other DTC
diagnostic test criteria have been met during the driving cycle. The other statusOfDTC parameter values
shall only be updated by the software of the server (ECU) if the DTCReadinessFlag is set to
testComplete or if the client (tester) has successfully performed a clearDiagnosticInformation service.
After a clearDiagnosticInformation service the DTCReadinessFlag shall be set to testNotComplete.
6,5 DTCStorageState DTCSS_
This bit field is state encoded and represents different diagnostic trouble code states.
'00' = noDTCDetected at time of request; NODTCD
no DTC stored in non volatile memory;
'01' = DTCNotPresent at time of request; DTCNP
DTC was present;
DTC stored in non volatile memory;
'10' = DTCMaturing-Intermittent at time of request; DTCM-I
insufficient data to consider as a malfunction to store in non volatile memory;
'11' = DTCPresent at time of request; DTCP
DTC stored in non volatile memory;
7 DTCWarningLampCalibrationStatus DTCWLCS
This bit includes the "calibration status" (DTCWarningLampCalibrationStatus enabled or disabled) of _
the malfunction warning lamp for the diagnostic trouble code supported in the server's (ECU's) memory.
'0' = disabled
Warning lamp not illuminated for this DTC;
'1' = enabled DISA
Warning lamp illuminated for this DTC;
ENA
Table 8.2.1.2.3 - Definition of statusOfDTC values

Page: 87 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

The figure below shows a diagram which specifies an example of how the Diagnostic Trouble Code (DTC) detection logic shall be implemented in a server (ECU). The diagram is
splitted into thirteen (13) columns (steps). The step width is a measure of time. The different lines represent: upper four (4) lines consist of a DTC readiness flag, unfiltered DTC
detection, a filtered DTC diagram which shall be used to control the state of the DTCWarningLamp; a DTCStorageState diagram which shows the state of bit ‘5’ and ‘6’ of the
statusOfDTC parameter; a check light diagram which shows the state OFF or ON. The DTC filter is always incremented either to validate a fault detection or to validate the disappearance
of the fault. The state of the filtered DTC only changes if the filter counter reaches the appropriate threshold. Bit ‘6’ of the DTCStorageState indicates whether a fault is detected.

Step Number 0 1 2 3 4 5 6 7 8 9 10 11 12 13

1
DTC-
Readiness- DTCReadinessFlag set to '0' = testComplete (DTC test conditions have been met)
Flag
0
1
Unfiltered
DTC No Fault Fault No Fault Fault No Fault Fault No Fault Fault No Fault Fault
Detection
0
1
Filtered
DTC
0

DTC NODTCD DTCM-I NODTCD DTCM-I DTCP DTCNP DTCP DTCNP DTCNP DTCP DTCNP DTCNP DTCP DTCP
State

1
B = Bit '6'
DTC- 0
StorageState: 1
A = Bit '5'
0
1
DTC-
Warning- OFF ON OFF ON
Lamp 0
1
Emergency
or Normal Mode Emergency Mode Normal Mode
Normal Mode
0
time
Step Number 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Figure 5 - Diagnostic Trouble Code DTCStorageState

Page 88 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

8.2.2 - Message data bytes

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readDiagnosticTroubleCodesByStatus Request SId M 18 RDTCBS
#2 statusOfDTC M xx SODTC_...
#3 groupOfDTC (High Byte) M xx GODTC_...
#4 groupOfDTC (Low Byte) M xx
Table 8.2.2.1 - ReadDiagnosticTroubleCodesByStatus Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readDiagnosticTroubleCodesByStatus Pos. Response SId M 58 RDTCBSPR
#2 numberOfDTC M xx NRODTC_...
listOfDTCAndStatus=[ C LODTCAS_...
#3 DTC#1 (High Byte) xx DTC_
: DTC#1 (Low Byte) xx
: statusOfDTC#1 xx SODTC_
: : : :
: DTC#m (High Byte) xx DTC_
: DTC#m (Low Byte) xx
#n statusOfDTC#m] xx SODTC_
Table 8.2.2.2 - ReadDiagnosticTroubleCodesByStatus Positive Response Message

C = condition: listOfDTCAndStatus is only present if numberOfDTC is > "$00".

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 readDiagnosticTroubleCodesByStatus Request SId M 18 RDTCBS
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 8.2.2.3 - ReadDiagnosticTroubleCodesByStatus Negative Response Message
8.2.3 - Message description
Part 3 Implementation Recommended Practice addition:
If the server(s) does not (do not) have any DTC with status information stored and the parameter statusOfDTC in the
request message is not equal to “requestSupportedDTCAndStatus” it (they) shall set the parameter numberOfDTCStored
to "$00". This causes the server(s) not to include DTC(s) and status information in the parameter
listOfDTCAndStatus in the positive response message.
The readDiagnosticTroubleCodesByStatus service is used by the client (tester) to read diagnostic trouble
codes by status from the server's (ECU's) memory. The parameter groupOfDTC shall be either set to
requestByFunction or requestByDTC in the request message. The server(s) (ECU(s)) shall only report DTC(s) with
status information based on the content of the groupOfDTC parameter value selected by the client (tester).
Note: The DTCs shall be reported by the server(s) (ECU(s)) in the same sequence as they have been
identified/detected!
There are two ways in reporting DTC`s from the server (ECU) to the client (tester):

a.) A DTC shall be reported by the server(s) ECU(s) as many times as it has been detected with different
DTCFaultSymptom values. As a consequence the parameter “numberOfDTC” in the positive response
message is the total number of all DTCs + DTCFaultSymptoms which are part of the groupOfDTC
parameter requested.

b.) A DTC shall be reported by the server(s) ECU(s) uniquely. The corresponding system supplier data
shall be stored according to it´s priority or last occurance.

It is in the vehicle manufacturer´s responsibility to decide which method shall be implemented.

Page: 90 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

8.2.4 - Message flow example

See message flow example of Physically Addressed Service in section 5.3.1.1 and Functionally Addressed
Service in section 5.3.2.1.
8.2.5 - Implementation example of readDiagnosticTroubleCodesByStatus

8.2.5.1 - Test specification readDiagnosticTroubleCodesByStatus (SAE J2012 format)

The following example describes a sequence of diagnostic trouble code occurence of a "Powertrain" system.

• Read all DTCs with statusOfDTC (request) = '$00'

The DTCs stored in the server's (ECU's) memory are specified below:

DTC#1: P0130: O2 Sensor Circuit Malfunction (Bank 1, Sensor 1)

statusOfDTC#1 = $24: DTCFaultSymptom = '0100b' { no signal }
DTCReadinessFlag = '0b' { testComplete }
DTCStorageState = '01b' { notPresent }
DTCWarningLampCalibrationStatus = '0b' { off }

DTC#2: P0120: Throttle Position Circuit Malfunction

statusOfDTC#2 = $E2: DTCFaultSymptom = '0010b' { below minimum threshold }
DTCReadinessFlag = '0b' { testComplete }
DTCStorageState = '11b' { present }
DTCWarningLampCalibrationStatus = '1b' { on }

DTC#3: P0135: O2 Sensor Heater Circuit Malfunction (Bank 1, Sensor 1)

statusOfDTC#3 = $12: DTCFaultSymptom = '0010b' { below minimum threshold }
DTCReadinessFlag = '1b' { testNotComplete }
DTCStorageState = '00b' { noDTCDetected }
DTCWarningLampCalibrationStatus = '0b' { off }

8.2.5.2 - Message flow

8.2.5.2.1 - Message flow of readDTCByStatus (request all DTCs) (SAE J2012 format)
Note: DTC#3 is not included in the positive response message because the DTCReadinessFlag is still set to
"testNotComplete"!
STEP#1 readDiagnosticTroubleCodesByStatus(SODTC-RT, GODTC_PG)
time Client (tester) Request Message Hex
P3 readDTCByStatus.ReqSId[ 18
statusOfDTC { requestIdentifiedDTCAndStatus } 00
groupOfDTC { GODTC_PG = Powertrain High Byte } 00
groupOfDTC { GODTC_PG = Powertrain Low Byte }] 00

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDTCByStatus.PosRspSId[ 58 negativeResponse Service Identifier 7F
numberOfDTC 02 readDTCByStatus.ReqSId[ 18
DTC#1 { High Byte } {O2 Sensor Circuit Malf.} 01 responseCode { refer to section 4.4 }] xx
DTC#1 { Low Byte } {Bank 1, Sensor 1} 30
statusOfDTC#1 24
DTC#2 { High Byte } {Throttle Position Malf.} 01
DTC#2 { Low Byte } {Throttle Position Malf.} 20
statusOfDTC#2 E2
return(main) return(responseCode)

Page: 91 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

8.2.5.2.2 Message flow of readDTCByStatus (request all supported DTCs) (vehicle manufacturer
specific 2 Byte Hex DTC format)

The following 19 DTCs stored in the server's (ECU's) memory are specified below:

DTC#1: $0001: ECU-specific DTC 1

DTC#2: $0002: ECU-specific DTC 2
DTC#3: $0003: ECU-specific DTC 3
DTC#4: $0004: ECU-specific DTC 4
DTC#5: $0005: ECU-specific DTC 5
DTC#6: $0006: ECU-specific DTC 6
DTC#7: $0007: ECU-specific DTC 7
DTC#8: $0008: ECU-specific DTC 8
DTC#9: $0009: ECU-specific DTC 9
DTC#10: $000A: ECU-specific DTC 10
DTC#11: $000B: ECU-specific DTC 11
DTC#12: $000C: ECU-specific DTC 12
DTC#13: $000D: ECU-specific DTC 13
DTC#14: $000E: ECU-specific DTC 14
DTC#15: $000F: ECU-specific DTC 15
DTC#16: $0010: ECU-specific DTC 16
DTC#17: $0011: ECU-specific DTC 17
DTC#18: $0012: ECU-specific DTC 18
DTC#19: $0013: ECU-specific DTC 19
statusOfDTC#1 - 19 = $xx

STEP#1 readDiagnosticTroubleCodesByStatus(SODTC-RT, GODTC_PG)

time Client (tester) Request Message Hex
P3 readDTCByStatus.ReqSId[ 18
statusOfDTC { requestSupportedVehicleManufacturerSpecificDTCAndStatus} 03
groupOfDTC { GODTC_PG = All Groups High Byte } FF
groupOfDTC { GODTC_PG = All Groups Low Byte }] FF

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDTCByStatus.PosRspSId[ 58 negativeResponse Service Identifier 7F
numberOfDTC 13 readDTCByStatus.ReqSId[ 18
DTC#1 { High Byte } 00 responseCode { refer to section 4.4 }] xx
DTC#1 { Low Byte } 01
statusOfDTC#1 xx
DTC#2 { High Byte } 00
DTC#2 { Low Byte } 02
statusOfDTC#2 xx
DTC#3 { High Byte } 00
DTC#3 { Low Byte } 03
statusOfDTC#3 xx
DTC#4 { High Byte } 00
DTC#4 { Low Byte } 04
statusOfDTC#4] xx
: :
: :
DTC#19 { High Byte } 00
DTC#19 { Low Byte } 13
statusOfDTC#19] xx
return(main) return(responseCode)

Page: 92 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

8.2.5.2.3 - Message flow of readDTCByStatus with server (ECU) transmit data segmentation
This message flow specifies two (2) different methods of implementations in the server (ECU) in case the number of
DTCs to report to the client (tester) is greater than the transmit buffer in the server (ECU). In such case the server (ECU)
shall use one of the following described methods:
Method #1: Data Segmentation
The client (tester) recognizes that the numberOfDTC parameter includes a greater value than the actual amount of data
bytes (DTCs) included in the positive response message. The client (tester) receives multiple positive response messages
with the same service identifier value and if a three (3) byte header is used it shall also look for the target address. The
client (tester) shall concatenuate all positive response messages received which meet above described critera as one
positive response message.
In this example the server (ECU) has a limited transmit buffer of fifteen (15) data bytes only. The server (ECU) supports
sixteen (16) DTCs which add up to a total of (16 * 3 + 2 = 50 data bytes if one response message) based on the request
message.
STEP#1 readDiagnosticTroubleCodesByStatus(SODTC-RT, GODTC_PG) (SAE J2012 fomat or vehicle
manufacturer specific 2 Byte Hex DTC format)
time Client (tester) Request Message Hex
P3 readDTCByStatus.ReqSId[ 18
statusOfDTC { requestSupportedDTCAndStatus } 01,0
groupOfDTC { GODTC_PG = Powertrain High Byte } 3
groupOfDTC { GODTC_PG = Powertrain Low Byte }] 00
00

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDTCByStatus.PosRspSId[ 58 negativeResponse Service Identifier 7F
numberOfDTC 10 readDTCByStatus.ReqSId[ 18
DTC#1 { High Byte } xx responseCode { refer to section 4.4 }] xx
DTC#1 { Low Byte } xx
statusOfDTC#1 xx
: :
DTC#5 { High Byte }] xx
goto(STEP#2) return(responseCode)

STEP#2 readDiagnosticTroubleCodesByStatusPositiveresponse(...)
time Server (ECU) Positive Response Message Hex Negative Response Message Not Possible!
P2 readDTCByStatus.PosRspSId[ 58
DTC#5 { Low Byte } xx
statusOfDTC#5 xx
: :
DTC#9 { High Byte } xx
DTC#9 { Low Byte } xx
statusOfDTC#9] xx
goto(STEP#3)

STEP#3 readDiagnosticTroubleCodesByStatusPositiveresponse(...)
time Server (ECU) Positive Response Message Hex Negative Response Message Not Possible!
P2 readDTCByStatus.PosRspSId[ 58
DTC#10 { High Byte } xx
DTC#10 { Low Byte } xx
statusOfDTC#10 xx
: :
DTC#14 { High Byte } xx
DTC#14 { Low Byte }] xx
goto(STEP#4)

Page: 93 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

STEP#4 readDiagnosticTroubleCodesByStatusPositiveresponse(...)
time Server (ECU) Positive Response Message Hex Negative Response Message Not Possible!
P2 readDTCByStatus.PosRspSId[ 58
statusOfDTC#14 xx
DTC#15 { High Byte } xx
DTC#15 { Low Byte } xx
statusOfDTC#15 xx
DTC#16 { High Byte } xx
DTC#16 { Low Byte } xx
statusOfDTC#16] xx
return(main)

Method #2: On line transmit buffer refill during transmission

The server (ECU) has more DTCs to report than the size of the transmit buffer. To avoid data segmentation the server
(ECU) shall start sending the positive response message while adding more DTCs to the transmit buffer on the fly. This
shall result in one (1) positive response message of the server (ECU).
STEP#1 readDiagnosticTroubleCodesByStatus(SODTC-RT, GODTC_PG) (SAE J2012 fomat or vehicle
manufacturer specific 2 Byte Hex DTC format)
time Client (tester) Request Message Hex
P3 readDTCByStatus.ReqSId[ 18
statusOfDTC { requestSupportedDTCAndStatus } 01,0
groupOfDTC { GODTC_PG = Powertrain High Byte } 3
groupOfDTC { GODTC_PG = Powertrain Low Byte }] 00
00

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDTCByStatus.PosRspSId[ 58 negativeResponse Service Identifier 7F
numberOfDTC 10 readDTCByStatus.ReqSId[ 18
DTC#1 { High Byte } xx responseCode { refer to section 4.4 }] xx
DTC#1 { Low Byte } xx
statusOfDTC#1 xx
: :
DTC#16 { High Byte } xx
DTC#16 { Low Byte } xx
statusOfDTC#16] xx
return(main) return(responseCode)

Page: 94 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

8.3 - ReadStatusOfDiagnosticTroubleCodes service

8.3.1 - Parameter definition
• The parameter groupOfDTC (GODTC_) is used by the readDiagnosticTroubleCodeByStatus and
readStatusOfDiagnosticTroubleCode services to access a specific DTC. Format of this parameter is vehicle
manufacturer specific.
8.3.1.1 Function groups according to SAE J2012 (DTC Definitions Recommended Practice)

Hex requestByFunction requestByDTC Description Cvt Mnemonic

0001 - 3999 not applicable K Powertrain DTCs M PDTC_...
4001 - 7999 not applicable K Chassis DTCs M CDTC_...
8001 - B999 not applicable K Body DTCs M BDTC_...
C001 - F999 not applicable K Network Communication DTCs M NCDTC_...
Table 8.3.1.1 - Definition of groupOfDTC ranges

• groupOfDTC = requestByDTC: The parameter groupOfDTC shall also be used to identify a single diagnostic
trouble code (DTC). The DTC may be of the group powertrain, chassis or body. The indication, whether the
parameter groupOfDTC includes a DTC group or a unique DTC number is specified by the content of this
parameter. A value different than "$0000", "$4000", "$8000" or "$C000" indicates a DTC number (refer to table
below: "DTC range“ column).

High Byte Low Byte

High Nibble Low Nibble High Nibble Low Nibble Hex Description
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 DTC range
0 0=P x x x x x x x x x x x x x x 0001 - 3999 Powertrain DTCs
0 1=C x x x x x x x x x x x x x x 4001 - 7999 Chassis DTCs
1 0=B x x x x x x x x x x x x x x 8001 - B999 Body DTCs
1 1=U x x x x x x x x x x x x x x C001 - F999 Network Communication
DTCs
Table 8.3.1.1.1 - Definition of DTC within the parameter groupOfDTC

8.3.1.2 Vehicle Manufacturer defined function groups according to 2 Byte Hex DTC format
Hex requestByFunction requestByDTC Description Cvt Mnemonic
to be not applicable K Powertrain DTCs M VMS_PDT
C_...
determined not applicable K Chassis DTCs M VMS_CDT
C_...
by Vehicle not applicable K Body DTCs M VMS_BDT
C_...
Manufacturer not applicable K Network Communication DTCs M VMS_NCD
TC_...
Table 8.3.1.2.1 - Definition of Vehicle Manufacturer defined groupOfDTC

• The parameter numberOfDTC (NRODTC_) is defined in section 8.2.1.

Part 3 Implementation Recommended Practice addition:

• The parameter listOfDTCAndStatus (LODTCAS_) shall be defined by the system supplier and the vehicle
manufacturer. This parameter shall report diagnostic trouble codes (DTCs) and status information for those DTCs
which have been identified at the time of the request, independent of their status. The definition of this parameter
used in this service may be different than in the service readDiagosticTroubleCodesByStatus.
The parameter Diagnostic Trouble Code (DTC) is defined in section 8.2.1.
The parameter statusOfDTC (SODTC_) is used by the server (ECU) to report system specific DTC status
information.

Page: 95 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

8.3.2 - Message data bytes

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readStatusOfDiagnosticTroubleCodes Request SId M 17 RSODTC
#2 groupOfDTC = requestByDTC { High Byte } [ refer to table 8.3.1.3 ] M xx GODTC_...
#3 groupOfDTC = requestByDTC { Low Byte } [ refer to table 8.3.1.3 ] M xx
Table 8.3.2.1 - ReadStatusOfDiagnosticTroubleCodes Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readStatusOfDiagnosticTroubleCodes Positive Response SId M 57 RSODTCPR
#2 numberOfDTC M xx NRODTC_
listOfDTCAndStatus=[ LODTCAS_
#3 DTC { High Byte } M xx DTC_
#4 DTC { Low Byte } M xx
#5 statusOfDTC M xx SODTC_
#6 systemSupplierData#1 M xx SSD
: : : : :
#n systemSupplierData#m] U xx SSD
Table 8.3.2.2 - ReadStatusOfDiagnosticTroubleCodes Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NA
#2 readStatusOfDiagnosticTroubleCodes Request SId M 17 RSODTC
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 8.3.2.3 - ReadStatusOfDiagnosticTroubleCodes Negative Response Message
8.3.3 - Message description
The readStatusOfDiagnosticTroubleCodes service is used by the client to read diagnostic trouble codes with
their associated status from the server's memory.
If the server(s) does not (do not) have any DTC with status information stored it (they) shall set the parameter
numberOfDTC to noDTCStored ($00). This causes the server(s) not to include DTC(s) and status information
in the parameter listOfDTC in the positive response message.
Part 3 Implementation Recommended Practice addition:
This service shall be used to report DTC location and symptom(s) (environmental parameter conditions when the DTC
is identified) as systemSupplierData. This service is limited to the request of DTC status information about a single
(selected) DTC. Each DTC may have a unique number of systemSupplierData.
If the client (tester) requests the status of a DTC which is unknown to the server (ECU) the server (ECU) shall send a
negative response message with the appropriate negative response code!
8.3.4 - Message flow example
See message flow example of Physically Addressed Service in section 5.3.1.1 and Functionally Addressed
Service in section 5.3.2.1.

Page: 96 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

8.3.5 - Implementation example of readStatusOfDiagnosticTroubleCodes

8.3.5.1 - Test specification readStatusOfDiagnosticTroubleCodes (SAE J2012 format)

In this example the groupOfDTC parameter is set to: "requestByDTC" = P0120: Throttle Position Circuit Malfunction.

The server (ECU) has stored the DTC with the following statusOfDTC systemSupplierSpecific data:

DTC#2: P0120: Throttle Position Circuit Malfunction

statusOfDTC#2 = $E2: DTCFaultSymptom = '0010b' { below minimum threshold }
DTCReadinessFlag = '0b' { testComplete }
DTCStorageState = '11b' { present }
DTCWarningLampCalibrationStatus = '1b' { on }
systemSupplierData#1: Environmental Condition#1: Engine Speed { $2648 = 2450 r/min }
systemSupplierData#2: Environmental Condition#2: Vehicle Speed { $46 = 75 km/h }
systemSupplierData#3: DTC Event Counter { $07 = 7 }

8.3.5.2 - Message flow

STEP#1 readStatusOfDiagnosticTroubleCodes(GODTC_DTC "P0120")

time Client (tester) Request Message Hex
P3 readStatusOfDTC.ReqSId[ 17
groupOfDTC { GODTC_DTC = DTC High Byte } {Throttle Position Malf.} 01
groupOfDTC { GODTC_DTC = DTC Low Byte } {Throttle Position Malf.}] 20

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readStatusOfDTC.PosRspSId[ 57 negativeResponse Service Identifier 7F
numberOfDTC 01 readStatusOfDTC.ReqSId[ 17
DTC#1 { High Byte } {Throttle Position Malf.} 01 responseCode { refer to section 4.4 }] xx
DTC#1 { Low Byte } {Throttle Position Malf.} 20
statusOfDTC E2
systemSupplierData#1 {Engine Speed=2450 26
r/min} 48
systemSupplierData#1 {Engine Speed=2450 46
r/min} 07
systemSupplierData#2 {Vehicle Speed=75
km/h}
systemSupplierData#3 {Event Counter=7}]
goto STEP#2 return(responseCode)

8.3.5.2.1 - Test specification readStatusOfDiagnosticTroubleCodes (vehicle manufacturer specific

format)
In this example the groupOfDTC parameter is set to: "requestByDTC" = $0ACD: ECU-specific DTC

The server (ECU) has stored the DTC with the following statusOfDTC systemSupplierSpecific data:

DTC#2: $0ACD: ECU-specific DTC#2

statusOfDTC#2 = $E2: DTCFaultSymptom = '0010b' { below minimum threshold }
DTCReadinessFlag = '0b' { testComplete }
DTCStorageState = '11b' { present }
DTCWarningLampCalibrationStatus = '1b' { on }
systemSupplierData#1: Environmental Condition#1: Engine Speed { $2648 = 2450 r/min }
systemSupplierData#2: Environmental Condition#2: Vehicle Speed { $46 = 75 km/h }
systemSupplierData#3: DTC Event Counter { $07 = 7 }

Page: 97 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

8.3.5.3 - Message flow

STEP#1 readStatusOfDiagnosticTroubleCodes(GODTC_DTC "$0ACD")

time Client (tester) Request Message Hex
P3 readStatusOfDTC.ReqSId[ 17
groupOfDTC { GODTC_DTC = DTC High Byte } 0A
groupOfDTC { GODTC_DTC = DTC Low Byte } CD

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readStatusOfDTC.PosRspSId[ 57 negativeResponse Service Identifier 7F
numberOfDTC 01 readStatusOfDTC.ReqSId[ 17
DTC#1 { High Byte } {Throttle Position Malf.} 0A responseCode { refer to section 4.4 }] xx
DTC#1 { Low Byte } {Throttle Position Malf.} CD
statusOfDTC E2
systemSupplierData#1 {Engine Speed=2450 26
r/min} 48
systemSupplierData#1 {Engine Speed=2450 46
r/min} 07
systemSupplierData#2 {Vehicle Speed=75
km/h}
systemSupplierData#3 {Event Counter=7}]
goto STEP#2 return(responseCode)

8.4 - ReadFreezeFrameData service

8.4.1 - Parameter definition
• The parameter freezeFrameNumber (FFNR_) is used by the client to identify the freeze frame to be read
from the server's memory.

Part 3 Implementation Recommended Practice addition:

Hex Description Cvt Mnemonic

00 freezeFrameDataRecord M FFDR
This value references a freeze frame data record in the server's (ECU's) memory.
01 - FE failureDataRecord U FDR
This range of values reference failure data records in the server's (ECU's) memory.
FF freezeFrameAndFailureDataRecords U FFAFDR
This value references the freeze frame data record and all failure data records in the server's
(ECU's) memory.
Table 8.4.1.1 - Definition of freezeFrameNumber values

• The parameter recordAccessMethodIdentifier (RAMI_) is used by the client to define the access
method which shall be used in the recordIdentification parameter to access a specific freeze frame data
record within the freezeFrameData.

Page: 98 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Part 3 Implementation Recommended Practice addition:

Hex Description Cvt Mnemonic
00 requestAllData U RAD
This value indicates to the server(s) (ECU(s)) that the client (tester) requests all freeze
frame data stored within the server's (ECU's) memory.
01 requestByLocalIdentifier U RBLI
This value indicates to the server that the client (tester) requests freeze frame data
identified by a local identifier.
02 requestByCommonIdentifier U RBCI
The purpose of common identifiers is to reference a unique parameter with the same
value across multiple servers (ECUs).
This value indicates to the server(s) that the client (tester) requests freeze frame data
identified by a common identifier.
03 requestByMemoryAddress N/A RBMA
This parameter shall not be implemented in the KWP 2000 Part 3 Implementation
Recommended Practice!
This value indicates to the server(s) (ECU(s)) that the client (tester) requests freeze
frame data identified by a memory address. If the server supports "16 bit" wide
address range the high byte of the memoryAddress shall be used as a
memoryIdentifier if required.
Table 8.4.1.2 - Definition of recordAccessMethodIdentifier values
Hex Description Cvt Mnemonic
04 requestByDTC U RBDTC
This value indicates to the server (ECU) that the client (tester) requests freeze frame
data identified by a DTC.
05 - 7F reservedByDocument M RBD
This range of values is reserved by this document for future definition.
80 DTCThatCausedFreezeFrameStorage U DTCTC
This value indicates to the server (ECU) that the client (tester) requests the DTC that FFS
caused the freeze frame data storage.
81 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This range of values is reserved by this document for future definition.
Table 8.4.1.2 - Definition of recordAccessMethodIdentifier values (cont’d)

Page: 99 of 160
OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

• The parameter recordIdentification (RI_) is used by the client to identify the record within the freeze
frame referenced by the parameter freezeFrameNumber.
Hex Description Cvt Mnemonic
01 - FE localIdentifier U LI_...
This range of values identifies a record which includes the data within a freeze
frame referenced by a localIdentifier.
Note: $00 and $FF are reservedByDocument;
0001 - EFFF commonIdentifier U CI_...
This range of values identifies a record which includes the data within a freeze
frame referenced by a commonIdentifier.
Note: $0000 and $FFFF are reservedByDocument; $F000-$FFFE are reserved for
system supplier use only!
0001 - 3999 DTC (Diagnostic Trouble Code) U DTC_...
4001 - 7999 SAE J2012 DTC Definitions Recommended Practice
8001 - B999 This range of values identifies a record which includes the data within a freeze
C001 - F999 frame referenced by a SAE J2012 DTC. Refer to table 8.2.1.1.1.2 - "Definition
of groupOfDTC and range of DTC numbers".
DTC (Diagnostic Trouble Code) U VMSDTC_
to be Vehicle Manufacturer defined 2 Byte Hex DTC
determined This range of values identifies a record which includes the data within a freeze
by Vehicle frame referenced by a Vehicle Manufacturer specific 2 Byte Hex DTC. Refer to
Manufacturer table 8.2.1.1.2.1 - "Definition of Vehicle Manufacturer defined groupOfDTC and
range of 2 Byte Hex DTC numbers".
Table 8.4.1.3 - Definition of recordIdentification values

• The parameter freezeFrameData is used by the readFreezeFrameData positive response message and
consists of the data identified by the parameters freezeFrameNumber and, if present, recordIdentification.
8.4.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 readFreezeFrameData Request Service Id M 12 RFFD
#2 freezeFrameNumber {default = $00} M xx FFNR_...
#3 recordAccessMethodIdentifier=[ refer to table 8.4.1.2 ] M xx RAMI_...
#4 recordIdentification { High byte } [ refer to table 8.4.1.3 ] C2/C5 xx RI_...
#5 recordIdentification { Low byte } [ refer to table 8.4.1.3 ] C5 xx
Table 8.4.2.1 - ReadFreezeFrameData Request Message

C2 = condition: present if recordAccessMethodIdentifier = requestByLocalIdentifier

C2 & C5 = condition: present if recordAccessMethodIdentifier = requestByCommonIdentifier
C2 & C5 = condition: present if recordAccessMethodIdentifier = requestByDTC
C2 & C5 = condition: not present if recordAccessMethodIdentifier = requestAllData
C2 & C5 = condition: not present if recordAccessMethodIdentifier = DTCThatCausedFreezeFrameStorage

Page: 100 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 readFreezeFrameData Positive Response Service Id S 52 RFFDPR
#2 freezeFrameNumber M xx FFNR_...
#3 freezeFrameData#1 C1 xx FFD
: : : : :
#n-3 freezeFrameData#m C1 xx FFD
#n-2 recordAccessMethodIdentifier=[ refer to table 8.4.1.1 ] 1) M xx RAMI_...
#n-1 recordIdentification { High byte } [ refer to table 8.4.1.2 ] 1) C2/C5 xx RI_...
#n recordIdentification { Low byte } [ refer to table 8.4.1.2 ] 1) C5 xx
Table 8.4.2.2 - ReadFreezeFrameData Positive Response Message

C1 = condition: not present if recordAccessMethodIdentifier = DTCThatCausedFreezeFrameStorage; otherwise present!

C2 = condition: present if recordAccessMethodIdentifier = requestByLocalIdentifier
C2 & C5 = condition: present if recordAccessMethodIdentifier = requestByCommonIdentifier
C2 & C5 = condition: present if recordAccessMethodIdentifier = requestByDTC
C2 & C5 = condition: include DTC number if recordAccessMethodIdentifier = requestAllData

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 readFreezeFrameData Request Service Id M 12 RFFD
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 8.4.2.3 - ReadFreezeFrameData Negative Response Message
8.4.3 - Message description
The readFreezeFrameData service is used by the client to read freezeFrameData stored in the server's
memory. The parameter freezeFrameNumber identifies the respective freeze frame if one or multiple freeze
frames are stored in the server's memory.
The content, type and size of this parameter depends on the value of the recordAccessMethodIdentifier (refer
to table 8.4.1.2).
Part 3 Implementation Recommended Practice addition:
The recordAccessMethodIdentifier in the request message identifies the access method used by the client (tester) to
request freezeFrameData from the server's (ECU's) memory. In addition, the parameter recordIdentifier shall always be
used in conjunction with the recordAccessMethodIdentifier.
The server (ECU) send a positive response message including the freezeFrameNumber, freezeFrameData and the
conditional parameters recordAccessMethodIdentifier and recordIdentifier. If only one (1) freezeFrame is stored by the
server (ECU) the freezeFrameNumber shall be of the value ‘$00’.

Example: Data content and data format of the freezeFrameData shall be specified by the vehicle
manufacturer. Typical uses for this mode are to report data stored upon detection of a system malfunction.
Multiple frames of data may be stored before and/or after the malfunction has been detected.
8.4.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1 and Functional Addressed
Service in section 5.3.2.1.
8.4.5 - Implementation example of readFreezeFrameData

8.4.5.1 - Test specification readFreezeFrameData

Three (3) different implementation examples are specified in the Message Flow section 8.4.5.2. It is assumed that the
server (ECU) has one (1) freeze frame stored with a freeze frame number of zero (‘$00’). The cause of the freeze frame
data storage in the server (ECU) in this example shall be by the occurence of the DTC "P0130" O2 Sensor Circuit
Malfunction (Bank 1, Sensor 1). This DTC causes the following parameters to be stored as freeze frame data:

Page: 101 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Note: The parameters listed are specified as freeze frame data in the SAE J1979 E/E Diagnostic Test Modes. The
single byte Parameter Identifier is treated as a "localIdentifier" as specified in section 8.4.1.

localIdentifier (Hex) Parameter Description Mnemonic

03 Fuel System Status FSS
04 Calculated Load Value CLV
05 Engine Coolant Temperature ECT
06 Short Term Fuel Trim - Bank 1 STFT
07 Long Term Fuel Trim - Bank 1 LTFT
08 Fuel Pressure (Gage) FP
09 Intake Manifold Absolute Pressure IMAP
0A Engine Speed ES
0B Vehicle Speed VS
Table 8.4.5.1 - FreezeFrameData
8.4.5.2 - Message flow

8.4.5.2.1 - Message flow with recordAccessMethodIdentifier DTCThatCausedFreezeFrameStorage

This example shows how the client (tester) requests the DTC which caused the freeze frame data to be stored. The
positive response message includes the DTC value in the recordIdentification parameter.
STEP#1 readFreezeFrameData(FFNR_ZERO, RAMI_DTCTCFFS)
time Client (tester) Request Message Hex
P3 readFreezeFrameData.ReqSId[ 12
freezeFrameNumber 00
recordAccessMethodId=DTCThatCausedFreezeFrameStorage] 80

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readFreezeFrameData.PosRspSId[ 52 negativeResponse Service Identifier 7F
freezeFrameNumber 00 readFreezeFrameData.ReqSId[ 12
RAMI=DTCThatCausedFreezeFrameStorage 80 responseCode { refer to section 4.4 }] xx
recordIdentification=P0130 { High Byte } 01
recordIdentification=P0130 { Low Byte }] 30
return(main) return(responseCode)

8.4.5.2.2 - Message flow with recordAccessMethodIdentifier RequestByDTC with "P0130"

This example shows how the client (tester) requests the freeze frame data with the recordAccessMethodIdentifier =
requestByDTC and the DTC number P0130 included in the recordIdentification parameter. The positive response
message includes the freeze frame data record stored by the server (ECU) at the time the DTC P0130 was stored in long
term memory.
STEP#1 readFreezeFrameData(FFNR_ZERO, RAMI_RBDTC, RI_P0130)
time Client (tester) Request Message Hex
P3 readFreezeFrameData.ReqSId[ 12
freezeFrameNumber 00
recordAccessMethodId=requestByDTC 04
recordIdentification=P0130 { High Byte } 01
recordIdentification=P0130 { Low Byte }] 30

Page: 102 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readFreezeFrameData.PosRspSId[ 52 negativeResponse Service Identifier 7F
freezeFrameNumber 00 readFreezeFrameData.ReqSId[ 12
freezeFrameData#1 {PID#1 High Byte} : responseCode { refer to section 4.4 }] xx
freezeFrameData#2 {PID#1 Low Byte} :
freezeFrameData#1 {PID#1 data#1} :
: :
freezeFrameData#1 {PID#1 data#k} :
: :
: :
freezeFrameData#n {PID#m High Byte} :
freezeFrameData#n+1 {PID#m Low Byte} :
freezeFrameData#n+2 {PID#m data#1} :
: :
freezeFrameData#n+k {PID#m data#k} :
RAMI=requestByDTC 04
recordIdentification=P0130 { High Byte } 01
recordIdentification=P0130 { Low Byte }] 30
return(main) return(responseCode)

8.4.5.2.3 - Message flow with method identification and requestByLocalIdentifier

The example listed below shows how the client (tester) requests the freeze frame parameter "Long Term Fuel Trim -
Bank 1". The recordAccessMethodIdentifier is set to "requestByLocalIdentifier". The recordIdentification is set to the
localIdentifier '$07' as specified in above table 8.4.5.1. The positive response message includes the content of the
parameter requested by the recordIdentification value.
STEP#1 readFreezeFrameData(FFNR_ZERO, RAMI_RBLI, RI_ )
time Client (tester) Request Message Hex
P3 readFreezeFrameData.ReqSId[ 12
freezeFrameNumber 00
recordAccessMethodId=requestByLocalId 01
recordIdentification=LongTermFuelTrim-Bank1] 07

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readFreezeFrameData.PosRspSId[ 52 negativeResponse Service Identifier 7F
freezeFrameNumber 00 readFreezeFrameData.ReqSId[ 12
FFD#1 {value of LongTermFuelTrim-Bank1} 8F responseCode { refer to section 4.4 }] xx
recordAccessMethodId=requestByLocalId 01
recordIdentification=LongTermFuelTrim-Bank1] 07
return(main) return(responseCode)

8.4.5.2.4 - Message flow with recordAccessMethodIdentifier set to requestAllData

8.4.5.2.4.1 - Message flow with recordAccessMethodIdentifier set to requestAllData with freeze

frames and failure records stored in the server (ECU)
The example listed below shows how the client (tester) requests all freeze frame and failure data records stored in the
server's (ECU's) memory. The freeze frame and each failure data record is sent as a separate positive response message
by the server (ECU) based on the client (tester) request. message. It is the vehicle manufacturer's and system supplier's
responsibility how many additional failureDataRecords a server (ECU) shall be able to store in memory!
STEP#1 readFreezeFrameData(FFNR_ZERO, RAMI_RAD)
time Client (tester) Request Message Hex
P3 readFreezeFrameData.ReqSId[ 12
freezeFrameNumber FF
recordAccessMethodId=requestAllData] 00

Page: 103 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readFreezeFrameData.PosRspSId[ 52 negativeResponse Service Identifier 7F
freezeFrameNumber 00 readFreezeFrameData.ReqSId[ 12
freezeFrameData#1 {PID#1 High Byte} : responseCode { refer to section 4.4 }] xx
freezeFrameData#2 {PID#1 Low Byte} :
freezeFrameData#1 {PID#1 data#1} :
: :
freezeFrameData#1 {PID#1 data#k} :
: :
: :
freezeFrameData#n {PID#m High Byte} :
freezeFrameData#n+1 {PID#m Low Byte} :
freezeFrameData#n+2 {PID#m data#1} :
: :
freezeFrameData#n+k {PID#m data#k} :
RAMI=requestAllData 00
recordIdentification=P0130 { High Byte } 01
recordIdentification=P0130 { Low Byte }] 30
goto STEP#2 return(responseCode)

:
STEP#n readFreezeFrameData positive response#n
time Server (ECU) Positive Response Message Hex Negative Response Message Not Possible!
P2 readFreezeFrameData.PosRspSId[ 52
failureFrameNumber #n
failureDataRecord#1 {PID#1 High Byte} :
failureDataRecord#2 {PID#1 Low Byte} :
failureDataRecord#1 {PID#1 data#1} :
: :
failureDataRecord#1 {PID#1 data#k} :
: :
: :
failureDataRecord#n {PID#m High Byte} :
failureDataRecord#n+1 {PID#m Low Byte} :
failureDataRecord#n+2 {PID#m data#1} :
: :
failureDataRecord#n+k {PID#m data#k} :
RAMI=requestAllData 00
recordIdentification=P1xxx { High Byte } 1x
recordIdentification=P1xxx { Low Byte }] xx
return(main)

8.4.5.2.4.2 - Message flow with recordAccessMethodIdentifier set to requestAllData with no freeze

frames and failure records stored in the server (ECU)
The example listed below shows the server’s (ECU’s) positive response message in case the client (tester) requests all
freeze frame and failure data records but none are stored in the server's (ECU's) memory at the time of the request. The
recordIdentification parameter shall include ‘$00’ values to indicate that no DTC is stored in server’s (ECU’s) memory.
STEP#1 readFreezeFrameData(FFNR_ZERO, RAMI_RAD)
time Client (tester) Request Message Hex
P3 readFreezeFrameData.ReqSId[ 12
freezeFrameNumber FF
recordAccessMethodId=requestAllData] 00

Page: 104 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readFreezeFrameData.PosRspSId[ 52 negativeResponse Service Identifier 7F
freezeFrameNumber FF readFreezeFrameData.ReqSId[ 12
RAMI=requestAllData 00 responseCode { refer to section 4.4 }] xx
recordIdentification=no DTC stored { High Byte } 00
recordIdentification=no DTC stored { Low Byte }] 00
return(main) return(responseCode)

8.5 ClearDiagnosticInformation service

8.5.1 - Parameter definition
• The parameter groupOfDiagnosticInformation (GODI_) is used by the clearDiagnosticInformation service to select
which functional group of DTC or which specific DTC is selected. Format of this parameter is vehicle manufacturer
specific.
8.5.1.1 Group of DTC according to SAE J2012 (DTC Definitions Recommended Practice)
• The parameter groupOfDTC = requestByFunction is already defined in section 8.2.1.1.1
• The parameter groupOfDTC = requestByDTC is already defined in section 8.3.1
8.5.1.2 Group of DTC according to Vehicle Manufacturer specific 2 Byte Hex DTC Format
• The parameter groupOfDTC = requestByFunction is already defined in section 8.2.1.1.1.2
• The parameter groupOfDTC = requestByDTC is already defined in section 8.2.1.1.1.2
8.5.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 clearDiagnosticInformation Request Service Id M 14 CDI
#2 groupOfDiagnosticInformation = { High Byte } [ table 8.5.1.1, 8.5.1.3 ] M xx GODI_...
#3 groupOfDiagnosticInformation = { Low Byte } [ table 8.5.1.1, 8.5.1.3 ] M xx
Table 8.5.2.1 - ClearDiagnosticInformation Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 clearDiagnosticInformation Positive Response SId S 54 CDIPR
#2 groupOfDiagnosticInformation = { High Byte } [ table 8.5.1.1, 8.5.1.3 ] C xx GODI_...
#3 groupOfDiagnosticInformation = { Low Byte } [ table 8.5.1.1, 8.5.1.3 ] C xx
Table 8.5.2.2 - ClearDiagnosticInformation Positive Response Message
C = condition: Parameter shall include the same value as defined in the request message!

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 clearDiagnosticInformation Request Service Id M 14 CDI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 8.5.2.3 - ClearDiagnosticInformation Negative Response Message
8.5.3 - Message description
Part 3 Implementation Recommended Practice addition:
The clearDiagnosticInformation service is used by the client (tester) to clear diagnostic information in the server's
(ECU's) memory. If the parameter groupOfDiagnosticInformation in the request message is set to requestByFunction
then the server(s) (ECU(s)) shall clear all diagnostic information based on the functional group selected by the client
(tester). If a specific DTC shall be cleared the client (tester) shall set the groupOfDiagnosticInformation parameter to
requestByDTC and include the DTC to be cleared. If the server(s) (ECU(s)) does not (do not) have any DTC and/or
diagnostic information stored the server(s) (ECU(s)) shall send a positive response message upon the reception of a
clearDiagnosticInformation request message.
A successful completion of a clearDiagnosticInformation service shall reset all DTC related information in the server's
(ECU's) memory. DTC related information is specified as: DTC number, statusOfDTC parameter, systemSupplierData
and other DTC related data.

Page: 105 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

8.5.4 - Message flow example

See message flow example of Physically Addressed Service in section 5.3.1.1 and Functionally Addressed
Service in section 5.3.2.1.
8.5.5 - Implementation example of clearDiagnosticInformation

8.5.5.1 - Test specification clearDiagnosticInformation

Two (2) different implementation examples are specified in this section. The groupOfDiagnosticInformation parameter
in example #1 is set to "requestByFunction" = "Powertrain".
In example #2 this parameter is set to "requestByDTC" = "P0120" Throttle Position Circuit Malfunction.
The server (ECU) has stored two (2) DTCs: "P0130" O2 Sensor Circuit Malfunction (Bank 1, Sensor 1);
"P0120" Throttle Position Circuit Malfunction
8.5.5.2 - Message flow

8.5.5.2.1 - Message flow of clearDiagnosticInformation by function group

STEP#1 clearDiagnosticInformation(GODI_PG)
time Client (tester) Request Message Hex
P3 clearDiagnosticInformation.ReqSId[ 14
groupOfDiagnosticInformation = Powertrain { High Byte } 00
groupOfDiagnosticInformation = Powertrain { Low Byte }] 00

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 clearDiagnosticInformation.PosRspSId[ 54 negativeResponse Service Identifier 7F
groupOfDiagnosticInfo = Powertrain { High Byte 00 clearDiagnosticInformation.ReqSId[ 14
} 00 responseCode { refer to section 4.4 }] xx
groupOfDiagnosticInfo = Powertrain { Low Byte
}]
return(main) return(responseCode)

8.5.5.2.2 - Message flow of clearDiagnosticInformation by DTC

STEP#1 clearDiagnosticInformation(GODI_DTC_P0120)
time Client (tester) Request Message Hex
P3 clearDiagnosticInformation.ReqSId[ 14
groupOfDiagnosticInformation = DTC_P0120 { High Byte } 01
groupOfDiagnosticInformation = DTC_P0120 { Low Byte }] 20

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 clearDiagnosticInformation.PosRspSId[ 54 negativeResponse Service Identifier 7F
groupOfDiagnosticInfo=DTC_P0120 { High 01 clearDiagnosticInformation.ReqSId[ 14
Byte } 20 responseCode { refer to section 4.4 }] xx
groupOfDiagnosticInfo=DTC_P0120 { Low Byte
}]
return(main) return(responseCode)

9 - InputOutput Control functional unit

The services provided by this functional unit are described in table 9:

Service name Description

InputOutputControlByLocalIdentifier The client requests the control of an input/output specific to the server.
InputOutputControlByCommonIdentifier The client requests the control of an input/output common to one or
multiple server(s).
Table 9 - InputOutput Control functional unit

Page: 106 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

9.1 - InputOutputControlByLocalIdentifier service

9.1.1 - Parameter definition
• The parameter inputOutputLocalIdentifier (IOLI_) in the inputOutputControlByLocalIdentifier request
service identifies an ECU local input signal, internal parameter or output signal.

Hex Description Cvt Mnemonic

00 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
01 - F9 inputOutputLocalIdentifier U IOLI_
This range of values shall be used by the vehicle manufacturer to reference input/output
local identifiers in the server (ECU).
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 9.1.1.1 - Definition of inputOutputLocalIdentifier values

Part 3 Implementation Recommended Practice addition:

• The controlOption parameters consist of an inputOutputControlParameter (IOCP_) and controlState (CS_)
parameters in the inputOutputControlByLocalIdentifier service. The service shall be used to control different states
of the server's (ECU's) local input signal(s), internal parameter(s) and output signal(s) as defined in the table below.
• The inputOutputControlParameter (IOCP_) parameter is used by the inputOutputControlByLocalIdentifier request
message to describe how the server (ECU) has to control its inputs or outputs as specified in the table below.

Note: The usage of the inputOutputControlParameters specified in the following table depends on the
inputOutputLocalIdentifier which shall be manipulated.
Hex Description Cvt Mnemonic
00 returnControlToECU U RCTECU
This value shall indicate to the server (ECU) that the client (tester) does no longer have control
about the input signal, internal parameter or output signal referenced by the
inputOutputLocalIdentifier.
01 reportCurrentState U RCS
This value shall indicate to the server (ECU) that it is requested to report the current state of the
input signal, internal parameter or output signal referenced by the inputOutputLocalIdentifier.
02 reportIOConditions U RIOC
This value shall indicate to the server (ECU) that it is requested to report the conditions of the
input signal, internal parameter or output signal referenced by the inputOutputLocalIdentifier.
The server (ECU) specific condition(s) are the responsibility of the vehicle manufacturer/system
supplier.
03 reportIOScaling U RIOS
This value shall indicate to the server (ECU) that it is requested to report the scaling of the input
signal, internal parameter or output signal referenced by the inputOutputLocalIdentifier. The
server (ECU) specific scaling is the responsibility of the vehicle manufacturer/system supplier.
04 resetToDefault U RTD
This value shall indicate to the server (ECU) that it is requested to reset the input signal, internal
parameter or output signal referenced by the inputOutputLocalIdentifier to its default state.
05 freezeCurrentState U FCS
This value shall indicate to the server (ECU) that it is requested to freeze the current state of the
input signal, internal parameter or output signal referenced by the inputOutputLocalIdentifier.
Table 9.1.1.2 - Definition of inputOutputControlParameter values

Page: 107 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Hex Description Cvt Mnemonic

06 executeControlOption U ECO
This value shall indicate to the server (ECU) that it is requested to execute the controlOption
parameter(s). The controlOption shall be of single or multiple parameters (bytes) if requested.
07 shortTermAdjustment U STA
This value shall indicate to the server (ECU) that it is requested to adjust the input signal,
internal parameter or output signal referenced by the inputOutputLocalIdentifier in RAM to the
value(s) included in the controlOption parameter(s). (e.g. set Idle Air Control Valve to a specific
step number, set pulse width of valve to a specific value/duty cycle).
08 longTermAdjustment U LTA
This value shall indicate to the server (ECU) that it is requested to adjust the input signal,
internal parameter or output signal referenced by the inputOutputLocalIdentifier in
EEPROM/FLASH EEPROM to the value(s) included in the controlOption parameter(s). (e.g. set
Engine Idle Speed, set CO Adjustment parameter to a specific value).
09 reportIOCalibrationParameters U RIOCP
This value shall indicate to the server (ECU) that it is requested to report the
inputOutputCalibrationParameters of the input signal, internal parameter or output signal
referenced by the inputOutputLocalIdentifier.
0A - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document for future definition.
Table 9.1.1.2 - Definition of inputOutputControlParameter values (cont’d)

Part 3 Implementation Recommended Practice addition:

• The controlStatus (CSS_) parameters consist of an inputOutputControlParameter (IOCP_) and controlState (CS_)
parameters in the inputOutputControlByLocalIdentifier positive response message. The controlState parameter may
consist of multiple bytes which include data (e.g. feedback) depending on the inputOutputControl parameter used in
the request message.
9.1.2 - Message Data Bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 inputOutputControlByLocalIdentifier Request SId M 30 IOCBLI
#2 inputOutputLocalIdentifier M xx IOLI_...
controlOption=[ CO_
#3 inputOutputControlParameter M xx IOCP_...
#4 controlState#1 C xx CS_...
: : : : :
#n controlState#m] C xx CS_...
Table 9.1.2.1 - InputOutputControlByLocalldentifier request message
C = condition: parameter depends on content of inputOutputControlParameter!

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 inputOutputControlByLocalIdentifier Positive Response SId S 70 IOCBLIPR
#2 inputOutputLocalIdentifier M xx IOLI_...
controlStatus=[ CSS_
#3 inputOutputControlParameter M xx IOCP_...
#4 controlState#1 C xx CS_...
: : : : :
#n controlState#m] C xx CS_...
Table 9.1.2.2 - InputOutputControlByLocalldentifier positive response message
C = condition: parameter depends on content of inputOutputControlParameter!

Page: 108 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 inputOutputControlByLocalIdentifier Request SId M 30 IOCBLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 9.1.2.3 - InputOutputControlByLocalldentifier negative response message
9.1.3 - Message description
The inputOutputControlByLocalIdentifier service is used by the client to substitute a value for an input signal,
internal ECU function and/or control an output (actuator) of an electronic system referenced by an
inputOutputLocalIdentifier of the server. The user optional controlOption parameter shall include all
information required by the server's input signal, internal function and/or output signal.
The server shall send a positive response message if the request message was successfully executed. It is
user optional if the positive response message shall include controlStatus information which possibly is
available during or after the control execution. The controlOption parameter can be implemented as a single
ON/OFF parameter or as a more complex sequence of control parameters including a number of cycles, a
duration, etc. if required.
9.1.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1.
9.1.5 - Implementation example of "Desired Idle Adjustment"

9.1.5.1 - "Desired Idle Adjustment" resetToDefault

9.1.5.1.1 - Test specification resetToDefault

This section specifies the test conditions of the resetToDefault function and the associated message flow of the "Desired
Idle Adjustment" inputOutputLocalIdentifier ($32).
Test conditions: ignition=ON, engine at idle speed, engine at operating temperature, vehicle speed=0 [kph]
Conversion: Desired Idle Adjustment [R/MIN] = decimal(Hex) * 10 [r/min]
9.1.5.1.2 - Message flow

STEP#1 inputOutputControlByLocalIdentifier("Desired Idle Adjustment, "IOCP_RTD)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = resetToDefault] 04

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = resetToDefault 04 responseCode { refer to section 4.4 }] xx
750 r/min { default idle adjustment }] 4B
return(main) return(responseCode)

9.1.5.2 - "Desired Idle Adjustment" shortTermAdjustment

9.1.5.2.1 - Test specification shortTermAdjustment

This section specifies the test conditions of a shortTermAdjustment function and the associated message flow of the
"Desired Idle Adjustment" inputOutputLocalIdentifier.
Test conditions: ignition=ON, engine at idle speed, engine at operating temperature, vehicle speed=0 [kph]
Conversion: Desired Idle Adjustment [r/min] = decimal(Hex) * 10 [r/min]

Page: 109 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

9.1.5.2.2 - Message flow

STEP#1 inputOutputControlByLocalIdentifier("Desired Idle Adjustment", IOCP_RCS)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = reportCurrentState] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = reportCurrentState 01 responseCode { refer to section 4.4 }] xx
800 r/min] 50
goto STEP#2 return(responseCode)

STEP#2 inputOutputControlByLocalIdentifier("Desired Idle Adjustment", IOCP_FCS)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = freezeCurrentState 05

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = freezeCurrentState 05 responseCode { refer to section 4.4 }] xx
800 r/min] 50
goto STEP#3 return(responseCode)

STEP#3 inputOutputControlByLocalIdentifier("Desired Idle Adjustment", IOCP_STA, 1000 r/min)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = shortTermAdjustment 07
1000 r/min] 64

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = shortTermAdjustment 07 responseCode { refer to section 4.4 }] xx
820 r/min { current Engine Speed }] 52
goto STEP#4 return(responseCode)

Note: The client (tester) has sent an inputOutputControlByLocalIdentifier request message as specified in STEP#3.
The server (ECU) has sent an immediate positive response message which includes the controlState parameter
"Engine Speed" with the value of "820 r/min". The engine requires a certain amount of time to adjust the idle
speed to the requested value of "1000 r/min".

Page: 110 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

STEP#4 Repeat readDataByLocalIdentifier(RLI_01) Until ("Desired Idle Adjustment"==1000 r/min)

time Client (tester) Request Message Hex
P3 readDataByLocalId.Request[ 21
recordLocalIdentifier] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 readDataByLocalId.PosRsp[ 61 negativeResponse Service Identifier 7F
recordLocalIdentifier 01 readDataByLocalId.ReqSId[ 21
recordValue#1 xx responseCode { refer to section 4.4 }] xx
: :
recordValue#n] xx
goto STEP#5 return(responseCode)

STEP#5 inputOutputControlByLocalIdentifier("Desired Idle Adjustment", IOCP_RCTECU)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = returnControlToECU] 00

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = returnControlToECU] 00 responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

9.1.5.3 - "Desired Idle Speed Offset" longTermAdjustment

9.1.5.3.1 - Test specification longTermAdjustment

This section specifies the test conditions of a longTermAdjustment function and the associated message flow of the
"Desired Idle Speed Offset" inputOutputLocalIdentifier ($33).
Test conditions: ignition=ON, engine at idle speed, engine at operating temperature, vehicle speed=0 [kph]
Conversion: Desired Idle Speed Offset [r/min] = decimal(Hex) * 1 [r/min]
Assumptions for this example: Current "Desired Idle Speed Offset" is 50 [r/min]. Current Idle Speed = 750 [r/min].
Basic Idle Speed = 700 [r/min].
After the server (ECU) has sent an inputOutputControlByLocalidentifier positive response message to the client (tester),
ignition shall be turned off to enable the ECU to write the new Desired Idle Speed Offset value into the Non Volatile
Memory.
9.1.5.3.2 - Message flow

STEP#1 inputOutputControlByLocalIdentifier("Desired Idle Speed Offset", IOCP_RIOCP)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Speed Offset" 33
inputOutputControlParameter = reportIOCalibrationParameters 09

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Speed Offset" 33 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = reportIOCalibrationPara 09 responseCode { refer to section 4.4 }] xx
minimumOffsetValue { 0 [r/min] } 00
maximumOffsetValue { 150 [r/min] } 96
offsetParameterResolution { 50 [r/min] } 32
defaultOffsetValue { 0 [r/min] } 00
actualOffsetValue] { 50 [r/min] } 32
goto STEP#2 return(responseCode)

Page: 111 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

STEP#2 inputOutputControlByLocalIdentifier("Desired Idle Speed Offset", IOCP_LTA, 150 r/min)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Speed Offset" 33
inputOutputControlParameter = longTermAdjustment 08
150 r/min] 96

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Speed Offset" 33 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = longTermAdjustment 08 responseCode { refer to section 4.4 }] xx
150 r/min] 96
goto STEP#3 return(responseCode)

InputOutputByLocalIdentifier: Desired Idle Adjustment ($32)

Basic Idle Speed now equals 850 [r/min].
Conversion: Desired Idle Adjustment [r/min] = decimal(Hex) * 10 [r/min]
STEP#3 inputOutputControlByLocalIdentifier("Desired Idle Adjustment", IOCP_RCS)
time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = reportCurrentState] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = reportCurrentState 01 responseCode { refer to section 4.4 }] xx
850 r/min] 55
return(main) return(responseCode)

9.1.5.4 - "Desired Idle Adjustment" reportIOConditions

9.1.5.4.1 - Test specification reportIOConditions

This section specifies the test conditions of the reportIOConditions function and the associated message flow of the
"Desired Idle Adjustment" inputOutputLocalIdentifier ($32).
The test conditions are identified by socalled IOConditionIdentifier(s) which are listed in the following table:

Hex Description Mnemonic

00 reservedByDocument RBD
This value is reserved by this document for future definition.
01 ignitionOn-EngineOff ION-EOF
02 engineAtOperatingTemperature EAOT
03 zeroVehicleSpeed ZVS
04 engineAtIdleSpeed EAIS
05 selectorLeverInPark SLIP
06 selectorLeverInDrive SLID
... ... ...
Table 9.1.5.4.1 - InputOutputConditionIdentifier table

Page: 112 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

9.1.5.4.2 - Message flow

STEP#1 inputOutputControlByLocalIdentifier("Desired Idle Adjustment, "IOCP_RIOC)

time Client (tester) Request Message Hex
P3 inputOutputControlByLocalId.Request[ 30
inputOutputLocalId = "Desired Idle Adjustment" 32
inputOutputControlParameter = reportIOConditions] 02

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 inputOutputControlByLocalId.PosRsp[ 70 negativeResponse Service Identifier 7F
inputOutputLocalId = "Desired Idle Adjustment" 32 inputOutputControlByLocalId.ReqSId[ 30
inputOutputControlParameter = reportIOConditions 02 responseCode { refer to section 4.4 }] xx
inputOutputConditionIdentifier#1 02
inputOutputConditionIdentifier#2 03
inputOutputConditionIdentifier#3 04
inputOutputConditionIdentifier#4] 05
return(main) return(responseCode)

9.2 - InputOutputControlByCommonIdentifier service

9.2.1 - Parameter definition
• The parameter inputOutputCommonIdentifier in the inputOutputControlByCommonIdentifier request
service identifies an input or output common to the ECU(s).

The inputOutputCommonIdentifier table consists of four (4) columns and multiple lines.
• The 1st column (Hex) includes the "Hex Value" assigned to the inputOutputCommonIdentifier specified in the 2nd
column.
• The 2nd column (Description) specifies the inputOutputCommonIdentifier.
• The 3rd column (Cvt) is the convention column which specifies whether the inputOutputCommonIdentifier is "M"
(mandatory) or "U" (User Optional).
• The 4th column (Mnemonic) specifies the mnemonic of this inputOutputCommonIdentifier.
M = mandatory, U = user optional
Hex Description Cvt Mnemonic
0000 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
0001 - EFFF inputOutputCommonIdentifier U IOCI_
This range of values shall be reserved to reference parameters implemented in the server
(ECU) upon the vehicle manufacturer's request.
F000 - FFFE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FFFF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 9.2.1.1 - Definition of inputOutputCommonIdentifier values

Part 3 Implementation Recommended Practice addition:

• The controlOption parameters consist of an inputOutputControlParameter (IOCP_) and controlState (CS_)
parameters in the inputOutputControlByCommonIdentifier service. The service shall be used to control different
states of the server's (ECU's) local input signal(s), internal parameter(s) and output signal(s) as defined in the table
below.
• The inputOutputControlParameter (IOCP_) parameter is used by the inputOutputControlByCommonIdentifier
request message to describe how the server (ECU) has to control its inputs or outputs as specified in the table below.

Page: 113 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Note: The usage of the inputOutputControlParameters specified in the following table depends on the
inputOutputCommonIdentifier which shall be manipulated.
Hex Description Cvt Mnemonic
00 returnControlToECU U RCTECU
This value shall indicate to the server (ECU) that the client (tester) does no longer have control
about the input signal, internal parameter or output signal referenced by the
inputOutputCommonIdentifier.
01 reportCurrentState U RCS
This value shall indicate to the server (ECU) that it is requested to report the current state of the
input signal, internal parameter or output signal referenced by the inputOutputCommonIdentifier.
02 reportIOConditions U RIOC
This value shall indicate to the server (ECU) that it is requested to report the conditions of the
input signal, internal parameter or output signal referenced by the inputOutputCommonIdentifier.
The server (ECU) specific condition(s) are the responsibility of the vehicle manufacturer/system
supplier.
03 ReportIOScaling U RIOS
This value shall indicate to the server (ECU) that it is requested to report the scaling of the input
signal, internal parameter or output signal referenced by the inputOutputCommonIdentifier. The
server (ECU) specific scaling is the responsibility of the vehicle manufacturer/system supplier.
04 ResetToDefault U RTD
This value shall indicate to the server (ECU) that it is requested to reset the input signal, internal
parameter or output signal referenced by the inputOutputCommonIdentifier to its default state.
05 freezeCurrentState U FCS
This value shall indicate to the server (ECU) that it is requested to freeze the current state of the
input signal, internal parameter or output signal referenced by the inputOutputCommonIdentifier.
06 executeControlOption U ECO
This value shall indicate to the server (ECU) that it is requested to execute the controlOption
parameter(s). The controlOption shall be of single or multiple parameters (bytes) if requested.
07 shortTermAdjustment U STA
This value shall indicate to the server (ECU) that it is requested to adjust the input signal,
internal parameter or output signal referenced by the inputOutputCommonIdentifier in RAM to
the value(s) included in the controlOption parameter(s). (e.g. set Idle Air Control Valve to a
specific step number, set pulse width of valve to a specific value/duty cycle).
08 longTermAdjustment U LTA
This value shall indicate to the server (ECU) that it is requested to adjust the input signal,
internal parameter or output signal referenced by the inputOutputCommonIdentifier in
EEPROM/FLASH EEPROM to the value(s) included in the controlOption parameter(s). (e.g. set
Engine Idle Speed, set CO Adjustment parameter to a specific value).
09 reportIOCalibrationParameters U RIOCP
This value shall indicate to the server (ECU) that it is requested to report the
inputOutputCalibrationParameters of the input signal, internal parameter or output signal
referenced by the inputOutputCommonIdentifier.
0A - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA – FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document for future definition.
Table 9.2.1.2 - Definition of inputOutputControlParameter values

Page: 114 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Part 3 Implementation Recommended Practice addition:

• The controlStatus (CSS_) parameters consist of an inputOutputControlParameter (IOCP_) and controlState (CS_)
parameters in the inputOutputControlByLocalIdentifier positive response message. The controlState parameter may
consist of multiple bytes which include data (e.g. feedback) depending on the inputOutputControl parameter used in
the request message.
9.2.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 inputOutputControlByCommonIdentifier Request SId M 2F IOCBCID
#2 inputOutputCommonIdentifier (High Byte) M xx IOCI_
#3 inputOutputCommonIdentifier (Low Byte) M xx
controlOption=[ CO_
#4 inputOutputControlParameter M xx IOCP_...
#5 controlState#1 C xx CS_...
: : : : :
#n controlState#m] C xx CS_...
Table 9.2.2.1 - InputOutputControlByCommonIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 inputOutputControlByCommonIdentifier Positive Resp. SId S 6F IOCBCIDPR
#2 inputOutputCommonIdentifier (High Byte) M xx IOCI_
#3 inputOutputCommonIdentifier (Low Byte) M xx
controlStatus=[ CSS_
#4 inputOutputControlParameter M xx IOCP_...
#5 controlState#1 C xx CS_...
: : : : :
#n controlState#m] C xx CS_...
Table 9.2.2.2 - InputOutputControlByCommonIdentifier Positive Response Message

C = condition: parameter depends on content of inputOutputControlParameter!

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NACK
#2 inputOutputControlByCommonIdentifier Request SId M 2F IOCBCID
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_
Table 9.2.2.3 - InputOutputControlByCommonIdentifier Negative Response Message
9.2.3 - Message description
The InputOutputControlByCommonIdentifier service is used by the client to substitute a value for an input
signal, internal ECU function and/or an control output (actuator) of electronic systems referenced by an
inputOutputCommonIdentifier of the server. The user optional controlOption parameter shall include all
information required by the server's input signal, internal function and/or output signal.
The server(s) shall send a positive response message if the request message was successfully executed. It
is user optional if the positive response message shall include controlStatus information which possibly is
available during or after the control execution.
The controlOption parameter can be implemented as a single ON/OFF parameter or as a more complex
sequence of control parameters including a number of cycles, a duration, etc.
9.2.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1 and Functional Addressed
Service in section 5.3.2.1.
9.2.5 - Implementation examples
Refer to the implementation examples of section 9.1.5.

Page: 115 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

10 - Remote Activation Of Routine functional unit

The services provided by this functional unit are described in table 10:

Service name Description

StartRoutineByLocalIdentifier The client requests to start a routine in the ECU of the server.
StartRoutineByAddress The client requests to start a routine in the ECU of the server.
StopRoutineByLocalIdentifier The client requests to stop a routine in the ECU of the server.
StopRoutineByAddress The client requests to stop a routine in the ECU of the server.
RequestRoutineResultsByLocalIdentifier The client requests the results of a routine by the Routine Local Identifier.
RequestRoutineResultsByAddress The client requests the results of a routine by the Routine Address.
Table 10 - Remote Activation Of Routine functional unit

This functional unit specifies the services of remote activation of routines as they shall be implemented in servers
(ECUs) and client (tester). "The following figure - Various methods of Remote Activation Of Routines" shows two
(2) different methods of implementation (Methods: "A" and "B"). There may be other methods of implementation
possible. Methods "A" and "B" shall be used as a guideline for implementation of routine services.

Note: Each method may feature the service "requestRoutineResultsByLocalIdentifier/Address" after the routine has
been stopped. The selection of method and the implementation is the responsibility of the vehicle manufacturer
and system supplier.

The following is a brief description of method "A" and "B" shown in figure 6 and 7:

• Method "A": This method is based on the assumption that after a routine has been started by the client (tester) in
the server's (ECU's) memory the client (tester) shall be responsible to stop the routine.
The ECU routine shall be started in the server's (ECU's) memory some time between the completion of the
startRoutineByLocalIdentifier/Address request message and the completion of the first response message (if
"positive" based on the server's conditions).
The ECU routine shall be stopped in the server's (ECU's) memory some time after the completion of the
stopRoutineByLocalIdentifier/Address request message and the completion of the first response message (if
"positive" based on the server's conditions).
The client (tester) may request routine results after the routine has been stopped.

• Method "B": This method is based on the assumption that after a routine has been started by the client (tester) in
the server's (ECU's) memory that the server (ECU) shall be responsible to stop the routine.
The ECU routine shall be started in the server's (ECU's) memory some time between the completion of the
startRoutineByLocalIdentifier/Address request message and the completion of the first response message (if
"positive" based on the server's conditions).
The ECU routine shall be stopped any time as programmed or previously initialised in the server's (ECU's) memory.

Page: 116 of 160 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION SPECIFICATION

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Routine stopped by service

Start of Routine by service ECU routine running
"stopRoutineByLocalIdentifier"
"startRoutineByLocalIdentifier" "stopRoutineByAddress"
"startRoutineByAddress"

0 P3min P3max 0 P2min P2max/P3max 0 P3min P3max 0 P2min P2max/P3max 0 P3min P3max 0 P2min P2max/P3max 0 P3min

1
t t t t t t t

STRBLI STRBLIPR NEXT NR, RC $78 SPRBLI NR, RC $78

(SID $31) (SID $71) REQUEST (SID $7F) (SID $32) (SID $7F)

SPRBLIPR
POSITIVE
(SID $72)
RESPONSE

NR, RC = (x)
NR, RC = (x)
(SID $7F)
(SID $7F)
(x) = $21; $23
(x) = $21; $23
NR, RC != (x)
NR, RC != (x) (SID $7F)
(SID $7F)
(x) = $21; $23; $78
(x) = $21; $23; $78

NR, RC != (x)
(SID $7F)
(x) = $21; $23; $78

P3max 0 P2min P2max/P3max 0 P3min P3max

Request routine results by service:
1
"requestRoutineResultsByLocalId" t t t
"requestRoutineResultsByAddress"

RRRBLI NR, RC $78

(SID $33) (SID $7F)

RRRBLIPR
(SID $73)

NR, RC != $78
(SID $7F) Note: "!=" shall be interpreted as "NOT EQUAL"

Figure 6 - Example for Method A: Routine stopped by service

Page: 118 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

ECU routine running

Start of routine by service Routine stopped by time
"startRoutineByLocalIdentifier"
"startRoutineByAddress"

0 P3min P3max 0 P2min P2max/P3max 0 P3min P3max 0 P2min P2max/P3max 0 P3min

t t t t t
1

STRBLI NR, RC $78 NEXT NR, RC = (x)

(SID $31) (SID $7F) REQUEST (SID $7F)

(x) = $21

NR, RC != (x)
(SID $7F)

(x) = $21; $23; $78

POSITIVE
NR, RC = (x) RESPONSE
(SID $7F)
(x) = $23

STRBLIPR
(SID $71)

NR, RC != (x)
(SID $7F)
(x) = $21; $23; $78

P3max 0 P2min P2max/P3max 0 P3min P3max

Request routine results by service:

1
"requestRoutineResultsByLocalId" t t t
"requestRoutineResultsByAddress"

RRRBLI NR, RC $78

(SID $33) (SID $7F)

RRRBLIPR
(SID $73)

NR, RC != $78
(SID $7F)
Note: "!=" shall be interpreted as "NOT EQUAL"

Figure 7 - Example for Method B: Routine stopped by time

Page: 119 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

10.1 - StartRoutineByLocalIdentifier service

10.1.1 - Parameter definition
The parameter routineLocalIdentifier (RELI_) in the start/stopRoutineByLocalIdentifier and
requestRoutineResultsByLocalIdentifier request message identifies a server local routine.

Hex Description Cvt Mnemonic

00 reservedByDocument M RBD
This value shall be reserved by this document for future definition.
01 - F9 routineLocalIdentifier U RELI_
This range of values shall be used by the vehicle manufacturer to reference routines in the
server (ECU).
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value shall be reserved by this document for future definition.
Table 10.1.1 - Definition of routineLocalIdentifier values

• The parameter routineEntryOption (REYO_) is used by the startRoutineByLocalIdentifier and

startRoutineByAddress request message to specify the start conditions of the routine.
• The parameter routineEntryStatus (REYS_) is used by the startRoutineByLocalIdentifier and
startRoutineByAddress positive response message to give to the client additional information about the
status of the server following the start of the routine.
10.1.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 startRoutineByLocalIdentifier Request Service Id M 31 STRBLI
#2 routineLocalIdentifier M xx RELI_...
#3 routineEntryOption#1 U xx REYO_...
: : : : :
#n routineEntryOption#m U xx REYO_...
Table 10.1.2.1 - StartRoutineByLocalIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 startRoutineByLocalIdentifier Positive Response SId S 71 STRBLIPR
#2 routineLocalIdentifier M xx RELI_...
#3 routineEntryStatus#1 U xx REYS_...
: : : : :
#n routineEntryStatus#m U xx REYS_...
Table 10.1.2.2 - StartRoutineByLocalIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 startRoutineByLocalIdentifier Request Service Id M 31 STRBLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 10.1.2.3 - StartRoutineByLocalIdentifier Negative Response Message

Page: 120 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

10.1.3 - Message description

The startRoutineByLocalIdentifier service is used by the client to start a routine in the server's memory.
Part 3 Implementation Recommended Practice addition:
The ECU routine shall be started in the server's (ECU's) memory some time between the completion of the
startRoutineByLocalIdentifier request message and the completion of the first response message if the response message
is positive or negative with either response code '$23' (routineNotComplete) or '$78' (requestCorrectlyReceived-
ResponsePending).
The routines could either be tests that run instead of normal operating code or could be routines that are
enabled and executed with the normal operating code running. In particular in the first case, it might be
necessary to switch the server in a specific diagnostic mode using the startDiagnosticSession service or to
unlock the server using the securityAccess service prior to using the startRoutineByLocalIdentifier service.
The parameter routineEntryOption is user optional and shall be of any type and length defined within KWP
2000. Examples of routineEntryOptions are: timeToRun, startUpVariables, etc.
10.1.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1. A complete message flow
example is shown in section 10.5.4.
10.1.5 - Implementation example of "Input/output signal intermittent test routine"

10.1.5.1 - Test specification "Input/output signal intermittent test routine" (IOSITR)

This section specifies the test conditions to start a routine in the server (ECU) to continuously test (as fast as possible)
all input and output signals on intermittents while a technician would "wiggle" all wiring harness connectors of the
system under test. The routineLocalIdentifier references this routine by the routineLocalIdentifier '$01'.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]
10.1.5.2 - Message flow

STEP#1 startRoutineByLocalIdentifier(RELI_ IOSITR)

time Client (tester) Request Message Hex
P3 startRoutineByLocalId.Request[ 31
routineLocalId = inputOutputSignalIntermittentTestRoutine] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 startRoutineByLocalId.PosRsp[ 71 negativeResponse Service Identifier 7F
routineLocalId = inputOutputSignalIntermittent- 01 startRoutineByLocalId.ReqSId[ 31
TestRoutine] responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

10.2 - StartRoutineByAddress service

10.2.1 - Parameter definition
• The parameter routineAddress (RA_) in the start/stopRoutineByAddress and requestRoutine-
ResultsByAddress request message identifies a server local routine.
• The parameter routineEntryOption (REYO_) is defined in section 10.1.1.
• The parameter routineEntryStatus (REYS_) is defined in section 10.1.1.
10.2.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 startRoutineByAddress Request Service Id M 38 STRBA
#2 routineAddress (High Byte) M xx RA_
#3 routineAddress (Middle Byte) M xx
#4 routineAddress (Low Byte) M xx
#5 routineEntryOption#1 U xx REYO_...
: : : : :
#n routineEntryOption#m U xx REYO_...
Table 10.2.2.1 - StartRoutineByAddress Request Message

Page: 121 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 startRoutineByAddress Positive Response Service Id S 78 STRBAPR
#2 routineAddress (High Byte) M xx RA_
#3 routineAddress (Middle Byte) M xx
#4 routineAddress (Low Byte) M xx
#5 routineEntryStatus#1 U xx REYS_...
: : : : :
#n routineEntryStatus#m U xx REYS_...
Table 10.2.2.2 - StartRoutineByAddress Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 startRoutineByAddress Request Service Id M 38 STRBA
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 10.2.2.3 - StartRoutineByAddress Negative Response Message
10.2.3 - Message description
The startRoutineByAddress service is used by the client to start a routine in the server's memory.
Part 3 Implementation Recommended Practice addition:
The ECU routine shall be started in the server's (ECU's) memory some time between the completion of the
startRoutineByAddress request message and the completion of the first response message if the response message is
positive or negative with either response code '$23' (routineNotComplete) or '$78' (requestCorrectlyReceived-
ResponsePending).
The routines could either be tests that run instead of normal operating code or could be routines that are
enabled and executed with the normal operating code running. In particular in the first case, it might be
necessary to switch the server in a specific diagnostic mode using the startDiagnosticSession service or to
unlock the server using the securityAccess service prior to using the startRoutineByAddress service.
The parameter routineEntryOption is user optional and shall be of any type and length defined within KWP
2000. Examples of routineEntryOptions are: timeToRun, startUpVariables, etc.
10.2.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1.
A complete message flow example is shown in section 10.6.4.
10.2.5 - Implementation example of "Input/output signal intermittent test routine"

10.2.5.1 - Test specification "Input/output signal intermittent test routine" (IOSITR)

This section specifies the test conditions to start a routine at a specific address in the server's (ECU's) memory to
continuously test (as fast as possible) all input and output signals on intermittents while a technician would "wiggle" all
wiring harness connectors of the system under test. The routineAddress to access this routine shall be '$604720'.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]
10.2.5.2 - Message flow

STEP#1 startRoutineByAddress(RA_...)
time Client (tester) Request Message Hex
P3 startRoutineByAddress.Request[ 38
routineAddress { High Byte } 60
routineAddress { Middle Byte } 47
routineAddress { Low Byte }] 20

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 startRoutineByAddress.PosRsp[ 78 negativeResponse Service Identifier 7F
routineAddress{High Byte} 60 startRoutineByAddress.ReqSId[ 38
routineAddress { Middle Byte } 47 responseCode { refer to section 4.4 }] xx
routineAddress { Low Byte }] 20
return(main) return(responseCode)

Page: 122 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

10.3 - StopRoutineByLocalIdentifier service

10.3.1 - Parameter definition
• The parameter routineLocalIdentifier (RELI_) is defined in section 10.1.1.
• The parameter routineExitOption (RETO_) is used by the stopRoutineByLocalIdentifier and
stopRoutineByAddress request message to specify the stop conditions of the routine.
• The parameter routineExitStatus (RETS_) is used by the stopRoutineByLocalIdentifier and
stopRoutineByAddress positive response message to provide additional information to the client about the
status of the server after the routine has been stopped. Values are defined in the table below:

Hex Description Cvt Mnemonic

00-60 reservedByDocument M RBD
This range of values is reserved by this document.
61 normalExitWithResultsAvailable U NEWRA
62 normalExitWithoutResultsAvailable U NEWORA
63 abnormalExitWithResultsAvailable U AEWRA
64 abnormalExitWithoutResultsAvailable U AEWORA
65 - 7F reservedByDocument M RBD
This range of values is reserved by this document.
80 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This value is reserved by this document.
Table 10.3.1 - Definition of routineExitStatus values
10.3.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 stopRoutineByLocalIdentifier Request Service Id M 32 SPRBLI
#2 routineLocalIdentifier M xx RELI_...
#3 routineExitOption#1 U xx RETO_...
: : : : :
#n routineExitOption#m U xx RETO_...
Table 10.3.2.1 - StopRoutineByLocalIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 stopRoutineByLocalIdentifier Positive Response S 72 SPRBLIPR
#2 routineLocalIdentifier M xx RELI_...
#3 routineExitStatus#1 U xx RETS_...
: : : :
#n routineExitStatus#m U xx
Table 10.3.2.2 - StopRoutineByLocalIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 stopRoutineByLocalIdentifier Request Service Id M 32 SPRBLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 10.3.2.3 - StopRoutineByLocalIdentifier Negative Response Message

Page: 123 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

10.3.3 - Message description

The stopRoutineByLocalIdentifier service is used by the client to stop a routine in the server's memory
referenced by a routineLocalIdentifier. The parameter routineExitOption is user optional and shall be of any
type and length defined within KWP 2000.
Part 3 Implementation Recommended Practice addition:
The ECU routine shall be stopped in the server's (ECU's) memory some time after the completion of the
stopRoutineByLocalIdentifier/Address request message and the completion of the first response message if the response
message is positive or negative with either response code '$23' (routineNotComplete) or response code '$78'
(requestCorrectlyReceived-ResponsePending).
Note: The ECU routine shall be stopped any time as programmed or previously initialised in the server's (ECU's)
memory.
Examples of routineExitOption are: timeToExpireBeforeRoutineStops, variables, etc.The parameter
routineExitStatus is user optional and shall be of any type and length defined within KWP 2000. Examples of
routineExitStatus are: totalRunTime, results generated by the routine before stopped, etc.
10.3.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1. A complete message flow
example is shown in section 10.5.4.
10.3.5 - Implementation example of "Input/output signal intermittent test routine"

10.3.5.1 - Test specification "Input/output signal intermittent test routine" (IOSITR)

This section specifies the test conditions to stop a routine in the server (ECU) which has continuously tested (as fast as
possible) all input and output signals on intermittents while a technician would have been "wiggled" all wiring harness
connectors of the system under test. The routineLocalIdentifier references this routine by the routineLocalIdentifier
'$01'. Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]
10.3.5.2 - Message flow

STEP#1 stopRoutineByLocalIdentifier(RELI_IOSITR)
time Client (tester) Request Message Hex
P3 stopRoutineByLocalId.Request[ 32
routineLocalId = inputOutputSignalIntermittentTestRoutine] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 stopRoutineByLocalId.PosRsp[ 72 negativeResponse Service Identifier 7F
routineLocalId = inputOutputSignalIntermittent- 01 stopRoutineByLocalId.ReqSId[ 32
TestRoutine] responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

10.4 - StopRoutineByAddress service

10.4.1 - Parameter definition
• The parameter routineAddress (RA_) is defined in section 10.2.1.
• The parameter routineExitOption (RETO_) is defined in section 10.3.1.
• The parameter routineExitStatus (RETS_) is defined in section 10.3.1.
10.4.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 stopRoutineByAddress Request Service Id M 39 SPRBA
#2 routineAddress (High Byte) M xx RA_
#3 routineAddress (Middle Byte) M xx
#4 routineAddress (Low Byte) M xx
#5 routineExitOption#1 U xx RETO_...
: : : : :
#n routineExitOption#m U xx RETO_...
Table 10.4.2.1 - StopRoutineByAddress Request Message

Page: 124 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 stopRoutineByAddress Positive Response Service Id S 79 SPRBAPR
#2 routineAddress (High Byte) M xx RA_
#3 routineAddress (Middle Byte) M xx
#4 routineAddress (Low Byte) M xx
#5 routineExitStatus#1 U xx RETS_...
: : : : :
#n routineExitStatus#m U xx RETS_...
Table 10.4.2.2 - StopRoutineByAddress Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 stopRoutineByAddress Request Service Id M 39 SPRBA
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 10.4.2.3 - StopRoutineByAddress Negative Response Message
10.4.3 - Message description
The stopRoutineByAddress service is used by the client to stop a routine in the server's memory referenced
by a memoryAddress. The parameter routineExitOption is user optional and shall be of any type and length
defined within KWP 2000.
Part 3 Implementation Recommended Practice addition:
The ECU routine shall be stopped in the server's (ECU's) memory some time after the completion of the
stopRoutineByAddress request message and the completion of the first response message if the response message is
positive or negative with either response code '$23' (routineNotComplete) or response code '$78'
(requestCorrectlyReceived-ResponsePending).
Note: The ECU routine shall be stopped any time as programmed or previously initialised in the server's (ECU's)
memory.
Examples of routineExitOption are: timeToExpireBeforeRoutineStops, variables, etc.
The parameter routineExitStatus is user optional and shall be of any type and length defined within KWP
2000. Examples of routineExitStatus are: totalRunTime, results generated by the routine before stopped, etc.
10.4.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1. A complete message flow
example is shown in section 10.6.4.
10.4.5 - Implementation example of "Input/output signal intermittent test routine" (IOSITR)

10.4.5.1 - Test specification "Input/output signal intermittent test routine"

This section specifies the test conditions to stop a routine at a specific address in the server's (ECU's) memory to
continuously test (as fast as possible) all input and output signals on intermittents while a technician would "wiggle" all
wiring harness connectors of the system under test. The routineAddress to access this routine is '$604720'.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]

Page: 125 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

10.4.5.2 - Message flow

STEP#1 stopRoutineByAddress(RA_...)
time Client (tester) Request Message Hex
P3 stopRoutineByAddress.Request[ 39
routineAddress { High Byte } 60
routineAddress { Middle Byte } 47
routineAddress { Low Byte }] 20

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 stopRoutineByAddress.PosRsp[ 79 negativeResponse Service Identifier 7F
routineAddress {High Byte} 60 stopRoutineByAddress.ReqSId[ 39
routineAddress { Middle Byte } 47 responseCode { refer to section 4.4 }] xx
routineAddress { Low Byte }] 20
return(main) return(responseCode)

10.5 - RequestRoutineResultsByLocalIdentifier service

10.5.1 - Parameter definition
• The parameter routineLocalIdentifier (RELI_) is defined in section 10.1.1.
• The parameter routineResults (RRS_) is used by the requestRoutineResultsByLocalIdentifier and
requestRoutineResultsByAddress positive response message to provide the results (exit status
information) of the routine which has been stopped previously in the server.
10.5.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 requestRoutineResultsByLocalIdentifier Request Service Id M 33 RRRBLI
#2 routineLocalIdentifier M xx RELI_...
Table 10.5.2.1 - RequestRoutineResultsByLocalIdentifier Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 requestRoutineResultsByLocalIdentifier Pos. Resp. Service Id S 73 RRRBLIPR
#2 routineLocalIdentifier M xx RELI_...
#3 routineResults#1 M xx RRS_...
: : : : :
#n routineResults#m U xx RRS_...
Table 10.5.2.2 - RequestRoutineResultsByLocalIdentifier Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 requestRoutineResultsByLocalIdentifier Request Service Id M 33 RRRBLI
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 10.5.2.3 - RequestRoutineResultsByLocalIdentifier Negative Response Message
10.5.3 - Message description
The requestRoutineResultsByLocalIdentifier service is used by the client to request results (e.g. exit status
information) referenced by a routineLocalIdentifier and generated by the routine which was executed in the
server's memory. The parameter routineResults is user optional and shall be of any type and length defined
within KWP 2000. Based on the routineResults which may have been received in the
stopRoutineByLocalidentifier or stopRoutineByAddress positive response message (routineResults =
normal/abnormalExitWithResults) the requestRoutineResultsByLocalIdentifier service shall be used.
Example of routineResults: data collected by the ECU which could not be transmitted during routine
execution because of ECU performance limitations.
10.5.4 - Message flow example
time client (Tester) server (ECU)

Page: 126 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

P3 startRoutineByLocalId.Request[...]
P2 startRoutineByLocalId.PositiveResponse[...]
P3 stopRoutineByLocalId.Request[...]
P2 stopRoutineByLocalId.PositiveResponse[...]
P3 requestRoutineResultsByLocalId.Request[...]
P2 requestRoutineResultsByLocalId.PositiveResponse[...]
Table 10.5.4 - Message flow example of start/stopRoutineByLocalIdentifier service followed by a
requestRoutineResultsByLocalIdentifier service

The requestRoutineResultsByLocalIdentifier service shall only be used with physical addressing.

10.5.5 - Implementation example of "Input/output signal intermittent test routine"

10.5.5.1 - Test specification "Input/output signal intermittent test routine" (IOSITR)

This section specifies the test conditions to stop a routine in the server (ECU) which has continuously tested as fast as
possible all input and output signals on intermittents while a technician would have been "wiggled" at all wiring harness
connectors of the system under test. The routineLocalIdentifier to reference this routine is '$01'.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]
10.5.5.2 - Message flow

STEP#1 requestRoutineResultsByLocalIdentifier(RELI_IOSITR)
time Client (tester) Request Message Hex
P3 requestRoutineResultsByLocalId.Request[ 33
routineLocalId = inputOutputSignalIntermittentTestRoutine] 01

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 requestRoutineResultsByLocalId.PosRsp[ 73 negativeResponse Service Identifier 7F
routineLocalId = inputOutputSignalIntermittent- 01 requestRoutineResultsByLocalId.ReqSId[ 33
TestRoutine responseCode { refer to section 4.4 }] xx
routineResult#1 = inputSignal#1 57
routineResult#2 = inputSignal#2 33
: :
routineResult#m = inputSignal#m] 8F
return(main) return(responseCode)

Page: 127 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

10.6 - RequestRoutineResultsByAddress service

10.6.1 - Parameter definition
• The parameter routineAddress (RA_) is defined in section 10.2.1.
• The parameter routineResults (RRS_) is defined in section 10.5.1.
10.6.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 requestRoutineResultsByAddress Request Service Id M 3A RRRBA
#2 routineAddress (High Byte) M xx RA_
#3 routineAddress (Middle Byte) M xx
#4 routineAddress (Low Byte) M xx
Table 10.6.2.1 - RequestRoutineResultsByAddress Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 requestRoutineResultsByAddress Positive Response Service Id S 7A RRRBA
#2 routineAddress (High Byte) M xx RA_
#3 routineAddress (Middle Byte) M xx
#4 routineAddress (Low Byte) M xx
#5 routineResults#1 M xx RRS_...
: : : : :
#n routineResults#m U xx RRS_...
Table 10.6.2.2 - RequestRoutineResultsByAddress Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 Negative Response Service Id S 7F NR
#2 requestRoutineResultsByAddress Request Service Id M 3A RRRBA
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 10.6.2.3 - RequestRoutineResultsByAddress Negative Response Message
10.6.3 - Message description
The requestRoutineResultsByAddress service is used by the client to request results referenced by a
memoryAddress and generated by the routine which was executed in the server's memory.
The parameter routineResults is user optional and shall be of any type and length defined within KWP 2000.
Based on the routineResults which may have been received in the stopRoutineByLocalIdentifier or
stopRoutineByAddress positive response message (routineResults = normal/abnormalExitWithResults) the
requestRoutineResultsByAddress service shall be used.
Example of routineResults: data collected by the ECU which could not be transmitted during routine
execution because of ECU performance limitations.
10.6.4 - Message flow example
See message flow example of Physical Addressed Service in section 10.5.4.

Note: Above mentioned message flow example uses a localIdentifier instead of a memoryAddress.
10.6.5 - Implementation example of "Input/output signal intermittent test routine"

10.6.5.1 - Test specification "Input/output signal intermittent test routine" (IOSITR)

This section specifies the test conditions to stop a routine in the server (ECU) which has continuously tested (as fast as
possible) all input and output signals on intermittents while a technician would have been "wiggled" all wiring harness
connectors of the system under test. The routineAddress to access this routine is '$204720'.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]

Page: 128 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

10.6.5.2 - Message flow

STEP#1 requestRoutineResultsByAddress(RA_...)
time Client (tester) Request Message Hex
P3 requestRoutineResultsByAddress.Request[ 3A
routineAddress { High Byte } 20
routineAddress { Middle Byte } 47
routineAddress { Low Byte }] 20

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 requestRoutineResultsByAddress.PosRsp[ 7A negativeResponse Service Identifier 7F
routineAddress { High Byte } 20 requestRoutineResultsByAddress.ReqSId[ 3A
routineAddress { Middle Byte } 47 responseCode { refer to section 4.4 }] xx
routineAddress { Low Byte } 20
routineResult#1 = inputSignal#1 57
routineResult#2 = inputSignal#2 33
: :
routineResult#m = inputSignal#m] 8F
return(main) return(responseCode)

11 - Upload Download functional unit

The services provided by this functional unit are described in table 11:

Service name Description

RequestDownload The client requests the negotiation of a data transfer from the client to the server.
RequestUpload The client requests the negotiation of a data transfer from the server to the client.
TransferData The client transmits data to the server (download) or requests data from the server (upload).
RequestTransferExit The client requests the termination of a data transfer.
Table 11 - Upload Download functional unit

Page: 129 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

11.1 - RequestDownload service

11.1.1 - Parameter definition
Part 3 Implementation Recommended Practice addition:
• The transferRequestParameter (TRTP_) is used by the requestDownload request message. This parameter consists
of several other parameters which are required by the server (ECU) to prepare for the data transfer from the client
(tester) to the server (ECU). Each parameter is specified in detail:
• The parameter memoryAddress (MA_) is defined in section 7.3.1.
• The parameter dataFormatIdentifier (DFI_) is a one byte identifier. Each nibble shall be encoded separatedly. The
high nibble specifies the "compressionMethod" (CM_) and the low nibble specifies the "encryptingMethod"
(EM_). The use of a data compression method saves overall data transfer time if large amount of data shall be
transferred between client (tester) and server (ECU). Using an encoding method improves tamper protection. The
values are specified in the table below:

Hex Description of Compression and Encoding Method Cvt Mnemonic

0x unCompressed M UC
1x - Fx This range of values shall be reserved by the vehicle manufacturer / system supplier specific U C_...
Compression Methods
x0 unEncrypted M UE
x1 - xF vehicle manufacturer / system supplier specific Encrypting Methods U E_...
Table 11.1.1.1 - Definition of transferResponseParameter value
• The parameter unCompressedMemorySize (UCMS) is a three (3) byte value. This parameter shall be used by the
server (ECU) to compare the uncompressed memory size with the total amount of data transferred during the
requestTransferExit service. This increases the programming security.
• The transferResponseParameter (TREP_) "maxNumberOfBlockLength (MNROBL)" is used by the
requestDownload positive response message to inform the client (tester) how many data bytes shall be included in
each transferData request message from the client (tester). This parameter allows the client (tester) to adapt to the
receive buffer size of the server (ECU) before it starts transferring data to the server (ECU).
11.1.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 requestDownload Request Service Id M 34 RD
transferRequestParameter=[ TRTP_
#2 memoryAddress { High Byte } M xx MA_
#3 memoryAddress { Middle Byte } M xx MA_
#4 memoryAddress { Low Byte } M xx MA_
#5 dataFormatIdentifier M xx DFI_
#6 unCompressedMemorySize { High Byte } M xx UCMS
#7 unCompressedMemorySize { Middle Byte } M xx UCMS
#8 unCompressedMemorySize { Low Byte }] M xx UCMS
Table 11.1.2.1 - RequestDownload Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 requestDownload Positive Response Service Id M 74 RDPR
#2 transferResponseParameter=[maxNumberOfBlockLength] M xx TREP_
MNROBL
Table 11.1.2.2 - RequestDownload Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 requestDownload Request Service Id M 34 RD
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 11.1.2.3 - RequestDownload Negative Response Message

Page: 130 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

11.1.3 - Message description

The requestDownload service is used by the client to initiate a data transfer from the client to the server
(download). After the server has received the requestDownload request message the ECU shall take all
necessary actions to receive data before it sends a positive response message.
The parameters transferRequestParameter and transferResponseParameter are user optional and shall be
of any type and length defined within KWP 2000.
Example of transferRequestParameter: initialisation value(s) for data download.
Example of transferResponseParameter: maximum number of bytes per transferData message.
11.1.4 - Message flow example
See message flow example of Physical Addressed Service in section 5.3.1.1.
A complete message flow example is shown in section 11.4.4.
11.1.5 - Implementation example of "requestDownload"
Section 11.4.5.1 - Implementation example of "requestDownload, transferData, requestTransferExit" includes a
complete implementation example of requestDownload, followed by multiple transferData services and terminated by a
requestTransferExit service.
11.2 - RequestUpload service
11.2.1 - Parameter definition
• The transferRequestParameter (TRTP_) is used by the requestUpload request message. This parameter consists of
several other parameters which are required by the server (ECU) to prepare for the data transfer from the server
(ECU) to the client (tester). Each parameter is specified in detail:
• The parameter memoryAddress (MA_) is defined in section 7.3.1.
• The parameter dataFormatIdentifier (DFI_) is a one byte identifier. Each nibble shall be encoded separatedly. The
high nibble specifies the "compressionMethod" (CM_) and the low nibble specifies the "encryptingMethod"
(EM_). The use of a data compression method saves overall data transfer time if large amount of data shall be
transferred between server (ECU) and client (tester). Using an encoding method improves tamper protection. The
values are specified in the table below:

Hex Description of Compression and Encoding Method Cvt Mnemonic

0x unCompressed M UC
1x - Fx This range of values shall be reserved by the vehicle manufacturer / system supplier specific U C_...
Compression Methods
x0 unEncrypted M UE
x1 - xF vehicle manufacturer / system supplier specific Encrypting Methods U E_...
Table 11.2.1.1 - Definition of transferResponseParameter value

• The parameter uncompressedMemorySize (UCMS) is a three (3) byte value. This parameter shall be used by the
server (ECU) to compare the uncompressed memory size with the total amount of data transferred during the
requestTransferExit service.
• The transferResponseParameter (TREP_) "maxNumberOfBlockLength (MNROBL)" is used by the
requestUpload positive response message to inform the client (tester) how many data bytes shall be included in each
transferData positive response message from the server (ECU).

Page: 131 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

11.2.2 - Message data bytes

Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 requestUpload Request Service Id M 35 RU
transferRequestParameter=[ TRTP_
#2 memoryAddress { High Byte } M xx MA_
#3 memoryAddress { Middle Byte } M xx MA_
#4 memoryAddress { Low Byte } M xx MA_
#5 dataFormatIdentifier M xx DFI_
#6 uncompressedMemorySize { High Byte } M xx UCMS
#7 uncompressedMemorySize { Middle Byte } M xx UCMS
#8 uncompressedMemorySize { Low Byte }] M xx UCMS
Table 11.2.2.1 - RequestUpload Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 requestUpload Positive Response Service Id M 75 RUPR
#2 transferResponseParameter=[maxNumberOfBlockLength] M xx TREP_
MNROBL
Table 11.2.2.2 - RequestUpload Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 requestUpload Request Service Id M 35 RU
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 11.2.2.3 - RequestUpload Negative Response Message
11.2.3 - Message description
The requestUpload service is used by the client to initiate a data transfer from the server to the client
(upload). After the server has received the requestUpload request message the ECU shall take all necessary
actions to send data before it sends a positive response message.
The parameters transferRequestParameter and transferResponseParameter are user optional and shall be
of any type and length defined within KWP 2000.
Example of transferRequestParameter: initialisation value(s) for data upload.
Example of transferResponseParameter: maximum number of bytes per transferData message.
11.2.4 - Message flow example
See message flow example of Physically Addressed Service in section 5.3.1.1. A complete message flow
example is shown in section 11.4.4.
11.2.5 - Implementation example of "requestUpload"
Section 11.4.5.2 - Implementation example of "requestUpload, transferData, requestTransferExit" includes a
complete implementation example of requestUpload, followed by multiple transferData services and terminated by a
requestTransferExit service.

Page: 132 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

11.3 - TransferData service

11.3.1 - Parameter definition
• The parameter transferRequestParameter (TRTP_) in the transferData request message shall contain
parameter(s) which are required by the server to support the transfer of data. Format and length of this
parameter(s) are vehicle manufacturer specific. In addition, this document specifies one value which is
described in the table below:
• The parameter transferResponseParameter (TREP_) in the transferData positive response message
shall contain parameter(s) which are required by the client to support the transfer of data. Format and
length of this parameter(s) are vehicle manufacturer specific. In addition, this document specifies one
value which is described in the table below:
11.3.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 transferData Request Service Id M 36 TD
#2 transferRequestParameter#1 U xx TRTP_...
: : : : :
#n transferRequestParameter#m U xx TRTP_...
Table 11.3.2.1 - TransferData Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 transferData Positive Response Service Id M 76 TDPR
#2 transferResponseParameter#1 U xx TREP_...
: : : : :
#n transferResponseParameter#m U xx TREP_...
Table 11.3.2.2 - TransferData Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 transferData Request Service Id M 36 TD
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 11.3.2.3 - TransferData Negative Response Message
11.3.3 - Message description
The transferData service is used by the client to transfer data either from the client to the server (download)
or from the server to the client (upload). The data transfer direction is defined by the preceding
requestDownload or requestUpload service. If the client initiated a requestDownload the data to be
downloaded is included in the parameter(s) transferRequestParameter in the transferData request
message(s). The server may include the blockTransferComplete/NextBlock parameter as an
transferResponseParameter in the transferData positive response message. If the client initiated a
requestUpload the data to be uploaded is included in the parameter(s) transferResponseParameter in the
transferData positive response message(s). The client may include the blockTransferComplete/NextBlock
parameter as an transferRequestParameter in the transferData request message.
The user optional parameters transferRequestParameter and transferResponseParameter in the
transferData request and positive response messages shall be of any type and length defined within KWP
2000.
Example of transferRequestParameter and transferResponseParameter:
• For a download, the parameter transferRequestParameter could include the data to be transferred and the
parameter transferResponseParameter a checksum computed by the server.
• For an upload, the parameter transferRequestParameter parameter could include the address and
number of bytes to retrieve data and the parameter transferResponseParameter the uploaded data.
The transferData service shall only be terminated by the requestTransferExit service.

Page: 133 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Part 3 Implementation Recommended Practice addition:

The transferRequestParameters and transferResponseParameters shall not include obvious absolute server (ECU)
memoryAddress information to increase tamper protection!
11.3.4 - Message flow example
time client (Tester) server (ECU)
P3 transferData.Request#1[...]
P2 transferData.PositiveResponse#1[...]
P3 transferData.Request#2[...]
P2 transferData.PositiveResponse#2[...]
: : :
P3 transferData.Request#n[...]
P2 transferData.PositiveResponse#n[...]
Table 11.3.4 - Message flow example of transferData Service
11.3.5 - Implementation example of "transferData"
Section 11.4.5.1 - Implementation example of "requestDownload, transferData, requestTransferExit" includes a
complete implementation example of requestDownload, followed by multiple transferData services and terminated by a
requestTransferExit service.
Section 11.4.5.2 - Implementation example of "requestUpload, transferData, requestTransferExit" includes a
complete implementation example of requestUpload, followed by multiple transferData services and terminated by a
requestTransferExit service.

11.4 - RequestTransferExit service

11.4.1 - Parameter definition
• The parameter transferRequestParameter (TRTP_) is defined in section 11.1.1.
• The parameter transferResponseParameter (TREP_) in the requestTransferExit positive response
message defines the status of the server's data transfer exit status. Format and length of additional
parameters are vehicle manufacturer specific.
11.4.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 requestTransferExit Request Service Id M 37 RTE
#2 transferRequestParameter#1 U xx TRTP_...
: : : : :
#n transferRequestParameter#m U xx TRTP_...
Table 11.4.2.1 - RequestTransferExit Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 requestTransferExit Positive Response Service Id M 77 RTEPR
#2 transferResponseParameter#1 U xx TREP_...
: : : : :
#n transferResponseParameter#m U xx TREP_...
Table 11.4.2.2 - RequestTransferExit Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 requestTransferExit Request Service Id M 37 RTE
#3 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 11.4.2.3 - RequestTransferExit Negative Response Message

Page: 134 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

11.4.3 - Message description

This service is used by the client to terminate a data transfer between client and server. The user optional
parameters transferRequestParameter and transferResponseParameter in the requestTransferExit request
and positive response message shall be of any type and length defined within KWP 2000.
Example of transferRequestParameter: checksum request of entire data transferred.
Example of transferResponseParameter: checksum of entire data transferred.
11.4.4 - Message flow example
time client (Tester) server (ECU)
P3 requestUpload.Request[...]
P2 requestUpload.PositiveResponse[...]
P3 transferData.Request#1[...]
P2 transferData.PositiveResponse#1[...]
P3 transferData.Request#2[...]
P2 transferData.PositiveResponse#2[...]
: : :
P3 transferData.Request#n[...]
P2 transferData.PositiveResponse#n[...]
P3 requestTransferExit.Request[...]
P2 requestTransferExit.PositiveResponse[...]
Table 11.4.4 - Message flow example of requestUpload, multiple transferData services followed by a
requestTransferExit service

Note: The requestTransferExit service shall only be used with physical addressing.
11.4.5 - Implementation example of "requestTransferExit"

11.4.5.1 - Test specification "requestDownload, transferData, requestTransferExit"

11.4.5.1.1 - Implementation example of "requestDownload, transferData, requestTransferExit"

This section specifies the conditions to transfer data (download) from the client (tester) to the server (ECU).
The example consists of three (3) steps.
In the 1st step the client (tester) and the server (ECU) execute a requestDownload service. With this service the
following information is exchanged as parameters in the request and positive response message between client (tester)
and the server (ECU):

Data Parameter Name Data Parameter Data Parameter Description

Value(s) (Hex)
transferRequestParameter#1 - #3 $602000 memoryAddress (start) to download data to
transferRequestParameter#4 $11 dataFormatIdentifier (compressionMethod = $1x) (encryptingMethod =
$x1)
transferRequestParameter#5 - #7 $00FFFF uncompressedMemorySize = (64 Kbytes)
This parameter value shall be used by the server (ECU) to compare to the
actual number of bytes transferred during the execution of the
requestTransferExit service.
Table 11.4.5.1.1 - Definition of transferRequestParameter values

Data Parameter Name Data Parameter Data Parameter Description

Value(s) (Hex)
transferResponseParameter#1 $81 maximumNumberOfBlockLength:
(serviceId + 128 ECU data bytes = 129 data bytes)
Table 11.4.5.1.2 - Definition of transferResponseParameter value

Page: 135 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

In the 2nd step the client (tester) transfers 64 KBytes (number of transferData services with 128 data bytes can not be
calculated because the compression method and its compression ratio is supplier specific) of data to the flash memory
starting at memoryaddress $602000 to the server (ECU).
In the 3rd step the client (tester) terminates the data transfer to the server (ECU) with a requestTransferExit service.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]
11.4.5.1.2 - Message flow

STEP#1 requestDownload(TRTP_MA, TRTP_DFI, TRTP_UCMS)

time Client (tester) Request Message Hex
P3 requestDownload.Request[ 34
transferRequestParameter#1 = memoryAddress { High Byte } 60
transferRequestParameter#2= memoryAddress { Middle Byte } 20
transferRequestParameter#3= memoryAddress { Low Byte } 00
transferRequestParameter#4= dataFormatIdentifier { compressionMethod, encryptingMethod } 11
transferRequestParameter#5= uncompressedMemorySize { High Byte } 00
transferRequestParameter#6= uncompressedMemorySize { Middle Byte } FF
transferRequestParameter#7= uncompressedMemorySize { Low Byte }] FF

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 requestDownload.PosRsp[ 74 negativeResponse Service Identifier 7F
transferRspPara = maxNumberOfBlockLength] 81 requestDownload.ReqSId[ 34
responseCode { refer to section 4.4 }] xx
goto STEP#2 return(responseCode)

STEP#2 transferData#1(TRTP_..., ... , TRTP_...)

time Client (tester) Request Message Hex
P3 transferData.Request#1[ 36
transferData#1 = dataByte#2 xx
: :
transferData#128 = dataByte#129] xx

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 transferData.PosRsp#1 76 negativeResponse Service Identifier 7F
transferData.ReqSId[ 36
responseCode { refer to section 4.4 }] xx
goto STEP#2 transferData#m() return(responseCode)

:
STEP#2 transferData#m(TRTP_..., ... , TRTP_...)
time Client (tester) Request Message Hex
P3 transferData.Request#m[ 36
transferData#1 = dataByte#2 xx
: :
transferData#n-1 = dataByte#n] xx

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 transferData.PosRsp#m 76 negativeResponse Service Identifier 7F
transferData.ReqSId[ 36
responseCode { refer to section 4.4 }] xx
goto STEP#3 return(responseCode)

Page: 136 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

STEP#3 requestTransferExit()
time Client (tester) Request Message Hex
P3 requestTransferExit.Request 37

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 requestTransferExit.PosRsp 77 negativeResponse Service Identifier 7F
requestTransferExit.ReqSId[ 37
responseCode { refer to section 4.4 }] xx
return main() return(responseCode)

11.4.5.2 - Test specification "requestUpload, transferData, requestTransferExit"

11.4.5.2.1 - Implementation example of "requestUpload, transferData, requestTransferExit"

This section specifies the conditions to transfer data (upload) from a server (ECU) to the client (tester).
The example consists of three (3) steps. In the 1st step the client (tester) and the server (ECU) execute a requestUpload
service. With this service the following information is exchanged as parameters in the request and positive response
message between client (tester) and the server (ECU):

Data Parameter Name Data Parameter Data Parameter Description

Value(s) (Hex)
transferRequestParameter#1 - #3 $201000 memoryAddress (start) to upload data from
transferRequestParameter#4 $11 dataFormatIdentifier (compressionMethod = $1x) (encryptingMethod =
$x1)
transferRequestParameter#5 - #7 $000F00 uncompressedMemorySize = (511 bytes)
This parameter value shall indicate how many data bytes shall be transferred
and shall be used by the server (ECU) to compare to the actual number of
bytes transferred during execution of the requestTransferExit service.
Table 11.4.5.2.1 - Definition of transferRequestParameter values

Data Parameter Name Data Parameter Data Parameter Description

Value(s) (Hex)
transferResponseParameter#1 $81 maximumNumberOfBlockLength:
(serviceId + 128 ECU data bytes = 129 data bytes)
Table 11.4.5.2.2 - Definition of transferResponseParameter value

In the 2nd step the client (tester) transfers 511 data bytes (3 transferData services with 129 (128 ECU data bytes + 1
serviceId data byte) data bytes and 1 transferData service with 128 (127 ECU data bytes + 1 serviceId data byte) data
bytes from the external RAM starting at memoryaddress $201000 in the server (ECU). In the 3rd step the client (tester)
terminates the data transfer to the server (ECU) with a requestTransferExit service.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph]
11.4.5.2.2 - Message flow

STEP#1 requestUpload(TRTP_MA, TRTP_DFI, TRTP_UCMS)

time Client (tester) Request Message Hex
P3 requestUpload.Request[ 35
transferRequestParameter#1 = memoryAddress { High Byte } 20
transferRequestParameter#2 = memoryAddress { Middle Byte } 10
transferRequestParameter#3 = memoryAddress { Low Byte } 00
transferRequestParameter#4 = dataFormatIdentifier 11
transferRequestParameter#5 = uncompressedMemorySize { High Byte } 00
transferRequestParameter#6 = uncompressedMemorySize { Middle Byte } 0F
transferRequestParameter#7 = uncompressedMemorySize { Low Byte }] 00

Page: 137 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 requestUpload.PosRsp[ 75 negativeResponse Service Identifier 7F
transferRspPara=[maxNumberOfBlockLength] 81 requestUpload.ReqSId[ 35
responseCode { refer to section 4.4 }] xx
return(main) return(responseCode)

STEP#2 transferData#1-3()
time Client (tester) Request Message Hex
P3 transferData.Request#1-3 36

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 transferData.PosRsp#1-3[ 76 negativeResponse Service Identifier 7F
transferData#1 = dataByte#2 xx transferData.ReqSId[ 36
: : responseCode { refer to section 4.4 }] xx
transferData#128 = dataByte#129] xx
goto STEP#2 transferData#4() return(responseCode)

STEP#2 transferData#4()
time Client (tester) Request Message Hex
P3 transferData.Request#4 36

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 transferData.PosRsp#4[ 76 negativeResponse Service Identifier 7F
transferData#1 = dataByte#2 xx transferData.ReqSId[ 36
: : responseCode { refer to section 4.4 }] xx
transferData#127 = dataByte#128] xx
goto STEP#3 return(responseCode)

STEP#3 requestTransferExit()
time Client (tester) Request Message Hex
P3 requestTransferExit.Request 37

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 requestTransferExit.PosRsp 77 negativeResponse Service Identifier 7F
requestTransferExit.ReqSId[ 37
responseCode { refer to section 4.4 }] xx
return main() return(responseCode)

Page: 138 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

12 - Keyword Protocol 2000 extended services

12.1 - EscapeCode service
12.1.1 - Parameter definition
• The parameter manufacturerSpecific Service Identifier is defined as an extension of the service
identifiers specified in the document ISO 14230. The range of values is specified in the table below:

Hex Description Cvt Mnemonic

00 reservedByDocument M RBD
This range of values is reserved by this document for future definition.
01 - F9 vehicleManufacturerSpecific U VMS
This range of values is reserved for vehicle manufacturer specific use.
FA - FE systemSupplierSpecific U SSS
This range of values is reserved for system supplier specific use.
FF reservedByDocument M RBD
This range of values is reserved by this document for future definition.
Table 12.1.1 - Definition of vehicleManufacturer- and systemSupplierSpecific Service Identifier

• The parameter recordValue is defined in section 7.1.1.

12.1.2 - Message data bytes
Data Byte Parameter Name Cvt Hex Value Mnemonic
#1 escapeCode Request Service Id M 80 EC
#2 manufacturerSpecific Service Id M xx MSSID
#3 recordValue#1 U xx RV_...
: : : : :
#n recordValue#m U xx RV_...
Table 12.1.2.1 - EscapeCode Request Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 escapeCode Positive Response Service Id M C0 ECPR
#2 manufacturerSpecific Service Id M xx MSSID
#3 recordValue#1 U xx RV_...
: : : : :
#n recordValue#m U xx RV_...
Table 12.1.2.2 - EscapeCode Positive Response Message

Data Byte Parameter Name Cvt Hex Value Mnemonic

#1 negativeResponse Service Id S 7F NR
#2 escapeCode Request Service Id M 80 EC
#3 manufacturerSpecific Service Id M xx MSSID
#4 responseCode=[KWP2000ResponseCode { section 4.4 }] M xx=[00-FF] RC_...
Table 12.1.2.3 - EscapeCode Negative Response Message
12.1.3 - Message description
The escapeCode service is used by the client if none of the services specified in the document ISO 14230
can provide the function required by the vehicle manufacturer.

Page: 139 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

12.1.4 - Message flow example

time client (Tester) server (ECU)
P3 escapeCode.Request[...]
P2 escapeCode.PositiveResponse[...]
P3 escapeCode.Request[...]
P2 escapeCode.NegativeResponse[...]
P3 escapeCode.Request[...]
P2 escapeCode.PositiveResponse[...]
Table 12.1.4 - Message flow example of escapeCode service

See also message flow examples of Physically Addressed Service in section 5.3.1.1 and Functionally
Addressed Service in section 5.3.2.1.
12.1.5 - Implementation example of "escapeCode(manufacturerSpecificServiceId)"

12.1.5.1 - Test specification "escapeCode(manufacturerSpecificServiceId)"

This section specifies the test conditions to execute the escapeCode service with the manufacturerSpecific parameter
"escapeCode(manufacturerSpecificServiceId)".
12.1.5.2 - Message flow

STEP#1 escapeCode(manufacturerSpecificServiceId)
time Client (tester) Request Message Hex
P3 escapeCode.Request[ 80
manufacturerSpecificServiceId xx
recordValue#1 xx
: :
recordValue#m] xx

time Server (ECU) Positive Response Message Hex Server (ECU) Negative Response Message Hex
P2 escapeCode.PosRsp[ C0 negativeResponse Service Identifier 7F
manufacturerSpecificServiceId xx escapeCode.ReqSId[ 80
recordValue#1 xx manufacturerSpecificServiceId xx
: : responseCode { refer to section 4.4 }] xx
recordValue#m] xx
return(main) return(responseCode)

Page: 140 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

13 - Application examples
This section aims at showing with a real example how the Keyword Protocol 2000 services defined in this
document can be used to build diagnostic applications for a tester and one or multiple on-vehicle ECUs.

Note: ECM = Engine server (ECU); TCM = Transmission server (ECU)

13.1 - Description of the on-vehicle ECUs
Description of On-Vehicle Configuration
Two ECUs connected: Engine Control Module & Transmission Control Module
Multi Point Connection
Table 13.1.1 - On-vehicle configuration

List of communication functions supported by both servers (ECUs)

Fast Initialisation
Arbitration
Table 13.1.2 - Server (ECU) supported functions

Engine server (ECU) features

Re-programmable (Flash EPROM)
Requires security login with Seed & Key
Table 13.1.3 - Engine server (ECU) features

Server (ECU) supported services Engine Transmission Security Required

startCommunication YES YES NO
stopCommunication YES YES NO
accessTimingParameters (TPI: read, set) YES YES NO
testerPresent YES YES NO
startDiagnosticSession(defaultMode-StandardDiagnosticMode) YES YES NO
stopDiagnosticSession YES YES NO
readECUIdentification YES YES NO
readDiagnosticTroubleCodesByStatus YES YES NO
clearDiagnosticInformation YES YES NO
readDataByLocalIdentifer YES YES NO
dynamicallyDefineLocalIdentifier YES YES NO
securityAccess YES NO NO
startDiagnosticSession(ECUProgrammingMode) YES NO NO
requestDownload YES NO YES
transferData YES NO YES
startRoutineByLocalIdentifier YES NO NO
requestTransferExit YES NO YES
Table 13.1.4 - Engine and Transmission server (ECU) supported services

13.2 - Fast initialisation and physically addressed communication

• Both servers (ECUs) shall be initialized with the fast initialisation wake up pattern and startCommunication
request service.
• The client (tester) sends a functional readECUIdentification request service to retrieve all identification
data from each server (ECU).
• A functional readDiagnosticTroubleCodesByStatus request is used by the client (tester) to read the DTC's from the
servers (ECUs).

Page: 141 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

time client (Tester) server (ECU)

Fast Initialisation
startComm.Req {TGT=$FE; Functional Init. }
P2 startComm.PosRsp[KB1,KB2] {ECM}
P2 startComm.PosRsp[KB1,KB2] {TCM}
Normal Timing is enabled by the keybytes of the ECM
and TCM!
P3 readECUId.Req[identificationOption] {TGT=$FE}
P2 readECUId.PosRsp[identificationRecordValues] {TCM}
P2 readECUId.PosRsp[identificationRecordValues] {ECM}
P3 readDTCByStatus.Req[statusOfDTC,GroupOfDTC]
P2 {TGT=$FE} readDTCByStatus.PosRsp[NODTC,DTC#1,DTC#2] {ECM}
P2 readDTCByStatus.PosRsp[NODTC,DTC#3] {TCM}
Table 13.2 - Message flow of functional initialisation and communication

13.3 - ReadDataByLocalIdentifier response message and termination of communication

• The client (tester) reads specific data records identified by recordLocalIdentifiers from each ECU by sending
physically addressed readDataByLocalIdentifier requests.
• Then the client (tester) clears all diagnostic information by sending a clearDiagnosticInformation request message to
"all nodes" (all servers/ECUs).
• Then the communication with the TCM is stopped.

The communication with the TCM is stopped by a physically addressed stopCommunication request message.

time client (Tester) server (ECU)

P3 readDataByLocId.Req[RecLocId=10] {TGT=ECM}
P2 readDataByLocId.PosRsp[10,recordValues] {ECM}
P3 readDataByLocId.Req[RecLocId=03] {TGT=TCM}
P2 readDataByLocId.PosRsp[03,recordValues] {TCM}
P3 readDataByLocId.Req[RecLocId=01] {TGT=ECM}
P2 readDataByLocId.PosRsp[01,recordValues] {ECM}
P3 clearDiagInfo.Req[GroupOfDTC] {TGT=$FE}
P2 clearDiagnosticInformation.PosRsp {ECM}
P2 clearDiagnosticInformation.PosRsp {TCM}
P3 stopCommunication.Req {TGT=TCM}
P2 stopCommunication.PosRsp {TCM}
Table 13.3 - Message flow of single and multiple response messages

13.4 - SecurityAccess, data transfer and modification of timing parameters

Now the tester starts preparing for programming the ECM's memory by utilizing the following services:
• The tester sends a securityAccess request with the accessMode set to requestSeed to the ECM. The ECM responds
with the parameter Seed.
• The tester manipulates the Seed into a Key value and sends it to the ECM with the securityAccess request with the
accessMode set to sendKey. The ECM denies the request by sending a negative response with the responseCode set
to securityAccessDenied (tester has sent the wrong key). The client repeats the request. If the server (here ECM)
denies the security access again, both, the server (ECM) and the client start a ten (10) second timer which shall
expire before the next securityAccess is allowed.
• Now it is the client's responsibility to keep the communication alive. Therefore the tester must continuously send
testerPresent messages to the ECM with the parameter responseRequired set to YES. The number of testerPresent
services required depends on the timing parameter P3max. The tester stops sending testerPresent requests as soon as
the 10 second timer has expired. A new request is sent to the server.

Page: 142 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

time client (Tester) server (ECU)

P3 startDiagnosticSession.Req[ECUProgrammingMode]
P2 {TGT=ECM} startDiagnosticSession.PosRsp[ECUProgrammingMode]
{ECM}
P3 securityAcc.Req[requestSeed] {TGT=ECM}
P2 securityAcc.PosRsp[requestSeed,seed] {ECM}
P3 securityAcc.Req[requestSeed] {TGT=ECM} { tester has sent the wrong key! }
P2 securityAcc.PosRsp[requestSeed,seed] {ECM}
P3 securityAcc.Req[sendKey] {TGT=ECM} { tester has sent the wrong key! }
P2 securityAcc.NegRsp[securityAccessDenied] {ECM}
10 second timer starts!
P3 testerPresent.Req#1 {TGT=ECM}
P2 testerPresent.PosRsp#1 {ECM}
P3 testerPresent.Req#2 {TGT=ECM}
P2 testerPresent.PosRsp#2 {ECM}
: : :
P3 testerPresent.Req#n {TGT=ECM}
P2 testerPresent.PosRsp#n {ECM}
10 second timer expired!
Table 13.4.1 - Message flow of securityAccess
• The tester repeats the entire login procedure. It finally received a positive response with the parameter
securityAccessAllowed. Now the ECM is ready to execute diagnostic sessions which require a security login.
• The tester starts a programming session in the ECM which enables a new set of services which were not available in
the repairShop diagnostic mode.
• To speed up the upcoming data transfer the tester changes the timing parameters based on the ECMs communication
capabilities while in the ECUProgrammingMode. Therefore it sends the accessCommunication-Parameter request
service with the timingParameterIndex set to readLimits. The ECM responses with the internally stored timing
parameters "P2 - P4" used for fast data transfer and memory re-programming.
• The tester sends another accessTimingParameter request message with the timingParameterIndex set to setLimits.
The timing becomes active with the next request of the tester.
time client (Tester) server (ECU)
P3 securityAcc.Req[requestSeed] {TGT=ECM}
P2 securityAcc.PosRsp[requestSeed,seed] {ECM}
P3 securityAcc.Req[sendKey,key] {TGT=ECM}
P2 securityAcc.PosRsp[sendKey,securityAccessAllowed] {ECM}
P3 accessTimingPara.Req[readLimits] {TGT=ECM}
P2 accessTimingPara.PosRsp[readLimits,P2-P4] {ECM}
ECM sends fast programming P2...P4 timing values!
P3 accessTimingPara.Req[setPara,P2 - P4] {TGT=ECM}
P2 accessTimingPara.PosRsp[setPara] {ECM}
Fast programming timing P2...P4 is enabled!
Table 13.4.2 - Message flow of securityAccess, startDiagnosticSession and
accessTimingParameters
• The tester sends a requestDownload request with transferRequestParameters (e.g. memoryAddress,
dataFormatIdentifier, uncompressedMemorySize). The positive response message of the ECM includes the
transferResponseParameter maximumNumberOfBlockLength indicates to the tester that the ECM has accepted the
request and is ready for receiving download data.
• The transferData service is used to download a software routine from the tester to the ECM.
• The tester now sends the startRoutineByLocalIdentifier request message to start the routine which has been
downloaded before. This routine re-organizes the RAM of the ECM in order to free up additional memory space to
store further downloaded data.
• The tester uses multiple transferData services to transfer all FLASH EEPROM data to be re-programmed.
• When finished the tester terminates the data transfer by sending a requestTransferExit request message.
• Now the tester stops the current diagnostic session.
• Finally, the communication is terminated by the stopCommunication service.

Page: 143 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

time client (Tester) server (ECU)

P3 requestDownload.Req[TRQP_...] {TGT=ECM}
P2 requestDownload.PosRsp[TRSP_...] {ECM}
P3 transferData.Req[TRQP_..., ...]
P2 {TGT=ECM}
transferData.PosRsp {ECM}
P3 startRoutineByLocId.Req[RELI_.,REO_.]{TGT=ECM}
P2 startRoutineByLocId.PosRsp[RELI _...,RES_...] {ECM}
P3 transferData.Req[TRQP_..., ...] {TGT=ECM}
P2 transferData.PosRsp {ECM}
P3 transferData.Req[TRQP_..., ...] {TGT=ECM}
P2 transferData.PosRsp {ECM}
: : :
P3 transferData.Req[TRQP_..., ...] {TGT=ECM}
P2 transferData.PosRsp {ECM}
P3 requestTransferExit.Req {TGT=ECM}
P2 requestTransferExit.PosRsp {ECM}
P3 stopDiagnosticSession.Req {TGT=ECM}
P2 stopDiagnosticSession.PosRsp {ECM}
P3 stopCommunication.Req {TGT=ECM}
P2 stopCommunication.PosRsp {ECM}
Table 13.4.3 - Message flow of transferData and stopCommunication

14 - Implementation of ECU memory programming

14.1 - Standardised ECU memory programming
14.1.1 - Standardised ECU memory programming initialisation description
This section specifies the initialisation of a server (ECU) which is equipped with a re-programmable memory device and
shall be re-programmed. The initialisation is specified to allow for maximum data transfer rates and minimum timing to
reduce the overall memory programming time.
14.1.2 - Standardised ECU memory programming initialisation message flow
The message flow in table 14.1.2 shall always be implemented at the beginning of the programming session and shall
be standardised for all ECUs equipped with a re-programmable memory device. The message flow shown always
describes the positive path. If the server (ECU) reacts with a negative response message please refer to the message
description of this service for further detail.

Page: 144 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

time client (Tester) server (ECU)

Fast Initialisation
startCommunication.Req {ECM}
P2 {Normal or Extented Timing is enabled by the keybytes startCommunication.PosRsp[KB1,KB2] {ECM}
of the ECM} {Normal or Extented Timing is enabled by the keybytes of the
ECM}
P3 startDiagnosticSession.Req[ECUProgrammingMode]
P2 startDiagnosticSession.PosRsp[ECUProgrammingMode]
P3 securityAccess.Req#1[requestSeed]
P2 {Key = manipulated Seed} securityAccess.PosRsp#1[requestSeed,seed]
P3 securityAccess.Req#2[sendKey,key]
P2 securityAccess.PosRsp#2[sendKey,securityAccessAllowed]
P3 accessTimingPara.Req[readLimits]
P2 accessTimingPara.PosRsp[readLimits,P2-P4]
{tester calculates possible P2 - P4 timing values!} {ECM sends fast programming P2 - P4 timing values!}
P3 accessTimingPara.Req[setParameters,P2 - P4]
P2 accessTimingPara.PosRsp[setParameters]
{Fast programming timing P2 - P4 is enabled!} {Fast programming timing P2 - P4 is enabled!}
P3 accessTimingPara.Req[readActivePara]
P2 accessTimingPara.PosRsp[readActivePara,P2 - P4]
{Adapt to active timing in the server (ECU)!}
Table 14.1.2 - Standardised ECU memory programming initialisation message flow
14.1.3 - Example of ECU memory programming data transfer description
This section describes one of many possible examples of how to realize the data transfer from an off-board
programming device and an ECU. The concept described is based on a ECU software design which has all necessary
routines stored in its internal flash memory device. This requires the client (tester) to copy the "eraseRoutine" from a
protected flash sector to the EXRAM of the microcontroller. The "eraseRoutine" is then started by the client (tester)
with a startRoutineByLocalIdentifier request message. The request message may include a flash sector number as an
routineEntryOption. The advantage of erasing flash sectors separatedly by using multiple startRoutineByLocalIdentifier
services is that the time for erasing a flash sector is less time consuming and therefore the server (ECU) may not be
required to send negative response messages with the negative responseCode "requestCorrectlyReceived-
ResponsePending" as shown in the message flow example. The "programmingRoutine" is then copied from a protected
flash sector to the EXRAM of the microcontroller with a startRoutineByLocalIdentifier request message. Now the server
(ECU) is ready for programming the flash memory. The client (tester) sends a requestDownload request message to the
server (ECU) with optional ECU specific parameters or software to indicate the data transfer direction between the
client (tester) and server (ECU). Multiple transferData services may be required to send all data to the server (ECU).

Note: It is recommended to set the P2max timing parameter to a value which is greater than the time required to
program a block of data received via the transferData request message because this method does not cause the
server (ECU) to send one or multiple negative response messages with the responseCode
"requestCorrectlyReceived-ResponsePending" as shown in the message flow example to gain additional time
for completion of programming the block of data into the flash memory. When the client (tester) sends a
requestTransferExit request message the server (ECU) recognizes that no more data will be sent by the client
(tester). The client (tester) now is requested to initiate test routines in the server's (ECU's) memory which
calculate code and/or data checksum(s) over the data previously downloaded.

Page: 145 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

14.1.4 - Example of ECU memory programming data transfer message flow

The message flow in table 14.1.4 is an example
time client (Tester) server (ECU)
P3 startRoutineByLocalId.Req[RELI_...,REO_...]
{copy "eraseRoutine" from FLASH to EXRAM}
P2 startRoutineByLocalId.PosRsp[RELI_...,RES_...]
P3 startRoutineByLocId.Req[RELI_...,REO_...]
{start "eraseRoutine" in EXRAM}
P2 startRoutineByLocId.NegRsp[reqCorrectRcvd-RspPending]
{P2max is loaded with P3max=P2*} {P2max is loaded with P3max=P2*}
P2* {testerPresent service disabled} startRoutineByLocId.PosRsp[RELI_...,RES_...]
{P2max is reset to previous P2max value} {P2max is reset to previous P2max value}
{testerPresent service enabled}
P3 startRoutineByLocId.Req[RELI_...,REO_...]
{copy "programmingRoutine" to EXRAM}
P2 startRoutineByLocId.PosRsp[RELI_...,RES_...]
P3 requestDownload.Req[TRQP_...]
P2 requestDownload.PosRsp[TRSP_...]

time client (Tester) server (ECU)

P3 transferData.Req#1[TRQP_...,RECVAL...]
P2 transferData.NegRsp[reqCorrectRcvd-RspPending]
{P2max is loaded with P3max=P2*} {P2max is loaded with P3max=P2*}
{testerPresent service disabled}
P2* transferData.PosRsp#1[TRSP_...]
{P2max is reset to previous P2max value} {P2max is reset to previous P2max value}
{testerPresent service enabled}
: : :
P3 transferData.Req#n[TRQP_...,RECVAL...]
P2 transferData.NegRsp[reqCorrectRcvd-RspPending]
{P2max is loaded with P3max=P2*} {P2max is loaded with P3max=P2*}
{testerPresent service disabled}
P2* transferData.PosRsp#n[TRSP_...]
{P2max is reset to previous P2max value} {P2max is reset to previous P2max value}
{testerPresent service enabled}
P3 requestTransferExit.Req[TRQP_...]
P2 requestTransferExit.PosRsp[TRSP_...]
P3 startRoutineByLocId.Req[RELI_...,REO_...]
{start "dataChecksum" routine}
P2 startRoutineByLocId.PosRsp[RELI_...,RES_...]
OR
startRoutineByLocId.NegRsp[blockTransferDataCSError]
P3 startRoutineByLocId.Req[RELI_...,REO_...]
{start "codeChecksum" routine}
P2 startRoutineByLocId.PosRsp[RELI_...,RES_...]
OR
startRoutineByLocId.NegRsp[blockTransferDataCSError]
Table 14.1.4 - Example of ECU memory programming message flow

Page: 146 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

14.1.5 - Program Vehicle Identification Number (VIN) into ECU memory

The message flow in table 14.1.5 shows the programming of the VIN into the server's (ECUs) memory.

time client (Tester) server (ECU)

P3 writeDataByLocalIdentifier.Req[RLI=VIN,VIN]
P2 writeDataByLocalIdentifier.PosRsp[RLI=VIN]
Table 14.1.5 - Message flow to program the VIN into ECU memory
14.1.6 - Standardised ECU memory programming termination description
The client (tester) shall send a stopCommunication request message to the server (ECU) to terminate the
programmingSession. A stopDiagnosticSession service (user optional) may be exchanged prior to the
stopCommunication service. After the client (tester) has received a stopCommunication positive response message the
'K' line shall be in the 'idle' state.
14.1.7 - Standardised ECU memory programming termination message flow
The message flow in table 14.1.6 shall always be implemented at the end of the programming session and shall be
standardised for all server's (ECUs) equipped with a re-programmable memory device.

time client (Tester) server (ECU)

P3 stopDiagnosticSession.Req
P2 stopDiagnosticSession.PosRsp
P3 stopCommunication.Req
P2 stopCommunication.PosRsp
Table 14.1.7 - Standardised message flow at the end of the ECU memory programming session

Page: 147 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

14.2 - Example of ECU flash memory programming

14.2.1 - Example of timing analysis of ECU flash memory programming
[ms] Hex Header Description

; startCommunication!
49.12 <81> F - H01 - address mode: 10 - With address Info; Physical addressing; with Length
5.09 <11> T - H02 - target address
5.08 <F1> S - H03 - source address
5.09 <81> D - 001- SCR - startCommunication request service identifier
5.08 <04> C - CS - checksum

25.75 <80> F - H01 - address mode: 10 - with address Info, Physical addressing; with Length
0.00 <F1> T - H02 - target address
0.00 <11> S - H03 - source address
0.00 <03> L - H04 - length byte
0.09 <C1> D - 001 - SCRPR - startCommunication positive response service identifier
0.09 <6B> D - 002 - Keybyte 1: 0x6B ->
0.09 <8F> D - 003 - Keybyte 2: 0x8F -> Protocol: Keyword 2027 (Normal Timing=default Timing)
0.00 <40> C - CS - checksum

; startDiagnosticSession(ECUProgrammingMode)!
60.16 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
5.09 <11> T - H02 - target address
5.09 <F1> S - H03 - source address
5.08 <10> D - 001 - STDS - startDiagnosticSession request service identifier
5.09 <85> D - 002 - DCM_ECUPM = 0x85: ECUProgrammingMode
5.08 <19> C - CS - checksum

26.26 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.00 <F1> T - H02 - target address
0.00 <11> S - H03 - source address
0.00 <02> L - H04 - length byte
0.09 <50> D - 001 - STDS - startDiagnosticSession positive response service identifier
0.09 <85> D - 002 - DCM_ECUPM = 0x85: ECUProgrammingMode
0.06 <57> C - CS - checksum

Note: Default timing is active because of previous startDiagnosticSession!

; securityAccess (requestSeed)!
61.36 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
5.09 <11> T - H02 - target address
5.09 <F1> S - H03 - source address
5.08 <27> D - 001 - SA - securityAccess request service identifier
5.09 <01> D - 002 - ACCMODE = 0x01: requestSeed
5.08 <AC> C - CS - checksum

25.57 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.07 <F1> T - H02 - target address
0.09 <11> S - H03 - source address
0.05 <04> L - H04 - length byte
0.09 <67> D - 001 - SAPR - securityAccess positive response service identifier
0.09 <01> D - 002 - ACCMODE = 0x01: requestSeed
0.09 <12> D - 003 - SEED High-Byte: 0x12
0.09 <34> D - 004 - SEED Low-Byte: 0x34 SEED = 0x1234
0.06 <34> C - CS - checksum

Page: 148 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

[ms] Hex Header Description

; securityAccess (sendKey)!
68.36 <84> F - H01 - address mode: 10 - with address Info, Physical addressing
5.09 <11> T - H02 - target address
5.09 <F1> S - H03 - source address
5.08 <27> D - 001 - SA - securityAccess request service identifier
5.09 <02> D - 002 - ACCMODE = 0x02: sendKey
5.08 <56> D - 003 - KEY High-Byte: 0x56
5.09 <78> D - 004 - KEY Low-Byte: 0x78 Key = 0x5678
5.09 <7D> C - CS - checksum

25.38 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.08 <F1> T - H02 - target address
0.05 <11> S - H03 - source address
0.09 <03> L - H04 - length byte
0.09 <67> D - 001 - SAPR - securityAccess positive response service identifier
0.07 <02> D - 002 - ACCMODE = 0x02: sendKey
0.09 <34> D - 003 - SACCSTAT: 0x34 - Security Access Allowed
0.08 <22> C - CS - checksum

; accessTimingParameter (read limits of possible values)!

72.28 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
5.09 <11> T - H02 - target address
5.08 <F1> S - H03 - source address
5.09 <83> D - 001 - ATP - accessTimingParameters request service identifier
5.09 <00> D - 002 - TPI = 0x00: read limits of possible values
5.08 <07> C - CS - checksum

25.87 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.08 <F1> T - H02 - target address
0.06 <11> S - H03 - source address
0.08 <07> L - H04 - length byte
0.09 <C3> D - 001 - ATPPR - accessTimingParameters positive response service identifier
0.09 <00> D - 002 - TPI = 0x00: read limits of possible values
0.09 <14> D - 003 - P2min = 0x14 = 10.00ms (0.5ms Res.)
0.09 <28> D - 004 - P2max = 0x28 = 1000.00ms ( 25ms Res.)
0.09 <0A> D - 005 - P3min = 0x0A = 5.00ms (0.5ms Res.)
0.09 <28> D - 006 - P3max = 0x28 = 10000.00ms (250ms Res.)
0.09 <08> D - 007 - P4min = 0x08 = 4.00ms (0.5ms Res.)
0.09 <C2> C - CS - checksum

; accessTimingParameter (set timing parameter values)!

66.80 <87> F - H01 - address mode: 10 - with address Info, Physical addressing
5.08 <11> T - H02 - target address
5.09 <F1> S - H03 - source address
5.08 <83> D - 001 - ATP - accessTimingParameters request service identifier
5.09 <03> D - 002 - TPI = 0x03: set parameters
5.09 <14> D - 003 - P2min = 0x14 = 10.00ms (0.5ms Res.)
5.08 <28> D - 004 - P2max = 0x28 = 1000.00ms ( 25ms Res.)
5.09 <0A> D - 005 - P3min = 0x0A = 5.00ms (0.5ms Res.)
5.08 <28> D - 006 - P3max = 0x28 = 10000.00ms (250ms Res.)
5.09 <08> D - 007 - P4min = 0x08 = 4.00ms (0.5ms Res.)
5.09 <85> C - CS - checksum

Page: 149 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

[ms] Hex Header Description

25.60 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.07 <F1> T - H02 - target address
0.08 <11> S - H03 - source address
0.09 <02> L - H04 - length byte
0.09 <C3> D - 001 - ATPPR - accessTimingParameters positive response service identifier
0.09 <03> D - 002 - TPI = 0x03: set parameters
0.07 <4A> C - CS - checksum

; accessTimingParameter (read active timing parameter values)!

70.35 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.12 <83> D - 001 - ATP - accessTimingParameters request service identifier
4.13 <02> D - 002 - TPI = 0x02: read active parameters
4.13 <09> C - CS - checksum
10.05 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.07 <F1> T - H02 - target address
0.08 <11> S - H03 - source address
0.09 <07> L - H04 - length byte
0.09 <C3> D - 001 - ATPPR - accessTimingParameters positive response service identifier
0.09 <02> D - 002 - TPI = 0x02: read active parameters
0.09 <14> D - 003 - P2min = 0x14 = 10.00ms (0.5ms Res.)
0.09 <28> D - 004 - P2max = 0x28 = 1000.00ms ( 25ms Res.)
0.09 <0A> D - 005 - P3min = 0x0A = 5.00ms (0.5ms Res.)
0.09 <28> D - 006 - P3max = 0x28 = 10000.00ms (250ms Res.)
0.09 <08> D - 007 - P4min = 0x08 = 4.00ms (0.5ms Res.)
0.09 <C4> C - CS - checksum

; copy erase flash routine!

71.30 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <31> D - 001 - STRBLI - startRoutineByLocalIdentifier request service identifier
4.12 <01> D - 002 - routineLocalIdentifier for copy "eraseRoutine" to EXRAM of µC
4.13 <B6> C - CS - checksum

10.06 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.07 <F1> T - H02 - target address
0.06 <11> S - H03 - source address
0.08 <02> L - H04 - length byte
0.09 <71> D - 001- STRBLIPR - startRoutineByLocalIdentifier positive response service identifier
0.09 <01> D - 002 - routineLocalIdentifier for copy "eraseRoutine" to EXRAM of µC
0.09 <F6> C - CS - checksum

Page: 150 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

[ms] Hex Header Description

; start erase flash routine!

79.35 <83> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <31> D - 001- STRBLI - startRoutineByLocalIdentifier request service identifier
4.12 <02> D - 002 - routineLocalIdentifier to start "eraseRoutine"
4.13 <1E> D - 003 - flash sector number
4.12 <D6> C - CS - checksum

10.03 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.00 <F1> T - H02 - target address
0.09 <11> S - H03 - source address
0.08 <03> L - H04 - length byte
0.09 <7F> D - 001 - NR - negative response service identifier
0.09 <31> D - 002 - STRBLI - startRoutineByLocalIdentifier request service identifier
0.09 <78> D - 003 - *** requestCorrectlyReceived-ResponsePending
0.00 <AD> C - CS - checksum

2407.13 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.08 <F1> T - H02 - target address
0.07 <11> S - H03 - source address
0.09 <02> L - H04 - length byte
0.09 <71> D - 001 - STRBLIPR - startRoutineByLocalIdentifier positive response service identifier
0.09 <02> D - 002 - routineLocalIdentifier to start "eraseRoutine"
0.09 <1E> D - 003 - flash sector number
0.08 <15> C - CS - checksum

; copy program flash routine!

71.80 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.12 <31> D - 001 - STRBLI - startRoutineByLocalIdentifier request service identifier
4.13 <03> D - 002 - routineLocalIdentifier to copy "programmingRoutine" to EXRAM of µC
4.12 <B8> C - CS - checksum
11.43 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.08 <F1> T - H02 - target address
0.08 <11> S - H03 - source address
0.09 <02> L - H04 - length byte
0.09 <71> D - 001 - STRBLIPR - startRoutineByLocalIdentifier positive response service identifier
0.09 <03> D - 002 - routineLocalIdentifier to copy "programmingRoutine" to EXRAM of µC
0.08 <F8> C - CS - checksum

; requestDownload!
43.28 <81> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.03 <34> D - 001 - RD - requestDownload request service identifier
4.03 <60> D - 002 - memoryAddress
4.03 <20> D - 003 - memoryAddress
4.03 <00> D - 004 - memoryAddress
4.03 <11> D - 005 - dataFormatIdentifier
4.03 <00> D - 006 - uncompressedMemorySize
4.03 <00> D - 007 - uncompressedMemorySize
4.03 <10> D - 008 - uncompressedMemorySize (16 data bytes)
4.13 <58> C - CS - checksum

Page: 151 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

[ms] Hex Header Description

10.04 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.09 <F1> T - H02 - target address
0.08 <11> S - H03 - source address
0.09 <01> L - H04 - length byte
0.09 <74> D - 001 - RDPR - requestDownload positive response service identifier
0.08 <F7> C - CS - checksum

; transferData!
114.32 <91> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.12 <36> D - 001 - TD - transferData request service identifier
4.13 <40> D - 002 - some data to program into flash memory!
4.12 <80> D - 003 -
4.13 <00> D - 004 -
4.13 <00> D - 005 -
4.12 <01> D - 006 -
4.13 <02> D - 007 -
4.12 <03> D - 008 -
4.13 <04> D - 009 -
4.13 <05> D - 010 -
4.12 <06> D - 011 -

4.13 <07> D - 012 -

4.12 <08> D - 013 -
4.13 <09> D - 014 -
4.12 <0A> D - 015 -
4.13 <0B> D - 016 -
4.13 <0C> D - 017 -
4.12 <D7> C - CS - checksum

10.92 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.09 <F1> T - H02 - target address
0.09 <11> S - H03 - source address
0.09 <04> L - H04 - length byte
0.09 <76> D - 001 - TDPR - transferData positive response service identifier
0.09 <40> D - 002 - some data which are programmed into flash memory are returned!
0.09 <80> D - 003 -
0.09 <00> D - 004 -
0.09 <BC> C - CS - checksum

; requestTransferExit!
44.32 <81> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <37> D - 001 - RTE - requestTransferExit request service identifier
4.12 <BA> C - CS - checksum

10.06 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.09 <F1> T - H02 - target address
0.09 <11> S - H03 - source address
0.09 <01> L - H04 - length byte
0.09 <77> D - 001 - RTEPR - requestTransferExit positive response service identifier
0.09 <FA> C - CS - checksum

Page: 152 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

[ms] Hex Header Description

; test checksum of data programmed into flash memory!

71.30 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <31> D - 001 - STRBLI - startRoutineByLocalIdentifier request service identifier
4.12 <06> D - 002 - routineLocalIdentifier to start "dataChecksumRoutine"
4.13 <BB> C - CS - checksum

10.06 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.09 <F1> T - H02 - target address
0.09 <11> S - H03 - source address
0.09 <02> L - H04 - length byte
0.09 <71> D - 001 - STRBLIPR - startRoutineByLocalIdentifier positive response service identifier
0.09 <06> D - 002 - routineLocalIdentifier to start "dataChecksumRoutine"
0.09 <FB> C - CS - checksum

; test checksum of code programmed into flash memory!

71.30 <82> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <31> D - 001 - STRBLI - startRoutineByLocalIdentifier request service identifier
4.12 <07> D - 002 - routineLocalIdentifier to start "codeChecksumRoutine"
4.13 <6C> C - CS - checksum

10.06 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.07 <F1> T - H02 - target address
0.08 <11> S - H03 - source address
0.08 <02> L - H04 - length byte
0.09 <71> D - 001 - STRBLIPR - startRoutineByLocalIdentifier positive response service identifier
0.09 <07> D - 002 - routineLocalIdentifier to start "codeChecksumRoutine"
0.08 <FC> C - CS - checksum

; write VIN into ECU memory!

20.55 <93> F - H01 - address mode: 10 - with address Info, Physical addressing
4.02 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <3B> D - 001 - WDBLI - writeDataByLocalIdentifier request service identifier
4.02 <90> D - 002 - recordLocalIdentifier = VIN
4.00 <57> D - 003 - 1st character of VIN: 'W'
4.04 <30> D - 004 - 2nd character of VIN: '0'
4.05 <4C> D - 005 - 3rd character of VIN: 'L'
4.02 <30> D - 006 - 4th character of VIN: '0'
4.03 <30> D - 007 - 5th character of VIN: '0'
4.02 <30> D - 008 - 6th character of VIN: '0'
4.03 <30> D - 009 - 7th character of VIN: '0'
4.02 <34> D - 010 - 8th character of VIN: '4'
4.02 <33> D - 011 - 9th character of VIN: '3'
4.02 <4D> D - 012 - 10th character of VIN: 'M'
4.03 <42> D - 013 - 11th character of VIN: 'B'
4.02 <35> D - 014 - 12th character of VIN: '5'
4.04 <34> D - 015 - 13th character of VIN: '4'
4.05 <31> D - 016 - 14th character of VIN: '1'
4.02 <33> D - 017 - 15th character of VIN: '3'
4.02 <32> D - 018 - 16th character of VIN: '2'
4.02 <36> D - 019 - 17th character of VIN: '6'
4.22 <1E> C - CS - checksum

Page: 153 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

[ms] Hex Header Description

10.08 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.09 <F1> T - H02 - target address
0.09 <11> S - H03 - source address
0.09 <02> L - H04 - length byte
0.09 <7B> D - 001 - WDBLI - writeDataByLocalIdentifier positive response service identifier
..0.09 <90> D - 002 - recordLocalIdentifier = VIN
0.09 <8F> C - CS - checksum

; stopDiagnosticSession!
20.55 <81> F - H01 - address mode: 10 - with address Info, Physical addressing
4.02 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <20> D - 001 - SPDS - stopDiagnosticSession request service identifier
4.12 <A3> C - CS - checksum

10.08 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.08 <F1> T - H02 - target address
0.08 <11> S - H03 - source address
0.08 <01> L - H04 - length byte
0.09 <60> D - 001 - SPRPR - stopDiagnosticSession positive response service identifier
0.09 <E3> C - CS - checksum

Note: Default timing is active because of previous stopDiagnosticSession!

; stopCommunication!
60.85 <81> F - H01 - address mode: 10 - with address Info, Physical addressing
4.03 <11> T - H02 - target address
4.03 <F1> S - H03 - source address
4.13 <82> D - 001 - SPR - stopCommunication request service identifier
4.12 <05> C - CS - checksum

10.07 <80> F - H01 - address mode: 10 - with address Info, Physical addressing
0.00 <F1> T - H02 - target address
0.00 <11> S - H03 - source address
0.00 <01> L - H04 - length byte
0.09 <C2> D - 001 - SPRPR - stopCommunication positive response service identifier
0.09 <45> C - CS - checksum

; end of script file!

Page: 154 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

15 - Revision History Log

Date Section Description of change Requested
by
30OCT96 Title page Cancelled "Part: 3" AG1
30OCT96 " Changed spec. name from "Implementation Specification" to "Implementation of G. Feiter GM
Diagnostic Services Recommended Practice Specification" STG-IO
30OCT96 2 Updated release date of ISO 142xx:1996 G. Feiter GM
STG-IO
30OCT96 2 ISO 14230-4:1996 Road Vehicles - Diagnostic Systems G. Feiter
Keyword Protocol 2000 Part 4: Requirements for Emission Related Systems GM STG-IO
30OCT96 5.2 Cancelled: J. Hilger
Siemens
• Only those server(s) which are initialized and in a diagnostic session which support
the service request message shall send a response message.
30OCT96 6.6.1 1st bullet: changed range from "$90 - $9F" to "$82 - $9F" AG1
30OCT96 Table 6.6.1 Modified range of values as in section 6.6.1; AG1
Cancelled sentence: "These data are ... of the vehicle manufacturer."
30OCT96 Table 6.6.1 added line in table: $82 - $85 reservedByDocument AG1
30OCT96 Table 6.6.1 Changed value in 1st column from $82 to $86; AG1
Added last sentence of definition to definition of vehicleManufacturerSpecific,
systemSupplierSpecific, and idoption $99 definition
30OCT96 all tables Changed Cvt (Convention) in all tables from "M" to "U" for AG1
vehicleManufacturerSpecific and systemSupplierSpecific
30OCT96 table Cancelled sentence "previous 2 DTC bytes include DTC number;" in DTCStorageState Kalweit
8.2.1.2.3 table line BMW
30OCT96 8.3.3 If the server(s) does not (do not) have any DTC with status information stored it (they) Hilger,
shall set the parameter numberOfDTC to noDTCStored ($00). Siemens
30OCT96 " Part 3 Implementation Specification addition: Hilger,
This service shall be used to report DTC location and symptom(s) (environmental Siemens
parameter conditions when the DTC is identified) as systemSupplierData.
30OCT96 8.3.5.1 8.3.5.1 - Test specification readStatusOfDiagnostic-TroubleCodes Hilger,
In this example the groupOfDTC parameter is set to: "requestByDTC" = P0120: Siemens
Throttle Position Circuit Malfunction.
30OCT96 Table 8.4.1.2 Renumbered: Table 8.4.1.3 - Definition of recordAccessMethodIdentifier values Feiter, GM
(cont’d) STG-IO
18NOV96 Table 8.4.1.2 Renumbered: Table 8.4.1.4 - Definition of recordIdentification values Feiter, GM
STG-IO
18NOV96 all relevant Changed/corrected range of “Undefined DTCs” from “C000 - C999” to “ C000 - F999” Preuschoff,
tables MB
05DEC96 Table 7.6.2.1 Corrected mnemonic WDBLI to WDBCI in request, pos. and neg. response message Walter, GM
STG-IO
05DEC96 Table 8.4.2.2 Corrected mnemonic RFFDNR to RFFDPR in pos. response message Walter, GM
STG-IO
05DEC96 Table 13.4.2 Corrected accessCommunicationPara to accessTimingPara; I recommend to perform a
Walter, GM
replace by MS-Word! STG-IO
05DEC96 Table 14.4.1 Corrected accessCommunicationPara to accessTimingPara Walter, GM
STG-IO
05DEC96 Table 14.4.1 Corrected accessCommunicationPara to accessTimingPara Walter, GM
STG-IO
05DEC96 entire doc Replaced “Implementation Specification” with “Implementation Recommended Feiter, GM
Practice” STG-IO

Page: 155 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Date Section Description of change Requested

by
05DEC96 entire doc Replaced “Data Link Layer Specification” with “Data Link Layer Recommended Feiter, GM
Practice” STG-IO
05DEC96 8.2.1.2 Added to this section: DTC number decoding according to SAE J2012: Feiter, GM
STG-IO
05DEC96 section Old: Kalweit,
8.2.1.2 The parameter listOfDTCAndStatus (LODTCAS_...) is used by the BMW
second bullet readDiagnosticTroubleCodesByStatus positive response message to report diagnostic
trouble codes (DTCs) and status information or those DTCs which have been identified
at the time of the request, independent of their status. The listOfDTCAndStatus
parameter is of the type "record" and shall include multiple DTCs with status
information if DTCs have been identified by the server(s) (ECU(s)). If no DTC has been
identified (the parameter numberOfDTC = '$00') by the server(s) (ECU(s)) at the time
of the request the server(s) (ECU(s)) shall not include the parameter
listOfDTCAndStatus in the positive response message. Refer to table 8.2.2.2 for more
detailed information.
New:
The parameter listOfDTCAndStatus (LODTCAS_...) is used by the
readDiagnosticTroubleCodesByStatus positive response message to report diagnostic
trouble codes (DTCs) and status information. If the parameter statusOfDTC in the
request message is set to “requestIdentifiedDTC And Status”, the ECU reports those
DTCs which, have been identified at the time of the request, independent of their status.
If the parameter statusOfDTC in the request message is set to
“requestSupportedDTCAndStatus”, the ECUreports all supported DTCs, independent
of their status. The listOfDTCAndStatus parameter is of the type "record" and shall
include multiple DTCs with status information if DTCs have been identified by the
server(s) (ECU(s)). If no DTC has been identified (the parameter numberOfDTC =
'$00') by the server(s) (ECU(s)) at the time of the request and the parameter
statusOfDTC in the request message is set to “requestIdentifiedDTCAndStatus” the
server(s) (ECU(s)) shall not include the parameter listOfDTCAndStatus in the positive
response message. Refer to table 8.2.2.2 for more detailed information.
05DEC96 8.2.3 Old: Kalweit,
If the server(s) does not (do not) have any DTC with status information stored it (they) BMW
shall set the parameter numberOfDTCStored to "$00". This causes the server(s) not to
include DTC(s) and status information in the parameter listOfDTCAndStatus in the
positive response message.
Part 3 Implementation Recommended Practice addition:
The readDiagnosticTroubleCodesByStatus service is used by the client (tester) to read
diagnostic trouble codes by status from the server's (ECU's) memory. The parameter
groupOfDTC shall be either set to requestByFunction or requestByDTC in the request
message. The server(s) (ECU(s)) shall only report DTC(s) with status information based
on the content of the groupOfDTC parameter value selected by the client (tester).
Note: The DTCs shall be reported by the server(s) (ECU(s)) in the same sequence
as they have been identified/detected!

Page: 156 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Date Section Description of change Requested

by
05DEC96 8.2.3 New: Kalweit,
Part 3 Implementation Recommended Practice addition: BMW
If the server(s) does not (do not) have any DTC with status information stored and the
parameter statusOfDTC in the request message is not equal to
“requestSupportedDTCAndStatus” it (they) shall set the parameter
numberOfDTCStored to "$00". This causes the server(s) not to include DTC(s) and
status information in the parameter listOfDTCAndStatus in the positive response
message.
The readDiagnosticTroubleCodesByStatus service is used by the client (tester) to read
diagnostic trouble codes by status from the server's (ECU's) memory. The parameter
groupOfDTC shall be either set to requestByFunction or requestByDTC in the request
message. The server(s) (ECU(s)) shall only report DTC(s) with status information based
on the content of the groupOfDTC parameter value selected by the client (tester).
Note: The DTCs shall be reported by the server(s) (ECU(s)) in the same sequence
as they have been identified/detected! A DTC shall be reported by the server(s) ECU(s)
as many times as it has been detected with different DTCFaultSymtom values. As a
consequence the parameter “numberOfDTC” in the positive response message is the
total number of all DTCs + DTCFaultSymtoms which are part of the groupOfDTC
parameter requested.
05DEC96 Figure 1 Figure 1 - Mapping of the Diagnostic Services and Keyword Protocol 2000 on the OSI Feiter, GM
Model has been exchanged with the revised Figure 1 of the ISO Standard. No technical STG-IO
change!
05JAN97 entire Eliminated shading in all figures and tables, changed ‘shaded areas’ to ‘bold font’ in Feiter, GM
document description STG-IO
10JAN97 table 4.3 Changed column 2 from ‘Part 3 Impl. Spec’ to KWP 2000 Part No.’ because of wrong Walter, GM
Part references for Services STC, SPC, ATP STG IO
20JAN97 entire Added automatic numberbering of all sections Feiter, GM
document STG-IO
26JAN97 figure 1 Added ISO 14230-4 document to figure 1. AG1
26JAN97 Table 4.1.2.3 Changed Hex Value range in Table 4.1.2.3 - Negative response message from 00-7F to Kalweit,
00-8F and 80-FF to 90-FF to meet specs in table 4.4.29 BMW
26JAN97 section Cancelled comma in 2nd sentence of parameter description ListOfDTCAndStatus Kalweit,
8.2.1.2 BMW
26JAN97 table Cancelled “)” in description of bit 7 in Table 8.2.1.2.3 - Definition of statusOfDTC Kalweit,
8.2.1.2.3 values BMW
26JAN97 figure 5 Exchanged Check Light with DTCWarningLamp in Figure 5 - Diagnostic Trouble Code Kalweit,
DTCStorageState. The same applies to the above description. BMW
26JAN97 section 8.2.3 Changed 2nd and 3rd senctence to Font Arial because both sentences are carry over from Kalweit,
the International Standard. BMW
Corrected typo in DTCFaultSymptom of Note:
26JAN97 section Corrected DTC#10 to DTC#16 in table STEP#1 response message. Kalweit,
8.2.5.2.2 BMW
26JAN97 section 8.3.3 Added the sentence “This service is limited to the request of DTC status information Kalweit,
about a single (selected) DTC.” BMW
26JAN97 table 8.4.1.2 Cancelled “(cont’d) in table description. Kalweit,
Corrected table number 8.4.1.3 to 8.4.1.2. BMW
Corrected table number 8.4.1.4 to 8.4.1.3.
26JAN97 section 3.3 Updated mnemonic tables with abbreviations of Data Link Layer document. Feiter, GM
STG-IO

Page: 157 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Date Section Description of change Requested

by
08MAR97 title page Added ETAS company Hoffmann,
ETAS
08MAR97 section 6.3.2 Corrected hex value range specification for: vehicleManufacturerSpecific from 81-FA Hilger,
to 81-F9 and systemSupplierSpecific from FB-FE to FB-FD to meet specification in Siemens
section 6.3.1. Tables 6.3.2.1 and 6.3.2.2 have been corrected accordingly.
08MAR97 section 6.3.2 Corrected hex value range specification for: vehicleManufacturerSpecific from 82-F9 to Hilger,
82-FA and systemSupplierSpecific from FA-FE to FC-FE to meet specification in Siemens
section 6.3.1. Tables 6.3.2.4 and 6.3.2.5 have been corrected accordingly.
08MAR97 section 5.4.2 Additional description has been added to the section specifying the Data Scaling Table Hilger,
Structure for clarification of multiple use of the same identificationOption in one ECU. Siemens
08MAR97 section This section has been expanded and splitted into two sub sections to describe the Jin, GM
8.4.5.2.4 situation (positive response of ECU) if the tester requests freeze frame data from the Powertrain
ECU with and without freeze frame and failure record data stored in the ECU.
08MAR97 end of The following sentence has been cancelled because the statement is not necessarily true: Preuschoff,
section 8.3.1 “The content of this record in the readStatusOfDiagnosticTroubleCodes positive MB AG
response message shall be different compared to the parameter statusOfDTC in the
readDiagnosticTroubleCodeByStatus request and positive response message.”
10MAR97 section 8.4.2 The following condition has been added to the readFreezeFrame request message table Feiter, GM
(8.4.2.1): “C2 & C5 = condition: not present if recordAccessMethod-Identifier = STG-IO
requestAllData”
The reason for this modification is, that the recordIdentification parameter in the request
message is not of any additional value if the requestAccessMethodId ist set to
requestAllData.
17MAR97 section table 8.2.1.2.3 Jin, GM
8.2.1.1 Powertrain
This bit indicates whether the diagnostic trouble code test conditions have been met
during a driving cycle since the last successful clearDiagnosticInformation service. This
bit allows for one bit to be available for service which indicates that the diagnostic test
of a DTC has been completed, since DTC information was cleared.
17APR97 section 8 Complete update of section 8 to meet SAE J2012 (BCD coded) and Manufacturer Walter, GM
specific (2 byte Hex coded) DTCs. STG IO,
Preuschoff,
MB AG
17APR97 title page Removed company „ACG Technical Centre Luxembourg“, because it’s DELCO Poull, Delco
10JUN97 section 6.1 Service startDiagnosticSession: 3 conditional bytes added for transmission of specific Walter, GM
baudrate (raw data transmission) within the request (only present if optional STG IO
baudrateIdentifier = specificBaudrate).
10JUN97 section 10 Figure 6 separated into 2 figures (figure 6 and figure 7) for clarification of the two Preuschoff,
possible methods for routine handling. MB AG
Walter, GM
STG IO
16JUN97 title page AISIN AW CO., Limited Japan Walter, GM
STG IO
01JULI97 title page changed Mercedes-Benz AG to Daimler-Benz AG Preuschoff,
DB AG
01JULI97 entire Version 1.3: Release VDA publication AG1
document

Page: 158 of 160

KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE OCTOBER 1, 1997

Date Section Description of change Requested

by
17JULI97 section 8 Changed word „undefined“ to „network communication“ in DTC descriptions to meet AG1
SAE J2012 naming conventions.
Changed Mnemonic „UG“ (Undefined Group) to „NCG“ (Network Communication
Group)
Changed Mnemonic „UDTC_“ (Undefined DTC) to „NCDTC“ (Network
Communication DTC)
17JUL97 title page Added companies: Walter, GM
- MAN Nutzfahrzeuge AG STG IO
- VDO Adolf Schindling AG
- Isuzu Motors Ltd.

17JUL97 6.1.5.2.3. Corrected positive response message in example for service startDiagnosticSession. The Preuschoff,
baudrateIdentifier must be 0x06 (specificBaudrate) instead of 0x05. MB AG
12SEP97 history log Column for document version number added Walter, GM
STG IO

Page: 159 of 160

OCTOBER 1, 1997 KEYWORD PROTOCOL 2000 PART 3: IMPLEMENTATION RECOMMENDED PRACTICE

Date Version of Section Description of change Requested

document by
12SEP97 1.3 title page Added companies: Walter, GM
- FEV Motorentechnik GmbH & Co. KG STG IO
- Kelsey-Hayes
12SEP97 1.3 8.2.3 Note changed: Description of two alternative methods of reporting Preuschoff,
8.2.4 DTCs to reach vehicle manufacturer specific needs. MB AG
Adaption of message flow example.
16SEP97 1.4 entire Version 1.4: Release for VDA publication AG1
document
29SEP97 1.4 title page Bottom line of title page removed. AG1
29SEP97 1.4 section Text of table 7.4.5.5.1 corrected to „Data record referenced by two Schmidt,
7.4.5.5 different memory addresses of two different Siemens
readDataByMemoryAddress messages“
29SEP97 1.4 section Positive response Sid of message flow example (step#4) corrected to Schmidt,
‘61’ Siemens
29SEP97 1.4 section New sections added: Preuschoff,
8.3 „8.3.1.1 Function groups according to SAE J2012 (DTC Definitions MB AG
Recommended Practice)“
„8.3.1.2 Vehicle Manufacturer defined function groups according to 2
Byte Hex DTC format“
New table added:
„Table 8.3.1.2.1 - Definition of Vehicle Manufacturer defined
groupOfDTC“
29SEP97 1.4 Section table 8.4.3.1: One more column added for description of vehicle Preuschoff,
8.4 manufacturer specifc 2 Byte Hex DTCs. MB AG
29SEP97 1.4 section Numbering of table „8.2.1.1.2“ corrected to „8.2.1.1.1.2“. Adaption of Walter, GM
8.2 all references within the document. STG IO
29SEP97 1.4 title page Added companies: Walter, GM
- LucasVarity STG IO
01OCT97 1.5 entire Final release for VDA publication: Version 1.5 AG1
document

Page: 160 of 160