Service Description: Harmonised Data

Exchange with Inter-VTS Exchange Format

(IVEF)

Issue: 1
Issue Status: Approved
Issue Date: 18/05/2015

Lead Author Reviewer Approved for Release

Name: Jeffrey van Gils Name: Transnational Project Co- Name: Project Steering
ordination Group Committee

Job Title: WP6 Contributor Job Title: N/A Job Title: N/A

Partner: RWS Partner: All Partner: All

Signature: pp Alwyn I. Williams Signature: pp Alwyn I. Williams Signature: pp Alwyn I.

Williams
Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Executive Summary
The pilot showed the interchange of traffic images between VTS’s and between vessels and
coastguard/VTS centres (vice versa), making use of the IVEF standard.
To share information between parties is of great importance to reduce misunderstanding
between parties and to enlarge/enhance the information coverage of the individual parties.
Examples of tasks which benefit from the information exchange are:
 SAR tasks
 VTS / Monitoring tasks
 VTS outside territorial waters
 Port entry by vessels
Sharing the picture build up by your own sensors and shared with other parties in the same
area has several advantages:
1. Saves money on installing and maintaining sensors like radar and AIS stations;
2. Possibility to verify your data with data of partners;
3. Track smaller targets than possible from shore only;
4. Share a common harmonized picture over a specific area with partners (shore and ships);
5. Ability to look and search further than your own sensors farm;
6. Backup system for your shore based system;
7. Ability to have data available when needed in areas normally not covered.
Some disadvantages or points that have to be solved are:
1. Quality assurance of the data;
2. Responsibility of the data;
3. Legislation about sharing data;
4. Communications costs;
5. Implementation costs for current (proprietary) systems.
Growing from coverage only on the shore site as shown in figure 1 to a coverage on need
and current shown in figure 2:

Figure2: Possible sensor (radar) coverage

Figure 1: Current sensor (radar) coverage

Implementing the pilot showed that not all shore based systems are already IVEF compliant,
due to different reasons, what makes the connection between these systems more difficult.
This problem is even greater on ship site but some standardization helped already making
use of the same sensors on board.
The organisation of the pilot was the greatest challenge: getting everybody involved and
enthusiastic, getting permissions and cooperation. Cooperation with the German EMS VTS
and the British coastguard was planned, but is not realised due to the fact that both
organisation were dealing with a redesign of their systems and were not able to deal with

ACCSEAS Project Page 2 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

adjustments on their systems for the pilot at the same time In the last case special thanks
goes to the Dutch Coastguard and the crew of the Barend Biesheuvel.

ACCSEAS Project Page 3 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Document Disclaimer

Document is uncontrolled when removed from iManage (either electronic or printed)

Document Information

Project Title ACCSEAS

Work Package No. 6

Document Title Service Description: Harmonised Data Exchange with Inter-VTS

Exchange Format (IVEF

Description This document describes the results of the efforts in developing

and testing the Inter-VTS Exchange Format under ACCSEAS.

Date 18/05/2015

Lead Author Jeffrey van Gils

Lead Author’s Contact Rijkswaterstaat Water, Traffic and Environment

Information
Directie Accessibility and Infrastructure
Department Synchro-modal Transport and Shipping
Lange Kleiweg 34 | 2288 GK Rijswijk | The Netherlands
P.O. Box 5807 | 2280 HV Rijswijk | The Netherlands
Mobile: +31 (0)6 51 42 70 66
Email: [email protected]
www.rijkswaterstaat.nl

Contributing Author(s) WP6 Contributors

iManage Location 29921

Circulation 1. Client
2. Project Files (i-manage)
3. Transnational Project Co-ordination Group
4. Project Steering Committee

NSRP Secretariat Yes / No

Approval

ACCSEAS Project Page 4 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Contents
1 Introduction .................................................................................................................... 7
1.1 Background............................................................................................................. 7
1.2 Scope/goal of the pilot ............................................................................................ 8
1.3 Current status ......................................................................................................... 8
1.4 Description of the Harmonised Data Exchange Service .......................................... 9
1.5 Considerations ...................................................................................................... 11
2 Description of Developed Service................................................................................. 12
2.1 Pilot setup ............................................................................................................. 12
2.2 Starting point......................................................................................................... 12
2.2.1 Radar ............................................................................................................. 13
2.3 System Setup ....................................................................................................... 15
2.4 Connection between ship and shore ..................................................................... 16
3 Observations and Feedback......................................................................................... 18
3.1 Reactions of the end users: .................................................................................. 18
3.2 Organisation ......................................................................................................... 18
3.3 Technical .............................................................................................................. 19
3.3.1 Shore side ..................................................................................................... 19
3.3.2 Ship side ........................................................................................................ 20
3.4 Overall Advice ....................................................................................................... 20
4 Material Investments .................................................................................................... 22
4.1 ACCSEAS Legacy: IVEF Hardware ...................................................................... 22

ACCSEAS Project Page 5 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

This page is deliberately blank.

ACCSEAS Project Page 6 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

1 Introduction
1.1 Background
“What is your status?” misunderstanding is often caused by miscommunication,
particularly when information used is different, not complete or not clear for the parties
involved. What may result in unsafe hazardous situations for ship, crew and
environment?
It is well understood that the availability of reliable and accurate information is essential
for the (future) traffic management, logistics and decisions for the operational
processes both on board and on shore.
Liu and Wu (2003) studied 100 collision reports from the maritime authorities of the
UK, USA, Australia, Canada, New Zealand and Sweden. They found that
communication problems were one of the most prominent causes of accidents at sea.
The most frequently identified causes were lack of communication and misinterpreting
information. Underlying human factor issues, they concluded, were the reluctance of
navigators to exchange information.
In the passing years information gets more important every day for enabling a safe
passage on the same waterways as before. Bigger ships, more ships, other use of the
waterways (i.e. windfarms, oil platforms and environmental areas) reduces the
accessibility of the area.
With all these threats for the “freedom of the Sea” the ports situated alongside the
waterway (Sea) wants to have an even greater accessibility of their ports. Therefor
knowing what is happening in your port and on the fairways towards your port, is
essential. All measures supporting the processes that enable a safe and reliable
infrastructure are welcomed.
Sharing harmonized traffic images between partners is essential to enable this goal.
Sharing this information supports services like:
 port logistics, planning services (port and fairway);
 port entry of vessels, Having this information ships could decide on their own or on advice
of a VTS operator to adjust their intentions. VTS services (INS/NAS/TOS);
 SAR services;
 monitoring and management services (including the provision of “future” route advising;
 enforcement of (inter)national/regional maritime laws and regulations);
 it could even enable the possibility to provide VTS services on difficult areas like VTS
outside territorial waters;
At the ship site a huge part of the same data, next to her own data, can be used for:
 the operational processes on board for a safer, faster and more reliable journey. Saving
money on fuel and harbour fees.
 In case of an incident, taking part in an on-scene command procedure

Traffic images must be accurate, reliable, up-to-date and covering the area of
responsibility and the area of interest.
Most waterways authorities already have a complete image/coverage of their area of
responsibility, but this may not be the same as the area of interest. This area of interest
is often covered by an adjacent authority and therefore could be provided by this
adjacent authority. Sharing a harmonized image gives all parties the same and more
reliable picture of the current status of the waterway and the object they will encounter.

ACCSEAS Project Page 7 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Areas where the information is unavailable or not accurate enough, mostly further
away from shore, and most difficult cover with radar or receiving AIS data. These areas
are still sailed by ships and could share there sensor data (radar/AIS) with other ships
or the shore.
By this way the shore and ship side sharing information on a structured way could save
investments costs for information services supporting services for all parties involved.

1.2 Scope/goal of the pilot

To obtain a (more accurate) image of the southern part of the North Sea is very costly
and seems not always necessary at all times. Therefore a solution could be a
temporarily extra (more accurate) coverage of an area by radar and/or AIS when
necessary, e.g. during SAR operations or the establishment of temporary VTS outside
the regular VTS areas.
The goal of the pilot was to obtain and share a traffic image of the whole of the North
Sea area and share this with all partners (cross-border/cross-responsibility) around the
North Sea for their tasks. This implicated connecting the shore based systems of these
partners to each other and share the data. This will give each partner next to its own
area of responsibility a verified picture of the area of interest covered by a partner.
But some part of the area of interest is not covered on the North Sea by shore systems
but will, when this is available, help for safety and logistics on. The main interest will be
where ships are sailing. If these ships could share their traffic picture with others (ships
and shore) a common shared traffic picture of the areas of responsibility and interest
would be available for every partner (ships, shore, planes, oil-rigs etc.).
Better and more accurate information about an area of interest by using on-board radar
images and/or AIS. Particularly in case of an incident the on-scene command is in
some cases on board of a vessel nearby the location of the incident. The on-board
radar/AIS information may provide very useful information for the SAR Authority to
handle the incident. Because when there is more distance between the radar sensor
and the target, the accuracy will get less, what will result in smaller objects not being
detected.

1.3 Current status

At the moment, the Netherlands Coastguard is connected with several domestic VTS
systems providing the Joint Rescue Coordination Centre (JRCC) at the Coastguard a
real-time picture of the complete Exclusive Economic Zone (Netherlands part of the
Continental Shelf). This picture consists of fused radar and/or AIS data. It should
however be noted that only the coastal waters are covered by radar, which of course
makes this part of the overall picture more accurate and reliable, the rest is only based
on AIS data.

ACCSEAS Project Page 8 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Figure 3: Current sensor (radar) coverage

In case of incidents or with the extension of VTS outside radar coverage, it will be very
useful to have on demand access to on board radar image of vessels navigating in that
area.
A larger image, exceeding the boundaries of the Dutch Exclusive Economical Zone,
could help to fulfil the objectives, like:
1. safe navigation (cross border SAR operations), accessibility of ports and maritime
waters, sustainability;
2. accessibility of maritime waters (planning and the prediction of traffic intensities);
3. future management of traffic in order to enhance (or at least maintaining the same
level of) maritime safety;
4. to guarantee the accessibility of ports in the region;
5. protection of the environment.
Collaboration between all relevant stakeholders in order to defy the identified future
challenges and risks for the North Sea Region is considered to be inevitable.
Sharing data and information with the relevant parties on shore and ship side in the
Netherlands and abroad like the UK (VTSs, MRCCs) could enhance the effectiveness
of the separate bodies. Sharing of information will improve their tasks.

1.4 Description of the Harmonised Data Exchange Service

The IVEF Service is intended to provide a common framework for the exchange of
real-time Vessel Traffic Image1 information between shore-based e-Navigation
systems, such as VTS systems, e-Navigation stakeholders and relevant external
parties. The IVEF Service is described in IALA recommendation V-145 and may be
revised based on the results of the ACCSEAS test.

Figure 4 shows a situation, where VTS centres share information about the common
operational area and also to relevant other users and authorities.

1
The consolidated information about vessels and their movements in a particular area of interest. This information may
be presented in different ways according to the task at hand.

ACCSEAS Project Page 9 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Figure 4: The IVEF Service in operation

The current Harmonised Data Exchange Service is client/server-based on the IVEF

(IALA V-145) protocol. Clients make a connection to a server, running the IVEF
Service and receive traffic image data according to their specific preferences and
authorisations (Figure 5). It should be noted that different clients may specify different
data requirements, such as the area of interest, the update frequency and the
particular traffic objects that are relevant to them. Based on the client credentials, the
IVEF Service will enforce restrictions on the data that is being provided to the client.
These restrictions can be specified by the data provider.

Figure 5: The IVEF Service Client/Server Model

The previous text gives the current situation as installed and operational in the
Netherlands.
Essential is the means of communications for connecting all stakeholders (Coastguard
centres, vessels, SAR-units) what can be done through the “Maritime Cloud”.
This situation is shown in Figure 6 below.

ACCSEAS Project Page 10 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Traffic
Image
Traffic
Image
IVEF
P&O passenger ship service
IVEF
IVEF service VTS Port of Rotterdam
IVEF
IVEF
(optional)

Traffic
IVEF Image
Maritime Cloud
IVEF
service Dutch
Coastguard VTS
IVEF
IVEF
IVEF
Traffic
Image
Traffic
Image
Govermental ship IVEF Traffic
service Image
IVEF
service Coastguard
IVEF
VTS United Kingdom
service VTS
Harwich

Figure 6: IVEF Maritime Cloud

1.5 Considerations
During the project there were several considerations for testing and using the IVEF
service in combination with the Maritime cloud. The following considerations were
taken into account:
1. The maritime cloud makes it possible to manage the subscription/use of the
traffic image exchange service;
2. The maritime cloud makes it possible to switch between different
communication channels. In this way always the most efficient communication
channel can be selected;
3. The IVEF service is already in use (shore to shore)and is a recommended
service by IALA (V-145);
4. The IVEF service is tested and used in the Netherlands to connect VTS centres
and the Coastguard centres with each other.
New technology, like the “Maritime Cloud”, may make it easier to share data
transnational between VTS centres and/or vessels. Using this gives other opportunities
than available when the IVEF protocol was invented but also gives new challenges
with privacy laws.
Unfortunately, due to lack of time, sharing the data through the Maritime cloud could
not be tested but it has a great potential for sharing this data.

ACCSEAS Project Page 11 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

2 Description of Developed Service

2.1 Pilot setup
For the pilot due to time the possibilities were limited for reaching the ultimate goal.
Therefor a smaller pilot was eventually emphasized where available possibilities were
used. As described before we used the already installed connection of the shore
systems and fed this data into a separate environment, not to influence the operational
system.
Next to this also the data (radar/AIS) from the ships sensors was fed into this system.
The system fused both data streams to one complete traffic picture. This picture was
shared on the shore and ship side.
On the shore side it was send to the VTS operators at the Coastguard. The ship also
received a part of the picture approximately 50 nautical miles around the ship (could
have set larger if the data communications connection would allow this.
By sharing the data to the VTS operators they would get better and more accurate
information than with only the shore based system. The VTS operators used this
information for their VTS tasks like INS, NAS and TOS. But also the law enforcement
users from police, customs could use this information plan their actions.
On the ship side the information was displayed on a extra screen and officially (due to
the pilot state and dependencies) could (not) be used for navigation. But it could be
used for law enforcement tasks performed by the ship and when assisting with SAR
operations.
During the test a comparison of the VTS picture from shore side (left) was made with
the same picture but enriched with the information of the vessel (right side). In the next
picture (Figure 7) on the right side extra targets can be seen mainly in the red circle.
Where the Barend Biesheuvel has a label.

Figure 7: Comparison screens

2.2 Starting point

The drawing (Figure 3) gave the possible theoretical overview of the ultimate solution
for conducting the tests. This solution had the following starting points described:
1. The test systems will re-use data of the systems already in place. The re-use of data
may never interfere with or influence the operation of the existing systems. Therefore
data will not incorporate in the systems already in place. This to ensure that the
systems will not be influenced by the test systems of ACCSEAS;

ACCSEAS Project Page 12 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

2. For all the tests within ACCSEAS the same equipment/environment will be used unless
this is not possible. By this it will be more cost effective and unnecessary
use/placement of equipment will be minimised;
3. All tests will be conducted on the same ships/infrastructure unless this is not possible.
This is also a result of the previous item.
To perform the tests the following conditions were needed:
1. Availability of vessels;
2. Communications between systems;
3. Connection between the ACCSEAS test systems and the on-board or local systems
when needed;
Due to several reasons these starting points were not solid and were adjusted during
the tests.
2.2.1 Radar
The next picture (figure 8) gives an overview off the range and detection of radar. The
picture makes is clear that ship further away from the sensor are only detected if big
enough, so small vessels are best detected nearby the radar sensor.

RADAR beam

RADAR
Passenger vessel

Figure 8: Radar coverage

During the tests all present on-board (radar/AIS) sensors were used. But to make
these sensors usable for the test adjustments/expands had to be made on the
technical installation to make it usable for the pilot. This installation differs from the
shore site installation, due to the technical requirements defined by IMO and the
restrictions on board regarding space available .
For the tests we used the on board systems and forwarded the data from these
systems. The next picture (Figure 9) gives an overview of the sensors needed for
generating the on board picture.

ACCSEAS Project Page 13 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

GPS antenna

AIS
RADAR

NMEA
NMEA
ARPA
(NMEA)

ECDIS

Figure 9: on board sensors

Radar data can be transmitted in different ways between parties. In principal there are
three ways to transfer the data:
1. Raw video; this is the raw data received from the different sensors like radar,
AIS and GPS.
2. Extraction (plots); These are the interpreted RAW radar picture to a defined
description of this radar image with an absolute position of the ship
3. Tracking (tracks); this is the fused picture from radar and AIS with the exact
position in the envelope (IVEF).
These have all their advantages and disadvantages which are summarized in the next
table:

Description Sources Advantage Disadvantage

Video 1. ARPA Optimal fusion at shore side Most bandwidth

(radar)
2. GPS

Extraction 1. ARPA 1. Absolute position to the Less bandwidth

(radar) ship
2. GPS 2. Fusion at shore side

Tracking 1. ARPA 1. Smallest bandwidth

(radar) needed
Possible information
2. GPS 2. No extra interpretation of loss from RAW
“image” radar
3. AIS
3. Fusing at source

Concluding from the table sharing of track data is the most efficient way and is
supported for instance by IVEF services.
Next to the IVEF service there are also other possibilities to share this information. A
possibility is using AIS. During the project it was decided to use IVEF and not to use
other services like AIS, based on the following reasons:

ACCSEAS Project Page 14 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

1. The data shared with AIS is only within the range of the ships, so the shore could miss
this information. This could off course be received by shore infrastructure but the start
point was that this was not available;
2. The AIS VHF Data Link could be overloaded in high density areas;
3. Due to privacy laws sharing this information with non-governmental agencies is
difficult/not allowed and could not be encrypted with AIS;
4. In case of an accident based on the (wrong) information shared parties could be hold
responsible especially if they are non-governmental bodies.
These reasons in combination with the time to solve some of the issues, was the
reason that the IALA standard IVEF was chosen with other combining standardised
products. This suite of product could protect (encrypt) the data and was transferred by
other means than over the AIS VDL.

2.3 System Setup

The following figure 10 shows the physical implemented test system:

Coastguard VTS
RADAR Display Traffic image
ARPA IVEF
(NMEA)

GPS antenna
NMEA

NMEA IVEF VSAT IVEF

NMEA VSAT provider

Connection Display
AIS On-board IVEF de-encriptor chose Gateway ISIS test server
NMEA
IBS
3G/LTE Mobile provider
Heading

Figure 10: Implemented

The main hardware components (already present, within red line= extra) are
 Sensors (radar, AIS, GPS and heading)
 The on-board IBS system
 A converter RS322 (IBS NMEA) data to TCP/IP (not shown);
 A device for converting and fusing sensor data from the IBS to IVEF;
 A screen to present the Harmonised VTS picture
 A router determine the preferred connection and to limit the throughput;
 A mobile 3G/LTE data unit;
 A VSAT infrastructure;
 An HITT ISIS server. This server merges the KWC traffic image with the received on-
board traffic image and send it back to the ship.

The software components are displayed in figure 11:

ACCSEAS Project Page 15 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Radar/AIS/
Sensor Data IVEF
Heading ISIS
Converter Coastguard
(IBS)

ARAMIS Decoder Encoder Decoder Encoder

Data LInk Data LInk

On Board On Shore

Figure 11: Test system software components

The main software components (Blue = off-the-shelf, Red = development) are

 A converter from the sensor data in IBS data format to IVEF;
 An encoder/decoder from IVEF to compress data and link format also vice versa. For
efficiency reasons, the data link format will not be the IVEF xml text format. It will be
compressed;
 An ARAMIS display on the ship;
 An HITT ISIS server. This server merges the KWC traffic image with the received on-
board traffic image.

Figure 11 show that mostly standardised products are used for realising the pilot
system with the on-board Integrated Bridge System. What resulted in a faster process
of realisation of the pilot system. Another solution was a ship without a suitable IBS but
should need more components to accomplish the same result. Two other vessels
where investigated for the pilot. They had the right sensors on board to use off-the-
shelf products, but not suitable for this first test in case of traceability.

2.4 Connection between ship and shore

There were two options for communication between the shore systems and the ship
systems. The “old” point-to-point connection type or the new Maritime Cloud.
The Maritime Cloud is a digital Information Technology framework consisting of
standards, infrastructure and governance that facilitates secure interoperable
information exchange between stakeholders in the maritime community using the
principles of Service Oriented Architectures (SOA). For a detailed description of the
Maritime Cloud, which is also open source, please refer to http://maritimecloud.net.
The intention was that IVEF should use the Maritime Cloud Messaging Service (MMS)
for sharing its real-time picture like services such as intended route exchange, route
suggestions, MSI-NM and text messaging. A vessel will broadcast its own real-time
picture periodically via MMS, and all interested parties (i.e. vessels, VTS centres, etc.)
will hook up as listeners for this message type and receive the real-time picture.

ACCSEAS Project Page 16 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Figure 12: Broadcasting through the Maritime Cloud

The Maritime Cloud and the “old” point-to-point connection both needed a internet
connection at all times to operate. Internet connections on a ship going outside of the
mobile networks are expensive and the bandwidth is limited. Next to this the primary
tasks of the ship also used internet connections and could not be interfered by the
pilot.
To realise an internet connection that would reduce costs and not interfere with the
primary tasks, a combined connection type was introduces with bandwidth
management. (See figure 9) This solution makes use of LTE/GSM network when
available and the VSAT connection when outside of the LTE/GSM networks. Also
when operation on the VSAT communication bandwidth was maximised to 200Kbit.
To detect, switch and apply bandwidth management an extra router was placed whom
had these features. After configuring the router switching from LTE/GSM network to
(on-board) VSAT and back was detected and managed by the router. This router is in
this pilot system the single point of failure but could be fixed in a permanent solution.
As mentioned before the pilot should have used the Maritime Cloud but was impossible
to realise in the time frame. Therefor a point-to-point solution was chosen by building
an secure tunnel between the ship pilot system and shore pilot system using the
realised internet connection.
This seemed to work fine but after some tests we found out that during the network
switch (VSAT – LTE/GSM) the secure connection did not reconnected. After
investigation the server process seemed to be crashing due to the switch and
additional functionality was build. Changing the “old” point-to-point connection to the
Maritime Cloud would solve this problem.
The Maritime Cloud has no centralised system where every client has to connect to is
has a common architecture to connect to and if one part fails another part takes over.

ACCSEAS Project Page 17 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

3 Observations and Feedback

There were several positive observations at the end of the project.

3.1 Reactions of the end users:

The involved persons on board of the coastguard vessels and at the Coastguard
centre were very enthusiastic about the usefulness of the information. Some of their
reactions were foreseen but others came when the project progressed.
Ship side:
1. The functionality gave the possibility to see further than their own sensors could
detect. Therefor they could locate ships earlier what gave them more time to plan;
2. They had the same picture as on shore as on the ship what gave no information gap
between ship and shore side. This resulted in less (mis)communication;
3. Drifting buoys or other drifting material without AIS could be identified and
transferred to the shore side
4. vessels without AIS (like pleasure crafts) coming into the area were detected earlier in
the area where shore based radar images are available;
5. Extra data not present on the ship added on the shore side became available on the
ship.
Shore side:
1. Smaller targets further away from the shore infrastructure could be tracked due to the
higher accuracy of the information from the on-board radar systems;
2. AIS targets with transmission problems could in some cases not be received by the
shore system due to distance to the closest base station. These were received by the
ships AIS mobile station and then transferred to the shore side;
3. Targets only detected by one of the shore infrastructures sensors could be verified by
the sensors on-board of the ship.

3.2 Organisation
Doing a pilot in an operational environment, like is done with the IVEF pilot encounters
several organisational problems and challenges. These organisational issues gave
restrictions to the technical solutions and had a large influence on the realisation of the
pilot set-up.
A big issue when doing a pilot also involving a ship is that the ship is at sea several
days in a row what makes planning very important. In a (large) organisation like
Rijkswaterstaat, you have to deal with several departments, each with their own
responsibility. When you have the agreement of the coastguard to take part in the pilot,
your still not ready to go forward. You need to deal with the sections responsible for
planning, for the technical systems on board, technical systems on the shore side, PR
department, etc.)

ACCSEAS Project Page 18 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

Current sensor (radar) coverage Possible sensor (radar) coverage

View from ships bridge Harmonized view on ship

Harmonized view on ship (zoom) Small ship used during test

Figure 13 – Results from the trial in ACCSEAS.

3.3 Technical
3.3.1 Shore side
During the technical installation of the pilot the problems at the shore side were mainly
getting access to the Coastguard network on a safe manner. Problems with different
contractors was not an issue because both systems (ship and shore side) were build
and maintained by the same contractor.

ACCSEAS Project Page 19 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

The connection between the Coast Guard system and the pilot system was easy
because the products were the same, and both capable of sending and receiving IVEF.
Regarding the connection between the ship and pilot shore systems the main problem
was the change of the transmitter (IP) address, due to switching between mobile
network and VSAT network. This was solved by a VPN network connection.
3.3.2 Ship side
During the selecting of the pilot ship, there were several issues to take into account:
1. Difference in equipment on board of ships;
2. Finding the right maintenance company of the on board systems;
3. Changing of the maintenance company of the on board systems;
4. Capability of the equipment on board of the ship;
5. Which communication systems are present on board of the ships (mobile/VSAT?)
By connecting the ships sensors there were two options one was connection to an IBS
system and another was connecting to the sensors directly (radar). The first option
gave the possibility that the operator could fine tune the reception of targets. The other
was that there is no human interference but fine tuning would not be possible. In case
of the test and the traceability, the first option, connection to the IBS system was
chosen.

3.4 Overall Advice

During this pilot several issues were encountered what resulted in the following advice.
Organisational:
1. Find the right contacts on all sides (make a stakeholder map) whom are interested and
motivated to help;
2. Make an inventory of possible problems the parties could encounter. Like:
a. Operational;
b. Legal;
c. Organisation;
d. Political;
e. Goals;
f. Technical.
3. Explain the importance of sharing data for their process but also explain the possible
problems and project them on their goals and problems it would fix;
4. Make clear that “Cloud” thinking (sharing data instead of collecting it on your own)
will fullfill the user need better, faster and cheaper;
5. Make clear that possible future budgets cuts will empazise the need for sharing and
collecting data because there is not enough money to realize your own system.
Technical:
1. The Maritime Cloud could in the future solve problems with sharing data to all
stakeholders. For making use of the Maritime Cloud some issues should be solved:
a. Legal matters for privacy and responsibility matters;
b. Fusing process where should that be done;
c. Rights whom can see which data.
2. Technical connection through the IVEF protocol is a good solution in cooperation with
the Maritime Cloud. Most functionality is incorporated in the protocol. Secure
connections and compression if the data is not incorporated. This was done
intentionally because these are evolved more rapidly than the IVEF.

ACCSEAS Project Page 20 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

3. Sensor data from and to systems should be more standardized and should be held
mandatory by official bodies like IMO, IHO and ITU.

ACCSEAS Project Page 21 of 22

Service Description: Inter-VTS Exchange Format Issue: 1 Approved

4 Material Investments
4.1 ACCSEAS Legacy: IVEF Hardware
For the ACCSEAS IVEF demonstration, the following equipment was purchased to
provide the functionality that was required:

Table 1 - Equipment purchased for the trial under ACCSEAS.

Quantity. Equipment purchased Description

1 Console Consists of a display and a processing unit to process

the ship sensor data to IVEF and display the received
harmonized picture
1 ISIS A centralized CVE that processes and fuses the data
received from the ship and the shore systems.
2 Datacom equipment To enable a seamless switch between different
operators and bandwidth management
1 MoXo converter Converting signals to a network enabled connection
signal.

This equipment was purchased by RWS, to carry out the tests in the Netherlands on
the test bed areas. The tests will be carried out during and beyond the end of the
project to emphasize the potential to several stakeholders
The tests during the ACCSEAS project have already shown that IVEF using is feasible.
Further tests will be required after the project has ended to determine the potential.
These tests should show that a full position solution is possible with the technology,
providing harmonized picture on-board vessels and shore. This would be a very
significant legacy outcome for ACCSEAS.

ACCSEAS Project Page 22 of 22