ISO/TC22/SC3/WG1/TF2 N
124
Date: 1998-06-24
ISO/WD 15765-2
ISO/TC 22/SC 3/WG 1
Secretariat: SMS, issue 0.7
Road Vehicle – Diagnostic systems – Diagnostics on CAN – Part 2:
Network layer services
Document type: International Standard
Document subtype: Not applicable
Document stage: (20) Preparatory
Document language: E
ISOSTD ISO Template Version 3.0 1997-02-07
Page: 1 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
Contents
1. SCOPE.....................................................................................................................................................................5
2. NORMATIVE REFERENCE(S) ..........................................................................................................................5
2.1 ISO PUBLICATIONS .............................................................................................................................................5
3. TERM(S) AND DEFINITION(S)..........................................................................................................................6
4. SYMBOLS (AND ABBREVIATED TERMS) .....................................................................................................6
5. OPEN SYSTEMS INTERCONNECTION (OSI) STANDARD REFERENCE MODEL................................7
6. SPECIFICATION SCOPE ....................................................................................................................................8
7. NETWORK LAYER..............................................................................................................................................9
7.1 OVERVIEW ..........................................................................................................................................................9
7.2 PROTOCOL LAYER SERVICES .............................................................................................................................10
7.2.1 Unacknowledged and Segmented data transfer........................................................................................10
7.2.2 Segmented message reception in progress ...............................................................................................11
7.2.3 Network layer error indication .................................................................................................................11
7.2.4 Change protocol parameters ....................................................................................................................12
7.3 PROTOCOL LAYER ENTITY .................................................................................................................................13
7.3.1 Addressing scheme....................................................................................................................................13
7.3.2 Protocol Data unit (PDU) ........................................................................................................................13
7.3.3 Protocol Control Information (PCI).........................................................................................................15
7.4 PROTOCOL LAYER TIMINGS AND ASSOCIATED ACTIONS .....................................................................................19
7.4.1 Monitored time interval (error detection).................................................................................................19
7.4.2 Consecutive frame (CF) transmission time...............................................................................................21
7.4.3 Wait frame (FC.WT) transmission time ...................................................................................................23
7.5 INTERLEAVING OF MESSAGES ............................................................................................................................24
7.6 DATA LINK LAYER INTERFACE...........................................................................................................................25
7.6.1 Services.....................................................................................................................................................25
7.6.2 CAN bus frame definition .........................................................................................................................26
7.6.3 Mapping of D_UUData.req onto L_Data.request service primitive ........................................................27
7.6.4 Mapping of L_Data.indication onto D_UUData.ind service primitive ....................................................28
8. DRAFT HISTORY...............................................................................................................................................29
9. ANNEXE ...............................................................................................................................................................30
9.1 TIME-OUT VALUES SETTING REQUIREMENTS .....................................................................................................30
Page: 2 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
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 3.
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.
International Standard ISO 15765 was prepared by Technical Committee ISO/TC 22, Road vehicles,
Subcommittee SC 3, Electrical and electronic equipment.
ISO 15765 consists of the following parts, under the general title Road vehicles – Diagnostic systems –
Diagnostics on CAN:
—
—
—
—
—
Part 1: Application layer and session layer services
Part 2: Network layer services
Part 3: Application layer services for enhanced diagnostics - Keyword Protocol 2000
Part 4: Requirements for emission-related systems
Part 5: Requirements for truck & bus systems
Annex X forms an integral part of this part of ISO 15765.
Annex X of this part of ISO 15765 is given for information only.
1 Introduction
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 Road
vehicles - Interchange of digital information - Controller area network (CAN) for high-speed
communication and ISO 11519-2 Road vehicles - Low-speed serial data communication - Part 2 : Lowspeed controller area network (CAN).
Although primarily intended for diagnostic systems, ISO 15765 has been developed to also meet
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 and ISO/IEC 10731 which structures communication systems into seven
layers. When mapped on this model, the services specified by ISO 15765 are broken into:
— diagnostic services (layer 7),
— session layer services (layer 5)
— network layer services (layers 3),
— Controller Area Network (CAN) services (layers 1 and 2),
in accordance with the table below.
Page: 3 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
Table 1 — Applicability and relationship between international standards
Applicability
Vehicle manufacturer
enhanced diagnostics
Emission-related
diagnostics
Commercial vehicle
diagnostics
User defined
ISO 15765-4
ISO 15765-5
ISO 15765-1, ISO 15765-4
ISO 15765-1, ISO 15765-5
Presentation layer
Seven layers
according to
ISO 15765-1
ISO/IEC 7498 and Session layer
ISO/IEC 10731
Transport layer
ISO 15765-1, ISO 15765-4
ISO 15765-1, ISO 15765-5
Network layer
ISO 15765-2
ISO 15765-2, ISO 15765-4
ISO 15765-2, ISO 15765-5
Data link layer
ISO 11898, ISO 11519-2
ISO 11898, ISO 15765-4
ISO 11898, ISO 15765-5
Physical layer
User defined
ISO 11898, ISO 15765-4
User defined
Diagnostic
application
User defined
Application layer ISO 15765-1, ISO 15765-3
The application and session layer services have been defined in compliance with diagnostic services
defined in ISO 14230-3 Road vehicles - Diagnostic systems - Keyword Protocol 2000 - Part 3: Application
layer and ISO 15031-5 Road vehicles - Emission-related diagnostics - Communication between vehicle
and external equipment - Part 5: Emissions related diagnostic services, but are not limited to be used only
with these international standards. ISO 15765-1 will also be compatible with most diagnostic services
defined in national standards or in vehicle manufacturer specifications.
The network layer services have been defined to be independent of the physical layer implemented. A
physical layer is only defined for emission-related systems. For other application areas, ISO 15765 can be
used with any Controller Area Network (CAN) physical layer.
Page: 4 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
Road Vehicle – Diagnostic systems – Diagnostics on CAN – Part 2:
Network layer services
1. Scope
International Standards ISO 15765 is applicable to vehicle diagnostic systems implemented on a
Controller Area Network (CAN) communication network as specified in ISO 11898 or ISO 11519-2.
Part 1: Application layer and session layer services, of ISO 15765, specifies diagnostic services specially
tailored to meet the requirements of CAN based vehicle network systems. It has been defined in
compliance with diagnostic services defined in ISO 14230-3 and ISO 15031-5, but is not limited to be
used only with these international standards. ISO 15765-1 will be compatible also with most diagnostic
services defined in national standards or in vehicle manufacturer specifications.
ISO 15765-1 defines diagnostic services which in some cases already are defined in other International
Standards. This is done when there are specific requirements for CAN based systems, and if so, the
definitions in this International Standards shall be used.
The application layer services establish means for controlling and retrieving information about the CAN
network system.
The session layer services gives guidelines and definitions on how to implement a safe, secure and
powerful vehicle diagnostic system compatible with most vehicle manufacturer specific specifications for
normal application communication.
2. Normative reference(s)
The following standards contain provisions which, through reference in this text, constitute provisions of
this International Standard. At the time of the publication, the editions indicated were valid. All standards
are subject to revision, and parties to agreements based on the International Standard are encouraged to
investigate the possibility of applying the most recent editions of the standards indicated below. Members
of IEC and ISO maintain registers of currently valid International Standards.
2.1 ISO Publications
ISO 7498:
ISO/DIS 11898:1993/Amd.1:
ISO/DIS 14229:
ISO/DIS 14230-3:
ISO/WD 15031-3:
ISO/WD 15765-1:
ISO/WD 15765-3:
ISO/WD 15765-4:
Data Processing Systems, Open Systems Interconnection (OSI)
Standard Reference Model (OSI Model)
1995(E) - Road vehicles, Interchange of Digital Information, Controller
Area Network (CAN) for High Speed Communication
1996, Road vehicles - Diagnostic Systems - Diagnostic services
specification.
1996, Road vehicles - Diagnostic Systems - Keyword Protocol 2000
Part 3: Implementation.
OBD Connector
Road Vehicles - Diagnostic Systems - Communication services
Road Vehicles - Diagnostic Systems - Enhanced Diagnostic Services
Road Vehicles - Diagnostic Systems - Requirements for Emission
Related Systems definition
Page: 5 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
3. Term(s) and definition(s)
4. Symbols (and abbreviated terms)
ADDR
BSmax
CAN
CF
CTS
DL
ECU
FC
FF
FFL
FS
OSI
PCI
RBD
Rx
SF
SN
STmin
Tx
USDT
WFTmax
WT
XDL
Address information
BlockSize (maximum)
Controller Area Network
ConsecutiveFrame
ClearToSend
DataLength
Engine Control Unit
FlowControl
FirstFrame
Fixed Frame Length
FlowStatus
Open System Interconect
Protocol Control Information
ReservedByDocument
Receiver
SingleFrame
SequenceNumber
SeparationTime (minimum)
Transmitter
Unacknowledged Segmented Data Transfer
WaitFrameTransmission(s) (maximum)
WaiT
eXtendedDataLength
Page: 6 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
5. Open Systems Interconnection (OSI) Standard Reference Model
The ISO Reference Model for Open System Interconnection (OSI) provides a common basis for the
structuring of the communication software to provide reliable, data independent, communication services
and to support a wide range of applications.
The ISO/OSI Reference Model describes “Services and Protocols” without making assumptions
concerning the:
• Programming language bindings
• Operating systems bindings
• Application and user interfaces issues
This standard specifies layer three (3) “Network Layer” of the OSI Model by providing scaleable and
network-dependent means to support information exchange between equipment.
Application
Layer
Encapsulation
Presentation
Layer
Receiving
Task
Application
Protocol
Presentation
Protocol
Session
Layer
Session
Protocol
Transport
Layer
Transport
Protocol TH
Network
Layer
Network
Protocol NH
Data Link
Layer
Physical
Layer
PH
SH
Data
Application
Layer
Data
Presentation
Layer
Session
Layer
Data
Transport
Layer
Data
Network
Layer
Data
DH
Data
DT
Data Link
Layer
Physical
Layer
Bit Stream
Actual Data Transmission Path
AH
SH
NH
DT
Application Header
Session Header
Network Header
Data Link Trailer
PH
TH
DH
Presentation Header
Transport Header
Data Link Header
Figure 1: Open Systems Interconnection (OSI) Standard Reference Model (OSI Model)
Page: 7 of 30
Decapsulation
Sending
Task
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
6. Specification scope
The figure below depicts elements defined in this document :
Protocol layer N+1
Protocol layer N+1
Interface services (2)
(1)
…
Protocol layer entity N (4)
PDU (3)
Protocol layer N
Interface services (5)
Protocol layer N-1
Protocol layer N-1
Figure 2 : Detailed protocol layer model
Element (1) : ISO 15765-2
defines the communication protocol that enables data exchange between equipments (ECU - ECU and
ECU - Tester).
Element (2) : Interface services (Layer N)
defines the protocol layer interface services used to enable transfer of data. This section defines both
services and parameters without hinting at any particular implementation scheme.
Element (3) : Protocol Data Units
defines the format of protocol data exchanged between the protocol entity of that layer and its
corresponding peer protocol entity.
Element (4) : Protocol Entity
defines the data communication protocol, i.e. a set of rules known in a communication system, to enable
consistent data exchange.
Element (5) : Interface services (Layer N-1)
defines the interface services of the underlying protocol layer used to enable transfer of data. This section
defines both services and parameters without hinting at any particular implementation scheme.
Page: 8 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7. Network layer
7.1 Overview
The purpose of the network layer is to support the transfer of messages that may fit or not in a single
CAN bus frame. Messages that do not fit in a single frame are transmitted in a way that is compatible with
the operating capability of the receiver peer. The following pictures illustrate this concept.
Frame format of UNSEGMENTED messages :
An unsegmented message is transmitted within a single frame containing a complete request or
response message of a diagnostic service.
Sender
Receiver
DataLength = 2, DL=$2;
SingleFra
me(SF)[(P
CI.DL=2,x
x.. ]
DataLength = 2
DL=$2
Figure 3: Example of UNSEGMENTED message
Frame format of SEGMENTED messages :
A segmented message is transmitted within a set of frames containing a complete (request or) response
message of a diagnostic service.
Sender
Receiver
FirstFrame(F
F)[(PCI.XDL
=$0, DL=$24
,xx.. ]
xx..]
3,FC.STmin,
FC.BSmax=$
C)[ PCI.FS,
FlowControl(F
Multiple
consecutive
frames
DataLength = 36
XDL = $0, DL=$24
Flow Control frame
with implicit
connection set-up
Consecutive
Frame(CF)[(P
CI.SN=1,xx,x
x,.. ]
Consecutive
Frame(CF)[(P
CI.SN=2,xx,x
x,.. ]
Consecutive
Frame(CF)[(P
CI.SN=3,xx,x
x,.. ]
.STmin]
FC.BSmax,FC
C)[ PCI.FS,
FlowControl(F
The last
consecutive
frame include 2
valid user data
bytes
FlowControl
frame because
SN=BSmax
Consecutive
Frame(CF)[(P
CI.SN=4,xx,x
x,.. ]
Consecutive
Frame(CF)[(P
CI.SN=5,xx,x
x,.. ]
End of multiple
frame
Figure 4: Example of SEGMENTED message
Page: 9 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.2 Protocol layer services
This service specification does not specify any implementation requirements but provides abstract
services prototypes to support data exchange.
7.2.1 Unacknowledged and Segmented data transfer
Service name :
N_USData
Syntax :
internal service
Request :
N_USData.req(<AI>, <AF>, <MessageData>, <Length>)
Confirmation :
N_USData.con(<Result>)
Indication :
N_USData.ind(<AI>, <AF>, <MessageData>, <Length>, <Result>)
Parameter :
AI :
AS :
MessageData :
Length :
Result :
Description :
Addressing Information, e.g. diagnostics target and source addresses.
Addressing format, e.g. OBD, Trailer diagnostics, enhanced.
Message data to be transferred
Length of <MessageData> parameter (bytes)
Result of the requested and indicated service
The service primitive N_USData.req requests transmission of data
<MessageData> having a length <Length> to the recipient(s) identified by the
target address encapsulated in <AI>.
The service primitive N_USData.con confirms the completion of its
corresponding N_USData.req service. The parameter <Result> provides the
status of the completed N_USData.req service. The service primitive
N_USData.ind indicates to the adjacent upper layer availability of a received
message from a sender identified by the source address encapsulated in <AI>.
Results :
E_NWL_OK :
successful service completion
Page: 10 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.2.2 Segmented message reception in progress
Service name :
N_USData_FF
Syntax :
internal service
Indication :
N_USData_FF.ind(<AI>, <AF>, <Result>)
Parameter :
AI :
AF :
Result :
Addressing Information, e.g. diagnostics target and source addresses.
Addressing format, e.g. OBD, Trailer diagnostics, enhanced.
Result of the indicated service
Description :
The service primitive N_USData_FF.ind indicates the arrival of a segmented
message to the upper adjacent layer. This indication shall take place upon
reception of a First Frame PDU.
Results :
E_NWL_OK :
successful reception of a first frame.
7.2.3 Network layer error indication
Service name:
N_Error.ind
Syntax:
internal service
Indication :
N_Error.ind(<ErrorStatus>)
Parameter :
ErrorStatus :
Error type.
Description:
The service primitive N_Error.ind indicates to the adjacent upper layer that an
error has occurred.
Results
E_NWL_OK :
E_NWL_TOUT_A :
E_NWL_TOUT_B1:
E_NWL_TOUT_B2 :
E_NWL_TOUT_C :
E_NWL_WRG_SN :
successful service completion.
Time-out A has occurred.
Timeout B1 has occurred
Timeout B2 has occurred
Timeout C has occurred
Received sequence number value SN is not
consistent with internally made calculation of the
receiver.
E_NWL_UNEXP_FRM: Unexpected reception of a protocol data unit (PDU)
that violates protocol rules.
E_NWL_WFT_OVRN :
Received number of flow control frames with wait
state FC.WAIT exceeds maximum counter WFTmax.
Page: 11 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.2.4 Change protocol parameters
Service name:
N_ChangeProtocolParams
Syntax:
internal service
Request:
N_ChangeProtocolParams.req(<Parameter>, <Value>)
Confirmation:
N_ChangeProtocolParams.con(<Parameter>, <Result>)
Parameter :
ParameterName : Identifies the protocol parameter to be changed :
• BS
• ST
Value :
New value requested for the parameter
Result :
Result of the requested service
Description:
The service primitive N_ChangeprotocolParams.req is used to request the
change of an internal parameter’s value as required by <Parameter>.
If a reception or transmission is going on by request’s time, then the change is
not allowed.
- reception : a change is possible before transmission of the first FC and after
reception of the last CF of a segmented message.
- transmission : a change is possible before transmission of FF, and after
transmission of the last CF.
Network Layer on tester
Change
is
possible
Change
is
not allowed
Change
is
possible
Results
E_NWL_OK :
E_NWL_TX_ON :
E_NWL_RX_ON :
E_NWL_WRG_PARAM:
E_NWL_WRG_VALUE :
Subnet1
Network Layer on UCEs
Change
is
possible
Change
is
not allowed
Change
is
possible
successful service completion.
non-permitted service execution, transmission taking place.
non-permitted service execution, reception taking place.
non-permitted service execution ,<Parameter> undefined.
non-permitted service execution,<Value> out of range.
Page: 12 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.3 Protocol layer entity
7.3.1 Addressing scheme
The protocol layer supports two address field lengths to transmit addressing information. The number of
data bytes transported within a single bus frame is set given the type of addressing scheme chosen. The
following schemes are defined :
NORMAL addressing scheme :
Addressing field :
The CAN bus identifier field is provided to encapsulate the diagnostic application addresses. The
addressing information (e.g. source address, target address) shall be fitted within the CAN frame
identifier.
Data field :
8 data byte per bus frame
EXTENDED addressing scheme :
Addressing field :
st
The CAN bus identifier and 1 data byte of the CAN data field are provided to encapsulate the
diagnostic application addresses. The addressing information (source address, target address) shall
st
be fitted within both the CAN frame identifier and the 1 byte of the CAN bus data field as defined in
the respective diagnostic ISO 15765 specifications, e.g. ISO15765-4 : OBD.
Data field :
7 data byte per bus frame
7.3.2 Protocol Data unit (PDU)
Purpose :
The protocol data unit (PDU) enables the transfer of data between peer protocol entities. A PDUs
consists of various fields whose intents are known to each peer protocol entities. Those fields enables
each protocol entity to act in conformance with a set of communication rules as defined in this document.
Description :
The PDU consists of the following fields :
Addressing information
Protocol Control Information
Data
Figure 5 - PDU format
1) Addressing information (AI) :
Purpose :
This field contains addressing data that identify recipient(s) and sender between which data exchange
takes place. The addressing information consists of the diagnostic target and source addresses.
Size :
NORMAL addressing scheme
EXTENDED addressing scheme
: CAN identifier field length
st
: CAN identifier field length + 1 data byte of data field frame.
2) Protocol Control Information (PCI) :
Purpose :
This field identifies the type of PDU’s exchanged. This enables a receiving protocol entity to select the
appropriate protocol rule set to carry out the data transfer.
Possible parameters can be associated with the PCI, i.e. BSmax, STmin, DL.
The PCI identifies the following PDU’s :
Page: 13 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
Table 1 - PCI type
PCI type
First Frame (FF)
Consecutive Frame (CF)
Flow Control frame (FC)
Single Frame (SF)
Description
first frame of a segmented message
frame that transports data only.
frame that controls the arrival of consecutive
frames (CF) blocks.
frame that transports data which fit into a single
bus frame.
Size :
1 byte
3) Message data :
Purpose :
This field contains data to be exchanged and protocol control information parameters as applicable.
Size :
Table 2 - PDU data field length
PCI type
Length of PDU’s data field
Normal addressing
Extended addressing
First Frame (FF)
7 bytes
Flow Control frame (FC)
6 bytes
2 bytes
Consecutive Frame (CF)
7 bytes
6 bytes
Exception :
The length of the data field of the last CF of a
message depends on the message length
Single Frame (SF)
1 to 7 bytes
Page: 14 of 30
1 to 6 bytes
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.3.3 Protocol Control Information (PCI)
Each PDU is encoded for identification by means of a PCI as defined below :
Table 3: Encoding of Protocol Control Information (PCI)
USDT PCI encoding
PCI name
PCI byte
Mnemonic
7
6
5
4
SF
0
0
0
0
DL
FirstFrame
FF
0
0
0
1
XDL
ConsecutiveFrame
CF
0
0
1
0
SN
Flow Control frame
FC
0
0
1
1
FS
SingleFrame
ReservedByDocument
RBD
3
2
1
$40 through $FF
7.3.3.1 SingleFrame (SF)
For unsegmented message, the USDT protocol provides an optimised implementation of the network
protocol with the message length embedded in the PCI byte only.
7.3.3.1.1 SF.DataLength (DL)
Table 4: USDT Protocol Control Information (PCI) : SF.DL
USDT PCI encoding
PCI name
PCI byte
Mnemonic
7
6
5
4
SF
0
0
0
0
SingleFrame
3
data bytes
2
1
0
+1 … +6/7
xx … xx
DL
DataLength (DL) defined in a SingleFrame (SF) shall be encoded out of the PCI low nibble value. The
PCI byte is not included in the data length calculation.
The bit “3” shall always be set to zero (0) since CAN frames allow for a maximum of eight (8) data bytes
(PCI byte included).
7.3.3.2 FirstFrame (FF)
For segmented message, the first frame is encoded as a FirstFrame (FF). On receipt of a FirstFrame
(FF) PDU the receiving network layer entity shall start to assemble the segmented message.
7.3.3.2.1 FF.EXtendedDataLength (XDL)
Table 5: USDT Protocol Control Information (PCI) : FF.XDL
USDT PCI encoding
PCI byte
PCI name
Mnemonic
7
6
5
4
FirstFrame
FF
0
0
0
1
3
data bytes
2
1
XDL
0
+1
+2 … +6/7
DL
xx … xx
The eXtendedDataLength (XDL) shall be encoded out of the data byte #1 which follows the PCI byte and
the PCI low nibble value. This results into a twelve (12) bit eXtendedDataLength (XDL) value where the
least significant bit (LSB) is specified to be bit “0” of the data byte #1 and the most significant bit (MSB) is
bit “3” of the PCI byte.
The eXtendedDataLength (XDL) can specify a maximum of four thousand and ninety five (4095) bytes of
user data. The PCI byte is not included in the data length calculation.
7.3.3.2.2 FF.DataLength (DL)
Page: 15 of 30
0
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
Table 6: USDT Protocol Control Information (PCI) : FF.DL
USDT PCI encoding
PCI byte
PCI name
Mnemonic
7
6
5
4
FirstFrame
FF
0
0
0
1
3
data bytes
2
1
0
XDL
+1
+2 … +6/7
DL
xx … xx
This field encodes the lower eight bits of the message data length. This field needs to be interpreted
along with XDL for the receiver to determine the message length.
7.3.3.3 FlowControl frame (FC)
The purpose of FlowControl (FC) is to prevent a sender node to overpower a receiver node. FlowControl
(FC) frame shall be sent to the sender peer after correct reception of a) a FirstFrame (FF) and b) the last
ConsecutiveFrame (CF) of a block of frame provided that further ConsecutiveFrame (CF) need(s) to be
sent in a new block.
7.3.3.3.1.1 FC.FlowStatus (FS)
Table 7: Definition of Protocol Control Information (PCI) : FC.FS
USDT PCI encoding
PCI name
PCI byte
Mnemonic
7
6
5
4
FC
0
0
1
1
FlowControl frame
3
data bytes
2
1
0
FS
+1
+2
+3 … +6/7
BSmax
STmin
N/A
The FlowStatus (FS) indicates to the sender whether it can proceed the message transmission. The flow
status (FS) shall be encoded in the low nibble of the PCI byte of the FlowControl (FC) frame.
The FlowStatus (FS) network protocol parameter is defined as follows :
Table 8: Protocol Control Information (PCI) : FC.FS
PCI FlowStatus (FS) lower nibble
3
2
1
0
0
0
0
0
Description of FlowStatus (FS) network protocol information
ClearToSend (CTS)
This parameter value is sent to the sender to resume message
transmission.
Flow control parameters (BSmax, STmin) shall be taken into account by
the sender only upon reception of the FlowControl.ClearToSend
(FC.CTS) frame that follows the FirstFrame (FF).
0
0
0
1
WaiT (WT)
This parameter value is sent by the receiver during the reception of a
multiple frame message to inform the sender to not resume
transmission and wait for an FC.CTS.
7.3.3.3.1.1.1 FC.BlockSize (BSmax)
Table 9: Definition of Protocol Control Information (PCI) : FC.BS
USDT PCI encoding
PCI name
FlowControl frame
PCI byte
Mnemonic
7
6
5
4
FC
0
0
1
1
3
Page: 16 of 30
data bytes
2
1
FS
0
+1
+2
+3 … +6/7
BSmax
STmin
N/A
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
The network protocol BlockSize (BS) parameter is used to request a data transfer in which a block of
BlockSize (BS) Consecutive Frames (CF) can be sent without intermediate flow control frame (FC) from
the receiving network entity. The BlockSize (BS) parameter shall be within the range of zero (0) to two
hundred fifty five (255).
Table 10: Definition of BlockSize (BS)
BlockSize (BS)
Description
0
If the BlockSize (BSmax) parameter value in the FlowControl (FC) frame
(FC.BSmax) is set to zero (0) by the receiver no further flow control shall be
performed during the transmission of ConsecutiveFrame(s) (CF). Only one (1)
FlowControl (FC) frame is sent after the FirstFrame (FF) to inform the sender on
how to proceed.
1 ≤ BlockSize (BS) ≤ 255
If the BlockSize (BSmax) parameter value in the FlowControl (FC) frame
(FC.BSmax) is set to a value within the range of one (1) to two hundred fifty five
(255) by the receiver then flow control shall be performed accordingly.
7.3.3.3.1.1.2 SeparationTime (STmin)
Table 11: Definition of FlowStatus (FS) in the PCI byte
USDT PCI encoding
PCI name
FlowControl frame
PCI byte
Mnemonic
7
6
5
4
FC
0
0
1
1
3
data bytes
2
1
FS
0
+1
+2
+3 … +6/7
BSmax
STmin
N/A
The minimum SeparationTime (STmin) specifies the minimum time gap between the transmission of
ConsecutiveFrames (CF). This time is specified by the receiver and kept by the sender for a particular
message transmission.
7.3.3.3.1.1.3 Maximum number of FC.Wait frame transmissions (FC.WFTmax)
This variable is defined at system generation time and indicates how many wait frames (FC.WT) can be
consecutively transmitted.
Note: This parameter is local to communication peers and is not transmitted hence not part of the
FlowControl (FC) frame.
The purpose of this variable is to avoid communication sender nodes being potentially hooked-up in case
of a fault condition whereby the latter would be requested to wait continuously.
Table 12: Definition of maximum number of FlowControl.WaitFrameTransmissions (FC.WFTmax)
1 ≤ FC.WFTmax ≤ 15
FC.WFTmax = 0
Flow control relies upon FC.CTS only. Wait flow
control frame not supported.
Maximum number of consecutive wait FC frame to
be sent for a given segmented message.
7.3.3.4 ConsecutiveFrame (CF)
When sending segmented data, all consecutive frames following the first frame (FF) are encoded as
Consecutive Frames (CF). On receipt of a ConsecutiveFrame (CF) the receiving network layer shall
assemble the received data bytes until the whole message is received. The receiving entity shall pass the
assembled message to the adjacent upper protocol layer after the last frame of the message has been
received without error.
7.3.3.4.1 CF.SequenceNumber (SN)
Table 13: Definition of Protocol Control Information (PCI) : CF.SN
Page: 17 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
USDT PCI encoding
PCI name
ConsecutiveFrame
PCI byte
Mnemonic
7
6
5
4
CF
0
0
1
0
3
data bytes
2
1
0
+1 … +6/7
xx … xx
SN
The SequenceNumber (SN) is used to detect duplication or loss of ConsecutiveFrame(s) (CF).
The sequence counter shall use the PCI lower nibble bits for the SequenceNumber (SN) value only.
SequenceNumber (SN) range :
The SequenceNumber (SN) range is zero (0) to fifteen (15).
Conditions to initialise SequenceNumber (SN) :
• The SequenceNumber (SN) is initialised to zero (0) when a) starting transmission of a message and
b) a wraparound of the SequenceNumber (SN) occurs within the transmission of a block of
Consecutive Frames (CF).
• The first consecutive frame (CF) following the FirstFrame (FF) shall be assigned the SN value = 1.
SN's
Sender
Receiver
FirstFrame(FF
)[(PCI.XDL=$
0F, DL=$FF,x
x.. ]
xx..]
3,FC.STmin,
, FC.BSmax=$
FC)[ PCI.FS
FlowControl(
Multiple
consecutive
frames
Flow Control frame
with implicit
connection set-up
Consecutive
Frame(CF)[(P
CI.SN=1,xx,
xx,.. ]
Consecutive
Frame(CF)[(P
CI.SN=2,xx,
xx,.. ]
SN = 1
Consecutive
Frame(CF)[(P
CI.SN=3,xx,
xx,.. ]
...
Consecutive
Frame(CF)[(P
CI.SN= 15,xx,
xx,.. ]
Consecutive
Frame(CF)[(P
CI.SN=00,xx
,xx,..
]
...
Figure 6 : SN values
Page: 18 of 30
SN = 15
SN = 0
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.4 Protocol layer timings and associated actions
7.4.1 Monitored time interval (error detection)
Network Layer of Sender
sub-network
Network Layer of Receiver
D_UUData.req(FF) à
As
D_UUData.con(FF) ß
à D_UUData.ind(FF)
n
ß D_UUData.req(FC.CTS)
B1
Ar
5
D_UUData.ind(FC.CTS) ß
à D_UUData.con(FC)
n
D_UUData.req (CF) à
n
C
As
5
D_UUData.con (CF) ß
5
à D_UUData.ind(CF)
D_UUData.req (CF) à
D1
As
D_UUData.con (CF) ß
à D_UUData.ind(CF)
n
D_UUData.req (CF) à
D1
As
5
D_UUData.con (CF) ß
à D_UUData.ind(CF)
n
ß D_UUData.req(FC.WT)
B2
Ar
5
D_UUData.ind (FC) ß
à D_UUData.con(FC.WT)
ß D_UUData.req(FC.WT)
n
D2
Ar
5
D_UUData.ind (FC) ß
à D_UUData.con(FC.WT)
n
ß D_UUData.req(FC.CTS)
D2
Ar
5
D_UUData.ind (FC) ß
à D_UUData.con(FC.CTS)
D_UUData.req (CF) à
C
As
à D_UUData.ind(CF)
Figure 7: Placement of time-outs
Aforementioned time intervals shall be monitored (sender side : As, B1, B2, D2, Receiver side : Ar, C,
D1).
Page: 19 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.4.1.1 Monitored time interval summary
The following table summarise the monitored time intervals for a given message transfer :
Table 14 - Error detection : monitored time interval
Time interval name
Location
Tx
As
Ar
B1
B2
C
D1
D2
Start monitoring (n)
Stop monitoring (5)
Rx
4
4
4
4
4
4
4
DUUDATA_Req
DUUDATA_Req
DUUDATA_Con(FF)
DUUDATA_Con(block’s last CF)
DUUDATA_Con(FC.CTS)
DUUDATA_Ind(CF)
DUUDATA_Ind(FC.WT)
DUUDATA_Con
DUUDATA_Con
DUUDATA_Ind(FC)
DUUDATA_Ind(CF)
DUUDATA_Ind(CF)
DUUDATA_Ind(block’s next CF)
DUUDATA_Ind(next FC)
7.4.1.2 Monitored time interval time-out values
Table 15 : time-out values
Monitored time interval
time out value (ms)
A
B1
B2
C
D1
D2
1000
1000
1000
1000
1000
1000
7.4.1.3 Action upon expiration of time interval
Upon expiration of one of the monitored time interval, the following action shall be performed :
Table 16 : Error handling
Time interval
Expiration cause
A
Frame not transmitted on time
B1
Frame lost (overwritten)
Receiver disconnected (line cut, timeout on A, ...)
Frame lost (overwritten)
Receiver disconnected (line cut, timeout on A, ...)
Frame or preceding FC lost (overwritten)
Sender disconnected (line cut, timeout on A, ...)
Frame lost (overwritten)
Sender disconnected (line cut, timeout on A, ...)
Frame lost (overwritten)
Receiver disconnected (line cut, timeout on A, ...)
Preceding reception on the receiver is lasting
longer than expected.
B2
C
D1
D2
Page: 20 of 30
Action
Abort transmission
Disconnect
(Reset)
Abort transmission
Repeat WFTmax time
Abort transmission
Repeat WFTmax time
Abort reception
Abort reception
Abort transmission
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.4.2 Consecutive frame (CF) transmission time
Network Layer of Sender
sub-network
Network Layer of Receiver
D_UUData.req(FF) à
D_UUData.con(FF) ß
à D_UUData.ind(FF)
ß D_UUData.req(FC.CTS)
D_UUData.ind (FC.CTS) ß
à D_UUData.con(FC.CTS)
D_UUData.req (CF) à
D_UUData.con (CF) ß
à D_UUData.ind(CF)
n
STmin
s
D_UUData.req (CF) à
D_UUData.con (CF) ß
à D_UUData.ind(CF)
ß D_UUData.req(FC.CTS)
D_UUData.ind (FC.CTS) ß
à D_UUData.con(FC.CTS)
D_UUData.req (CF) à
D_UUData.con (CF) ß
à D_UUData.ind(CF)
Figure 8 - Transmission of FC.WT upon expiration of 'E'
A flow control wait frame (FC.WT) shall be sent to the sender upon expiration (s) of a waiting time
interval STmin .
7.4.2.1 Time interval summary
The following table defines the time interval relating to the transmission of consecutive frames (CF).
Table 17 - CF frame transmission : inter-transmission time
Time interval name
Location
Tx
STmin
4
Start waiting (n)
Stop waiting (5)
Rx
D_UUData.con (CF.SN) and
CF.SN
is
not
the
last
consecutive frame of a block.
STmin expiration
Note: Various time-out values and combinations can lead to various implementation optimisations
which are not hinted by this specification. No implementation restrictions nor hints are made in
this specification document.
Page: 21 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.4.2.2 Time interval value
This specification does not define any default separation time (STmin) between consecutive frames (CF).
7.4.2.3 Action upon expiration of interval time
Upon expiration of the interval time as defined below, the following action shall be performed for a single
message transfer :
Table 18 : flow control wait frame handling
Time interval
STmin
Expiration cause
Sender waiting
Action
D_UUData.req(CF)
Page: 22 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.4.3 Wait frame (FC.WT) transmission time
Network Layer of Sender
sub-network
Network Layer of Receiver
D_UUData.req(FF) à
D_UUData.con(FF) ß
à D_UUData.ind(FF)
n
E1
s
ß D_UUData.req(FC.WT)
D_UUData.ind(FC.WT) ß
à D_UUData.con(FC.WT)
n
5
E1
ß D_UUData.req(FC.CTS)
D_UUData.ind (FC.CTS) ß
à D_UUData.con(FC.CTS)
D_UUData.req (CF) à
D_UUData.con (CF) ß
à D_UUData.ind(CF)
D_UUData.req (CF) à
D_UUData.con (CF) ß
à D_UUData.ind(CF)
n
E2
s
ß D_UUData.req(FC.WT)
D_UUData.ind(FC.WT) ß
à D_UUData.con(FC.WT)
n
5
D_UUData.ind (FC.CTS) ß
E3
ß D_UUData.req(FC.CTS)
à D_UUData.con(FC.CTS)
D_UUData.req (CF) à
D_UUData.con (CF) ß
à D_UUData.ind(CF)
Figure 9 - Transmission of FC.WT upon expiration of 'E'
Page: 23 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.4.3.1 Time interval summary
The following table summarises the respective ‘E’ time intervals for a given message transfer :
Table 19 - FC.WT frame transmission : monitored time interval
Time interval name
Tx
E1
E2
E3
Start monitoring (n)
Location
Stop monitoring (5)
Rx
4
4
4
D_UUDATA_Ind(FF)
D_UUDATA_Ind(last CF of a block)
D_UUDATA_Con(FC.WT)
D_UUDATA_req(FC.CTS)
D_UUDATA_req(FC.CTS)
D_UUDATA_req(FC.CTS)
A flow control wait frame (FC.WT) shall be sent to the sender upon expiration (s) of one of the time
intervals [E1, E2, E3] and FC.WFTmax > 0, see 7.3.3.3.1.1.3.
Note: Various time-out values and combinations can lead to various implementation optimisations
which are not hinted by this specification. No implementation restrictions nor hints are made in
this specification document.
7.4.3.2 Time interval value
Table 20 : time-out values
Monitored time interval
time out value (ms)
E1
E2
E3
TBD
TBD
TBD
7.4.3.3 Action upon expiration of time interval
Upon expiration of one of the time interval, the following action shall be performed for a given message
transfer :
Table 21 : flow control wait frame handling
Time interval
E1
E2
E3
Expiration cause
Receiver not ready to resume reception of new
block of frame.
Receiver not ready to resume reception of new
block of frame.
Receiver not ready to resume reception of new
block of frame.
Action
D_UUData.req(FC.WT)
(WFTmax time)
D_UUData.req(FC.WT)
(WFTmax time)
D_UUData.req(FC.WT)
(WFTmax time)
7.5 Interleaving of messages
The USDT protocol shall be capable to carry out parallel transmission of different messages provided that
they are not mapped onto the same address (NORMAL addressing mode : bus frame identifier;
EXTENDED addressing mode : bus frame identifier and extended address byte) so that the receiving
peer is able to reassemble in a consistent manner received frames to build-up a particular message as
defined at system generation time. This scheme enables gateway operation which requires the ability to
handle different message transmissions “in parallel” across distinct subnetworks.
Page: 24 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.6 Data link layer interface
7.6.1 Services
Service name:
D_UUData
Syntax:
internal service
Request:
D_UUData.req (<AI>, <AF>,<Data>, <Length>)
Confirmation:
D_UUData.ind (<AI>, <AF>, <Data>, <Length>, <Result>)
Indication:
D_UUData.con (<Result>)
Parameter:
AI :
AF :
Data
Result
Addressing information
Addressing format
Reference to the frame data
Result of the requested service
Description:
The service primitive D_UUData.req requests transmission of the data <Data>
over the network. This service maps the addressing information onto the CAN
data frame according to the type of addressing format chosen.
The service primitive D_UUData.con confirms transmission of <Data> onto the
sub-network.
The service primitive D_UUData.ind indicates to the upper adjacent layer arrival
of <Data>.
Result :
E_DLL_OK :
successful service completion
Page: 25 of 30
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.6.2 CAN bus frame definition
This chapter provides an overview of the fitting of data to be transmitted within a single CAN frame. Two
fittings are possible depending on the addressing scheme chosen.
7.6.2.1 CAN bus frame definition : CAN identifier (NORMAL addressing)
The addressing information (AI), shall be encoded within the bus CAN identifier field, according to the
addressing format (AF) used.
Refer to the appropriate ISO 15765 specification for the detailed definition of the Addressing Format (AF).
Table 22: CAN frame example with NORMAL addressing
CAN frame data field
Description
Id
byte 1
byte 2
byte 3
byte 4
byte 5
byte 6
byte 7
byte 8
SF
AI
PCI
Data
Data
Data
Data
Data
Data
Data
FF
AI
PCI
DL
Data
Data
Data
Data
Data
Data
CF
AI
PCI
Data
(Data)
(Data)
(Data)
(Data)
(Data)
(Data)
FC
AI
PCI
BSmax
STmin
(-)
(-)
(-)
(-)
(-)
7.6.2.2 CAN bus frame definition : CAN identifier (EXTENDED addressing)
The addressing information (AI), shall be encoded within the bus CAN identifier field, according to the
addressing format (AF) used.
Refer to the appropriate ISO 15765 specification for the detailed definition of the Addressing Format (AF).
Table 23: CAN frame example with EXTENDED addressing
CAN frame data field
Description
Id
byte 1
byte 2
byte 3
byte 4
byte 5
byte 6
byte 7
byte 8
SF
AI
PCI
Data
(Data)
(Data)
(Data)
(Data)
(Data)
FF
AI
PCI
DL
Data
Data
Data
Data
Data
CF
AI
PCI
Data
(Data)
(Data)
(Data)
(Data)
(Data)
FC
AI
PCI
BSmax
STmin
(-)
(-)
(-)
(-)
7.6.2.3 CAN bus frame definition : DLC
Refer to the appropriate ISO15765 specification for the fixed frame length (FFL) requirements that define
whether the bus frame length is constant or variable.
Page: 26 of 30
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
7.6.3 Mapping of D_UUData.req onto L_Data.request service primitive
The following table summarises the mapping operation necessary to map the ISO 15765 D_UUData parameters within the IS0 11898 LLC service parameters.
Table 24 - Mapping D_UUData.req onto L_Data.request service
ISO 15765 service primitive parameters
<AI>
<AF>
<Data>
<Len.>
Data Link Layer
Mapping operations
ààà
A) Map Addressing information :
ISO 11898 LLC service primitive parameters
Header
Data Field
Id
DLC
1
2
3
5
6
7
1. Id = Set_CAN_Identifier( <AI> )
st
2. 1 data byte = Set_FirstDataByte( <AF> )
• <AF> uses NORMAL addressing scheme
• <AF> uses EXTENDED addressing scheme
B) Map Length :
1. DLC = Set_DLC(<Length>, FFL)
• <AF> uses NORMAL addressing scheme
• <AF> uses EXTENDED addressing scheme
C) Map Data :
1. Data_Field = Set_DataField(<Data>)
• <AF> uses NORMAL addressing scheme
• <AF> uses EXTENDED addressing scheme
L_DATA.request service primitive parameters à
Page: 27 of 30
ID
DLC
Data
8
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
7.6.4 Mapping of L_Data.indication onto D_UUData.ind service primitive
The following table summarises the mapping operation necessary to map the IS0 11898 LLC service parameters onto ISO 15765 D_UUData parameters.
Table 25 - Mapping of L_Data.indication onto D_UUData.ind service
ISO 15765 service primitive parameters
<AI>
<AF>
<Data>
<Len.>
Data Link Layer
Mapping operations
ßßß
A) Map CAN identifier :
1. <AI> = Set_AI( <CAN_Identifier> )
2. <AF> = Set_AF(<CAN_Identifier>)
• <AF> uses NORMAL addressing scheme
• <AF> uses EXTENDED addressing scheme
B) Map Length :
1. <Length> = Set_Length(DLC)
C) Map Data :
1. <Data> = Set_DataField(Data, CAN_Identifier)
• <AF> uses NORMAL addressing scheme
• <AF> uses EXTENDED addressing scheme
<AI>
<AF>
<Data>
<Len.>
à D_UUData.ind service primitive parameters.
Page: 28 of 30
ISO 11898 LLC service primitive parameters
Header
Data Field
Id
DLC
1
2
3
5
6
7
8
ISO / WD 15765 - 2 : Diagnostics Systems - Network Layer
8. DRAFT History
Version
0.1
Date
23.01/98
Change description
Original issue based on Com13/1 v1.2
0.2
0.3
*
03/02/98
*
Changes according to remarks received from
OSEK/COM and ISO/TF2 – see OSEK/VDX/Com24/1
0.4
06/03/98
1. Add Network layer services
2. Update time-outs/timer chapter
3. Conditions for the sender to take into account BS, ST
LucasVarity :
Laurent Roy
0.5
16/06/98
1. Migrate draft in ISO template
2. Define the no flow control USDT protocol extension
3. Complete the time-out section for TF2 revision
LucasVarity :
Laurent Roy
0.6
24/06/98
Following comments from DB : W.Preuschoff
1. Remove Figure 4
2. Remove table 8/9
3. Correct Time-out B1 definition
LucasVarity :
Laurent Roy
0.7
21/09/98
Comments in meeting minutes 13 and 14 .
th
Page: 29 of 30
th
Author
GM :
Gangolf Feiter
Thomas Walter
*
LucasVarity :
Laurent Roy
LucasVarity :
Laurent Roy
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - Network Layer
9. Annexe
9.1 Time-out values setting requirements
Table 26 : time-out values settings requirements
Timeout on the opposite side
B1min
B2min
D2min
Cmin
D1min
Constraint
Internal CPU load
>
>
>
>
>
E1max + Armax
E2max + Armax
E3max + Armax
Fmax + Asmax
Gmax + Asmax
Page: 30 of 30