ISO 14229-8:2020
(Main)Road vehicles — Unified diagnostic services (UDS) — Part 8: UDS on Clock eXtension Peripheral Interface (UDSonCXPI)
Road vehicles — Unified diagnostic services (UDS) — Part 8: UDS on Clock eXtension Peripheral Interface (UDSonCXPI)
This document specifies the implementation of a common set of unified diagnostic services (UDS) on clock extension peripheral interface networks in road vehicles. The UDSonCXPI diagnostics defines methods to implement diagnostic data transfer between a client and the CXPI slave nodes via the CXPI master node. This document specifies support of three different diagnostic classes for CXPI slave nodes. This document references ISO 14229-1 and ISO 14229-2 and specifies implementation requirements of the UDSonCXPI communication protocol for mainly HMI (Human Machine Interface), but not limited to, electric/electronic systems of road vehicles. UDSonCXPI defines how to implement the diagnostic data transfer between a client and CXPI slave nodes via CXPI master node. NOTE UDSonCXPI does not specify any requirement for the in-vehicle CXPI bus architecture. This document refers to information contained in ISO 14229-1, ISO 14229-2 and ISO 20794 (all parts). This document does not include any redundant information of the above-mentioned documents. It focuses on — additional requirements specific to the implementation of UDSonCXPI network, and — specific restrictions in the implementation of UDSonCXPI network.
Véhicules routiers — Services de diagnostic unifiés (SDU) — Partie 8: Partie 8: SDU sur l’interface périphérique d’extension d’horloge (UDSonCXPI)
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14229-8
First edition
2020-02
Road vehicles — Unified diagnostic
services (UDS) —
Part 8:
UDS on Clock eXtension Peripheral
Interface (UDSonCXPI)
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 8: Partie 8: SDU sur l’interface périphérique d’extension
d’horloge (UDSonCXPI)
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 Abbreviated terms . 2
5 Conventions . 2
6 SIP – Service interface parameters . 2
6.1 SIP – General . 2
6.2 SIP — Data type definitions . 2
6.3 SIP — A_Mtype, message type . 3
6.4 SIP — A_TAtype, target address type . 3
6.5 SIP — A_TA, target address . 3
6.6 SIP — A_SA, source address . 3
6.7 SIP — A_Length, length of A_PDU . 4
6.8 SIP — A_Data, protocol data unit . 4
6.9 SIP — A_SCT, sequence count . 4
6.10 SIP — A_Result, result. 4
6.11 SIP — ev_wakeup_ind, event wake-up indication (optional) . 4
6.12 SIP — cmd_wakeup_req, command wake-up request . 5
6.13 SIP — NMInfo, network management information . . 5
7 APP – Application . 5
7.1 APP – General . 5
7.2 APP – Definition of diagnostic classes . 6
7.2.1 APP – Overview . 6
7.2.2 APP – Diagnostic class I . 6
7.2.3 APP – Diagnostic class II. 6
7.2.4 APP – Diagnostic class III . 6
7.3 APP – CXPI master node requirements – Master node fault management, sensor
reading, I/O control . 7
7.4 APP – CXPI slave node requirements . 7
7.4.1 APP – General . 7
7.4.2 APP – Error indications . 7
7.5 APP – CXPI measurement and control data diagnostics . 7
7.5.1 APP – Master handling of slave failure status measurement and control data . 7
7.5.2 APP – Slave node current failure status support . 7
7.6 APP – Network management (optional) . 8
7.7 APP – CXPI master node gateway application . 8
7.7.1 APP – General . 8
7.7.2 APP – CXPI master gateway number of subnets . 8
7.7.3 APP – CXPI master gateway address routing table . 8
7.7.4 APP – CXPI master gateway all nodes request message handling . 9
7.7.5 APP – Round trip of all node addressing with functional NAD . 9
7.7.6 APP – Round trip of all node addressing with node-specific NADs .10
8 AL – Application layer .11
8.1 AL – Client to CXPI slave node(s) communication .11
8.2 AL – Overview of UDSonCXPI services and applicability to diagnostic classes .11
8.3 AL – CommunicationControl (28 ) service .12
8.4 AL – UDSonCXPI services .13
8.4.1 AL – Supported functions .13
8.4.2 AL – Master node receive buffer length .14
8.4.3 AL – Message length is exceeded .14
8.5 AL – Protocol .14
8.6 AL – Timing .14
8.6.1 AL – General .14
8.6.2 AL – Timing parameter values .14
8.6.3 AL – Server timing performance requirements .14
8.6.4 AL – SuppressPosRspMsgIndicationBit .15
8.7 AL – Response pending .15
8.8 AL – CXPI slave node configuration services .16
8.8.1 AL – CXPI node configuration .16
8.8.2 AL – Slave node model .16
8.8.3 AL – WriteDataByIdentifier – AssignNodeAddress.20
8.8.4 AL – WriteDataByIdentifier – NodeDataDump .22
8.8.5 AL – ReadDataByIdentifier – NodeProductIdentification .23
8.8.6 AL – ReadDataByIdentifier – NodeSerialNumberIdentification .24
8.8.7 AL – ReadDataByIdentifier – NodeConfigurationFileAvailability .25
8.8.8 AL – WriteDataByIdentifier – SaveConfiguration .27
8.8.9 AL – WriteDataByIdentifier – AssignFrameIdentifierRange .28
9 PL – Presentation layer .29
10 SL – Session layer.29
10.1 SL – General .29
10.2 SL – A_Data and T_Data service interface parameter mapping.29
11 TL – Transport layer .30
11.1 TL – Service primitive interface adaptation – General information.30
11.2 TL – CXPI transport layer interface adaptation .30
11.2.1 TL – Mapping of session layer to transport layer service primitives .30
11.2.2 TL – Mapping of T_Data service primitive interface parameters .30
12 NL – Network layer .31
12.1 NL – Service primitive interface adaptation .31
12.1.1 NL – General information .31
12.1.2 NL – CXPI network layer interface adaptation .31
12.2 NL – CXPI master node .32
12.2.1 NL – Network layer .32
12.2.2 NL – Dynamic NAD assignment.32
12.2.3 NL – NodeIdentificationNumber .32
12.3 NL – Master message routing .32
12.3.1 NL – General .32
12.3.2 NL – Diagnostic request message routing .33
12.3.3 NL – Diagnostic response message routing .33
12.3.4 NL – Master node transport protocol support .33
12.4 NL – CXPI slave node .33
12.4.1 NL – General .33
12.4.2 NL – Node configuration handling .33
12.4.3 NL – Slave node diagnostic class II .34
12.4.4 NL – Slave node diagnostic class II – Fixed node address .34
12.4.5 NL – Slave node diagnostic class II – Ignore NAD 7E as broadcast.34
12.4.6 NL – Slave diagnostic class III – Network layer .34
12.4.7 NL – Slave diagnostic class III – Fixed node address .34
12.4.8 NL – Slave diagnostic class III – Accept NAD 7E as broadcast .34
13 DLL – Data link layer .34
Annex A (normative) DID parameter definitions .35
Annex B (informative) Guideline for P2 setting .36
CAN_Client
Bibliography .43
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 14229 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
This document has been created in order to enable the implementation of unified diagnostic services,
as specified in ISO 14229-1, on the clock extension peripheral interface (CXPI) networks (UDSonCXPI).
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified
in ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers.
Figure 1 illustrates the document references from ISO 14229-1, ISO 14229-2 and ISO 20794 (all parts).
This document uses only a subset of the diagnostic services defined in ISO 14229-1 (see Table 2).
Figure 1 — UDSonCXPI documents reference according to OSI model
vi © ISO 2020 – All rights reserved
INTERNATIONAL STANDARD ISO 14229-8:2020(E)
Road vehicles — Unified diagnostic services (UDS) —
Part 8:
UDS on Clock eXtension Peripheral Interface (UDSonCXPI)
1 Scope
This document specifies the implementation of a common set of unified diagnostic services (UDS) on
clock extension peripheral interface networks in road vehicles. The UDSonCXPI diagnostics defines
methods to implement diagnostic data transfer between a client and the CXPI slave nodes via the CXPI
master node.
This document specifies support of three different diagnostic classes for CXPI slave nodes.
This document references ISO 14229-1 and ISO 14229-2 and specifies implementation requirements of
the UDSonCXPI communication protocol for mainly HMI (Human Machine Interface), but not limited to,
electric/electronic systems of road vehicles. UDSonCXPI defines how to implement the diagnostic data
transfer between a client and CXPI slave nodes via CXPI master node.
NOTE UDSonCXPI does not specify any requirement for the in-vehicle CXPI bus architecture.
This document refers to information contained in ISO 14229-1, ISO 14229-2 and ISO 20794 (all parts).
This document does not include any redundant information of the above-mentioned documents.
It focuses on
— additional requirements specific to the implementation of UDSonCXPI network, and
— specific restrictions in the implementation of UDSonCXPI network.
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 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on
CAN implementation (UDSonCAN)
ISO 20794 (all parts), Road vehicles — Clock extension peripheral interface (CXPI)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14229-1, ISO 14229-2,
ISO 20794 (all parts), ISO/IEC 7498-1 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/
4 Abbreviated terms
AE address extension
APP application
C conditional
Cvt convention
GW gateway
M mandatory
ID identifier
N/A not applicable
NAD node address for slave nodes
P2 server response time
SA source address
SF single frame
TA target address
U user optional
5 Conventions
This document is based on the conventions discussed in the OSI Service Conventions
(ISO/IEC 10731:1994) as they apply for diagnostic services.
6 SIP – Service interface parameters
6.1 SIP – General
The following subclauses specify the service interface parameters and data types, which are used by
the application and application layer services.
6.2 SIP — Data type definitions
This requirement specifies the data type definitions of the UDSonCXPI service interface parameters.
REQ 0.1 SIP – Data type definitions
The data types shall be in accordance to:
2 © ISO 2020 – All rights reserved
REQ 0.1 SIP – Data type definitions
— Enum = 8-bit enumeration
— Unsigned Byte = 8-bit unsigned numeric value
— Unsigned Word = 16-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
6.3 SIP — A_Mtype, message type
This requirement specifies the message type parameter values of the CXPI service interface.
REQ 0.2 SIP – A_Mtype, message type
The A_Mtype parameter shall be of data type Enum and shall be used to identify the message type and range of
address information included in a service call.
Range: [NormalCom, DiagNodeCfg]
6.4 SIP — A_TAtype, target address type
This requirement specifies the target address type parameter values of the CXPI service interface.
REQ 0.3 SIP – A_TAtype, target address type
The A_TAtype parameter shall be of data type Enum and shall be used to encode the communication model used
by the communicating peer entities. Two communication models are specified: '1 to 1' communication, called
physical addressing, and '1 to n' communication, called functional addressing.
Range: [physical, functional]
6.5 SIP — A_TA, target address
This requirement specifies the target address parameter values of the CXPI service interface.
REQ 0.4 SIP – A_TA, target address
The A_TA parameter shall be of data type Unsigned Byte and shall be used to identify the target address of the
information to be transmitted.
Range: [0116 to FF16]
6.6 SIP — A_SA, source address
This requirement specifies the source address parameter values of the CXPI service interface.
REQ 0.5 SIP – A_SA, source address
The A_SA parameter shall be of data type Unsigned Byte and shall be used to identify the source address of the
received information.
Mtype = DiagNodeCfg: Range = [00 to FC ]
16 16
6.7 SIP — A_Length, length of A_PDU
This requirement specifies the length of PDU parameter value of the CXPI service interface.
REQ 0.7 SIP – A_Length, length of PDU
The A_Length parameter shall be of data type Unsigned Byte and shall contain the length of the A_PDU to be
requested transmission/notified reception.
6.8 SIP — A_Data, protocol data unit
This requirement specifies the protocol data unit parameter values of the CXPI service interface.
REQ 0.8 SIP – A_Data, protocol data unit
The A_Data parameter shall be of data type Byte Array and shall contain the packet data (A_Data) content of
the request or response packet to be transmitted/received.
Range: [00 to FF ]
16 16
6.9 SIP — A_SCT, sequence count
This requirement specifies the sequence count parameter values of the CXPI service interface.
REQ 0.9 SIP – A_SCT, sequence count
The A_SCT parameter shall be of data type 2-bit Numeric and shall contain the sequence count information in
the response field to be transmitted/received.
Range: [0 to 1 ]
02 12
6.10 SIP — A_Result, result
This requirement specifies the result parameter values of the CXPI service interface.
REQ 0.10 SIP – A_Result, result
The A_Result parameter shall be of data type 16-bit Bit String and shall contain the status relating to the
outcome of a service execution. If two or more errors are discovered at the same time, then the transport or
network layer entity shall set the appropriate error bit in the Result parameter.
Range: [OK, DLL_Arb_Lost, Err_DLL_Byte, Err_DLL_CRC, Err_DLL_DLC,
Err_DLL_DLCext, Err_DLL_Parity, Err_DLL_Framing, Err_NL_TIMEOUT_A,
Err_TL_Ptype, Err_TL_PCI_DL_Value, Err_APP_SCT]
Range: [0 to 1 ] (1-bit per result)
2 2
6.11 SIP — ev_wakeup_ind, event wake-up indication (optional)
This requirement specifies the event wake-up indication parameter values of the CXPI service interface.
REQ 0.11 SIP – ev_wakeup_ind, event wake-up indication (optional)
The ev_wakeup_ind parameter shall be of data type Enum and shall include the event wake-up indication infor-
mation. Table 1 describes the network management values.
Range: [ev_wakeup_pulse_detect, ev_dominant_pulse_detect, ev_clk_detect, ev_clk_loss]
4 © ISO 2020 – All rights reserved
Table 1 — ev_wakeup_ind, event wake-up indication (optional)
Enum values Description
ev_wakeup_pulse_detect
This service interface parameter value indicates the reception of the wake-up
pulse event from the lower OSI layers. This parameter is optional if cmd_wake-
up_pulse_on in Table 2 is (optional).
ev_dominant_pulse_detect
This service interface parameter value indicates the reception of the dom-
inant pulse event from the lower OSI layers. This parameter is optional if
cmd_wakeup_pulse_on in Table 2 is (optional).
ev_clk_detect
This service interface parameter value indicates the reception of the clock
detection event from the lower OSI layers.
ev_clk_loss
This service interface parameter value indicates the reception of the clock
loss event from the lower OSI layers.
6.12 SIP — cmd_wakeup_req, command wake-up request
This requirement specifies the command wake-up request parameter values of the CXPI service
interface.
REQ 0.12 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 specifies 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 interface parameter value commands the clock generator to turn
on the clock transmission to the lower OSI layers.
cmd_clk_generator_off
This service interface parameter value commands the clock generator to turn
off the clock transmission to the lower OSI layers.
cmd_wakeup_pulse_on
This service interface parameter value commands the transmission of the
(optional)
wake-up pulse to the lower OSI layers.
6.13 SIP — NMInfo, network management information
This requirement specifies the network management information parameter values of the CXPI service
interface.
REQ 0.13 SIP – NMInfo, network management information
The NMInfo parameter shall be of data type 2-bit Bit String and shall contain the NetMngt information in
the response field.
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 APP – Application
7.1 APP – General
The subclauses define how the diagnostic services, as defined in ISO 14229-1, apply to CXPI.
To allow a common implementation of application layer and session layer for the ISO 20794 series and
other communications, this document uses the session layer protocol as defined in ISO 14229-2 and
focuses on necessary modifications and interfaces to adopt it to the ISO 20794 series.
The subfunction parameter definitions consider that the most significant bit is used for the
suppressPosRspMsgIndicationBit parameter as defined in ISO 14229-1.
It is the vehicle manufacturer’s responsibility to setup the CXPI master and slave nodes to exchange
UDSonCXPI information according to the ISO 20794 series documents.
7.2 APP – Definition of diagnostic classes
7.2.1 APP – Overview
Architectural, diagnostic communication performance and transport protocol requirements of slave
nodes are accommodated by classifying diagnostic services functionality into three diagnostic classes.
Therefore, a diagnostic class is assigned to each slave node according to its level of diagnostic
functionality and complexity. See Table 4 for further detail.
7.2.2 APP – Diagnostic class I
Diagnostic class I slave nodes are smart and simple devices like intelligent sensors and actuators,
requiring none or very low amount of diagnostic functionality. Actuator control, sensor reading and
fault memory handling is done by the master node, using measurement and control data carrying
messages. Therefore, specific diagnostic support for these tasks is not required. Fault indication is
always measurement and control data based.
7.2.3 APP – Diagnostic class II
A diagnostic class II slave node is similar to a diagnostic class I slave node, but it provides node
identification support. The extended node identification is normally required by vehicle manufacturers.
Test equipment or master nodes use ISO 14229-1 diagnostic services to request the extended node
identification information. Actuator control, sensor reading and fault memory handling is done by the
master node, using measurement and control data carrying messages. Therefore, specific diagnostic
support for these tasks is not required. Fault indication is always measurement and control data based.
7.2.4 APP – Diagnostic class III
Diagnostic class III slave nodes are devices with enhanced application functions, typically performing
their own local information processing (e.g. function controllers, local sensor/actuator loops). The slave
nodes execute tasks beyond the basic sensor/actuator functionality, and therefore require extended
diagnostic support. Direct actuator control and raw sensor data is often not exchanged with the master
node, and therefore not included in measurement and control data carrying messages. ISO 14229-1
diagnostic services for I/O control, sensor value reading and parameter configuration (beyond node
configuration) are required.
Diagnostic class III slave nodes have internal fault memory, along with associated reading and clearing
services. Optionally, reprogramming (flash/NVRAM reprogramming) of the slave node is possible. This
requires an implementation of a boot loader and necessary diagnostic services to unlock the device to
initiate downloads and transfer data, etc.
The primary difference between diagnostic class II and diagnostic class III is the distribution of
diagnostic capabilities to both, CXPI master node and the CXPI slave node, while for a diagnostic class III
CXPI slave node no diagnostic application features of the CXPI slave node are implemented in the CXPI
master node.
6 © ISO 2020 – All rights reserved
7.3 APP – CXPI master node requirements – Master node fault management, sensor
reading, I/O control
Diagnostic class I and diagnostic class II slave nodes provide measurement and control data-based fault
information and sensor, I/O access via measurement and control data carrying messages. The CXPI
master node is responsible to handle the slave nodes measurement and control data faults and handle
the associated DTCs. The CXPI master node serves UDS requests directly to the client/tester and acts
as a diagnostic application layer gateway. UDS services provide access to the measurement and control
data on the CXPI bus.
Diagnostic class III slave nodes are independent diagnostic entities. The CXPI master node does not
implement diagnostic services for the diagnostic capabilities of its diagnostic class III slave nodes.
7.4 APP – CXPI slave node requirements
7.4.1 APP – General
Slave nodes are typically electronic devices that are not involved in a complex data communication.
Also, their need of distributing diagnostic data is low.
7.4.2 APP – Error indications
REQ 8.1 APP – Error indications
Slave nodes shall transmit diagnostic information such as error indications in measurement and control data
carrying messages.
Node configuration services use frame ID 1F (same as the ID of master request field) and 5F (same
16 16
as the ID of slave response field). Node configuration can be performed by the master node. The NAD
is used as the target address in a diagnostic request message and as the source address in a diagnostic
response message.
Slave nodes are only accessable by the external test equipment via the CXPI master node network
connected to the diagnostic connector.
There is a one-to-many mapping between a physical slave node and a logical slave node and it is
addressed using the target address (NAD) value. This means that one physical slave node may be
composed of several logical slave nodes.
7.5 APP – CXPI measurement and control data diagnostics
7.5.1 APP – Master handling of slave failure status measurement and control data
REQ 8.2 APP – Master handling of slave failure status measurement and control data
A failure status measurement and control data shall be assigned for each failure that would result in a separate
DTC in the master node.
This information is used to indicate a failure of one of the components to the master node's application,
which can then store the associated DTC. There should be one measurement and control data per
replaceable component to simplify repair and maintenance of the vehicle.
7.5.2 APP – Slave node current failure status support
Measurement and control data diagnostics are implemented by slave nodes (diagnostic class I and II),
which do not implement a fault memory and the diagnostic protocol to directly access this fault memory
from an external test tool.
There are two types of failure transmission via measurement and control data carrying messages:
a) Type 1 failure information is periodically transmitted and encoded into an existing measurement
and control data (e.g. upper values of measurement and control data range used to indicate
specific failure conditions) by the slave node. A type 1 use case-specific failure defined by vehicle
manufacturers is not part of this document.
b) Type 2 failure information is not periodically transmitted for components which do not generate
a measurement and control data that is periodically transmitted (e.g. slave node internal failure).
Additional measurement and control data-based failure transmission shall be implemented for
type 2 failures (i.e. if a slave node is capable of locally detecting faults which are not transmitted
via the associated measurement and control data in carrying messages already).
REQ 8.3 APP – Slave node current failure status support
Each slave node shall transmit the failure status information that is monitored by the slave node to the master
node via measurement and control data carrying messages. The status information shall contain the current
failure status of the slave nodes' components. The measurement and control data shall support the states as
defined in Table 3.
Table 3 — Measurement and control data fault states
Test result Description
no test result No test execution available, default, initialization value
failed ---
passed ---
If a slave node implements more than one independent function, a status measurement and control
data can be assigned to each function. In this case only the failing function could be disabled by the
application.
7.6 APP – Network management (optional)
Network management involves wake-up and sleep functionality. The wake-up/sleep function is an
optional feature. This function manages the start and stop of transmission and reception of the message
by each node.
7.7 APP – CXPI master node gateway application
7.7.1 APP – General
The CXPI master node gateway application supports bidirectional CAN to CXPI communication as well
as multiple client backbone network handling on the CXPI subnetwork(s).
7.7.2 APP – CXPI master gateway number of subnets
REQ 8.4 APP – CXPI master gateway number of subnets
A CXPI master node gateway shall have no more than 8 subnets with a maximum of 15 CXPI slave nodes con-
nected to each subnet.
7.7.3 APP – CXPI master gateway address routing table
Each connected subnet requires an address routing table.
REQ 8.5 APP – Master node – Address routing table
The CXPI master node gateway shall implement an address routing table including CXPI target addresses
(NADs) and a supported message size for each CXPI slave node on a subnet.
8 © ISO 2020 – All rights reserved
REQ 8.6 APP – Master node – Verification of request message length
The message length of each request received from a client (on-board/off-board test equipment) shall be ver-
ified by the CXPI master node gateway application according to the CXPI slave node source address and the
supported message length in the address routing table.
If the received frame length is ≤ the supported message size of the target CXPI slave node then the message
shall be transmitted to the CXPI slave node.
If the received frame length is > the supported message size of the target CXPI slave node then the message
shall not be transmitted to the CXPI slave node.
7.7.4 APP – CXPI master gateway all nodes request message handling
REQ 8.7 APP – Master node – All nodes request message handling
The client shall send a request message to the CXPI master gateway on the backbone network including a CXPI
all nodes request message which the master node dispatches to the CXPI subnet using the 7E all nodes target
address (NAD) as specified in 7.7.6.
7.7.5 APP – Round trip of all node addressing with functional NAD
Figure 2 shows the round trip of an all node addressing with functional NAD. The test equipment
(client) sends a single message CAN message with an all node addressing with functional NAD to the
CXPI master gateway. The CXPI master gateway routes the message onto the CXPI network with the
functional all node NAD. Each CXPI slave node processes the request message and sends the response
message to the CXPI master gateway. The CXPI master gateway forwards the response message to the
test equipment (client).
Figure 2 — Round trip of all node addressing with functional NAD
Key
1 CXPI master gateway has received a CAN request message (SF ) from the client. CXPI master
Client_AllNodes
gateway verifies that the N_AE (if 11-Bit CAN ID) or N_TA (if 29-Bit CAN ID) included in the CAN request
message is listed in the address routing table (NAD 7E ) for the target CXPI subnet. CXPI master gateway
sends the "all nodes" CXPI request message onto the CXPI network.
2 CXPI slave node #1 (server 1) has received the CXPI request message from the CXPI master gateway. CXPI
slave node #1 starts the P2 timer. CXPI slave node #1 prepares the response message. CXPI slave
CXPI_Server
node #1 sends the response message to the CXPI master gateway and stops the P2 timer.
CXPI_Server
3 CXPI master gateway has received a CXPI response message (SF ) from CXPI slave node #1 (NAD
Slave1_Client
41 ). CXPI master gateway performs a transport protocol layer message routing into the CAN response
message format and sends the response message (SF ) to the client.
Slave1_Client
4 CXPI slave node #2 (server 2) has received the CXPI request message from the CXPI master gateway. CXPI
slave node #2 starts the P2 timer. CXPI slave node #2 prepares the response message. CXPI slave
CXPI_Server
node
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...