Developing evaluation criteria for the acquisition and implementation

of a SPRFMO VMS
Summary of views and comments received prior to 1 September 2015 by Australia,
Chile, EU, New Zealand, Chinese Taipei and USA

1. This paper summarises the feedback and views received so far with regard to a discussion paper
drafted by the Secretariat to facilitate the deliberations of the VMS Working Group.
2. Chile has proposed a four-step process for the implementation of a VMS. Step 1 includes a
comprehensive list of technical requirements for a SPRFMO VMS software (see Annex 1). The
VMS-WG is invited to review and comment.
3. As an overall point, New Zealand remarked on the desirability to align the SPRFMO VMS as much
as possible to other regional VMS in the South Pacific, in particular CCAMLR and WCPFC, and to
consider type approval processes to guidance such as the FFA type approval process.
4. Based on the comments received, the Secretariat is in the process of collecting more information
about the CCAMLR VMS and to explore options of sharing the VMS of CCAMLR. The VMS-WG will
be appraised of such information as soon as possible.
1 Introduction
5. The EU reminds the VMS WG of its position on "flag stage principle": VMS data should be sent to
the Flag FMC, who is (directly and automatically) forwarding it to other parties. VMS reporting to
SPRFMO via FMCs as opposed to directly from vessels is supported also by Australia who adds that
this is consistent with requirements in other RFMOs and in CCAMLR, and would also be more cost
effective for the SPRFMO Secretariat as administration costs would be borne by the flag State.
6. New Zealand believes that a SPRFMO VMS should allow both scenarios, i.e. (1) that vessels report
directly and simultaneously to the SPRFMO Secretariat and to their flag State FMC, and (2) vessels
report directly to their FMC that then forwards this information on to the Secretariat.
7. Regarding CMM 2.06 paragraph 3, the EU clarifies that the continuous monitoring should be
limited to the SPRFMO Convention Area.
2(a) The hardware (ALCs) and set-up required on-board authorised fishing vessels
8. The USA suggested that as an element of the evaluation criteria, SPRFMO might require a VMS
service provider to be capable of “ingesting” data from all ALC models and satellite services
approved for use in SPRFMO.
9. Regarding procedures for the manual transmission of VMS reports in case of ALC failure as well as
measures to prevent tampering, the USA suggested that it might fall outside the tasking of the
VMS WG in view of the high technical detail required. Chinese Taipei recommended to consider
the WCPFC procedures. New Zealand advised to consider many and up-to-date ways of ensuring
an ALC and its component parts are tamper-proof, and try to avoid out of date mechanisms such
as physical seals.
10. Australia supports the development of procedures for manual reporting in the case of ALC failure
and suggested to consider the Pacific Island Forum Fishery (FFA) policies and guidelines at
https://www.ffa.int/node/40. Australia also welcomes the development of measures to prevent
tampering provided they are reasonably consistent with those in other RFMOs that Australia is

South Pacific Regional Fisheries Management Organisation

party to, including CCAMLR. As tamper-proof seals might not be effective, Australia advised that
SPRFMO look to other means to reduce the risk of misreporting such as increasing the polling rate,
which is being discussed in CCAMLR.
11. New Zealand warns of having different sets of processes for different ALC units but on the same
vessel and therefore recommend looking at other SSPs (Satellite Service Providers?) and type
approval processes to guidance such as the FFA type approval process.
2(b) The type of information and format of reports transmitted via VMS
12. As mentioned above Chile proposed 41 technical elements of a SPRFMO VMS software (see Annex
1) including operation and validation requirements. New Zealand has already articulated its
general support of these (and commented in particular about the desirability of receiving
additional information through the VMS, e.g. catch/effort reports). The Secretariat suggests that
the other VMS WG members also consider this document and provide comments.
13. The EU notes that the NAF format will be replaced in the near future by the XML format which is
a better fit for electronic logbooks. The XML standard has been endorsed by FAO and is the
standard for transmission of daily fishing data in the EU. Therefore, the EU is in favour to include
the XML format in the tender and to implement the so-called FLUX system that will allow SPRFMO
to receive XML messages.
14. Australia believes that the FFA has strong VMS policies and procedures regarding data
transmission and suggests that SPRFMO consider these when developing its data transmission
standards. Also, Australia would be happy to explore the North Atlantic format further with
Members.
2(c) The capability of the Secretariat and SPRFMO inspectors to receiving and archiving VMS
reports from the fishing vessels
15. The EU noted that training and up-grades of the software could be costly. The USA remarked that
the number of vessels tracked is often the key figure vendors use as a baseline for the recurring
cost (the figure cited in the paper is not unrealistic).
16. Australia agrees that options should be explored where the SPRFMO VMS service provider could
allow for a certain number of changes each year at no cost to avoid budget fluctuation.
17. With regard to sharing the software with another RFMO, in particular CCAMLR, Australia, New
Zealand, Chinese Taipei and USA recommended to explore this option further, especially with
regard to potential cost-savings. The EU thought this was not a good idea and concurred with
some concerns raised by the Secretariat. Chile remained silent on this point.
18. The EU and USA also commented on the number of communication lines of a SPRFMO VMS. The
Secretariat had noted that the set-up and maintenance of communication lines with vessels and
FMCs is a time-consuming process. The EU remarked that this was an additional argument to
support the EUY approach to discourage direct contact between a vessel and an external
receiver and to channel all vessel messages through the flag State FMC instead. In this context,
the EU pointed out that with the FLUX-TL you would only need one connection.
19. The USA agreed that the process of setting up the VMS communication is time-consuming but
points out that in the case that CCAMLR or another entity acted on behalf of the SPRFMO
Secretariat, this would be reduced to one. Also, the USA recommended to investigate the
number of staff required by the CCAMLR VMS in view that SPRFMO manages about the same
amount of active vessels (under 400).
20. In relation to archiving VMS reports, Australia archives VMS reports for seven years and suggest
that SPRFMO may wish to consider a similar timeframe in developing its VMS policies

-2-
 3

ANNEX 1. Definition of Technical Requirements and VMS

1. Define how data is going to be received and stored in a standardized format via satellite from any
MCSP from vessels operating within and outside the SPRFMO Convention Area.
2. Establish a system that is able to extract and store in a standardized format, date, vessel ID, time,
position (latitude and longitude, DMS and/or decimal degrees format) and course and speed
(nautical miles) for a vessel from any MCSP.
3. Capacity to process VMS data received in various email formats.
4. Recognize unique ALC identifiers recorded for a vessel.
5. Receive and introduce VMS data provided by manual reporting and display in a manner that
distinguishes it from automatic reporting.
6. Display VMS data graphically in an accurate GIS interface and store vessel details including name,
IMO number, call sign, flag, fishing gear, ALC type, latitude and long, speed and direction.
7. Capacity to store VMS data, ALC configurations and vessel details in a secure structured database
including a query function in order to extract vessel metadata from the database.
8. Allow for the storage of other information sent and generated from various channels (e.g. catch and
effort reporting, transshipment, among others).
9. Capacity to store VMS data and be able to display that data to conduct historical analysis, among
others.
10. Allow the SPRFMO Secretariat to add new vessels and update vessel details.
11. Provide for a vessel to have multiple ALCs recorded and for a vessel receive data from one or more
ALCs in use.
12. Allow the SPRFMO Secretariat to request a position report from an ALC at any time (poll a vessel),
in addition to those position reports received via scheduled reporting.
13. Allow the SPRFMO Secretariat to set the frequency rate for a vessel's ALC and change these
frequency rates when be necessary.
14. Able to set the frequency rate to display when the vessel is actually operating (fishing sets).
15. Allow the CCAMLR Secretariat to set-up a range of alerts in relation to vessel activities including
movements across geo-coded areas, within area alert, overdue reports, power status position
reports, ALC open, antenna blocked, and transhipment mode.
16. Allow for the creation of groups of vessels and allow for the simultaneous selection and tracking of
all vessels in a particular group.
17. Allow for the searching and selection of vessels in various ways, such as: by vessel name, group,
flag, fishing gear, fishing zone, last alert, alert over a range of dates, position type over a range of
dates. This must include the ability to define a particular date range
18. Display VMS data graphically in an accurate GIS interface simultaneously for vessels selected.
19. Display VMS data graphically in an accurate GIS interface simultaneously for vessels in a particular
area selected.
20. Display the movements of vessels over time in an accurate GIS interface.
21. Display the movements of vessels over time in an accurate GIS interface through the animation of
positions (showing vessel position(s) relative to areas or other vessels over time).

-3-
 4

22. Outputs:
i. Provide the ability to print and save VMS data graphically in an accurate GIS interface
ii. Export of VMS data in appropriate tabular format (Excel CSV) in order to render position
reports in external geospatial software.
23. Provide a mechanism for monitoring specified events such as notifications for movements or
transhipments, entering an MPA or closed fishery and a SAR event by:
i. Providing an email
ii. Providing an SMS
24. Prohibit the modification of original data reports or data logs.
25. Provide a comprehensive data audit function including a query to review and extract data such as
latency check of received ALCs from satellite airtime provider. Therefore enabling ability to conduct
internal fault finding etc.
26. Generate a report when vessels activate an alarm in the system for security reasons.
27. Generate reports for vessels that have not supplied data reports over a range of dates and times with
the indication what was the possible cause of (power, POS, wrong data format).
28. Display VMS data in near-real time and have a high level of reliability.
29. With respect to user access, a minimum number of simultaneous users for the SPRFMO Secretariat
should be defined and remote end-user access at discretion of SPRFMO Secretariat.
30. Provide different levels of authorized access to data according to the type of user.
31. Be scalable beyond the current user base requirements of the SPRFMO Secretariat.
32. Be able to provide security audits at any time at request of the Commission.
33. Capable of producing an annual report of any security issues/events.
34. Provide for individual vessel owners and Flag States to track their own vessel(s) using a secure web-
based system administered by the SPRFMO Secretariat.
35. Be compatible with existing SPRFMO Secretariat IT infrastructure and support the internal
procedures of the SPRFMO Secretariat
36. Integrate with other databases held at the SPRFMO Secretariat
37. Provide full support from the supplier of the VMS solution implementation, including training of
staff, the provision of system and user documentation.
38. Provide Fabric Acceptance Test (FAT) to be performed at the tenders’ venue before delivery
39. Provide Client Acceptance Test (CAT) to be performed at SPRFMO premises after installations and
before acceptance by SPRFMO.
40. Enter into a Service Level Agreement with SPRFMO for ongoing support, software maintenance
and updates that should be annually automatically renewable if none of the parties do not denounce
or re-negotiate 3 months before the end date of the contract.
41. VMS provider Helpdesk services with response standards and escalation process & timelines
specified.

-4-