MONALISA 2.0 Activity 1.

STM Voyage exchange format

and architecture
Document No: MONALISA 2 0_D1.3.2

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 1

Document Status
Authors
Name Organisation
Anders Rydlinger Transas

Review
Name Organisation
Jens Kristian Jensen DMA

Approval
Name Organisation Signature Date
Per Setterberg SMA

Document History
Version Date Status Initials Description
Revised 8dec 2015 Ok US Language checked

TEN-T PROJECT NO: 2012-EU-21007-S

DISCLAIMER: THIS INFORMATION REFLECTS THE VIEW OF THE AUTHOR (S)
AND THE EUROPEAN COMMISSION IS NOT LIABLE FOR ANY USE THAT MAY BE
MADE OF THE INFORMATION CONTAINED THEREIN.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 2

Table of contents
1 Background ............................................................................................................... 4
2 Objectives .................................................................................................................. 4
3 Other on going work ................................................................................................. 5
4 Result ......................................................................................................................... 5
5 The route exchange format as proposed to IEC ..................................................... 6
5.1 General ....................................................................................................................... 6
5.2 RTP Data container ..................................................................................................... 7
5.3 High-level description of the RTZ format ..................................................................... 8
5.4 Adaptation to third-party extensions ............................................................................ 8
5.4.1 Generic idea .................................................................................................... 8
5.4.2 Unique identification of a waypoint ........................................................................ 9
5.4.3 Creation of new waypoints..................................................................................... 9
5.4.4 Change of geographic data for a waypoint ............................................................ 9
5.4.5 Waypoint remopval ................................................................................................ 9
5.5 Detailed RTZ format description ................................................................................ 10
5.5.1 File components .................................................................................................. 10
5.5.2 Route node description ........................................................................................ 10
5.5.3 RouteInfo node description .................................................................................. 11
5.5.4 Waypoints node description................................................................................. 12
5.5.5 DefaultWaypoint node description ....................................................................... 12
5.5.6 Waypoint node description .................................................................................. 13
5.5.7 Storing date and time for legs .............................................................................. 14
5.5.8 Schedules node description................................................................................. 15
5.5.9 Schedule node description .................................................................................. 15
5.5.10 Extensions node description ................................................................................ 17
5.5.11 Extension node description.................................................................................. 17
5.6 XML schema to be met by RTZ route files................................................................. 18
5.7 Basic RTZ route example .......................................................................................... 33
5.8 Example of the RTZ route with embedded extensions............................................... 34
5.9 UML model of the Route exchange format ................................................................ 35

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 3

1 Background
The task of the workgroup in sub-activity 1.3 of the MONALISA 2.0 project was to
identify the need for a new or improved exchange format for voyage related information
covering the operational needs for Sea Traffic Management.

The work group, with its wide range of skills, knowledge and experience, represented
by administrations, academia, industry, service providers and research institutes
gathered the requirements and outlined a proposal through a number of workgroup
sessions autumn 2013 and spring 2014.

The prerequisites for the work was identified and could be summarized as follow:
No International standard existed, detailed description missing in IMO
performance standard and corresponding IEC standards.
Proprietary format is used by manufacturers and service providers
Common standard does not exist for Shore based parts i.e. VTS etc.
With the following obvious drawbacks:
No interoperability between different systems on board
No possibility to exchange information ship to shore in a unified way
Additional workload for crew when route is supposed to be used in different
systems or operations

2 Objectives
The following objectives were agreed upon:
A common route exchange format should be developed, which supports all processes
in the MONALISA 2.0 project i.e. Sea Traffic Management (STM) where the route can
be used:
On board for safe navigation (ECDIS etc.)
On board for route-schedule-speed optimisation
By Pilots
Ashore for Sea Traffic Management services as:
o Flow management
o On route navigational assistance
o Enhanced monitoring
o Route exchange ship-ship
o Port CDM
o Winter navigation

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 4

 o Area management
o Automated reporting
o SAR
Ashore for Route optimisation and creation of dynamic routes
Ashore by other stakeholders who have an interest in the vessels route and
schedule (Vetting, Ships-operator, ports)
The route format should:
Be open and if possible be aligned with International Standards.
Allow easy customisation so that project goals can be achieved

3 Other on going work

It was noticed by the working group that work under way in IEC (TC80/MT7) to revise
the standard IEC 61174 ed. 3.0 Electronic chart display and information system
(ECDIS) Operational and performance requirements, methods of testing and required
test results.

The question was; could it be possible to solve the project needs within the new IEC
standard? Time was short as TC80/MT7 (technical committee 80/meeting 7) was in its
final stage and the CDV (Committee draft for voting) was just a few months away with
the following milestones CDV March 2014 and FDIS March 2015.

Thanks to good cooperation through the CIRM (Comit International Radio-

Maritime), IEC TC80/MT7 accepted to add additional attributes into the new
formal to meet the project needs. The work was done in a very short time.

4 Result
On the 19th of August 2015, IEC adopted edition 4 of the 61174 standard, where Annex
S contains the route exchange format. This standardised route exchange format
primarily builds on the work in the MONALISA 2.0 project and is divided into three
major blocks
Route General Information
Route Geometry block
Route Schedule block
Each block can contain mandatory and optional information
It should also be possible for manufacturer to add own container of information.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 5

5 The route exchange format as proposed to IEC
This section contains the proposal for the route exchange format as it was delivered
from the MONALISA 2.0 project to IEC.

DISCLAIMER
This proposal may differ in some parts from the standard that was later adopted
by IEC. The format described here below MUST NOT be used for any
implementation of the standard. Please refer to www.iec.ch to obtain the IEC
61174 ed. 4 documentation.

5.1 General
This route plan exchange format is intended to 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 optimisation systems, etc. Another example of
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 optimise a route, etc.
This route plan exchange format is based on standardising 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.
A route plan consists of waypoints. Each waypoint contains information related to the
leg from the previous waypoint. Descriptions of route plans are shown in Figures 5.1
and 5.2. The route exchange format is a file containing an XML coded version of the
route plan. The XML route exchange file uses the extension .rtz. A description of the
RTZ format is given in Clause 5.5. Examples of RTZ format routes are given in
Clauses 5.7 and 5.8.

Clause 5.6 gives an XML schema to be met by RTZ route files so that their structure
and content can be verified.

NOTE 1: 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 2: 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 3: 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.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 6

 WP 2 (geographical coordinates) Calculated distance

Radius

4
WP 1 (geographical coordinates)

WP 3 (geographical coordinates)
GM_Point
Geographical Coordinates
WP
Radii

NOTE: The distance between waypoints is from WOL to WOL with zero advance and transfer or
forwarding distance.

Figure 5.1 Description of route plan distance between WP 2 and WP 3

Figure 5.2 Description of route plan leg parameters belonging to WP 3

5.2 RTP Data container

Data containers are standard ZIP archive files used to compress the size of the route
exchange files.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 7

The container file .rtzp stores a XML file .rtz, which conforms to the XML schema
described in Clause 5.6.
Use of the data container is optional with removable media. In this case the route
exchange may be used with or without the data container. When used without the data
container the filename of the route exchange is .rtz instead of .rtzp.
NOTE: The filename is the attribute routeName described in 5.5.3.
In addition to the .rtz file a number of free-format files may be placed in the data
container. The semantic data link between the XML nodes and files may be
documented using a HTTP like scheme "rtz://<URI>", where "<URI>" identifies a file
name inside the data container.
For example:

<extensions>
<extension manufacturer="Acme" version="2.1"
name="AuxRouteInfo-9674F26E-EAFB-4319-AE24-08D5BA69D895">
<property name="source"

value="http://services.acme.com/auto_route/?id=3e891884e620970e5303fd2399427986"/>
<property name="attachment" value="rtz://assignement-13.04.2013.docx"/>
<property name="attachment" value="rtz://MFD_original.rt3"/>
</extension>
</extensions>
<extensions>

5.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 .

5.4 Adaptation to third-party extensions

5.4.1 Generic idea

Extended information in most cases refers to the geography (geometry) of a route.
There is a need to ensure that:
For the possibility to keep extensions from different manufacturers in a
single file
That modifying the geography (geometry) of a route shall not result in
extensions data bindings being invalid

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 8

 That when changing, adding or removing legs, data consistency should not
break down due to unknown extensions in codes for a particular
manufacturer.

5.4.2 Unique identification of a waypoint

Each waypoint in a route has a unique composite ID.
It is assumed that all RTZ extensions use this identifier to link their data to the
geography.

The identifier consists of two parts:

ID, which allows the finding of a waypoint in the list
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.

5.4.3 Creation of new waypoints

After creation of the waypoint the revision attribute gets the value of 0.

5.4.4 Change of geographic data for a waypoint

When the data of a waypoint changes, the software should increase the revision
number revision, so that third-party software that works with the extension is able to
find out that the data to which it is associated is no longer valid.

5.4.5 Waypoint remopval

When deleting a waypoint from a route, all the waypoint data including schedule data is
deleted and the waypoint numbers within the route are updated.

Responsibility for the extension's data modification is assigned to the manufacturers

code only.

The data that software is not able to recognize (e.g. extensions and options) are written
back into the modified file without modification.

It is assumed that the receiver which understands extensions is able to filter out data
when reading the route and be able to eliminate the data of extensions related to
removed or to non-existent waypoints.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 9

5.5 Detailed RTZ format description

5.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 ro u te n o d e , wh ic h in c lu d e
namespace
http://www.w3.org/2001/XMLSchema-instance as well as the RTZ
namespace1 http://www.cirm.org/RTZ/1/0;
The version attribute in the format "Major.Minor" (currently "1.0").

The preferred file encoding is UTF-8.

5.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 format
used during file creation.

Version is specified as a combination of two figures separated with a dot. The first
figure corresponds to the major version. It shall be changed in the case of significant
modifications to the document structure. Formats with different major versions are
incompatible.

The second figure 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.

1
Comit International Radio-Maritime (CIRM) is the international association for marine electronics
companies.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 10

5.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
validityPeriodStart ISO 8601 Option
period

Stop of validity ISO 8601

validityPeriodStop Option
period

vesselName Ships name String Option

vesselMMSI Ships MMSI XXXXXXXXX Option

vesselIMO Ships IMO number XXXXXXX Option

Number of the
vesselVoyage String Option
voyage

vesselDisplacement Ships displacement Integer Option Unit: tons

vesselCargo Ships cargo Integer Option Unit: tons

Metacentric height of
the ship for intended
vesselGM Metacentric height XX.XX Option voyage.
Unit: metres

Could be fixed
Route is optimised speed, Lowest Fuel
optimisationMethod String Option
to meet KPI Consumption, Fixed
ETA

Ships max roll angle

vesselMaxRoll XX Option Unit: degrees
allowed

Ship significant
vesselMaxWave XX.X Option Unit: metres
wave height limit

Ships max wind

vesselMax_Wind XX.X Option Unit: metres
speed limit

Unit: knots, Speed

vesselSpeedMax Ships max speed XX.X Option
through water

Ships preferred
Unit: knots, Speed
vesselServiceMin service speed XX.X Option
through water
window_min

Ships preferred
Unit: knots, Speed
vesselServiceMax service speed XX.X Option
through water
window_max

Cause of route
routeChangesHistory change, Originator String Option
and Reason

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 11

For example:

<RouteInfo routeName="AROUNDtheSKAGEN" />

vesselName=ACME
validityPeriodStart=2014-01-03T03:15:00Z
validityPeriodStop=2014-01-06T10:15:00Z
vesselMMSI=xxxxxxxxx
vesselVoyage =xxxx/>

Additionally, the node may contain a child extension.

5.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 defines default values of attributes for newly created legs except for the
geometry data.

For example:

<Waypoint id="24" revision="3" radius="0.6">

<Position lat="53.0513" lon="8.87509"/>
<Leg starboardXTD="0.2" portsizeXTD="0.1" geometryType="1"/>
</Waypoint>

Additionally, the node may contain a child extensions node.

5.5.5 DefaultWaypoint node description

The DefaultWaypoint node allows the definition of default values of attributes for
newly created waypoints.

For example:

<Waypoints>
<DefaultWaypoint radius="1.4">
<Leg starboardXTD="0.5" portsizeXTD="0.5" geometryType="0"/>
</DefaultWaypoint>

If the DefaultWaypoint node is provided before the sequence of waypoints, then it shall
contain values for attributes for newly created waypoints.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 12

For example:

<Waypoints> Defaults settings for all waypoints

<DefaultWaypoint radius="1.4">
<Leg starboardXTD="0.3" portsideXTD="0.3"
geometryType="0"/>
</DefaultWaypoint>
<Waypoint id="33" rev="1"/> For this waypoint default settings
<Position lat="53.0492" lon="8.87731"/> applied
</Waypoint>
<Waypoint id="17" rev="3" radius="0.3"> For this waypoint user settings applied:
<Position lat="53.0513" lon="8.87509"/> Port XTD = 0,5 NM
<Leg starboardXTD="0.4" portsideXTD="0.5" Starboard XTD = 0,4 NM
geometryType="1"/> Turn radius = 0,3 NM
</Waypoint> Geometry type is orthodrome

5.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
id Unique identifier Integer Mandatory equal to the index of the
waypoint
revision Waypoint revision Integer Option Index of revision
name Waypoint String Option
radius Turn radius Real Option Unit: NM
position Geographic point GM_Point Mandatory Unit: degrees
Optional for the first
leg Leg attributes Mandatory
waypoint

Position node contains the latitude and longitude of the waypoint.

Attribute Description Format Status Comment
Unit: degrees with
lat Latitude Real Mandatory
decimal
Unit: degrees with
lon Longitude Real Mandatory
decimal

Leg node contains attributes of the leg associated with the waypoint (see
Figure 5.2).
Attribute Description Format Status Comment
starboardXTD Starboard XTD Real Option Unit: NM with decimal
portsideXTD Portside XTD Real Option Unit: NM with decimal
safetyContour Planned Safety Real Option Unit: metres

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 13

 contour
safetyDepth Planned Safety depth Real Option Unit: metres
loxodrome (= rhumb
line) or
geometryType Geometry type of leg Enumeration Option
orthodrome (= great
circle)
Unit: knots, Speed over
planSpeedMin Lowest cruising speed Real Option
ground
Highest allowed Unit: knots, Speed over
planSpeedMax Real Option
speed ground
Static Draught
draughtForward Real Option Unit: metres
Forward
draughtAft Static Draught Aft Real Option Unit: metres
Minimum UKC on the
staticUKC Real Option Unit: metres
leg
Minimum Dynamic
dynamicUKC Real Option Unit: metres
UKC on the leg
Unit: metres
masthead Height of masthead Real Option
Calculated from keel
Part of annotated route
legReport Reporting information String Option
plan
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 will be taken from the
element defaults node. If this parameter is absent in the defaults node, then its value
is set to "zero" or "empty", depending on the type of the parameter. For the case when
geometryType is absent, this attribute should be considered as Loxodrome.
Additionally, the node may contain a child extensions node.

5.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 dates and UTC in extended format according to ISO 8601.
For example:

<Schedule id="2" name="Schedule2">

<Manual>
<ScheduleElement id="100" etd="2002-11-17T15:25:00Z"/>
<ScheduleElement id="105" eta="2002-11-17T15:25:00Z"/>
</Manual>
</Schedule>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 14

5.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.

5.5.9 Schedule node description

5.5.9.1 Components
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.

5.5.9.2 Manual node description

Manual node contains a sequence of ScheduleElement nodes that describe time
preferences and calculation restrictions for each leg 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.

5.5.9.3 Calculated node description

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.

5.5.9.4 ScheduleElement (manual/calculated) node description

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:

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 15

 Attribute Description Format Status Comment
waypointID Identifier of waypoint Integer Mandatory
etd Departure time ISO 8601 Option
Describes the
etdWindowBefor uncertainty of the
+ HH.MM Option - HHMM to etd
e predicted etd after
optimisation
Describes the
uncertainty of the
etdWindowAfter + HH.MM Option + HHMM after etd
predicted etd after
optimisation
eta Arrival time ISO 8601 Option
Describes the
etaWindowBefor uncertainty of the
+ HH.MM Option - HHMM to eta
e predicted eta after
optimisation
Describes the
uncertainty of the
etaWindowAfter + HH.MM Option + HHMM after eta
predicted eta after
optimisation
stay Stay time on WP dd.hh.mm Option Length of stop on WP
speed Ground speed Real Option Unit: knots
Describes the Unit: knots
uncertainty of the
speedWindow + x.xx Option - x.xx knots to + x.xx
predicted speed after
optimisation knots

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 by
windLoss Real Option Calculated during
wind
optimisation
Unit: knots
Speed loss caused by
waveLoss Real Option Calculated during
wave
optimisation
Unit: knots
totalLoss Total speed loss Real Option Calculated during
optimisation
Unit: RPM
rpm Advised Engine RPM Integer Option Calculated during
optimisation
Unit: %
pitch Advised propeller pitch Integer Option Calculated during
optimisation
Unit: kg
Predicted fuel
fuel Real Option Calculated during
consumption on leg
optimisation
Unit: kg
Relative fuel saving after
relFuelSave Real Option Calculated during
optimisation
optimisation
absFuelSave Absolute fuel saving after Real Option Unit: kg

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 16

 optimisation Calculated during
optimisation
Note String Option

For example:

<Schedule id="2" name="Schedule2">

<Manual>
<SheduleElement id="100" etd="2002-11-17T15:25:00Z" />
<SheduleElement id="105" eta="2002-12-17T15:25: 00Z" />
</Manual>
<Calculated>
<SheduleElement id="100" etd="2002-11-17T15:25:00Z speed="11.00000000"/>
<SheduleElement id="105" eta="2002-12-17T15:25:00Z" speed="12.23242000"/>
</Calculated>
<Extensions>
</Extensions>
</Schedule>

Additionally, the node may contain a child extensions node.

5.5.10 Extensions node description

The Extensions node contains a set of child extension nodes, each of which specifies
additional information that may be associated with:
Whole route
Whole geographical data
Certain waypoint
Whole schedules block
Certain schedule
Certain schedule element.

5.5.11 Extension node description

Extension node contains a set of mandatory attributes that identify the extension and a
number of child nodes that may contain arbitrary information. The format of these
nodes is beyond the scope of this standard.

If provided, the manufacturer shall include the specification of his extension nodes in
the user manual.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 17

The following attributes are used:

Attribute Description Format Status Comment

Unique vendor
manufacturer String Mandatory
identifier
Extension
name String Mandatory
name
Extension
version String Option
version

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

<Extensions>
<Extension manufacturer="acme" name="GMDSS-96CF94DF-6ADB-4B08-B43F-355F939AF5F8"
version="1.3">
<Point id="77" class="A1" range="20.0"/>
<Point id="79" class="A1" range="22.0"/>
<Point id="80" class="A2" range="121.2"/>
</Extension>
</Extensions>

5.6 XML schema to be met by RTZ route files

<?xml version="1.0" encoding="utf-8"?>
<!--

Route Exchange Format (RTZ)

XML schema

Revision 1.0

Source: IEC 61174 Ed 4.0:2015

-->

<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.cirm.org/RTZ/1/0"
targetNamespace="http://www.cirm.org/RTZ/1/0"
elementFormDefault="qualified">

<xsd:annotation>
<xsd:documentation>
RTZ schema version 1.0 For more information on RTZ and this schema,
visit http://www.cirm.org/RTZ.

RTZ uses the following conventions: all coordinates are relative to the WGS8
datum.

All measurements are in nautical miles unless otherwise specified.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 18

 </xsd:documentation>
</xsd:annotation>

<!-- -->
<!-- Root element -->
<!-- -->
<xsd:element name="route" type="Route">
<xsd:annotation>
<xsd:documentation>
Route is the root element in the XML RTZ file.
</xsd:documentation>
</xsd:annotation>
</xsd:element>

<!-- -->
<!-- Root element type definition -->
<!-- -->
<xsd:complexType name="Route">
<xsd:annotation>
<xsd:documentation>
RTZ files contain a number of waypoints, followed with auxiliary schedules.
You can add your own elements to the extension section of the RTZ document.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="routeInfo" type="RouteInfo" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Generic route information.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="waypoints" type="Waypoints" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
A list of waypoints.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="schedules" type="Schedules" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Optional list of schedules.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="version" type="xsd:string" use="required" fixed="1.0">
<xsd:annotation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 19

 <xsd:documentation>
Format version (currently "1.0").
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- "RouteInfo" element type definition -->
<!-- -->
<xsd:complexType name="RouteInfo">
<xsd:sequence>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="routeName" type="xsd:string" use="required">
<xsd:annotation>
<xsd:documentation>The name of the route.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="routeAuthor" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The author of route.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="routeStatus" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Status of route.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="validityPeriodStart" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
Start of validity period in ISO 8601 format.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="validityPeriodStop" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
Stop of validity period in ISO 8601 format.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The name of ship.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselMMSI" type="xsd:nonNegativeInteger">
<xsd:annotation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 20

 <xsd:documentation>MMSI of ship.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselIMO" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>IMO number of ship.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselVoyage" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Number of the voyage.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselDisplacement" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>Displacement of ship in tons.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselCargo" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>Cargo of ship in tons.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselGM" type="LengthType">
<xsd:annotation>
<xsd:documentation>Metacentric height in metres.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="optimisationMethod" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Route is optimised to meet KPI.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselMaxRoll" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>
Max roll angle of ship allowed in degrees.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselMaxWave" type="LengthType">
<xsd:annotation>
<xsd:documentation>
Ship significant wave height limit in metres.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselMaxWind" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>
Max wind speed limit of ship in metres per second.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselSpeedMax" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Max speed of ship in knots.</xsd:documentation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 21

 </xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselServiceMin" type="SpeedType">
<xsd:annotation>
<xsd:documentation>
Preferred service speed window minimum in knots.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="vesselServiceMax" type="SpeedType">
<xsd:annotation>
<xsd:documentation>
Preferred service speed window maximum in knots.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="routeChangesHistory" type="SpeedType">
<xsd:annotation>
<xsd:documentation>
Cause of route change, originator and reason.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- "LengthType" element type definition -->
<!-- -->
<xsd:simpleType name="LengthType">
<xsd:annotation>
<xsd:documentation>Length type.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.0"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- "SpeedType" element type definition -->
<!-- -->
<xsd:simpleType name="SpeedType">
<xsd:annotation>
<xsd:documentation>Speed type.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.0"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- Extension point type definition -->
<!-- -->
<xsd:complexType name="Extensions">
<xsd:annotation>
<xsd:documentation>
You can add extend GPX by adding your own elements from another schema here.
</xsd:documentation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 22

 </xsd:annotation>
<xsd:sequence>
<xsd:any namespace="##any" processContents="skip"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
You can add extend GPX by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>

<!-- -->
<!-- "Waypoints" element type definition -->
<!-- -->
<xsd:complexType name="Waypoints">
<xsd:sequence>
<xsd:element name="defaultWaypoint" type="DefaultWaypoint" minOccurs="0"
maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Waypoint defaults.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="waypoint" type="Waypoint" minOccurs="2"maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Waypoint details.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<!-- -->
<!-- "DefaultWaypoint" element type definition -->
<!-- -->
<xsd:complexType name="DefaultWaypoint">
<xsd:sequence>
<xsd:element name="leg" type="Leg" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Leg attributes.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 23

 </xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="radius" type="RadiusType">
<xsd:annotation>
<xsd:documentation>Turn radius in NM.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- "RadiusType" element type definition -->
<!-- -->
<xsd:simpleType name="RadiusType">
<xsd:annotation>
<xsd:documentation>Radius type.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.0"/>
<xsd:maxExclusive value="10.0"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- "Waypoint" element type definition -->
<!-- -->
<xsd:complexType name="Waypoint">
<xsd:sequence>
<xsd:element name="position" type="GM_Point" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Geographic point.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="leg" type="Leg" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Leg attributes.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:nonNegativeInteger" use="required">
<xsd:annotation>
<xsd:documentation>
Unique waypoint identifier.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="revision" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 24

 Waypoint revision. Increased on every change.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Waypoint name.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="radius" type="RadiusType">
<xsd:annotation>
<xsd:documentation>
Turn radius in NM.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- "Leg" element type definition -->
<!-- -->
<xsd:complexType name="Leg">
<xsd:attribute name="starboardXTD" type="XtdType">
<xsd:annotation>
<xsd:documentation>Starboard XTE in NM.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="portsideXTD" type="XtdType">
<xsd:annotation>
<xsd:documentation>Portside XTE in NM.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="safetyContour" type="LengthType">
<xsd:annotation>
<xsd:documentation>Safety contour in metres.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="safetyDepth" type="LengthType">
<xsd:annotation>
<xsd:documentation>Safety depth in metres.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="geometryType" type="GeometryType">
<xsd:annotation>
<xsd:documentation>Geometry type of leg.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="speedMin" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Lowest cruising speed in knots.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="speedMax" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Highest allowed speed in knots.</xsd:documentation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 25

 </xsd:annotation>
</xsd:attribute>
<xsd:attribute name="draughtForward" type="LengthType">
<xsd:annotation>
<xsd:documentation>Static draught forward in metres.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="draughtAft" type="LengthType">
<xsd:annotation>
<xsd:documentation>Static draught aft in metres.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="staticUKC" type="LengthType">
<xsd:annotation>
<xsd:documentation>Minimum UKC on the leg.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="dynamicUKC" type="LengthType">
<xsd:annotation>
<xsd:documentation>Minimum dynamic UKC on the leg.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="masthead" type="LengthType">
<xsd:annotation>
<xsd:documentation>Height of masthead.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="legReport" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Reporting information.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="legInfo" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Nice to know.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="legNote1" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Notes regarding the ETD/ETA.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="legNote2" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Local remarks.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- XTD type definition -->
<!-- -->
<xsd:simpleType name="XtdType">
<xsd:annotation>
<xsd:documentation>
XTD of the point. Nautical miles.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 26

 </xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.0"/>
<xsd:maxExclusive value="10. 0"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- "geometry/geopoint" element type definition -->
<!-- -->
<xsd:complexType name="GM_Point">
<xsd:attribute name="lat" type="LatitudeType" use="required">
<xsd:annotation>
<xsd:documentation>Latitude in degrees.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="lon" type="LongitudeType" use="required">
<xsd:annotation>
<xsd:documentation>Longitude in degrees.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- RL/GC indicator type definition -->
<!-- -->
<xsd:simpleType name="GeometryType">
<xsd:annotation>
<xsd:documentation>RL/GC indicator.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Loxodrome"/>
<xsd:enumeration value="Orthodrome"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- Geographical latitude type definition -->
<!-- -->
<xsd:simpleType name="LatitudeType">
<xsd:annotation>
<xsd:documentation>
The latitude of the point. Decimal degrees, WGS84 datum.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="-90.0"/>
<xsd:maxInclusive value="90.0"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- Geographical longitude type definition -->
<!-- -->
<xsd:simpleType name="LongitudeType">
<xsd:annotation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 27

 <xsd:documentation>
The longitude of the point. Decimal degrees, WGS84 datum.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="-180.0"/>
<xsd:maxExclusive value="180.0"/>
</xsd:restriction>
</xsd:simpleType>

<!-- -->
<!-- "Schedules" element type definition -->
<!-- -->
<xsd:complexType name="Schedules">
<xsd:sequence>
<xsd:element name="schedule" type="Schedule" minOccurs="0"maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Schedule definition.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<!-- -->
<!-- "schedules/schedule" element type definition -->
<!-- -->
<xsd:complexType name="Schedule">
<xsd:annotation>
<xsd:documentation>
Schedule definition.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="manual" type="Manual" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Manual schedule values definition.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="calculated" type="Calculated" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Calculated schedules.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 28

 <xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:nonNegativeInteger" use="required">
<xsd:annotation>
<xsd:documentation>
Schedule name.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Schedule name.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- "Manual" element type definition -->
<!-- -->
<xsd:complexType name="Manual">
<xsd:annotation>
<xsd:documentation>User defined schedule parameters.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sheduleElement" type="ScheduleElement"
minOccurs="1" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Manual schedule leg definition.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements
from another schema here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<!-- -->
<!-- "Calculated" element type definition -->
<!-- -->
<xsd:complexType name="Calculated">
<xsd:annotation>
<xsd:documentation>
Calculated schedule parameters.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 29

 </xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sheduleElement" type="ScheduleElement"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Calculated schedule waypoint parameters.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements
from another schema here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<!-- -->
<!-- "ScheduleElement" element type definition -->
<!-- -->
<xsd:complexType name="ScheduleElement">
<xsd:sequence>
<xsd:element name="extensions" type="Extensions" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
You can add extend RTZ by adding your own elements from another schema
here.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="waypointId" type="xsd:nonNegativeInteger" use="required">
<xsd:annotation>
<xsd:documentation>Unique waypoint identifier.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="etd" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
UTC estimated departure time in ISO 8601 format.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="etdWindowBefore" type="xsd:time">
<xsd:annotation>
<xsd:documentation>
Describes the uncertainty of the predicted ETD after optimisation.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="etdWindowAfter" type="xsd:time">
<xsd:annotation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 30

 <xsd:documentation>
Describes the uncertainty of the predicted ETD after optimisation.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="eta" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
UTC estimated arrival time in ISO 8601 format.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="etaWindowBefore" type="xsd:time">
<xsd:annotation>
<xsd:documentation>
Describes the uncertainty of the predicted ETA after optimisation.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="etaWindowAfter" type="xsd:time">
<xsd:annotation>
<xsd:documentation>
Describes the uncertainty of the predicted ETA after optimisation.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="stay" type="xsd:time">
<xsd:annotation>
<xsd:documentation>Stay time on WP.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="speed" type="SpeedType">
<xsd:annotation>
<xsd:documentation>True speed in knots.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="speedWindow" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>
Describes the uncertainty of the predicted speed after optimisation in knots.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="windSpeed" type="SpeedType">
<xsd:annotation>
<xsd:documentation>True wind speed in metres per second.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="windDirection" type="CourseType">
<xsd:annotation>
<xsd:documentation>True wind direction in degrees.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="currentSpeed" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Current speed in knots.</xsd:documentation>
</xsd:annotation>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 31

 </xsd:attribute>
<xsd:attribute name="currentDirection" type="CourseType">
<xsd:annotation>
<xsd:documentation>Current direction in degrees.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="windLoss" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Speed loss caused by wind in knots.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="waveLoss" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Speed loss caused by wave.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="totalLoss" type="SpeedType">
<xsd:annotation>
<xsd:documentation>Total speed loss.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="rpm" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>Advised Engine RPM.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="pitch" type="xsd:integer">
<xsd:annotation>
<xsd:documentation>Advised Engine Pitch.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="fuel" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>Predicted fuel consumption on leg.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="relFuelSave" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>
Relative fuel saving after optimisation in percent.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="absFuelSace" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>
Absolute fuel saving after optimisation.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="Note" type="xsd:string">
</xsd:attribute>
</xsd:complexType>

<!-- -->
<!-- Course type definition -->
<!-- -->

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 32

 <xsd:simpleType name="CourseType">
<xsd:annotation>
<xsd:documentation>Course type in degrees.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.0"/>
<xsd:maxExclusive value="360.0"/>
</xsd:restriction>
</xsd:simpleType>

</xsd:schema>

5.7 Basic RTZ route example

<?xml version="1.0" encoding="UTF-8"?>
<route xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.cirm.org/RTZ/1/0" version="1.0"
xsi:schemaLocation="http://www.cirm.org/RTZ/1/0 rtz.xsd">
<routeInfo routeName="AROUNDtheSKAGEN"/>
<waypoints>
<defaultWaypoint radius="0.1">
<leg portsideXTD="0.1" starboardXTD="0.1"/>
</defaultWaypoint>
<waypoint id="15" revision="1">
<position lat="53.0492" lon="8.87731"/>
</waypoint>
<waypoint id="52" revision="3">
<position lat="53.0513" lon="8.87509"/>
<leg portsideXTD="0.3" starboardXTD="0.3"
safetyContour="11.20000000" safetyDepth="22.20000000"
geometryType="Orthodrome"/>
</waypoint>
<waypoint id="1" revision ="1" name="To the pier">
<position lat="53.5123" lon="8.11998"/>
<leg portsideXTD="0.1" starboardXTD="0.1"/>
</waypoint>
<waypoint id="5" revision ="3" name="To the pier">
<position lat="53.0492" lon="8.87731"/>
<leg portsideXTD ="0.1" starboardXTD ="0.1"
safetyContour ="11.20000000" safetyDepth ="22.20000000"
geometryType="Orthodrome"/>
</waypoint>
</waypoints>
<schedules>
<schedule id="1" name="Schedule1">
<manual>
<sheduleElement waypointId="15" etd="2002-11-17T15:25:00Z" />
<sheduleElement waypointId="15" eta="2002-11-17T15:25:00Z" />
</manual>
<calculated/>
</schedule>
<schedule id="2" name="Schedule2">
<manual>
<sheduleElement waypointId="15" etd="2002-11-17T15:25:00Z" />
<sheduleElement waypointId="15" eta="2002-12-17T15:25:00Z" />
</manual>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 33

 <calculated>
<sheduleElement waypointId="15" etd="2002-11-17T15:25:00Z"
speed="11.34520000"/>
<sheduleElement waypointId="15" eta="2002-12-17T15:25:00Z"
speed="12.66635112"/>
</calculated>
</schedule>
</schedules>
<extensions/>
</route>

5.8 Example of the RTZ route with embedded extensions

<?xml version="1.0" encoding="UTF-8"?>
<route xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.cirm.org/RTZ/1/0" version="1.0"
xsi:schemaLocation="http://www.cirm.org/RTZ/1/0 rtz.xsd">
<routeInfo routeName="AROUNDtheSKAGEN"/>
<waypoints>
<defaultWaypoint radius="0.1">
<leg portsideXTD ="0.1" starboardXTD ="0.1"/>
</defaultWaypoint>
<waypoint id="15" revision="1">
<position lat="53.0492" lon="8.87731"/>
<leg portsideXTD="0.1" starboardXTD="0.1"
safetyContour="11.20000000"
safetyDepth="22.20000000" geometryType="Loxodrome"/>
</waypoint>
<waypoint id="52" revision="3">
<position lat="53.0513" lon="8.87509"/>
<leg portsideXTD="0.3" starboardXTD="0.3"
safetyContour="11.20000000"
safetyDepth="22.20000000" geometryType="Orthodrome"/>
</waypoint>
<waypoint id="1" revision="1" name="To the pier">
<position lat="53.5123" lon="8.11998"/>
<leg portsideXTD ="0.1" starboardXTD ="0.1"/>
</waypoint>
</waypoints>
<schedules>
<schedule id="1" name="Schedule1">
<manual>
<sheduleElement waypointId="15" etd="2002-11-17T15:25:00Z"/>
<sheduleElement waypointId="1" eta="2002-11-17T15:25:00Z"/>
</manual>
<calculated/>
</schedule>
<schedule id="2" name="Schedule2">
<manual>
<sheduleElement waypointId="15" etd="2002-11-17T15:25:00Z"/>
<sheduleElement waypointId="15" eta="2002-12-17T15:25:00Z"/>
</manual>
<calculated>
<sheduleElement waypointId="15" etd="2002-11-17T15:25:00Z"
speed="11.34520000"/>

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 34

 <sheduleElement waypointId="15" eta="2002-12-17T15:25:00Z"
speed="12.66635112">
<extensions>
<extension manufacturer="Acme" version="2.1"
name="Int-681EA94E-C27A-4CCA-A405-98BDA20AA7C6">
<struct name="xxx">
<Param name="x" value="y" />
</struct>
</extension>
</extensions>
</sheduleElement>
</calculated>
<extensions/>
</schedule>
</schedules>
<extensions>
<extension manufacturer="Acme" version="1.0"
name="Internal-C93B70B2-D733-4388-937C-639472E2C6CF">
<saypoint id="15" rev="1" link="rtz://symbols.png"/>
</extension>
</extensions>
</route>

5.9 UML model of the Route exchange format

Figure 5.3 gives the Unified Modelling Language diagram for the route exchange
format.

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 35

 GM_Point Integer Real CharacterString Time Date DateTime Boolean
+lat : Real +value[1] : int +value : double +value[1..*] : char +value[1] : double +value[1] : double +value[1] : double +value[1] : bool
+lon : Real
1 Route
enumeration
GeometryType +version[1] : CharacterString
+Loxodrome +extensions[0..1] : Extensions 1 1
+Orthodrome
1
1 RouteInfo
0..1
+routeName[1] : CharacterString
+routeAuthor[0..1] : CharacterString
Waypoints Schedules +routeStatus[0..1] : CharacterString
+extensions[0..1] : Extensions +extensions[0..1] : Extensions +validityPeriodStart[0..1] : DateTime
+validityPeriodStop[0..1] : DateTime
1 1 +vesselName[0..1] : CharacterString
1 +vesselMMSI[0..1] : Integer
0..1 0..*
+vesselIMO[0..1] : Integer
+vesselVoyage[0..1] : CharacterString
DefaultWaypoint Schedule +vesselDisplacement[0..1] : Integer
+radius[0..1] : Real +id[1] : Integer +vesselCargo[0..1] : Integer
+extensions[0..1] : Extensions +name[0..1] : CharacterString +vesselGM[0..1] : Real
+extensions[0..1] : Extensions +optimizationMethod[0..1] : CharacterString
+vesselMaxRoll[0..1] : Integer
1 2..* +vesselMaxWave[0..1] : Real
0..1 1 1 0..1
+vesselMaxWind[0..1] : Real
+vesselSpeedMax[0..1] : Real
Waypoint Manual Calculated +vesselServiceMin[0..1] : Real
+id[1] : Integer +extensions[0..1] : Extensions +extensions[0..1] : Extensions +vesselServiceMax[0..1] : Real
+revision[0..1] : Integer +routeChangesHistory[0..1] : CharacterString
+name[0..1] : CharacterString +extensions[0..1] : Extensions
1 1
+radius[0..1] : Real 1..* 0..*
+position[1] : GM_Point
+extensions[0..1] : Extensions ScheduleElement

1 +waypointId[1] : Integer
0..1 +etd[0..1] : DateTime
0..1 +etdWindowBefore[0..1] : Time
+etdWindowAfter[0..1] : Time
Leg +eta[0..1] : DateTime
+etaWindowBefore[0..1] : Time
+starboardXTD[0..1] : Real Extension
+etaWindowAfter[0..1] : Time
+portsideXTD[0..1] : Real +stay[0..1] : Time +manufacturer[1] : CharacterString
+safetyContour[0..1] : Real +speed[0..1] : Real +name[1] : CharacterString
+safetyDepth[0..1] : Real +speedWindow[0..1] : Real +version[0..1] : CharacterString
+geometryType[0..1] : GeometryType +windSpeed[0..1] : Real
+speedMin[0..1] : Real +windDirection[0..1] : Real 0..*
+speedMax[0..1] : Real +currentSpeed[0..1] : Real
+draught[0..1] : Real 1
+currentDirection[0..1] : Real
+draughtForward[0..1] : Real +windLoss[0..1] : Real
+draughtAft[0..1] : Real +waveLoss[0..1] : Real Extensions
+staticUKC[0..1] : Real +totalLoss[0..1] : Real
+dynamicUKC[0..1] : Real +rpm[0..1] : Real
+masthead[0..1] : Real +pitch[0..1] : Integer
+legReport[0..1] : CharacterString +fuel[0..1] : Real
+legInfo[0..1] : CharacterString +relFuelSave[0..1] : Real
+legNote1[0..1] : CharacterString +absFuelSace[0..1] : Real
+legNote2[0..1] : CharacterString +note[0..1] : CharacterString
+extensions[0..1] : Extensions +extensions[0..1] : Extensions

Figure 5.3 UML diagram

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 36

 39 partners from 10 countries
taking maritime transport into the digital age

By designing and demonstrating innovative use of ICT solutions

MONALISA 2.0 will provide the route to improved

SAFETY - ENVIRONMENT - EFFICIENCY

Swedish Maritime Administration LFV - Air Navigation Services of Sweden SSPA

Viktoria Swedish ICT Transas Carmenta Chalmers University of Technology
World Maritime University The Swedish Meteorological and Hydrological Institute
Danish Maritime Authority Danish Meteorological Institute GateHouse Navicon
Novia University of Applied Sciences DLR Fraunhofer Jeppesen Rheinmetall
Carnival Corp. Italian Ministry of Transport RINA Services DAppolonia Port of
Livorno IB SRL Martec SPA Ergoproject University of Genua VEMARS
SASEMAR Ferri Industries Valencia Port Authority Valencia Port Foundation
CIMNE Corporacion Maritima Technical University of Madrid University of
Catalonia Technical University of Athens MARSEC-XL Norwegian Coastal
Administration

www.monalisaproject.eu

MONALISA 2.0 - STM VOYAGE EXCHANGE FORMAT AND ARCHITECTURE 37