prEN IEC 63281-5-1:2026

• Status: Not Published
• Publication Date: 01-Feb-2028
• ICS: 43.120 - Electric road vehicles
• Technical Committee: CLC/SR 125 - Personal e-Transporters (PeTs)
• Current Stage: 4020 - Enquiry circulated - Enquiry
• Start Date: 28-Aug-2026
• Due Date: 30-Oct-2026
• Completion Date: 28-Aug-2026
• Ref Project: oSIST prEN IEC 63281-5-1:2026 - Interface requirements of autonomous cargo e-Transporters and cloud platform scheduling system

prEN IEC 63281-5-1:2026 is an IEC draft standard for the interface between autonomous cargo e-Transporters (ACeTs) and a cloud platform scheduling system. It specifies the communication protocol, message formats, and feedback objects used to release, update, verify, execute, and cancel routes, and to exchange operating status and exception information. It is aimed at engineers, integrators, operators, and buyers who need the vehicle and cloud software to exchange commands and status in a consistent way.

What does prEN IEC 63281-5-1:2026 specify?

prEN IEC 63281-5-1:2026 specifies the communication protocol for the interface between ACeTs defined by IEC 63281-2-2 and a cloud platform scheduling system. The document focuses on route-related driving instructions, their update and cancellation, route verification feedback, execution status feedback, and basic exception handling messages.

Part of the document	What it covers
Clause 1	Scope of the interface
Clause 2	Normative references
Clause 3	Terms and definitions
Clause 4	Basic specifications and overall architecture
Clause 5	Message format
Annex A (normative)	Message examples
Bibliography	Referenced background material

Clause 4 sets out the overall architecture and information flow. Clause 5 defines the message header and the Route, Action, RouteState, RouteVerificationState, and State objects that carry the interface data.

What are the key requirements of prEN IEC 63281-5-1:2026?

prEN IEC 63281-5-1:2026 defines a compact command-and-feedback model for route dispatch and vehicle status exchange. In practice, implementers need to align the cloud platform and the ACeT on the transport protocol, JSON structure, message header, route model, action model, and feedback cycle.

Transport, encoding, and data format

Clause 4.1 requires message transmission to use MQTT v3.1.1 and above versions or HTTP, with business messages encoded in JSON. JSON messages use UTF-8 encoding, and all data elements must follow the JSON data types defined in ISO/IEC 21778:2017.

For implementers, this means the interface is not just a business API but a specific wire format. Both sides have to agree on protocol, encoding, and data typing before route messages can be exchanged reliably.

Command and feedback flow

Clause 4.1.2 defines the sequence of interaction: the cloud platform sends a route instruction, the ACeT verifies it and returns RouteVerificationState, the ACeT executes the route and returns RouteState, and the cloud platform can send Action messages. The ACeT also sends State messages while operating.

This flow matters because the standard is bidirectional. The cloud does not only issue tasks - it also has to receive verification, execution, and live status feedback before it can safely update or cancel work.

Message header

Clause 5.1 requires every message to carry a header with a fixed direction marker, a version, a UTC timestamp, a headSeqId, manufacturer, model, and the ACeT id. The timestamp is used to judge whether a message has timed out or is invalid, and headSeqId increases for each new message.

In practice, this header gives every message traceability and basic freshness control. It lets the receiver identify who sent the message, which vehicle it relates to, and whether the message is still current.

Route object and route updates

Clause 5.3 defines the Route object. It uses a routeId to link multiple messages for the same task, a routeUpdateSeqId that increments for each update, an optional releasedNodeSequenceId that marks the farthest node the ACeT may reach, and an array of nodes.

Each node can carry a nodeId, sequenceId, position, direction, expected speed, expected time, and optional allowed deviations. The standard also explains that the route node granularity can be coarse for highly autonomous ACeTs or very fine for lower autonomy.

For readers, this means the cloud platform can describe a route at the level of detail the vehicle can use, and it can progressively release more nodes as the route advances.

Route acceptance and cancellation

Clause 5.3.1.4 allows route cancellation when the ACeT has reached the farthest node in the route, when the path is manually suspended, or when route execution has failed and driving has stopped. Clause 5.3.1.5 describes route refusal when the ACeT cannot execute the planned path because of positioning deviations, restricted work sites, prohibited areas, or similar factors.

This is important operationally because route planning is not assumed to be perfect. The ACeT has to validate what it receives, and the cloud platform has to handle refusal or cancellation when the route is not executable.

Action object

Clause 5.4 defines non-driving instructions in the Action object. The actionType values include FaultReset, RouteRetry, CancelRoute, PauseRoute, and ResumeRoute. PauseRoute uses a nodeSequenceId to tell the ACeT where it should slow down and stop if possible.

This gives the cloud platform a controlled way to recover from faults, retry driving, pause a route, or resume it later. It also limits when CancelRoute can be issued, which helps prevent conflicting commands.

State and fault reporting

Clause 5.5 defines RouteState, which reports the routeId, the last passed nodeSequenceId, and the execution state. Clause 5.6 defines RouteVerificationState, which reports whether route verification succeeded or failed. Clause 5.7 defines the State object, which carries the current position, heading, speed, mileage, battery energy, charging status, control mode, device state, wheel angles, and optional faults.

The fault structure includes a faultCode and a faultLevel. The fault level distinguishes fatal malfunction, general malfunction, and warning, which helps the cloud platform decide whether the ACeT should stop, continue, or go to maintenance.

What terms does prEN IEC 63281-5-1:2026 define?

• e-Transporter - An electrically powered transport device for public roads or public spaces that carries passengers, goods, or both.
• autonomous e-Transporter - An e-Transporter that can operate in autonomous or semi-autonomous driving mode within defined operational preconditions such as ODDa.
• cargo e-Transporter (CeT) - An e-Transporter designed primarily for transporting cargo or goods.
• autonomous cargo e-Transporter (ACeT) - An autonomous e-Transporter that carries parcels and goods to designated locations in public road and public-space environments.
• cloud platform scheduling system - Cloud software that manages ACeT scheduling and the full lifecycle of transport tasks, including status monitoring and task assignment.
• route - An instruction to move an ACeT along a path made up of nodes from a starting point to an endpoint.
• instruction - Data exchanged between ACeTs and the cloud platform scheduling system to guide and regulate ACeT operation.

Who uses prEN IEC 63281-5-1:2026?

prEN IEC 63281-5-1:2026 is used by ACeT manufacturers, cloud-platform software developers, vehicle integrators, and fleet operators working with autonomous goods transport. Test and validation teams use it to check message exchange, route acceptance, route updates, and fault reporting. Quality managers and buyers use it to compare vehicle and platform offers against a common interface model.

What changed in prEN IEC 63281-5-1:2026 from the previous edition?

prEN IEC 63281-5-1:2026 supersedes documents 125/129/CD and 125/132/CC in the IEC development process.

Which standards are used with prEN IEC 63281-5-1:2026?

• IEC 63281-1:2023 - Provides terminology and classification for e-Transporters.
• IEC 63281-2-2 - Provides safety requirements and test methods for autonomous cargo e-Transporters, and supplies core definitions used in this document.
• ISO/IEC 20922:2016 - Defines MQTT v3.1.1, the message transport protocol named in the interface.
• ISO/IEC 21778:2017 - Defines the JSON syntax and data types used for message encoding.
• IETF RFC 9112 - Defines HTTP/1.1, which the document allows as an application-layer transport.

What does the prEN IEC 63281-5-1:2026 document contain?

The document uses Figure 1 to show the information flow, Figures 2 and 3 to explain route nodes and route updates, and Tables 1 to 11 to define the message header and the Route, Action, RouteState, RouteVerificationState, State, and fault structures. Annex A gives message examples for a new route, an updated route, State, RouteState, and PauseRoute. These worked examples help developers implement and test the interface without guessing the message layout.

SLOVENSKI STANDARD
01-november-2026
Zahteve za vmesnike avtonomnih tovornih e-prevoznikov in oblačnega sistema za
razporejanje prometa
Interface requirements of autonomous cargo e-Transporters and cloud platform
scheduling system
Ta slovenski standard je istoveten z: prEN IEC 63281-5-1:2026
ICS:
43.120 Električna cestna vozila Electric road vehicles
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

125/134/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 63281-5-1 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2026-08-28 2026-11-20
SUPERSEDES DOCUMENTS:
125/129/CD, 125/132/CC
IEC TC 125 : E-TRANSPORTERS
SECRETARIAT: SECRETARY:
Belgium Mr Bram Rotthier
OF INTEREST TO THE FOLLOWING COMMITTEES: HORIZONTAL FUNCTION(S):

ASPECTS CONCERNED:
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which
they are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).

TITLE:
Interface requirements of autonomous cargo e-Transporters and cloud platform scheduling system

PROPOSED STABILITY DATE: 2030
NOTE FROM TC/SC OFFICERS:
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

Link to Committee Draft for Vote (CDV) online document:
Click here
How to access
This link leads you to the Online Standards Development (OSD) platform for National Mirror Committee’s
(NMC) comments. The project draft may be found further down this document.

Resource materials
We recommend NCs to review the available materials to better understand the member commenting on the
OSD platform. This includes the:
• OSD NC roles overview
• How to add and submit comments to the IEC

Contact
Should you require any assistance, please contact the IEC IT Helpdesk.

IEC CDV 63281-5-1 © IEC 2026
CONTENTS
Contact . 2
CONTENTS . 1
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Basic specifications . 8
4.1 Overall Architecture . 8
4.1.1 General . 8
4.1.2 Information Flow . 8
5 Message format . 9
5.1 Message Header . 9
5.2 Communication Object . 9
5.3 Route Object . 10
5.3.1 Explanation of Route Mechanism . 10
5.3.2 Format of Route Object . 11
5.4 Action Object . 12
5.4.1 Description . 12
5.4.2 Format of Action Object . 13
5.5 RouteState Object . 13
5.5.1 Description . 13
5.5.2 Format of RouteState Object . 13
5.6 RouteVerificationState Object . 14
5.6.1 Description . 14
5.6.2 Format of RouteVerificationState Object . 14
5.7 State Object . 14
5.7.1 Description . 14
5.7.2 Format of State Object. 14
Annex A (normative) Message example . 16
A.1 Example of new Route . 16
A.2 Example of updating Route . 16
A.3 Example of State . 17
A.4 Example of RouteState . 18
A.5 Example of Action PauseRoute . 18
Bibliography . 19

Figure 1 – Information Flow . 9
Figure 2 – Nodes in a route . 10
Figure 3 – Route update diagram . 11

Table 1 – Message head . 9
Table 2 – Communication Object . 9
Table 3 – Structure of Route . 11
Table 4 – Structure of node . 12
IEC CDV 63281-5-1 © IEC 2026
Table 5 – Structure of Action Object . 13
Table 6 – Optional values of actionType . 13
Table 7 – Structure of nodeSequenceId . 13
Table 8 – Structure of RouteState Object . 13
Table 9 – Structure of RouteCheckState Object . 14
Table 10 – Structure of State Object . 14
Table 11 – Structure of fault. 15

IEC CDV 63281-5-1 © IEC 2026
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Interface requirements of autonomous cargo e-Transporters and cloud
platform scheduling system
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for
standardization comprising all national electrotechnical committees (IEC National Committees).
The object of IEC is to promote international co-operation on all questions concerning
standardization in the electrical and electronic fields. To this end and in addition to other
activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC
Publication(s)"). Their preparation is entrusted to technical committees; any IEC National
Committee interested in the subject dealt with may participate in this preparatory work.
International, governmental and non-governmental organizations liaising with the IEC also
participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two
organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as
possible, an international consensus of opinion on the relevant subjects since each technical
committee has representation from all interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted
by IEC National Committees in that sense. While all reasonable efforts are made to ensure that
the technical content of IEC Publications is accurate, IEC cannot be held responsible for the
way in which they are used or for any misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC
Publications transparently to the maximum extent possible in their national and regional
publications. Any divergence between any IEC Publication and the corres ponding national or
regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies
provide conformity assessment services and, in some areas, access to IEC marks of conformity.
IEC is not responsible for any services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including
individual experts and members of its technical committees and IEC National Committees for
any personal injury, property damage or other damage of any nature whatsoever, whether direct
or indirect, or for costs (including legal fees) and expenses arising out of the publication, use
of, or reliance upon, this IEC Publication or any other IEC Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced
publications is indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve
the use of (a) patent(s). IEC takes no position concerning the evidence, validity or applicability
of any claimed patent rights in respect thereof. As of the date of publication of this document,
IEC had received notice of (a) patent(s), which may be required to implement this document.
However, implementers are cautioned that this may not represent the latest information, which
IEC CDV 63281-5-1 © IEC 2026
may be obtained from the patent database available at https://patents.iec.ch or 9) IEC draws
attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, IEC had received
notice of (a) patent(s), which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be
obtained from the patent database available at https://patents.iec.ch or www.iso.org/patents.
IEC shall not be held responsible for identifying any or all such patent rights. . IEC shall not be
held responsible for identifying any or all such patent rights.
IEC 6XXXX has been prepared by IEC technical committee 125: e-Transporters. It is an
International Standard.
The text of this International Standard is based on the following documents:
Draft Report on voting
XX/XX/FDIS XX/XX/RVD
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
IEC CDV 63281-5-1 © IEC 2026
INTRODUCTION
Standardization of "autonomous cargo e-Transporters": autonomous cargo electrically powered
transport devices for use on public roads or in public spaces. These e-Transporters provide
solutions for transporting goods.
These devices should be autonomous.
This document has been developed in response to an increased demand throughout the world
for Autonomous Cargo e-Transporters. The world market sizes and applications are expected
to grow significantly. To date, autonomous cargo e-Transporters have not had a complete and
unified standard of interface with cloud platform scheduling system. This has created
challenges for engineers, producers, operators, and other actors in the field of autonomous
cargo e-Transporters. The development of an interface standard applicable to autonomous
cargo e-Transporters, will promote the standardization of autonomous cargo e-Transporters,
aid the progress of technology, improve product quality, and increase safety.
IEC CDV 63281-5-1 © IEC 2026
1 Scope
This document specifies the communication protocol for the interface between autonomous
cargo e-Transporters as defined by IEC 63281-2-2 and cloud platform scheduling system,
including technical requirements such as message format, message transmission met hod.
This document mainly describes the communication protocol of the autonomous cargo e -
Transporters in terms of driving, including the creation, update, and cancellation of path
instructions issued by the cloud platform scheduling system, as well as the statu s feedback of
the autonomous cargo e-Transporters when executing path instructions and basic exception
handling messages.
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.
IEC 63281-1:2023, E-Transporters - Part 1: Terminology and classification
ISO/IEC 20922:2016, Information technology — Message Queuing Telemetry Transport
(MQTT) v3.1.1
ISO/IEC 21778:2017, Information technology — The JSON data interchange syntax
IEC 63281-2-2: E-Transporters – Part 2-2: Safety requirements and test methods for
autonomous cargo e-Transporters
IETF RFC 9112, HTTP/1.1
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 63281-1:2023 and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://www.iso.org/obp
3.1
e-Transporter
electrically powered transport device for use on public roads or in public spaces which provides
solutions for transporting either passengers or goods, or both
[SOURCE: SOURCE: IEC 63281-1:2023, 3.2]
3.2
autonomous e-Transporter
e-Transporter that can operate in autonomous driving mode or semi-autonomous driving mode,
and it drives within defined operational preconditions such as ODDa (IEC 63281-2-2, 3.6)

[SOURCE: SOURCE: IEC 63281-2-2 , 3.2]
IEC CDV 63281-5-1 © IEC 2026
3.3
cargo e-Transporter (CeT)
e-Transporter that is primarily designed for transporting cargo or goods, or both
[SOURCE: IEC 63281-1:2023, 3.4]
3.4
autonomous cargo e-Transporter(ACeT)
autonomous e-transporters traveling without human intervention in carrying loads of parcels
and goods to designated locations including public road environments and public spaces (e.g.,
walkway, pedestrian road, big building's corridors) coexisting with unspecified humans with a
maximum speed not exceeding specified limit

Note 1 to entry: Even if in case of over the operational preconditions, an authorized users can operate remotely for
the ACeTs manually via an external systems or supplementary telecommunication control devices.
[SOURCE: IEC 63281-2-2, 3.4]
3.5
cloud platform scheduling system
cloud platform
Cloud
software system deployed in public/private networks, providing full-lifecycle management and
scheduling for ACeT—including real-time operating status monitoring, intelligent task
assignment, and overall transportation efficiency optimization
3.6
instruction
data collection for communication between ACeTs and cloud platform scheduling system, used
to guide and regulate the operation of ACeTs
3.7
route
instruction to move the ACeT along the path, consisting of a series of nodes forming a straight
line or curve, describing complete information from the starting point to the endpoint
3.8
HTTP/1.1
HyperText Transfer Protocol version 1.1
Note 1 to entry: HTTP/1.1 is a stateless application-level request/response protocol for distributed, collaborative
hypermedia information systems.
Note 2 to entry: In this document, “HTTP” means HTTP/1.1 unless otherwise specified.
[SOURCE: IETF RFC 9112]
3.9
MQTT v3.1.1
Message Queuing Telemetry Transport version 3.1.1
Note 1 to entry: MQTT v3.1.1 is a lightweight client-server publish/subscribe messaging transport protocol for
machine-to-machine (M2M) and Internet of Things (IoT) applications.
[SOURCE: ISO/IEC 20922:2016]
3.10
JSON
JavaScript Object Notation
IEC CDV 63281-5-1 © IEC 2026
Note 1 to entry: JSON is a lightweight, text-based, language-independent data interchange syntax.
Note 2 to entry: This syntax is consistent with IETF RFC 8259
...