ISO 20794-4:2020

INTERNATIONAL ISO
STANDARD 20794-4
First edition
2020-02
Road vehicles — Clock extension
peripheral interface (CXPI) —
Part 4:
Data link layer and physical layer
Véhicules routiers — Interface du périphérique d'extension d'horloge
(CXPI) —
Partie 4: Couches de liaison de données et physique
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
4.1 Symbols . 2
4.2 Abbreviated terms . 3
5 Conventions . 4
6 Introduction to data link layer and physical layer . 5
6.1 Frames . 5
6.2 Frame collision avoidance . 5
6.3 Error detection and indication . 5
6.4 Clock transmission and detection . 5
7 Service interface parameters (SIP) . 5
7.1 SIP — General . 5
7.2 SIP — Data type definitions . 5
7.3 SIP — Ftype, frame type . 6
7.4 SIP — ReqId, request identifier . 6
7.5 SIP — ReqTypeId, request type identifier . 6
7.6 SIP — PDU, protocol data unit . 6
7.7 SIP — Length, length of PDU . 7
7.8 SIP — ev_wakeup_ind, event wake-up indication (optional) . 7
7.9 SIP — cmd_wakeup_req, command wake-up request . 7
7.10 SIP — NMInfo, network management information . . 8
7.11 SIP — SCT, sequence count . 8
7.12 SIP — Result, result . 8
8 Data link layer (DLL) . 8
8.1 SI — L_Data.req and L_Data.ind service interface . 8
8.2 SI — L_Data.req and L_Data.ind service interface parameter mapping . 9
8.3 DLL — Service interface with L_Ftype parameter mapping .10
8.3.1 DLL — L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_
Length = NULL) .10
8.3.2 DLL — L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_
Length ≥ 0016) . .11
8.3.3 DLL — L_Data.req and L_Data.ind interface with L_Ftype = DiagNodeCfg .12
8.4 DLL — Frame fields .13
8.4.1 DLL — Frame field definition .13
8.4.2 DLL — Request type identifier and request identifier fields.14
8.4.3 DLL — L_FI (frame information) field .15
8.4.4 DLL — L_DATA (data field) .16
8.4.5 DLL — L_CRC field .17
8.5 DLL — Internal operation .19
8.6 DLL — Timing parameters .20
8.6.1 DLL — IBS timing handling .20
8.6.2 DLL — IFS timing handling .20
8.6.3 DLL — Beginning condition of frame .21
8.6.4 DLL — Start of frame .22
8.6.5 DLL — Frame transmission time .22
8.7 DLL — Completion of frame .23
8.7.1 DLL — General .23
8.7.2 DLL — Completing condition of L_PTYPE field .23
8.7.3 DLL — Completing condition of L_PID field .23
8.7.4 DLL — Completing condition of frame .24
8.8 DLL — Byte arbitration .24
8.9 DLL — Function models .24
8.9.1 DLL — Transmission logic .24
8.9.2 DLL — Reception logic .25
8.10 DLL — Error detection .26
8.10.1 DLL — General .26
8.10.2 DLL — Byte error (Err_DLL_Byte) .26
8.10.3 DLL — CRC error (Err_DLL_CRC) .27
8.10.4 DLL — Parity error (Err_DLL_Parity) .27
8.10.5 DLL — Data length code error (Err_DLL_DLC) .27
8.10.6 DLL — Data length code extension error (Err_DLL_DLCext) .27
8.10.7 DLL — Framing error (Err_DLL_Framing) .28
8.10.8 DLL — Exception handling for L_FI_DLC = '1111 ' detection .28
9 Physical layer (PHY) .28
9.1 PHY — Overview .28
9.2 PHY — Concept of waveform generation .29
9.3 PHY — Physical signalling (PS) requirements .30
9.3.1 PHY — PS general .30
9.3.2 PHY — PS physical interface configuration .31
9.3.3 PHY — PS bit rate .31
9.3.4 PHY — PS bit sample timing .31
9.3.5 PHY — PS encoding and decoding logic .32
9.3.6 PHY — PS clock generation .35
9.3.7 PHY — PS node clock synchronization and bit synchronization .36
9.3.8 PHY — PS detection of clock existence .36
9.3.9 PHY — PS bit-wise collision resolution .37
9.3.10 PHY — PS AC parameters.37
9.3.11 PHY — PS node transmission of wake-up pulse .38
9.4 PHY — Physical medium attachment (PMA) requirements .39
9.4.1 PHY — PMA general .39
9.4.2 PHY — PMA electrical parameters.40
9.4.3 PHY — PMA AC parameters .42
9.4.4 PHY — PMA wake-up pulse and dominant pulse filter time .50
9.5 PHY — Physical media dependent (PMD) sub-layer requirements .53
9.5.1 PHY — PMD entity requirements .53
9.5.2 PHY — PMD device interface requirements .53
9.6 PHY — Physical media (PM) sub-layer requirements .54
9.7 PHY — Control and event services .54
9.7.1 PHY — Control and event service interface .54
9.7.2 PHY — Wake-up request .55
9.7.3 PHY — Wake-up event .55
Bibliography .56
iv © ISO 2020 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
A list of all parts in the ISO 20794 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
ISO 20794 (all parts) specifies the application (partly), application layer, transport layer, network
layer, data link layer, and physical layer requirements of an in-vehicle network called "clock extension
peripheral interface (CXPI)".
CXPI is an automotive low-speed single-wire network. It is an enabler for reducing vehicle weight and
fuel consumption by reducing wire counts to simple devices like switches and sensors.
CXPI serves as and is designed for automotive control applications, for example door control group,
light switch, and HVAC (Heating Ventilation and Air Conditioning) systems.
The CXPI services, protocols, and their key characteristics are specified in different parts according to
the OSI layers.
— Application and application layer
— application measurement and control data communication to exchange information between
applications in different nodes based on message communication;
— wake-up and sleep functionality;
— two kinds of communication methods can be selected at system design by each node:
i) the event-triggered method, which supports application measurement- and control-based
(event-driven) slave node communication, and
ii) the polling method, which supports slave node communication based on a periodic master
schedule;
— performs error detection and reports the result to the application;
— application error management.
— Transport layer and network layer
— transforms a message into a single packet;
— adds protocol control information for diagnostic and node configuration into each packet;
— adds packet identifier for diagnostic and node configuration into each packet;
— performs error detection and reports the result to higher OSI layers.
— Data link layer and physical layer
— provides long and short data frames;
— adds a frame identifier into the frame;
— adds frame information into the frame;
— adds a cyclic redundancy check into the frame;
— performs byte-wise arbitration and reports the arbitration result to higher OSI layers;
— performs frame type detection in reception function;
— performs error detection and reports the result to higher OSI layers.
— performs Carrier Sense Multiple Access (CSMA);
— performs Collision Resolution (CR);
vi © ISO 2020 – All rights reserved

— generates a clock, which is transmitted with each bit to synchronise the connected nodes on the
CXPI network;
— supports bit rates up to 20 kbit/s.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified
[1]
in ISO/IEC 7498-1 and ISO/IEC 10731 , which structures communication systems into seven layers.
Figure 1 illustrates an overview of communication frameworks beyond the scope of this document
including related standards:
— vehicle normal communication framework, which is composed of ISO 20794-2, and ISO 20794-5;
[3]
— vehicle diagnostic communication framework, which is composed of ISO 14229-1, ISO 14229-2 ,
[4]
and ISO 14229-8 ;
[6]
— presentation layer standards, e.g. vehicle manufacturer specific or ISO 22901-1 ODX ;
— lower OSI layers framework, which is composed of ISO 20794-3, ISO 20794-4, ISO 20794-6, and
ISO 20794-7 conformance testing.
[4]
ISO 20794 (all parts) and ISO 14229-8 are based on the conventions specified in the OSI Service
[1]
Conventions (ISO/IEC 10731) as they apply for all layers and the diagnostic services.
Figure 1 — ISO 20794 documents reference according to OSI model
INTERNATIONAL STANDARD ISO 20794-4:2020(E)
Road vehicles — Clock extension peripheral interface
(CXPI) —
Part 4:
Data link layer and physical layer
1 Scope
This document specifies the CXPI data link layer and the CXPI physical layer.
The DLL is based on:
— priority-based CXPI network access;
— non-destructive content-based arbitration;
— broadcast frame transfer and acceptance filtering; and
— node related error detection and error signalling.
The CXPI physical layer (PHY) requirements comprise of:
— physical signalling (PS) sub-layer, which specifies the requirements of the clock generation function,
the encoding and decoding of CXPI frames, and bit-wise collision resolution logic;
— physical media attachment (PMA) sub-layer, which specifies the requirements of the signal shaping
waveform logic;
— physical media dependent (PMD) sub-layer, which specifies the requirements of the CXPI network
termination, electrostatic discharge protection, etc., and device connector requirements; and
— physical media (PM), which specifies the requirements of the CXPI network cable/wiring harness.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 20794-2, Road vehicles — Clock extension peripheral interface (CXPI) — Part 2: Application layer
ISO 20794-3, Road vehicles — Clock extension peripheral interface (CXPI) — Part 3: Transport and
network layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20794-2, ISO 20794-3, and
ISO/IEC 7498-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
bit rate
transmission speed (bit/s) of the protocol within the specification range of transmit frames
3.3
higher OSI layer
OSI layer 3 or more than higher number of layers
3.4
idle state
state of the CXPI network when no frames are exchanged (idle state) and only the clock exists to
synchronise the nodes
3.5
inter frame space
IFS
time interval between frames on the CXPI network
4 Symbols and abbreviated terms
4.1 Symbols
C total bus capacitance
BUS
C capacity of CXPI network
LINE
C capacity of master node
MASTER
C capacity of slave node
SLAVE
kbit/s kilobit per second
LEN length of CXPI bus wire
BUS
R total bus-resistor including all slave nodes resistors and master node resistor
BUS
R master node resistor
MASTER
R slave node resistor
SLAVE
t bit time
bit
t bit time of reference bit rate
bit_ref
t difference of the dominant time between logical value '1' and logical value '0'
rx_dif_cont
t time that the receiving clock master detects the width of dominant level as the wake-
rx_wakeup_clk
up pulse.
t time that the receiving node detects each width of dominant level in the wake-up pulse.
rx_wakeup
t limitation time of acceptance second dominant pulse in the wake-up pulse from first
rx_wakeup_space
dominant pulse.
2 © ISO 2020 – All rights reserved

t time that the transceiver node transmits the dominant voltage of the wake-up pulse
tx_wakeup
t interval time between two of dominant level of transmitting wake-up pulse
tx_wakeup_space
t dominant time of logical value '0'
tx_0_lo
t dominant time of logical value '0' (TH = 30 % of V )
tx_0_lo_dom tx_dom SUP
t at the time of logical value '0' outputs, time from the LO level detection of the CXPI
tx_0_pd
network until falling the voltage TH = 30 % of V
tx_dom SUP
t dominant time of logical value '1'
tx_1_lo
t dominant time of logical value '1' (TH = 30 % of V )
tx_1_lo_dom tx_dom SUP
t dominant time of logical value '1' (TH = 70 % of V )
tx_1_lo_rec tx_rec SUP
TH dominant threshold voltage of the driver node
tx_dom
TH recessive threshold voltage of the driver node
tx_rec
TH dominant threshold voltage of the received node
rx_dom
TH recessive threshold voltage of the received node
rx_rec
V voltage of CXPI network
BUS
V centre recessive threshold voltage of the received node
BUS_CNT
V dominant voltage of the received node
BUSdom
V recessive voltage of the received node
BUSrec
V hysteresis voltage between the recessive threshold voltage and the dominant thresh-
HYS
old voltage of the received node
V maximum recessive level of logical value “1”
rec_master
V measured value of the dominant threshold voltage of the received node
th_dom
V measured value of the recessive threshold voltage of the received node
th_rec
4.2 Abbreviated terms
AC alternating current
CRC cyclic redundancy check
CT count
DLC data length code
DLL data link layer
ECU electronic control unit
FI frame information
Ftype frame type
HI high
IBS inter byte space
ID identifier
IFS inter frame space
ind indicator
L_ link
LO low
LSB least significant byte
MSB most significant byte
NM network management
NRZ non-return to zero
OSI open systems interconnection
PDU protocol data unit
PID protected identifier
PHY physical layer
PM physical media
PMA physical media attachment
PMD physical media dependent
PS physical signalling
PTYPE protected type identifier
PWM pulse width modulation
ReqId request identifier
ReqTypeId request type identifier
RX PMA receiver interface signal
PWM
RXD PS receiver interface signal
NRZ
SIP service interface parameter
TH threshold
TX PMA transmit interface signal
PWM
TXD PS transmitter interface signal
NRZ
5 Conventions
This document is based on the conventions discussed in the OSI Service Conventions as specified in
ISO/IEC 10731.
4 © ISO 2020 – All rights reserved

6 Introduction to data link layer and physical layer
6.1 Frames
Information on the CXPI network is sent in fixed format frames of different limited lengths. When the
CXPI network is in idle state, any connected node is allowed to start the transmission of a Protected
Identifier (PID). The CXPI network is in idle state when no frames are transmitted.
6.2 Frame collision avoidance
If two or more nodes start to transmit a PID value at the same time, the bus access conflict is resolved
by content-based arbitration using the PID value. The transmitter with the PID value of the highest
priority gains the bus access.
6.3 Error detection and indication
For detecting errors, the following measures are specified:
— byte value error (Err_DLL_Byte);
— cyclic redundancy check value error (Err_DLL_CRC);
— data length code value error (Err_DLL_DLC);
— data length code extension value error (Err_DLL_DLCext);
— parity value error (Err_DLL_Parity); and
— framing value error (Err_DLL_Framing).
To confirm an error occurrence during data transmission and reception, an error indication to the
higher OSI layers is provided.
6.4 Clock transmission and detection
The node (master node by default), that generates the clock, continuously transmits the clock to the
CXPI network. Clock existence is detected by the falling edge of the clock on the CXPI network. A node
performs communication synchronised with the node, that generates the clock.
7 Service interface parameters (SIP)
7.1 SIP — General
The following subclauses specify the service interface parameters and data types, which are used by
the CXPI data link and physical layer services.
7.2 SIP — Data type definitions
This requirement specifies the data type definitions of the CXPI service interface.

REQ 0.1 SIP — Data type definitions
The data types shall be in accordance to:
— Enum = 8-bit enumeration
— Unsigned Byte = 8-bit unsigned numeric value
— Byte Array = sequence of 8-bit aligned data
— 2-bit Bit String = 2-bit binary coded
— 8-bit Bit String = 8-bit binary coded
— 16-bit Bit String = 16-bit binary coded
7.3 SIP — Ftype, frame type
This requirement specifies the frame type parameter value of the CXPI service interface.
REQ 0.2 SIP — Ftype, frame type
The Ftype parameter shall be of data type Enum and shall be used to identify the frame type and range of
address information included in a service call.
Range: [NormalCom, DiagNodeCfg]
7.4 SIP — ReqId, request identifier
This requirement specifies the request identifier parameter value of the CXPI service interface.
REQ 0.3 SIP — ReqId, request identifier
The ReqId parameter shall be of data type Unsigned Byte and shall contain the request identifier.
Range: [01 to 7F ]
16 16
7.5 SIP — ReqTypeId, request type identifier
This requirement specifies the request type identifier parameter value of the CXPI service interface.
REQ 0.4 SIP — ReqTypeId, request type identifier
The ReqTypeId parameter shall be of data type Unsigned Byte and shall contain the request type identifier.
Range: [00 ] in DLL
NOTE ReqTypeId is used by the application to enable the polling method. It has a fixed value.
7.6 SIP — PDU, protocol data unit
This requirement specifies the protocol data unit parameter value of the CXPI service interface.
REQ 0.5 SIP — PDU, protocol data unit
The PDU parameter shall be of data type Byte Array and shall contain the frame data (PDU) content of the
request or response frame to be transmitted/received.
Range: [00 to FF ]
16 16
6 © ISO 2020 – All rights reserved

7.7 SIP — Length, length of PDU
This requirement specifies the length parameter value of the CXPI service interface.
REQ 0.6 SIP — Length, length of PDU
The Length parameter shall be of data type Unsigned Byte and shall contain the length of the PDU to be
transmitted/received.
Range: [00 to FF ]
16 16
7.8 SIP — ev_wakeup_ind, event wake-up indication (optional)
This requirement specifies the event wake-up indication parameter value of the CXPI service interface.
REQ 0.7 SIP — ev_wakeup_ind, event wake-up indication (optional)
The ev_wakeup_ind parameter shall be of data type Enum and shall include the network management informa-
tion in the response, which is composed of wake-up indication information of a CXPI node.
Table 1 describes the network management information values.
Range: [ev_wakeup_pulse_detect, ev_dominant_pulse_detect, ev_clk_detect,
ev_clk_loss]
Table 1 — ev_wakeup_ind, event wake-up indication (optional)
Enum values Description
ev_wakeup_pulse_detect
This service primitive parameter value indicates the reception of the
wake-up pulse event from the DLL. This parameter is optional if cmd_
wakeup_pulse_on in Table 2 is (optional).
ev_dominant_pulse_detect
This service primitive parameter value indicates the reception of the
dominant pulse event from the DLL. This parameter is optional if cmd_
wakeup_pulse_on in Table 2 is (optional).
ev_clk_detect
This service primitive parameter value indicates the reception of the
clock detection event from the DLL.
ev_clk_loss
This service primitive parameter value indicates the reception of the
clock loss event from the DLL.
7.9 SIP — cmd_wakeup_req, command wake-up request
This requirement specifies the command wake-up request parameter value of the CXPI service
interface.
REQ 0.8 SIP — cmd_wakeup_req, command wake-up request
The cmd_wakeup_req parameter shall be of data type Enum and shall include the wake-up request command
information to wake-up a CXPI node. Table 2 describes the cmd_wakeup_req values.
Range: [cmd_clk_generator_on, cmd_clk_generator_off, cmd_wakeup_pulse_on]
Table 2 — cmd_wakeup_req values
Enum values Description
cmd_clk_generator_on
This service primitive parameter value commands the clock generator
to turn on the clock transmission to the DLL.
cmd_clk_generator_off
This service primitive parameter value commands the clock generator
to turn off the clock transmission to the DLL.
cmd_wakeup_pulse_on (optional)
This service primitive parameter value commands the transmission of
the wake-up pulse to the DLL.
7.10 SIP — NMInfo, network management information
This requirement specifies the network management information parameter value of the CXPI service
interface.
REQ 0.9 SIP — NMInfo, network management information
The NMInfo parameter shall be of data type Enum and shall contain the NM information in the response field.
Type:  Enum
Range: 00 = [no request for wakeup_ind, sleep_ind prohibition]
01 = [no request for wakeup_ind, sleep_ind permission]
10 = [request for wakeup_ind, sleep_ind prohibition]
11 = [request for wakeup_ind, sleep_ind permission]
7.11 SIP — SCT, sequence count
This requirement specifies the sequence count parameter value of the CXPI service interface.
REQ 0.10 SIP — SCT, sequence count
The SCT parameter shall be of data type Unsigned Byte and shall contain the sequence count information in
the response field to be transmitted/received.
Type: 2-bit Unsigned Byte
Range: [00 to 11 ]
2 2
7.12 SIP — Result, result
This requirement specifies the result parameter value of the CXPI service interface.
REQ 0.11 SIP — Result, result
The Result parameter shall be of data type Bit String and shall contain the status relating to the outcome of
a ReqField or RespField execution.
Range: [OK, DLL_Arb_Lost, Err_DLL_Byte, Err_DLL_CRC, Err_DLL_DLC,
Err_DLL_DLCext, Err_DLL_Parity, Err_DLL_Framing]
Range: [0 to 1 ]
2 2
8 Data link layer (DLL)
8.1 SI — L_Data.req and L_Data.ind service interface
The service interface defines the service primitives and parameter mapping to the DLL.
Figure 2 shows the DLL L_Data.req and L_Data.ind service interface.
8 © ISO 2020 – All rights reserved

Key
1 service access point
2 read back from CXPI network provided by lower OSI layer
t time
Figure 2 — DLL L_Data.req and L_Data.ind service interface
For normal communication (NormalCom) the sender node transmits, if master node, either a request
protected type identifier field (polling method), or a request protected identifier field (L_Data.req).
All nodes receive the request protected identifier field of type NormalCom (L_Data.ind). The node,
which has corresponding PDU data transmits the response PDU (L_Data.req) and all nodes receive the
response PDU (L_Data.ind).
For diagnostic and node configuration (DiagNodeCfg) the sender node transmits a request message
including a protected identifier field and the N_PDU (L_Data.req) onto the CXPI network. All nodes
receive the DiagNodeCfg request message (L_Data.ind). The node(s), which is (are) targeted by the
request message, transmit a DiagNodeCfg response message (L_Data.req) onto the CXPI network.
8.2 SI — L_Data.req and L_Data.ind service interface parameter mapping
This requirement specifies the data link layer service interface parameter mapping to lower OSI layers.
REQ 2.1 SI — L_Data.req and L_Data.ind service interface parameter mapping
The L_Data.req and L_Data.ind service interface parameter mapping is specified in Table 3.
The normal communication frame (NormalCom) either consists of a L_ReqId (L_PID) only (L_
Length = NULL) or L_ReqId (L_PID) and a response L_PDU (L_Length ≥ 00 ).
The diagnostic and node configuration frame (DiagNodeCfg) always consist of a L_ReqId (L_PID) and a
response L_PDU. Therefore, the L_Length > 00 .
Table 3 — L_Data.req and L_Data.ind service interface parameter mapping
L_Data.req and L_Data.ind parameter validity
Higher OSI layers Data link layer NormalCom with L_Length DiagNodeCfg with L_Length
(service user) (service provider) = NULL ≥00 >00
16 16
.req .ind .req .ind .req .ind
a a a a a a
N_Ptype L_Ftype
X X X X X X
c c a a a a
N_Length L_Length
— — X X X X
a a a a a a
N_ReqId L_ReqId
X X X X X X
b b a a c c c c
N_ReqTypeId L_ReqTypeId X X — — — —
c c a a a a
N_PDU L_DATA
— — X X X X
c c a a a a
N_NMInfo L_NMInfo
— — X X X X
c c a a a a
N_SCT L_SCT
— — X X X X
c a c a c a
N_Result L_Result
— X — X — X
NOTE  A service interface call either includes a ReqId or a ReqTypeId parameter.
a
Supported "X".
b
Not used if DiagNodeCfg.
c
Not supported "—".
8.3 DLL — Service interface with L_Ftype parameter mapping
8.3.1 DLL — L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_Length = NULL)
This requirement specifies the data link layer frame type NormalCom with L_Length = NULL via the
L_Data.req and L_Data.ind interface.
REQ 2.2 DLL — L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_Length = NULL)
The L_Data.req and L_Data.ind service interface with L_Ptype = NormalCom with L_Length = NULL shall
use the service interface parameters specified in Table 3 and Figure 3.
If the DLL provider is the sender then the following mapping shall be implemented for a L_Data.req:
—  L_Ftype = N_Ptype(NormalCom);
—  L_ReqTypeId = N_ReqTypeId;
—  L_ReqTypeId[Bit 6 to Bit 0] = N_ReqTypeId;
—  L_ReqTypeId[Bit 7] = ODD_Parity(N_ReqTypeId);
—  L_ReqId[Bit 6 to Bit 0] = N_ReqId;
—  L_ReqId[Bit 7] = ODD_Parity(N_ReqId);
—  L_Length = NULL.
If the DLL provider is the receiver then the following mapping shall be implemented for a L_Data.ind:
—  N_Ptype = L_Ftype(NormalCom);
—  N_ReqTypeId = L_ReqTypeId;
—  N_ReqId = L_ReqId;
—  N_Length = NULL;
—  N_Result = L_Result.
10 © ISO 2020 – All rights reserved

Figure 3 — DLL L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_Length = NULL)
8.3.2 DLL — L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_Length ≥ 0016)
This requirement specifies the data link layer frame type NormalCom with L_Length ≥ 00 via the
L_Data.req and L_Data.ind interface.
REQ 2.3 DLL — L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_Length ≥ 00 )
The L_Data.req and L_Data.ind service interface with L_Ftype = NormalCom with L_Length ≥ NULL shall
use the service interface parameters specified in Table 3 and Figure 4.
If the DLL provider is the sender then the following mapping shall be implemented for a L_Data.req:
—  L_Ftype = N_Ptype(NormalCom);
—  L_ReqId[Bit 6 to Bit 0] = N_ReqId;
—  L_ReqId[Bit 7] = ODD_Parity(N_ReqId);
—  If (0 <= N_Length ≤ 12) then (L_FI_DLC = N_Length) else
(L_FI_DLC = 1111 and L_FI_DLCext = N_Length);
—  L_PDU = [F_FI, N_PDU, L_CRC];
—  L_MNInfo = N_MNInfo;
—  L_SCT = N_SCT.
If the DLL provider is the receiver then the following mapping shall be implemented for a L_Data.ind:
—  N_Ptype = L_Ftype(NormalCom);
—  N_ReqId = L_ReqId[Bit 6 to Bit 0];
—  N_Length = L_Length;
—  If (L_FI_DLC ≤ 12) then (N_Length = L_FI_DLC) else
(N_Length = L_FI_DLCext);
—  N_PDU = [L_PDU, w/o L_FI, w/o L_CRC];
—  N_MNInfo = L_MNInfo;
—  N_SCT = L_SCT;
—  N_Result = L_Result.
Figure 4 — DLL L_Data.req and L_Data.ind with L_Ftype = NormalCom (L_Length ≥ 0016)
8.3.3 DLL — L_Data.req and L_Data.ind interface with L_Ftype = DiagNodeCfg
This requirement specifies the data link layer frame type DiagNodeCfg via the L_Data.req and L_Data.
ind interface.
REQ 2.4 DLL — L_Data.req and L_Data.ind interface with L_Ftype = DiagNodeCfg
The L_Data.req and L_Data.ind service interface with L_Ftype = DiagNodeCfg shall use the service inter-
face parameters specified in Table 3 and in Figure 5.
If the DLL provider is the sender then the following mapping shall be implemented for a L_Data.req:
—  L_Ftype = N_Ptype(DiagNodeCfg);
—  L_Length = LENGTH(N_PDU);
—  L_ReqId[Bit 6 to Bit 0] = N_ReqId;
—  L_ReqId[Bit 7] = ODD_Parity(N_ReqId);
—  If (0 < N_Length ≤ 12) then (L_FI_DLC = N_Length) else
(L_FI_DLC = 1111 and L_FI_DLCext = N_Length);
—  L_PDU = [F_FI, N_PDU, L_CRC];
—  L_MNInfo = N_MNInfo;
—  L_SCT = N_SCT.
If the DLL provider is the receiver then the following mapping shall be implemented for a L_Data.ind:
—  N_Ptype = L_Ftype(DiagNodeCfg);
—  N_ReqId = L_ReqId[Bit 6 to Bit 0];
—  If (L_FI_DLC ≤ 12) then (N_Length = L_FI_DLC) else
(N_Length = L_FI_DLCext);
—  N_PDU = [L_PDU, w/o L_FI, w/o L_CRC];
—  N_MNInfo = L_MNInfo;
—  N_SCT = L_SCT;
—  N_Result = L_Result.
12 © ISO 2020 – All rights reserved

Figure 5 — DLL L_Data.req and L_Data.ind with L_Ftype = DiagNodeCfg
8.4 DLL — Frame fields
8.4.1 DLL — Frame field definition
This requirement specifies the CXPI frame fields.
REQ 2.5 DLL — Frame field definition
A frame shall consist of a request protected type identifier field (polling method only), a request protected
identifier field, and a response PDU field (see Fig
...