ISO 14230-2:2013

INTERNATIONAL ISO
STANDARD 14230-2
Second edition
2013-03-15
Road vehicles — Diagnostic
communication over K-Line (DoK-
Line) —
Part 2:
Data link layer
Véhicules routiers — Communication de diagnostic sur la ligne K
(DoK-Line) —
Partie 2: Couche de liaison de données
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols, and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Conventions . 3
5 Document overview. 4
6 Physical bus topology . 6
7 Data link layer overview . 7
7.1 General . 7
7.2 Format description of data link layer services . 7
7.3 Services provided by the data link layer to higher layers . 7
7.4 Specification of DoK-Line data link layer service primitives . 8
7.5 Service data unit specification .10
8 Protocol initialization .14
8.1 General .14
8.2 Timing parameters for 5-BAUD_INIT .14
8.3 Protocol determination .15
8.4 Protocol-specific key bytes .23
9 Message definition .26
9.1 Message structure .26
9.2 Message header .27
9.3 Protocol data unit (PDU) .29
9.4 Checksum byte (CS) .29
10 Protocol timing requirements .30
10.1 General timing measurement requirements .30
10.2 Protocol timing parameter definition .30
10.3 Inter-byte message timing .31
10.4 Data link layer timing at T-Data interface .33
11 Communication services .35
11.1 StartCommunication service .35
11.2 StopCommunication service .36
11.3 AccessTimingParameter service .38
11.4 SendData service .41
12 Data collisions
......................................................................................................................................................................................................41
13 Error handling.42
13.1 Error handling during physical/functional 5-BAUD initialization .42
13.2 Error handling during physical/functional FAST_INIT .43
13.3 Error handling after physical/functional initialization .45
Annex A (normative) Server and client addresses for 5-BAUD_INIT .47
Annex B (informative) Recommended server and client addresses .48
Annex C (informative) Protocol comparison of initialization sequence .49
Bibliography .50
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 14230-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
This second edition cancels and replaces the first edition (ISO 14230-2:1999), which has been
technically revised.
ISO 14230 consists of the following parts, under the general title Road vehicles — Diagnostic communication
over K-Line (DoK-Line):
— Part 1: Physical layer
— Part 2: Data link layer
— Part 3: Application layer
— Part 4: Requirements for emission-related systems
iv © ISO 2013 – All rights reserved

Introduction
This part of ISO 14230 has been established in order to define common requirements for vehicle diagnostic
systems implemented on K-Line (UART-based) communication link, as specified in ISO 14230-1.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in
accordance with ISO/IEC 7498-1:1994 and ISO/IEC 10731, which structures communication systems
into seven layers. When mapped on this model, the services specified by ISO 14230 are broken into:
— Diagnostic services (layer 7), specified in ISO 14229-1, ISO 14229-6,
— Presentation layer (layer 6),
— vehicle manufacturer specific,
— legislated WWH-OBD: specified in ISO 27145-2, SAE J1930-DA, SAE J1979-DA, SAE J2012-DA,
SAE J1939, Companion Spreadsheet (SPNs), SAE J1939-73:2010, Appendix A (FMIs),
— Session layer services (layer 5),
— legislated OBD: specified in ISO 14229-2,
— legislated WWH-OBD: specified in ISO 14229-2,
— Transport layer services (layer 4), specified in ISO 14230-2,
— Network layer services (layer 3), specified in ISO 14230-2,
— Data link layer (layer 2), specified in ISO 14230-4, ISO 14230-2,
— Physical layer (layer 1), specified in ISO 14230-1.
This breakdown is shown in Table 1.
Table 1 — Enhanced and legislated OBD diagnostic specifications applicable to the OSI layers
Applicability OSI seven Enhanced Legislated OBD Legislated WWH-OBD
layer diagnostics (On-Board Diagnostics) (On-Board Diagnostics)
Application ISO 14229-1,
ISO 15031-5 ISO 14229-1, ISO 27145-3
(layer 7) ISO 14229-6
Presentation ISO 15031-2, ISO 15031-5, ISO 27145-2, SAE 1930-DA,
(layer 6) vehicle ISO 15031-6, SAE J1939 Companion Spread-
manufacturer SAE J1930-DA, sheet (SPNs), SAE J1939-73:2010,
specific SAE J1979-DA, Appendix A (FMIs),
SAE J2012-DA SAE J1979-DA, SAE J2012-DA,
Seven layer
Session
according to ISO 14229-2
(layer 5)
ISO/IEC 7498-1
and Transport
ISO/IEC 10731 (layer 4)
ISO 15765-4,
ISO 14230-2 ISO 15765-2
ISO 15765-2
Network
(layer 3)
ISO 15765-4 ISO 27145-4
Data link ISO 14230-2
ISO 15765-4,
(layer 2)
ISO 11898-1,
ISO 11898-1,
ISO 11898-2
Physical ISO 14230-1
ISO 11898-2
(layer 1)
The application layer services covered by ISO 14229-6 have been defined in compliance with diagnostic
services established in ISO 14229-1 and ISO 15031-5, but are not limited to use only with them.
ISO 14229-6 is also compatible with most diagnostic services defined in national standards or vehicle
manufacturer’s specifications.
vi © ISO 2013 – All rights reserved

INTERNATIONAL STANDARD ISO 14230-2:2013(E)
Road vehicles — Diagnostic communication over K-Line
(DoK-Line) —
Part 2:
Data link layer
1 Scope
This part of ISO 14230 specifies data link layer services tailored to meet the requirements of UART-
based vehicle communication systems on K-Line as specified in ISO 14230-1. It has been defined in
accordance with the diagnostic services established in ISO 14229-1 and ISO 15031-5, but is not limited
to use with them, and is also compatible with most other communication needs for in-vehicle networks.
The protocol specifies an unconfirmed communication.
The diagnostic communication over K-Line (DoK-Line) protocol supports the standardized service
primitive interface as specified in ISO 14229-2.
This part of ISO 14230 provides the data link layer services to support different application layer
implementations like:
— enhanced vehicle diagnostics (emissions-related system diagnostics beyond legislated functionality,
non-emissions-related system diagnostics);
— emissions-related OBD as specified in ISO 15031, SAE J1979-DA, and SAE J2012-DA.
In addition, this part of ISO 14230 clarifies the differences in initialization for K-line protocols defined in
ISO 9141 and ISO 14230. This is important since a server supports only one of the protocols mentioned above
and the client has to handle the coexistence of all protocols during the protocol-determination procedure.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 14230-1, Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 1: Physical layer
ISO 14230-4, Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 4: Requirements for
emission-related systems
3 Terms, definitions, symbols, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
5-baud initialization
5-BAUD_INIT
starts with bus idle and ends with inverted address byte sent by the server
3.1.2
fast initialization
FAST_INIT
starts with bus idle and ends with the reception of all positive responses of the StartCommunication
service from all addressed servers
3.1.3
topology
serial link between client and servers that consists of a K-Line and an optional L-Line
3.1.4
server
function that is part of an electronic control unit and that provides the diagnostic services
3.1.5
client
function that is part of the tester and that makes use of the diagnostic services
Note 1 to entry: A tester normally makes use of other functions such as data base management, specific
interpretation, human-machine interface.
3.2 Abbreviated terms
5-BAUD_INIT 5-baud initialization
ISO 9141-2, 5-BAUD_INIT protocol on K-Line according to ISO 9141-2 including 5-BAUD_INIT
ISO 14230-2, 5-BAUD_INIT protocol on K-Line according to ISO 14230-2 including 5-BAUD_INIT
ISO 14230-2 FAST_INIT protocol on K-Line according to ISO 14230-2 including FAST_INIT
ISO 14230-4, 5-BAUD_INIT protocol on K-Line according to ISO 14230-4 including 5-BAUD_INIT
ISO 14230-4 FAST_INIT protocol on K-Line according to ISO 14230-4 including FAST_INIT
bus converter electronic control unit that links bus systems
client external test equipment
confirm confirmation service primitive
Cvt M = mandatory, C = conditional, U = user-optional
ECU electronic control unit
FAST_INIT fast initialization
FB first byte
FMT format byte
gateway linking hardware between bus systems
DA destination address
DoK-Line diagnostic communication over K-Line
DoK-Line_SA data link source address
DoK-Line_TA data link target address
2 © ISO 2013 – All rights reserved

DoK-Line_TAtype data link target address type
indication indication service primitive
LEN length byte
Mtype message type
request request service primitive
DL_Data data link data
DoK-Line_PCI data link protocol control information
DoK-Line_PCItype data link protocol control information type
DoK-Line_PDU data link protocol data unit
DoK-Line_SA data link source address
DoK-Line_SDU data link service data unit
P1 inter-byte timing parameter of the server
Receiver
P2 time between client request and server response or two server
Server
responses
P3 time between end of server responses and start of new client request
Client
P4 inter-byte timing parameter of the client
Sender
SA source address
server electronic control unit (ECU)
TA target address
UART universal asynchronous receiver and transmitter
WuP wake-up pattern
4 Conventions
This part of ISO 14230 is based on the conventions discussed in the OSI Service Conventions
(ISO/IEC 10731:1994) as they apply for diagnostic services.
These conventions specify 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.
Figure 1 summarizes the distinction between service and protocol.
Figure 1 — The services and the protocol
NOTE The figure above does not show the confirmation generated on the transmitter side of the message.
ISO 14230-2 defines confirmed services. The confirmed services use the three service primitives:
request, indication, and confirmation.
For all services defined in ISO 14230-2, the request and indication service primitives always have the
same format and parameters.
5 Document overview
Figure 2 shows the diagnostic communication over K-Line document reference according to OSI model.
4 © ISO 2013 – All rights reserved

Figure 2 — DoK-Line document reference according to OSI model
6 Physical bus topology
DoK-Line is a bus concept based on a serial link consisting of one or two physical lines.
Figure 3 shows the server and client topology.
Server 1 Server 2 Server n Client
Key
1 K-Line
2 L-Line (optional)
Figure 3 — Server and client topology
“K-Line” is used for communication and initialization, whereas “L-Line” (optional) is used for initialization
only. Special cases are node-to-node connection that means only one server (ECU) is on the line, which
also can be a bus converter.
The following recommendations apply:
— It is recommended to no longer support the L-Line in server (ECU) hardware.
— Client (external test equipment) hardware shall support the L-Line if compliance to ISO 15031-4 is
required.
For more details, refer to ISO 14230-1 “K-/L-line configurations”.
Figure 4 illustrates an example of multiple servers (ECUs) connected with the K-Line to the client
(external test equipment). Server 1.2 (ECU 1.2) functions as a gateway (bus converter) and is operating
on a bus system (e.g. ISO 15765, SAE J1850).
Server 2.1 Server 2.2 Server 2.m
Server 1.2
Server 1.1 Bus Converter/ Server 1.n Client
Gateway
Key
1 K-Line
2 arbitrary bus system
Figure 4 — Gateway topology example
6 © ISO 2013 – All rights reserved

7 Data link layer overview
7.1 General
This part of ISO 14230 specifies the data link layer services which are used in client-server based systems
to transmit data from one to the other entity. The client, referred to as the external test equipment, uses
the data link layer services to transfer diagnostic request data to one or more servers, referred to as
an ECU. The server, usually a function that is part of an ECU, uses the data link layer services to send
response data, provided by the requested diagnostic service, back to the client. The client is usually the
external test equipment but can in some systems also be an on-board test equipment. The usage of data
link layer services is independent from the external test equipment being an off-board or on-board test
equipment. It is possible to have more than one client (test equipment) in the same vehicle system.
In order to describe the function of the data link layer, services provided to higher layers and the internal
operation of the data link layer have to be considered.
7.2 Format description of data link layer services
All data link layer services have the same general format. Service primitives are written in the form
service_name.type (
[parameter 1, parameter 2, parameter 3, .]
)
where
— “service_name” is the name of the diagnostic service (e.g. DL_Data),
— “type” indicates the type of the service primitive (e.g. request),
— “[parameter 1, .]” are parameters that depend on the specific service (e.g. parameter 1 can be the
source address of the sender). The brackets indicate that this part of the parameter list may be empty.
7.3 Services provided by the data link layer to higher layers
The data link layer service interface defines a set of services that are needed to access the functions
offered by the data link layer, i.e. transmission/reception of data, setting of data link layer parameters.
The service access point of the data link layer provides the following service primitives as specified:
— Using the service primitive request (service_name.request), a service user requests a service from
the service provider.
— Using the service primitive indication (service_name.indication), the service provider informs a
service user about an internal event of the network layer or the service request of a peer protocol
layer entity service user.
— With the service primitive confirm (service_name.confirm), the service provider informs the service
user about the result of a preceding service request of the service user.
The three types of services are defined:
a) Initialization services
These services, of which the following are defined, provide the functionality to perform the
initialization of the DoK-Line communication.
— DoK-Line_Initialize.request
This service is used to request the DoK-Line communication.
— DoK-Line_Initialize.confirm
This service confirms to the higher layers that the DoK-Line communication has been carried
out (successfully or not).
b) Communication services
These services, of which the following are defined, enable the transfer of up to 255 bytes of data.
— DL_Data.request
This service is used to request the transfer of data.
— DL_Data_FB.indication
This service is used to signal the beginning of a message reception to the upper layer.
— DL_Data.indication
This service is used to provide received data to the higher layers.
— DL_Data.confirm
This service confirms to the higher layers that the requested service has been carried out
(successfully or not).
c) InputOutputControl services
These services, of which the following are defined, provide the functionality to perform certain
fixed sequences (e.g. 5-baud initialization, wake-up pattern generation).
— DoK-Line_IOControl.request
This service is used to request the execution of a specific data link layer sequence.
— DoK-Line_IOControl.confirm
This service confirms to the upper layer that the request to execute a specific data link layer
sequence has been done (successfully or not).
d) Protocol parameter setting services
These services, of which the following are defined, enable the dynamic setting of protocol parameters.
— DoK-Line_ChangeParameter.request
This service is used to request the dynamic setting of specific internal parameters (e.g.
timing parameters).
— DoK-Line_ChangeParameter.confirm
This service confirms to the upper layer that the request to change a specific protocol parameter
has been carried out (successfully or not).
7.4 Specification of DoK-Line data link layer service primitives
7.4.1 DL_Data.request
The service primitive requests transmission of < MessageData > with < Length > bytes from the sender
to the receiver peer entities identified by the address information in SA and TA.
Each time the DL_Data.request service is called, the data link layer shall signal the completion (or failure)
of the message transmission to the service user by means of issuing a DL_Data.confirm service call.
8 © ISO 2013 – All rights reserved

DL_Data.request (
SA
TA
TAtype


)
7.4.2 DL_Data.confirm
The data link layer issues the DL_Data.confirm service. The service primitive confirms the completion of
a DL_Data.request service identified by the address information in SA and TA. The parameter < Result_
DoK-Line > provides the status of the service request.
DL_Data.confirm (
SA
TA
TAtype

)
7.4.3 DL_Data_FB.indication
The data link layer issues the DL_Data_FB.indication service. The service primitive indicates to the
adjacent upper layer the arrival of the first byte (FB) of a message received from a peer protocol entity
identified. This indication shall take place upon reception of the first byte of a message.
The DL_Data_FB.indication service shall always be followed by a DL_Data.indication service call from
the data link layer to indicate the completion (or failure) of the message reception.
DL_Data_FB.indication (
SA
TA
TAtype


)
There is no address information contained in the indication, because the first byte only indicates the
start of a message. There can only be one message transmitted on the data link layer at a time (no
multiple messages can be pending in the data link layer at a time); therefore, the first byte indication
does not require any address information. The final indication of the message reception will contain the
address information for the received message.
7.4.4 DL_Data.indication
The data link layer issues the DL_Data.indication service. The service primitive indicates < Result_DoK-
Line > events and delivers < MessageData > with < Length > bytes received from a peer protocol entity
identified by the address information in SA and TA to the adjacent upper layer.
The parameters < MessageData > and < Length > are only valid if < Result_DoK-Line > equals DoK-Line_OK.
DL_Data.indication (
SA
TA
TAtype



)
7.4.5 DoK-Line_Init.request
The service primitive requests the initialization of the data link layer.
Each time the DoK-Line_Initialize.request service is called, the data link layer shall signal the completion
(or failure) of the message transmission to the service user by means of issuing a DoK-Line_Initialize.
confirm service call.
DoK-Line_Initialize.request (
SA
TA

)
7.4.6 DoK-Line_Initialize.confirm
The data link layer issues the DoK-Line_Initialize.confirm service. The service primitive confirms the
completion of a DoK-Line_Initialize.request service. The parameter < Result_Initialize > provides the
status of the service request, and the parameter < InitializeResultData > provides result data of the
performed input output control (e.g. key bytes).
DoK-Line_Initialize.confirm (


)
7.4.7 DoK-Line_ChangeParameter.request
The service primitive is used to request the change of an internal parameter’s value on the local protocol
entity. The < Parameter_Value > is assigned to the < Parameter > (see 10.2 for parameter definition).
A parameter change is always possible except after reception of the first byte (DL_Data_FB.indication)
until the end of the reception of the corresponding message (DL_Data.indication).
DoK-Line_ChangeParameter.request (


)
This is an optional service that can be replaced by implementation of fixed parameter values.
7.4.8 DoK-Line_ChangeParameter.confirm
The service primitive confirms the completion of a DoK-Line_ChangeParameter.Confirmation service
(see 10.2 for parameter definition).
DoK-Line_ChangeParameter.confirm (


)
7.5 Service data unit specification
7.5.1 SA, Source Address
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description:
The parameter SA shall be used to encode client and server identifiers, and it shall be used to represent
the physical location of a client or server.
For the transmission of data from the client to the server, SA represents the client identifier in the service
request, service indication, and service confirmation.
For the transmission of data from the server to the client, SA represents the server identifier in the
service request, service indication, and service confirmation.
10 © ISO 2013 – All rights reserved

The client shall always be located in one external test equipment only. There shall be a strict, one to one,
relation between client identifiers and source addresses. Each client identifier shall be encoded with one
SA value. If more than one client is implemented in the same external test equipment, then each client
shall have its own client identifier and corresponding SA value.
A server may be implemented in one ECU only or be distributed and implemented in several ECUs. If
a server is implemented in one ECU only, then it shall be encoded with one SA value only. If a server is
distributed and implemented in several ECUs, then the server identifier shall be encoded with one SA
value for each physical location of the server.
7.5.2 TA, Target Address
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description:
The parameter TA shall be used to encode client and server identifiers.
For the transmission of data from the client to the server, TA represents the server identifier in the
service request, service indication, and service confirmation.
For the transmission of data from the server to the client, TA represents the client identifier in the
service request, service indication, and service confirmation.
TA may be a physical or a functional address. Physical addresses may be the 5-baud address byte (see
ISO 9141:1989, Annex A and Annex B).
For emissions-related messages, this byte is defined in ISO 14230-4.
7.5.3 TAtype, target address type
Type: enumeration
Range: physical, functional
Description:
The parameter TAtype is an extension to the TA parameter. It shall be used to encode the communication
model used by the communicating peer entities of the data link layer. Two communication models are
specified: 1-to-1 communication called physical addressing and 1-to-n communication called functional
addressing. (For the format of the format byte in the DoK-Line_PDU to handle the two addressing types,
see 9.2.1.)
7.5.4 < Length >
Type: 1 byte
Range: 0x00 – 0xFF
Description:
This parameter includes the length of data to be transmitted/received.
7.5.5 < MessageData >
Type: string of bytes
Range: not applicable
Description:
This parameter includes all data exchanged by the higher layer entities.
7.5.6 < Result_DoK-Line >
Type: enumeration
Range: DoK-Line_OK, DoK-Line_TIMEOUT_P1, DoK-Line_TIMEOUT_P4, DoK-Line_UNEXP_PDU
Description:
This parameter contains the status relating to the outcome of a service execution. If more than one error
is discovered at the same time, then the data link layer entity shall use the parameter value first found
in this list in the error indication to the higher layers.
— DoK-Line_OK
This parameter means that the service execution has completed successfully. This parameter can
be issued to a service user on both the sender and receiver side.
— DoK-Line_TIMEOUT_P1
This parameter is issued to the protocol user when the timer DoK-Line_P1 has passed its timeout
value DoK-Line_P1 . This parameter can be issued to the service user on the server side.
max
— DoK-Line_TIMEOUT_P4
This parameter is issued to the protocol user when the timer DoK-Line_P4 has passed its timeout
value DoK-Line_P4 . This parameter can be issued to the service user on the client side.
max
— DoK-Line_UNEXP_PDU
This parameter is issued to the service user upon reception of an unexpected protocol data unit.
This parameter can be issued to the service user on both the sender and receiver side.
NOTE The status parameters DoK-Line_TIMEOUT_P1 and DoK-Line_TIMEOUT_P4 are equivalent for the
upper layer.
7.5.7 < InitializationModeIdentifier >
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description:
This parameter identifies the type of initialization to be performed by the data link layer.
— Perform 5-BAUD_INIT initialization sequence and provide the resulting key bytes.
— Perform FAST_INIT initialization sequence and provide the resulting key bytes.
NOTE The above listed functionality is only required to be supported by the client (external test equipment).
7.5.8 < InitializationResultData >
Type: string of bytes
Range: not applicable
Description:
This parameter includes all data provided by the initialization procedure (e.g. key bytes).
12 © ISO 2013 – All rights reserved

7.5.9 < Result_Initialization >
Type: enumeration
Range: DoK-Line_OK, DoK-Line_RX_ON, DoK-Line_WRONG_PARAMETER, DoK-Line_WRONG_VALUE
Description:
This parameter contains the status relating to the outcome of a service execution.
— DoK-Line_OK
This parameter means that the service execution has completed successfully. This parameter can
be issued to a service user on both the sender and receiver side.
— DoK-Line_RX_ON
This parameter is issued to the service user to indicate that the service did not execute, since a
reception of the message identified by < AI > was taking place. This parameter can be issued to the
service user on the receiver side only.
— DoK-Line_WRONG_PARAMETER
This parameter is issued to the service user to indicate that the service did not execute due to an
undefined < Parameter > . This parameter can be issued to the service user on both the receiver
and sender side.
— DoK-Line_WRONG_VALUE
This parameter is issued to the service user to indicate that the service did not execute due to an out
of range < Parameter_Value > . This parameter can be issued to the service user on both the receiver
and sender side.
7.5.10 < Parameter_Value >
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description:
This parameter is assigned to a protocol parameter < Parameter > as indicated in the service section of
this document. The upper layer can, for instance, configure what kind of DoK-Line_FMT shall be placed
in the DoK-Line_SDU when transmitting a message (see Clause 9).
7.5.11 < Result_ChangeParameter >
Type: enumeration
Range: DoK-Line_OK, DoK-Line_RX_ON, DoK-Line_WRONG_PARAMETER, DoK-Line_WRONG_VALUE
Description:
This parameter contains the status relating to the outcome of a service execution.
— DoK-Line_OK
This parameter means that the service execution has completed successfully. This parameter can
be issued to a service user on both the sender and receiver side.
— DoK-Line_RX_ON
This parameter is issued to the service user to indicate that the service did not execute, since a
reception of the message identified by < AI > was taking place. This parameter can be issued to the
service user on the receiver side only.
— DoK-Line_WRONG_PARAMETER
This parameter is issued to the service user to indicate that the service did not execute due to an
undefined < Parameter >. This parameter can be issued to the service user on both the receiver
and sender side.
— DoK-Line_WRONG_VALUE
This parameter is issued to the service user to indicate that the service did not execute due to an out
of range < Parameter_Value > . This parameter can be issued to the service user on both the receiver
and sender side.
8 Protocol initialization
8.1 General
ISO 9141-2 and ISO 14230-2 define three different methods to accomplish asynchronous-to-synchronous
communications.
The three protocols are separate and distinct:
— ISO 9141-2 with 5-BAUD_INIT initialization,
— ISO 14230-2 with 5-BAUD_INIT initialization,
— ISO 14230-2 with FAST_INIT initialization.
ISO 14230-4 states that all emissions-related OBD ECUs on a single vehicle shall only support one of either
the 5-BAUD_INIT or the FAST_INIT. ISO 9141-2 also defines a 5-BAUD_INIT sequence, which is differentiated
from the ISO 14230-2, 5-BAUD_INIT sequence by the key bytes that the vehicle responds with.
8.2 Timing parameters for 5-BAUD_INIT
Table 2 shows timing values for 5-baud initialization. These are fixed values. They cannot be changed by
the AccessCommunicationParameter service.
Table 2 — Timing parameters for 5_BAUD_INIT
Timing Values Description
parameter [ms]
min max
W1 60 300 Time from end of the address byte to start of synchronization pattern.
W2 5 20 Time from end of the synchronization pattern to the start of key byte 1.
W3 0 20 Time between key byte 1 and key byte 2.
W4 25 50 Time between key byte 2 (from the server) and its inversion from the client.
Also the time from the inverted key byte 2 from the client and the inverted
address from the server.
W5 300 - Time before the client starts to transmit the address byte.
14 © ISO 2013 – All rights reserved

8.3 Protocol determination
8.3.1 5-BAUD_INIT according to ISO 9141
ISO 9141 5-BAUD_INIT initialization starts with a sequence by the client (external test equipment)
issuing the address byte at 5 bits per second.
The address byte has a preceding start bit (level low) and a following stop bit (level high). This gives a
total length of 10 bits to be transmitted at 5 baud (see Figure 5 and Figure 6).
Table 3 defines the initialization procedure.
Table 3 — ISO 9141 initialization procedure with 5-BAUD_INIT
Client/
# Step Description
Server
1 Address byte trans- client Address byte at 5 baud including start and stop bit takes 2 seconds.
mission
2 Address byte valida- server Validation of the address byte internally in the vehicle servers, which
tion takes the time W1 (20 . 300 ms).
3 Synchronization server Exactly one vehicle server will respond with the synchronization byte
byte transmission 0x55 informing the external test equipment of the new baud rate.
4 Synchronization client Reconfiguration has to be done within 5 ms.
byte validation & set
new baud rate
5 Key bytes transmis- server The vehicle server which has sent the synchronization byte shall wait
sion the time W2 (5 . 20 ms) for the client to reconfigure to the new baud
rate. Then this vehicle server will send the two key bytes.
6 Key bytes validation client See 8.4 for protocol-specific key bytes.
According to the received key bytes, the external test equipment (cli-
ent) has to configure:
—  ISO 9141 protocol,
—  header format,
—  timing (P2 ).
min
7 Inverted key byte 2 client As an acknowledgement of reception of the key bytes, the client, after
transmission waiting W4 (25 . 50 ms), shall then send the inverted key byte 2 to the
vehicle servers.
8 Validation of server Evaluation of inverted key byte.
inverted key byte
9 Inverted address server After waiting another period equal to W4, the vehicle server which
byte transmission has sent the synchronization byte shall then invert the initialization
address byte and send it to the client as the “ready to communicate”
signal. This ends the initialization sequence from the viewpoint of the
server.
10 Validation of client Evaluation of inverted address byte. This ends the initialization
inverted address sequence from the viewpoint of the client.
byte
Figure 5 shows the initialization with 5-BAUD_INIT according to ISO 9141-2.
Key
1 P2 timing value (25 . 50 ms) depends on the key bytes (normal timing).
Server
2 P2 timing value (0 . 50 ms) depends on the key bytes (extended timing).
Server
3 P3 timing value (55 . 5 000 ms) depends on the key bytes.
Client
Figure 5 — Initialization with 5-BAUD_INIT according to ISO 9141-2
8.3.2 5-BAUD_INIT according to ISO 14230-2
ISO 14230 5-BAUD_INIT is identical to the ISO 9141 5-BAUD_INIT, except for the key bytes sent from the
vehicle to the external test equipment. The definition in 8.4.1 Table 11 is valid for both protocols. The
key byte sets are defined in 8.4.2 and 8.4.4.
Table 4 defines the ISO 14230-2 initialization procedure with 5-BAUD_INIT.
16 © ISO 2013 – All rights reserved

Table 4 — ISO 14230-2 initialization procedure with 5-BAUD_INIT
# Step Client/Server Description
1 Address byte client Address byte at 5 baud including start and stop bit takes 2 sec-
transmission onds.
2 Address byte vali- server Validation of the address byte internally in the vehicle servers,
dation which takes the time W1 (20 . 300 ms).
3 Synchronization server Exactly one vehicle server will respond with the synchronization
byte transmission byte 0x55 informing the external test equipment of the new baud
rate.
4 Synchronization client Reconfiguration has to be done within 5 ms.
byte validation &
set new baud rate
5 Key bytes trans- server The vehicle server which has sent the synchronization byte shall
mission wait the time W2 (5 . 20 ms) for the client to reconfigure to the
new baud rate. Then this vehicle server will send the two key
bytes.
6 Key bytes valida- client See 8.4 for protocol-specific key bytes.
tion
According to the received key bytes, the external test equipment
(client) has to con
...