ISO 22133

Privileged
ISO/FDIS 22133:2025(en)
ISO/TC 22/SC 33
Secretariat: DIN
Date: 2025-01-0709
Road vehicles — Test object monitoring and control for active safety
and automated/autonomous vehicle testing — Functional
requirements, specifications and communication protocol
Véhicules routiers – — Surveillance et contrôle des objets de test pour l’évaluation de la sécurité active et des
véhicules automatisés/autonomes –— Exigences fonctionnelles, caractéristiques et protocole de
communication
FDIS stage
Privileged
ISO/FDIS 22133:2025(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
EmailE-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Privileged
ISO/FDIS 22133:2025(en)
Contents
Foreword . v
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 5
5 Test scenario illustration . 5
6 General requirements and recommendations . 7
6.1 Function overview . 7
6.2 Test object coordinate system . 7
6.3 Test scenario coordinate system. 12
6.4 Time requirements . 14
6.5 Communication requirements, recommendations and permissions . 18
7 Safety and risk assessment requirements and recommendations . 20
7.1 General. 20
7.2 Local test object fence and global geofence . 20
8 Communication security requirements . 24
9 Architecture and interfaces . 25
9.1 General. 25
9.2 Control centre and test object states . 26
9.3 Communication setup . 32
9.4 Control functionalities . 39
9.5 Monitoring functionalities . 42
10 Trajectory and scenario-based testing . 43
10.1 Introduction to trajectory and scenario-based testing . 43
10.2 Static trajectories . 44
10.3 Dynamic trajectories . 44
10.4 Scenario description languages . 45
11 Functional requirements . 45
11.1 Device interface description XML (DIDX) . 45
11.2 Control centre requirements and recommendations . 46
11.3 Stationary test object requirements . 46
11.4 Moveable test object requirements and recommendations . 47
11.5 Functions with behaviour description . 48
12 Message requirements . 65
12.1 General. 65
12.2 Message . 65
12.3 Definition of messages . 72
Annex A (normative) Trajectory file format . 121
Annex B (informative) Message footer checksum calculation. 125
Annex C (informative) Trigger and action . 131
Annex D (normative) Device interface description XML (DIDX) . 138
Annex E (informative) An overtake by a test object with dynamic position points (DPP). 140
iii
Privileged
ISO/FDIS 22133:2025(en)
Bibliography . 156

iv
Privileged
ISO/FDIS 22133:2025(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 documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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 patents 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 22, Road vehicles, Subcommittee SC 33, Vehicle
dynamics, chassis components and driving automation systems testing.
This first edition cancels and replaces the first edition of ISO/TS 22133:2023, which has been technically
revised.
The main changes are as follows:
— — update of the test coordinate system (6.3.2(6.3.2););
— — update of the local test object and global geofence (7.2(7.2););
— — redesign of the test object and control centre state diagram (9.2(9.2 and 9.39.3););
— — extension of MONR-struct with StopTrigger, ObjectAction, etc.;
— — increase of position accuracy (MONR, TRAJ, GEOF);
— — introduction of monitoring mode;
— — increase of the DRES message (added supported modes);
— — update of diagrams (e.g. Estop, NormalStop);
— — introduction of a normal stop by a test object;
— — improvement and development of object discovery detection;
v
Privileged
ISO/FDIS 22133:2025(en)
— — added the dynamic position point message.
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.
vi
Privileged
ISO/FDIS 22133:2025(en)
Introduction
Testing of collision avoidance systems, active safety functions and more advanced autonomous functions in
vehicles require testing on proving grounds. The purpose is to expose the vehicle under test to potentially
dangerous traffic situations in a safe manner. The evaluation is done during development and in voluntary
and mandatory test procedures.
To orchestrate these traffic scenarios, various impactable targets representing traffic actors are controlled.
The number of controlled targets can be one or many depending on the required traffic situation scenario.
Several requirements are important ranging from safety to position and speed precision, to logging
capabilities.
This document specifies requirements, functionality and a protocol allowing for multivendor target carrier
systems to be controlled according to the required traffic situation scenario, to report expected information
for logging purposes and other functions required.
vii
DRAFT International Standard ISO/FDIS 22133:2025(en)
Privileged
Road vehicles — Test object monitoring and control for active safety
and automated/autonomous vehicle testing — Functional
requirements, specifications and communication protocol
1 Scope
This document specifies requirements, procedures and message formats for controlling and monitoring of test
objects, used for testing of active safety functions and autonomous vehicles.
This document specifies functionality and messaging for monitoring and controlling of test objects by a control
centre facilitating an interoperable test object environment. This document defines a communication protocol
which allows for the control centre to safely execute tests using test objects from multiple vendors.
This document does not specify the internal architecture of the test object nor control centre.
This document does not specify how testing of the vehicles shall be performed.
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 (all parts), Date and time — Representations for information interchange
ISO 8855, Road vehicles — Vehicle dynamics and road-holding ability — Vocabulary
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:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
3.1 3.1
test object
entity, as defined in ISO 34501, which is part of a traffic scenario under monitoring and control by the control
centre (3.5(3.5))
Note 1 to entry: Two types of test objects exist: moveable and stationary test objects (3.4(3.4).).
Note 2 to entry: A test object can have several attributes, see Figure 1Figure 1.
Privileged
ISO/FDIS 22133:2025(en)
Figure 1 — Relations and inheritance view
3.2 3.2
subject vehicle
SV
vehicle with active safety system to be tested and evaluated
Note 1 to entry: The subject vehicle, SV, is also known as vehicle under test, VUT.
Note 2 to entry: There can be one subject vehicle (standard setup) or a set of subject vehicles in the specific traffic
scenario.
Note 3 to entry: The subject vehicle can be under safety-driver control and/or under control-centre (3.5(3.5)) control.
Note 4 to entry: The subject vehicle is an instantiated test object (3.1(3.1)) in either type of: stationary test object
(3.4(3.4)) or moveable test object (3.3(3.3).).
3.3 3.3
moveable test object
object under control by the control centre (3.5(3.5)) which has the capability of activation of physical
movement
Note 1 to entry: Various levels of control are possible: open-loop control (using no feedback from the real-time activities
of other test objects (3.1(3.1)) or environment) and closed-loop control (taking into account activities of other test objects
in real-time and environment). One other type of controlling/triggering is related to test object unique features like: turn
indicator, headlight beam, etc.
3.4 3.4
stationary test object
part of a traffic scenario, which is not moveable but can be under control by the control centre (3.5(3.5))
Privileged
ISO/FDIS 22133:2025(en)
Note 1 to entry: Different stationary test objects can exist. Normally they are divided in to two groups: active and passive
stationary test objects.
EXAMPLE 1 Active stationary test object: traffic light, lighting, rain/snow/fog simulator.
EXAMPLE 2 Passive stationary test object: elements of construction area such as road signs, guardrails.
3.5 3.5
control centre
CC
centralized or distributed service for test object (3.1(3.1)) control and safety monitoring including provision
of communication services to the test objects
3.6 3.6
path
set of local or global positions in respect to a point of origin and in respect to the orientation to the axes of a
defined coordinate system (x,y,z)
3.7 3.7
lateral path deviation
position error of the target vehicle relative to the planned path (3.6(3.6)) measured perpendicular from the
planned path direction
[SOURCE: ISO 19206-3:2021, 3.8, modified — Notes to entry and figure removed.]
3.8 3.8
trajectory
path (3.6(3.6)) where a test object (3.1(3.1)) is or is intended to move along including test object dynamics
Note 1 to entry: A trajectory contains a path and additionally the test object dynamics (e.g. time, yaw, velocity,
acceleration) for each position on the path.
Note 2 to entry: All test object parameters related to test object dynamic (e.g. limitations in acceleration) are described
in the corresponding DIDX file.
3.9 3.9
static trajectory
offline pre-planned trajectory (3.8(3.8)) including test object (3.1(3.1)) position and test object motion
dynamics for a single moveable test object (3.3(3.3)) as part of the test scenario (3.11(3.11))
Note 1 to entry: The trajectory is downloaded to the test object utilizing the trajectory object message (TRAJ).
Note 2 to entry: The parameters used by the test object are described in the DIDX file.
Note 3 to entry: The control centre (3.5(3.5)) can extract information from the trajectory file and builds a trajectory
message, TRAJ, that is received by the test object before start of test.
3.10 3.10
dynamic trajectory
trajectory (3.8(3.8)) which at the start of the scenario execution is not known by the test object (3.1(3.1)) nor
the control centre (CC) (3.5(3.5))
Note 1 to entry: The dynamic trajectory is created based on events and actions during the ongoing test.
Note 2 to entry: The dynamic trajectory is continuously sent by the CC or gated through the CC in smaller
pieces/fragments utilizing the trajectory object message (TRAJ).
Privileged
ISO/FDIS 22133:2025(en)
Note 3 to entry: In the case where the test object or other system (e.g. a simulation environment) is generating the
dynamic trajectory, this information is sent to the CC and then from the CC to the test object.
3.11 3.11
test scenario
scenario, as defined in ISO 34501, including all test objects (3.1(3.1),), moveable and stationary, and the
definition of the planned activities over time or/and location
Note 1 to entry: The traffic scenario can be formally represented by two complementary descriptions enabling test
execution, a scenario description (3.12(3.12),), and a map of the test area.
3.12 3.12
scenario description
textual representation of a scenario
Note 1 to entry: A scenario description can be used in combination with a scenery description (3.13(3.13)) to generate
trajectories (3.8(3.8)) (static or dynamic) by the control centre (3.5(3.5)) or a test object (3.1(3.1).).
[ [17] ]
EXAMPLE Test scenario (3.11(3.11)) described using OpenSCENARIO or iSCAML 0 . .
3.13 3.13
scenery description
representation of the test area limited to the road geometry (e.g. lanes and junctions) and stationary test
objects (3.4(3.4)) (e.g. road signs and markings)
Note 1 to entry: A scenery description can be used in combination with a scenario description (3.12(3.12)) to generate
trajectories (3.8(3.8)) (static or dynamic) by the control centre (3.5(3.5)) or a test object (3.1(3.1).).
EXAMPLE Temporary lane-setup on a proving ground, described using OpenDRIVE.
3.14 3.14
safety speed limit
maximum allowed speed when repositioning moveable test objects (3.3(3.3)) while not participating in
ongoing test
Note 1 to entry: The test object (3.1(3.1)) is manually driven with the remote control functionality or automatically
driven when outside the test execution phase.
3.15 3.15
device ID
unique identifier for each test object (3.1(3.1)) and control centre (3.5(3.5)) in the test setup
Note 1 to entry: The device ID number is used as transmitter ID or receiver ID in every message except when tunnelling
data.
3.16 3.16
message gating
mechanism to gate messages from a sender to a receiver defined by the transmitter ID and receiver ID in the
message header
3.17 3.17
dynamic position point
DPP
position that moves in time relative an origin and defines the momentary destination
Note 1 to entry: Further explanation is given in Annex EAnnex E.
Privileged
ISO/FDIS 22133:2025(en)
4 Abbreviated terms
ASP adaptive synchronization point
DIDX device interface description XML
CC control centre
DPP dynamic position point
ECEF earth-centred, earth-fixed (geographical coordinate system)
GNSS global navigation satellite system
GPS global positioning system (one constellation of GNSS)
ISE infrastructure elements
NTP network time protocol
NTRIP networked transport of RTCM via Internet protocol
OWD one-way delay / end-to-end delay
PGRS proving ground reference system
PTP precision time protocol
RPM reference point marker (geographic reference point on the proving ground)
RTK real time kinematic
SCT soft crash targets
SOW second of week (in respect to GPS time)
SV subject vehicle, also known as VUT
TAI international atomic time
TCP transmission control protocol – connection oriented communication between a server and
client
TSV traffic simulation vehicles
TRUE equal to 1 in bitwise operation
UDP used datagram protocol - connectionless communication model
UTM universal transverse mercator (a two-dimensional Cartesian coordinate system for locations
on the surface of the Earth)
VUT vehicle under test
WGS84 World geodetic system 1984
5 Test scenario illustration
The illustration of a test scenario in Figure 2Figure 2 is used as an example to explain a possible test scenario
with various test objects. The test objects present in the example scenario are categorised in types and sub
types in Table 1Table 1. The example does not include all possible test objects and scenarios referred to in
this document.
To be able to achieve the following scenario, several different mechanisms can be used to control and monitor
all different test objects, which will be described later in this document. Some or all test objects can be
controlled by a control centre (CC) but may also be controlled by a safety driver or by an integrated controller.
All test objects are always monitored by the CC.
Privileged
ISO/FDIS 22133:2025(en)
A test scenario is normally described in a story board or segment description.
Table 1 — Test object type categorization example
Test object type Test object subtype Illustration
Active infrastructure elements (A-ISE)

Stationary test objects
Passive infrastructure elements (P-ISE)

Object controlled/monitored by the CC (TSV/SCT)

Moveable test objects
Subject vehicle (SV/VUT)
Figure 2 — Example of test scenario
Privileged
ISO/FDIS 22133:2025(en)
6 General requirements and recommendations
6.1 Function overview
Several techniques and methods used for function and safety testing of autonomous moving test objects are
covered by this document and listed below:
a) a) test scenario execution,
b) b) static and dynamic trajectory following,
c) c) trigger and actions,
d) d) adaptive synchronization points (leader/follower),
e) e) remote control driving,
f) f) object-to-object communication,
g) g) safety features:
— — emergency stop,
— — arm/disarm,
— — time synchronization,
— — geofencing,
— — centralized control.
6.2 Test object coordinate system
6.2.1 Vehicle
Vehicle coordinate system orientation shall follow ISO 8855. See Figure 3Figure 3.
If not otherwise stated, the geometrical centre which is the centre of the bounding box of the test object
projected on the ground is used as the origin of the coordinate system.
Privileged
ISO/FDIS 22133:2025(en)
NOTE ψt is the rotation about the zt axis.
Figure 3 — Vehicle reference coordinate system (Source: ISO 19206-3:2021, Figure 2)
6.2.2 Moveable test objects other than vehicle
6.2.2.1 Bicyclist
Origin is the centre of pedal crankshaft, projected on the ground, see Figure 4Figure 4 (see also ISO 19206-
4:2020, Figure A.1).
Privileged
ISO/FDIS 22133:2025(en)
Figure 4 — Bicyclist reference coordinate system
6.2.2.2 Pedestrian
Origin is the centre between the hips, projected on the ground, see Figure 5Figure 5 (see also ISO 19206-
2:2018, Figure A.1).
Privileged
ISO/FDIS 22133:2025(en)
Figure 5 — Pedestrian reference coordinate system
6.2.2.3 Airborne test objects
For test objects not located directly on the ground of the test area such as drones or other aircrafts, the origin
shall not be projected on the ground but on the correct altitude/height on the z-axis, see Figure 6Figure 6.
Privileged
ISO/FDIS 22133:2025(en)
Figure 6 — Aerial test object reference coordinate system
6.2.2.4 Other
The origin on the geometrical centre of the test object is shown in Figure 7Figure 7.
Privileged
ISO/FDIS 22133:2025(en)
Figure 7 — Other geometrical test object reference coordinate system
6.3 Test scenario coordinate system
6.3.1 Background info: tectonic/continental plate drift
Test object trajectory planning shall take place within a PGRS, proving ground reference system, which is not
affected by any creeping or sudden tectonic movements, but referenced to a local reference point.
EXAMPLE In Europe, the absolute movement of the tectonic plate as whole is about 1 cm / year, in the Pacific area
[ [15]]
values of 10 cm / year are known 0 and after earthquakes sudden significant shifts along faults within the tectonic
[ ][ [11][12] ]
plate, and/or its margins are observed 0 0 . .
WGS84 (as an output of uncorrected GNSS) shall not be used. If used, the infrastructure elements would
"move" against the planned trajectory due to the continental plate drift, resulting in significant risk of collision
between test objects.
6.3.2 Coordinate system – Tests on proving ground
Test objects shall report their position in the MONR-message with local cartesian coordinates (PGRS) in (x,y,z)
in relation to the local test origin defined in the OSEM message. Only one test origin shall be defined per test.
A top-down view of the coordinate system can be found in Figure 8Figure 8 where the yaw angle Ψ (psi) is
measured counterclockwise in degrees, starting with 0° pointing to the local x-direction. If rotation of the
origin is set to 0°, the PGRS system is defined as a cartesian local coordinate system with its x-axis to east, y-
Privileged
ISO/FDIS 22133:2025(en)
axis to true north and z-axis upwards (ENU). Rotation of the origin is a parameter available in the OSEM
message.
NOTE GNSS heading is usually measured clockwise in degrees, starting with 0° pointing to north. The relation
between yaw and heading is then Ψ = 90° - heading (when the rotation of the origin zero).

Key
X east
Y north
1 origin
Figure 8 — RPM in PGRS and yaw explanation (rotation is zero)
Privileged
ISO/FDIS 22133:2025(en)
6.3.3 Coordinate system – Test on other test areas
For larger areas, or areas outside a limited test area, a global coordinate system using UTM/ECEF shall be
used.
Test objects shall report their position in the MONR2-message with global, absolute, coordinates.
Depending on where (on which tectonic plate) the test is executed, a different plate-drift-free coordinate
system shall be used according to Table 2Table 2.
Table 2 — Geodetic systems on specific tectonic plates
Geographical location of test Geodetic system
Eurasian plate ETRS89
North American plate NAD83
South American plate ITRF2000
African plate ITRF2000
Australian plate ITRF2000
Indian plate ITRF2000
Arabian plate ITRF2000
Other plates/fallback /local GNSS correction data WGS84, locally corrected (see below)
The CC shall transmit information to the test objects about the base coordinate system that shall be used for
the test scenario. If this is not applicable or if the CC did not send the information, then the fallback solution is
to use either:
— — WGS84 (for tests as described in 6.3.36.3.3),), or
— — a local coordinate system (for tests as described in 6.3.26.3.2).).
It is recommended to use a local GNSS reference station to provide RTK correction data, which is located close
to the proving ground’s local RPM, using as its initial position the local coordinates being corrected by tectonic
plate drift (i.e. taken from the same map, which also provides the coordinates of all other infrastructure
elements during the traffic scenario).
This local GNSS reference station shall transmit its RTK correction data to each participating moveable test
object. This guarantees that all moveable test objects are located within the same, tectonic plate drift invariant
coordinate system.
6.4 Time requirements
6.4.1 General time requirements
All test objects and the CC shall have the same understanding and perception of time. Therefore, it is important
that time representation, time resolution, time accuracy and time synchronisation is commonly shared.
6.4.2 Time representation
GPS time shall be used as time base. GPS time is monotonous and does not get affected by leap seconds.
NOTE UTC time is affected by leap seconds, hence is not monotonous and not useable for surveying and control
applications with high timing precision requirements.
Privileged
ISO/FDIS 22133:2025(en)
6.4.3 Absolute time
To represent absolute time, the time is defined as the number of elapsed milliseconds since GPS time began
th th
on midnight (00:00:00 UTC) between January 5 and January 6 , 1980.
NOTE The difference between GPS-time and TAI-time is always 19 s (TAI is always 19 s ahead of GPS).
TAI is currently 37 s ahead of UTC (as to date 2025-06-30).
GPS is currently 18 s ahead of UTC (as per date 2025-06-30).
6.4.4 Relative time
The GPS second of week (SOW) shall be used when representing relative time (e.g. during test execution). The
GPS week starts at midnight (00h00m00s GPS time) between Saturday and Sunday and consists of 604 800 s
[ [16] ]
0 . .
All transmitted times shall be in relation to the start of the given GPS week.
6.4.5 Time resolution
When using 32 bits for representing the GPS seconds of week in milliseconds, the time resolution for
transmission is 0,25 ms. See Error! Reference source not found.Formula (1).
(1)
604 800×1 000×4=2 419 200 000 𝑞𝑢𝑎𝑟𝑡𝑒𝑟𝑠 𝑜𝑓 𝑚𝑠 𝑝𝑒𝑟 𝑤𝑒𝑒𝑘 (1)
Representation:
GPSSecondOfWeek::=INTEGER
{startOfWeek(0),oneMillisecAfterStartOfWeek(4),unavailable(4294967295)}
(0… 2419199999)
NOTE 1 For each millisecond since start of the week, the GPSSecondOfWeek-value increases with 4 due to the
0,25 ms resolution.
NOTE 2 The unavailable value 4294967295 (dec) corresponds to 0xFFFFFFFF (hex).
EXAMPLE The GPS week roll-over behaviour for the GPSSecondOfWeek looks like this at midnight between
Saturday and Sunday:
GPSSecondOfWeek=2419199996
Saturday@23:59:59,99900
GPSSecondOfWeek=2419199997
Saturday @23:59:59,99925
GPSSecondOfWeek=2419199998
Saturday @23:59:59,99950
GPSSecondOfWeek=2419199999
Saturday @23:59:59,99975
GPSSecondOfWeek=0
Sunday@00:00:00,00000
GPSSecondOfWeek=1
Sunday @00:00:00,00025
GPSSecondOfWeek=2
Sunday @00:00:00,00050
GPSSecondOfWeek=3
Sunday @00:00:00,00075
GPSSecondOfWeek=4
Sunday @00:00:00,00100
Privileged
ISO/FDIS 22133:2025(en)
…
GPSSecondOfWeek=4000
Sunday @00:00:01
…
GPSSecondOfWeek=240000
Sunday @00:01:00
6.4.6 Time accuracy (and precision)
Control centre and test object internal clocks shall not deviate from the GPS second of week more than:
— — ±125 µs for moveable test objects;
— — ±10 ms for infrastructure elements (or slow-moving test objects).
This requires that each test object uses the GPS time for its own time synchronisation or uses a network time
server (PTP / NTP) for time synchronisation.
6.4.7 Time synchronization
The time reference for test objects as well as for the CC shall be GPS time. This time is available to all
participants operating their own GPS receiver and having sufficient GPS observations available. The GPS
observations shall preferably be direct communication with satellites, but for GPS-denied areas a GPS-
repeater may be used as a substitute.
For moving test objects in GPS-denied areas (such as indoor) and if the duration of loss of GPS time is outside
the stability duration of the clock on the test object shall the time be retrieved from the PTP-server hosted by
the CC.
For static or slow-moving test objects in GPS-denied areas (such as indoor), and if the duration of loss of GPS
time is outside of the stability duration of the clock on the test object, the time shall be retrieved from the NTP
or PTP-server hosted by the CC.
If different time sources are available to the CC and test objects they shall retrieve their time according to the
following priority, further visualised in Figure 9Figure 9::
a) a) GNSS source (GPS time),
b) b) PTP,
c) c) NTP.
If no time source is currently available, unavailable shall be sent in messages transmitting time stamped
information.
NOTE PTP is using UDP port 319 and 320. NTP is using UDP port 123.
Privileged
ISO/FDIS 22133:2025(en)
Key
1 GNSS source (GPS time) 4 control centre
2 PTP 5 test object
3 NTP
1 GNSS source (GPS time)
2 PTP
3 NTP
4 control centre
5 test object
Figure 9 — Schematic view of time source priority and NTP/PTP service allocation
6.4.8 Date synchronization
During configuration/setup of a test, the CC shall transmit the current date, using the test object setting
(OSEM)-message to the test objects. The test object shall use this time as reference for the test to be executed.
The following date and time information shall be included in the message:
[Date, GPSWeek, GPSSecondOfWeek, LeapSeconds]
The date format shall be in accordance with the ISO 8601 series (YYYYMMDD).
The CC shall transmit the week-roll-over message to the test objects if a new GPS-week is entered during
execution of a test. This message is called GPS second of week roll over message – SOWM.
6.4.9 Network delay
[13]
A one-way-delay (OWD) shall be determined after the network has been set up. The determination inside
the network is easy because the true time reference is distributed via PTP/NTP (for test objects without GNSS
receiver) or the OSEM. Each data packet, being transmitted between any test object and the control centre,
contains in its header a timestamp of the time when the data content has been generated.
It is important to recognize, that the OWD is not important for the application, if the total time between data
generation on the sender’s site and data receiving at the other site is lower than a defined threshold. This
threshold is defined, for example, by the heartbeat timeout.
Privileged
ISO/FDIS 22133:2025(en)
The heartbeat or monitor packets can therefore be used directly for an online monitoring of the over-all
latencies of the network.
Current measured network delay can be retrieved from the test object (or from CC) by reading the network-
delay-parameter (if available). Other network parameters may also be retrieved. All available parameters are
specified in the device interface description XML file (DIDX).
6.5 Communication requirements, recommendations and permissions
The following requirements, recommendations and permissions apply.
a) a) Network IPs shall be used for communication among the CC and test objects. The CC and all
test objects being part of the same traffic scenario shall operate on the same logical IP network and being
addressable (able to communicate with each other).
b) b) Logical sub-networks should be supported to allow the execution of several independent traffic
scenario tests on the same proving ground without conflicts.
c) c) Test object status collection provides the CC with current information about all available test
objects, such as battery level, current faults, etc.
d) d) The subject vehicle shall support sending monitor information to the CC.
e) e) A traffic scenario may include one or more subject vehicles in a single scenario.
f) f) Each test object shall be able to report its capabilities via request from the CC.
g) g) Multicasting of information may be applied if the underlaying network and all entities in the
test setup support this.
h) h) Test objects shall be capable of reading the heartbeat message (see 12.3.612.3.6)) and send
monitor message (see 12.3.712.3.7).).
Structure and package of data are done according to Figure 10Figure 10. A message is the highest element
consisting of header, content data and footer. This is called flexible message structure.
A message can contain one or more content(s). Each message can be built up to contain dynamic content,
meaning that addition to a defined message is possible. Pre-defined content is specified further down in this
document, and addition to this should be used with care, since it may affect the latency of communication
timing expected.
Privileged
ISO/FDIS 22133:2025(en)
Key
1 message header metadata: ID, counter, version, length, etc.
2 one or several message content(s) containing: valueID, length, data
3 message footer: CRC checksum
1 message header metadata: ID, counter, version, length, etc.
2 one or several message content(s) containing: valueID, length, data
3 message footer: CRC checksum
Figure 10 — Message structure
Privileged
ISO/FDIS 22133:2025(en)
7 Safety and risk assessment requirements and recommendations
7.1 General
The control centre shall support safety monitoring of moveable test objects. This includes support for
emergency stop of all moveable test objects.
The following requirements, recommendations and permissions apply:
a) a) the system should support a safe low-speed mode for remote transport;
b) b) the system should support a safe low-speed mode for safe return/re-position;
c) c) the system shall support an arming function (ready to start test – active);
d) d) the system shall support an emergency stop;
e) e) the system may support soft stop – controlled braking – also called normal stop.
If a test object receives an emergency stop signal or the condition for initiating an emergency stop is fulfilled,
the test object shall stop as quickly as possible without considering extensive usage of tires. This type of
stopping should only be used for emergency stop, compared to a soft stop where test object can use a longer
period for stopping, if preferred.
7.2 Local test object fence and global geofence
7.2.1 Common requirements and recommendations
The control centre as well as all moveable test objects shall have support to enforce one or more virtual fences.
For every virtual fence an appropriate function shall be supported, for example low speed fence, stop fence,
shutdown fence and a geofence.
Virtual fences are used as criteria of whether a moveable test object meets certain safety requirements.
The global geofence defines the area on the proving ground (or on the public road or other test area)
where the moveable test objects are allowed, or not allowed, to move.
The local test object fence is defined individually for each moveable test object and defines criteria
(such as position, speed, type of test) which shall be fulfilled by each moveable test object in respect to its
trajectory.
NOTE Local test object fence is the maximum allowed deviation from the intended path.
7.2.2 Global geofence
The virtual boundary around the allowed test area is called global geofence. The test object shall evaluate the
position of itself in real-time against the geofence. If the test object exceeds (enters or exits) the boundary, a
related measure shall be executed, stop and request an abort. The control centre may additionally evaluate
the position of each test object against the geofence.
7.2.3 Local test object fence
The CC shall inform moveable test objects how much deviation from their trajectories is allowed. This
information is sent to the test object before the test is executed, but in principle the local fence can also depend
Privileged
ISO/FDIS 22133:2025(en)
on specific situations and scenarios and the fence-tolerances may be updated during a running test scenario.
Figure 11Figure 11 illustrates a combination of both global and local virtual fences during a test scenario.

Key
Privileged
ISO/FDIS 22133:2025(en)
1 test object 1
2 test object 1 – local test object fence
3 test object 1 – trajectory
4 global geofence
5 test object 2
6 test object 2 – local test object fence
7 test object 2 – trajectory
1 test object 1
2 test object 1 – local test object fence
3 test object 1 – trajectory
4 global geofence
5 test object 2
6 test object 2 – local test object fence
7 test object 2 – trajectory
Figure 11 — Test scenario with geofence and local test object fences
The test object trajectory deviation shall not exceed the maximum value(s) as sent in the configuration
message for local fences (e.g. MaxWayDeviation, MaxLateralDeviation, MaxYawDeviation). If
such deviation is identified by the test object, it shall abort the test, it shall perform an emergency stop action
and send an requestEmergencyStop to the control centre.
Figure 12Figure 12 illustrates the lateral path deviation in the context of geofencing.
Privileged
ISO/FDIS 22133:2025(en)
Privileged
ISO/FDIS 22133:2025(en)
Key
1 planned path
2 local test object fence
3 lateral path deviation
YG, XG ground (fixed) coordinate axes in which the planned path is defined
1 planned path
2 local test object fence
3 lat
...