Ship Reporting CG Meeting 8

Ship Reporting CG Meeting 8

April 16th, 2019

 

Meeting Summary

 

Participants

Bergmann Marine, Fred Pot, Secretary

Chartworld, Konstantin Ivanov

TELKO International. Anders Rydlinger

 

 

Update on meeting of IALA’s ARM WG2 Ship Reporting Task Group during ARM9

 

  • IMO Resolution FAL.12(40)

This resolution requires shore-based authorities to implement electronic ship reporting by April 8th, 2019, however, FAL has limited means to enforce shore-based authorities to implement such systems on this schedule.

 

Implementation of this directive is therefore foreseen to be, at least initially, limited to shore-based authorities that are technologically sophisticated thus leaving many paper-based ship reporting schemes in effect for the foreseeable future.

 

  • System Architecture

The IALA ARM Committee Ship Reporting Task Group (TG) decided that the distributed model should be adopted mostly because it will minimize the associated administrative burden and cost. This means that the Ship Reporting Registry will become a “Portal” that provides a URL for each shore-based authority. This URL allows ship-board reporting ICT tools to exchange information with the shore-based authority using a M2M (SOAP or REST) webservice.

 

The TG is considering setting up the Ship Reporting Portal as a layer in the ENC. Specifically as a S-127 “Traffic Management” layer. The layer would show the (country or port) area that a shore-based authority is responsible for. It could then be used by the on-board Voyage Management System to discover the URL to the Ship Reporting webservice of the shore-based authority for the next port of call.

 

Electronic Ship Reporting Information Exchange

  1. The on-board reporting ICT tool receives the URL for the shore-based authority in the next port of call from the Voyage Management System.
  2. The ICT tool automatically opens a secure (SOAP or REST) webservice session with the shore-based authority
  3. The webservice requests (in machine readable XML form) basic voyage information (LoA, Beam, Destination, etc.) to determine what the reporting requirements will be
  4. The on-board ICT Tool provides this basic voyage information in XML format
  5. The webservice uses the basic voyage information to determine reporting requirements and provides the on-board ICT tool with machine readable specification of full reporting requirements in XML format
  6. The on-board ICT tool draws the required reporting information from the Voyage Planning System and from other systems (using M2M connections). It then generates and transmits a data package in XML format that fulfills the reporting requirements.
  7. The webservice provides the on-board ICT tool with an acknowledgement of receipt of the data package.

 

 

Shore-based ship reporting service

We discussed an alternative to the above. In this alternative the ship provides information to a shore-based ship reporting service. It includes all information that possibly could be required by shore-based authorities.

 

The shore-based ship reporting service keeps abreast of (i.e. maintains a centralized knowledgebase of) the specific reporting requirements of all shore-based authorities and submits ship reports on their behalf.

 

This alternative system is described in detail in Deliverable 5.3, Development of a new common port

database concept and structure of the EfficienSea2 project (see attached).

 

We decided that we need to get feedback from all SRCG Members on the preferred ship reporting method:

  • Direct M2M communication between the on-board reporting ICT tool and shore-based authorities’ webservices
  • Introduction of a third party “ship reporting service” that communicates with ships and submits ship reports on their behalf

 

There are governance and funding repercussions associated with this alternative that would need to be addressed.

 

Changes in reporting requirements

If a shore-based authority changes it reporting requirements (i.e. New Zealand wants to start collecting stack emissions information from ships) then the on-board ICT tool will need to be updated to enable it to provide this additional information. We discussed the lead-time required to update on-board ICT tools to allow them to comply with changes in reporting requirements. The group felt that it would not require very much lead time.

 

IMO FAL seems to be open to require shore-based authorities to provide information to SRCG Members about changes in reporting requirements at least 12 months before their effective date.

 

Fred suggested that we get feedback on this issue from all SRCG Members.

 

Update on application for funding through STM BALT SAFE

The Swedish Maritime Authority has declined to provide funding for a testbed of the Ship Report Registry through the STM BALT SAFE project. Fred is seeking other sources of test bed funding.

 

Next Steps

Fred to develop a short survey of SRCG members to seek feedback on:

  1. The need for a survey of shore-based authorities on their plans to implement electronic ship reporting. This survey should allow us to quantify how many (and which) will require paper/PDF forms for the foreseeable future
  2. Preferred nature of the Ship Reporting “Portal” (see above)
    1. On-line Portal
    2. Embedded in an S-127 Layer in the ENC
  3. Alternative methods of ship reporting
    1. Ship -> Shore-based authority direct
    2. Ship -> Shore-based reporting service -> Shore-based authority
  4. Lead time required to implement changes in reporting requirements

 

 

Next Meeting

Tuesday June 4th, 2019

  • 07:00 AM PDT
  • 03:00 PM BST
  • 04:00 PM CEST
  • 05:00 PM MSK

 

Best Regards

 

Fred Pot

Secretary

Ship Reporting CG

+1-206-850-7664 Mobile

fred.pot@bergmann-marine.com

www.srcg.bergmann-marine.com