ISO 15765-2:2011
(Main)Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services
Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services
Véhicules·routiers·—·Communication·de·diagnostic·sur·gestionnaire·de·réseau·de·communication·(DoCAN) — Partie 2: Protocole de transport et services de la couche réseau
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 15765-2
Second edition
2011-11-15
Road vehicles — Diagnostic
communication over Controller Area
Network (DoCAN) —
Part 2:
Transport protocol and network layer
services
Véhicules routiers — Communication de diagnostic sur gestionnaire de
réseau de communication (DoCAN ) —
Partie 2: Protocole de transport et services de la couche réseau
Reference number
ISO 15765-2:2011(E)
©
ISO 2011
---------------------- Page: 1 ----------------------
ISO 15765-2:2011(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing 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 2011 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 15765-2:2011(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 1
4 Conventions . 3
5 Document overview . 3
6 Network layer overview . 5
6.1 General . 5
6.2 Services provided by network layer to higher layers . 5
6.3 Internal operation of network layer . 5
7 Network layer services . 7
7.1 General . 7
7.2 Specification of network layer service primitives . 7
7.3 Service data unit specification .10
8 Transport layer protocol .13
8.1 Protocol functions .13
8.2 SingleFrame transmission .13
8.3 Multiple-frame transmission .13
8.4 Transport layer protocol data units .17
8.5 Protocol control information specification .18
8.6 Maximum number of FC.WAIT frame transmissions (N_WFTmax) .24
8.7 Network layer timing .24
8.8 Interleaving of messages .29
9 Data link layer usage .30
9.1 Data link layer service parameters .30
9.2 Data link layer interface services .30
9.3 Mapping of the N_PDU fields .30
9.4 CAN frame data length code (DLC) .33
Annex A (normative) Use of normal fixed and mixed addressing with data link layer according to SAE
J1939 .35
Annex B (normative) Reserved CAN Ids .38
Bibliography .39
© ISO 2011 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 15765-2:2011(E)
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 15765-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 15765-2:2004), which has been technically
revised.
ISO 15765 consists of the following parts, under the general title Road vehicles — Diagnostic communication
over Controller Area Network (DoCAN):
— Part 1: General information and use case definition
— Part 2: Transport protocol and network layer services
— Part 3: Implementation of unified diagnostic services (UDS on CAN)
— Part 4: Requirements for emissions-related systems
iv © ISO 2011 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 15765-2:2011(E)
Introduction
This part of ISO 15765 has been established in order to define common requirements for vehicle diagnostic
systems implemented on a controller area network (CAN) communication link, as specified in ISO 11898.
Although primarily intended for diagnostic systems, it also meets requirements from other CAN-based systems
needing a network layer protocol.
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 as shown
in Table 1.
Table 1 — Enhanced and legislated on-board diagnostics specifications
applicable to the OSI layers
Vehicle-
manufacturer- Legislated OBD Legislated WWH-OBD
Applicability OSI 7 layers
enhanced (on-board diagnostics) (on-board diagnostics)
diagnostics
ISO 14229-1,
Application (layer 7) ISO 15031-5 ISO 27145-3, ISO 14229-1
ISO 14229-3
ISO 15031-2, ISO 27145-2, SAE 1930-DA,
ISO 15031-5, SAE J1979-DA, SAE J2012-DA,
Vehicle manufacturer ISO 15031-6, SAE J1939:2011,
Presentation (layer 6)
specific SAE J1930-DA, Appendix C (SPN),
SAE J1979-DA, SAE J1939-73:2010,
SAE J2012-DA Appendix A (FMI)
Seven layers
according to
Session (layer 5) ISO 14229-2
ISO/IEC 7498-1
Transport protocol
and
ISO 15765-4,
(layer 4)
ISO/IEC 10731 ISO 15765-2ISO 15765-2
ISO 15765-2
Network (layer 3)
Data link (layer 2) ISO 11898-1 ISO ISO
ISO 11898-2 15765-4 27145-4
ISO 15765-4,
ISO 11898-3 ISO 11898-1,
ISO 11898-1,
ISO 11898-5 ISO 11898-2
Physical (layer 1)
ISO 11898-2
or
user defined
The application layer services covered by ISO 14229-3 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-3
is also compatible with most diagnostic services defined in national standards or vehicle manufacturer’s
specifications.
The transport protocol and network layer services covered by this part of ISO 15765 have been defined to be
independent of the physical layer implemented, and a physical layer is only specified for legislated OBD.
For other application areas, ISO 15765 can be used with any CAN physical layer.
© ISO 2011 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 15765-2:2011(E)
Road vehicles — Diagnostic communication over Controller
Area Network (DoCAN) —
Part 2:
Transport protocol and network layer services
1 Scope
This part of ISO 15765 specifies a transport protocol and network layer services tailored to meet the requirements
of CAN-based vehicle network systems on controller area networks as specified in ISO 11898. 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 controller area network (DoCAN) protocol supports the standardized
service primitive interface as specified in ISO 14229-2.
This part of ISO 15765 provides the transport protocol and network layer services to support different
application-layer implementations such as
— enhanced vehicle diagnostics (emissions-related system diagnostics beyond legislated functionality, non-
emissions-related system diagnostics),
— emissions-related on-board diagnostics (OBD) as specified in ISO 15031, and
— world-wide harmonized on-board diagnostics (WWH-OBD) as specified in ISO 27145.
2 Normative references
The following referenced documents are indispensable for the application 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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1 apply.
3.2 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
BS BlockSize
CAN controller area network
CF ConsecutiveFrame
© ISO 2011 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 15765-2:2011(E)
confirm confirmation service primitive
CTS continue to send
DL DataLength
DoCAN diagnostic communication over CAN
ECU electronic control unit
FC FlowControl
FF FirstFrame
FF_DL FirstFrame data length
FMI failure mode indicator
FS FlowStatus
indication indication service primitive
Mtype message type
N_AE network address extension
N_AI network address information
N_Ar network layer timing parameter Ar
N_As network layer timing parameter As
N_Br network layer timing parameter Br
N_Bs network layer timing parameter Bs
N_ChangeParameter network layer service name
N_Cr network layer timing parameter Cr
N_Cs network layer timing parameter Cs
N_Data network data
N_PCI network protocol control information
N_PCItype network protocol control information type
N_PDU network protocol data unit
N_SA network source address
N_SDU network service data unit
N_TA network target address
N_TAtype network target address type
N_USData network layer unacknowledged segmented data transfer service name
NW network
NWL network layer
OBD on-board diagnostics
2 © ISO 2011 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 15765-2:2011(E)
OSI Open Systems Interconnection
PCI protocol control information
SF SingleFrame
SN SequenceNumber
SPN suspect parameter number
STmin SeparationTime minimum
UDS unified diagnostic services
WWH-OBD world-wide harmonized OBD
4 Conventions
ISO 15765 is based on the conventions discussed in the OSI service conventions (ISO/IEC 10731) as they
apply for diagnostic services.
5 Document overview
Figure 1 illustrates the most applicable application implementations utilizing the DoCAN protocol.
© ISO 2011 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 15765-2:2011(E)
ISO 15765-1
DoCAN
General information and
use case definition
Enhanced
Emissions-
WWH-OBD
Diagnostics
related OBD
ISO 15031-5
ISO 14229-1 UDS
ISO 14229-3 ISO 27145-3
subset
Specification and Emissions-related
OSI Layer 7
UDSonCAN WWH-OBD
requirements OBD services
Application
Vehicle ISO 15031-2, -5, -6
ISO 27145-2
manufacturer Emissions-related
OSI Layer 6
WWH-OBD
specific OBD data definition
Presentation
ISO 14229-2 UDS
ISO 14229-2 UDS
1 : 1
Session layer
OSI Layer 5
Session layer services
services
Session
Standardized Service Primitive Interface
CAN diagnostic communication protocol (DoCAN)
OSI Layer 4
ISO 15765-2
Transport
DoCAN
Transport
protocol
and
network
layer services
OSI Layer 3
Network
ISO 15765-4
DoCAN
ISO 11898-1 CAN
Data link layer
Requirements for
OSI Layer 2
and physical emissions- related
Data Link
signalling
systems
ISO 11898 CAN
ISO 11898 CAN
Part 1: Data link layer and physical signalling
Part 2: High- speed medium access unit
Part 1: Data link
Part 3: Low-speed , fault-tolerant, medium-
layer and physical
OSI Layer 1
dependent interface
signalling
Physical
Part 5: High-speed medium access unit
Part 2: High-speed
with low-power mode
medium access unit
Figure 1 — DoCAN document reference according to the OSI model
4 © ISO 2011 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 15765-2:2011(E)
6 Network layer overview
6.1 General
This part of ISO 15765 specifies an unconfirmed network layer communication protocol for the exchange of
data between network nodes, e.g. from ECU to ECU, or between external test equipment and an ECU. If the
data to be transferred do not fit into a single CAN frame, a segmentation method is provided.
In order to describe the functioning of the network layer, it is necessary to consider services provided to higher
layers and the internal operation of the network layer.
6.2 Services provided by network layer to higher layers
The service interface defines a set of services that are needed to access the functions offered by the network
layer, i.e. transmission/reception of data and setting of protocol parameters.
Two types of service are defined.
a) Communication services
These services, of which the following are defined, enable the transfer of up to 4 095 bytes of data.
1) N_USData.request
This service is used to request the transfer of data. If necessary, the network layer segments the data.
2) N_USData_FF.indication
This service is used to signal the beginning of a segmented message reception to the upper layer.
3) N_USData.indication
This service is used to provide received data to the higher layers.
4) N_USData.confirm
This service confirms to the higher layers that the requested service has been carried out (successfully
or not).
b) Protocol parameter setting services
These services, of which the following are defined, enable the dynamic setting of protocol parameters.
1) N_ChangeParameter.request
This service is used to request the dynamic setting of specific internal parameters.
2) N_ChangeParameter.confirm
This service confirms to the upper layer that the request to change a specific protocol has been
carried out (successfully or not).
6.3 Internal operation of network layer
The internal operation of the network layer provides methods for segmentation, transmission with FlowControl,
and reassembly. The main purpose of the network layer is to transfer messages that might or might not fit in a
single CAN frame. Messages that do not fit into a single CAN frame are segmented into multiple parts, where
each can be transmitted in a CAN frame.
Figures 2 and 3 show, respectively, an example of an unsegmented message transmission and of a segmented
message transmission.
© ISO 2011 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 15765-2:2011(E)
Sender Receiver
SingleFrame (SF)
Figure 2 — Example of an unsegmented message
Sender Receiver
FirstFrame
(FF)
FlowControl frame
(FC)
ConsecutiveFrame
(CF)
ConsecutiveFrame
(CF)
ConsecutiveFrame
(CF)
FlowControl frame
(FC)
ConsecutiveFrame
(CF)
ConsecutiveFrame
(CF)
Figure 3 — Example of a segmented message
FlowControl is used to adjust the sender to the network layer capabilities of the receiver. This FlowControl
scheme allows the use of diagnostic gateways and sub-networks.
6 © ISO 2011 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 15765-2:2011(E)
7 Network layer services
7.1 General
All network layer services have the same general structure. To define the services, three types of service
primitive are specified:
— a service request primitive, used by higher communication layers or the application to pass control
information and data required to be transmitted to the network layer;
— a service indication primitive, used by the network layer to pass status information and received data to
upper communication layers or the application;
— a service confirmation primitive, used by the network layer to pass status information to higher
communication layers or the application.
This service specification does not specify an application programming interface, but only a set of service
primitives that are independent of any implementation.
All network layer services have the same general format. Service primitives are written in the form:
service_name.type (
parameter A,
parameter B
[,parameter C, .]
)
where “service_name” is the name of the service, e.g. N_USData, “type” indicates the type of service primitive,
and “parameter A, parameter B [,parameter C, .]” are the N_SDU as a list of values passed by the service
primitive. The square brackets indicate that this part of the parameter list may be empty.
The service primitives define how a service user (e.g. diagnostic application) cooperates with a service provider
(e.g. network layer). The following service primitives are specified in this part of ISO 15765: request, indication
and confirm.
— 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.
7.2 Specification of network layer service primitives
7.2.1 N_USData.request
The service primitive requests transmission of with bytes from the sender to the
receiver peer entities identified by the address information in N_SA, N_TA, N_TAtype [and N_AE] (see 7.3 for
parameter definition).
© ISO 2011 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 15765-2:2011(E)
N_USData.request (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
Each time the N_USData.request service is called, the network layer shall signal the completion (or failure) of
the message transmission to the service user by issuing an N_USData.confirm service call.
7.2.2 N_USData.confirm
The N_USData.confirm service is issued by the network layer. The service primitive confirms the completion
of an N_USData.request service identified by the address information in N_SA, N_TA, N_TAtype [and N_AE].
The parameter provides the status of the service request (see 7.3 for parameter definition).
N_USData.confirm (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
7.2.3 N_USData_FF.indication
The N_USData_FF.indication service is issued by the network layer. The service primitive indicates to the
adjacent upper layer the arrival of a FirstFrame (FF) of a segmented message received from a peer protocol
entity, identified by the address information in N_SA, N_TA, N_TAtype [and N_AE] (see 7.3 for parameter
definition). This indication shall take place upon receipt of the FF of a segmented message.
N_USData_FF.indication (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
The N_USData_FF.indication service shall always be followed by an N_USData.indication service call from
the network layer, indicating the completion (or failure) of message reception.
An N_USData_FF.indication service call shall only be issued by the network layer if a correct FF message
segment has been received.
If the network layer detects any type of error in an FF, then the message shall be ignored by the network layer
and no N_USData_FF.indication shall be issued to the adjacent upper layer.
If the network layer receives an FF with a data length value (FF_DL) that is greater than the available receiver
buffer size, then this shall be considered as an error condition and no N_USData_FF.indication shall be issued
to the adjacent upper layer.
7.2.4 N_USData.indication
The N_USData.indication service is issued by the network layer. The service primitive indicates
events and delivers with bytes received from a peer protocol entity identified by the
8 © ISO 2011 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 15765-2:2011(E)
address information in N_SA, N_TA, N_TAtype [and N_AE] to the adjacent upper layer (see 7.3 for parameter
definition).
The parameters and are valid only if equals N_OK.
N_USData.indication (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
The N_USData.indication service call is issued after reception of a SingleFrame (SF) message or as an
indication of the completion (or failure) of a segmented message reception.
If the network layer detects any type of error in an SF, then the message shall be ignored by the network layer
and no N_USData.indication shall be issued to the adjacent upper layer.
7.2.5 N_ChangeParameters.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 7.3 for parameter definition).
A parameter change is always possible, except after reception of the FF (N_USData_FF.indication) and until
the end of reception of the corresponding message (N_USData.indication).
N_ChangeParameter.request (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
This is an optional service that can be replaced by implementation of fixed parameter values.
7.2.6 N_ChangeParameter.confirm
The service primitive confirms completion of an N_ChangeParameter.confirm service applying to a message
identified by the address information in N_SA, N_TA, N_TAtype [and N_AE] (see 7.3 for parameter definition).
N_ChangeParameter.confirm (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
© ISO 2011 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO 15765-2:2011(E)
7.3 Service data unit specification
7.3.1 Mtype, Message type
Type: enumeration
Range: diagnostics, remote diagnostics
Description: The parameter Mtype shall be used to identify the type and range of address information
parameters included in a service call. This part of ISO 15765 specifies a range of two values for this parameter.
The intention is that users of this part of ISO 15765 can extend the range of values by specifying other types
and combinations of address information parameters to be used with the network layer protocol specified in
this part of ISO 15765. For each such new range of address information, a new value for the Mtype parameter
shall be specified to identify the new address information.
— If Mtype = diagnostics, then the address information N_AI shall consist of the parameters N_SA, N_TA,
and N_TAtype.
— If Mtype = remote diagnostics, then the address information N_AI shall consist of the parameters N_SA,
N_TA, N_TAtype, and N_AE.
7.3.2 N_AI, Address Information
7.3.2.1 N_AI description
These parameters refer to addressing information. As a whole, the N_AI parameters are used to identify
the source address (N_SA), the target address (N_TA) of message senders and recipients, as well as the
communication model for the message (N_TAtype) and the optional address extension (N_AE).
7.3.2.2 N_SA, Network Source Address
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description: The N_SA parameter shall be used to encode the sending network layer protocol entity.
7.3.2.3 N_TA, Network Target Address
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description: The N_TA parameter shall be used to encode one or multiple (depending on the N_TAtype: physical
or functional) receiving network layer protocol entities.
7.3.2.4 N_TAtype, Network Target Address type
Type: enumeration
Range: physical, functional
Description: The parameter N_TAtype is an extension to the N_TA parameter. It shall be used to encode the
communication model used by the communicating peer entities of the network layer. Two communication
models are specified: 1 to 1 communication, called physical addressing, and 1 to n communication, called
functional addressing.
— Physical addressing (1 to 1 communication) shall be supported for all types of network layer messages.
— Functional addressing (1 to n communication) shall only be supported for SingleFrame communication.
10 © ISO 2011 – All rights reserved
---------------------- Page: 15 ----------------------
ISO 15765-2:2011(E)
7.3.2.5 N_AE, Network Address Extension
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description: The N_AE parameter is used to extend the available address range for large networks, and to
encode both sending and receiving network layer entities of sub-networks other than the local network where
the communication takes place. N_AE is only part of the addressing information if Mtype is set to remote
diagnostics.
7.3.3
Type: 12 bits
Range: 0x001 - 0xFFF
Description: This parameter includes the length of data to be transmitted/received.
7.3.4
Type: string of bytes
Range: not applicable
Description: This parameter includes all data that the higher-layer entities exchange.
7.3.5
Type: enumeration
Range: STmin, BS
Description: This parameter identifies a parameter of the network layer.
7.3.6
Type: 1 byte unsigned integer value
Range: 0x00 – 0xFF
Description: This parameter is assigned to a protocol parameter as indicated in 7.2.5.
7.3.7
Type: enumeration
Range: N_OK, N_TIMEOUT_A, N_TIMEOUT_Bs, N_TIMEOUT_Cr, N_WRONG_SN, N_INVALID_FS, N_
UNEXP_PDU, N_WFT_OVRN, N_BUFFER_OVFLW, N_ERROR
Description: This parameter contains the status relating to the outcome of a service execution. If two or more
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.