ISO/TS 25614-1

• Abstract:

  Define the data and operating functions required to orchestrate the use of spaces (spots, bays) for road vehicles to stop (stand) for the purpose of loading or unloading goods and passengers. The data and functions defined support space definition and vehicle requirements (demand), space-to-vehicle matching, scheduling, reservation, delays, rescheduling, cancellation, and queueing-in-motion. This is inclusive of all levels of vehicle automation—i.e., both uncrewed and crewed vehicles. It will be inclusive of any space that may be in demand for shared loading and unloading, curb-sides, parking lots, and both indoor and outdoor facilities, and of all spaces that admit shared use by more than one vehicle as described.

• Status: Not Published
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 19 - Mobility integration
• Current Stage: 6000 - International Standard under publication
• Start Date: 16-Sep-2026
• Completion Date: 19-Sep-2026

Overview

ISO/TS 25614-1: Intelligent Transport Systems - Orchestration of Vehicles for Fixed Locations – Part 1: Reservation Service is an international specification developed by the International Organization for Standardization (ISO). This technical specification addresses the growing challenges of managing urban pickup and drop-off (PUDO) spaces-such as curb-sides, parking areas, and loading zones-used by various types of road vehicles for the loading and unloading of passengers and goods. The standard defines the required data structures and operating functions for dynamically orchestrating the use of these spaces, supporting both crewed and uncrewed (automated) vehicles of all automation levels.

By characterizing how vehicles and space operators interact to request, reserve, schedule, and cancel the use of PUDO locations, ISO/TS 25614-1 establishes a foundation for reliable and interoperable intelligent transport systems across different vehicle fleets, operators, and jurisdictions.

Key Topics

• PUDO Space Definition: Describes the requirements for uniquely identifying and dimensioning spaces used for loading and unloading, including location coordinates, physical dimensions, and permitted vehicle or cargo types.
• Reservation and Scheduling: Details the functions for requesting, matching, reserving, delaying, rescheduling, and canceling allocations of PUDO spaces. Outlines the sequence of message types and transaction protocols necessary for robust scheduling.
• Data Structures: Specifies essential application-layer data elements and messages used in the reservation workflow, such as vehicle attributes, space properties, temporal data, and status codes. Ensures compatibility with ISO 8601-2 for time representation.
• Space-to-Vehicle Matching: Outlines how demands from different vehicles are matched to available spaces using descriptors and operational constraints like size, weight, noise, and fuel type.
• Shared and Multi-Use Spaces: Enables operators to manage spaces shared by multiple vehicle types and operators, increasing the efficiency of valuable urban real estate.
• Operational Resilience: Stipulates requirements for minimal risk handling in the event of communication or system failures and defines service level agreements (SLAs) between orchestration systems and vehicle operators.
• Inclusivity and Accessibility: Accounts for accessibility, priority rules, and fair access policies, supporting public transport, emergency services, logistics, and more.

Applications

The practical applications of ISO/TS 25614-1 extend across several domains of intelligent transportation and urban mobility:

• Urban Freight and Passenger Management: Optimizes loading and unloading at busy city curbs and parking lots by enabling just-in-time reservations, reducing congestion and improving traffic safety.
• Smart Parking Solutions: Supports both indoor and outdoor parking facilities in dynamically assigning spaces to eligible vehicles, including automated and connected vehicles.
• Automated Fleet Operations: Facilitates orchestration for future mobility, supporting autonomous taxis, shuttles, delivery robots, and driverless goods vehicles that require precise and reliable access to shared spaces.
• Transportation Network Companies: Strengthens ride-hailing, shuttle, and car-share operations through reliable space scheduling and orchestration, improving service predictability.
• Public and Emergency Services: Assists municipal service vehicles, buses, and emergency responders with priority-based access and efficient routing to critical PUDO locations.
• Multistakeholder Interoperability: Harmonizes communications between public and private operators, across mixed vehicle fleets, using standardized transaction and data formats.

Related Standards

For greater interoperability and context, implementation of ISO/TS 25614-1 may reference or align with these related standards:

• ISO 8601-2 – Date and time representations for information interchange, ensuring consistent time-stamping.
• ISO/TS 5206-1:2023 – Parking facility definitions and hierarchies.
• SAE J3016 – Taxonomy and definitions for driving automation systems.
• ISO/TC 204 Family – A range of intelligent transport systems standards addressing communications, management, and urban mobility.

Organizations seeking to improve the efficiency, safety, and accessibility of urban curb management and shared mobility infrastructure will benefit from aligning their solutions with ISO/TS 25614-1, supporting seamless integration in tomorrow’s smart cities and intelligent transport systems.

FINAL DRAFT
Technical
Specification
ISO/DTS 25614-1
ISO/TC 204
Intelligent transport systems —
Secretariat: ANSI
Orchestration of vehicles for fixed
Voting begins on:
locations —
2026-07-21
Part 1:
Voting terminates on:
2026-09-15
Reservation service
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/DTS 25614-1:2026(en) © ISO 2026

FINAL DRAFT
ISO/DTS 25614-1:2026(en)
Technical
Specification
ISO/DTS 25614-1
ISO/TC 204
Intelligent transport systems —
Secretariat: ANSI
Orchestration of vehicles for fixed
Voting begins on:
locations —
Part 1:
Voting terminates on:
Reservation service
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/DTS 25614-1:2026(en) © ISO 2026

ii
ISO/DTS 25614-1:2026(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Orchestration of pickup and drop-off (PUDO) for passengers and goods . 2
4.1 System considerations .2
4.1.1 Orchestration system to set location and schedule for PUDO events .2
4.1.2 PUDO orchestration service capability .3
4.1.3 PUDO orchestration service failure .3
4.1.4 PUDO orchestration service level agreement .3
4.2 PUDO Descriptors .3
4.2.1 PUDO match descriptor message types .3
4.2.2 PUDO match descriptor message elements .3
4.2.3 PUDO match descriptor message details .5
4.2.4 PUDO match descriptor: The request descriptor .9
4.2.5 PUDO match descriptor: The offer descriptor .10
4.2.6 PUDO match descriptor: The alternate descriptor . 12
4.3 PUDO space description .14
4.3.1 A PUDO space location is unique .14
4.3.2 A PUDO space description shall be fully dimensioned .14
4.3.3 PUDO space orientation .14
4.3.4 A PUDO space description is a 3D bounding cuboid . 15
4.3.5 Accuracy of PUDO space and vehicle dimensions . 15
4.3.6 PUDO space dimensions shall not be overestimated . 15
4.3.7 PUDO vehicle dimensions shall not be underestimated. 15
4.3.8 PUDO space schedule . 15
4.4 PUDO auxiliary matching functions .16
4.4.1 PUDO matching for location optimization.16
4.4.2 Request a PUDO space .17
4.4.3 Accept an offer of a PUDO space .17
4.4.4 Request a time change for a PUDO contract .17
4.4.5 Reject an offer of a PUDO space .17
4.4.6 Abandon a contract for a PUDO space .17
4.4.7 Complete a contract for a PUDO space .18
4.4.8 Declare a PUDO space to be Unusable .18
4.4.9 Offer a contract for a PUDO space .18
4.4.10 Refuse to grant an offer for a PUDO space .19
4.4.11 Revise an offer for a PUDO space .19
4.4.12 Cancel a contract for a PUDO space .19
4.4.13 Close a contract for a PUDO space . 20
4.4.14 Timeout a PUDO transaction . 20
4.4.15 Issue an alternate descriptor . 20
4.4.16 Order of servicing requests . 20
4.5 Transaction Diagrams .21
4.5.1 Common transaction rules .21
4.5.2 State diagram of match descriptor workflows .21
4.5.3 Request-Offer-Accept-Complete-Close sequence . 22
4.5.4 Request-Abandon sequence . 23
4.5.5 Offer-Unusable sequence . .24
4.5.6 Offer-Revise sequence . 25
4.5.7 Request-Change (time) sequence . 26
4.5.8 Request-Offer-Reject sequence .27
4.5.9 Request-Alternate sequence .27

iii
ISO/DTS 25614-1:2026(en)
4.5.10 Request-Refuse sequence . 28
4.5.11 Request-Cancel sequence . 29
Annex A (normative) ASN.1 Module Definiton .30
Bibliography .32

iv
ISO/DTS 25614-1:2026(en)
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO 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, ISO had not 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
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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 204, Intelligent transport systems.
A list of all parts in the ISO 25614 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.

v
ISO/DTS 25614-1:2026(en)
Introduction
This document specifies system requirements for regional, multi-agent, pickup and drop-off (PUDO)
orchestration that coordinates multiple, independent vehicle fleets accessing shared curb spaces and
loading zones. PUDO orchestration manages temporal and spatial access to curb space and loading areas for
passenger and goods movement across public and private operators.
The increasing automation of vehicle fleets, growth in e-commerce deliveries, and the expansion of mobility
services such as automated ride-hail services have intensified competition for limited PUDO spaces. Without
coordinated orchestration, this competition can lead to congestion, safety hazards, and inefficient use of
urban infrastructure.
This document enables interoperability among multiple independent operators' systems while supporting
prioritization rules, fair access policies, and local regulations. It enables system reliability, respects data
privacy, and acknowledges cybersecurity as essential for managing critical urban mobility infrastructure.
While this document specifies data and function requirements, it does not describe or prescribe specific
algorithms for space allocation or mandate particular operational policies, which are expected to remain
under local authority control.

vi
FINAL DRAFT Technical Specification ISO/DTS 25614-1:2026(en)
Intelligent transport systems — Orchestration of vehicles for
fixed locations —
Part 1:
Reservation service
1 Scope
This document defines the application layer data structures and functional requirements for systems that
dynamically allocate pickup and drop-off (PUDO) access among:
— Automated passenger vehicles (private and commercial)
— Emergency vehicles
— Logistics and delivery fleets
— Municipal service vehicles
— Private commercial fleets (passenger and goods)
— Public transportation vehicles
— Transportation network company fleets
This document defines the data and data flow functions required to orchestrate the use of spaces (spots,
bays) for road vehicles to stop (stand) for the purpose of loading or unloading goods and passengers. The
data and functions defined support space definition (supply) and vehicle requirements (demand), space-to-
vehicle matching, scheduling, reservation, delays, rescheduling, cancellation, and queueing-in-motion.
This is inclusive of all levels of vehicle automation, i.e. both uncrewed and crewed vehicles.
This is inclusive of any space that can be in demand for shared loading and unloading, curb-sides, parking
lots, and both indoor and outdoor facilities. It is inclusive of all spaces that admit shared use by more than
one vehicle as described.
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 8601-2, Date and time — Representations for information interchange — Part 2: Extensions
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— IEC Electropedia: available at http:// www .electropedia .org/
— ISO Online browsing platform: available at http:// www .iso .org/ obp

ISO/DTS 25614-1:2026(en)
3.1
minimal risk condition
stable, stopped condition to which a user or an automated driving system (ADS) can bring a vehicle after
performing the dynamic driving task (DDT) fallback in order to reduce the risk of a crash when a given trip
cannot or should not be continued
[1]
[SOURCE: S A E J3016: 2021 , modified — Adjusted to fit ISO drafting guidelines.]
3.2
PUDO, noun
pickup and drop-off
load (pick up) or unload (drop off) passengers or goods
Note 1 to entry: "Pick up" and "drop off" are verbs.
Note 2 to entry: "Pickup," "drop-off," and "PUDO" are adjectives. Examples are "a pickup/drop-off spot," "a PUDO
schedule," or "a PUDO permission".
3.3
orchestration
act of coordinating multiple entities in an activity
Note 1 to entry: In this document, orchestration relates to vehicular pickup and drop-off activities while using shared,
publicly accessible spaces.
3.4
orchestrator
entity that receives, manages and distributes orchestration (3.3) requests and instructions for multiple
independent vehicle (3.6) or fleet operators
Note 1 to entry: This entity may be a governing authority.
Note 2 to entry: It is possible for the owner of a private household vehicle to require PUDO (3.2) access and, hence, be a
vehicle operator for purposes of this document.
3.5
space
identified area for a vehicle to stop to load/unload
[2]
Note 1 to entry: The end element of a parking place hierarchy in the ISO/TS 5206-1:2023 definition for parking
facilities.
3.6
vehicle
machine or conveyance to transport persons or goods, as identified by a number of specific attributes
defined to orchestrate its loading/unloading
[3]
Note 1 to entry: ISO 26262-1:2018 describes a number of types and properties of "vehicle," but does not define the
term "vehicle".
4 Orchestration of pickup and drop-off (PUDO) for passengers and goods
4.1 System considerations
4.1.1 Orchestration system to set location and schedule for PUDO events
For locations where multiple vehicles can require co-temporal access for loading or unloading operations, a
vehicle management system shall orchestrate:
a) vehicle stop position (space);

ISO/DTS 25614-1:2026(en)
b) vehicle arrival time (schedule);
c) vehicle dwell time (duration of stay) at space.
NOTE Orchestration helps prevent spatial contention among vehicles wishing to occupy the same stopping/
loading space within the same time frame.
4.1.2 PUDO orchestration service capability
A PUDO orchestration system shall be designed and deployed without limitation with respect to:
a) The expected peak number of vehicles under management.
b) The expected peak number of spaces under management.
c) The extent of the geographic area under management.
d) Its ability to handle peak request volumes within a stated time or space window.
NOTE PUDO orchestration is a traffic management system embedded within a wider traffic management system,
inclusive of many other road users, vehicles, and spaces that are not part of the orchestration activity. There can
be traffic events beyond the PUDO system's control. Some such events can not be anticipated, but the orchestration
system must be resilient. Specifically, the system can experience long lags, or a large number of PUDO spaces can be
taken out of service, yet the orchestrator cannot fail to operate.
The system should be able to handle the volume of requests at peak demand for the full complement
of vehicles and spaces under management in the full geography of its jurisdiction. For example, if all the
vehicles under management were to request a PUDO reservation within the same minute, the system can lag
but would not fail, regardless of the length of the service queue or any reservation delays incurred.
4.1.3 PUDO orchestration service failure
In the event of communication failure involving the orchestration service, any participating vehicle that
cannot access its assigned PUDO place shall assume a minimal risk condition.
4.1.4 PUDO orchestration service level agreement
A PUDO orchestration system shall incorporate service level agreements between the system orchestrator
entity and each vehicle operator to be served by the system.
4.2 PUDO Descriptors
4.2.1 PUDO match descriptor message types
A PUDO match descriptor is a message holding several identified data elements needed to match a vehicle
with a space. It is provided in, and used as, one of three message types:
a) A request for a space for a specified PUDO event; a request is sent from a vehicle operator to a regional
PUDO orchestrator, i.e., an orchestration agent or system.
b) An offer of a PUDO reservation (contract); an offer is sent from a PUDO orchestrator to the vehicle
operator that is managing the requesting vehicle.
c) An alternate is a description of a near-match between a requesting vehicle and the closest-match space;
this is sent from a PUDO orchestrator to a vehicle operator.
4.2.2 PUDO match descriptor message elements
Data elements match descriptor messages shall use data identifiers listed below:
— messageType
ISO/DTS 25614-1:2026(en)
— reasonField
— timeStampInit
— timeStampNow
— transactionID
— operatorID
— vehicleID
— vehiclePurpose
— length
— width
— height
— weight
— noiseLevel
— fuelType
— hazardLevel
— timeZone
— startDateTime
— endDateTime
— dwellTime
— radius
— roadCrossCount
— timeSpacePreference
— feePerMinute
— spaceCx
— spaceCy
— spaceCz
— spaceFLx
— spaceFLy
— spaceFLz
— spaceFRx
— spaceFRy
— spaceFRz
— spaceBRx
— spaceBRy
ISO/DTS 25614-1:2026(en)
— spaceBRz
— spaceBLx
— spaceBLy
— spaceBLz
Those data elements and their formats are defined in clauses 4.2.3, 4.2.4, 4.2.5, and 4.2.6.
4.2.3 PUDO match descriptor message details
The feature meaning for each element of the three match descriptors shall be consistent (Table 1), but the
calculation and interpretation of some descriptor elements may differ (Table 2, Table 3, and Table 4).
Table 1 — The elements of a match descriptor
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
messageType a) "request" One of n) "alternate"
b) "accept"
c) "change"
d) "reject"
e) "abandon"
f) "complete"
g) "unusable"
h) "offer"
i) "refuse"
j) "revise"
k) "cancel"
l) "close"
m) "timeout"
reasonField nil See Table 3 and 4.4.8 nil
timeStampInit time stamp of initial request confirmed and sustained confirmed and sustained
timeStampNow =timeStampInit time stamp of this message time stamp of this message
The minimum space height is the lowest height the vehicle must traverse before stopping in the assigned PUDO space. If a
PUDO area has an entrance gate with a maximum vehicle height that is less than the PUDO space offered, then the height of that
entrance gate shall be used.
NOTE 1 vehiclePurpose is declared by the vehicle operator. Whether the orchestrator uses this to manage priorities is
outside the scope of this document.
NOTE 2 dwellTime is the time that the PUDO vehicle operator requests to complete loading or unloading. It is not the same
as {endDateTime minus startDateTime}, but it must be less than or equal to that.
NOTE 3 radius is the preferred maximum distance between the requested and proposed PUDO locations.
NOTE 4 timeSpacePreference is used to weight an offer that cannot be met as requested with an offer closest to the time
or location requested.
NOTE 5 roadCrossCount is the preferred maximum number of streets to be crossed between the requested and proposed
PUDO locations. Some passengers can be blind or wheelchair users, and some deliveries can include large or heavy objects or
medical or food deliveries that are temperature controlled.

ISO/DTS 25614-1:2026(en)
TTabablele 1 1 ((ccoonnttiinnueuedd))
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
transactionID nil if 1st request; provided by orchestrator only provided by orchestrator only
(unique) on initial offer; on initial offer;
same as provided by orches-
trator if re-request follows an sustained until transaction sustained until transaction
alternate or rejection is closed, completed, or aban- is closed, completed, or aban-
doned doned
operatorID (unique) assigned by the orchestrator confirmed and sustained confirmed and sustained
at the time of initial operator
registration;
the operatorID initialization
process is out of scope
vehicleID (unique) declared by vehicle operator confirmed and sustained confirmed and sustained
vehiclePurpose — dignitary confirmed and sustained confirmed and sustained
— ems
— fire
— goods
— passenger, private
— passenger, taxi
— passenger, transit
— police
— service
length vehicle length, integer, mm space length, mm space length minus- vehicle
(maximum) length, mm
width vehicle width, integer, mm space width, mm space width minus- vehicle
width, mm
height vehicle height, integer, mm space height, mm (minimum) space height minus vehicle
(maximum) (note 1) height, mm
weight vehicle gross weight, integer, space max weight permitted, space weight minus vehicle
kg kg weight, kg
noiseLevel vehicle noise max level ex- space noise max level permit- space noise minus vehicle
pected, dB ted, dB noise, dB
The minimum space height is the lowest height the vehicle must traverse before stopping in the assigned PUDO space. If a
PUDO area has an entrance gate with a maximum vehicle height that is less than the PUDO space offered, then the height of that
entrance gate shall be used.
NOTE 1 vehiclePurpose is declared by the vehicle operator. Whether the orchestrator uses this to manage priorities is
outside the scope of this document.
NOTE 2 dwellTime is the time that the PUDO vehicle operator requests to complete loading or unloading. It is not the same
as {endDateTime minus startDateTime}, but it must be less than or equal to that.
NOTE 3 radius is the preferred maximum distance between the requested and proposed PUDO locations.
NOTE 4 timeSpacePreference is used to weight an offer that cannot be met as requested with an offer closest to the time
or location requested.
NOTE 5 roadCrossCount is the preferred maximum number of streets to be crossed between the requested and proposed
PUDO locations. Some passengers can be blind or wheelchair users, and some deliveries can include large or heavy objects or
medical or food deliveries that are temperature controlled.

ISO/DTS 25614-1:2026(en)
TTabablele 1 1 ((ccoonnttiinnueuedd))
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
fuelType vehicle fuel type (declared) space fuel permissions; one of: Fuel mismatch (binary)
— [0] Unknown
— [1] Diesel
— [2] Electric
— [3] Gasoline (petrol)
— [4] Hydrogen
— [5] LPG
— [6] Methanol
— [7] Natural gas
— [8] Propane
— [9] Other
hazardLevel hazardous cargo descriptor hazardous cargo permission hazardous mismatch (binary)
(declared) (table)
UN codes, 9 categories
[4]
ISO HCC codes are for
storage
timeZone time zone for the request time zone for the offer sustained
startDateTime start date and time for the start date and time for the start date and time alternate
request offer in the offer
endDateTime end date and time for the end date and time for the offer end date and time alternate in
request the offer
dwellTime amount of time requested amount of time offered amount of time offered
radius maximum euclidean distance euclidean distance offered (shortest) euclidean distance
requested from {cX,cY} from {cX,cY} offered from {cX,cY}
roadCrossCount maximum road-crossing count road-crossing count between (minimum) road-cross-
between requested {cX,cY,0} offered {cX,cY,0} and request- ing count between offered
and offered {cX,cY,0} ed {cX,cY,0} {cX,cY,0} and requested
{cX,cY,0}
timeSpacePreference "time" if requesting closest in "time" if offer is closest in "time" if offer is closest in
time; time; time;
"space" if requesting closest in "space" if offer is closest in "space" if offer is closest in
distance distance distance
The minimum space height is the lowest height the vehicle must traverse before stopping in the assigned PUDO space. If a
PUDO area has an entrance gate with a maximum vehicle height that is less than the PUDO space offered, then the height of that
entrance gate shall be used.
NOTE 1 vehiclePurpose is declared by the vehicle operator. Whether the orchestrator uses this to manage priorities is
outside the scope of this document.
NOTE 2 dwellTime is the time that the PUDO vehicle operator requests to complete loading or unloading. It is not the same
as {endDateTime minus startDateTime}, but it must be less than or equal to that.
NOTE 3 radius is the preferred maximum distance between the requested and proposed PUDO locations.
NOTE 4 timeSpacePreference is used to weight an offer that cannot be met as requested with an offer closest to the time
or location requested.
NOTE 5 roadCrossCount is the preferred maximum number of streets to be crossed between the requested and proposed
PUDO locations. Some passengers can be blind or wheelchair users, and some deliveries can include large or heavy objects or
medical or food deliveries that are temperature controlled.

ISO/DTS 25614-1:2026(en)
TTabablele 1 1 ((ccoonnttiinnueuedd))
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
feePerMinute zero (0.0) or maximum accept- zero (0.0) or fee in local cur- zero (0.0) or fee in local cur-
able fee in local currency rency rency
cX requested PUDO location, x longitude of the centre of the difference in x
space being offered
cY requested PUDO location, y latitude of the centre of the difference in y
space being offered
cZ requested PUDO location, z altitude of the centre of the difference in z
space being offered
flX nil longitude of the front left nil
extreme of the space being
offered
flY nil latitude of the front left nil
extreme of the space being
offered
flZ nil altitude of the front left nil
extreme of the space being
offered
frX nil longitude of the front right nil
extreme of the space being
offered
frY nil latitude of the front right nil
extreme of the space being
offered
frZ nil altitude of the front right nil
extreme of the space being
offered
brX nil longitude of the back right nil
extreme of the space being
offered
brY nil latitude of the back right nil
extreme of the space being
offered
brZ nil altitude of the back right nil
extreme of the space being
offered
blX nil longitude of the back left nil
extreme of the space being
offered
The minimum space height is the lowest height the vehicle must traverse before stopping in the assigned PUDO space. If a
PUDO area has an entrance gate with a maximum vehicle height that is less than the PUDO space offered, then the height of that
entrance gate shall be used.
NOTE 1 vehiclePurpose is declared by the vehicle operator. Whether the orchestrator uses this to manage priorities is
outside the scope of this document.
NOTE 2 dwellTime is the time that the PUDO vehicle operator requests to complete loading or unloading. It is not the same
as {endDateTime minus startDateTime}, but it must be less than or equal to that.
NOTE 3 radius is the preferred maximum distance between the requested and proposed PUDO locations.
NOTE 4 timeSpacePreference is used to weight an offer that cannot be met as requested with an offer closest to the time
or location requested.
NOTE 5 roadCrossCount is the preferred maximum number of streets to be crossed between the requested and proposed
PUDO locations. Some passengers can be blind or wheelchair users, and some deliveries can include large or heavy objects or
medical or food deliveries that are temperature controlled.

ISO/DTS 25614-1:2026(en)
TTabablele 1 1 ((ccoonnttiinnueuedd))
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
blY nil latitude of the back left nil
extreme of the space being
offered
blZ nil altitude of the back left nil
extreme of the space being
offered
The minimum space height is the lowest height the vehicle must traverse before stopping in the assigned PUDO space. If a
PUDO area has an entrance gate with a maximum vehicle height that is less than the PUDO space offered, then the height of that
entrance gate shall be used.
NOTE 1 vehiclePurpose is declared by the vehicle operator. Whether the orchestrator uses this to manage priorities is
outside the scope of this document.
NOTE 2 dwellTime is the time that the PUDO vehicle operator requests to complete loading or unloading. It is not the same
as {endDateTime minus startDateTime}, but it must be less than or equal to that.
NOTE 3 radius is the preferred maximum distance between the requested and proposed PUDO locations.
NOTE 4 timeSpacePreference is used to weight an offer that cannot be met as requested with an offer closest to the time
or location requested.
NOTE 5 roadCrossCount is the preferred maximum number of streets to be crossed between the requested and proposed
PUDO locations. Some passengers can be blind or wheelchair users, and some deliveries can include large or heavy objects or
medical or food deliveries that are temperature controlled.
4.2.4 PUDO match descriptor: The request descriptor
The PUDO request descriptor describes the vehicle and demand for a PUDO space. It shall be constructed as
in Table 2.
Table 2 — Construction of a PUDO request descriptor
Element Type Unit Description
messageType char See Table 1 "request"
reasonField char See Table 1 nil
timeStampInit ISO 8601-2 See Table 1 since there is only one initial request descriptor, timeS-
tampInit is sustained throughout the transaction
timeStampNow ISO 8601-2 See Table 1 this is the same value as timeStampInit when a request is
initialized
transactionID char See Table 1 unique ID assigned by the orchestrator
(unique)
persists throughout all exchanges on this transaction until
the transaction is closed
operatorID (unique) char See Table 1 unique ID assigned at the time a vehicle operator first
enrols in the orchestration system
persists for this operator within this orchestration system
NOTE 2 With regard to noiseLevel, it is possible for a vehicle to be able to emit noise at a higher dB level than it requests
(reports), in order to load or unload at spaces that do not permit high dB levels. Hence, a vehicle that reports a low DB level to gain
access to such a space is expected to constrain its noise output to that level.
NOTE 3 All transactions that straddle a time change or a time zone calculate dwellTime and (possibly adjusted)
endDateTime from the startDateTime and start timeZone.

ISO/DTS 25614-1:2026(en)
TTabablele 2 2 ((ccoonnttiinnueuedd))
Element Type Unit Description
vehicleID (unique) char See Table 1 unique ID for a PUDO vehicle provided by the vehicle oper-
ator at the time of the initial request
persists throughout all message exchanges within this
PUDO transaction until the transaction is closed
If a vehicle is exchanged with another vehicle before the
PUDO transaction is completed, a new transaction shall be
started
NOTE 1 This can be a vehicle identification number (VIN)
or a vehicle registration plate number if the plate jusisdiction is
included.
vehiclePurpose char See Table 1 see Table 1
length int mm vehicle extended length in including all space needed for
loading or unloading including open doors, entrance/exit
ramps, ingress/egress of passengers or goods
width int mm vehicle extended width in including all space needed for
loading or unloading including open doors, entrance/exit
ramps, ingress/egress of passengers or goods
height int mm vehicle height in including roof carriage and all space
needed to pass under any entrance gate; to load/unload
under low ceiling, an awning, or other infrastructural
element
weight int kg vehicle gross weight prior to unloading, or after loading,
whichever is heaviest
noiseLevel int dB expected peak level of the engine, motor, loading/unload-
ing activity, horns, sirens, or speakers
fuelType char See Table 1 see Table 1
hazardLevel char See Table 1 see Table 1
timeZone IA5String See Table 1 time zone in which the desired PUDO space is located
use IANA time zone identifier
startDateTime ISO 8601-2 See Table 1 requested start date and time for a PUDO space to be used
endDateTime ISO 8601-2 See Table 1 end date and time for which a PUDO space is requested
dwellTime int sec amount of time required for intended purpose
radius int m see Table 1
RoadCrossCount int>0 See Table 1 see Table 1
timeSpacePreference char See Table 1 see Table 1
feePerMinute real See Table 1 see Table 1
pX real Decimal degrees requested PUDO target longitude
pY real Decimal degrees requested PUDO target latitude
pZ real m requested PUDO target altitude
NOTE 2 With regard to noiseLevel, it is possible for a vehicle to be able to emit noise at a higher dB level than it requests
(reports), in order to load or unload at spaces that do not permit high dB levels. Hence, a vehicle that reports a low DB level to gain
access to such a space is expected to constrain its noise output to that level.
NOTE 3 All transactions that straddle a time change or a time zone calculate dwellTime and (possibly adjusted)
endDateTime from the startDateTime and start timeZone.
4.2.5 PUDO match descriptor: The offer descriptor
The PUDO offer descriptor describes an offer for a PUDO space. A PUDO offer descriptor shall be constructed
as in Table 3.
ISO/DTS 25614-1:2026(en)
Table 3 — Construction of a PUDO offer descriptor
Element Type Unit Description
messageType See Table 2 See Table 2 see Table 1
reasonField See Table 2 See Table 2 only used if messageType is "unusable"
legal values are listed in 4.4.8
timeStampInit See Table 2 See Table 2 copy of timeStampInit from original request descriptor
timeStampNow See Table 2 See Table 2 time stamp of this current message, use ISO 8601-2
transactionID See Table 2 See Table 2 unique ID assigned by the orchestrator
(unique)
persists throughout all exchanges about this PUDO trans-
action until closed (completed or cancelled)
operatorID (unique) See Table 2 See Table 2 unique ID for the requesting vehicle operator assigned at
the time that operator initially enrolled in the orchestra-
tion system
permanent and persists for this operator while registered
within this orchestration system
vehicleID (unique) See Table 2 See Table 2 see Table 2
vehiclePurpose See Table 2 See Table 2 stated in the request descriptor
sustained throughout the transaction
length See Table 2 See Table 2 space length
includes all space usable for loading or unloading includ-
ing open doors, entrance/exit ramps, ingress/egress of
passengers or goods
width See Table 2 See Table 2 space width
includes all space usable for loading or unloading includ-
ing open doors, entrance/exit ramps, ingress/egress of
passengers or goods
height See Table 2 See Table 2 space height
includes all space to pass under any entrance gate; to load/
unload under low ceiling, an awning, or other cantile-
vered or overhanging infrastructural element that would
obstruct access to the space
weight See Table 2 See Table 2 gross weight a space permits
noiseLevel See Table 2 See Table 2 highest noise level that a space permits
includes engine, motor, loading/unloading activity, horns,
sirens, speakers, door slamming, and any other sounds
made by the vehicle or its activities
fuelType See Table 2 See Table 2 see Table 1
hazardLevel See Table 2 See Table 2 see Table 1
timeZone char time zone in which this PUDO space is located
startDateTime See Table 2 See Table 2 start date and time (arrival) for which this PUDO space is
being offered
endDateTime See Table 2 See Table 2 end date and time (departure) for which this PUDO space
is being offered
Spatial dimension definitions need to match the final location description for a space. Many place hierarchy attributes
[2]
described in ISO/TS 5206-1:2023 might be included in any particular instance of a PUDO system for integration with parking
description, rules, guidance, enforcement, rights, monetization, etc., but not all place attributes are required in this document,
hence are out of scope.
For detailed vehicle positioning, final settling should be achieveable without ground markings or beacons which can be occluded
by snow, sand, rubbish, etc., hence a PUDO space should be locatable in detail and using virtual means to every degree possible.
NOTE Default dimensions are intentionally set to zero to force the responsible agent to describe the space so that no PUDO
vehicle is offered a space in error that it cannot fit in by virtue of a default being overlooked.

ISO/DTS 25614-1:2026(en)
TTabablele 3 3 ((ccoonnttiinnueuedd))
Element Type Unit Description
dwellTime See Table 2 See Table 2 total time the space is reserved
default is {endDateTime - startDateTime} in seconds
if vehic
...

ISO/TC 204
ISO/CD TSDTS 25614-1(en)
ISO/TC 204
Secretariat: ANSI
Date: 2026-07-07
Intelligent transport systems — Orchestration of vehicles for fixed
locations —
Part 1:
Reservation service
ISO/DTS 25614-1:2026(en)
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
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
ISO/DTS 25614-1:2026(en)
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Orchestration of pickup and drop-off (PUDO) for passengers and goods . 3
4.1 System considerations . 3
4.2 PUDO Descriptors . 4
4.3 PUDO space description . 14
4.4 PUDO auxiliary matching functions . 17
4.5 Transaction Diagrams . 22
Annex A (normative) ASN.1 Module Definiton . 36
Bibliography . 40

iii
ISO/DTS 25614-1:2026(en)
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO 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, ISO [had/had not] 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
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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 [or Project Committee] , , [name of committee],
Subcommittee SC ISO/TC 204, Intelligent transport systems.
This edition cancels and replaces the edition (ISO :), which has been technically revised.
The main changes are as follows:

A list of all parts in the ISO series25614 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.
iv
ISO/DTS 25614-1:2026(en)
Introduction
This document specifies system requirements for regional, multi-agent, pickup and drop-off (PUDO)
orchestration that coordinates multiple, independent vehicle fleets accessing shared curb spaces and loading
zones. PUDO orchestration manages temporal and spatial access to curb space and loading areas for passenger
and goods movement across public and private operators.
The increasing automation of vehicle fleets, growth in e-commerce deliveries, and the expansion of mobility
services such as automated ride-hail services have intensified competition for limited PUDO spaces. Without
coordinated orchestration, this competition can lead to congestion, safety hazards, and inefficient use of urban
infrastructure.
This document enables interoperability among multiple independent operators' systems while supporting
prioritization rules, fair access policies, and local regulations. It enables system reliability, respects data
privacy, and acknowledges cybersecurity as essential for managing critical urban mobility infrastructure.
While this document specifies data and function requirements, it does not describe or prescribe specific
algorithms for space allocation or mandate particular operational policies, which are expected to remain
under local authority control.
v
ISO/DTS 25614-1:2026(en)
Intelligent transport systems — Orchestration of vehicles for fixed
locations —
Part 1:
Reservation service
1 Scope
This document defines the application layer data structures and functional requirements for systems that
dynamically allocate pickup and drop-off (PUDO) access among:
— Automated passenger vehicles (private and commercial)
— Emergency vehicles
— Logistics and delivery fleets
— Municipal service vehicles
— Private commercial fleets (passenger and goods)
— Public transportation vehicles
— Transportation network company fleets
This document defines the data and data flow functions required to orchestrate the use of spaces (spots, bays)
for road vehicles to stop (stand) for the purpose of loading or unloading goods and passengers. The data and
functions defined support space definition (supply) and vehicle requirements (demand), space-to-vehicle
matching, scheduling, reservation, delays, rescheduling, cancellation, and queueing-in-motion.
This is inclusive of all levels of vehicle automation—, i.e.,. both uncrewed and crewed vehicles.
This is inclusive of any space that maycan be in demand for shared loading and unloading, curb-sides, parking
lots, and both indoor and outdoor facilities. It is inclusive of all spaces that admit shared use by more than one
vehicle as described.
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 8601-2, Date and time — Representations for information interchange — Part 2: Extensions
3 Terms and definitions
For rules on the drafting of the Terms and definitions, refer to the .
To insert a new terminological entry, go to the Structure tab and click on Insert Term entry.

ISO/DTS 25614-1:2026(en)
For the purposes of this document, the following terms and definitions / terms and definitions given in , as well
as the following [delete what doesn't apply] apply.apply.
ISO and IEC maintain terminologicalterminology databases for use in standardization at the following
addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
minimal risk condition
"A stable, stopped condition to which a user or an ADS (automated driving system) may (ADS) can bring a
vehicle after performing the DDT (dynamic driving task (DDT) fallback in order to reduce the risk of a crash
when a given trip cannot or should not be continued."
[SOURCE: SAE J3016:2021Note 1 to entry: This is defined in SAE J3016, Apr2021 "Taxonomy and Definitions for Terms
Related to Driving Automation Systems for On-Road Motor Vehicles." page 15.
3.2
, modified — Adjusted to fit ISO drafting guidelines.]
3.2
PUDO, noun
pickup/ and drop-off
load (pick up) or unload (drop off) passengers or goods
Note 1 to entry: "pickPick up" and "drop off" are verbs.
Note 2 to entry: "pickupPickup," "drop-off," and "PUDO" are adjectives. Examples are "a pickup/drop-off spot," "a PUDO
schedule," or "a PUDO permission."".
3.3
orchestration
act of coordinating multiple entities in an activity
Note 1 to entry: In this document, orchestration relates to vehicular pickup and drop-off activities while using shared,
publicly accessible spaces.
3.4
orchestrator
entity that receives, manages and distributes orchestration (3.3) requests and instructions for multiple
independent vehicle (3.6) or fleet operators
Note 1 to entry: This entity may be a governing authority.
Note 2 to entry: It is possible for the owner of a private household vehicle to require PUDO (3.2) access and, hence, be a
vehicle operator for purposes of this document.
3.5
space
identified area for a vehicle to stop to load/unload
[2]
Note 1 to entry: The end element of a parking place hierarchy in the ISO/TS 5206-1:2023 definition for parking
facilities.
ISO/DTS 25614-1:2026(en)
3.6
vehicle
machine or conveyance to transport persons or goods, as identified by a number of specific attributes defined
to orchestrate its loading/unloading
[3]
Note 1 to entry: ISO 26262-1:2018 describes a number of types and properties of "vehicle," but does not define the
term "vehicle."".
4 Orchestration of pickup and drop-off (PUDO) for passengers and goods
4.1 System considerations
4.1.1 Orchestration system to set location and schedule for PUDO events
For locations where multiple vehicles maycan require co-temporal access for loading or unloading operations,
a vehicle management system shall orchestrate:
a) vehicle stop position (space));
b) vehicle arrival time (schedule));
c) vehicle dwell time (duration of stay) at space.
NOTE Orchestration helps prevent spatial contention among vehicles wishing to occupy the same stopping/loading
space within the same time frame.
4.1.2 PUDO orchestration service capability
A PUDO orchestration system shall be designed and deployed without limitation with respect to:
a) The expected peak number of vehicles under management.
b) The expected peak number of spaces under management.
c) The extent of the geographic area under management.
d) Its ability to handle peak request volumes within a stated time or space window.
NOTE 1 PUDO orchestration is a traffic management system embedded within a wider traffic management system,
inclusive of many other road users, vehicles, and spaces that are not part of the orchestration activity. There maycan be
traffic events beyond the PUDO system's control. Some such events maycan not be anticipated, but the orchestration
system must be resilient. Specifically, the system maycan experience long lags, or a large number of PUDO spaces maycan
be taken out of service, yet the orchestrator cannot fail to operate.
NOTE 2 The system should be able to handle the volume of requests at peak demand for the full
complement of vehicles and spaces under management in the full geography of its jurisdiction. For example,
if all the vehicles under management were to request a PUDO reservation within the same minute, the system
maycan lag but would not fail, regardless of the length of the service queue or any reservation delays incurred.
4.1.3 PUDO orchestration service failure
In the event of communication failure involving the orchestration service, any participating vehicle that cannot
access its assigned PUDO place shall assume a minimal risk condition.
ISO/DTS 25614-1:2026(en)
4.1.4 PUDO orchestration service level agreement
A PUDO orchestration system shall incorporate service level agreements between the system orchestrator
entity and each vehicle operator to be served by the system.
4.2 PUDO Descriptors
4.2.1 PUDO match descriptor message types
A PUDO match descriptor is a message holding several identified data elements needed to match a vehicle
with a space. It is provided in, and used as, one of three message types:
a) A request for a space for a specified PUDO event; a request is sent from a vehicle operator to a regional
PUDO orchestrator, i.e., an orchestration agent or system.
b) An offer of a PUDO reservation (contract); an offer is sent from a PUDO orchestrator to the vehicle
operator that is managing the requesting vehicle.
c) An alternate is a description of a near-match between a requesting vehicle and the closest-match
space; this is sent from a PUDO orchestrator to a vehicle operator.
4.2.2 PUDO match descriptor message elements
Data elements match descriptor messages shall use data identifiers listed below:
— messageType
— reasonField
— timeStampInit
— timeStampNow
— transactionID
— operatorID
— vehicleID
— vehiclePurpose
— length
— width
— height
— weight
— noiseLevel
— fuelType
— hazardLevel
— timeZone
ISO/DTS 25614-1:2026(en)
— startDateTime
— endDateTime
— dwellTime
— radius
— roadCrossCount
— timeSpacePreference
— feePerMinute
— spaceCx
— spaceCy
— spaceCz
— spaceFLx
— spaceFLy
— spaceFLz
— spaceFRx
— spaceFRy
— spaceFRz
— spaceBRx
— spaceBRy
— spaceBRz
— spaceBLx
— spaceBLy
— spaceBLz
Those data elements and their formats are defined in clauses 4.2.3 ,, 4.2.4 ,, 4.2.5 ,, and 4.2.6 .
4.2.3 PUDO match descriptor message details
The feature meaning for each element of the three match descriptors shall be consistent (Table 1), but the
calculation and interpretation of some descriptor elements may differ (Table 2, Table 3, and Table 4).
ISO/DTS 25614-1:2026(en)
Table 1 — The elements of a match descriptor
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
a) "request" n) "alternate"
messageType One of
b) "accept"
c) "change"
d) "reject"
e) "abandon"
f) "complete"
g) "unusable"
h) "offer"
i) "refuse"
j) "revise"
k) "cancel"
l) "close"
m) "timeout"
reasonField nil See Table 3 and 4.4.8 nil
timeStampInit time stamp of initial request confirmed and sustained confirmed and sustained
timeStampNow =timeStampInit time stamp of this message time stamp of this message
transactionID nil if 1st request; provided by orchestrator provided by orchestrator
(unique) only on initial offer; only on initial offer;
same as provided by
orchestrator if re-request sustained until transaction is sustained until transaction is
follows an alternate or closed, completed, or closed, completed, or
rejection abandoned abandoned
operatorID assigned by the orchestrator confirmed and sustained confirmed and sustained
(unique) at the time of initial operator
registration;
the operatorID initialization
process is out of scope
vehicleID (unique) declared by vehicle operator confirmed and sustained confirmed and sustained
— dignitary
vehiclePurpose confirmed and sustained confirmed and sustained
— ems
— fire
— goods
— passenger, private
ISO/DTS 25614-1:2026(en)
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
— passenger, taxi
— passenger, transit
— police
— service
length vehicle length, integer, mm space length, mm space length minus- vehicle
(maximum) length, mm
width vehicle width, integer, mm space width, mm space width minus- vehicle
width, mm
height vehicle height, integer, mm space height, mm (minimum) space height minus vehicle
(maximum) (note 1) height, mm
weight vehicle gross weight, integer, space max weight permitted, space weight minus vehicle
kg kg weight, kg
noiseLevel vehicle noise max level space noise max level space noise minus vehicle
expected, dB permitted, dB noise, dB
fuelType vehicle fuel type (declared) space fuel permissions; one Fuel mismatch (binary)
of:
— [0] Unknown
— [1] Diesel
— [2] Electric
— [3] Gasoline (petrol)
— [4] Hydrogen
— [5] LPG
— [6] Methanol
— [7] Natural gas
— [8] Propane
— [9] Other
hazardLevel hazardous cargo descriptor hazardous cargo permission hazardous mismatch (binary)
(declared) (table)
UN codes, 9 categories
[4]
ISO HCC codes are for
storage
timeZone time zone for the request time zone for the offer sustained
startDateTime start date and time for the start date and time for the start date and time alternate
request offer in the offer
endDateTime end date and time for the end date and time for the end date and time alternate
request offer in the offer
ISO/DTS 25614-1:2026(en)
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
dwellTime amount of time requested amount of time offered amount of time offered
radius maximum euclidean distance euclidean distance offered (shortest) euclidean distance
requested from {cX,cY} from {cX,cY} offered from {cX,cY}
roadCrossCount maximum road-crossing road-crossing count between (minimum) road-crossing
count between requested offered {cX,cY,0} and count between offered
{cX,cY,0} and offered requested {cX,cY,0} {cX,cY,0} and requested
{cX,cY,0} {cX,cY,0}
timeSpacePreferenc "time" if requesting closest in "time" if offer is closest in "time" if offer is closest in
e time; time; time;
"space" if requesting closest "space" if offer is closest in "space" if offer is closest in
in distance distance distance
feePerMinute zero (0.0) or maximum zero (0.0) or fee in local zero (0.0) or fee in local
acceptable fee in local currency currency
currency
cX requested PUDO location, x longitude of the centre of the difference in x
space being offered
cY requested PUDO location, y latitude of the centre of the difference in y
space being offered
cZ requested PUDO location, z altitude of the centre of the difference in z
space being offered
flX nil longitude of the front left nil
extreme of the space being
offered
flY nil latitude of the front left nil
extreme of the space being
offered
flZ nil altitude of the front left nil
extreme of the space being
offered
frX nil longitude of the front right nil
extreme of the space being
offered
frY nil latitude of the front right nil
extreme of the space being
offered
frZ nil altitude of the front right nil
extreme of the space being
offered
brX nil longitude of the back right nil
extreme of the space being
offered
brY nil latitude of the back right nil
extreme of the space being
offered
brZ nil altitude of the back right nil
extreme of the space being
offered
ISO/DTS 25614-1:2026(en)
Request descriptor Offer descriptor Alternate descriptor
Element
(for vehicle) (for space) (for difference)
blX nil longitude of the back left
nil
extreme of the space being
offered
blY nil latitude of the back left nil
extreme of the space being
offered
blZ nil altitude of the back left nil
extreme of the space being
offered
The minimum space height is the lowest height the vehicle must traverse before stopping in the assigned PUDO space. If a PUDO
area has an entrance gate with a maximum vehicle height that is less than the PUDO space offered, then the height of that entrance
gate shall be used.
NOTE 1NOTE 1 vehiclePurpose is declared by the vehicle operator. Whether the orchestrator uses this to manage priorities
is outside the scope of this document.
NOTE 2NOTE 2 dwellTime is the time that the PUDO vehicle operator requests to complete loading or unloading. It is not the
same as {endDateTime minus startDateTime}, but it must be less than or equal to that.
NOTE 3NOTE 3 radius is the preferred maximum distance between the requested and proposed PUDO locations.
NOTE 4NOTE 4 timeSpacePreference is used to weight an offer that cannot be met as requested with an offer closest to the
time or location requested.
NOTE 5NOTE 5 roadCrossCount is the preferred maximum number of streets to be crossed between the requested and
proposed PUDO locations. Some passengers can be blind or wheelchair users, and some deliveries can include large or heavy objects
or medical or food deliveries that are temperature controlled.
4.2.4 PUDO match descriptor: The request descriptor
The PUDO request descriptor describes the vehicle and demand for a PUDO space. It shall be constructed as in
Table 2.
Table 2 — Construction of a PUDO request descriptor
Element Type Unit Description
messageType char See Table 1 "request"
reasonField char See Table 1 nil
timeStampInit ISO 8601-2 See Table 1 since there is only one initial request descriptor,
timeStampInit is sustained throughout the transaction
timeStampNow ISO 8601-2 See Table 1 this is the same value as timeStampInit when a request is
initialized
transactionID char See Table 1 unique ID assigned by the orchestrator
(unique)
persists throughout all exchanges on this transaction until
the transaction is closed
operatorID (unique) char See Table 1 unique ID assigned at the time a vehicle operator first
enrols in the orchestration system
persists for this operator within this orchestration system
vehicleID (unique) char See Table 1 unique ID for a PUDO vehicle provided by the vehicle
operator at the time of the initial request
ISO/DTS 25614-1:2026(en)
Element Type Unit Description
persists throughout all message exchanges within this
PUDO transaction until the transaction is closed
If a vehicle is exchanged with another vehicle before the
PUDO transaction is completed, a new transaction shall be
started
NOTE 1NOTE 1 This can be a vehicle identification number
(VIN) or a vehicle registration plate number if the plate
jusisdiction is included.
vehiclePurpose char See Table 1 see Table 1
length int mm vehicle extended length in including all space needed for
loading or unloading including open doors, entrance/exit
ramps, ingress/egress of passengers or goods
width int mm vehicle extended width in including all space needed for
loading or unloading including open doors, entrance/exit
ramps, ingress/egress of passengers or goods
height int mm vehicle height in including roof carriage and all space
needed to pass under any entrance gate; to load/unload
under low ceiling, an awning, or other infrastructural
element
weight int kg vehicle gross weight prior to unloading, or after loading,
whichever is heaviest
noiseLevel int dB expected peak level of the engine, motor,
loading/unloading activity, horns, sirens, or speakers
fuelType char See Table 1 see Table 1
hazardLevel char See Table 1 see Table 1
timeZone IA5String See Table 1 time zone in which the desired PUDO space is located
use IANA time zone identifier
startDateTime ISO 8601-2 See Table 1 requested start date and time for a PUDO space to be used
endDateTime ISO 8601-2 See Table 1 end date and time for which a PUDO space is requested
dwellTime int sec amount of time required for intended purpose
radius int m see Table 1
RoadCrossCount int>0 See Table 1 see Table 1
timeSpacePreference char See Table 1 see Table 1
feePerMinute real See Table 1 see Table 1
pX real Decimal degrees requested PUDO target longitude
pY real Decimal degrees requested PUDO target latitude
pZ real m requested PUDO target altitude
NOTE 2NOTE 2 With regard to noiseLevel, it is possible for a vehicle to be able to emit noise at a higher dB level than it requests
(reports), in order to load or unload at spaces that do not permit high dB levels. Hence, a vehicle that reports a low DB level to gain
access to such a space is expected to constrain its noise output to that level.
NOTE 3NOTE 3 All transactions that straddle a time change or a time zone calculate dwellTime and (possibly adjusted)
endDateTime from the startDateTime and start timeZone.
ISO/DTS 25614-1:2026(en)
4.2.5 PUDO match descriptor: The offer descriptor
The PUDO offer descriptor describes an offer for a PUDO space. A PUDO offer descriptor shall be constructed
as in Table 3.
Table 3 — Construction of a PUDO offer descriptor
Element Type Unit Description
messageType See Table 2 See Table 2 see Table 1
reasonField See Table 2 See Table 2 only used if messageType is "unusable"
legal values are listed in 4.4.8
timeStampInit See Table 2 See Table 2 copy of timeStampInit from original request descriptor
timeStampNow See Table 2 See Table 2 time stamp of this current message, use ISO 8601-2
transactionID See Table 2 See Table 2 unique ID assigned by the orchestrator
(unique)
persists throughout all exchanges about this PUDO
transaction until closed (completed or cancelled)
operatorID (unique) See Table 2 See Table 2 unique ID for the requesting vehicle operator assigned at
the time that operator initially enrolled in the
orchestration system
permanent and persists for this operator while registered
within this orchestration system
vehicleID (unique) See Table 2 See Table 2 see Table 2
vehiclePurpose See Table 2 See Table 2 stated in the request descriptor
sustained throughout the transaction
length See Table 2 See Table 2 space length
includes all space usable for loading or unloading
including open doors, entrance/exit ramps,
ingress/egress of passengers or goods
width See Table 2 See Table 2 space width
includes all space usable for loading or unloading
including open doors, entrance/exit ramps,
ingress/egress of passengers or goods
height See Table 2 See Table 2 space height
includes all space to pass under any entrance gate; to
load/unload under low ceiling, an awning, or other
cantilevered or overhanging infrastructural element that
would obstruct access to the space
weight See Table 2 See Table 2 gross weight a space permits
noiseLevel See Table 2 See Table 2 highest noise level that a space permits
includes engine, motor, loading/unloading activity, horns,
sirens, speakers, door slamming, and any other sounds
made by the vehicle or its activities
fuelType See Table 2 See Table 2 see Table 1
hazardLevel See Table 2 See Table 2 see Table 1
timeZone char time zone in which this PUDO space is located
startDateTime See Table 2 See Table 2 start date and time (arrival) for which this PUDO space is
being offered
ISO/DTS 25614-1:2026(en)
Element Type Unit Description
endDateTime See Table 2 See Table 2 end date and time (departure) for which this PUDO space
is being offered
dwellTime See Table 2 See Table 2 total time the space is reserved
default is {endDateTime - startDateTime} in seconds
if vehicle arrives after startDateTime, dwellTime is
shorter, accordingly
radius See Table 2 See Table 2 see Table 1
RoadCrossCount See Table 2 See Table 2 see Table 1
timeSpacePreference See Table 2 See Table 2 see Table 1
feePerMinute See Table 2 See Table 2 see Table 1
cX Real Decimal degrees see Table 1
cY Real Decimal degrees see Table 1
cZ Real m see Table 1
flX Real Decimal degrees see Table 1
flY Real Decimal degrees see Table 1
flZ Real m see Table 1
frX Real Decimal degrees see Table 1
frY Real Decimal degrees see Table 1
frZ Real m see Table 1
brX Real Decimal degrees see Table 1
brY Real Decimal degrees see Table 1
brZ Real m see Table 1
blX Real Decimal degrees see Table 1
blY Real Decimal degrees see Table 1
blZ Real m see Table 1
Spatial dimension definitions need to match the final location description for a space. Many place hierarchy attributes
described in ISO/TS 5206-1:2023 might be included in any particular instance of a PUDO system for integration with parking
description, rules, guidance, enforcement, rights, monetization, etc., but not all place attributes are required in this document,
hence are out of scope.
For detailed vehicle positioning, final settling should be achieveable without ground markings or beacons which can be occluded
by snow, sand, rubbish, etc., hence a PUDO space should be locatable in detail and using virtual means to every degree possible.
NOTE Default dimensions are intentionally set to zero to force the responsible agent to describe the space so that no PUDO
vehicle is offered a space in error that it cannot fit in by virtue of a default being overlooked.
4.2.6 PUDO match descriptor: The alternate descriptor
The PUDO alternate descriptor describes the failure to generate a fully satisfactory offer for a PUDO space. It
shall be constructed as in Table 4.
Table 4 — Construction of a PUDO alternate descriptor
Element Description
messageType "alternate"
ISO/DTS 25614-1:2026(en)
Element Description
reasonField nil
timeStampInit copy of timeStampInit from original request descriptor
timeStampNow time stamp of this current message
use ISO 8601-2
transactionID (unique) same as in offer descriptor
not a reason for an alternate
required for transaction alignment
operatorID (unique) same as in offer descriptor
not a reason for an alternate
required for transaction alignment; redundant
vehicleID (unique) same as in offer descriptor
not a reason for an alternate
required for transaction alignment
vehiclePurpose confirmed and sustained
length space length difference (cm)
negative if short; positive if over; see Table 3
width space width difference (cm)
negative if short; positive if over; see Table 3
height space height difference (cm)
negative if short; positive if over; see Table 3
weight space gross weight difference (kg)
negative if short; positive if over; see Table 3
noiseLevel space noise level difference (dB)
negative if short; positive if over; see Table 3
fuelType -1 if vehicle fuel type not permitted
0 if permitted
hazardLevel -1 if hazard level not permitted; 0 if permitted
timeZone same as in offer descriptor, Table 3
not a reason for an alternate
startDateTime alternate (later) startDateTime in excess of the requested {endDateTime -
dwellTime} for which this PUDO space can be offered
endDateTime alternate (later) endDateTime, in excess of the actual offered time plus dwellTime
for which this PUDO space is being offered
dwellTime alternate (shorter) dwellTime than was requested
negative number in seconds
radius distance in excess of the requested maximum radius (m)
roadCrossCount number in excess of the requested maximum roadCrossCount (integer)
timeSpacePreference sustained from the initial Request
feePerMinute excess fee compared to maximum stated in the request (local currency)
cX longitude of the center of the space being offered
ISO/DTS 25614-1:2026(en)
Element Description
cY latitude of the center of the space being offered
cZ altitude of the center of the space being offered
flX longitude of the front left extreme of the space being offered
flY latitude of the front left extreme of the space being offered
flZ altitude of the front left extreme of the space being offered
frX longitude of the front right extreme of the space being offered
frY latitude of the front right extreme of the space being offered
frZ altitude of the front right extreme of the space being offered
brX longitude of the back right extreme of the space being offered
brY latitude of the back right extreme of the space being offered
brZ altitude of the back right extreme of the space being offered
blX longitude of the back left extreme of the space being offered
blY latitude of the back left extreme of the space being offered
blZ altitude of the back left extreme of the space being offered
For each field in an alternate descriptor, use the Type and Unit attributes from Table 3.
4.3 PUDO space description
4.3.1 A PUDO space location is unique
A PUDO space location description shall be unique.
NOTE WGS84 coordinates are suitable and assumed. If GNSS signals are insufficiently accurate or inaccessible,
additional supporting systems maycan be required. Such additional support is out of scope.
WarningWARNING — In the event of PUDO spaces in multi-storey structures, the WGS84 altitude will
be required, and in such structures, real-time positioning maycan be compromised, and maycan
require additional positioning support.
4.3.2 A PUDO space description shall be fully dimensioned
A PUDO space description shall include its physical dimensions, the acceptable properties of vehicles and
payloads that can use this location, the calendar schedule availability of this space, the time duration in which
this space maycan be occupied by a single PUDO vehicle, and the fee for using this space.
4.3.3 PUDO space orientation
A PUDO space x-axis shall be oriented (positive, signed direction) along the direction that the PUDO vehicle is
expected (default) to drive into.
The orientation of a PUDO space shall be given by the front left (x,y,z), front right (x,y,z) and the center (x,y,z)
coordinates of the space description.
ISO/DTS 25614-1:2026(en)
Key
A general orientation
B parallel
C perpendicular
Figure 1 — Alignment of a PUDO vehicle when it is correctly stopped in its assigned PUDO space: [A]
general orientation, [B] parallel, [C] perpendicular
NOTE 1 This is independent of whether the PUDO vehicle enters into the space forward, reverse, or parallel parks; it
is intended to provide the orientation of the space, default direction of entry, and maycan influence the choice of optimal
direction of approach.
NOTE 2 In the event that a PUDO vehicle reverses into a PUDO space (the front right of the space is aligned with the
back left of the vehicle), it is incumbent on the vehicle operator to consider the position of doors and the entrance and
exit of passengers and goods from the PUDO vehicle. There is no provision in the standard for an orchestrator to
understand or account for such a reversal.
NOTE 3 (x,y,z) correspond to WGS84 (longitude, latitude, altitude)).
4.3.4 A PUDO space description is a 3D bounding cuboid
The length, width, and height of a PUDO space describes a three-dimensional right parallelepiped—a
simple cuboid—that can fully enclose (without extrusion) a correctly positioned vehicle that has been
matched to a PUDO space.
ISO/DTS 25614-1:2026(en)
It shall be possible for a correctly measured and specified vehicle of a described length, width, and height
to enter into, open all doors, and extend all equipment and fixtures for ingress and egress of passengers or
goods and to safely load or unload within a matched PUDO space.
In the case of a PUDO space for which height is immaterial, height shall be set to -1. This effectively implies
that the height of the cuboid is unlimited relative to the vehicle.
Warning — When a vehicle must pass through a gate to reach a PUDO space, the minimum of the height of
the gate and the height of the space mustshall be used as the height description for the space.
4.3.5 Accuracy of PUDO space and vehicle dimensions
All PUDO space spatial dimensions shall be provided by rounding down to the nearest centimetre.
All PUDO vehicle spatial dimensions shall be provided by rounding up to the nearest centimetre.
4.3.6 PUDO space dimensions shall not be overestimated
In the case of measurement uncertainty, PUDO space dimensions shall be biased toward an underestimate.
NOTE This is to ensure that no vehicle maycan be assigned to a space that it cannot physically occupy, access (arrival
gateway opening), or open for egress or ingress.
4.3.7 PUDO vehicle dimensions shall not be underestimated
In the case of measurement uncertainty, PUDO vehicle dimensions shall be biased toward an overestimate.
NOTE This is to ensure that no vehicle maycan be assigned a space that it cannot physically occupy, access (arrival
gateway opening) or open for egress or ingress.
4.3.8 PUDO space schedule
A PUDO orchestration operator shall maintain a reliable schedule for all PUDO spaces defined within its
geographic and temporal jurisdiction.
A PUDO orchestration operator shall be able to offer a space to match any valid request descriptor from any
valid vehicle operator, such that the space offered is within the geographic and temporal jurisdiction of the
operator.
A PUDO orchestration operator shall not offer a space outside of its geographic or temporal jurisdiction.
A PUDO space schedule shall:
a) be accurate within 15 seconds;
b) be relative to the time zone and daylight savings status of the PUDO space;
c) indicate the times for which a space may be reserved;
d) be used consistently throughout all PUDO operations;
e) be able to consider vehiclePurpose when considering priority.
NOTE 1 Out of scope are:
— how far in advance such a schedule must be maintained (this constrains how far ahead PUDO reservations can be
provided));
ISO/DTS 25614-1:2026(en)
— how and whether such a schedule maycan be communicated to PUDO vehicle operators;
— equitable scheduling.
NOTE 2 Because PUDO space schedules must be accurate within 15 seconds, a minimum buffer time
between the endDateTime of one offer and the startDateTime of the subsequent offer must be at least 30
seconds. In the event that an orchestration operator cannot be certain of this accuracy, it mustneeds to
consider how to adjust this buffer time.
4.4 PUDO auxiliary matching functions
4.4.1 PUDO matching for location optimization
A PUDO orchestrator shall offer a closely matching PUDO space that accommodates the PUDO vehicle within
the time window {startDateTime, endDateTime}, radius, and roadCrossCount specification of the
request descriptor.
A vehicle operator shall be able to:
a) request a PUDO space
b) accept an offer of a PUDO space
c) request a time change to a PUDO contract
d) reject an offer of a PUDO space
e) abandon a contract for a PUDO space (only a vehicle operator can abandon a contract)
f) complete a contract for a PUDO space (only a vehicle operator can complete a contract)
g) declare a PUDO space to be unusable
A PUDO orchestrator shall be able to:
h) offer a contract for a PUDO space
i) refuse to grant an offer for a PUDO space
j) revise an offer for a PUDO space
k) cancel a contract for PUDO space (only an orchestrator can cancel a contract)
l) close a contract for a PUDO space (only an orchestrator can close a contract for final settlement)
m) issue an alternate descriptor
n) issue a timeout
NOTE 1 A vehicle operator can achieve a non-time change to a PUDO contract that has already been accepted by
abandoning the contract and issuing a new request descriptor.
NOTE 2 Additional decision criteria maycan be added, such as differential monetization rates, differential priorities
for goods vehicles and passenger vehicles, etc. The nature of, and necessity for, such additional criteria are out of scope.
NOTE 3 Preferential treatment for passengers with disabilities is implicit in the PUDO demand message by asking for
a very small radius or setting roadCrossCount to zero.
ISO/DTS 25614-1:2026(en)
4.4.2 Request a PUDO space
A vehicle operator shall be able to request a PUDO space by issuing a request descriptor (4.2.4) to a PUDO
orchestrator.
4.4.3 Accept an offer of a PUDO space
A vehicle operator shall be able to accept an offer for a PUDO space by returning the offer descriptor (4.2.5)
substituting "accepted" as the messageType to the issuing PUDO orchestrator.
Returning the offer descriptor, and substituting "accepted" as the messageType shall mean the vehicle
operator has accepted the offered PUDO space as a contract, and is obligated to the PUDO transaction under
the terms agreed with the offering PUDO orchestrator.
When accepting an offer, nothing shall be changed in the offer descriptor excepting the messageType. Hence,
only messageType, timeStampNow, and, transactionID shall be required to confirm the contract, and
no other fields shall be altered.
NOTE The terms of any contract between a vehicle operator and a PUDO orchestrator are outside the scope of this
document.
4.4.4 Request a time change for a PUDO contract
A vehicle operator shall be able to request a new time window by returning the currently accepted offer
descriptor, substituting "change" as the messageType, and changing startDateTime, endDateTime, and
dwellTime, accordingly.
In response to a request for a time change, the PUDO orchestrator shall do one of:
a) Issue a new offer under the same transactionID with new time data
b) Reissue the currently accepted offer , with no change to the PUDO time data
c) Issue a refuse and close
In the case of receiving an offer, the vehicle operator shall accept, reject, request another change, or abandon
the transaction.
4.4.5 Reject an offer of a PUDO space
A vehicle operator shall be able to reject an offer of a proposed PUDO space by returning the offer descriptor
(4.2.5) to the PUDO orchestrator, substituting "reject" as the messageType. The remainder of the offer
descriptor shall be updated with a modified request.
In the event that the orchestrator receives a "reject" message with no change to the remainder of the request,
it shall return the same message with messageType set to "refuse" which is automatically followed b
...