ISO 14230-2:2016
(Main)Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data link layer
Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data link layer
ISO 14230-2:2016 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. ISO 14230-2:2016 provides the data link layer services to support different application layer implementations like the following: - 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, ISO 14230-2:2016 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.
Véhicules routiers — Communication de diagnostic sur la ligne K (DoK-Line) — Partie 2: Couche de liaison de données
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14230-2
Third edition
2016-08-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 2016
© ISO 2016, Published in Switzerland
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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Symbols and abbreviated terms. 2
4 Conventions . 3
5 Document overview. 4
6 Physical bus topology . 5
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.4.1 DL_Data.request. 8
7.4.2 DL_Data.confirm . 8
7.4.3 DL_Data_FB.indication . 9
7.4.4 DL_Data.indication . 9
7.4.5 DoK-Line_Init.request . 9
7.4.6 DoK-Line_Initialize.confirm . 9
7.4.7 DoK-Line_ChangeParameter.request .10
7.4.8 DoK-Line_ChangeParameter.confirm .10
7.5 Service data unit specification .10
7.5.1 SA, Source Address .10
7.5.2 TA, Target Address .10
7.5.3 TAtype, target address type .11
7.5.4 .11
7.5.5 .11
7.5.6 .11
7.5.7 .12
7.5.8 .12
7.5.9 .12
7.5.10 .13
7.5.11 .13
8 Protocol initialization .14
8.1 General .14
8.2 Timing parameters for 5-BAUD_INIT .14
8.3 Protocol determination .14
8.3.1 5-BAUD_INIT according to ISO 9141 .14
8.3.2 5-BAUD_INIT according to this document .16
8.3.3 FAST_INIT according to this document .17
8.3.4 FAST_INIT according to ISO 14230–4 .19
8.3.5 Client protocol determination by server (ECU) key bytes .20
8.3.6 Initial data exchange after successful completion of initialization .22
8.4 Protocol specific key bytes .22
8.4.1 Format of key bytes .22
8.4.2 Key bytes for emissions-related OBD protocols of ISO 9141-2 .23
8.4.3 Key bytes for emissions-related OBD protocol ISO 14230-4 .23
8.4.4 Key bytes for enhanced diagnostics with support of ISO 14230-4 .24
8.4.5 Calculation of decimal value of key bytes .25
9 Message definition .25
9.1 Message structure .25
9.2 Message header .26
9.2.1 Format byte (FMT) .26
9.2.2 Target address byte (TA) .26
9.2.3 Source address byte (SA) .27
9.2.4 Length byte (LEN) .27
9.2.5 Message header configurations .27
9.3 Protocol data unit (PDU) .28
9.4 Checksum byte (CS) .28
10 Protocol timing requirements .29
10.1 General timing measurement requirements .29
10.2 Protocol timing parameter definition .29
10.2.1 Inter-byte and inter-message timing parameters .29
10.2.2 Inter-byte timing parameter set .29
10.3 Inter-byte message timing .30
10.4 Data link layer timing at T-Data interface .32
11 Communication services .34
11.1 StartCommunication service .34
11.1.1 Service definition.34
11.1.2 Implementation .35
11.2 StopCommunication service .36
11.2.1 Service definition.36
11.2.2 Implementation .36
11.3 AccessTimingParameter service .37
11.3.1 Service definition.37
11.3.2 Implementation .38
11.4 SendData service .40
11.4.1 Service definition.40
12 Data collisions .41
13 Error handling.41
13.1 Error handling during physical/functional 5-BAUD initialization .41
13.1.1 Client (external test equipment) error handling during physical/
functional 5-BAUD-INIT .41
13.1.2 Server (ECU) error handling during physical/functional 5-BAUD_INIT .42
13.2 Error handling during physical/functional FAST_INIT .42
13.2.1 Client (external test equipment) error handling during physical/
functional FAST_INIT . .42
13.2.2 Server (ECU) error handling during physical FAST_INIT.43
13.2.3 Server (ECU) error handling during functional FAST_INIT (normal timing only) 43
13.3 Error handling after physical/functional initialization .44
13.3.1 Client (external test equipment) communication error handling (after
physical/functional initialization) .44
13.3.2 Server (ECU) communication error handling after physical initialization .44
13.3.3 Server (ECU) error handling after functional initialization .45
Annex A (normative) Server and client addresses for 5-BAUD_INIT .46
Annex B (informative) Recommended server and client addresses .47
Annex C (informative) Protocol comparison of initialization sequence .48
Bibliography .49
iv © ISO 2016 – All rights reserved
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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
This third edition cancels and replaces the second edition (ISO 14230-2:2013), which has been
technically revised.
A list of parts in the ISO 14230 series can be found on the ISO website.
Introduction
This document 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 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 the
following:
— Diagnostic services (layer 7), specified in ISO 14229-1, ISO 14229-6;
— Presentation layer (layer 6):
— vehicle manufacturer specific;
— legislated WWH-OBD: ISO 27145-2, SAE 1930-DA, SAE J1979-DA, SAE J2012-DA, SAE J1939:2011,
Appendix C (SPN), SAE J1939-73:2010, Appendix A (FMI);
— 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;
in accordance with Table 1.
Table 1 — Enhanced and legislated OBD diagnostic specifications applicable to the OSI layers
Enhanced Legislated OBD Legislated WWH-OBD
a
OSI seven layer
diagnostics (On-Board Diagnostics) (On-Board Diagnostics)
ISO 14229-1,
Application (layer 7) ISO 15031-5 ISO 14229-1, ISO 27145-3
ISO 14229-6
ISO 15031-2, ISO 27145-2, SAE 1930-DA,
ISO 15031-5, SAE J1979-DA, SAE J2012-DA,
vehicle
Presentation ISO 15031-6, SAE J1939:2011,
manufacturer
(layer 6) SAE J1930-DA, Appendix C (SPN),
specific
SAE J1979-DA, SAE J1939–73:2010,
SAE J2012-DA Appendix A (FMI)
Session (layer 5) ISO 14229-2
Transport (layer 4)
ISO 15765-4,
ISO 14230-2 ISO 15765-2
ISO 15765-2
Network (layer 3)
ISO 15765-4,
ISO 15765-4 ISO 27145-4
Data link (layer 2) ISO 14230-2 ISO 11898-1
ISO 11898-1
ISO 11898-1, ISO 11898-1,
Physical (layer 1) ISO 14230-1
ISO 11898-2 ISO 11898-2
a
Seven layers according to ISO/IEC 7498-1 and ISO/IEC 10731.
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.
vi © ISO 2016 – All rights reserved
ISO 14229-6 is also compatible with most diagnostic services defined in national standards or vehicle
manufacturer’s specifications.
INTERNATIONAL STANDARD ISO 14230-2:2016(E)
Road vehicles — Diagnostic communication over K-Line
(DoK-Line) —
Part 2:
Data link layer
1 Scope
This document 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 document provides the data link layer services to support different application layer
implementations like the following:
— 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 document 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 are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
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 and 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 database management, specific
interpretation, human-machine interface.
3.2 Symbols and 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 Convention: 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
2 © ISO 2016 – All rights reserved
DoK-Line_SA data link source address
DoK-Line_TA data link target address
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 responses
Server
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 document is based on the conventions discussed in the OSI Service Conventions (ISO/IEC 10731)
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 — Services and protocol
NOTE Figure 1 does not show the confirmation generated on the transmitter side of the message.
This document defines confirmed services. The confirmed services use the three service primitives
request, indication and confirmation.
For all services defined in this document, 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 2016 – 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.
Key
1 K-Line
2 L-Line (optional)
Figure 3 — Server and client topology
“K-Line” is used for communication and initialization, “L-Line” (optional) is used for initialization only.
Special cases are node-to-node connection that means only one server (ECU) 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 detail, 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).
Key
1 K-Line
2 arbitrary bus system
Figure 4 — Gateway topology example
6 © ISO 2016 – All rights reserved
7 Data link layer overview
7.1 General
This document 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 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
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 has 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 (i.e. DL_Data);
type indicates the type of the service primitive (i.e. request);
[parameter 1, .] are parameters that depend on the specific service (i.e. parameter 1 can be the
source address of the sender). The brackets indicate that this part of the parame-
ter 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 following 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 (i.e. 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 with 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.
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
provides the status of the service request.
DL_Data.confirm (
SA
TA
Tatype
8 © ISO 2016 – All rights reserved
)
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 (FB) 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
Line> events and delivers with bytes received from a peer protocol entity
identified by the address information in SA and TA to the adjacent upper layer.
The parameters and are only valid if 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 provides the
status of the service request and the parameter provides result data of the
performed input output control, i.e. 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 is assigned to the (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: 00 – FF
16 16
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.
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: 00 – FF
16 16
Description:
The parameter TA shall be used to encode client and server identifiers.
10 © ISO 2016 – All rights reserved
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: one-to-one communication called physical addressing and one-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
Type: 1 byte
Range: 00 – FF
16 16
Description:
This parameter includes the length of data to be transmitted/received.
7.5.5
Type: string of bytes
Range: not applicable
Description:
This parameter includes all data the higher layer entities exchange.
7.5.6
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 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 service user on the client side.
max
— DoK-Line_UNEXP_PDU
This pa
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...