ISO 20794-2:2020

Road vehicles - Clock extension peripheral interface (CXPI) - Part 2: Application layer

This document describes the application layer protocol including the application measurement and control data management, message transfer and fault management. The application and application layer contain the following descriptions: - message structure; - communication method; - network management (optional); - measurement and control data; and - error handling. This document also specifies: - the service interface; and - the service interface parameters.

Véhicules routiers — Interface du périphérique d'extension d'horloge (CXPI) — Partie 2: Couche Application

General Information

• Status: Published
• Publication Date: 04-Feb-2020
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 3 - In-vehicle networks
• Current Stage: 9093 - International Standard confirmed
• Start Date: 02-Jul-2025
• Completion Date: 13-Dec-2025

Overview - ISO 20794-2:2020 (CXPI Part 2: Application layer)

ISO 20794-2:2020 defines the application layer protocol for the Clock eXtension Peripheral Interface (CXPI), an automotive low‑speed single‑wire in‑vehicle network. This part specifies how applications exchange measurement and control data, manage messages and faults, and interact with lower OSI layers via a defined service interface. CXPI is intended to reduce wiring (and vehicle weight) by connecting simple devices such as switches and sensors over a single wire.

Key topics and technical requirements

• Message structure and transfer

  • Defines application layer message formats and the A_PDU response field.
  • Specifies message types and PDU (protocol data unit) handling.

• Service interface and parameters (SI / SIP)

  • Standardizes the service interface between application and lower layers (A_Data.req / A_Data.ind).
  • Lists SIP parameters such as Mtype, ReqId, ReqTypeId, PDU, Length, SCT (sequence count), Result, NMInfo, ev_wakeup_ind, and cmd_wakeup_req.

• Communication methods

  • Supports two selectable node-level methods:
    • Event‑triggered (event-driven publisher/subscriber communication)
    • Polling (master‑controlled periodic schedule)

• Network management (optional)

  • Node states (normal, standby, sleep), wake‑up/sleep sequences and related parameters.
  • Optional NM information exchanged via SIP.

• Measurement and control data management

  • Publisher/subscriber model for measurement and control data.
  • Data types, consistency requirements, ReqId assignment and priority.

• Error handling and fault management

  • Application error handling, CXPI network error reporting, optional SCT error handling, retransmission and transmission prohibition mechanisms.
  • Error detection features to report faults to the application.

Practical applications and target users

• Typical CXPI use cases: door control modules, light switches, HVAC controls, sensors and simple actuators where wiring simplification and low cost are priorities.
• Who uses this standard:
  • Automotive system architects and OEMs designing body and comfort networks.
  • ECU and microcontroller firmware engineers implementing application‑layer CXPI protocols.
  • Suppliers of switches, sensors, gateways and diagnostic tools integrating CXPI communication.
  • Test and validation teams verifying message handling, wake/sleep behavior and error management.

Related standards

• Other parts of the ISO 20794 series (transport, network, data link and physical layers) - together they define the complete CXPI stack.
• References to OSI models: ISO/IEC 7498‑1 and ISO/IEC 10731 (basic reference for layered communication).

Keywords: ISO 20794-2, CXPI, application layer, clock extension peripheral interface, in‑vehicle network, event‑triggered, polling, service interface parameters, automotive wiring reduction, measurement and control data.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 20794-2
First edition
2020-02
Road vehicles — Clock extension
peripheral interface (CXPI) —
Part 2:
Application layer
Véhicules routiers — Interface du périphérique d'extension d'horloge
(CXPI) —
Partie 2: Couche Application
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: [phone]
Fax: [phone]
Email: [e-mail]
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 . 3
4.1 Symbols . 3
4.2 Abbreviated terms . 3
5 Conventions . 4
6 Introduction to application and application layer . 4
6.1 Application properties . 4
6.2 Application layer properties . 4
6.3 Message transmission . 4
6.4 Communication methods . 4
6.5 Message types . 5
6.6 Error handling . 5
7 Service interface parameters (SIP) . 5
7.1 SIP — General . 5
7.2 SIP — Data type definitions . 5
7.3 SIP — Mtype, message 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 . 6
7.8 SIP — ev_wakeup_ind, event wake-up indication (optional) . 6
7.9 SIP — cmd_wakeup_req, command wake-up request . 7
7.10 SIP — NMInfo, network management information . . 7
7.11 SIP — SCT, sequence count . 8
7.12 SIP — Result, result . 8
8 SI — Service interface (SI) definition to application and lower OSI layers .8
8.1 SI — A_Data.req and A_Data.ind service interface . 8
8.2 SI — A_Data.req and A_Data.ind service interface parameter mapping . 9
9 Application (APP) . 9
9.1 APP — Message exchange . 9
9.2 APP — Communication methods . 9
9.2.1 APP — General . 9
9.2.2 APP — Event-triggered method .10
9.2.3 APP — Polling method . .10
9.3 APP — Network management (NM) .11
9.3.1 APP — General .11
9.3.2 APP — Normal, standby, and sleep states .12
9.3.3 APP — Normal state .13
9.3.4 APP — Sleep state (optional) .14
9.3.5 APP — Standby state (optional) .14
9.3.6 APP — Wake-up/sleep function (optional) .14
9.3.7 APP — Wake-up/sleep sequence parameter .24
9.4 APP — Multi clock master sequence processing .24
9.5 APP — Measurement and/or control data .25
9.5.1 APP — Publisher and subscriber data .25
9.5.2 APP — Measurement and/or control data management .26
9.5.3 APP — Measurement and/or control data types.26
9.5.4 APP — Measurement and/or control data consistency .26
9.5.5 APP — Assignment of ReqId . .27
9.5.6 APP — Priority of ReqId .27
9.6 APP — Error handling .28
9.6.1 APP — General .28
9.6.2 APP — CXPI network error.28
9.6.3 APP — Network management information .29
9.6.4 APP — SCT, sequence count (optional) .30
9.6.5 APP — Sequence count (SCT) error (optional) .31
9.6.6 APP — Transmission prohibition . .31
9.6.7 APP — Retransmission . .32
9.6.8 APP — Error notification on CXPI network (optional).32
10 Application layer (AL) .33
10.1 AL — Message exchange .33
10.2 AL — Message structure .34
10.3 AL — Request protected type identifier field .35
10.4 AL — Request protected identifier field .35
10.4.1 AL — General .35
10.4.2 AL — Judgment of received message .35
10.5 AL — Response field (A_PDU) .35
10.5.1 AL — General .35
10.5.2 AL — A_PDU . .35
10.5.3 AL — Wake-up indication and request .36
10.6 AL — Error detection .36
Bibliography .37
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 this document, 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
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-2:2020(E)
Road vehicles — Clock extension peripheral interface
(CXPI) —
Part 2:
Application layer
1 Scope
This document describes the application layer protocol including the application measurement and
control data management, message transfer and fault management.
The application and application layer contain the following descriptions:
— message structure;
— communication method;
— network management (optional);
— measurement and control data; and
— error handling.
This document also specifies:
— the service interface; and
— the service interface parameters.
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-3, Road vehicles — Clock extension peripheral interface (CXPI) — Part 3: Transport layer and
network layer
ISO 20794-4, Road vehicles — Clock extension peripheral interface (CXPI) — Part 4: Data link layer and
physical layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20794-3, ISO 20794-4,
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
clock master
node that transmits clock (3.4) to the lower OSI layers (3.2)
3.2
lower OSI layer
below the application layer
3.3
master node
node that provides the schedule (3.10) master management (including polling method), the primary
clock (3.6), and optionally the sleep message transmission management
3.4
clock
pulse that synchronises all nodes
3.5
normal state
state which enables transmission and reception of messages
3.6
primary clock
clock (3.4) that is provided by the master node (3.3)
3.7
publisher
node providing a message response containing application measurement and/or control data
3.8
request identifier
ReqId
parameter that requests dedicated measurement and/or control data
3.9
request type identifier
ReqTypeId
parameter that enables the polling method for dedicated measurement data and/or control data
3.10
schedule
origin of periodic message transmission
3.11
secondary clock
clock (3.4) that is provided by a dedicated slave node (3.13)
3.12
sequence
transmission and reception procedure of messages
3.13
slave node
node other than master node (3.3)
3.14
subscriber
master or slave node (3.13) that receives the data within a message
2 © ISO 2020 – All rights reserved

3.15
wake-up pulse
stimulus initiated by a node used for wake-up of other nodes
4 Symbols and abbreviated terms
4.1 Symbols
t time that the master node requests the clock to the lower OSI layers at the latest
clock_start_m
t time that the master node stops to request the clock after master node receives the
clock_stop_m
sleep message notification
t judgment time of the CXPI network error
cxpi_network_error
t time that each slave node transits to sleep state after the node receives the sleep
sleep_s
message notification
t minimum time that master node starts the request of any request field first for the
wakeup_m
wake-up sequence
t time that slave node starts the request of the second wake-up pulse after request of
wakeup_recovery_s
the first wake-up pulse
t maximum time until the slave node wakes up by the wake-up sequence
wakeup_s
t maximum time until master node starts the request of any request field (ReqId) or
wakeup_schedule_m
request field (ReqTypeId) first for the wake-up sequence
4.2 Abbreviated terms
AL application layer
APP application
CRC cyclic redundancy check
DLC data length code
ECU electronic control unit
LSB least significant bit
MSB most significant bit
Mtype message type
NMInfo network management information
NormalCom normal communication
OSI open systems interconnection
param parameter
PDU protocol data unit
ReqId request identifier
ReqTypeId request type identifier
SCT sequence count
SI service interface
SIP service interface parameter
5 Conventions
This document is based on the conventions discussed in the OSI Service Conventions as specified in
ISO/IEC 10731.
6 Introduction to application and application layer
6.1 Application properties
The application has the following properties:
— communication methods;
— message types;
— network management (optional wake-up, sleep);
— state management (state machine);
— measurement and/or control data; and
— error handling.
6.2 Application layer properties
The application layer has the following properties:
— message exchange;
— message structure; and
— service interface and parameters.
6.3 Message transmission
A message consists of a request field and a response field. The node that corresponds to a request
identifier composed in the request field can transmit the response field.
6.4 Communication methods
Two communication methods are supported:
— Event-triggered method
Each node can request a request protected identifier field and response field based on an internal
event occurrence.
4 © ISO 2020 – All rights reserved

— Polling method
The master node requests a request protected type identifier field (event request in polling
method) to the lower OSI layers and then each node can transmit a request protected identifier
field. The node corresponding to the request protected identifier field transmits the response field.
6.5 Message types
The application layer supports the following message types:
— request message field;
— response message field; and
— request sleep message field.
6.6 Error handling
The error handling is based on the following measures:
— CXPI network errors; and
— sequence count error (optional).
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 application and application layer services.
7.2 SIP — Data type definitions
This requirement specifies the data type definitions of the CXPI service interface parameters.
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
— 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
7.3 SIP — Mtype, message type
This requirement specifies the message type parameter values of the CXPI service interface.
REQ 0.2 SIP — Mtype, message type
The 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]
7.4 SIP — ReqId, request identifier
This requirement specifies the request identifier parameter values 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 ] (fixed value)
7.6 SIP — PDU, protocol data unit
This requirement specifies the protocol data unit parameter values 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 packet data (PDU) content of the
request or response packet to be transmitted/received.
Range:  [00 to FF ]
16 16
7.7 SIP — Length, length of PDU
This requirement specifies the length of PDU 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 requested transmission/notified reception. If Mtype = NormalCom then 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 values 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 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]
6 © 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_
wakeup_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.
7.9 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.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 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.
7.10 SIP — NMInfo, network management information
This requirement specifies the network management information parameter values of the CXPI service
interface.
REQ 0.9 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.11 SIP — SCT, sequence count
This requirement specifies the sequence count parameter values of the CXPI service interface.
REQ 0.10 SIP — SCT, sequence count
The 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:  [00 to 11 ]
2 2
7.12 SIP — Result, result
This requirement specifies the result parameter values of the CXPI service interface.
REQ 0.11 SIP — Result, result
The 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
8 SI — Service interface (SI) definition to application and lower OSI layers
8.1 SI — A_Data.req and A_Data.ind service interface
The service interface defines the service and parameter mapping to the application and the lower
OSI layers.
Figure 2 shows the application A_Data.req and A_Data.ind service interface.
Key
1 service access point
2 read back from CXPI network provided by lower OSI layer
Figure 2 — A_Data.req and A_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 (A_Data.req).
8 © ISO 2020 – All rights reserved

All nodes receive the request protected identifier field of type NormalCom (A_Data.ind). The node,
which has corresponding PDU data transmits the response PDU (A_Data.req) and all nodes receive the
response PDU (A_Data.ind).
8.2 SI — A_Data.req and A_Data.ind service interface parameter mapping
This requirement specifies the application service interface parameter mapping between application
and application layer and to the lower OSI layers.
REQ 0.12 SI — A_Data.req and A_Data.ind service interface parameter mapping between application
and application layer and to the lower OSI layers
The A_Data.req and A_Data.ind service interface parameter mapping is specified in Table 3.
The normal communication (NormalCom) message consists of an A_ReqId (request field) or an A_PDU
(response field). The request field has no A_PDU and therefore the A_Length = NULL. The response field
has an A_PDU and therefore the A_Length > 0.
Table 3 — A_Data.req and A_Data.ind service interface parameter mapping
Application Application layer A_Data.req and A_Data.ind parameter validity
NormalCom with A_Length
(service user) (service provider)
= NULL ≥'0'
.req .ind .req .ind
a a a a
Mtype A_Mtype X X X X
b b a a
Length A_Length — — X X
a a a a
ReqId A_ReqId X X X X
b b a a b b
ReqTypeId A_ReqTypeId X X — —
b b a a
PDU A_PDU — — X X
b b a a
NMInfo A_NMInfo — — X X
b b a a
SCT A_SCT — — X X
b a b a
Result A_Result — X — X
NOTE A service interface call either includes a ReqId or a ReqTypeId parameter.
a
Supported “X”.
b
Not supported “—”.
9 Application (APP)
9.1 APP — Message exchange
A message consists of a request protected type identifier field or a request protected identifier field and
a response field (PDU). The request protected identifier field is transmitted by a node. The node that
corresponds to the request protected identifier field value can request the response field (PDU) to the
lower OSI layers.
9.2 APP — Communication methods
9.2.1 APP — General
The CXPI communication protocol supports two communication methods.
9.2.2 APP — Event-triggered method
Each node can transmit a request protected identifier field (message request) in case it wants to
transmit a corresponding response field (response message).
REQ 8.1 APP — Communication methods — Event-triggered method
If all nodes' application software supports the event-triggered method, it shall immediately request a request
protected identifier field to the lower OSI layers. The node corresponding to the request protected identifier
field shall request the response field (PDU) including application measurement and/or control data.
Figure 3 shows a sequence example of the event-triggered method. This method is asynchronous with
the master node. The node '1' requests the request PID 'B', then the node '2' requests the response
message PDU 'B', which corresponds to the request PID 'B'. Then an event occurs in the node '3'. The
node '3' requests request PID 'C' and then node '3' requests the response PDU 'C', which corresponds to
request PID 'C'.
Then an event occurs in the node '2' application. Node '2' requests the request (PID) 'B'. The node '2'
requests request PID 'B' and then node '2' requests the response PDU 'B', which corresponds to request
PID 'B'.
The node '1' requests the request PID 'B' periodically, then the node '2' requests the response PDU 'B',
which corresponds to request PID 'B'. The slave nodes may request PIDs periodically too.
Figure 3 — Message sequence of event-triggered method
9.2.3 APP — Polling method
There are two kinds of requests that the master node requests about the request protected identifier
field and the request protected type identifier field. When the master node requests the request
protected type identifier field (event request in polling method) to the lower OSI layers, each node
can request the request protected identifier field. If multiple nodes request the request protected
identifier field at the same time and the request protected identifier fields collide on CXPI network, a
non-destructive arbitration takes place in the data link layer and the higher priority request protected
identifier field is transmitted to the CXPI network. The node corresponding to the request protected
identifier field requests the response field (PDU). The slave node only requests PDUs when it receives
the request protection identifier field or request protected type identifier field from the master node.
The slave node cannot request PDUs voluntarily.
10 © ISO 2020 – All rights reserved

Although the polling method lowers the responsivity of event compared with the event-triggered
method, the polling method can be selected to guarantee communicative periodicity.
REQ 8.2 APP — Communication methods — Polling method
If the master node application is in polling method, then the master node shall periodically request a request
protected type identifier field (event request in polling method) or a request protected identifier field, or both,
to the lower OSI layers. The node corresponding to the request protected identifier field shall request the re-
sponse field (A_PDU) including application measurement and/or control data.
Figure 4 shows an example of the polling method sequence. When the master node '1' requests the
periodic request protected identifier field PID 'B' to the lower OSI layers, each node can request the
response field. In this example, node '2' requests the response field PDU 'B'.
Then an event occurs in node '3'. The master node '1' requests a periodic request protected type
identifier field (PTYPE) to the lower OSI layers, which allows all nodes to request a request protected
identifier field. In this example, node '3' requests a request protected identifier field PID 'C' followed by
a response field PDU 'C'.
The master node '1' requests the periodic request protected identifier field PID 'C' to the lower OSI
layers and node '3' requests the response field PDU 'C'.
Figure 4 — Message sequence of polling method
9.3 APP — Network management (NM)
9.3.1 APP — General
The network management describes the wake-up/sleep function, which allows a node to transit to a
sleep state. The wake-up/sleep function is an optional feature. Implementation of the wake-up/sleep
function is selected for each node.
The master node checks the response field (PDU) with NMInfo = sleep permission of all slave nodes. If all
slave nodes confirm sleep permission, the master node requests a normal communication (NormalCom)
message with a Sleep PDU.
Master node trigger:
— The master node with an internal event, which requires data to be requested, transmits the
synchronisation clock pulse to the lower OSI layers.
Slave node trigger:
— A slave node with an internal event, which requires data to be requested, transmits a wake-up pulse
to the lower OSI layers.
— A slave node receives the synchronisation clock from the clock master, which enables the application
to transmit the data to the lower OSI layers.
9.3.2 APP — Normal, standby, and sleep states
This state manages the state of wake-up/sleep function for each node as shown in Figure 5. The state
machine supports the following three states:
a) Normal state (mandatory);
b) Standby state (optional); and
c) Sleep state (optional).
REQ 8.3 APP — NM — Normal, standby, and sleep states
The state machine shall comply to the states and state transits as specified in Figure 5.

Key
1 master node: requests clock transmission
2 wake-up condition occurred (optional)
3 CXPI network error and sleep permission (optional)
4 master node requests clock transmission (optional)
5 slave node notification of the clock (optional)
6 CXPI network error and sleep permission (optional)
7 master node: when sleep condition is satisfied (optional)
8 slave node: when preset time elapses after sleep message is received (optional)
Figure 5 — NM state machine
12 © ISO 2020 – All rights reserved

9.3.3 APP — Normal state
9.3.3.1 APP — General
In normal state, the clock is generated by the master node and received by the slave nodes. The normal
state enables transmission and reception of messages.
9.3.3.2 APP — Event-triggered method in normal state
This request specifies the normal state of an event-triggered method.
REQ 8.4 APP — NM — Event-triggered method in normal state — Wake-up/sleep not supported
After power ON the node shall transit into normal state if the wake-up/sleep and standby state features are not
supported.
REQ 8.5 APP — NM — Event-triggered method in normal state — Master node starts message
transmission
The master node shall begin message transmission after it enters the normal state.
REQ 8.6 APP — NM — Event-triggered method in normal state — Slave node starts message
transmission
The slave node shall transmit a response field after it receives a supported request field (ReqId). Table 4 speci-
fies the condition of a slave node to enable message transmission.
Table 4 — Condition that transmission of message of slave nodes is possible
Condition Executable processing
When it receives any request field (ReqId) from the Transmission of response field that corresponds to
lower OSI layers, and there is no error. request field (ReqId).
When it wants to transmit request field (ReqId). Transmission of request field (ReqId).
9.3.3.3 APP — Polling method in normal state
This request specifies the polling method in normal state.
REQ 8.7 APP — NM — Polling method in normal state
The application shall transit to normal state, if power-on and wake-up/sleep and standby are not supported
and shall begin the message transmission.
REQ 8.8 APP — NM — Polling method in normal state — Master node starts message transmission
The master node shall transmit either any request identifier field (ReqId) or the request type identifier field
(ReqTypeId) at least once after transit to the normal state.
REQ 8.9 APP — NM — Polling method in normal state –Slave node starts message transmission
The slave node shall not begin message transmission as long as it has not received either
...