IEC PAS 61174-1:2021

IEC PAS 61174-1 ®
Edition 1.0 2021-03
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
colour
inside
Maritime navigation and radiocommunication equipment and systems –
Part 1: Route plan exchange format (RTZ) – General requirements, methods of
testing and required test results

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform IEC online collection - oc.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always
committee, …). It also gives information on projects, replaced have access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 000 terminological entries in English
details all new publications released. Available online and
and French, with equivalent terms in 18 additional languages.
once a month by email.
Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc

If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC PAS 61174-1 ®
Edition 1.0 2021-03
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
colour
inside
Maritime navigation and radiocommunication equipment and systems –

Part 1: Route plan exchange format (RTZ) – General requirements, methods of

testing and required test results

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 47.020.70; 47.060 ISBN 978-2-8322-9482-6

– 2 – IEC PAS 61174-1:2021 © IEC 2021
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviated terms . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms . 7
4 Requirements . 8
4.1 General . 8
4.2 RTZP data container . 9
4.3 High-level description of the RTZ format . 10
4.4 Adaption to third-party extensions and handling of optional data . 10
4.4.1 Generic idea . 10
4.4.2 Unique identification of a waypoint. 10
4.4.3 Creation of new waypoints . 11
4.4.4 Change of geographic data for a waypoint . 11
4.4.5 Waypoint removal . 11
4.4.6 Waypoint modification . 11
4.5 Detailed RTZ format description . 11
4.5.1 File components . 11
4.5.2 Route node description . 11
4.5.3 RouteInfo node description . 12
4.5.4 Waypoints node description . 13
4.5.5 DefaultWaypoint node description . 13
4.5.6 Waypoint node description . 14
4.5.7 Storing date and time for legs . 15
4.5.8 Schedules node description . 16
4.5.9 Schedule node description . 16
4.5.10 Extensions node description . 18
4.5.11 Extension node description . 19
4.6 XML schema to be met by RTZ route files . 19
4.6.1 RTZ schema version 1.0 . 19
4.6.2 RTZ schema version 1.2 . 19
4.7 Basic RTZ v1.0 route example . 19
4.8 RTZ v1.2 test files . 21
5 Methods of testing and required test results . 21
5.1 General . 21
5.2 User manual . 21
5.3 Schema compliance . 21
5.4 RTZP data container . 22
5.5 Revision attribute . 22
5.6 Schedules . 22
5.7 Manufacturer extensions and handling of optional data . 23
5.8 Default data . 23
5.9 Application of leg element values . 23
Annex A (normative) RTZ schema version 1.2 . 24

Annex B (normative) RTZ v1.2 test files . 48
B.1 RTZ v1.2 with minimum mandatory elements . 48
B.2 RTZ v1.2 with leg elements . 48
B.3 RTZ v1.2 with all optional elements and attributes . 48
B.4 RTZ v1.2 not fully conforming to schema (errors) . 48
B.5 RTZ v1.2 in RTZP data container . 49
B.6 RTZ v1.2 with extensions from 3rd party manufacturer . 49
B.7 RTZ v1.2 using revision attribute. 49
B.8 RTZ 1.2 with default waypoint . 49
Annex C (informative) UML model of the route plan exchange format (RTZ v.1.2) . 50
Annex D (informative) Comparison of schema versions . 51
Bibliography . 52

Figure 1 – Description of route plan – Distance between WP 2 and WP 3 . 8
Figure 2 – Description of route plan – Leg parameters belonging to WP 3 . 9

Table D.1 – Schema changes . 51

– 4 – IEC PAS 61174-1:2021 © IEC 2021
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
MARITIME NAVIGATION AND RADIOCOMMUNICATION
EQUIPMENT AND SYSTEMS –
Part 1: Route plan exchange format (RTZ) –
General requirements, methods of testing and required test results

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
A PAS is an intermediate specification made available to the public and needing a lower level
of consensus than an International Standard to be approved by vote (simple majority).
IEC PAS 61174-1 has been processed by IEC technical committee 80: Maritime navigation and
radiocommunication equipment and systems.
The text of this PAS is based on the This PAS was approved for publication
following document: by the P-members of the committee
concerned as indicated in the following
document
Draft PAS Report on voting
80/978/DPAS 80/986/RVDPAS
Following publication of this PAS, which is a pre-standard publication, the technical committee
or subcommittee concerned may transform it into an International Standard.

This PAS shall remain valid for an initial maximum period of 2 years starting from the publication
date. The validity may be extended for a single period up to a maximum of 2 years, at the end
of which it shall be published as another type of normative document, or shall be withdrawn.

IMPORTANT – The "colour inside" logo on the cover page of this document indicates that it
contains colours which are considered to be useful for the correct understanding of its
contents. Users should therefore print this document using a colour printer.

– 6 – IEC PAS 61174-1:2021 © IEC 2021
INTRODUCTION
A route plan exchange format RTZ was published as Annex S of IEC 61174:2015.
This route plan exchange format is intended be used for many purposes. For example it can be
used on board for route plan exchange between main and backup ECDIS, ECDIS and radar,
ECDIS and optimization systems, etc. Another example use is between ship and shore where
it can be used to inform the shore about the plan of the vessel, the shore can recommend a
route, the shore can optimize a route, etc.
This route plan exchange format is based on standardizing a single route plan. The application
level of the sender and receiver is assumed to be able to handle multiple route plans for use
cases which require availability of multiple routes, for example alternative route plans for the
same voyage or route plans for different purposes.
Since publication of IEC 61174:2015, typographical errors have been identified in the original
route plan exchange format. Issues relating to ambiguity in the underlying requirements have
also been identified. Testing has uncovered further issues, including (among others) route
import failures, highlighting a lack of robustness in the RTZ testing clauses specified in
IEC 61174:2015.
During the implementation of route exchange as part of a collaborative industry project, the Sea
Traffic Management (STM) Validation Project , an iteration of the RTZ XML schema, version
1.1, was developed in order to correct the errors that had been identified in version 1.0 and to
expand the schema to accommodate the project’s needs.
Further development has led to RTZ schema version 1.2 which incorporates schema version
1.1 and contains a further change by permitting extensions in the Leg element.
This PAS includes the following significant technical changes with respect to IEC 61174:2015:
• modifications to the body text of IEC 61174:2015 Annex S intended to correct typographical
errors, properly align the text with the original RTZ schema, and to add clarification and
remove ambiguity from the requirements;
• modifications to the testing clauses in IEC 61174:2015 6.9.2 to expand the existing tests for
route plan exchange by introducing testing clauses covering the full range of requirements
specified in IEC 61174:2015 Annex S;
• an updated RTZ schema to revised version 1.2 in order to expand the original schema and
to correct errors and weaknesses in the original schema.
Details of the substantive changes between version 1.0 and version 1.2 of the schema are given
in Annex D.
___________
https://www.seatrafficmanagement.info/projects/stm-validation/

MARITIME NAVIGATION AND RADIOCOMMUNICATION
EQUIPMENT AND SYSTEMS –
Part 1: Route plan exchange format (RTZ) –
General requirements, methods of testing and required test results

1 Scope
This PAS specifies requirements, methods of testing and required test results for route plan
exchange format (RTZ).
This PAS has been developed to improve interoperability between equipment implementing
route plan exchange format by addressing issues uncovered in the original RTZ specification
(Annex S of IEC 61174:2015), and in recognition of the fact that some manufacturers have
identified a pressing business need to implement an improved and expanded version of the
RTZ format.
This PAS is intended to complement the original RTZ specification. This PAS provides a revised
version 1.2 of the RTZ schema but retains the original version 1.0 of the schema unchanged.
The intention is that compliance with this PAS can be achieved without compromising
compliance with IEC 61174:2015.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 61174:2015, Maritime navigation and radiocommunication equipment and systems –
Electronic chart display and information system (ECDIS) – Operational and performance
requirements, methods of testing and required test results
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
No terms and definitions are listed in this PAS.
ISO and IEC maintain terminological 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.2 Abbreviated terms
ECDIS Electronic chart display and information system
EUT Equipment under test
– 8 – IEC PAS 61174-1:2021 © IEC 2021
4 Requirements
4.1 General
A route plan consists of waypoints. Each waypoint, except the first, contains information related
to the leg from the previous waypoint. Descriptions of route plans are shown in Figure 1 and
Figure 2. The route exchange format is a file containing an XML encoded version of the route
plan. The XML route exchange file shall use the extension .rtz. A description of the RTZ format
is given in 4.5. Examples of RTZ format routes are given in 4.7 and 4.8.
XML schema is provided for validation of the structure and content of the RTZ format route files.
Two versions of the RTZ schema are defined: version 1.0 (provided in Annex S of
IEC 61174:2015) and 1.2 (provided in Annex A of this PAS). By default, equipment shall export
routes using version 1.2 of the schema. Equipment shall allow the version 1.0 schema to be
selected for export. Equipment shall support the import of both version 1.0 and version 1.2
schemas. Validation shall be mandatory for files using the version 1.2 schema and optional for
files using the 1.0 schema. If an imported file fails to validate it shall not be used and an
indication of the reason for validation failure shall be provided. The user manual shall specify
the versions and optional attributes that are supported.
One of the differences between the version 1.0 and 1.2 schema is the renaming of the
SheduleElement type to ScheduleElement. In textual references, other than xml examples, this
PAS uses ScheduleElement to refer to both items.
NOTE 1 The requirements in this PAS can be applied not only to ECDIS, but also to software applications importing
routes from ECDIS or exporting routes to ECDIS. In order to achieve interoperability, manufacturers of non-ECDIS
software applications are strongly encouraged to apply the associated tests in this PAS.
NOTE 2 This route exchange format has some limitations for applicability due to the simple geometric mode used.
Application for latitudes above 70º may cause significantly different paths over the earth surface between two
systems. Application to long legs such as an ocean crossing is subject to differences in the exact path over the earth
surface.
NOTE 3 It is recommended that the receiver of the route exchange always performs a check against the chart
database and a geometry check before use for navigation purposes.
NOTE 4 Information in addition to the route exchange format will be necessary between third parties to assure the
level of accuracy and repeatability required for Track Control System purposes.
NOTE 5 RTZ version 1.1 was used by the European Union’s Sea Traffic Management project, but lacked the
optional Extensions in the Leg element.

The distance between waypoints is from WOL to WOL with zero “advance and transfer” or “forwarding distance”.
Figure 1 – Description of route plan – Distance between WP 2 and WP 3

Figure 2 – Description of route plan – Leg parameters belonging to WP 3
4.2 RTZP data container
RTZP data containers are standard ZIP archive files used to compress the size of the route
exchange files.
The RTZP data container file .rtzp stores a single XML file .rtz, which conforms to the XML
schema described in 4.6.
A single RTZP file shall be limited in compressed size to 10 MB.
Use of the RTZP data container is optional. When used without the RTZP data container the
filename extension of the route exchange shall be .rtz and when used with the RTZP data
container the extension shall be .rtzp. Within the RTZP data container the filename extension
of the route exchange shall be .rtz. The user manual shall specify whether the RTZP data
container is supported.
The filename of the RTZP data container shall be the same as the content of the attribute
routeName described in 4.5.3.
In addition to the .rtz file a number of free-format files may be placed in the RTZP data
container. The semantic data link between the XML nodes and files may be documented using
a HTTP like scheme "rtz://", where "" identifies a file name inside the RTZP data
container.
– 10 – IEC PAS 61174-1:2021 © IEC 2021
For example:

name="AuxRouteInfo-9674F26E-EAFB-4319-AE24-08D5BA69D895">
value="http://services.acme.com/auto_route/?id=3e891884e620970e5303fd2399427986"/>




4.3 High-level description of the RTZ format
The logical design of a route consists of three independent units:
• a block with general information about the route;
• a block with route geography (geometry) information which consists of blocks describing
individual legs. Legs are listed in the order they appear on the route;
• a block that contains a set of route schedules. Each block can be extended by manufacturers
to fit their needs.
Each block can be extended by manufacturers to fit their needs.
4.4 Adaption to third-party extensions and handling of optional data
4.4.1 Generic idea
Extended information in most cases refers to the geography (geometry) of a route.
It shall be possible to import and export RTZ files with extensions from different manufacturers.
4.4.2 Unique identification of a waypoint
Each waypoint in a route has a unique composite ’id’.
RTZ extensions shall use this composite identifier to link their data to the geography. This
allows an application that does understand the extension to identify when third-party software
has modified the related element (see 4.4.4).
The identifier consists of two parts:
• id, which allows the finding of a waypoint in the list; This ‘id’ is not intended to be a sequence
number (i.e. does not need to relate to the position of the waypoint in the route);
• revision, which allows the determination of modifications of a waypoint since the entry of
the data into a file extension.
id is an integer,
revision is a monotonically increasing integer.

4.4.3 Creation of new waypoints
After creation of the waypoint the revision attribute shall have the value of 0.
4.4.4 Change of geographic data for a waypoint
When the data of a Waypoint or associated Leg changes, including the addition of a
manufacturer extension, the software shall increase the revision number revision. This allows
third-party software that works with the extension to find out that the data to which it is
associated may no longer be valid.
4.4.5 Waypoint removal
When deleting a waypoint from a route, all the waypoint data including Leg and any Schedule
data associated with the removed Waypoint shall be deleted and the ids of other waypoints
within the route shall remain unchanged.
NOTE Deletion of the waypoint may result in schedules for other waypoints becoming invalid or being updated.
4.4.6 Waypoint modification
The data that software is not able to recognize (e.g. extensions and optional elements and
optional attributes) shall be written back into the modified file without modification.
The data that software is able to recognize (e.g. extensions and optional elements and optional
attributes known by the manufacturer) shall be handled as declared by the manufacturer. When
importing a route, manufacturer extension data that is recognized shall be checked (e.g. by
using the composite ‘id’ described in 4.4.2) and, where the application determines that
modifications by an external 3rd party application may have invalidated the data, appropriate
action shall be taken. The manufacturer shall declare the appropriate action to be taken which
will depend on the nature of the extension, and may range from removal of the extension to
maintaining it unchanged.
NOTE Modification of the waypoint can result in schedules becoming invalid or being updated.
4.5 Detailed RTZ format description
4.5.1 File components
The RTZ file consists of:
• the mandatory XML processing instruction, which allows the specification of the encoding
of string data;
• a root node, which includes the URIs of the namespaces used;
NOTE An example of a namespace is available in 4.6.
• the version attribute in the format "Major.Minor".
The file encoding shall be UTF-8.
A single RTZ file shall be limited in uncompressed size to 1 MB.
There shall be an indication to the user if file size constraint will be exceeded through
modification to route plan.
4.5.2 Route node description
This is the only "root" element of the RTZ file.
It has one mandatory attribute "version" that contains the version of the RTZ schema.

– 12 – IEC PAS 61174-1:2021 © IEC 2021
Version is specified as a combination of two numbers separated with a dot. The first number
corresponds to the major version. It is changed following significant modifications to the
document structure.
The second number corresponds to the minor version and indicates format changes that do not
affect compatibility.
The Route node consists of a sequence of the following child nodes:
• RouteInfo node that contains basic information on the route;
• Waypoints node that describes the geographical components of the route;
• Schedules node that describes calculated schedule and timing defined by a user;
• Extensions node that allows for extending the format to fit the particular needs of a
manufacturer.
4.5.3 RouteInfo node description
The RouteInfo node provides a place to store information related to the whole route.
Information is stored in the following attributes:
Attribute Description Format Status Comment
routeName name of the route String Mandatory
routeAuthor Author of route String Option
routeStatus Status of route String Option
Start of validity ISO 8601 Option
validityPeriodStart
period
Stop of validity ISO 8601 Option
validityPeriodStop
period
vesselName Ship’s name String Option
vesselMMSI Ship’s MMSI XXXXXXXXX Option
vesselIMO Ship’s IMO number XXXXXXX Option
Number of the String Option
vesselVoyage
voyage
vesselDisplacement Ship’s displacement Integer Option Unit: tons
vesselCargo Ship’s cargo Integer Option Unit: tons
XX.XX Option Metacentric height of the ship
for intended voyage.
vesselGM Metacentric height
Unit: metres
String Option Could be fixed speed, Lowest
Route is optimized
optimizationMethod Fuel Consumption, Fixed
to meet KPI
ETA
Ship’s max roll XX Option Unit: degrees
vesselMaxRoll
angle allowed
Ship significant XX.X Option Unit: metres
vesselMaxWave
wave height limit
Ship’s max wind XX.X Option Unit: metres
vesselMaxWind
speed limit
XX.X Option Unit: knots, Speed through
vesselSpeedMax Ship’s max speed
water
Ship’s preferred XX.X Option Unit: knots, Speed through
vesselServiceMin service speed water
window_min
Attribute Description Format Status Comment
Ship’s preferred XX.X Option Unit: knots, Speed through
vesselServiceMax service speed water
window_max
String Option
Cause of route
routeChangesHistory change, Originator
and Reason
For example:
vesselName=”ACME”
validityPeriodStart=”2014-01-03T03:15:00Z”
validityPeriodStop=”2014-01-06T10:15:00Z”
vesselMMSI=”xxxxxxxxx”
vesselVoyage =”xxxx”/>
Additionally, the node may contain child extensions.
4.5.4 Waypoints node description
The Waypoints node contains data related to the geometry of the route.
As minimum, it shall contain a sequence of Waypoint nodes that describe every leg of the route.
The order of the Waypoint nodes follows the order of the legs.
Before the sequence of Waypoint nodes it is possible to insert a DefaultWaypoint node, which
may be used to define default values of attributes for newly created legs and for legs with
attributes that have not been explicitly supplied except for the geometry data.
Additionally, the node may contain a child extensions node.
4.5.5 DefaultWaypoint node description
The DefaultWaypoint node allows the route file to provide a definition of default values of
attributes for newly created waypoints and legs. Additionally, it allows the definition of default
values of attributes for waypoints and legs where data has not been explicitly supplied. The
user manual shall specify whether the equipment uses the default waypoint to set defaults and,
if not, shall specify how defaults are set (e.g. using default settings set by the mariner on the
ECDIS).
For example:




If the DefaultWaypoint node is provided, then it may be used to provide values for attributes
for newly created waypoints and legs and shall be used to provide values for attributes for
waypoints and legs where data has not been explicitly supplied.

– 14 – IEC PAS 61174-1:2021 © IEC 2021
For example:

Defaults settings for all waypoints

geometryType="Loxodrome"/>


For this waypoint default settings
applied



For this waypoint user settings applied:
Port XTD = 0,5 NM

Starboard XTD = 0,4 NM
Turn radius = 0,3 NM
geometryType="Orthodrome"/>
Geometry type is orthodrome

4.5.6 Waypoint node description
The Waypoint node contains the geographical description of a leg between waypoints.
Information is stored in the following attributes:
Attribute Description Format Status Comment
It does not have to be equal
id Unique identifier Integer Mandatory
to the index of the waypoint
revision Waypoint revision Integer Mandatory Index of revision
name Waypoint String Option
radius Turn radius Real Option Unit: NM
position Geographic point GM_Point Mandatory Unit: degrees
Not required for the first
leg Leg attributes Option waypoint. Required for other
waypoints.
The Position node contains the latitude and longitude of the waypoint.
Attribute Description Format Status Comment
lat Latitude Real Mandatory Unit: degrees with decimal
lon Longitude Real Mandatory Unit: degrees with decimal

The Leg node contains attributes of the leg leading from the previous waypoint to the waypoint
that contains the leg node (see Figure 2).

Attribute Description Format Status Comment
starboardXTD Starboard XTD Real Option Unit: NM with decimal
portsideXTD Portside XTD Real Option Unit: NM with decimal
Planned Safety Unit: metres
safetyContour Real Option
contour
Planned Safety Unit: metres
safetyDepth Real Option
depth
loxodrome (= rhumb line) or
Geometry type of
geometryType Enumeration Option
leg
orthodrome (= great circle)
Lowest cruising Unit: knots, Speed over
speedMin Real Option
speed ground
Highest allowed Unit: knots, Speed over
speedMax Real Option
speed ground
Static Draught Unit: metres
draughtForward Real Option
Forward
draughtAft Static Draught Aft Real Option Unit: metres
Minimum UKC on Unit: metres
staticUKC Real Option
the leg
Minimum Dynamic Unit: metres
dynamicUKC Real Option
UKC on the leg
Unit: metres
masthead Height of masthead Real Option
Calculated from keel
Reporting Part of annotated route plan
legReport String Option
information
e.g. telephone / web / service
point
legInfo Nice to know String Option
Could be relevant in
approach to harbour or VTS
Notes regarding the
legNote1 String Option
ETD/ETA
legNote2 Local remarks String Option

If an optional attribute is absent the appropriate parameter may be taken from the element
DefaultWaypoint.
For the case when geometryType is absent, this attribute should be considered as “Loxodrome”.
Additionally, the node may contain a child extensions node.
4.5.7 Storing date and time for legs
Date and time parameters that are associated with the corresponding legs are stored as strings
of calendar date and UTC in extended format according to ISO 8601.

– 16 – IEC PAS 61174-1:2021 © IEC 2021
For example:






4.5.8 Schedules node description
The Schedules node contains data on the schedules associated with the route.
Children schedule nodes describe the specific schedule.
Additionally, the node may contain a child extensions node.
4.5.9 Schedule node description
4.5.9.1 Components
The Schedule node consists of a sequence of the following child nodes:
• Manual node that describes user's preferences for the schedule;
• Calculated node that describes schedule calculation results according to user's
preferences.
Additionally, the node may contain a child extensions node.
The manufacturer shall declare which types of schedules are supported (Manual, Calculated or
none) and whether multiple schedules are supported when exchanging routes. This information
shall also be available in the user manual.
4.5.9.2 Manual node description
The Manual node contains a sequence of ScheduleElement nodes that describe time
preferences and calculation restrictions for selected legs of the route. A waypoint should not
have more than one associated ScheduleElement within a Manual node.
Additionally, the node may contain a child extensions node.
4.5.9.3 Calculated node description
The Calculated node contains a sequence of ScheduleElement nodes that store calculations
results according to user's preferences. A waypoint should not have more than one associated
ScheduleElement within a Calculated node.
Additionally, the node may contain a child extensions node.
4.5.9.4 ScheduleElement (manual/calculated) node description
The ScheduleElement node stores a number of time oriented values related to the route leg
(N-1, N), where N is a zero-based index of the leg in the list.

Information is stored in the following attributes:
Attribute Description Format Status Comment
waypointId Identifier of waypoint Integer Mandatory
etd Departure time ISO 8601 Option
Time window as hours
(HH) and minutes (MM)
Describes the
+ HH:MM (RTZ v1.0) before the etd. Both +
uncertainty of the
etdWindowBefore Option
and – HH:MM mean
predicted etd after
xsd:duration (RTZ v1.2)
before the etd,
optimization
(RTZ v1.0)
Time window as hours
(HH) and minutes (MM)
Describes the
+ HH:MM (RTZ v1.0) after the etd. Both +
uncertainty of the
etdWindowAfter Option
and – HH:MM mean
predicted etd after
xsd:duration (RTZ v1.2)
after the etd,
optimization
(RTZ v1.0)
eta Arrival time ISO 8601 Option
Time window as hours
(HH) and minutes (MM)
Describes the
+ HH:MM (RTZ v1.0) before the eta. Both +
uncertainty of the
etaWindowBefore Option
and – HH:MM mean
predicted eta after
xsd:duration (RTZ v1.2)
before the eta.
optimization
(RTZ v1.0)
Time window as hours
(HH) and minutes (MM)
Describes the
after the etd. Both +
+ HH:MM (RTZ v1.0)
uncertainty of the
etaWindowAfter Option
and – HH:MM mean
predicted eta after
xsd:duration (RTZ v1.2)
after the eta.
optimization
(RTZ v1.0)
Length of stop on WP
dd.hh.mm (RTZ v1.0) as days (dd), hours (hh)
stay Stay time on WP Option
and minutes (mm)
xsd:duration (RTZ v1.2)
(RTZ v1.0)
speed Ground speed Real Option Unit: knots
Describes the Unit: knots
uncertainty of the
speedWindow x.xx Option
from -x.xx knots to
predicted speed after
+ x.xx knots
optimization
windSpeed True wind speed Real Option Unit: knots
windDirection True wind direction Real Option Unit: degrees
currentSpeed Current speed Real Option Unit: knots
currentDirection Current direction Real Option Unit: degrees
Unit: knots
Speed loss caused
windLoss Real Option
Calculated during
by wind
optimization
Unit: knots
Speed loss caused
waveLoss Real Option
Calculated during
by wave
optimization
Unit: knots
totalLoss Total speed loss Real Option
Calculated during
optimization
Unit: RPM
rpm Advised Engine RPM Integer Option
Calculated during
optimization
– 18 – IEC PAS 61174-1:2021 © IEC 2021
Attribute Description Format Status Comment
Unit: %
pitch Advised propeller pitch Integer Option
Calculated during
optimization
Unit: kg
Predicted fuel
fuel Real Option
Calculated during
consumption on leg
optimization
Unit: kg
Relative fuel saving
relFuelSave Real Option
Calculated during
after optimization
optimization
Unit: kg
Absolute fuel saving
absFuelSave Real Option
Calculated during
after optimization
optimization
Note String Option
NOTE For details of the format of xs:duration see: https://www.w3schools.com/xml/schema_dtypes_date.asp
For example:












Additionally, the node may contain a child extensions node.
4.5.10 Extensions node description
The Extensions node contains a set of child extension nodes, each of which specify additional
information that may be associated with:
• whole route;
• whole geographical data;
• certain waypoint;
• whole schedules block;
• certain schedule;
• certain schedule element.
4.5.11 Extension node description
The Extension node contains a set of mandatory attributes that identify the extension and a
number of child nodes that may contain arbitrary information. Format of these nodes is beyond
the scope of this document.
If provided, the manufacturer shall include the specification of his extension nodes in the user
manual.
The following attributes are used:
Attribute Description Format Status Comment
manufacturer Unique vendor identifier String Mandatory
name Extension name String Mandatory
version Extension version String Option

An example that illustrates one of the Acme extensions for GMDSS areas is:

version="1.3">





4.6 XML schema to be met by RTZ route files
4.6.1 RTZ schema version 1.0
The RTZ Schema version 1.0 is defined in Annex S of IEC 61174:2015.
4.6.2 RTZ schema version 1.2
The RTZ Schema version 1.2 is defined in Annex A.
4.7 Basic RTZ v1.0 route example

xmlns="http://www.cirm.org/RTZ/1/0" version="1.0"
xsi:schemaLocat
...