ISO / WD 15765 Road Vehicles - Diagnostics Systems
Part 2:
Network USDT Protocol
(Unacknowledged Segmented Data Transfer)
Status: Working Draft
Version: 0.4
Date:
March 06, 1998
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
THIS PAGE INTENTIONALLY LEFT BLANK
Page: 2 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
Table of contents
1. INTRODUCTION ...........................................................................................................................................4
2. SCOPE .............................................................................................................................................................4
3. DEFINITIONS AND ABBREVIATIONS ......................................................................................................5
3.1 TERMS DEFINED IN OTHER STANDARDS ..........................................................................................................5
3.1.1 ISO definitions .....................................................................................................................................5
3.1.2 SAE definitions.....................................................................................................................................5
3.2 TERMS DEFINED BY THIS DOCUMENT .............................................................................................................5
4. NORMATIVE REFERENCES .......................................................................................................................5
4.1 ISO PUBLICATIONS ......................................................................................................................................6
4.2 SAE PUBLICATIONS .....................................................................................................................................6
4.3 OTHER PUBLICATIONS ..................................................................................................................................6
5. OPEN SYSTEMS INTERCONNECTION (OSI) STANDARD REFERENCE MODEL (OSI MODEL)...7
6. OPEN CONFIGURATION REQUIREMENTS TO NETWORK-LAYER BASED SYSTEMS..................8
7. ADDRESSING AND SEGMENTATION .....................................................................................................10
7.1 FRAME EXAMPLE WITH NORMAL ADDRESSING ..............................................................................................10
7.2 FRAME EXAMPLE WITH EXTENDED ADDRESSING ...........................................................................................10
7.3 PADDING OF UNUSED DATA BYTES ...............................................................................................................10
7.4 DEFINITION OF A SINGLE FRAME MESSAGE ....................................................................................................11
7.5 DEFINITION OF A MULTIPLE FRAME MESSAGE................................................................................................12
8. NETWORK LAYER.....................................................................................................................................13
8.1 SERVICES ...................................................................................................................................................13
8.2 SERVICES PROVIDED TO UPPER LAYER ..........................................................................................................13
8.2.1 Transfer of unacknowledged and unsegmented data (UUDT)..............................................................13
8.2.2 Transfer of unacknowledged and segmented data (USDT) ..................................................................14
8.2.3 Network layer results..........................................................................................................................15
8.3 SERVICES USED OF LOWER LAYER ................................................................................................................16
8.4 DEFINITION OF PROTOCOL CONTROL INFORMATION (PCI)............................................................................17
8.4.1 Encoding of Protocol Control Information (PCI)................................................................................17
8.4.2 Definition of frame types ....................................................................................................................17
8.5 DEFINITION OF TIME-OUTS AND TIMERS .......................................................................................................22
8.5.1 Placement of time-outs and [Timers]..................................................................................................22
8.5.2 Time-out values setting requirements .................................................................................................23
8.5.3 Time-out values..................................................................................................................................23
8.6 PROTOCOL ERROR HANDLING ......................................................................................................................24
8.6.1 Protocol behaviour upon error detection............................................................................................24
8.6.2 Error detection and reporting capability ............................................................................................24
8.7 INTERLEAVING OF MESSAGES ......................................................................................................................25
9. ANNEX ..........................................................................................................................................................26
9.1 USDT FLOW CONTROL EXAMPLES ...............................................................................................................26
9.1.1 Example of FlowControl with ClearToSend (FC.CTS) ........................................................................27
9.1.2 Example of FlowControl with Wait (FC.WT) ......................................................................................29
9.2 TOTAL NUMBER OF FRAMES REQUIRED FOR SEGMENTED MESSAGE TRANSMISSION ..........................................31
9.3 TOTAL NUMBER OF VALID BYTES .................................................................................................................31
10. DRAFT HISTORY ......................................................................................................................................33
Page: 3 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
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.
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.
•
•
•
•
Part 1: Road Vehicles - Diagnostic Systems - Communication Services
Part 2: Road Vehicles - Diagnostic Systems - Network USDT Protocol
(Unacknowledged Segmented Data Transfer)
Part 3: Road Vehicles - Diagnostic Systems - Enhanced Diagnostic Services
Implementation
• Part 4: Road Vehicles - Diagnostic Systems - Requirements for Emission Related Systems
• Part 5: Road Vehicles - Diagnostic Systems - Requirements for Tachograph Systems
Annex A of this International Standard is for information only.
1. Introduction
This International Standard contains references to SAE publications, which are regularly
amended/updated without any visible change (neither in the numbering, nor any additive
letter, etc.). To ensure precisely to which particular edition this International Standard refers to,
Annex A gives the precise dates of the SAE publications.
2. Scope
This International Standard specifies the requirements for a “Network USDT Protocol
(Unacknowledged Segmented Data Transfer)” which shall be used to bidirectionally
communicate diagnostic service data between a tester (scan tool) and a vehicle data link.
The standard specifies requirements limited to “Diagnostic Services”. For Normal
Communication refer to the OSEK/VDX communication (Open Systems and the
Corresponding Interfaces for Automotive Electronics) specification.
Page: 4 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
3. Definitions and Abbreviations
3.1 Terms defined in other standards
3.1.1 ISO definitions
This document makes use of terms defined in the ISO 14229 Diagnostic Services
Specification document.
3.1.2 SAE definitions
This document makes use of terms defined in the SAE J1930 E/E Systems Diagnostic Terms,
Definitions, Abbreviations & Acronyms document.
3.2 Terms defined by this document
ADDR
BSmax
CAN
CF
CTS
DL
EDC
ERC
FC
FF
FS
MUDBPF
PCI
RBD
SF
SN
STmin
USDT
UUDT
WFTmax
WT
XDL
Address information
BlockSize (maximum)
Controller Area Network
ConsecutiveFrame
ClearToSend
DataLength
ErrorDetectionCapability
ErrorReportingCapability
FlowControl
FirstFrame
FlowStatus
MaxUserDataBytesPerFrame
Protocol Control Information
ReservedByDocument
SingleFrame
SequenceNumber
SeparationTime (minimum)
Unacknowledged Segmented Data Transfer
Unacknowledged Unsegmented Data Transfer
WaitFrameTransmission(s) (maximum)
WaiT
eXtendedDataLength
4. Normative references
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.
Page: 5 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
4.1 ISO Publications
ISO 7498:
Data Processing Systems, Open Systems Interconnection (OSI)
Standard Reference Model (OSI Model)
ISO/DIS 11898:1993/Amd.1: 1995(E) - Road vehicles, Interchange of Digital Information,
Controller Area Network (CAN) for High Speed Communication
ISO/DIS 14229:
1996, Road vehicles - Diagnostic Systems - Diagnostic services
specification.
ISO/DIS 14230-3:
1996, Road vehicles - Diagnostic Systems - Keyword Protocol
2000 Part 3: Implementation.
ISO/WD 15031-3:
OBD Connector
ISO/WD 15765-1:
Road Vehicles - Diagnostic Systems - Communication services
ISO/WD 15765-3:
Road Vehicles - Diagnostic Systems - Enhanced Diagnostic
Services
ISO/WD 15765-4:
Road Vehicles - Diagnostic Systems - Requirements for
Emission Related Systems
4.2 SAE Publications
SAE J1962:
SAE J2284:
SAE J1978:
SAE J1979:
SAE J2178/1:
SAE J2190:
OBD Connector
Recommended Practice for High Speed CAN (HSC) for
Passenger Vehicle Applications
OBD II Scan Tool
E/E Diagnostic Test Modes
Class B Data Communication Network Messages - Detailed
Header Formats and Physical Address Assignments
E/E Enhanced Diagnostic Test Modes
4.3 Other Publications
OSEK/VDX/COM:
Com13/1 : Unacknowledged Segmented Data Transfer (USDT)
protocol definition
Page: 6 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
5. Open Systems Interconnection (OSI) Standard Reference Model
(OSI 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 33
Decapsulation
Sending
Task
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
6. Open configuration requirements to Network-layer based systems
This specification defines the functional and behavioural requirements of a communication
protocol layer whose setting is tightly coupled to the underlying sub-network media used.
Besides, interfacing of automotive heterogeneous sub-networks (e.g. CAN, D2B) is catered
for by means of flow control mechanism and scaleable layer configuration (i.e. data field payload size). It is on this basis that communication layer requirements addressed by this
specification maps to the OSI reference model layer 3 (Network).
Implementation of this protocol layer within sub-network interconnecting equipment depends
on sub-network interfacing requirements : it is the responsibility of the network architect to
decide on a per case basis whether the layer 3 is to be implemented in sub-network
interconnecting devices or not (bus frames repeater will not implement layer 3 but only 1). This
protocol layer can therefore be used in various configurations, e.g. enabling end-to-end
communication.
a)
NODE 1
NODE 2
End-to-End communication session
USDT/UUDT
USDT/UUDT
Sub-Net 1
b)
NODE 1
NODE 2
End-to-End communication session
USDT/UUDT
Sub-Net 1
USDT/UUDT
Repeater
Sub-Net 2
c)
NODE 1
USDT/UUDT
NODE 2
Gateway
Sub-Net 1
USDT/UUDT
Sub-Net 2
Figure 2: Example of various system configurations
Page: 8 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
7. Addressing and segmentation
USDT (Unacknowledged Segmented Data Transfer) shall support different combinations of
addressing and segmentation. For a connection using extended addressing there shall be
eight (8) bits of additional address information in the first byte of each data frame. For
connections not using extended addressing (i.e. normal addressing) there is no additional
address information hence no additional protocol overhead.
7.1 Frame example with normal addressing
Description
Mnemonic
1
2
3
4
5
6
7
8
UUDT
Data
Data
Data
Data
Data
Data
Data
Data
Normal addressing with
segmentation
("single frame")
USDT
PCI
Data
Data
Data
Data
Data
Data
Data
Normal addressing with
segmentation
USDT
PCI
DL
Data
Data
Data
Data
Data
Data
Normal addressing with
segmentation
("consecutive frame")
USDT
PCI
Data
Data
Data
Data
Data
Data
Data
-
-
-
-
-
-
Normal addressing with
segmentation
("flow control")
USDT
STmin
-
-
-
-
-
Normal addressing
no segmentation
("first frame")
PCI
BSmax
Table 1: Frame example with normal addressing
7.2 Frame example with extended addressing
Description
Mnemonic
1
2
3
4
5
6
7
8
extended addressing
no segmentation
UUDT
+ ADDR
EXT
ADDR
Data
Data
Data
Data
Data
Data
Data
extended addressing
with segmentation
("single frame"")
USDT
+ ADDR
EXT
ADDR
PCI
Data
Data
Data
Data
Data
Data
extended addressing
with segmentation
("first frame")
USDT
+ ADDR
EXT
ADDR
PCI
DL
Data
Data
Data
Data
Data
extended addressing
with segmentation
("consecutive frame")
USDT
+ ADDR
EXT
ADDR
PCI
Data
Data
Data
Data
Data
Data
-
-
-
-
-
extended addressing with
segmentation
("flow control")
USDT
+ ADDR
EXT
ADDR
PCI
STmin
-
-
-
-
BSmax
Table 2: Frame example with extended addressing
7.3 Padding of unused data bytes
The USDT protocol can support a data frame length up to sixteen (16) data bytes including
the PCI byte (Protocol Control Information) depending on the underlying type of bus used.
The constant MaxUserDataBytesPerFrame (MUDBPF) specifies the number of user data
Page: 9 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
bytes available per frame based on the data link layer implemented (i.e. CAN MUDBPF =
CANframe - PCI byte = 8 - 1 = 7); D2B MUDBPF = D2Bframe - PCI byte = 12 - 1 = 11).
MUDBPF
Header
PCI
data byte 1 … up to maximum data byte 15
Checksum
data frame length up to n = 16 bytes
Table 3: USDT data frame
Padding of unused data bytes in a single frame message, a flow control frame, and the last
consecutive frame of a multiple frame message shall be performed by all senders. No specific
padding pattern is specified in this standard.
7.4 Definition of a single frame message
A SingleFrame (SF) message is defined to be a unique frame containing a complete request
or response message of a diagnostic service.
Client (Tester)
DataLength = 2
DL=$2; unused
user data bytes are
padded with
random values
Server (ECU)
SingleFrame (SF) [PC
I.DL=$2, xx ... xx]
DataLength = 2
DL=$2
I.DL=$7, xx ... xx]
SingleFrame (SF) [PC
DataLength = 7
DL=$7
DataLength = 7
DL=$7; unused
user data bytes are
padded with
random values
Figure 3: Example of single frame message flow without extended address
Page: 10 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
7.5 Definition of a multiple frame message
A multiple frame message always starts with a:
• FirstFrame (FF) which includes the eXtendedDataLength (XDL) information followed by a
• FlowControl (FC) frame which is sent by the receiver of the FirstFrame followed by
Client (Tester)
DataLength = 36
XDL=$0, DL=$24
Server (ECU)
FirstFrame (FF)
[(PCI.XDL=$0, SF
.DL=$24)=$24, xx
... xx]
DataLength = 36
XDL=$0, DL=$24
]
STmin, xx ... xx
.BSmax=3,FC.
FC
S,
.F
CI
[P
C)
FlowControl (F
Multiple (3)
ConsecutiveFrames
Consecuti
veFrame
(CF) [PCI.S
N=1, xx ...
xx]
Consecuti
veFrame
(CF) [PCI.S
N=2, xx ...
xx]
Consecuti
veFrame
(CF) [PCI.S
N=3, xx ...
xx]
min, xx ... xx]
.BSmax,FC.ST
C) [PCI.FS,FC
(F
l
ro
nt
Co
Flow
Multiple (2)
ConsecutiveFrames
The last
ConsecutiveFrames
includes 2 validuser
data bytes; unused
user data bytes are
padded with
unspecified values
FlowControl frame with
implicit connection setup
FlowControl because of
SN=BSmax
Consecuti
veFrame
(CF) [PCI.S
N=4, xx ...
xx]
Last Con
secutiveF
rame (CF
) [PCI.SN
=5, xx ... xx
]
End of multiple frame
message transmission
• one or multiple ConsecutiveFrames (CF) with additional FlowControl (FC) frames
Figure 4: Example of multiple frame message flow without extended address
Page: 11 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8. Network layer
8.1 Services
According OSI Reference Model the network layer is defined by services. Each service
interworks internally with an other adjacent layer by means of service primitives for request,
confirmation and indication. Services and primitives are defined in the following chapter.
This service specification does not specifiy any implementation requirements but provides a
structuring framework which purpose is to bound the network layer specification within a well
defined container to facilitate its understanding.
8.2 Services provided to upper layer
The network layer provides services of unacknowledged and unsegmented data (UUDT) and
unacknowledged and segmented data (USDT). Any upper layer or application inside of a
network node which uses the services shall interface with the services provided below.
8.2.1 Transfer of unacknowledged and unsegmented data (UUDT)
Service name:
Syntax:
Request:
Confirmation:
Indication:
Parameter:
Handle
MessageData
Length
Result
Description:
N_UUData.req
internal service
N_UUData.req(<Handle>, <MessageData>, <Length>)
N_UUData.con(<Handle>, <Result>)
N_UUData.ind(<Handle>, <MessageData>, <Length>, <Result>)
Reference to a message transfer path
Reference to the message data
Length of message data in bytes
Result of the requested and indicated service (see network layer
results)
The service primitive N_UUData.req sends the data <MessageData> of
the length <Length> unsegmented over the network, using the physical
(network) address associated to the message transfer path referenced
by the parameter <Handle>.
The service primitive N_UUData.con contains the confirmation
regarding the execution of a previously called N_UUData.req service
primitive. The parameter <Result> represents the result detected by
the network layer. A successful result of transfer is indicated by value
E_NWL_OK. In case of errors (other results) the sending transfer is not
or incompletely performed.
The service primitive N_UUData.ind informs the receiver that a
message corresponding to the transfer path referenced by <Handle>
has been received unsegmented and provides the associated data
<MessageData>. The parameter <Result> represents the result
detected by the network layer. A successful result of transfer is
indicated by value E_NWL_OK. In case of errors (other results) the
receiving transfer is not or incompletely performed.
Note: Service procedures dealing with supporting service primitives, sending and receiving of
frames are described in the SDL model.
Page: 12 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8.2.2 Transfer of unacknowledged and segmented data (USDT)
Service name:
Syntax:
Request:
Confirmation:
Indication:
Parameter:
Handle
MessageData
Length
Result
Description:
N_USData.req
internal service
N_USData.req(<Handle>, <MessageData>, <Length>)
N_USData.con(<Handle>, <Result>)
N_USData.ind(<Handle>, <MessageData>, <Length>, <Result>)
Reference to message transfer path
Reference to the message data
Length of message data in bytes
Result of the requested and indicated service (see network layer
results)
The service primitive N_UUData.req sends the data <MessageData> of
the length <Length> segmented over the network, using the physical
(network) address assiociated to the message transfer path referenced
by the parameter <Handle>.
The service primitive N_UUData.con contains the confirmation
regarding the execution of a previsously called N_UUData.req service
primitive. The parameter <Result> represents the result detected by
the network layer. A successful result of sending transfer is indicated
by value E_NWL_OK. In case of errors (other results) the sending
transfer is not or incompletely performed.
The service primitive N_UUData.ind informs the receiver that a
message corresponding to the transfer path referenced by <Handle>
has been received segmented and provides the associated data
<MessageData>. The parameter <Result> represents the result
detected by the network layer. A successful result of receiving transfer
is indicated by value E_NWL_OK. In case of errors (other results) the
receiving transfer is not or incompletely performed.
Note: Service procedures dealing with supporting service primitives, sending and receiving of
frames are described in the SDL model.
Page: 13 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8.2.3 Network layer results
Following results indicate whether a given sending/receiving transfer was successfully
performed or not. In the latter case the error is identified by the result code.
Result Code
Description
E_NWL_OK
E_NWL_TOUT_A
E_NWL_TOUT_B1
E_NWL_TOUT_B2
E_NWL_TOUT_C
E_NWL_TOUT_D1
E_NWL_TOUT_D2
E_NWL_TOUT_E
E_NWL_WRG_SN
Sending or receiving transfer is successful.
Timeout A is occurred for sender or receiver.
Timeout B1 is occurred for sender.
Timeout B2 is occurred for sender.
Timeout C is occurred for receiver.
Timeout D1 is occurred for receiver.
Timeout D2 is occurred for receiver.
Timeout E is occurred for receiver.
Received sequence number value SN is non
conformant to internally made calculation of
receiver.
Received data frame is unexpected in the
current state of sender or receiver.
Received number of flow control frames with
wait state FC.WAIT exceeds maximum counter
WFTmax.
E_NWL_UNEXP_FRM
E_NWL_WFT_OVRN
Page: 14 of 33
used by service
UUDT USDT
•
•
•
•
•
•
•
•
•
•
•
•
•
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8.3 Services used of lower layer
The network layer uses the communication service(s) provided by the Data Link Layer.
Service name:
Syntax:
Request:
Confirmation:
Indication:
Parameter:
Handle
Data
Result
Description:
D_UUData
internal service
D_UUData.req (<Handle>, <Data>)
D_UUData.ind (<Handle>, <Data>)
D_UUData.con (<Handle>, <Result>)
Reference to frame transfer path
Reference to the frame data
Result of the requested service
The service primitive D_UUData.req sends the data <Data> over the
network, using the physical (network) address associated to this frame
transfer path referenced by the parameter <Handle>.
The service primitive D_UUData.con contains the confirmation
regarding the execution of a previously called D_UUData.req service
primitive. The parameter <Result> represents an implementationspecific status information.
The service primitive D_UUData.ind informs the receiver that a
message corresponding to the frame transfer path referenced by
<Handle> has been received and provides the associated <Data>.
Page: 15 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8.4 Definition of Protocol Control Information (PCI)
The purpose of the Protocol Control Information (PCI) is to define the type of frame
exchanged between communicaton peers. The following frames are defined :
• SingleFrames (SF) as an optimisation
• FirstFrame (FF) with implicit connection set-up
• ConsecutiveFrame (CF)
• FlowControl (FC)
8.4.1 Encoding of Protocol Control Information (PCI)
USDT PCI encoding
PCI name
PCI byte
Mnemonic
7
6
5
4
SingleFrame
SF
0
0
0
0
DL
FirstFrame
FF
0
0
0
1
XDL
ConsecutiveFrame
CF
0
0
1
0
SN
FlowControl frame
FC
0
0
1
1
FS
reservedByDocument
RBD
3
2
1
$40 through $FF
Table 4: Encoding of Protocol Control Information (PCI)
8.4.2 Definition of frame types
8.4.2.1 Definition of SingleFrame (SF)
For unsegmented data (single frame messages) the USDT protocol provides an optimised
implementation of the network protocol with the data length embedded in the PCI byte.
8.4.2.1.1 DataLength (DL)
USDT PCI encoding
PCI name
SingleFrame
PCI byte
Mnemonic
7
6
5
4
SF
0
0
0
0
3
data bytes
2
1
0
1 … MUDBPF
DL
xx … xx
Table 5: USDT Protocol Control Information (PCI) : SingleFrame (SF)
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.
• In case the CAN data link is implemented bit “3” shall always equal zero (0) because the
CAN frame allows for a maximum of eight (8) data bytes (PCI byte included) (MUDBPF =
7).
• In case the D2B data link is implemented the restriction is twelve (12) data bytes (PCI byte
included) (MUDBPF = 11).
The valid range for a single frame is one (1) to seven (7) bytes for a CAN frame and one (1) to
eleven (11) bytes for a D2B frame. Unused data bytes shall be padded with random values.
8.4.2.2 Definition of FirstFrame (FF)
When sending segmented data (more than one data segment), the first segment is encoded
as the FirstFrame (FF). On receipt of a FirstFrame (FF) data segment the receiving network
layer entity shall start to assemble the segmented message.
8.4.2.2.1 EXtendedDataLength (XDL)
Page: 16 of 33
0
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
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 … MUDBPF
DL
xx … xx
Table 6: USDT Protocol Control Information (PCI) : FirstFrame (FF).XDL
The eXtendedDataLength (XDL) defined in a FirstFrame (FF) 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 LSB (Least Significant Bit) is specified to
be bit “0” of the data byte #1 and the MSB (Most Significant Bit) is bit “3” of the PCI byte. The
eXtendedDataLength (XDL) which is only applicable with a multiple frame message supports
up to four thousand and ninety five (4095) bytes of user data. The PCI byte is not included in
the data length calculation.
8.4.2.2.2 DataLength (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 … MUDBPF
DL
xx … xx
Table 7: USDT Protocol Control Information (PCI) : FirstFrame (FF).DL
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.
8.4.2.3 Definition of ConsecutiveFrame (CF)
When sending segmented data, all segments except the first one are coded as a
ConsecutiveFrame (CF). On receipt of a ConsecutiveFrame (CF) data segment the receiving
network layer shall buffer the received data bytes until the whole message (number of bytes
defined by eXtendedDataLength (XDL) parameter value) is received. The receiving network
layer entity shall pass the assembled message to the application after the last frame of the
message is received without error.
8.4.2.3.1 SequenceNumber (SN)
USDT PCI encoding
PCI name
ConsecutiveFrame
PCI byte
Mnemonic
7
6
5
4
CF
0
0
1
0
3
data bytes
2
1
SN
0
1 … MUDBPF
xx … xx
Table 8: Definition of Protocol Control Information (PCI) : ConsecutiveFrame (CF).SN
The SequenceNumber (SN) is used to detect duplicated or lost ConsecutiveFrame(s) (CF)
(data segments). The sequence counter shall use the PCI lower nibble bits for the
SequenceNumber (SN) value only if a ConsecutiveFrame (CF) is encoded by the higher
nibble of the PCI byte. The “nibble (4 bit) counter” also allows for optimised implementations in
low-end microcontrollers.
SequenceNumber (SN) range :
Page: 17 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
The SequenceNumber (SN) range is zero (0) to fifteen (15), which is the minimal range for
efficient flow control.
Conditions to initialise SequenceNumber (SN) :
The SequenceNumber (SN) is initialised to zero (0) only when a) starting transmission of a
message and b) after SequenceNumber (SN) wraparound which can occur within the
transmission of block of frames.
8.4.2.4 Definition of FlowControl (FC) frame
The purpose of FlowControl (FC) is to prevent a sender node to overcome a receiver node.
FlowControl (FC) frame shall be sent following correct reception of a) FirstFrame (FF) and b)
last ConsecutiveFrame (CF) of a block of frame.
The network protocol parameters of the FlowControl (FC) frame are defined in one of the
following sections “Definition of FlowControl (FC) frame parameters. The data bytes in the
FlowControl (FC) frame which are not specified shall be padded with random values.
SEQARABISCH9Definition
of FlowControl (FC) frame parameters
The FlowControl (FC) frame includes the following network protocol information:
• FlowStatus (FS): ClearToSend (CTS), WaiT - receiver not ready - (WT)
• maximum BlockSize (BSmax)
• minimum SeparationTime (STmin)
8.4.2.4.2 Conditions for transmission of flow control Wait frame
The transmission of a WaiT flow control Wait (FC.WT) frame occurs upon expiration of the
timer [E], see chapter 8.5.1 Placement of time-outs on page 22.
8.4.2.4.2.1 Parameters reading conditions
Flow control parameters (BSmax, STmin) shall be taken into account by the sender only upon
reception of the first FlowControl.ClearToSend (FC.CTS) frame which follows the FirstFrame
(FF) : the protocol does not allow for parameter value change during message transmission.
8.4.2.4.2.2 Definition of FlowStatus (FS)
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 … MUDBPF
BSmax
STmin
xx … xx
Table 10: Definition of FlowStatus (FS) in the PCI byte
The FlowStatus (FS) is the receiver’s internal network layer status based on the correct
reception of a FirstFrame (FF) or ConsecutiveFrame (CF) from the sender. The receiver’s
internal status shall be encoded in the low nibble of the PCI byte of the FlowControl (FC)
frame. This frame shall be sent to the sender of the FirstFrame (FF) or ConsecutiveFrame
(CF).
SEQARABISCH11
The FlowStatus (FS) network protocol parameter specifies different flow control states:
PCI FlowStatus (FS) lower nibble
Description of FlowStatus (FS) network protocol information
Page: 18 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
bits
3
2
1
0
0
0
0
0
ClearToSend (CTS)
The ClearToSend FlowStatus (FS.CTS) parameter value is sent by the
receiver during the reception of a multiple frame message to indicate to the
sender to resume message transmission. This is defined for FlowControl
(FC) following the FirstFrame (FF) and ConsecutiveFrame(s) (CF)).
0
0
0
1
WaiT (WT) - receiver not ready
The WaiT FlowStatus (FS.WT) parameter value is sent by the receiver
during the reception of a multiple frame message to indicate to the sender
to set the time-out [D2 ] and the receiver to reset its timer [E]. This is
defined for FlowControl (FC) following the FirstFrame (FF) and
ConsecutiveFrame(s) (CF)).
Table 12: Protocol Control Information Flow Control encoding (PCI-FC)
8.4.2.4.2.2.1 Definition of BlockSize (BSmax)
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 … MUDBPF
BSmax
STmin
xx … xx
Table 13: Definition of FlowStatus (FS) in the PCI byte
The network protocol BlockSize (BS) parameter is used in the FlowControl (FC) frame to
request a data transfer mode, in which a block of BlockSize (BS) parameter data segments
can be sent without intermediate flow control from the receiving network entity. The BlockSize
(BS) parameter shall be within the range of zero (0) to two hundred fifty five (255).
SEQARABISCH14
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.
Table 15: Definition of BlockSize (BS)
8.4.2.4.2.2.2 Definition of SeparationTime (STmin)
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 … MUDBPF
BSmax
STmin
xx … xx
Table 16: Definition of FlowStatus (FS) in the PCI byte
The minimum SeparationTime (STmin) specifies the minimum time gap between
ConsecutiveFrames (CF) of a segmented message. This time has to be specified by the
receiver and kept by the sender.
Page: 19 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
SEQARABISCH17Definition of max. number of FlowControl.WaitFrameTransmissions
(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 having communication nodes hooked-up in case of a
fault condition whereby a receiver would request the sender to wait continuously
1 ≤ FC.WFTmax ≤ 15
FC.WFTmax = 0
Flow control relies upon FC.CTS only. Wait flow control
frame not supported.
Permitted range for the maximum number of wait FC
frame sent for a given segmented message.
Table 18: Definition of maximum number of FlowControl.WaitFrameTransmissions (FC.WFTmax)
Page: 20 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8.5 Definition of time-outs and Timers
8.5.1 Placement of time-outs and [Timers]
The USDT protocol time-outs are defined as follows :
Network Layer of Sender
Subnet1
Network Layer of Receiver
As
B1
[E]
Ar
C
As
D1
As
D1
As
[E]
B2
D2
D2
FC(WT)
Ar
FC(WT)
Ar
FC(CTS)
Ar
C
As
Figure 5: Placement of time-outs
Page: 21 of 33
[E]
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
8.5.1.1 Time-out As (Sender) / Ar (Receiver)
• The time-out As monitor the time which has elapsed between :
DUUDATA_Request and DUUDATA_Confirmation on the sender side.
• The time-out Ar monitor the time which has elapsed between :
DUUDATA_Request and DUUDATA_Confirmation on the receiver side.
8.5.1.2 Time-out B1
The time-out B1 monitors the time which has elapsed between :
DUUDATA_Confirmation(FF) and DUUDATA_Indication(CF).
8.5.1.3 Time-out B2
The time-out B2 monitors the time which has elapsed between :
DUUDATA_Confirmation(block’s last CF) and DUUDATA_Indication(CF).
8.5.1.4 Time-out C
The time-out C monitors the time which has elapsed between :
DUUDATA_Confirmation(FC.RR) and DUUDATA_Indication(CF).
8.5.1.5 Time-out D1
The time-out D1 monitors the time which has elapsed between :
DUUDATA_Indication(CF) and DUUDATA_Indication(block’s next CF).
8.5.1.6 Time-out D2
The time-out D2 monitors the time which has elapsed between :
DUUDATA_Indication(FC.RNR) and DUUDATA_Indication(next FC).
8.5.1.7 Timer [E]
The timer [E] determines the time at which a wait FlowControl (FC.WT) frame is to be sent to
the sender. The timer [E] is restarted upon the following conditions :
• D_UUData_indication(FF or block’s last CF)
• D_UUData_confimation(FC.WT)
Note: Various time-out values and combinations can lead to various implementation
optimisations which are not hinted by this specification, e.g. if D2 value is equal to B2
value then a timer reset may be more judicious than the setting of an explicit D2 value
upon reception of FC.WAIT. No implementation restrictions nor hints are made in this
specification document.
8.5.2 Time-out values setting requirements
The protocol behaviour is coupled to values associated with the above time-outs. Guidelines
to set time-out values are to be defined to ensure consistent behaviour of the overall
communication system.
** TBD **
1) Time-out E < Time-out B1,2
8.5.3 Time-out values
Page: 22 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
Times and time-out values are specified during system design for normal applications. Hence,
no time-out values are specified in this specification. Note that the ISO 15765 specification
may (shall ?) provides time-outs estimates.
**TBD **
8.6 Protocol error handling
8.6.1 Protocol behaviour upon error detection
The communication node(s) (sender, receiver) having detected a communication error shall
a) releases the resources allocated to the message handling and b) allow for provision of error
condition information to the sender/receiver application.
8.6.2 Error detection and reporting capability
Two things can be distinguished :
• error detection capability: this measures up the capability of the protocol to react to an error
occurrence.
• error reporting capability: this measures up the capability of the protocol to make
communication nodes (taking part to a message transmission) aware that an error has
occurred.
This conclusion attempts to bound both issues concerning the Network USDT protocol as
defined in this document.
8.6.2.1 ErrorDetectionCapability (EDC)
USDT protocol EDC is taken care of by the following mechanisms:
• Frame information : SequenceNumber
• Time-out information : A, B1,2, C, D1,2
• DLL features
8.6.2.1.1 SequenceNumber (SN)
The SequenceNumber (SN) enables the detection of loss or duplication of a frame.
8.6.2.1.2 Definition of time-outs
Four (4) time-outs are defined on the sender side:
• A
• B1
• B2
• D2
Four (4) time-outs are defined on the receiver side:
• A
• C
• D1
8.6.2.2 ErrorReportingCapability (ERC)
Whilst error occurrences (i.e. frame loss) are detectable by means of EDC, the USDT protocol
does not define an intrinsic error reporting procedure hence does not guarantee that the
sender is in all cases aware that an error has occurred on the receiver side.
The USDT ERC is asynchronous and depends on system configuration (message length,
number of sub-networks, block size). The ERC is asynchronous because communication
protocol fault information is reported -locally- on a “if they occur” basis.
Page: 23 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
Since there is no acknowledgement of message the sender does not receive explicit
notification of an error however it may be able to deduce the occurrence of an error based on
the system configuration where the communication dialogue takes place (i.e. message
length/number of block left to be sent after the error occurrence/number of sub-networks
which take part in a given communication session).
8.7 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 (in case of normal addressing
mode : bus frame identifier, in case of extended addressing mode : bus frame identifier and
extended address) so that the receiver communication 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 to support gateway operation which requires the ability
to handle different message transmissions “in parallel”.
Page: 24 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
9. Annex
9.1 USDT flow control examples
The following figure shows an example of the flow control mechanism during a message
transfer over three sub-networks.
Assumptions:
1. Gateway #1 has a buffering capacity of 3 segments (BS = 3) + the FirstFrame (FF).
2. Gateway #2 has a buffering capacity of 2 segments + the FirstFrame (FF).
3. The communication link between the gateways is also slower than the two other links (due
to a lower bit rate or higher bus load).
4. In the gateways, the Receiving Protocol Entity and the Sending Protocol Entity are sharing
the same buffer, therefore the gateways are not able to receive another block in the
segmented message before all segments in a previously received block have been
successfully sent on the other network.
Note: The beginning of the arrow indicates the time when the sender requests the segment
for transmission. The end of the arrow indicates the time when the sender has
successfully sent the segment, and if everything went well, the receiver received the
segment.
Page: 25 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
9.1.1 Example of FlowControl with ClearToSend (FC.CTS)
Sender
Net 1
N_Data.req
Gateway
1
Net 2
Gateway
2
Net 3
End
Receiver
FF(0)
FC(CTS,BS=3)
FF(0)
CF(1)
CF(2)
FC(CTS,BS=2)
CF(3)
FF(0)
FC(CTS,BS=0)
CF(1)
CF(2)
FC(CTS)
CF(1)
CF(2)
CF(3)
FC(CTS)
CF(3)
A
CF(4)
N_Data.conf(Success)
CF(5)
CF(4)
B
N_Data.req
C
FF(0)
CF(4)
FC(CTS)
CF(5)
FC(CTS,BS=3)
D
CF(5)
N_Data.ind
CF(1)
Figure 6: Example of FlowControl with ClearToSend (FC.CTS)
Event A)
Gateway #1 delays the sending of the FC.CTS after having received the first
block, until all the segments (0 to 3) have been successfully sent on Network 2.
(The sending PE has released the common buffer in the Gateway).
Note: Gateway #1 does not now if Gateway #2 has successfully received all the segments,
only that it has been successfully sent.
Page: 26 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
Event B)
The message transfer is confirmed success (local confirmation) in the Sender as
soon as the complete message has been successfully sent out on Network 1. The
resource in the Sending PE is released and it is now possible to request a new
message for transmission.
Event C)
A new message is requested for transmission.
Event D)
The Flow Control from Gateway 1 is delayed until the last segment in the previous
message
has
been
successfully
sent
on
Network
2.
The recovery (release of locked resources) in this example is handled by “Long
Time-outs” The idea is that the probability for an error in a well designed system is
low, and a recovery time in the range of second / seconds are acceptable in these
rare occasions. The necessary time-outs shall be fixed during system generation.
The above Flow Control mechanism indicates to the sender that the receiver is ready to
handle the next block of frame. This means that the flow control is not sent immediately after
the FF or the last CF of a block has been received. Instead, a time window is defined during
which the Receiver is allowed to indicate to the receiver to resume transmission by sending an
FC.CTS frame. This time window is defined at system generation time.
The window time period [E] (see chapter 5.) should be high enough to ensure a consistent
flow control mechanism but it should also be small enough so it does satisfy error detection
requirements (“short” detection time). One way to meet such conflicting requirement is to
define a flow control frame WAIT which purpose is to indicate to the sender that the receiver is
not ready and therefore tell to the sender to wait an additional time. This can be achieved by
resetting both the senders and receivers time windows B1,2 (or rather setting the sender time
window
D2
!!)
and E.
Page: 27 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
9.1.2 Example of FlowControl with Wait (FC.WT)
Sender
Net 1
N_Data.req
Gateway
1
Net 2
Gateway
2
Net 3
End
Receiver
FF(0)
FC(CTS,BS=3)
FF(0)
CF(1)
CF(2)
FC(CTS,BS=2)
CF(3)
FF(0)
FC(CTS,BS=0)
CF(1)
CF(2)
FC(WAIT)
FC(CTS)
A
CF(1)
CF(2)
CF(3)
FC(CTS)
B
CF(3)
CF(4)
N_Data.conf(Success)
C
CF(5)
CF(4)
CF(4)
FC(CTS)
CF(5)
CF(5)
N_Data.ind
Figure 7: Example of FlowControl with Wait (FC.WT)
In the figure above, the receiver sends a FlowControl.WAIT (FC.WT).
The receiver sends a WAIT flow control if the receiver is not ready (buffer full) within a certain
time period from that the last segment was received in the previous block. When the sender
receive this WAIT Flow Control, the sender restarts the timeout timer for the waiting of the
CTS Flow Control. The receiver can send additional WAIT Flow controls if necessary. The
maximum number of WAIT frame sent consecutively is set at system generation time and
equal to WFCRmax.
Page: 28 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
Event A)
Gateway 1 sends an FC.WAIT after certain time period to prevent the sender to
time-out.
Event B)
Gateway 1 has sent all the segments (0 to 3) successfully on Network 2. (The
sending PE has released the common buffer in the Gateway). A CTS Flow(local
confirmation) in the Sender.
Compared to example 1, the recovery (release of locked resources) can be made faster since
the time-outs can be shorter. Typically they can be in the range of 100ms.
The necessary time-outs shall be fixed during system generation time.
Page: 29 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
9.2 Total number of frames required for segmented message transmission
The following table specifies the calculation of “Total number of frame(s) required for message
transmission“. The “roundup()“ function shall always round to the next higher integer value.
The constant MaxUserDataBytesPerFrame (MUDBPF) specifies the number of user data
bytes available per frame based on the data link layer implemented.
Message
DataLength
DataLength
Number of frames
Frame
type
≤ MUDBPF
PCI.DL
1
SF
 DataLength − (MUDBPF - 1) 
roundup 
 +1
MUDBPF


FF
CF
> MUDBPF
7
PCI.XDL*2 +FF.DL
Table 19: Calculation of total number of frames required for message transmission without extended
address
Calculation example of NumberOfFrames:
Assumption: CAN network MUDBPF (MaxUserDataBytesPerFrame) = 7; DataLength = 36;
 36 − (7 − 1) 
NumberOfFrames = roundup 
 + 1 = roundup (4.2857 ) = 5
7


Figure 8: Calculation example of NumberOfFrames
9.3 Total number of valid bytes
The following table specifies the calculation of “Number of valid user data bytes in the
SingleFrame (SF) or in the last ConsecutiveFrame (CF)“. The “rounddown()“ function shall
always round to the next lower integer value.
Message
DataLength
DataLength
Number of valid data bytes
Frame
type
≤ MUDBPF
PCI.DL
DataLength
SF
  DataLength − (MUDBPF - 1) 
 DataLength − (MUDBPF - 1)  
 
 - rounddown 
  * MUDBPF
MUDBPF
MUDBPF




last
CF
> MUDBPF
7
PCI.XDL*2 +FF.DL
Table 20: Calculation of total number of valid user data bytes in the SingleFrame (SF) or last
ConsecutiveFrame (CF) without extended address
Calculation example of UserDataBytesInLastConsecutiveFrame:
Assumption: CAN network MUDBPF (MaxUserDataBytesPerFrame) = 7; DataLength = 36;
  36 − (7 − 1) 
 36 − (7 − 1)  
UserDataBytesInLastCF =  
 − rounddown 
  * 7 = (4.2857 − 4) * 7 = 2
7
7




Figure 9: Calculation example of UserDataBytesInLastConsecutiveFrame
Page: 30 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
SEQARABISCH10SEQARABISCH11SEQARABISCH12SEQARABISCH13SEQARABISCH14
Page: 31 of 33
ISO / WD 15765 - 2 : DIAGNOSTICS SYSTEMS - NETWORK USDT PROTOCOL
10. 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
0.4
06/03/98
*
Changes according to remarks received from
OSEK/COM and ISO/TF2 – see OSEK/VDX/Com24/1
Add Network layer services
Update time-outs/timer chapter
Conditions for the sender to take into account BS, ST
SEQARABISCH15SEQARABISCH16
Page: 32 of 33
Author
GM :
Gangolf Feiter
Thomas Walter
*
LucasVarity :
Laurent Roy
“