2002
Test of AIS
A
step on the path to AIS-Aided Navigation
October
26, 2002
Marine
Management Consulting
I.
Index
II.
Project
Overview
III.
Objectives
IV.
The
Process
A.
Organization
of the Test
B.
A
typical AIS Event
V. Lessons
Learned
A.
Transponder
Inter-Operability.
B.
Sensor
Input to Transponders.
C.
Integration
of AIS into Bridge Systems.
D.
Broadcast
of Environmental Conditions.
E.
Summary
of Lessons Learned by Bridge Teams.
VI.
Summary
VII.
Recommendations
A.
Non-SOLAS
Ship Carriage of AIS
B.
Re-broadcast
ARPA Targets.
C.
Make
AIS part of the Integrated Bridge System.
D.
AIS
effect on VHF Communications.
E.
Transit
Schedule.
F.
AIS
and Navigation Aids.
G.
Environmental
Conditions.
H.
Messaging.
I.
Verification
of own ship transmissions.
J.
Display
Preference Profiles.
K.
Target
Display.
L.
Target
Table.
M.
Target
Information Display.
N.
Target’s
ROT display.
O.
Entering
Static & Voyage Information.
VIII.
Acknowledgements
Appendix A..
In this project the Bridge Teams of 3 modern cruise ships
evaluated the current implementation of AIS during the summer of 2002 while
cruising British Columbian and S. E. Alaskan waters. Their evaluation resulted
in findings and recommendations aimed at improving its value as a navigation
aid.
Bridge Teams formulated their recommendations so
specifically that, in the process, they defined the meaning of ‘AIS-Aided
Navigation’. They developed detailed specifications of how AIS should aide
navigation and what changes should be made both to the system and its
environment to attain true ‘AIS-aided navigation’ as a state of the art in
all of its aspects and dimensions.
AIS was found to be a potentially very powerful tool
that, if implemented correctly, will reduce the number of near-misses and
collisions because it will significantly improve the OOW’s ability to
anticipate and avoid potential collisions. Anticipation will be
improved primarily by AIS’ extended range, its capability to see around a
point and by improving target’s path predictions. Avoidance will be improved
by clearly identifying targets for hailing purposes via VHF.
The
original main objective of the test was to verify that AIS allows a ship's
Bridge Team to become aware of nearby vessel traffic that cannot either be
seen visually, or acquired by ARPA due to topographical features, even if
other ships carry transponders from other vendors.
The
second objective was to determine to best way to integrate AIS into the
electronic chart or radar display. This objective was broadened during the
test to include development of specific recommendations to improve the value
of AIS as an aid to navigation.
Due
to various technical difficulties three other objectives could not be attained
during the test:
·
Test
Inter-operability between AIS and Non-AIS transponders through a gateway on
Bowen Island
·
Assess the
effect of AIS on VTS communications
·
Assess the
value of broadcasting real-time environmental conditions via AIS
To
ensure that Bridge Teams’ recommendations lead to actual AIS improvements,
this report will be distributed to all who are in a position to act on them.
This includes:
·
All relevant
committees and work groups of IMO, IALA, IEC, ITU
·
Coastal
Authorities and VTS Operators
·
AIS
Information Display Vendors
·
SOLAS Ship
Operators
The
recommendations, along with this report, will be published on www.bcmarine.org/wmc,
were briefly discussed at an AIS Seminar in Vancouver on September 30th,
2002 and will be discussed at an AIS Conference to be held in Seattle on
November 19th, 2002.
Readers are encouraged to comment on the recommendations
by responding to:
Rick
Bryant
Secretary
Western Marine Community Coalition
100 - 1111 West Hastings Street
Vancouver, British Columbia
V6E 2J3 Canada
bryant@bcmarine.org
www.bcmarine.org/wmc
This project was an initiative of the Western Marine
Community (WMC), an association of shipping interests based in Vancouver, BC.
WMC received funding from the Canadian Coast Guard, Transport Canada and the
North West Cruise-ship Association. Holland America Line-Westours, Inc, Royal
Caribbean Cruises, Tideland Signal Corporation, Transas Marine and Radio
Holland (Canada) provided in-kind funding for the project. WMC awarded the
contract to manage the project to Marine Management Consulting.
Invitations to participate in the test were extended to
cruise lines in January 2002. Celebrity Cruises, Holland America Line-Westours,
Inc. and Royal Caribbean Cruise
Lines accepted the invitations but, eventually, Celebrity Cruises had to
withdraw from participating in the test due to technical reasons.
The Bridge Teams of 3 cruise ships conducted the test of
AIS in British Columbia and S. E. Alaska.
The
ships involved in the test were
- VOLENDAM
- ZAANDAM
- VISION
OF THE SEAS.
Holland America Line-Westours, Inc.’s VOLENDAM and
ZAANDAM are sisterships:
Length
238 m
Beam
32 m
GRT
63,000
Speed
23 Knots
Passenger
Capacity 1440
VOLENDAM
entered service in 1999 and ZAANDAM in 2000.
VOLENDAM
They are equipped with SAAB TransponderTech transponders
that are connected to a Leica Display. They are also connected to a NaviSailor
3000 ECDIS Version 2 and to sensors for Heading and ROT. The ECDIS receives
ARPA target information from the NACOS Integrated Bridge System (IBS), which
is manufactured by STN Atlas Marine Electronics, GmbH.
VISION OF THE SEAS
Length
279 m
Beam
32 m
GRT
78,491
Speed 22 Knots
Passenger
Capacity 2,200
VISION OF THE SEAS entered operation in 1998. For
purposes of the test she was equipped with a Tideland Signal/MDS transponder
that was connected to a NaviSailor 3000 ECDIS Version 2. The ECDIS was
installed on a laptop computer that was acquired for purposes of the test of
AIS. The transponder was not connected to either the heading or the ROT sensor
and the ECDIS did not receive ARPA targets, COG or SOG from the IBS (‘Voyage
Management System‘). Sperry Marine manufactures this system.
Once the transponders were installed each Bridge Team
received a pre-test briefing during which they were asked to evaluate AIS and
to present their findings and recommendations during a debriefing session at
the end of the test, two month later. The Bridge Teams were provided with a
set of criteria to use for the evaluation in a letter (See Appendix A).
The Pre-test Bridge Team Briefings were conducted July
13, 14 and 15. The debriefings were conducted September 9, 15 and 28. This
gave the Bridge Teams about two months to evaluate AIS.
During this period all three ships mostly made weekly
roundtrip cruises through S. E. Alaska from Vancouver, BC.
Also participating were 3 ferries from the British
Columbia Ferry System:
- SPIRIT
OF VANCOUVER ISLAND
- SPIRIT
OF BRITISH COLUMBIA
- QUEEN
OF NANAIMO
They were equipped with a Tideland Signal/MDS
transponders that was connected to a NaviSailor 2500 ECS.
These ferries operate between Tsawassan and Vancouver
Island/Gulf Islands or well South of the routes of the cruise ships.
All participating ships and ferries operated their
transponders on AIS1 (VHF Channel 87B) and AIS2 (VHF Channel 88B).
AIS Base stations on Bowen Island and at Delta Port
operated on AIS2 and on VHF Channel 88A. For this reason communication between
the base stations and participating ships was intermittent.
The Delta Port Base Station was set up to transmit
real-time observations of winds, currents and tides.
Other ships that were acquired on AIS in the course of
the test were a SeaSpan tug, DAWN PRINCESS, AMSTERDAM and RADIANCE OF THE
SEAS.
During the test there were about 40 ‘AIS Events’
where participating ships passed. Following is a description of a typical
event.
Here you can see the track of VOLENDAM from Juneau to
Skagway. The arrows show VOLENDAM’s Heading and COG. The AIS target for
VISION OF THE SEAS has just been acquired. It is labeled with VISION’s MMSI
Number (636010801) because static and voyage data have yet to be received that
would allow translation of the MMSI number into the ship’s name. VISION’s
AIS target was acquired at a range of 30 NM, which is typical. TCPA is 62
minutes.
It takes 27 minutes before the MMSI number is translated
into the ship’s name. The range is now 17 NM and the TCPA 35 minutes.
VISION’s ARPA target is acquired at a range of 9.5 NM
and a TCPA of 19 minutes.
Zooming in on the VISION shows minor differences between
its ARPA target (A6) properties and its AIS target (636010801) properties. The
differences are small enough for these targets to qualify for consolidation
into a single one.
Note that the VISION icon has been replaced by an outline
of the ship that is aligned with the COG and shows the position of the
transponder’s GPS antenna.
VISION is making a course change. Both its ARPA and its
AIS target leave a ‘breadcrumb’ trail (green dots). The COG of the AIS
target has changed well before the COG of the ARPA target, indicating that the
COG value that is received from VISION’s GPS is more up to date than
ARPA’s derivation of COG from consecutive radar sweeps.
VISION is now directly behind VOLENDAM and in its Radar
Blind Sector. VISION’s ARPA target (A6) is wandering over Lincoln Island
while the AIS target inspires confidence.
Transponders from different vendors were found to
inter-operate. Specifically the TransponderTech and MDS transponders did
exchange AIS information and there was some evidence toward the end of the
test that both types of transponders also received AIS information from the
Seatex transponder on RADIANCE OF THE SEAS.
The only caveat was that messages that originated from
the Leica Display were received only on the Leica display of the receiving
ship. Similarly messages that originated on the NaviSailor were received only
on the NaviSailor of the receiving ship. The root of this problem may be that
the Leica and NaviSailor use different message types.
VOLENDAM
Bridge Team
Several
times during the test ZAANDAM and VOLENDAM exchanged messages via AIS. ZAANDAM
and VOLENDAM, unlike VISION OF THE SEAS, share the same AIS set-up. Messages
originating from the messaging feature of a ship's NaviSailor were received
only on the NaviSailor of the receiving ship. Similarly, messages originating
from the messaging feature of a ship's Leica were received only on the Leica
display of the receiving ship.
IMO regulations state that own ship Heading and ROT
sensor information should be broadcast. During the installation of
transponders on participating ships a clarification of this regulation was
received from the USCG. It stated that the USCG intends to make broadcast of
this information mandatory if such sensors are already installed on the ship.
Integration of AIS in the Bridge Systems of the
participating ships was not achieved. The hurdles were too high. The STN Atlas
Bridge Systems on VOLENDAM, ZAANDAM, INFINITY and SUMMIT and the Sperry Marine
‘Voyage Management Systems’ (VMS) on VISION OF THE SEAS and RADIANCE OF
THE SEAS were simply not ready to accept AIS information and display it on the
Bridge System’s Radar and ECDIS. Standalone NaviSailor ECDIS was used
instead of Bridge Systems’s radar and ECDIS to display AIS information on
participating ships.
RADIANCE OF THE SEAS could not participate in the test of
AIS for this reason.
Another lesson learned is that Bridge System Manufactures
would rather sell their transponders rather than connect their Bridge
System with a third party transponder. Some manufacturers will set up
insurmountable hurdles for this connection even though it is the subject of an
internationally agreed standard for all seven layers of communication. These
IEC standards prescribe the communication all the way from the bottom-layer
physical definition to the top-layer application protocol and message content.
This was the reason why SUMMIT and INFINITY did not
participate in the test of AIS.
At the start of the test it was noted that the NaviSailor
was receiving many unintelligible messages. Receipt of each of those was
accompanied by an alarm, which made it difficult to work with the ECDIS
system.
The source of the messages was traced to the
environmental data that were being transmitted by a transponder at the Delta
Port terminal. It sent out updates for wind, current and tide every 10
seconds. The NaviSailor processed these binary messages as regular text
messages resulting in the false alarms for receipt of an incoming message.
Transmission of the environmental conditions at Delta
Port was stopped until a new build (#5740) of NaviSailor 3000 software that
ignores the messages could be developed and installed on participating ships.
There are no internationally accepted standards for
messages describing environmental conditions. This poses a problem for AIS
Information Display Vendors, as they have to write separate interpreters for
every region in the world that defines its own message structure and protocol
for environmental conditions.
1.
Overall Impression
VISION
OF THE SEAS Bridge Team
Pros
The
benefits of displaying AIS targets on Chart or Radar are clear.
-
It
can lead to safer navigation if used in the appropriate manner.
-
It
will ease identifying SOLAS ship traffic in order to make appropriate
passing arrangements.
-
It
can be used as a secondary source of information along with the ARPA for
collision avoidance
Cons
ZAANDAM
Bridge Team
AIS
Pro’s:
-
Will lead to safer navigation if used in the appropriate manner.
-
Gives a lot of information needed to make proper collision avoidance
decisions.
AIS
Con’s:
-
Too much information can lead to confusion.
-
System on the ZAANDAM proved to be inconsistent.
2.
Timeliness and Quality of AIS versus ARPA Information
VOLENDAM
Bridge Team
AIS
targets were acknowledged to react much quicker to a change in course for
instance that ARPA targets. Also AIS targets don't 'swap' or disappear in
shore radar echoes.
ZAANDAM
Bridge Team
In
Glacier Bay we measured the distance between the ARPA and the AIS target icon
both of the DAWN PRINCESS. It was about 3 cables, which the Bridge Team found
unacceptable. The AIS target was correct, the ARPA was not.
3.
AIS Reliability
VOLENDAM
Bridge Team
AIS
was found to be quite reliable and especially useful to identify targets in
radar blind spots. When DAWN PRINCESS followed VOLENDAM through Seymour
Narrows, she was in VOLENDAM's Radar blind sector, however, DAWN's AIS target
presented itself on screen consistently and reliably.
a)
Range inconsistent
VISION
OF THE SEAS Ron Holmes
Sometimes
when rounding Rocky Point North bound we can see the Zaandam south bound in
Lynn Canal on the AIS before it becomes visible. This is handy. At other
times, we are around the point and in plain sight of the Zaandam at 15 miles
or so and the AIS sees nothing until 12-13 miles out. It is inconsistent in
range abilities so does not become a reliable tool, just a handy one when it
is functioning correctly.
VISION
OF THE SEAS Andres Holmgren
We
have had a very different range spectrum than Volendam experienced. From 30 NM
to just a few miles. The times we had good reception it was a good tool for
all of us.
b)
Connection with ECDIS inconsistent
ZAANDAM experienced intermittent problem with the
connection between the transponder and the NaviSailor ECDIS.
These problems continued at least through October 20th after
it’s dry-docking
Bridge Team recommendations for improvement of AIS can be
summarized as follows:
Following are the recommendations that, if adopted, would
make AIS a valuable aid to navigation. Excerpts from the debriefing minutes
that relate to the topic follow each recommendation.
1.
Require Boats to carry AIS
Regulators
and Coastal Authorities should require boats that are longer than 20m to carry
AIS.
2.
Reduce cost of Class ‘B’ transponders
Regulators
should minimize the barriers that prevent Non-SOLAS ships from carrying a
transponder. Specifically, regulators should simplify the technical
requirements for Class ‘B’ transponders, for instance by eliminating the
requirement that they operate on VHF Channel 70 and by limiting frequency
agility to only the higher frequencies close to AIS1 and AIS2. This will
significantly reduce the component and production costs of Class ‘B’
transponders.
3.
Rebroadcast ARPA Targets
Coastal Authorities should broadcast ARPA targets
of ships and boats that don’t carry AIS and are longer than 20 m LoA. Such
‘virtual’ AIS targets should at least include the name and callsign.
VISION
OF THE SEAS Bridge Team
All
vessels need to have transponders. They possibly should be segregated into two
or three groups:
This
would give the operator a clearer picture of any development of close quarter
situations and it will enable more rapid identification and communication with
conflicting traffic.
Pilot
reaction has been mixed but mostly very positive. The Pilots agreed
overwhelmingly that all vessels, especially fishing vessels, should be
required through regulation to carry transponders.
VISION
OF THE SEAS Ron Holmes
All
in all in is a nice system with many good uses. However, it would be 1000%
more useful if the vessels not participating in traffic schemes were required
to have transponders. This would include but not be limited to Fishing vessels
and Small commercial Vessels such as day trip pax vessels and towboats. I have
only used this in Alaskan and B.C. waters and in these areas we have had
Pilots on and/or were participating in a traffic management scheme. Therefore,
we knew the large vessels in the area and did not need to ID them. It is the
small vessels, especially the commercial Fishing Vessels that interfere in the
safe navigation of the vessel. It would be a wonderful deterrent if they were
easily identifiable by name. This would cut down on dangerous crossing
situations and make calling the correct vessel when needed while sailing in an
area of several Fish boats much easier.
VISION
OF THE SEAS Andres Holmgren
My
personal opinion is that the AIS-system has to be implemented on all size
vessels until it can be really useful for merchant marine vessels. Until then
it can only be used as an extra help in navigation and not as equipment that
you should trust fully upon.
VISION
OF THE SEAS Gustav Andersson
Usually
it has been with the “small boats” that we have the problem. The big ships
are carrying pilots, we all know in advance what ship will come around the
corner and we have the VTS to report to. The smaller crafts are not
participating in any system and therefore a hazard us. On the other hand, what
info can they transmit, what equipment do they have. GPS to send Pos, COG and
SOG, but nothing else.
ZAANDAM
Bridge Team
Problem
ships in Alaska are the small vessels and those ships are ones who do not have
AIS. Rules of the road should be followed at all times. Fishing boats should
have AIS too.
This
recommendation was given in point A.3 above. It is repeated here for a
different reason. If APRA targets are re-broadcast then it will allow the OOW
to unambiguously associate ship names mentioned in VTS traffic advisories with
targets, thus improving situation awareness. The same is true for other vessel
traffic related VHF communications, either between VTS and a ship or between
ships.
VOLENDAM
Bridge Team
The
Bridge Team would prefer if VTS rebroadcasts ARPA targets of ships over 20 m
LoA that do not carry a working AIS transponder. Such re-broadcasts should not
only include ARPA information about Position, COG and SOG but also and most
importantly the name of the vessel. Doing so will improve the OOW's
situational awareness not in the least because VHF traffic can be associated
with the target of the ship that is transmitting.
Terry
Sampson (Canadian Coast Guard, VTS Vancouver) commented that identification of
ARPA targets by VTS operators is not fool proof and that sometimes ARPA
targets' labels are swapped.
VISION
OF THE SEAS Gustav Andersson
It
would be a tool, but again it’s not the VTS liability to ensure that the
info is received correct.
ZAANDAM
Bridge Team
Also,
VTS should transmit its ARPA targets of ships > 20m that do not carry an
AIS transponder.
Bridge Teams feel that AIS information should be part of
the Integrated Bridge System (IBS) because it is unsafe to require the OOW to
watch a separate AIS screen as well as the (multiple) Radar and ECDIS screens.
Too much of the OOW’s time would be required to interpret and assimilate AIS
target information presented on the AIS screen and then associate it with
visually observed targets and with ARPA target information presented on other
screens. This is too distracting and could make AIS a deterrent rather than an
aid to navigation.
A three line ‘Minimum Keyboard Display’ of AIS
information was felt to be unacceptable.
The resulting recommendation for Manufacturers of
Integrated Bridge Systems is to allow a Ship Operator to upgrade the software
of an existing Bridge System at a reasonable cost so that it will display AIS
information on the systems’ Radar and ECDIS screens.
The resulting recommendation for Regulators and Competent
Authorities is to require SOLAS ships to integrate AIS information in existing
navigation screens and disallow setting up AIS as a separate stand-alone
(black) box with a 3-line display.
VISION
OF THE SEAS Andres Holmgren
There
was no integration between the two systems (AIS on ECDIS and the Integrated
Bridge System) on Vision. One good thing would be if the AIS targets could be
fed into our VMS (Integrated Bridge System).
VOLENDAM
Bridge Team
The
Bridge Team appreciated that AIS information was integrated in ECDIS but would
very much prefer to have the option to, also, show AIS targets on the active
Radar. The Leica GPS/AIS display although useful for a listing of AIS targets
wasn't felt to be useful in assessing the traffic situation mostly because it
doesn't relate AIS targets with Radar targets. Simon (Navigator, VOLENDAM)
indicated that for situational awareness purposes the ECDIS rather than
the Radar is used because it not only shows nearby traffic it also shows it in
the context of the relevant navigation chart.
ZAANDAM
Bridge Team
The
Bridge Team on the ZAANDAM wondered if there is an option to show the
AIS-targets on the radar screen, with an option to select which information to
show. STN-Atlas has this option. Why is it not available? AIS information
should be displayed both on radar and on ECDIS. Close-quarters navigation is
done with the radar. AIS needed on radar to show ship names.
1.
With VTS
Bridge Teams feel that it is desirable to minimize VHF
traffic because it reduces the number of things the OOW has to focus on. Thus
an AIS-equipped ship should not be required to report its particulars, nature
of its cargo, destination, position, etc. because AIS was designed to do this
without Bridge Team involvement. Bridge Teams, however, recommend that VTS
personnel continue to provide traffic advisories. These advisories are needed
by ships that do not carry AIS as well as by those that are, to improve
situation awareness.
To further reduce VHF traffic it may be desirable for VTS
to replace traffic advisories that are currently communicated to each
individual ship with generalized traffic advisories, especially if VTS
re-transmits ARPA targets via AIS. Such traffic advisories for AIS equipped
ships should to focus on the intentions of nearby traffic.
It may be desirable to also ‘publish’ a ‘Traffic
Control List’ of nearby traffic including each ship’s name and intentions
and use AIS to continuously update this list, much like the lock-through
schedules published by the St Lawrence Seaway VTS.
The resulting recommendation to Coastal Authorities is to
eliminate call-in points after an initial VHF communication to verify and
confirm that AIS information received by VTS is correct and up to date.
Another recommendation for Coastal Authorities,
Regulators and manufacturers of AIS display systems (IBS, Radar, ECDIS) is to
allow Bridge Teams to evaluate the merits of a ‘Traffic Control List’
(continually updated list of nearby traffic).
VISION
OF THE SEAS Bridge Team
During
the test Vancouver VTS (MCTS) operators we not able to see AIS targets. The
Team doesn't think it will affect VHF traffic with VTS because it will still
need confirmation of nearby traffic.
VISION
OF THE SEAS Gustav Andersson
It
is not the VTS responsibility nor liability to make sure that ships make
arrangement to clear each other and what confirmation does the VTS have that
the OOW has received the advise?
VOLENDAM
Bridge Team
He
(Simon Westall, Navigator, VOLENDAM) does expect that VHF traffic with VTS
operators will be eliminated because all information that is currently relayed
via VHF to VTS operators is being by transmitted via AIS. Even advisories from
VTS operators should be transmitted as (addressed or broadcast) AIS messages.
This reduction in VHF volume is expected to enhance safe navigation because it
reduces the number things the OOW has to focus on.
ZAANDAM
Bridge Team
Ship
to VTS reporting should be eliminated, however VTS operators still will need
to provide traffic advisories
2.
With other Ships
Bridge Teams expect a significant rise in ship-to-ship
VHF traffic because AIS will make it possible to address a target by its name.
The resulting recommendation is for Marine Training
Institutions, Regulators and Coastal Authorities to emphasize the importance
of adherence to COLREGS and the need for the OOW to focus on watch standing
rather than answering superfluous VHF calls from other ships and boats.
Also, Regulators should prohibit and Coastal Authorities
should enforce a prohibition for small boats to contact a SOLAS ship via VHF
in congested areas when there is no safety reason to initiate the contact.
VISION
OF THE SEAS Bridge Team
Inter-ship
VHF traffic volume is expected to rise significantly.
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) expects that AIS will cause inter-ship VHF traffic
volume to rise rapidly with the introduction of AIS just because AIS makes it
possible to hail a target by name. He expects that VHF traffic volume will
subside after everyone has gotten used to AIS.
VISION
OF THE SEAS Gustav Andersson
Do
not agree…. The chat on the VHF will not stop, because instead of using the
Colregs vessels will talk to each other that they will use the colregs,
“just to be sure”
ZAANDAM
Bridge Team
The
bridge team believes that VHF traffic will increase. Knowing the name of a
ship will make it easier to call and therefore we do have to be cautious not
to use the radio too often.
Bridge Teams feel that having a ‘Transit Schedule’
for a Gateways such as a narrow channel, a lock entrance, a bridges or a cape,
will allow them to anticipate traffic rather than having to react to it, thus
improving safety.
Such a ‘Transit Schedule’ should be a list of ship
names in sequence of their assigned or estimated transit sequence. This list
should be continuously kept up to date through AIS.
1.
Published by VTS
The transit sequence should be assigned by VTS who should
also communicate the list via VHF to ships that do not carry AIS. Gateway
Icons should be clearly displayed and positioned at the ‘Gate’. Selecting
this icon should open the transit sequence schedule.
VISION
OF THE SEAS Bridge Team
The
team felt that it would be useful to have lock through schedules and transits
through narrow passages and around capes available upon selection of a base
station, but only if a (shore-based) authority controls the sequence of
transits.
VOLENDAM
Bridge Team
Waterway
Condition messages about traffic should list the ships transiting through the
'Gateway' (Narrow Channel, Lock Entrance, Bridge or around a Cape) sorted by
their Gateway Transit Time and listing their name range and bearing.
This
information should be maintained and updated regularly. It should originate
from the local VTS or, in the absence of a VTS, from ships that are
approaching a Gateway.
To
make the latter possible it would be very helpful if an (un-manned) AIS relay
station was set up near each Gateway to increase the range and thus the period
during which transit sequence arrangements can be negotiated between ships,
published on the 'bulletin board type' list and acted on by adjusting
speed/Gateway ETA. This 'do-it-yourself' approach to VTS is expected to become
a major benefit of AIS. Currently, for Seymour Narrows for instance, such
Gateway transit sequence arrangements are made by the pilots using the cruise
ship schedules that are published months in advance. These arrangements, by
necessity, exclude transit sequence arrangements with other ships passing
though Seymour Narrows.
ZAANDAM
Bridge Team
A
continuously updated transit schedule, for example through Seymour Narrows,
will be very useful as a submenu option.
2.
Using ETA’s
If no VTS is available, Bridge Teams felt it to be
unrealistic to expect ships to negotiate transit sequences between themselves.
Thus, if no VTS is available, the transit sequence should be based on each
ship’s automatically calculated ETA at the ‘Gate’ using current VMG
(Velocity Made Good towards the Gate) and remaining distance. The position of
the Gate should be selectable by the OOW. The Transit Schedule should include
ETA’s of ships that are not equipped with AIS. The latter’s ETA’s should
be based on their (ARPA target’s) VMG and remaining distance.
3.
Extend AIS range through Relay Stations
Bridge Teams felt that they could better anticipate
traffic if AIS range were to be extended by Relay Stations especially near
Gateways. Such stations would ensure that Radar blind spots near Gateways
would be filled in with AIS targets.
If Relay Stations were also equipped with Radar then they
could also be used to transmit the ‘Gate’ Icon and publish the
automatically updated Transit Schedule of all traffic via AIS.
Bridge Teams feel that AIS information received directly
from a target should supersede AIS information received through a Relay
Station.
In light of the above Bridge Teams recommend that:
Manufacturers of AIS information displays agree on icons for
Gateways where
VTS
controls the transit sequence
-
Other Gateways
-
AIS Relay Stations
Manufacturers of AIS information displays add Transit Schedule features
Coastal Authorities set up unmanned AIS relay stations near Gateways
and consider equipping them with Radar.
Manufacturers of AIS information displays ensure that AIS information
received directly from a target supersedes AIS information about the same
target that is received from a Relay Station.
ZAANDAM
Bridge Team
Extra
AIS-relay stations will be necessary in areas where the range of AIS is
limited because of mountains or other elements.
VISION
OF THE SEAS Bridge Team
If
the range of AIS is extended through a (shore-based) relay station, then these
relayed AIS targets should only be displayed until AIS information is received
directly from the target. Similarly, VTS should re-broadcast ARPA targets as
AIS targets only for vessels that either don't carry AIS or carry an
inoperable transponder.
Bridge Teams feel that it would help the situation
awareness of the OOW if major navigation aids were either outfitted with a
transponder that broadcasts their ID and position or that this information be
transmitted by a nearby (shore based) transponder. They feel that Racon buoys,
in particular, should be AIS targets. Both actual and intended buoy positions
should be shown if they differ more than .1 NM.
The resulting recommendation is for Coastal Authorities
to either equip these navigation aids with a solar panel powered Class ‘B’
transponder or to establish a shore based transponder that could possibly
serve several nearby navigation aids. It would require very little incremental
costs in VTS areas that already have an AIS infrastructure.
VOLENDAM
Bridge Team
It
was felt important to show AIS icons of Navigation Aids on the radar screen as
a back-up to racon identification of marks and to display marks that are not
racon equipped.
ZAANDAM
Bridge Team
Major
NavAids should have a transponder especially racon buoys
Bridge Teams feel that real-time actual environmental
information will enable the OOW to better anticipate own ship behavior and
maneuvering limitations as well as the behavior and maneuvering limitations of
nearby ships and thus contribute to safer navigation.
Environmental information should include currents, winds,
tides (or water levels), visibility and, for smaller vessels, wave
characteristics where appropriate. Narrow channels, bridges and areas with
high current velocities (especially near docks) should be the first to be
equipped with ‘AIS weather stations’. The position of the sensors of such
weather stations should be clearly identified by a special AIS target icon.
Selecting such an icon should open a menu. The first option of this menu
should be ‘Show’ with sub-options for currents, winds, tides, visibility
or wave characteristics. Each of these sub-options should result in replacing
the AIS weather station icon with a graphical representation that is relevant
for the variable being shown. For winds this should be:
or 
(Display
preference should be saved in the user’s profile)
The wind vector should point to the sensor position and
indicate the ‘from’ direction
For tides this should be:
The current vector should point away from the sensor
position and indicate the ‘to’ direction.
The AIS weather station main menu should also have
options to drill down to tabular and graphical representations of historical
values for each variable for the last 3 hours in 10-minute intervals,
preferably comparing actual with predicted values.
The resulting recommendation to AIS Information Display
Vendors is to establish a consensus on the standard format of the AIS message
that will carry environmental observations and to agree on a standard for
display of observations.
The recommendation to Coastal Authorities is to establish
AIS weather stations or to turn existing weather stations into AIS weather
stations. Priority should be given to broadcasting observations of (cross)
currents and winds in narrow channels, near docks, under bridges and in areas
with notoriously strong currents such as Seymour Narrows in British Columbia.
Sensor positions will not necessarily have to coincide with the location of
the transponder that broadcasts its measurements.
VISION
OF THE SEAS Bridge Team
The
team felt that weather stations along the coast should transmit their
observations via AIS and stations should be displayed on screen with special
icons. Selecting a weather station icon should open a window that shows
current observations. The team felt that historical (and trend) information of
weather observations should be available as a secondary drilldown.
VOLENDAM
Bridge Team
The
Bridge Team would very much like to receive these messages. Environmental
Condition messages should be graphical and intuitive and allow drill down to
more detailed information. For wind, for instance, Simon (Navigator, VOLENDAM)
preferred the internationally recognized meteorological 'vector with barbs'
that can be drilled down to a compass rose with both graphical and digital
values for 'from' direction and strength and can be further drilled down to
recent historical values in graphical and digital format. For currents he
prefers the 'to' direction in the fashion used to depict predicted currents on
the NaviSailor.
ZAANDAM
Bridge Team
A
very useful option, if used for broadcasting relevant safety or weather
information.
These
messages would be very much appreciated. Information will be very useful,
because it is in real time. Preferably
this information could be setup with a menu, so OOW can choose what kind of
format he/she prefers. Environmental information should be displayed direct on
the Transas screen or in a sub-menu.
1.
Ship-to-Ship
Bridge Teams feel that the Ship-to-Ship messaging feature
of AIS should be eliminated because of it is too likely that it will be used
to make passing arrangements. Making private passing arrangements would be
dangerous because other nearby ships, even if they were equipped with AIS,
would not be aware of the arrangements.
VISION
OF THE SEAS Bridge Team
Bridge
Team on Vision observes the rule that there will be no e-mailing during the
watch.
The
team felt that passing arrangements should not be made using AIS inter-ship
messaging. Safety messages should be broadcast to all nearby ships but they
should carry a date stamp.
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) indicated that using addressed messages to make passing
arrangements was regarded by the Bridge Team as dangerous because the very
privacy of this message exchange means that other ships in the vicinity would
not be aware of such arrangements. This would be especially dangerous if the
arrangements were counter to COLREGS. For this reason, the Bridge Team felt
that the ship-to-ship addressed messaging feature of AIS should be eliminated.
Broadcast messages, too, should not be used to make passing arrangements
because their audience is limited to ships that are equipped with AIS, whose
AIS is in operation and whose OOW is watching for incoming messages.
While
the Bridge Teams were opposed to making passing arrangements counter to
COLREGS it was felt that confirmation of 'COLREGS compliant' passing
arrangements via VHF well in advance was worthwhile and was made possible by
AIS through early acquisition and identification of a target.
Writing
an ‘E-mail’ can be a distraction from watch keeping and should therefore
be kept to a minimum.
VISION
OF THE SEAS Andres Holmgren
I
don’t think it will improve the safe navigation to send messages over the
AIS. It could be a tool to exchange other info, but not regarding navigating
issues. I agree on the Volendam's comments about the messages and Colreg. It
could be used as a tool for other info, but than again, it could be misused.
ZAANDAM
Bridge Team
All
available means should be used to avoid a collision including AIS messaging.
But because the audible alarm was switched off, there was nothing to indicate
that a message was received
Passing
arrangements should not be made through AIS messaging.
COLREGS should prevail at all times.
The
Bridge Team agreed that it probably would be better if addressed messages were
eliminated altogether.
2.
Between Ship and VTS
Bridge Teams feel that this type of messaging might be
useful to confirm to VTS that the own ship transponder is sending out the
correct information.
3.
Broadcast Messages
Bridge Teams feel that broadcasting an AIS target of a
floating hazard would improve safety, however VHF should also be used to
broadcast such safety messages because not all ships carry AIS and those that
do may not have it turned on or may not be watching for incoming messages. In
near collision situations all means should be used, including (broadcast) AIS
messages. Bridge Teams feel that an easy to recognize and interpret alarm
should sound when a (broadcast) message has been received.
VOLENDAM
Bridge Team
The
Bridge team, however, felt that broadcast messages were useful particularly
where it concerns safety messages such as indicating an unmarked floating
hazard to nearby ships.
VISION
OF THE SEAS Andres Holmgren
As
it is on the test computer on Vision of the Seas we do not have a fully
working electronic chart system, which we can use as a reference to our
regular electronic chart system. Because of that we do not use it all the time
when navigating, and the fact that the AIS message do not give you an alarm it
is hard pay attention to targets that comes up on the AIS computer. If
the AIS were installed on our regular Electronic Chart System I think that it
would be more useful for us.
4.
Message Confirmations
Bridge Teams feel that there should be a confirmation
that a message was sent, and, if addressed messages will be used (for instance
between ships and VTS), a separate confirmation that the addressee received
the message.
VISION
OF THE SEAS Bridge Team
The
team felt that confirmation of sending a message and of reception by the
addressee was lacking from the current implementation of messaging on
NaviSailor and should be made available.
.
VISION
OF THE SEAS Ron Holmes
There
doesn’t appear to be anything that tells you a message has actually left the
ship. You just press the “send” button and hope for the best. Also, it
would be beneficial to have the “reply” icon on the main screen next to
the incoming message to save time.
VISION
OF THE SEAS Andres Holmgren
We
have received many messages, but not been able to transmit any. Not that we
are aware of. We reply and press send and that’s all we get. No confirmation
that is has been sent, nor that it’s been received.
ZAANDAM
Bridge Team
Confirmation
of receipt of an addressed message would be very useful, as we were never sure
if a message reached the addressed ship.
The resulting
messaging recommendations to AIS Information Display Vendors are not spelled
out in detail, as they are self-evident. The only recommendation that needs
explanation is the broadcasting of AIS target information for floating
hazards. It should be made easy to broadcast such targets and it should not
involve any effort on the part of the receiving ships to display such targets.
To make it easy
to broadcast the position of a floating hazard it should be made possible to
simply enter the range and bearing to it or its latitude and longitude along
with the time of the observation and a short explanation of the nature of the
hazard. Clicking on a send button should broadcast the floating hazard’s
position along with a date-time stamp (UTC) of the observation, the nature of
the hazard and the name of the broadcasting ship. The broadcast of this target
should continue until the range to it is beyond the range of the own ship AIS.
Bridge Teams feel that it should be easier to verify that
the information broadcast by the own ship transponder is correct. There were
problems with the broadcasting of ROT sensor information and the voyage and
navigation status information was not always up to date. The only way to check
the validity of the broadcasts is to ask a nearby AIS-equipped ship.
The resulting recommendation for AIS Information Display
Vendors is to make it possible to select the own ship AIS target and drill
down to the information that is being broadcast, especially sensor
information. Or, better yet, to build in a cross check between the sensor
information being broadcast and the information used by the Bridge System
along with an descriptive alarm in case of differences.
VOLENDAM
Bridge Team
Addressed
messages were used to verify that VOLENDAM's information that was transmitted
via AIS was being received by ZAANDAM and that it concurred with current
sensor readings of position, COG, SOG, Heading and ROT. During such
verifications it was noted that the ROT transmitted by ZAANDAM and received by
VOLENDAM, while of the correct magnitude, was consistently in the opposing
direction of ZAANDAM's actual course change. ZAANDAM did not receive ROT from
VOLENDAM at all. Both ships confirmed that Heading was being transmitted
correctly.
Bridge
Teams felt that there should be an easier way to verify that the own ship
information being transmitted is correct, possibly by showing the own ship as
a target on the display and allowing 'drill down' to actually transmitted
values for relevant variables, including static and voyage information.
1.
Orientation
Bridge Teams feel that the Navigation Information Display
preferences of the OOW should be saved in his/her personal record on the
Bridge System. These preferences should control all Navigation Information
Displays, not just AIS on ECDIS. They should allow for a multiple sets of
preferences that the OOW can activate in different circumstances. For
instance, one set for daylight, one for nighttime, one for navigation in
congested areas another for open seas and still another for (un)docking/anchoring.
The resulting recommendation to Bridge System vendors is
to amend their systems to allow each OOW to save and edit personal Navigation
Information Display preference settings for each combination of circumstances.
The Bridge System should have default setting for each of these combinations
of circumstances. The selection of settings should be intuitive and user
friendly so as not to require extensive training. On-line help in setting
display preferences should be available.
VISION
OF THE SEAS Andres Andersson
Orientation
of a display (North-up, Head-up or Course-up) should default to the
preferences listed in a user's profile but should be easy to change.
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) indicated that the Bridge Team generally uses a
'North-up' orientation but that on Southbound courses many officers prefer a
'Course-up' or 'Head-up' orientation on both Radar and ECDIS. He indicated
that it might be useful to allow each OOW to save his or her display
preferences in a personal profile that could be used to change all display
preferences at once.
1.
Show Ship Type
Bridge Teams feel that it would improve the situation
awareness of the OOW if the type of ship were evident from the color of an AIS
icon because it makes it easier to associate targets with visually observed
traffic.
ZAANDAM
Bridge Team
It
would be very useful if you could recognize the type of ship you are dealing
with. Perhaps by using different colors or shapes for fishing boats, cruise
ships, cargo ships, tugboats etc.
2.
Target Label
Selected targets should show the ship name and/or the
callsign (user-selectable in the display preference profile). The callsign
will help to overcome ship name pronunciation difficulties.
VISION
OF THE SEAS Bridge Team
AIS
target icon labels should show the ship name, the callsign or both. These
options should be user selectable. The reason to label icons with the callsign
is that hailing a ship by callsign sometimes helps to overcome name
pronunciation difficulties..
3.
Suppress if < 20 m LoA
To avoid screen clutter, boats carrying a Class ‘B’
transponder and are smaller than a user selectable maximum LoA should be
suppressed and only be shown as a dot. It should, however, remain possible to
drill down on such a dot to get more detail. The default threshold should be
20m LoA.
VISION
OF THE SEAS Bridge Team
Possibility
of cluttering the screen with targets. The Team felt that it should have the
option to suppress or minimize icons of AIS targets that are smaller than a
threshold LoA value and that it should have the option to set the value of
this threshold. The team agreed that displaying boats' AIS targets as single
points that can be drilled down to more details would significantly reduce
screen clutter without losing essential information
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) recommended that Pilots be involved in formulating
recommendations for the suppression of targets of smaller boats. Terry Sampson
(Vancouver VTS) suggested that AIS targets of small boats be represented by a
small dot on the screen (i.e. not by an AIS target icon) that can still be
drilled down to a target window. Joe Bienert (Western Marine Community) noted
that Class 'B' transponders that are intended for boats, will not transmit
their LoA. The consensus of the group was that there probably should be a
threshold that is defined in terms of both the LoA and Class of transponder of
the target and the TCPA or range of the target. AIS targets beyond this
threshold should be suppressed or at least severely minimized.
4.
Consolidate ARPA and AIS Targets
Bridge Teams feel that an AIS and an ARPA target of the
same ship should be automatically consolidated into a single target to reduce
confusion and screen clutter.
The resulting recommendation to AIS Information Display
Vendors is to consolidate an ARPA and an AIS target if all following
conditions are met simultaneously:
A target’s relative speed and course should be
considered rather than it’s over ground equivalent to eliminate the effect
that the error in own ship position would have on ARPA’s calculation of over
ground values.
The default values of ‘a’, ‘b’, ‘c’ and
‘d’ need to be derived from tests, but should be user-selectable in the
display preferences profile.
The OOW should also be able to disable automatic
consolidation, in case the ARPA targets for two different ships have merged.
Bridge Teams lack experience with the reliability of AIS
information so, until they do, they feel that, if target consolidation
conditions are met, then the consolidated target should be positioned on the
ARPA target rather than on the AIS target and the relative course and speed of
the target should be set to their ARPA target values. The (T)CPA should be
based on ARPA’s relative course and speed and ignore ROT.
VISION
OF THE SEAS Bridge Team
The
team felt that target consolidation should default to 'automatic' (i.e. based
on rules that compare properties of both the ARPA and the AIS target) but that
it should be possible to disable automatic consolidation and allow manual
selection of targets that are to be consolidated. The properties of a
consolidated target should be those of the ARPA target's bearing, range,
relative speed and relative course.
VOLENDAM
Bridge Team
Although
in the opinion of the Bridge Team there is little confusion about which ARPA
and AIS targets represent the same ship, it would help in reducing information
overload if ARPA and AIS targets for the same ship were consolidated. The
Bridge Team expressed a preference for using 'average values' for information
that is available from both ARPA and AIS rather than selecting one or the
other as the most likely actual values. This is counter to current IMO
guidelines for the display of AIS information of a consolidated target.
ZAANDAM
Bridge Team
Targets
icons of the same ship should be automatically consolidated but allow for a
manual override: How do you consolidate 2 separate AIS targets with one
(blended) ARPA target?
Bridge Teams feel that it should be possible to display a
table of all targets (ARPA and AIS). The rows in this table should be sorted
by the characteristic noted in the OOW’s display preference profile but it
should be easy to re-sort the table by TCPA, CPA, Range, Ship Name, Callsign
and possibly other characteristics. Such a list would help, amongst others, in
identifying collision risks, in associating VHF communications with screen
targets and in associating visually observed traffic with screen targets.
VISION
OF THE SEAS Bridge Team
The
target table should consist of rows of targets and their properties rather
than columns as is currently used in NaviSailor. Sorting of the target table
should be at the discretion of the user, but default to ascending range. User
display preferences should be controlled through user profiles.
VISION
OF THE SEAS Gustav Andersson
We
would wish to have the possibility to sort the targets in a customized way,
CPA, TCPA, range, speed or whatever info that is received.
VOLENDAM
Bridge Team
We
were also shown the Leica GPS/AIS display. Simon (Navigator, VOLENDAM)
explained that the Leica display although small, conveniently shows all AIS
targets sorted by increasing range and listing the MMSI Number, the range,
bearing and the name of the ship. Simon explained that this feature made it
easier to identify AIS targets than using the Target window on the NaviSailor
because on the NaviSailor's Target window, the radar and AIS targets are
mingled, they don't seem to be ordered in an any fashion and the AIS targets
are identified by their MMSI number rather than the name of the ship.
Furthermore the targets are listed as columns rather than rows which would
make display of ship names difficult to fit.
Simon
asked that this target window be redesigned to show ship names and to be
sorted by TCPA or range if TCPA is not available.
1.
Opening and Closing a Target Information Window
Bridge Teams feel that an information window should open
when a target is selected. It should close with a mouse click inside the
window.
The window that opens when a consolidated target is
selected should contain both ARPA and AIS information. For unconsolidated but
nearly overlapping AIS and ARPA targets it should be easy to select one or the
other target icon, possibly by opening the one window on the first click and
the window associated with the other target with a second mouse click in the
same general area.
VISION
OF THE SEAS Bridge Team
Mouse
click to open a window (i.e. NOT mouse over)
Automatic
closing after 30-seconds could have some adverse effects for operator once the
window closes. Therefore, windows should require a mouse click anywhere in the
window to be closed, rather than closing automatically after 30 seconds.
Windows should close with a mouse click rather than a mouse
over.
ZAANDAM
Bridge Team
Selecting
a target to open its window was sometimes difficult. The Transas screen shows
two overlapping target icons (an AIS icon and ARPA icon). The radar target
window shows ARPA information and the AIS target window shows a (big) list all
transmitted information. AIS and ARPA icons are very close to each other most
of the time, which makes it hard to select the right icon. You should be able
to set a preference. So only ARPA or only AIS-information. Also the option was
discussed to provide a single window with a combination of ARPA and AIS
information. ARPA-information would be CPA and TCPA and AIS-information ships
name and MMSI-number.
2.
Target Information Display Layout
The information, shown in the window that opens when a
target is selected, should only contain values that are relevant for collision
avoidance. The values shown should default to Name, Callsign, CPA, TCPA, SOG,
COG, Range and Bearing. It should be possible to edit the default layout of
this window and save the edited layout as a display preference in the user
profile. The window should have a ‘more…’ drilldown option to view the
remainder of the information available for this target.
VISION
OF THE SEAS Bridge Team
The
window that opens when a target is selected should contain information that is
relevant for collision avoidance only (i.e Name, Callsign, CPA, TCPA, SOG,
COG, range, bearing). Other information should be available in a drill down
fashion by clicking on a 'more...' option.
VOLENDAM
Bridge Team
The
window that opens when a target is selected should contain information that is
relevant for collision avoidance only. Other information should be available
in a drill down fashion by clicking on a 'more...' option.
ZAANDAM
Bridge Team
Information
shown in the Transas target window can be too much. You should be able to
select the information you need. As
been stated before too much information can lead to confusion. The system
should allow the user to set up his/her display preferences. What you really
need is the name of the vessel and maybe his call sign. It would also be
useful to show navigation status in the target window
3.
Targets Routes
Bridge Teams feel that it is not worthwhile to make an
option available to graphically display target’s route because it would
clutter the screen with information they don’t trust.
It would, however, be worthwhile to have a more general
written description of a target’s voyage plan available as a drill down
option. A high level description of its route would probably convey a
target’s intentions more effectively and efficiently than details of its
waypoints and routes, even if those were displayed graphically.
On the receiving end this route description should be
made available as a drill down option in the target information window.
The resulting recommendation to AIS Information Display
Vendors is to suppress waypoints and routes received from an AIS target and
to, instead, design a message template that can be used to describe the
intended route with channel names. It is important to have a date/time stamp
on this message to ensure that the route is current.
AIS Information Display Vendors should agree on a
standard for a template and an identification for route description messages
and seek to have this standard sanctioned by regulatory agencies.
VOLENDAM
Bridge Team
While
it was felt that displaying a target's route, even only when requested through
a 'drill down', would create too much clutter on the screen, it was felt to be
very useful to have a target's route information available as a 'more...'
drill down option in the target window. The route information should be a
textual description of the route rather than actual waypoints and routes.
1.
Method of ROT Information Display
Bridge Teams feel that
displaying a target’s ROT-corrected predicted path will improve the OOW’s
ability to anticipate a traffic situation.
1.
Straight-line path prediction
In
the crossing situation shown above, the blue line represents the straight-line
predicted path of the own ship making 12 knots on a true course of 110° and a
target ship (red line) making15 knots on a true course of 240°. The target
initially is on a true bearing of 70° with a range of 2 NM (green line). With
straight-line projection, the CPA of .4 NM will be reached in 4.8 minutes
(light blue line).
2.
ROT-corrected path prediction
In
the same crossing situation shown here, the blue arc represents the predicted
path of the own ship again making 12 knots on a true course of 110° and a ROT
of +5° per minute (starboard). Again the target is initially on a bearing of
70° at a range of 2 NM (green line) making 15 Knots on a true course of 240°
with a ROT of –10° per minute
(portside). The red arc shows the its predicted path. The CPA is now only 380
feet after 7.9 minutes (light blue line).
The above clearly
shows the value to the OOW of taking ROT into account when predicting a
target’s path. When given the choice Bridge Teams preferred predicted path
over a flag at the end of the heading vector for display of ROT information.
VISION
OF THE SEAS Bridge Team
A
target's vector should show its predicted path calculated from SOG, COG and
ROT.
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) was intrigued by the possibility of showing a predicted
path for both the own ship and each AIS target that takes into account the
current ROT value rather than assume that this ROT is zero as is currently the
custom and the basis of CPA and TCPA calculations. He indicated that he would
need to see it work in practice and gain experience with it before he could
formulate a recommendation. He did recognize that this is a logical extension
of the trial maneuver.
2.
(T)CPA Calculation
A recommendation to AIS Information Display Vendors, that
results from the recommendation to display ROT information as a curved
predicted path, is to develop an algorithm to calculate (T)CPA that takes into
account both the own ship and a target’s ROT. Fourier-LaPlace
transformations of the necessary equations will need to be solved for CPA
because it is not possible to directly solve the equation for the distance
between the two ships for its minimum.
1.
Should be on checklist
Bridge Teams acknowledged that the Static and Voyage
information was not always updated in the transponder.
The resulting recommendation is for regulators to include
a pre-departure check in the standard Bridge procedures of the voyage
information and navigation status being broadcast.
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) acknowledged that entering AIS Voyage Information isn't
part of ISM checklists yet and that on a few voyages this information was not
updated.
2.
Provide a keyboard
Bridge Teams feel that a keyboard should be provided to
enter voyage and static data in the AIS Information Display because using it
takes too much time and effort to enter this information through a simulated
keyboard.
VOLENDAM
Bridge Team
Simon
(Navigator, VOLENDAM) explained that entering voyage data was much easier to
accomplish via NaviSailor than via Leica even though the latter has this
feature. Voyage information entered via NaviSailor is acknowledged in the
Leica display and vice versa.
ZAANDAM
Bridge Team
This
was very easy in the Transas. Doing it on the Leica was a bit more work, but
both systems do communicate with each other.
On behalf of the Western Marine Community and as Project
Manager for the test of AIS, the author would like to thank the following
people for the interest, time and effort they expended to ensure that the test
attained its objectives and then some.
Steve
Poole
Doug Alpen
Terry Sampson
Miriam
van Roosmalen
Ioannis Miskis
Nicolas Pagonis
Rose Bray
Rick Bryant
Carol Jensen
Larry Bischoff
Cees Deelstra
Morne
Stamrood
Robin
Franco
Kaare Bakke
Fred McCague
Ed Monteiro
Ken
Pike
Frank
Christophersen
Arne Baier
Wolfgang Dickert
Karl-Christian Ehrke
Doris Niemann
Matthias Westphal
Liam Crawford
Darren Hamaoki
Stewart Furness
Lards Ljoen
Eric Schreiber
Knut Skeisvoll
Andrew Szymkiewicz
Kent
Berger-North
Clive Quickenden
Doug Sprunt
Neil Bennett
Larry DeGraff
Keith Rowlett
Jim Lawson
Gurdev Mann
John Yeung
Joe Bienert
Bill English
TO:
Captain, VOLENDAM
FROM:
Larry Bischoff
SUBJECT:
Test of AIS Transponders in British Columbia/Alaska Summer 2002
DATE:
July 9, 2002
The
installation of the AIS transponder on Volendam is progressing well and it
will soon be connected to a new version of the Transas Marine NaviSailor ECDIS
(3000). The formal test of AIS capabilities will start on Monday, July 15th.
I
would like to request your assistance in this evaluation of AIS as an aid to
safe navigation and collision avoidance. The reason for asking you to do so is
that international standards for integration of AIS in bridge displays are
currently being developed by IMO. Holland America Line and Royal Caribbean
Cruise Lines intend to participate in this standard setting process.
The
main objective of the test is to verify that AIS allows a ship's bridge team
to become aware of nearby vessel traffic that cannot either be seen visually,
or acquired by ARPA due to topographical features. The second objective is to
determine to best way to integrate AIS into the electronic chart or radar
display.
You
will also be able to assess the effect of AIS on communications the Marine
Communications and Traffic Service (MCTS) center for Vancouver when you are
within AIS range of Bowen Island. Furthermore you should be able to ‘see’
ferries and tugs that carry a different type of transponder (Meteor
Communications Corporation) when in range of the Bowen Island because a
gateway between those transponders and the type carried by SOLAS ships has
been set up there. Specifically you should be able to observe the SPIRIT OF
NANAIMO, a ferry that operates between Tsawassan and Schwartz Bay on Vancouver
Island as well as a number of tugs. You should be aware, however, that while
transponders generally broadcast position updates every 20 seconds or even
less, Meteor transponders generally do so every 5 minutes.
Although
the Leica/SAAB transponder on Volendam has received type approval, the display
of AIS information on the ship’s principle ARPA or ECDIS, has yet to be
approved by IMO. You should
therefore ensure that the display of AIS information does not interfere with
the normal operation of the principle ARPA or ECDIS display of your integrated
bridge
This
test is an initiative of the Western Marine Community Council. Transport
Canada, the Canadian Coast Guard, Holland America-Line Westours, Inc., Royal
Caribbean Cruise Lines, NWCA and the following vendors are sponsors of the
test:
Austin
Navigation Systems
Leica/SAAB
TransponderTech
Radio
Holland (Canada)
Seatex
/ Kongsberg
Sperry
Marine
Tideland
Signal Corporation / Marine Data Systems
Transas
Marine USA, Inc.
The
main test will start Monday, July15th and will end upon de-briefing (see
below).
To
allow analysis of Volendam's AIS and ARPA observations, the NaviSailor log
files will need to be e-mailed or recorded on disk and sent to the project
manager of the test:
Fred
W. Pot
Principal
Marine
Management Consulting
3837
31st Avenue West
Seattle,
WA 98199-1713
+1-206-301-9626
+1-206-850-7664
Mobile
+1-206-283-7108
Fax
fpot@attbi.com
www.uais.org
A
delegation representing the test sponsors will visit your vessel towards the
end of the season to gain direct user feedback by discussing AIS with you and
your officers. This meeting is scheduled for Monday September 16 on VOLENDAM
in Vancouver, BC.
To
prepare for the debriefing, I should be grateful if your Bridge Team could
begin to develop an evaluation of AIS, including but not limited to:
1.
Keeping a manual log of AIS targets seen on the Transas NaviSailor
during the main test period (See attached Form and a listing of Inter-Ship AIS
Events).
2.
Listing pro's and con's of displaying SOLAS ship AIS targets on the
electronic chart or radar, with recommendations as appropriate.
3.
Listing pro's and con's of displaying not only SOLAS, but also non-SOLAS
vessels equipped with AIS, even boats smaller than 20 m LoA.
4.
Listing the range (or TCPA) at which SOLAS targets would be useful, the
range at which non-SOLAS targets greater than 20 m would be useful and the
range at which non-SOLAS targets smaller than 20 m LoA would be useful
5.
Ranking of AIS features (See Appendix Chapter I)
6.
Ranking of AIS Display Options (See Appendix Chapter II)
7.
Describing Involvement of BC & Alaska Pilots - their knowledge of
and their reaction to AIS.
8.
Describing the AIS effect on VHF traffic with Comox MCTS when in range
of Discovery Mountain Base station.
9.
Listing Technical aspects of AIS - i.e. ease of transponder maintenance
& operation.
10.
General comments.
Thank
you in advance for your assistance.
I.
What features should be included in AIS?
Please
rank the following (future) AIS features in order of importance for safe
navigation (the features are explained in Chapter III of this appendix):
1.
Display a target's rate of turn.
2.
Label targets with ship's name or Call sign
3.
Consolidate (Fuse) ARPA and AIS targets
4.
Relay ARPA target information to others
5.
Enable exchange of vessel traffic related messages with targets
6.
Display a target's hazardous cargo information
7.
Display information about a target's unusual maneuvering limitations
8.
Display a target's characteristics (GRT, Ship Type, LoA, draft, number
of barges, barge dimensions)
9.
Display navigational aids (displaced buoys, temporary hazards, traffic
separation zones, range markers, etc.) as AIS targets
10.
Use AIS to receive Differential GPS corrections when direct broadcasts
are not available.
11.
Display a target’s voyage information (Destination, ETA, current
waypoint, current route)
12.
Other (Specify)
II.
How should AIS information be displayed?
A.
Please rank the following (future) AIS display options in order of preference:
1.
Display a target's details in a separate window upon
"mouse-over"
2.
Display a target's details in a separate window upon
"mouse-click"
3.
Display details of all targets in a table sorted by their TCPA on a
separate screen page.
4.
Other (Specify)
B. Please rank the following (future) AIS display options in order
of preference:
1.
Close a target's details window after 30 seconds
2.
Close a target's details window upon "mouse-off"
3.
Close a target's details window upon "mouse-click"
4.
Other (Specify)
III.
Explanation of Features
A. Display a target's rate
of turn
Ships
that have a rate of turn sensor and have linked the output of this sensor to
the AIS transponder can be set up to transmit their current rate of turn as
part of their regular position update. This could be displayed as a ‘flag’
at the end of the target’s heading vector. Alternatively the expected track
of a target during the next 6 minutes could be displayed as a curved vector
emanating from the target’s current position. Should the CPA and TCPA
calculation be adjusted to take rate of turn into account?
Every
6 minutes AIS transponders broadcast "static" ship information such
as name, MMSI number, call sign and ship's particulars. The ECDIS could be
set-up to label AIS targets with the name or, if the name is not available,
the call sign. Either would be useful in contacting a target via VHF.
C.Display
a target's route & destination
If
a ship has an ECDIS, uses it for route planning, then it can include the
currently active route leg in the periodic AIS voyage details update. A
target’s current active route leg can be displayed on ECDIS or radar. The
destination could be a detailed description of its intended mooring (i.e.:
Canada Place, West Side, Portside to). The latter would be used to anticipate
a target’s docking maneuvers.
D.
Consolidate
(Fuse) ARPA and AIS targets
Allow
manual linking of AIS and ARPA icons of the same target by clicking on them.
The result would be a single icon whose position and vector is the result of
an interpolation of the values of the separate icons. The reason to do this is
to show less clutter. If there are two ARPA icons (ARPA A & ARPA B) and an
AIS icon for the same target, the targets would be consolidated (fused) into a
single target. Alternatively, set up criteria for automatic consolidation of
ARPA and AIS targets based on the (trend in the) difference in range, bearing,
SOG and COG.
E.
Relay ARPA target information to others
Relaying
target information would allow other AIS equipped ships to acquire targets
well before they could acquire them on their own radar or AIS transponder.
ARPA targets would be relayed as if they were AIS targets. Relayed targets
could be displayed on the electronic chart or on the radar with a different
shape or color.
VTS
systems could very well be set-up to do this because a VTS center could attach
static and voyage related information (length, tonnage, hazardous cargo
information, destination, etc.) to its ARPA targets and turn them into almost
full-fledged AIS targets.
F.
Enable
instant messaging with targets
With
this function enabled, a pick list of short, traffic situation oriented
messages (“Intend to pass port to port”) would appear in a window as soon
as an AIS target is selected with a mouse click. The message would immediately
be sent to the AIS target.
A
blinking circle around the icon of the sender would indicate arrival of an
incoming traffic message from an AIS target. Clicking within this circle would
open both the message and a pick list of standard replies (“OK”). The
standard replies appearing on the pick-list would depend on the nature of the
original message. A reply would reference the original message. To avoid
distraction, standard messages and replies should not be customizable and
become “chatty”.
The
nature of the cargo could be displayed in the AIS target information window.
It would be part of the voyage information that is broadcast every few
minutes. Responsibility for transmitting the correct voyage information would
lie with the bridge team.
This
would allow AIS equipped ships to warn others of unusual maneuvering
limitations, such as running on one of two propellers or rudders. Like
hazardous cargo information, it would be displayed in a target’s information
window.
I. Display a target’s particulars and Voyage Data
Particulars
could include Name, Call sign, MMSI number, ship type, GRT, LoA, etc.
Voyage
Data could include number and size of barges being towed, draft, destination
port, berth and side-to, ETA pilot station. This information would be
displayed in a target’s information window.
J. Display
navigational aids as AIS targets
Specifically,
the actual velocity of the current at Ripple Rock at Seymour Narrows could be
displayed on the ECDIS Screen. Similarly actual visibility and wind readings
could be displayed. Other information could be temporary hazards, displaced
buoys, demarcation of traffic separation zones, range markers, etc. These
“stationary targets” would be of a different type would be identified as
such on the ECDIS. A VTS Center could broadcast the AIS information for these
stationary targets without actually equipping them with an AIS transponder.
K. Use
AIS to receive Differential GPS corrections
This
could be useful in areas where direct receipt of Differential correction
signals (RTCM 104) is not available, for instance due to topological
boundaries.
|
VISION
|
|
|
RADIANCE
|
|
|
ZAANDAM
|
|
VOLENDAM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Port
|
Arrive
|
Depart
|
Port
|
Arrive
|
Depart
|
Port
|
Arrive
|
Depart
|
Port
|
Arrive
|
Depart
|
|
Sat
|
|
|
|
Vancouver
|
7:00
|
17:00
|
Vancouver
|
17:00
|
|
|
|
|
Sun
|
Vancouver
|
7:00
|
17:00
|
|
-
|
-
|
|
|
|
|
|
|
|
Mon
|
|
-
|
-
|
Juneau
|
12:00
|
23:00
|
Juneau
|
14:00
|
23:00
|
Vancouver
|
17:00
|
|
Tue
|
Hubbard
Glacier
|
14:00
|
18:00
|
Skagway
|
6:30
|
20:30
|
Skagway
|
7:00
|
21:00
|
|
|
|
|
Wed
|
Skagway
|
7:30
|
20:30
|
Hubbard
Glacier
|
11:00
|
15:00
|
Glacier
Bay
|
7:00
|
16:00
|
Juneau
|
14:00
|
23:00
|
|
Thu
|
Juneau
|
7:00
|
16:00
|
Ketchikan
|
13:00
|
20:00
|
Ketchikan
|
10:00
|
18:00
|
Skagway
|
7:00
|
21:00
|
|
Fri
|
Ketchikan/Misty
Fjords
|
8:00
|
15:00
|
|
-
|
-
|
|
|
|
Glacier
Bay
|
7:00
|
16:00
|
|
Sat
|
|
-
|
-
|
Vancouver
|
7:00
|
17:00
|
Vancouver
|
8:00
|
17:00
|
Ketchikan
|
10:00
|
18:00
|
|
Sun
|
Vancouver
|
7:00
|
17:00
|
|
|
|
|
|
|
|
|
|
|
Mon
|
|
|
|
Juneau
|
12:00
|
23:00
|
Juneau
|
14:00
|
23:00
|
Vancouver
|
8:00
|
17:00
|
|
Tue
|
Hubbard
Glacier
|
14:00
|
18:00
|
Skagway
|
6:30
|
20:30
|
Skagway
|
7:00
|
21:00
|
|
|
|
|
Wed
|
Skagway
|
7:30
|
20:30
|
Hubbard
Glacier
|
11:00
|
15:00
|
Glacier
Bay
|
7:00
|
16:00
|
Juneau
|
14:00
|
23:00
|
|
Thu
|
Juneau
|
7:00
|
16:00
|
Ketchikan
|
13:00
|
20:00
|
Ketchikan
|
10:00
|
18:00
|
Skagway
|
7:00
|
21:00
|
|
Fri
|
Ketchikan/Misty
Fjords
|
8:00
|
15:00
|
|
-
|
-
|
|
|
|
Glacier
Bay
|
7:00
|
16:00
|
|
Sat
|
|
-
|
-
|
Vancouver
|
7:00
|
17:00
|
Vancouver
|
8:00
|
17:00
|
Ketchikan
|
10:00
|
18:00
|
|
Sun
|
Vancouver
|
7:00
|
17:00
|
|
|
|
|
|
|
|
|
|
|
Mon
|
|
|
|
Juneau
|
12:00
|
23:00
|
Juneau
|
14:00
|
23:00
|
Vancouver
|
8:00
|
17:00
|
|
Tue
|
Hubbard
Glacier
|
14:00
|
18:00
|
Skagway
|
6:30
|
20:30
|
Skagway
|
7:00
|
21:00
|
|
|
|
|
Wed
|
Skagway
|
7:30
|
20:30
|
Hubbard
Glacier
|
11:00
|
15:00
|
Glacier
Bay
|
7:00
|
16:00
|
Juneau
|
14:00
|
23:00
|
|
Thu
|
Juneau
|
7:00
|
16:00
|
Ketchikan
|
13:00
|
20:00
|
Ketchikan
|
10:00
|
18:00
|
Skagway
|
7:00
|
21:00
|
|
Fri
|
Ketchikan/Misty
Fjords
|
8:00
|
15:00
|
|
-
|
-
|
|
|
|
Glacier
Bay
|
7:00
|
16:00
|
|
Sat
|
|
-
|
-
|
Vancouver
|
7:00
|
17:00
|
Vancouver
|
8:00
|
17:00
|
Ketchikan
|
10:00
|
18:00
|
|
Sun
|
Vancouver
|
7:00
|
17:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vancouver
|
8:00
|
17:00
|
|
No.
|
Target
|
Place
and Comments
|
First
Observation
|
Last
Observation
|
|
Ship
Name
|
As
AIS Target
|
Visual
or as ARPA Target
|
As
AIS Target
|
Visual
or as ARPA Target
|
|
|
(Ship’s
Date & Time)
|
(Ship’s
Date & Time)
|
(Ship’s
Date & Time)
|
(Ship’s
Date & Time)
|
|
1
|
|
|
|
|
|
|
|
2
|
|
|
|
|
|
|
|
3
|
|
|
|
|
|
|
|
4
|
|
|
|
|
|
|
|
5
|
|
|
|
|
|
|
|
6
|
|
|
|
|
|
|
|
7
|
|
|
|
|
|
|
|
8
|
|
|
|
|
|
|
|
9
|
|
|
|
|
|
|
|
10
|
|
|
|
|
|
|
|
11
|
|
|
|
|
|
|
|
12
|
|
|
|
|
|
|
|
13
|
|
|
|
|
|
|
|
14
|
|
|
|
|
|
|
|
15
|
|
|
|
|
|
|
|
16
|
|
|
|
|
|
|
|
17
|
|
|
|
|
|
|
|
18
|
|
|
|
|
|
|
At the end of the
test please send the NaviSailor Log files to:
Fred
W. Pot
fpot@attbi.com
3837
31st Avenue West
Seattle,
WA 98199-1713
USA
+1-206-301-9626
Office
+1-206-850-7664
Mobile
On
NaviSailor Master (not the slave):
Hold down the Ctrl, Alt and Del keys simultaneously.
-
Click on ‘Task Manager’
-
Click on ’New Task’
-
In the ‘Open:’ window type ‘explorer.exe’
-
Click ‘OK’
-
Click on ‘Transas’
-
Click
on ‘NS_3000’
-
Click
on ‘Track’
-
Highlight
the three files for August 15, 2002: 020815.LBK, 020815.tgt and 020815.trk
-
Also
highlight these files for the other AIS Test dates
-
From
the ‘Edit’ menu at the top select ‘Copy’
-
Place
diskette in the drive
-
Click
on 3 ½ Floppy (A:)
-
From
the ‘Edit’ menu at the top select ‘Paste’
-
From the ‘File’ menu at the top select ‘Close’
-
Mark the diskettes with the ship name and the date.
-
Send
the diskette to Fred Pot (see above)
cc:
C. Deelstra
F. Pot