14 Data Link Layer: Software Documentation Page 14-1 EDC7 Keyword Protocol 2000

Software Documentation Page 14-1
Y281 S365_KWP_V14 EDC7 Keyword Protocol 2000 Version 1.4
14 Data Link Layer
14.1 Data Link Layer on K line
14.1.1 Message structure
This section describes the structure of a message. The message structure consists of three parts:
• Header
• Data bytes
• Checksum
Header Data bytes Checksum

(1) (1) (1) (2)
Fmt Tgt Src Len Sid ... Data ... CS
max. 4 byte max. 255 bytes 1 byte
(1)
Bytes are optional, depending on the format byte
(2)
Service identification, part of data bytes
14.1.1.1 Header
The header consists of maximum 4 bytes. A format byte includes information about the form of the
message. Target and source address bytes are optional for use with multi node connections. An optional
separate length byte allows message lengths up to 255 bytes. The different possibilities of using header
bytes is shown in the figure below.
14.1.1.2 Format Byte

The format byte contains 6 bit length information and 2 bit address mode information. The tester is informed
about use of header bytes by the key bytes in the startCommunication postitive response message.
A1 A0 L5 L4 L3 L2 L1 L0
A1, A0 define the form of the header which will be used by the message (see below).
L5..L0 define the length of a message from the beginning of the data field (service identification byte included) to the
checksum byte (not included). A message length of 1 to 63 bytes is possible. If L0 to L5 = 0, then the additional length
byte is included.
A1 A0 Mode
0 0 no address information
0 1 exception mode (CARB)
1 0 with address information, physical addressing
1 1 with address information, functional addressing
14.1.1.3 Target Address Byte

This is the target address for the message and is always used together with the source address byte.
According to SAE J2178-Part 1 (where the range of numbers 10h to 17h is assigned to "Engine Controllers"),
the physical address of EDC7 is 10h. The target address byte is optional and only necessary on multi node
bus topologies. For node-to-node connections it may be omitted.
© Robert Bosch GmbH (Germany) reserves all rights even in the event of industrial rights. We reserve all rights of disposal such as copying and passing to third parties.
DS-NF/ESN2 15-JAN-2004 Data link layer

14.1.1.4 Source Address Byte

This is the address of the transmitting device. It must be a physical address. There are the same
possibilities for the values as described for physical target address bytes. Addresses for testers are listed in
SAE J2178 Part 1. This byte is optional (always used together with target address byte) and only necessary
on multi node bus topologies. For node-to-node connections it may be omitted.
Data bytes Checksum
Fmt Sid Data CS
Checksum calculation 1 byte
Header without address Information, no additional length byte
Data bytes Checksum
Fmt Len Sid Data CS
Header without address Information, additional length byte
Data bytes Checksum
Fmt Tgt Src Sid Data CS
Header with address Information, no additional length byte
Data bytes Checksum
Fmt Tgt Src Len Sid Data CS
Header with address Information, additional length byte
Fmt Format byte Sid Service identification Byte

Tgt Target address (optional) Data depending on service
Src Source address (optional) CS Checksum byte
Len additional length byte (optional)
Use of header bytes

14.1.1.5 Length Byte

This byte is provided if the length in the header byte (L0 to L5) is set to zero. It allows the unit to transmit
messages with data fields longer than 63 bytes. With shorter messages ist may be omitted. This byte
defines the length of a message from the beginning of the data field (service identification byte included) to
the checksum byte (not included). A data length of 1 to 255 bytes is possible. The longest message consists
of a maximum of 260 bytes (4 bytes header, 255 data and 1 checksum byte).
For messages with less than 64 data-bytes there are two possibilities: the length information may be
included in the format byte or in the additional length byte. The tester may use both possibilities for request
messages. With EDC7 a response message contains the additional length byte only if there are more than
63 data bytes to transmit. The tester is informed about this procedure through the key bytes in the
startCommunication positive response message.
The chart below shows the three possible cases:
Data length Length provided in

Format byte Length byte
< 64 XX00 0000 present
< 64 XXLL LLLL not present
≥ 64 XX00 0000 present
XX: 2 bit address mode information (see section "Format Byte")
LL LLLL: 6 bit length information
14.1.2 Data Bytes

The data field may contain up to 63 or up to 255 bytes of information, depending on the use of length
information. The first byte of the data field is the service identification byte. It may be followed by
parameters and data depending on the selected service.
14.1.3 Checksum Byte

The checksum byte (CS) inserted at the end of the message block is defined as the simple 8-bit sum series
of all bytes in the mesage, excluding the checksum.
14.1.4 Message Interchange

Message interchange between tester and EDC7 is based on logical point-to-point connections with or
without physical address information in the message headers (see section "Format Byte"). To meet the
block handshake strategy a tester request message (target address = single ECU EDC7) is followed by one
single response message from the ECU. Periodical responding ("burst") is not supported by EDC7.
14.1.5 Timing
During normal operation the following timing parameters are relevant:
Tester ECU Tester

request response request
P2 P3 P2
P4 P1 P4
byte
block
(message)
Message flow timing
Value Description
P1 Inter-byte-time in the ECU response message

Value Description
P2 Time between end of tester request and start of ECU
response (inter-block-time)
P3 Time between end of ECU response and start of new
tester request (inter-block-time)
P4 Inter-byte-time in the tester request message
As for EDC7, the limits and default values for these parameters are defined in the "extended timing
parameter set", which restricts to physical addressing to allow fast communication:
Timing lower limit values upper limit values

Parameter min. default min. Resolution default max. max. Resolution
ms ms ms/bit ms ms ms/bit
P1 0 0 --- 20 20 ---
P2 0 0(1, 2) 0,5 1000(2) ∞ 25(4)
(2, 3) (2) (4)
P3 0 0 0,5 5000 ∞ 250
(2)
P4 0 0 0,5 20 20 ---
(1)
EDC7 responds to keyword protocol 2000 request messages within the 10ms time slice, which causes, that P2
can be longer than the currently active P2min value. Nevertheless it is granted that P2min will never be undershot
(if set to a value greater than 0 ms).
(2)
Timing parameter changeable by accessTimingParameters service.
(3)
The inter-block-time P3 may equal to 0 ms, if the active baudrate is lower than 19 kbaud; see note below
(4)
Hex-value Px = FFh means t = ∞
Values controlled by the ECU are shaded (default delays and thresholds for detection of tester time-outs).
EDC7 allows to perform communication without inter-byte and inter-block-times. Request messages from
the tester are evaluated by the ECU every 10 milliseconds (in the ECUProgrammingMode every 1
millisecond). Response messages will be transmitted to the tester right afterwards.
Timing parameters may be changed with the service "accessTimingParametersì, where the tester should
take care for the restrictions listed below. Requesting invalid timing parameters will not take effect in the
ECU:
P3min ≥ P4min
Pimax > Pimin for i = 1, 2, 3, 4
Note: For communication baudrates higher than 19 kbaud EDC7 may require inter-block-times P3 (delay
time between ECU response and tester request) longer than 0 ms, depending on the CPU load, engine
speed respectively.
14.1.6 Initialization
14.1.6.1 Fast Initialization

The tester has to transmit a wake up pattern to initialize communication via keyword protocol 2000. The
pattern has to be sent
• on K-line
The pattern begins with a low level signal for the duration of TiniL. An idle time Tidle is not required before
initialization, in order to allow the tester to initialize keyword protocol 2000 while another protocol is running.
After the low level period has elapsed, the ECU stops communication with the previously active protocol.
Another high level period for the duration of TiniL has to be passed, until the keyword protocol 2000 is totally
initialized. The tester transmits the first bit of the startCommunication request message after TWuP since start
of initialization. A baudrate of 10400 baud for communication is used.

Tester Wake up StartCommunication

Pattern request
TWuP P2
25ms 25ms 0..1000ms
Tidle TiniL
StartCommunication
Vehicle positive response
10400 baud
Fast initialization
Values of TWuP and TiniL are defined below:
Durations Range min. max.

ms ms ms
TiniL 25 ± 1 24 26
TWuP 50 ± 1 49 51
The transfer of a wake up pattern as described above is followed by a startCommunication request from the
tester and a response from the ECU. The first two messages of a fast initialization (startCommunication
request and response message) always use headers with target and source address and without additional
length byte. The key bytes in the startCommunication positive response message inform the tester about
the ECU supported modes (see following section).

14.1.7 Key Bytes

With the key bytes in the startCommunication positive response message the ECU informs the tester about
timings and supported kinds of headers. In accordance with ISO 9141, EDC7 passes the key bytes DFh and
8Fh to the tester, which indicates:
• "Length information in format byte or additional length byte": an additional length byte is only provided, if
64 or more (up to 255) data bytes have to be transmitted. If the response message comprises less than
64 data bytes, length information is contained in the format byte.
• "Both types of headers supported": EDC7 provides source and target information only in the headers of
those messages, that respond to request messages with source and target information.
• "Extended timing": EDC7 uses the extended timing parameter set as default, which allows to respond to
request messages without delay times (P2min = 0ms).
14.1.8 Information Frames

The information frame of each transmitted or received byte consists of the following elements:
• 1 start bit
• 8 data bits
• 1 stop bit
14.1.9 Error Handling
14.1.9.1 Tester Error Handling

The tester is responsible to keep the idle times before transmission of request messages (P3min). The tester
is not required to delay the transmission inter-byte-time (P4min), as the ECU has to be capable of receiving
messages without inter-byte-times (P4min may equal to 0ms). If the tester detects P1max or P2max time-outs and
the response of the ECU misses, the connection is supposed to be interrupted or disturbed (e. g. a
destroyed length information could be the reason for a P1max time-out diagnosis). For tester actions refer to
following table:
Tester detects... Action

P2max (ECU inter-block) time-out If the tester does not receive any response, it may repeat
the last request twice, each within a new timing window P3
(in total three requests). If the tester still does not receive
any response, it shall wait for P3max time-out and afterwards
may start a new initialization beginning with a wake up
pattern (Tidle = 0 ms).
P1max (ECU inter-byte) time-out The tester shall ignore the response and may repeat the
same request in a new timing window P3.
Error in positive response The tester shall ignore the response and may repeat the last
(Byte collision) request twice, each within a new timing window P3 (in total
(Checksum error) three requests). If the tester still receives faulty responses, it
shall wait for P3max time-out and afterwards may start a new
(Useless contents)
initialization beginning with a wake up pattern (Tidle = 0 ms).
14.1.9.2 ECU Error Handling

The ECU (EDC7) is responsible to keep the idle times before transmission of response messages (P2min).
The ECU is not required to delay the transmission inter-byte-time (P1min), as this time may always equal to
zero (P1min is not changeable by the tester). If the ECU detects P4max or P3max time-outs and does not receive
a new request message from the tester, the connection is supposed to be interrupted or disturbed. For ECU
actions refer to following table:
ECU detects... Action

Error in wake-up-pattern The ECU does not react but is ready to detect a new wake-
up-pattern sequence. If another protocol was running before
sending the wake up pattern, it becomes active again.

ECU detects... Action

Wrong header in the startCom- The keyword protocol is not initialized and the ECU is ready
munication request message or to detect a new wake-up-pattern sequence.
first message after initialization
is not a startCommunication
request message
P3max (tester inter-block) time- The ECU resets communication and the previously running
out communication protocol (if any) becomes active again. The
ECU is ready to detect a new wake-up-pattern sequence.
P4max (tester inter-byte) time-out The ECU ignores the request and opens a new timing win-
dow P3 to receive a new request message from the tester.
Error in request message The ECU ignores the request and opens a new timing win-
(Byte collision) dow P3 to receive a new request message from the tester.
(Checksum error)
(Useless contents)
(Invalid target address)

14.2 Data Link and Network Layer on CAN
14.2.1 Identifier for diagnostic CAN messages
This section describes the structure of a CAN message. The message structure consists of three parts:
• CAN Identifier
• Network protocol information
• Data bytes
The contens of the CAN Identifier and the data bytes depends on the used addressing scheme used for the
diagnostic communication on CAN. EDC7 supports extended addressing with 11 bit CAN Identifier . The
physical addresses mapped into the diagnostic CAN messages are the same as used on K line (10h for
EDC7).
14.2.1.1 CAN Identifier for extended addressing
Using the extended addressing the CAN Identifier holds the 11 bit source address information (N_AI) of the
transmitting device. The address information N_AI is build by adding a fixed offset of 600h to the physical
address of the transmitter. The physical address of the target device (N_TA) is mapped into the first data
byte.
Diagnostic CAN message transmitted by EDC7 using extended addressing:
CAN Identifier (Hex) CAN frame data field (Hex)

N_AI N_TA Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
610 F1 N_PCI and data bytes
Diagnostic CAN message transmitted by external device using extendend addressing:
CAN Identifier (Hex) CAN frame data field (Hex)

N_AI N_TA Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
6F1 10 N_PCI and data bytes
14.2.2 Network protocol information of diagnostic CAN messages
A single CAN frame can contain a maximum number of eight data bytes including the N_PCI data.
Therefore the network layer uses different types of CAN frames to transmit diagnostic messages with a
higher number of data bytes that donít fit into a single frame. Each CAN frame is identified by means of a
Network Protocol Control Information (N_PCI) as illustrated below:

Network Protocol Control Information (N_PCI) bytes

Byte #1 Byte #2 Byte #3
N_PDU name Bits 7-4 Bits 3-0
SingleFrame N_PCItype = 0 SF_DL N/A N/A
FirstFrame N_PCItype = 1 FF_DL N/A
ConsecutiveFrame N_PCItype = 2 SN N/A N/A
FlowControl N_PCItype = 3 FS BS STmin
Definition of N_PCItype values:
Hex value Description

0 SingleFrame
For unsegmented message, the USDT protocol provides an optimised implementation of the network
protocol with the message length embedded in the PCI byte only. SingleFrame (SF) shall be used to support
the transmission of messages that can fit in a single CAN frame.
1 FirstFrame
A first frame (FF) shall only be used to support the transmission of messages that cannot fit in a single CAN
frame, i.e. segmented message. The first frame of a segmented message is encoded as a FirstFrame (FF).
On receipt of a FirstFrame the receiving network layer entity shall start assembling the segmented message.
2 ConsecutiveFrame
When sending segmented data, all consecutive frames following the first frame (FF) are encoded as
ConsecutiveFrames (CF). On receipt of a Consecutive Frame (CF) the receiving network layer entity 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.
3 FlowControl
The purpose of Flow Control is to regulate the rate at which Consecutive Frame network protocol data unit
are sent to the receiver. Two distinct types of Flow Control protocol control information are specified to
support this function. The type is indicated by a field of the protocol control information called Flow Status
(FS) as defined hereafter.
14.2.2.1 SingleFrame N_PCI parameter definition

The table below provides an overview about the SingleFrame N_PCI byte:
SingleFrame N_PCI byte

Byte #1
N_PDU name 7 6 5 4 3 2 1 0
SingleFrame 0 0 0 0 SF_DL
The parameter SingleFrame DataLength (SF_DL) is used in the SingleFrame N_PDU to specify the number
of service user data bytes.


0-6 SingleFrame DataLength (SF_DL)
The SingleFrame DataLength is encoded in the low nibble of N_PCI byte #1 value. It shall be assigned the
value of the service parameter <Length>.
7 SingleFrame DataLength (SF_DL) with normal addressing
SF_DL = 7 is only allowed with normal addressing.
8-F Reserved
This range of values is reserved by this document.
14.2.2.2 FirstFrame N_PCI parameter definition

The table below provides an overview about the FirstFrame N_PCI bytes:
FirstFrame N_PCI bytes

Byte #1 Byte #2
N_PDU name 7 6 5 4 3 2 1 0 7-0
FirstFrame 0 0 0 1 FF_DL
The parameter FirstFrame DataLength (FF_DL) is used in the FirstFrame N_PDU to specify the number of
service user data bytes.

0-6 Reserved
7 FirstFrame DataLength (FF_DL) with extended addressing or mixed addressing
FF_DL = 7 is only allowed with extended addressing.
8 - FFF FirstFrame DataLength (FF_DL)
The encoding of the segmented message length results into a twelve (12) bit length value (FF_DL) where the
least significant bit (LSB) is specified to be bit "0" of the N_PCI byte #2 and the most significant bit (MSB) is
bit three (3) of the N_PCI byte #1 byte. The maximum segmented message length supported is equal to four
thousand and ninety five (4095) bytes of user data. It shall be assigned the value of the service parameter
<Length>.
14.2.2.3 ConsecutiveFrame N_PCI parameter definition

The table below provides an overview about the ConsecutiveFrame N_PCI byte:
ConsecutiveFrame N_PCI byte

Byte #1
N_PDU name 7 6 5 4 3 2 1 0
ConsecutiveFrame 0 0 1 0 SN
The parameter SequenceNumber (SN) is used in the ConsecutiveFrame N_PDU to specify the order of the
consecutive frames. The following rules apply to the SequenceNumber (SN):

 The SequenceNumber (SN) shall start with zero (0) for all segmented messages. The FirstFrame shall
be assigned the value zero (0). It does not include an explicit SequenceNumber in the N_PCI field but it
shall be treated as the segment number zero (0).
 The SequenceNumber (SN) of the first ConsecutiveFrame that immediately follows the FirstFrame
shall be set to one (1).
 The SequenceNumber (SN) shall be incremented by one (1) for each new ConsecutiveFrame (CF) that
is transmitted during a segmented message transmission.
 The SequenceNumber (SN) value shall not be affected by any FlowControl (FC) frame.
 When the SequenceNumber (SN) reaches the value of fifteen (15), it shall wraparound and be set to
zero (0) for the ConsecutiveFrame (CF).
This shall lead to the following sequence:
N_PDU FF CF CF CF CF CF CF CF
SN (hex) 0 1 Ö E F 0 1 Ö

0-F SequenceNumber (SN)
The SequenceNumber (SN) shall be encoded in the lower nibble bits of N_PCI byte #1. The
Sequence Number (SN) shall be set to a value within the range of zero (0) to fifteen (15).
14.2.2.4 FlowControl N_PCI parameter definition
The table below provides an overview about the FlowControl N_PCI bytes:
FlowControl N_PCI bytes

Byte #1 Byte #2 Byte #3
N_PDU name 7 6 5 4 3 2 1 0
FlowControl 0 0 1 1 FS BS STmin
The parameter FlowStatus (FS) indicates whether the sending network entity can proceed the message
transmission.
0 ContinueToSend (CTS)
The FlowControl ContinueToSend parameter shall be encoded by setting the lower nibble of the
N_PCI byte #1 to "0". It shall cause the sender to resume the sending of Consecutive frames. The
meaning of this value is that the receiver is ready to receive a maximum of BS number of
Consecutive frames.
1 Wait (WT)
The FlowControl Wait parameter shall be encoded by setting the lower nibble of the N_PCI byte #1
to "1". It shall cause the sender to continue to wait for a new FlowControl N_PDU.
2-F Reserved

14.2.2.4.1 Definition of BlockSize (BS) parameter

The Block Size (BS) parameter shall be encoded in byte#2 of the FlowControl network protocol control
information (N_PCI). The units of BlockSize (BS) are the absolute number of ConsecutiveFrame (CF)
network protocol data units per block: e.g. if BS is equal to twenty (20) (decimal) then the block shall consist
of twenty (20) (decimal) ConsecutiveFrame (CF) network protocol data units. Only the last block of
consecutive frames in a segmented data transmission may have less than BlockSize number of frames.
The table below provides an overview about the FlowControl N_PCI byte:
00 BlockSize (BS)
The BlockSize (BS) parameter value zero (0) shall be used to indicate to the sender that no more
FlowControl frames shall be sent during the transmission of the segmented message. The sending
network layer entity shall send all remaining consecutive frames without any stop for further
FlowControl frames from the receiving network layer entity.
01 - FF BlockSize (BS)
This range of BlockSize (BS) parameter values shall be used to indicate to the sender the
maximum number of consecutive frames that can be received without an intermediate FlowControl
frame (FC) from the receiving network entity.
14.2.2.4.2 Definition of SeparationTime (STmin) parameter

The SeparationTime (STmin) parameter shall be encoded in byte#3 of the FlowControl network protocol
control information (N_PCI).
This time is specified by the receiving entity and shall be kept by the sending network entity for the duration
of a segmented message transmission.

00 - FF SeparationTime (STmin)
The SeparationTime (STmin) parameter value specifies the minimum time gap allowed between
the transmission of consecutive frame network protocol data units. The units of STmin are absolute
milliseconds (ms). The measurement of the SeparationTime (STmin) starts after completion of
transmission of a ConsecutiveFrame (CF) and ends at the request for the transmission of the next
ConsecutiveFrame (CF).
Example: if STmin is equal to ten (10) (decimal) then the minimum SeparationTime authorised between
consecutive frame network protocol data units is equal to 10 ms.
14.2.2.5 Mapping of N_PCI data into diagnostic CAN messages
The mapping of the N_PCI data into the CAN message depends on the used addressing scheme and frame
type.
CAN frame types and position of N_PCI data for extended addressing:

N_PDU type CAN Identifier

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
SingleFrame (SF) 11 bit CAN-ID N_TA N_PCI N_Data
FirstFrame( FF) 11 bit CAN-ID N_TA N_PCI N_Data
ConsecutiveFrame (CF) 11 bit CAN-ID N_TA N_PCI N_Data
FlowControl (FC) 11 bit CAN-ID N_TA N_PCI N/A
14.2.3 Timing
During normal operation the following timing parameters are relevant for diagnostic messages on CAN:
Value Description
P2 Time between end of tester request and start of ECU
response (Single Frame or First Frame)
P3 Time between end of ECU response and start of new
tester request (Single Frame or First Frame)
Timing lower limit values upper limit values

Parameter min. default min. Resolution default max. max. Resolution
ms ms ms/bit ms ms ms/bit
(1, 2) (2)
P2 0 25 0,5 50 ∞ 25(3)
P3 0 55(2) 0,5 5000(2) ∞ 250(3)
(1)
EDC7 responds to keyword protocol 2000 request messages within the 10ms time slice, which causes, that P2
can be longer than the currently active P2min value. Nevertheless it is granted that P2min will never be undershot
(if set to a value greater than 0 ms).
(2)
Timing parameter changeable by accessTimingParameters service.
(3)
Hex-value Px = FFh means t = ∞
Values controlled by the ECU are shaded (default delays and thresholds for detection of tester time-outs).
EDC7 allows to perform communication without inter-block-times. Request messages from the tester are
evaluated by the ECU every 10 milliseconds (in the ECUProgrammingMode every 1 millisecond). Response
messages will be transmitted to the tester right afterwards.
14.2.4 Initialization
There is no initialization or wake-up defined for diagnostic communication on CAN. The external tester
device may start the communication with any available diagnostic service and the EDC7 will immediately
activate the diagnostic protocoll and send the appropiate response. A baudrate of 250 kBaud is used for the
diagnostic communication on CAN.

This page intentionally left blank

14 Data Link Layer: Software Documentation Page 14-1 EDC7 Keyword Protocol 2000

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

14 Data Link Layer: Software Documentation Page 14-1 EDC7 Keyword Protocol 2000

Uploaded by

Copyright:

Available Formats

Software Documentation Page 14-1

Y281 S365_KWP_V14 EDC7 Keyword Protocol 2000 Version 1.4

14 Data Link Layer

14.1 Data Link Layer on K line

14.1.1 Message structure

Header Data bytes Checksum

14.1.1.2 Format Byte

14.1.1.3 Target Address Byte

DS-NF/ESN2 15-JAN-2004 Data link layer

14.1.1.4 Source Address Byte

Data bytes Checksum

Fmt Sid Data CS

Checksum calculation 1 byte

Header without address Information, no additional length byte

Data bytes Checksum

Fmt Len Sid Data CS

Checksum calculation 1 byte

Header without address Information, additional length byte

Data bytes Checksum

Fmt Tgt Src Sid Data CS

Checksum calculation 1 byte

Header with address Information, no additional length byte

Data bytes Checksum

Fmt Tgt Src Len Sid Data CS

Checksum calculation 1 byte

Header with address Information, additional length byte

Fmt Format byte Sid Service identification Byte

DS-NF/ESN2 15-JAN-2004 Data link layer

14.1.1.5 Length Byte

Data length Length provided in

14.1.2 Data Bytes

14.1.3 Checksum Byte

14.1.4 Message Interchange

Tester ECU Tester

Message flow timing

DS-NF/ESN2 15-JAN-2004 Data link layer

Timing lower limit values upper limit values

14.1.6.1 Fast Initialization

DS-NF/ESN2 15-JAN-2004 Data link layer

Tester Wake up StartCommunication

Values of TWuP and TiniL are defined below:

Durations Range min. max.

DS-NF/ESN2 15-JAN-2004 Data link layer

14.1.7 Key Bytes

14.1.8 Information Frames

14.1.9 Error Handling

14.1.9.1 Tester Error Handling

Tester detects... Action

14.1.9.2 ECU Error Handling

ECU detects... Action

DS-NF/ESN2 15-JAN-2004 Data link layer

ECU detects... Action

DS-NF/ESN2 15-JAN-2004 Data link layer

14.2 Data Link and Network Layer on CAN

14.2.1 Identifier for diagnostic CAN messages

14.2.1.1 CAN Identifier for extended addressing

Diagnostic CAN message transmitted by EDC7 using extended addressing:

CAN Identifier (Hex) CAN frame data field (Hex)

Diagnostic CAN message transmitted by external device using extendend addressing:

CAN Identifier (Hex) CAN frame data field (Hex)

14.2.2 Network protocol information of diagnostic CAN messages

DS-NF/ESN2 15-JAN-2004 Data link layer

Network Protocol Control Information (N_PCI) bytes