ISO/TS 22133:2023

TECHNICAL ISO/TS
SPECIFICATION 22133
First edition
2023-03
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
Reference number
© ISO 2023
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents
Introduction. vii
Scope . 1
Normative references . 1
Terms and definitions . 1
Abbreviated terms . 4
Test scenario illustration . 5
General requirements and recommendations . 6
6.1 Function overview . 6
6.2 Test object coordinate system . 6
Vehicle . 6
Moveable test objects other than vehicle . 7
6.3 Test scenario coordinate system . 9
Background info: tectonic/continental plate drift . 9
Coordinate system – Tests on proving ground . 9
Coordinate system – Test on other test areas . 10
6.4 Time requirements . 10
General time requirements . 10
Time representation . 10
Absolute time . 10
Relative time . 11
Time resolution . 11
Time accuracy (and precision) . 11
Time synchronization . 11
Date synchronization . 12
Network delay. 12
6.5 Communication requirements and permissions . 13
Safety and risk assessment requirements and recommendations . 14
7.1 General . 14
7.2 Local test object fence and global geofence . 15
Common requirements and recommendations . 15
Global geofence . 15
Local test object fence . 15
Communication security requirements . 17
Architecture and interfaces . 17
9.1 General . 17
9.2 Control centre and test object states . 18
General . 18
Test objects state diagram . 18
Test object state change conditions . 20
Control centre state diagram . 20
Control centre state change triggers . 21
9.3 Communication setup . 22
General . 22
Test object discovery . 22
TCP communication setup (control channel) . 22
UDP communication setup (process channel) . 23
File transfer protocol (FTP) . 25
9.4 Control functionalities . 25
Automated and non-automated drive. 25
Remote-control manoeuvring . 26
Trajectory and scenario-based testing . 28
10.1 Introduction to trajectory and scenario-based testing . 28
10.2 Static trajectories . 28
10.3 Dynamic trajectories . 28
10.4 Scenario-description languages . 29
Functional requirements . 29
11.1 Device interface description XML (DIDX) . 29
11.2 Control centre requirements and recommendations . 30
11.3 Stationary test object requirements. 30
11.4 Moveable test object requirements and recommendations . 30
11.5 Functions with behaviour description . 31
Arm and disarm test object . 31
Start test . 32
Emergency stop of test scenario (initiated by the CC) . 33
Emergency stop of test scenario (upon request from test object) . 34
Normal stop of test scenario . 35
Download static (pre planned) trajectories . 36
Cyclic monitor and heartbeat . 36
Adaptive synchronization point . 36
Remote-control manoeuvring . 39
Trigger and action . 40
Interface requirements . 41
12.1 General . 41
12.2 Message . 42
Message structure . 42
Sequential byte order . 42
Message header . 43
Message content . 44
Message footer . 45
Protocol tunnel . 45
Vendor-specific messages . 46
12.3 Collective message overview . 46
Trajectory object message - TRAJ (MsgID 0x0001). 48
Object setting message – OSEM (MsgID 0x0002) . 51
Object state change request message – OSTM (MsgID 0x0003) . 58
Start message -STRT (MsgID 0x0004). 58
Heartbeat message – HEAB (MsgID 0x0005) . 59
Monitor message – MONR (MsgID 0x0006). 61
Monitor message 2 – MONR2 (MsgID 0x0007) . 64
GPS second of week roll over message – SOWM (MsgID 0x0008) . 66
Synchronization point configuration message – SYPM (MsgID 0x000B) . 67
Master time to synchronization point message -MTSP (MsgID 0x000C) . 68
Remote-control manoeuvring message – RCMM (MsgID 0x000A) . 68
Remote-control manoeuvring message 2 – RCMM2 (MsgID 0x0016). 71
Trigger configuration message – TRCM (MsgID 0x0021) . 73
Action configuration message – ACCM (MsgID 0x0022) . 76
Trigger event occured message – TREO (MsgID 0x0023) . 78
Execute action message – EXAC (MsgID 0x0024) . 79
Cancel or delete trigger and action – CADE (MsgID 0x0025) . 80
Action performed message – APEM (MsgID 0x0026). 80
Discovery request DREQ (MsgID 0x0010) . 81
iv © ISO 2023 – All rights reserved

Discovery response DRES (MsgID 0x0011) . 81
Parameter request message – PREQ (MsgID 0x0012) . 82
Parameter response message PRES (MsgID 0x0013) . 83
GeoFence message GEOF (MsgID 0x0009) . 84
General data message - GEDM (MsgID 0x0017) . 85
General response message - GREM (MsgID 0x0018). 87
Annex A (normative) Trajectory file format . 89
Annex B (informative) Message footer checksum calculation . 92
Annex C (informative) Trigger and action . 95
Annex D (normative) Device interface description XML (DIDX) . 100
Bibliography . 102

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO
collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on
the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 33,
Vehicle dynamics and chassis components.
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 © ISO 2023 – All rights reserved

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 may 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.
TECHNICAL SPECIFICATION ISO/TS 22133:2023(E)
Road vehicles — Test object monitoring and control for active
safety and automated/autonomous vehicle testing — Functional
requirements, specifications and communication protocol
Scope
This document specifies requirements, procedures and message formats for controlling and monitoring
of test targets, used for testing of active safety functions and autonomous vehicles.
The 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.
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
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
test object
entity, as defined in ISO 34501, part of a traffic scenario under monitoring and control by the control
centre (3.5)
Note 1 to entry: Two types of test objects exist; moveable and stationary test objects (3.4).
Note 2 to entry: A test object can have several attributes, see Figure 1.
Relations and inheritance view
3.2
subject vehicle
SV
vehicle to be tested with the system
Note 1 to entry: The subject vehicle, SV, is also known as vehicle under test, VUT.
Note 2 to entry: There may be one subject vehicle (standard setup) or a set of subject vehicles in the specific traffic
scenario.
Note 3 to entry: The subject vehicle may be under safety-driver control and/or under control-centre (3.5) control.
Note 4 to entry: The subject vehicle is an instantiated test object (3.1) in either type of: stationary test object (3.4)
or moveable test object (3.3).
3.3
moveable test object
object under control by the control centre (3.5) which has the capability of activation of physical
movement
Note 1 to entry: The subject vehicle (3.2) is typically a moveable test object.
Note 2 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) 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.
EXAMPLE Traffic simulation vehicles, also known as traffic support vehicles (TSV), soft crash targets (SCT).
3.4
stationary test object
part of a traffic scenario, which is not moveable but may be under control by the control centre (3.5)
Note 1 to entry: A VUT may also be a stationary test object.
Note 2 to entry: Different stationary test objects can exist. Normally they are divided in to two groups: active and
passive infrastructure elements (ISE).
EXAMPLE Active ISE: traffic lights, lighting, rain/snow/fog simulator. Passive ISE: elements of construction
area, road signs, guardrails, etc.

3.5
control centre
CC
centralized or distributed service for test-object (3.1) control and safety monitoring including provision of
communication services to the test objects

2 © ISO 2023 – All rights reserved

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
lateral path deviation
position error of the target vehicle relative to the planned path (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
trajectory
path (3.6) where a test object (3.1) is or is intended to move along including test-object dynamics (i.e.
including timing)
Note 1 to entry: A trajectory contains a path and additionally the test-object dynamics (such as time, yaw, velocity,
acceleration, etc.) 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
static trajectory
offline pre-planned trajectory (3.8) including test-object (3.1) position and test-object motion dynamics
for a single moveable test object (3.3) as part of the traffic scenario
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) extracts information from the trajectory file and builds a trajectory
message, TRAJ, that is understandable by the test object.
3.10
dynamic trajectory
trajectory (3.8) which at the start of the scenario execution is not known by the test object(s) (3.1) nor the
control centre (CC) (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).
Note 3 to entry: In the case where the test object(s) or other systems (e.g. a simulation environment) are generating
the dynamic trajectory this information shall be gated by sending to the CC and then from the CC to the test object.
3.11
test scenario
scenario, as defined in ISO 34501, including all test objects (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), and a map of the test area.
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) to generate
trajectories (3.8) (static or dynamic) by the control centre (3.5) or at a test object (3.1).
[17]
EXAMPLE: Test scenario (3.11) described using OpenSCENARIO or iSCAML .
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) (e.g. road signs and markings)
Note 1 to entry: A scenery description can be used in combination with a scenario description (3.12) to generate
trajectories (3.8) (static or dynamic) by the control centre (3.5) or at a test object (3.1).
EXAMPLE: Temporary lane-setup on a proving ground, described using OpenDRIVE.
3.14
safety speed limit
maximum allowed speed when repositioning moveable test objects (3.3) while not participating in
ongoing test
Note 1 to entry: The test object (3.1) is manually driven with the remote-control functionality or automatically
driven when outside the test execution phase.
3.15
device ID
unique identifier for each entity 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
message gating
mechanism to gate messages from a sender to a receiver defined by the transmitter ID and receiver ID in
the message header
Note 1 to entry: Control-centre (3.5) gating messages from one entity to another do not alter the transmitter ID in
the process of message gating.
Abbreviated terms
ASP Adaptive Synchronization Point

DIDX Device Interface Description XML

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 (physical 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
4 © ISO 2023 – All rights reserved

TAI International Atomic Time
TCP Transmission Control Protocol – Connection oriented communication between a
server and client
TSV Traffic Simulation Vehicles
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
CC Control Centre
Test scenario illustration
The illustration of a test scenario in Figure 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 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 CC but may also be controlled by a safety driver or by an integrated controller. All
test objects are always monitored by the CC.
A test scenario is normally described in a story board or segment description.
Table 1 — Test object type categorization example
Test object Test object sub type Illustration
type
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)
Example of test scenario
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) test scenario execution,
b) static and dynamic trajectory following,
c) trigger and actions,
d) adaptive synchronization points (master/slave),
e) remote control driving,
f) object-to-object communication,
g) safety features:
— emergency stop,
— arm/disarm,
— time synchronization,
— geofencing,
— centralized control.
6.2 Test object coordinate system
Vehicle
Vehicle coordinate system orientation shall follow ISO 8855. See Figure 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.
6 © ISO 2023 – All rights reserved

NOTE ψ is the rotation about the z axis.
t t
Vehicle reference coordinate system (Source: ISO 19206-3:2021, Figure 2)
Moveable test objects other than vehicle
Bicyclist
Origin is the centre of pedal crankshaft, projected on the ground, see Figure 4 (see also ISO 19206-4:2020,
Figure A.1).
Bicyclist reference coordinate system
Pedestrian
Origin is the centre between the hips, projected on the ground, see Figure 5 (see also ISO 19206-2:2018,
Figure A.1).
Pedestrian reference coordinate system
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 6.

Aerial test object reference coordinate system
Other
Origin on the geometrical centre of the test object, see Figure 7.

Other geometrical test object reference coordinate system
8 © ISO 2023 – All rights reserved

6.3 Test scenario coordinate system
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
[15]
area values of 10 cm / year are known and after earthquakes sudden significant shifts along faults within the
[11] [12]
tectonic plate, and/or its margins are observed .
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.
Coordinate system – Tests on proving ground
For tests executed on proving ground areas, the exchange of coordinates between the CC and test objects
shall use a local cartesian ENU (east-north-up, where the north direction is defined as true geographical
north if the rotation of the PGRS is equal to 0) coordinate system. Test objects shall report their position
in the MONR-message with local cartesian coordinates (PGRS) in millimetres (x,y,z) in relation to the local
reference point marker (RPM). Only one RPM shall be defined per test.
The coordinates of the RPM can be defined as the origin (values 0 / 0 / 0) which gives the PGRS system
defined as a cartesian local coordinate system with its x-axis to east, y-axis to true north and z-axis
upwards (ENU). A top-down view of the coordinate system can be found in Figure 8 where the yaw angle
Ψ (psi) is measured counter clockwise in degrees, starting with 0° pointing east.
The heading of a test object is measured clockwise in degrees, starting with 0° pointing to local north at
the origin (heading = 90° - Ψ).
y (north)
Ψ
(x,y,z)
origin
RPM in PGRS and yaw explanation

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 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.3), or
— A local coordinate system (for tests as described in 6.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
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.
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.
Absolute time
To represent absolute time, the time is defined as the number of elapsed milliseconds since GPS time
th th
began 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).
10 © ISO 2023 – All rights reserved

TAI is currently 37 s ahead of UTC (as to date 2021-12-31).
GPS is currently 18 s ahead of UTC (as per date 2021-12-31).
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
[16]
604800 s .
All transmitted times shall be in relation to the start of the given GPS week.
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 Formula (1).
604 800 × 1 000 × 4 = 2 419 200 000 quarters of ms per week (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:
Saturday@23:59:59,99900 GPSSecondOfWeek=2419199996
Saturday @23:59:59,99925 GPSSecondOfWeek=2419199997
Saturday @23:59:59,99950 GPSSecondOfWeek=2419199998
Saturday @23:59:59,99975 GPSSecondOfWeek=2419199999
Sunday@00:00:00,00000 GPSSecondOfWeek=0
Sunday @00:00:00,00025 GPSSecondOfWeek=1
Sunday @00:00:00,00050 GPSSecondOfWeek=2
Sunday @00:00:00,00075 GPSSecondOfWeek=3
Sunday @00:00:00,00100 GPSSecondOfWeek=4
…
Sunday @00:00:01 GPSSecondOfWeek=4000
…
Sunday @00:01:00 GPSSecondOfWeek=240000

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.
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 9:
a) GNSS source (GPS time),
b) PTP,
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.

Key
1 GNSS source (GPS time)
2 PTP
3 NTP
Schematic view of time source priority and NTP/PTP service allocation
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.
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.
12 © ISO 2023 – All rights reserved

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.
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 and permissions
The following requirements and
...