G1159 육상 관점에서 본 선박보고 (요약·한영 대역)

IALA GUIDELINE G1159
SHIP REPORTING FROM A SHORE-BASED PERSPECTIVE

Edition 2.0, December 2022
urn:mrn:iala:pub:g1159:ed2.0

Revisions to this document are to be noted in the table prior to the issue of a revised document.

1. Introduction
  1.1 Scope · 1.2 Objective of the Guideline
2. Concepts of systems for ship reporting
  2.1 Relationship to other maritime services
3. Streamlining ship reporting
  3.1 Fully Digital Harmonized System for Ship Reporting
4. Ship reporting obligations
  4.1 Description of Ship Reporting obligations (4.1.1 IMO FAL Convention · 4.1.2 IMO Ship Reporting system · 4.1.3 Obligations required at regional, national or local level · 4.1.4 Examples of types of reports · 4.1.5 Compliance with the FAL Convention · 4.1.6 Automate internal workflow and processing of ship reports)
5. Definition of main concepts
  5.1 IMO Compendium
  5.2 Fully Digital Harmonized System for Ship reporting (5.2.1 "Reporting as a Service" concept · 5.2.2 Technical aspects · 5.2.3 Message exchange · 5.2.4 Cyber Security requirements · 5.2.5 Technology to support data exchange)
6. Implementation steps
  6.1.1 Adding data elements to IMO Compendium
  6.2 Implement a Fully Digital System for Ship Reporting (6.2.1 to 6.2.7)
7. Definitions
8. Abbreviations
9. References
Annex A Cyber security
Annex B Project management for implementing a system for ship reporting

List of Tables: Table 1 Maritime Services and relationship to MS8 · Table 2 Types of reports
List of Figures: Figure 1 MSW conceptual architectural model · Figure 2 Example ship reporting requirements · Figure 3 IMO adopted MSRS areas as of February 2021 · Figure 4 Scope of ship reporting · Figure 5 Sequence diagram · Figure 6 Message exchange · Figure 7 Common shore based system

This Guideline is associated with IALA Standard S1070 Information Services [1] and its scope regarding data exchange systems.

Ship reporting is identified in several IMO Conventions, including:

• International Convention for the Safety of Life at Sea (SOLAS)
• International Convention for the Prevention of Pollutions from Ships (MARPOL)
• International Convention on Maritime Search and Rescue (SAR)
• Convention on Facilitation of International Maritime Traffic (FAL)

IMO has recognized that national ship reporting systems may use different procedures and reporting formats, as highlighted in IMO Resolutions A.851(20) [2] and MSC.433(98) [3]. In addition, 2022 amendments (FAL.14(46)) 1 January 2024 to the FAL Convention [4] require Contracting Governments to make use of the "single window" concept to enable all the information required by public authorities in connection with the arrival, stay and departure of ships, persons and cargo to be submitted through a single portal.

The purpose of this document is to provide guidance on approaches to facilitate harmonized ship reporting using digital systems.

The scope of this Guideline is to describe systems that could be used by those who require ships to submit reports. In the context of this Guideline, they are referred to as Shore-based Stakeholders. These systems could be adopted by Shore-based Stakeholders to enable implementation of standardized and automated reporting (S2 Prioritised e-Navigation Solution, e-Navigation Strategy Implementation Plan, MSC.1/Circ.1595) [5].

The Guideline is intended to be used by Shore-based Authorities to assist them comply with IMO FAL Conventions and IMO MSC and Assembly Resolutions on Mandatory Ship Reporting and to automate processes and procedures associated with ship reporting both ashore and on board.

The goal of this Guideline is to assist public authorities and other shore-based stakeholders, with the implementation of automated processes and procedures associated to ship reporting obligations, while complying with both national and regional/local reporting requirements as well as with the international requirements of the FAL Convention and relevant MSC and Assembly Resolutions on ship reporting. Automating these processes and procedures is expected to:

• Make them less labour intensive and error prone.
• Ensure compliance with all applicable national and regional port and area entry rules and regulations.
• Result in faster identification of reports that Shore-based Stakeholders will need to investigate further, thereby reducing the time it takes to clear a ship for port entry and departure.
• Improve compliance with reporting requirements by conveying details of the latest report submission requirements to ships well ahead of their submission deadlines.

In this Guideline, the following concept is proposed:

Fully Digital Harmonized System
This system complies with the relevant IMO FAL Conventions and relevant IMO MSC and Assembly Resolutions and automates almost all processes and procedures that are associated with collecting and distributing ship reports to Shore-based Stakeholders.

Regarding technical system specifications, note that the Guideline does not describe the detailed technical specifications of these systems mostly because the concepts have yet to be endorsed not only by shore-based stakeholders and by ship owners/operators but also by other stakeholders including international organizations (IMO, IHO etc.).

IALA will continue to develop detailed technical specifications as they become available and publish them in later editions of this Guideline.

IMO has identified a list of 16 Maritime Services (MS) in the context of e-Navigation.

Maritime Service 8 (MS8) is about vessel shore reporting. The list below gives example of maritime services that can benefit from access to information from MS8.

It should be noted that the ship/shore information exchange mechanisms that are described in this Guideline could be used for maritime services other than MS8.

To enable realization of all guideline goals, this Guideline proposes that shore-based stakeholders implement a fully digital information exchange with ships or their shore-based representatives using web services, possibly taking advantage of the infrastructure of existing NSW/MSW systems. The message exchanges between a ship and the shore should be harmonized to make it possible for on-board ship reporting equipment to automatically exchange messages with all web services that are hosted by shore-based stakeholders.

Setting up a Fully Digital Harmonized System for Ship Reporting involves establishing a national authority that hosts a machine-to-machine web service, a graphical web interface and possibly other digital services that ship reporting equipment used by Bridge Teams and by their shore-based representatives will utilise to request port entry, to receive their reporting requirements and to submit ship reports to the national authority along with their updates. Typically, the reporting services are applicable and available in clearly defined areas or regions. A Fully Digital Harmonized System for ship reporting will also include services that support reporting to one or more IMO approved Mandatory Ship Reporting System regimes.

The system depicted in Figure 1 represents a conceptual architectural model that defines the structure and behaviour of the MSW. This model assumes that a single national authority (CIM, Centralised Information Model) has the responsibility to operate the system that collects information electronically via the Single Window and then disseminates this information to all relevant stakeholders.

The conceptual model illustrates that the MSW consists of an environment that enables ship data providers to submit information electronically either through a graphical user interface or a system-to-system web service. Depending on the reporting obligation information can come directly from a ship or can be submitted by its shore-based representatives. The information is digitised, and the individual data elements will be submitted once only. Shore-based stakeholders must streamline and automate national and regional processes and procedures to implement a Fully Digital Harmonized System for Ship Reporting.

This includes implementing an NSW/MSW system that the national authority can use to automatically collect and distribute ship reports to individual government agencies and other stakeholders, possibly including shore-based stakeholders in other countries that are on the ship's route plan. The latter could involve updating a Port Community System (PCS) that governmental and industry stakeholders, in turn, can use to populate their individual information systems.

There are many existing requirements for ship reporting. These have been identified through different IMO Conventions. Requirements for reporting from ships may also exist at the regional, national or local level.

For international shipping to thrive, a unified, global approach to facilitation is vital. This is the purpose of the international treaty called the IMO FAL Convention (the FAL Convention). The FAL Convention [4] has been in force since 1967 but is kept continually amended and updated by Governments at the FAL Committee of IMO.

In its annex, the FAL Convention [4] contains standards and recommended practices and rules for simplifying formalities, documentary requirements and procedures on ships' arrival, stay and departure.

Under the FAL Committee, IMO has developed standardized FAL documentation (known as FAL Forms) for authorities and Governments to use, and the FAL Convention urges all stakeholders to use these.

Since April 2019, the FAL Convention makes it mandatory for ships and ports to exchange FAL data electronically and encourages the use of a Single Window concept, that distributes ship reports to all relevant agencies and authorities.

IMO adopted the Ship Reporting System with Resolution MSC.31(63) [7] as an amendment to SOLAS 74 [8] on 23 May 1994. At that time, the Ship Reporting System did not become mandatory, but MSC.31(63) [7] states:

"The Organization shall ensure that adopted ship reporting systems are reviewed under the guidelines and criteria developed by the Organization."

Resolution MSC.433(98) [3], adopted on 16 June 2017, IMO invited Governments to apply for the establishment of Mandatory Ship Reporting System Areas.

Resolution MSC.433(98) [3] states:

"Shore-based authority should have the ability to relay information relating to distress, maritime safety or threats to marine environment without delay to the appropriate national or international maritime authorities, with a view to the initiation of response action."

Mandatory Ship Reporting did not start until 1996. Previously, voluntary ship reporting systems were being promulgated such as AUSREP (Australian Ship Reporting System, 1973) and AMVER (Automated Mutual-Assistance Vessel Rescue System). At that time, VHF radiotelephony was envisioned but digital reporting was endorsed whenever it became available.

The first two mandatory ship reporting systems were adopted in May 1996. One for the Torres Strait / Inner route of the Great Barrier Reef and the other for "Off Ushant, France". The format and content of reports and the reporting time and geographical position for submitting report, the authority to whom reports should be sent and the available services are described in MSC.52 [9].

Since then, more than 20 other Mandatory Ship Reporting Systems have been adopted in MSC Resolutions. Mandatory Ship Reporting systems come into effect six months after adoption by IMO. Ship Reporting Systems may also be voluntary.

General principles for ship reporting system and ship reporting requirements are provided in resolution A.851(20) [2]. Resolution MSC.433(98) [3] revoked MSC.43(63), MSC111(73) [10] and MSC.189(79) [11]. Resolution MSC.433(98) [3] defines adopted ship reporting system that are in compliance with all requirements of SOLAS regulation V/11 [8].

To reduce ships' reporting burden, shore-based authorities, if practicable, should be consider automated electronic means of ship reporting, recognized by the organization.

All countries/ports require ship reports. The required reports differ from port to port even if they are in the same country. While some countries have established a National Single Window (NSW), ports within the country often still require additional reports. Many countries/ports still require reports to be sent directly to individual shore-side stakeholders on their unique forms.

Many ports have adopted IMO FAL Forms 1-7 for some of these reports but still require ships to submit them in hard copy to shore-based stakeholders.

Figure 2 is an example of the reporting requirements for Guangzhou, China as of 14 November 2016 according to IHS Markit [12].

The following are examples of typical ship report types, classified in three reporting obligation sources in accordance with:

• Mandatory Ship Reporting Systems (MSC Resolutions on IMO adopted MSRS) and the FAL Convention
• International Reporting Obligations
• National, Regional and Local Reporting Obligations

A country/port typically requires a subset of these types of reports on their unique forms.

The IMO Compendium [6] contains definitions for data elements for many of the above report types but a process to accommodate unique data elements that are not expected to be added to the Compendium will need to be developed.

The annex of the FAL Convention [4] contains several standards and recommended practices that Contracting Governments need to comply with. These are managed and updated by the FAL Committee Resolutions.

The FAL Convention [4], as amended, includes a list of documents in its Standard 2.1 which public authorities can demand of a ship and recommends the maximum information and number of copies that should be required.

IMO developed standardized forms for seven of these documents:

• IMO General Declaration (FAL form 1)
• Cargo Declaration (FAL form 2)
• Ship's Stores Declaration (FAL form 3)
• Crew's Effects Declaration (FAL form 4)
• Crew List (FAL form 5)
• Passenger List (FAL form 6)
• Dangerous Goods (FAL form 7)

Three additional declarations entered into force on 1 January 2018:

• Security-related information as required under SOLAS regulation XI-2/9.2.2 [8]
• Advance electronic cargo information for customs risk assessment purposes
• Advanced Notification Form for Waste Delivery to Port Reception Facilities

Two other documents may also be required under the Universal Postal Convention and the International Health Regulations.

The 2022 amendments (FAL.14(46)) 1 January 2024 to the FAL Convention states that Contracting Governments are required for their public authorities to introduce arrangements to enable the submission of all the information required by public authorities in connection with the arrival, stay and departure of ships, persons and cargo (avoiding duplication) to a "Maritime Single Window".

Consideration should also be given to such a Single Window serving as the mechanism through which the public authorities communicate decisions and other information covered by the FAL Convention.

IMO has published guidelines for setting up a Maritime Single Window (MSW). See FAL.5/Circ.42 [21]. It serves as a source of information, advice and guidance for those IMO Member States looking to create an MSW and provides examples of the experience and knowledge gained by some Member States in approaching the implementation of MSW.

Shipping companies engaged in international trade regularly must submit large volumes of information and documents to ports and governmental authorities, to comply with regulatory requirements. The information often must be submitted through several different agencies, each with their own specific system and paper forms. These requirements, together with the associated compliance costs, constitute a burden both to Governments and to the business community and can be a major barrier to the development of international trade, particularly in developing countries.

Establishing a Single Window facility is one means of addressing this problem. It can enhance the availability and handling of information and can simplify and expedite information flows between trade and government. It can also bring about greater harmonization and better sharing of the relevant data across governmental systems, bringing meaningful gains to all parties involved in cross-border trade.

The mandatory requirement for national governments to introduce electronic information exchange between ships and ports came into effect from 8 April 2019, under the FAL Convention [4], and as per 2022 amendments (FAL.14(46)) 1 January 2024, they are required to establish a Maritime Single Window to facilitate information exchange.

Standard 1.6bis [13] states that when introducing systems for the electronic exchange of information required by public authorities for the arrival, stay and departure of the ship, persons and cargo to facilitate clearance processes, Contracting Governments shall encourage public authorities and other parties concerned (ship-owners, handling companies, seaports, and/or cargo agents, etc.) to exchange data in conformity with the relevant UN Standards. Such standards include UN Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) Standards, or other internationally agreed Standards, such as the XML Standard.

Recommended practice 1.7.1 of the annex to the FAL Convention [4] states that:

"Contracting Governments should encourage public authorities and other parties concerned to cooperate or participate directly in the development of electronic systems using internationally agreed standards with a view to enhancing the exchange of information relating to the arrival, stay and departure of ships, persons and cargo and assuring inter-operability between the systems of public authorities and other parties concerned."

The IMO Compendium on Facilitation and Electronic Business [6] is a tool for software developers that design the systems (i.e., on-board ship reporting equipment) needed to support transmission, receipt, and response via electronic data exchange of information required for the arrival, stay, and departure of the ship, persons and cargo to a port. With regard to reporting obligations to public authorities, the IMO compendium consists of a data set, a reference model, and mapping to three main standards maintained by the following organizations:

• World Customs Organization (WCO)
• United Nations Economic Commission for Europe (UNECE)
• International Standards Organization (ISO)

The IMO reference model is growing since FAL 43 approved the compendium to go beyond the scope of the FAL Convention [4] and will be the base model for many of the maritime services provided in MSC.1/Circ.1595 [5] and MSC.1/Circ.1610 [14].

The IMO Compendium will also be mapped to S-XXX Product Specifications as they become available.

One of the core principals when the compendium was designed was that this was not intended to be a "new" standard rather, the tool to harmonize existing standards and from the beginning all participants agreed to that principal. The goal was to produce a guidance for all interested parties to be able to automatically map the data set coming out of the FAL Convention to any of the leading standards and make it easier for companies involved in maritime trade or transport to create software that could communicate irrespective of the standard they were based on. This means that any organization responsible for a standard or a data model in the scope of a ship approaching a port is welcome to add and map data in the FAL compendium [6].

For detailed information about the compendium see the IMO webpage.

A harmonized system for ship reporting reflects the idea that the ship (and its shore-based representatives) can submit its obligatory reporting requirements in a standardized way, without having to worry about which country or port the ship is arriving at.

This idea is one of the most important solutions to reduce the amount of mariners' time spent on preparing and submitting reports to shore-based stakeholders.

The use of standards plays an important role in a harmonized system for ship reporting and the emerging digitization in the maritime world, both on the ship and on shore, is a key enabler to achieve the ambition set out in the IMO e-Navigation Strategy Implementation Plan Solution 2 – Means for standardized and automated reporting (see MSC.1/Circ.1595) [5].

A harmonized system for ship reporting using the IMO e-Navigation ambition is achieved though the concept of "Reporting as a Service".

The introduced maritime "Reporting as a Service" comprises reporting services that supports reporting to two types of recognized reporting systems.

The first system, Vessel Shore Reporting (VSR) is normally implemented for (pre-) arrival, stay and departure reporting, often defined through the IMO FAL forms. These system services should cover information and guidelines related to reporting formalities and instructions (when, what and how) for reporting to a specific country or port. In addition, this service should facilitate the exchange of information required in a Single Window ship reporting system. The VSR regime should be based upon internationally recognised data formats and exchange standards.

The second system is normally linked to a ship's transit of an area where a Mandatory Ship Reporting System (MSRS) is established. Ship reporting systems and reporting requirements are used to provide, gather, or exchange information in short reports between the ship and shore. The information is used to provide data for many purposes including search and rescue, vessel traffic services, weather forecasting and prevention of marine pollution. Ship-to-shore reporting is included in SOLAS Chapter V Safety of Navigation, Regulation 11 (SOLAS V/11) [8] and defines the MSRS areas as shown in Figure 3 below:

Resolution MSC.433(98) [3] on Guidelines and criteria for ship reporting systems, recalls that communication between a shore-based authority and a participating ship should be limited to information essential to achieve the objectives of the Ship Reporting System. The resolution also states that information retained in the system should be made available only on a selective and secure basis to authorities required to respond to distress, maritime safety or threats to the marine environment. The IMO resolution A.851 [2] outlines reporting guidelines for MRS. The guidelines also identify and define the distinct information elements organised into so called designators.

Reporting requirements from the two mentioned systems are addressed by the shore-based stakeholders, the FAL Committee and the NCSR Committee. The unique data elements in the requirements are considered by the EGDH group in their efforts to maintain the IMO Compendium³ [6] on Facilitation and Electronic Business and ensure the further development of data elements beyond the FAL Convention. Eventually, the data elements are included in the IMO Data Reference Model if agreed and mapped into the WCO, ISO, UNECE and eventually into S-XXX data models ("Product Specifications").

The ISO28005-2 [16] standard is used as the MSRS reporting message format. The ISO 28005-2 standard covers the core data elements required for ship-to-shore and shore-to-ship reporting as defined in:

• All FAL standard declarations (FAL 1 to 7) as defined in the FAL Convention [4]
• ISPS reporting requirements as defined in ISPS [29] and MSC 1305 [18]
• All general ship reporting requirements as defined in IMO Resolution A.851 [2]
• Recommended reporting on ship-generated waste as defined in MEPC 644 [19] (mandatory within the European Union, as described in EU/2000/59)
• Required reporting as defined in the bulk loading and unloading code IMO Resolution A.862 [29]
• ETA reporting to pilot station as defined in IMO Resolution A.960 [20]

From a generic point of view the maritime "Reporting as a Service" does not in principle differentiate between the two reporting regimes briefly mention above. The service⁴(s) exposes two services to the ships:

• Information on the reporting requirements (when, what and how)
• An interface for reporting data values of structured data elements

Both services ensure a fully harmonized and digitized information exchange between ship and shore.

Obviously, there are user and operational aspects of automatic ship reporting, however this section addresses the technical aspects of "Reporting as a Service". Based upon the introduction described in the concept, to be capable of generating information and transmitting it automatically, a realistic implementation of these services will require involvement of both competent authorities and shipowners.

The concept of an automatic reporting schema comprises two technical systems/services:

• an on-board ship reporting equipment or shore-based ship reporting equipment (used by the ship's shore-based representatives); and
• an on-shore system (SHORE side).

Figure 4 below visualises the scope of the reporting and shows how the two systems or services interact at various stages of a ship voyage.

The Master usually is responsible for ship reporting. However, the actual reporting might be undertaken by a third party such as a ship agent. For simplicity, the third party is omitted from the Figure 4. Using existing data communication systems, ship information will be transmitted to the authorities, ports, VT's and shore centres during the ship voyage or ship arrival to port.

The "DATA CONSUMERS" (i.e., Shore-based Stakeholders) e.g., VTS, Authorities or private stakeholders' side, illustrated in the figure on the right, is included to visualise the holistic picture of ship reporting. The stakeholders will receive relevant information from ships, using the existing connections and exchange mechanisms implemented in the relevant system, i.e., National Single Window(s).

The main area of interest is depicted in the grey area of the figure. This represents the area where the automatic ship reporting typically operates and where the systems interact and communicate with, or affect, each other. The endpoints typically expose one or more services that enable submission, retrieval, and exchange of information.

The endpoints indicated in the figure comprise at least two principal set of services that are common in both Vessel Shore Reporting (VSR) and Mandatory Ship Reporting System (MSRS) reporting. The first enables the ship and shore to request and receive information and the second service enables the transmission and reception of the reporting information.

From the ship's perspective, the relevant reporting system provides an information service and is able to digitally respond to information requests from the ships. Both types of shore services should, as a minimum, respond by giving the requesting system the accurate current reporting obligation for that specific reporting system.

Additional functions of the service could provide responses to other requests as indicated in earlier in this document.

Currently the various reporting systems have different reporting obligations and procedures. The reporting obligations (data elements to be reported) should be in accordance with the IMO Data Reference Model. However, not all reporting systems require all the information that is specified in the reference model and the reporting procedures will vary based upon different parameters.

One of the central services that should be found in the Request and Response Service (RRS) is the ability for on-board ship reporting equipment to request the reporting obligations for a specific voyage area or port call. Based on the ship particulars and voyage information, such as the type and size of the ship, port of departure, crew and passengers, the ship system should be able to request the shore-based reporting system for the ship's reporting obligations for that specific voyage. The shore-based system should, in return, respond to the requester in a structured message with the obligatory reporting information and reporting procedures that would be required for the ship and voyage.

Therefore, as seen from the ship's perspective, the reporting system provides an information service, and can digitally respond to information requests from the ships. Both types of shore services should, as a minimum, respond by giving the requesting system the accurate current reporting obligations and procedures for that specific reporting system, being Vessel Shore Reporting (VSR) or Mandatory Ship Reporting System (MSRS).

The TRS service is a more traditional service provided by the VSR and MSRS systems. The services are exposed to ships and can receive and acknowledge the submitted reports (new or updates) from the ships or their shore-based representatives.

In every reporting schema, and especially in a harmonized and automatic reporting schema, there needs to be well defined message exchange mechanisms in place. These exchange mechanisms should in principle be independent of the context in which the exchange is taking place.

The exchange is often described in the form of message exchange sequences (patterns) and corresponding information elements that are necessary to execute the exchange. Each pattern can represent several specific exchanges between different parties. However, for ship reporting, the message sequences should be the same generic flow of information both for single window data exchanges or ship reporting to VTS or any other ship reporting system.

The sequence diagram(s) presented in Figure 5 consists of vertical lines representing an abstract time axis for client (ship) and server (shore) respectively and in some cases a proxy (catalogue).

Arrows between the parties represent the sequence of messages that need to be exchanged. A thick line from an arrow end to a new arrow start shows synchronous processing by the respective party.

The e-Navigation services message flow and representation are being discussed in the IMO Expert Group on Data Harmonization (EGDH), and the figure Service Request (Figure 5) is a slightly modified version of the figure found in annex 3 of the IMO document EGDH 1/9 [29]. The modification to the original generic drawing helps to visualise a specific sequence diagram for the pattern which describes a Service Request in relation to the concept of automatic reporting.

In Figure 5 the ship requests the RRS from the shore centre, in this case, the request is for the Reporting Obligations & Procedures for clearance to go to a port or entry into an MSRS area. A receipt is sent to acknowledge that the request for service is received by the shore centre. The shore centre proceeds with some work to handle the request and responds to the requesting ship with the relevant reporting requirements and procedures for the specific ship and voyage. In the generic sequence diagram, there are also sequences for loops and options related to the message exchange. Loops and options might not be relevant in the example.

A Ship Report Registry Service (proxy service) will expose the service on behalf of the shore centre.

In a sequence where the ship submits a report (TRS service), loops and options will be relevant. As an example, a single window system that has received a ship report would check that the data received is correct and in the correct format. The single window will then forward the relevant information to the appropriate authorities and other shore-based stakeholders.

Results of the work done by the shore centre is sent to the ship as a service response, for instance, for a Single Window, this can be a clearance to enter the port. The ship can both update and cancel the request in several iterations. For port clearance, this corresponds to sending a clearance message multiple times, when the ship has available more information to submit (i.e., updates). The ship can also cancel the service request, for example, to cancel the port clearance request.

To enable a sequence of data exchange similar to the one described in Figure 6 above would require definitions of additional data elements (beyond conventions and regulations). The data elements would be within the computer and communication domain and would not require additional human interaction or be an administrative burden.

The pattern can also be used to describe a use case where the client (i.e., the ship) subscribes to updates from the shore centre server until it times-out or until cancellation.

Note that for simplicity and consistency, the sequence diagram in Figure 8 is foreseen to be an information exchange between the ship and shore. However, from a practically and real-world point of view, systems, and services "onboard" might be implemented elsewhere i.e., on shore or in a cloud-based implementation. Interpretation of the sequence diagrams should take other scenarios into account.

The harmonized system for ship reporting has specific requirements regarding cyber security. These requirements will need to be fulfilled by all ships, their shore-based representatives, shore-based stake holders and other entities in the marine transportation logistics chain. As most communication on ship reporting uses standards as used in internet communication, like https (TLS), it is logical to utilize the internet best practices where possible. Special attention needs to be given to the authentication of digital certificates, as the chain of trust may deviate from the mechanisms used in communication over the internet. There are several technology providers, that address this. The IALA Guideline G1161 on Evaluation of platforms for the provision of maritime services in the context of e-navigation may be consulted for a selection of suitable technology-providers.

This Guideline assumes that a harmonized mechanisms for ensuring reliable, secure and authenticated communication are applied. Elements of cyber security that should be addressed include identification, authentication, repudiation, encryption and authorisation.

Shore-based stakeholders should be able to identify the ship that sends an entry request even if the request is submitted by a shore-based representative of the ship.

On-board ship reporting equipment or equipment used by the ship's shore-based representatives should be able to determine contact information for shore-based stakeholders that require them to submit report(s). This should include the URL for their web Interface and for their web-service.

Shore-based stakeholders will need to be able to authenticate senders of entry requests and of ship reports and their updates.

Ship reporting equipment used by ships and/or their shore-based representatives will need to be able to authenticate addressees of their entry requests and the addressees of their ship reports (and their updates).

Ship reporting equipment used by ships and/or their shore-based representatives will need to be able to prove that their entry requests, their ship reports, and their updates were received by shore-based stakeholders.

Shore-based stakeholders will need a way to prove that ship reporting equipment used by ships and/or their shore-based representatives did in fact receive their reporting requirements.

Ship Reports may contain sensitive (personal) information about crew and passengers as well as commercial data. Ship owners/operators (and by extension their representatives) own this information or are required to protect dissemination of this information on behalf of crew and passengers. Ship owners/operators must have control over access to certain ship reports and limit access to only those who have a need to know. Also they need to comply with (local) laws regarding privacy, e.g. GDPR when storing and exchanging data regarding the handling of personal data.

Communication systems between the ship and the shore should support the exchange of digital data used for Ship Reporting and the ability to support SOAP and/or REST based services either directly or through a gateway.

Considerations when selecting the communication systems could include:

• Data rate to carry the digital data
• Cost
• Coverage in the area of interest
• Use of a combination of communication systems
• Reliability/availability of the selected communication system

Communication systems that could be considered for use either directly or via a gateway are:

• IMT 2000 and IMT 2020 (LTE, 4G and 5G IMT technologies)
• VDES that includes AIS, ASM and VDE
• Satellite communication systems

While the goal is to establish a world-wide harmonized fully digital system for ship reporting, it is unlikely that all shore-based stakeholders will be able to migrate to such a system at the same speed.

Annex D recommends that formal Project Planning principles are used when implementing an Intermediary (or Fully Digital) System for Ship Reporting.

The IMO Compendium [6] is maintained by the Expert Group of Data Harmonization (EGDH) which is a group of experts that meet between the regular FAL committee meetings and prepare updates to the compendium that the FAL committee approves. Annex B describes an example of ship report harmonization that is a pre-requisite for adding data elements to the compendium. During the FAL committee the work produced by EGDH is examined by the electronic business working group.

To add data elements to the Compendium [6], shore-based stakeholders need to submit input papers in accordance with IMO procedures and preferably in a defined format. As a submitter, a shore-based stakeholder can either submit input to the EGDH which runs on a fixed priority list by the FAL Committee and EGDH can recommend a priority to be approved by the next FAL Committee, or the submission can be made directly to the FAL Committee which will assign the priority for the next EGDH.

The current format to submit new data elements to the data set is in the following format:

Description of the sequence of data exchanges. (The submitter is required to send in a brief description of the flow of the data between the submitter and the receiver)

Description of data elements as follows:

The elements mandatory for submission are:

• Data element
• Definitions
• Format

The other fields are not mandatory, but it is advised to specify Change Indicator and Data ID for fields that are requested to be updated. Code lists and business rules are to be provided if known or if the submitter has a suggestion.

Adding data elements to the IMO Compendium [6] is likely to be a rather lengthy process. To avoid the associated delays in setting up an National Single Window System for Ship Reporting, Shore-based Stakeholders should include definitions of ship report fields that have yet to be added to the IMO Compendium in the ship report submission requirements.

Establishing a national authority that offers an MSW/NSW is a prerequisite for migration to a fully digital, harmonized system for ship reporting. It, in turn, requires amending most if not all existing ship reporting processes and procedures. FAL.5/Circ.42 [21] is intended for:

"Public authorities or administrations responsible for developing or modifying environments for a Maritime Single Window (MSW)"

and provides detailed guidelines. Annex A of FAL.5/Circ.42 provides examples of NSW implementations.

IALA Guideline G1113 [22] establishes relevant principles for the design and implementation of harmonized shore-based technical system architectures that are used by national authorities.

IALA Guideline G1114 [23] proposes a Common Shore-Based System Architecture for all systems that a national authority uses (see Figure 7). In terms of this architecture, a MSW/NSW will require a:

• Data Collection and Data Transfer Service:
  • API Web service
• Value Added Data Processing Service:
  • Acknowledge Receipt of Entry Request
  • Analyse Entry Requests and respond with Reporting Requirements
  • Store and analyse Ship Reports
  • Acknowledge receipt of Ship Reports and their updates
• User Interactive Service:
  • For Shore-Based Authority Users
• Gateway Service for External Users:
  • For other Stakeholders: Customs, Immigration, Health, Security, Port Community, Authorities in other Countries, Etc.

Establish a web service that is designed to securely exchange information with approaching ships (and with their shore-based representatives).

This web service will need to comply with the requirements specified in section 5.2 (Harmonized System for Ship Reporting) where it concerns information exchange with ships and/or their shore-based representatives.

IALA Guideline G1157 [15] provides guidance on the establishment of a web service based on S-100 Data Exchange. While this guideline specifically addresses Data Exchange of S-XXX formatted data, it can be extended to also cover exchange of data formatted as Data Structures and Data Elements that are defined in the IMO Compendium [6].

Any service specification developed for ship reporting should follow the IALA guideline for the specification of e-Navigation technical services (G1128) [24].

Shore-based stakeholders will make the URL of their Ship Reporting Web service discoverable in Ship Report Registry Service as an IHO Marine Traffic Management S-127 Product Specification formatted entry. On-board ship reporting equipment can be used to discover the (URL of the) ship reporting web services associated with ports of call that are in the voyage plan and web services that are associated with Mandatory Ship Reporting System areas that the ship will enter during its voyage. The on-board ship reporting equipment will initiate ship reporting sessions with the relevant web services to request area and/or port entry.

The service will need to allow reporting equipment that is used by bridge teams and the ship's shore-based representatives to initiate a secure web service session and transmit a port/area entry request, possibly a S-421 [29] Route Plan message.

Based on the values of the data elements transmitted with the port/area entry request, the web service will need to have logic rules to determine what reports the ship will need to submit and when.

Specifically, in response to receiving a port/area entry request from a ship or from a shore-based representative of the ship, the web service will need to acknowledge receipt of the request and then transmit the names of the report data structures as defined in the IMO Compendium [6] along with their submission deadlines.

If the IMO Compendium data structures do not include the required report, then the procedures detailed in section 6.1.1 should be followed.

The report deadlines may be expressed in a specific UTC date/time or a date/time relative to the planned time of arrival (i.e., 96 hours before ETA). The submittal of ship reports may also be triggered by entering a certain geo-fenced area.

The web service should also allow on-board ship reporting equipment to initiate a secure web service session and transmit the values of the data elements that are part of required reports (also known as data structures) along with updates of these values.

The National Authority is required to distribute selected parts of the information it receives from on-board ship reporting equipment via its web service to other Shore-based stakeholders.

This will involve selecting the data structures or even individual data elements that they require, confirming that they are authorised to receive them and forwarding them using appropriately secured measures.

The definitions of terms used in this Guideline can be found in the International Dictionary of Marine Aids to Navigation (IALA Dictionary) and were checked as correct at the time of going to print. Where conflict arises, the IALA Dictionary should be considered as the authoritative source of definitions used in IALA documents.

1. IALA. Standard S1070 Information Services.
2. IMO. (1997) Resolution A.851(20) General Principles for Ship Reporting Systems and Ship Reporting Requirements, Including Guidelines for Reporting Incidents Involving Dangerous Goods, Harmful Substances and/or Marine Pollutants.
3. IMO. (2017) Resolution MSC.433(98) Guidelines and Criteria for Ship Reporting Systems.
4. IMO. (1967) Convention on Facilitation of International Maritime Traffic.
5. IMO. (2018) Circular MSC.1/Circ.1595 e-Navigation Strategy Implementation Plan - Update 1.
6. IMO. (2021) FAL.5/Circ.43 the IMO Compendium on Facilitation and Electronic Business.
7. IMO. Resolution MSC.31(63) Adoption of Amendments to the International Convention for the Safety of Life at Sea, 1974.
8. IMO. (1974) International Convention for the Safety of Life At Sea.
9. IMO. Resolution MSC.52(66) Mandatory Ship Reporting Systems.
10. IMO. Resolution MSC.111(73) Adoption of Amendments to Guidelines and Criteria for Ship Reporting Systems.
11. IMO. (2004) Resolution MSC.189(79) Adoption of Amendments to the Guidelines and Criteria for Ship Reporting Systems.
12. IHS Markit. Ports and Terminals Guide 2019-2020 date viewed 05/05/21 https://cdn.ihs.com/www/pdf/Ports-Terminals-Guide-2019-2020.pdf
13. IMO. (2016) FAL.12(40) Amendments to the Annex to the Convention on Facilitation of International Maritime Traffic, 1965.
14. IMO. (2019) Circular MSC.1/Circ.1610 Initial Descriptions of Maritime Services in the Context of e-Navigation.
15. IALA. (2020) Guideline G1157 Web Service Based S-100 Data Exchange, Ed 1.0.
16. ISO. 28005-1 (2013) Security management systems for the supply chain — Electronic port clearance (EPC) — Part 1: Message structures.
17. IMO. (2004) The International Ship and Port Facility (ISPS) Code.
18. IMO. (2009) MSC.1/Circ.1305 Revised Guidance to Masters, Companies and Duly Authorized Officers on the Requirements Relating to the Submission of Security-Related Information Prior to the Entry of a Ship into Port.
19. IMO. (2013) MEPC.1/Circ.644/Rev.1 Standard Format for the Advance Notification Form for Waste Delivery to Port Reception Facilities.
20. IMO. (2003) Resolution A.960(23) Recommendations on Training and Certification and on Operational Procedures for Maritime Pilots other than Deep-Sea Pilots.
21. IMO. (2019) FAL.5/Circ.42 Guidelines for Setting up a Maritime Single Window.
22. IALA. (2015) Guideline G1113 Design and Implementation Principles for Harmonized System Architectures of Shore Based Infrastructure, Ed. 1.0.
23. IALA. (2015) Guideline G1114 A Technical Specification for the Common Shore-Based System Architecture (CSSA), Ed 1.0.
24. IALA. (2018) Guideline G1128 The Specification of e-Navigation Technical Services, Ed. 1.1.
25. IHO. (2018) S-127 IHO Geospatial Standard for Marine Traffic Management, Ed. 1.0.0.
26. IMO. (2004) The International Ship and Port Facility (ISPS) Code.
27. IMO. (1997) Resolution A.862(20) Code of Practice for the Safe Loading and Unloading of Bulk Carriers.
28. ISO (2019), Input paper to IMO EGDH 1/9.
29. IEC. (2019) Maritime navigation and radiocommunication equipment and systems – Data Interface – Part 1: S-421 Route Plan Based on S-100.

In MSC-FAL.1/Circ.3 Annex, maritime cyber risk refers to a measure of the extent to which a technology asset is threatened by a potential circumstance or event, which may result in shipping-related operational, safety or security failures as a consequence of information or systems being corrupted, lost or compromised.

Resolution MSC.428(98) Maritime Cyber Risk Management in Safety Management Systems which was adopted on 16 June 2017:

"recognises the urgent need to raise awareness on cyber risk threats and vulnerabilities to support safe and secure shipping, which is operationally resilient to cyber risk and that Administrations, classification societies, ship owners and ship operators, ship agents, equipment manufacturers, service providers, port and port facilities, and all other maritime industry stakeholders should expedite work towards safeguarding shipping from current and emerging cyber threats and vulnerabilities."

Ship reports contain proprietary information about ship operations, such as voyage, oil consumption, the nature of the cargo and its source and destination as well as personal information about seamen and passengers.

If the cyber security of the system for ship reporting is compromised, then proprietary information and the information systems associated with shipping operations, port and terminal operations and the operations of the whole of supply chain in maritime logistics are at risk as is the access to personal information about seamen and passengers.

There are many ways to threaten cyber security on board and onshore. For example:

• Spread malicious code by laptop infected with malicious execution code.
• Plugging in a USB stick that is infected with malicious code.
• System attack by eavesdropping or hacking into equipment and/or software.
• Accidentally deleting system files.
• Professional hackers who watch for vulnerabilities and invade a network to steal and/or change information and data.

In general, the cyber security guideline presents the functional elements that support effective cyber risk management which purpose is to support safe and secure shipping. A risk management framework includes the following:

• Identify - Define personnel roles and responsibilities for cyber risk management and identify the systems, assets, data and capabilities that, when disrupted, pose risks to ship operations.
• Protect - Implement risk control processes and measures, and contingency planning to protect against a cyber-event and ensure continuity of shipping operations.
• Detect - Develop and implement activities necessary to detect a cyber-event in a timely manner.
• Respond - Develop and implement activities and plans to provide resilience and to restore systems necessary for shipping operations or services impaired due to a cyber-event.
• Recover - Identify measures to back-up and restore cyber systems necessary for shipping operations impacted by a cyber-event.

A Cyber Security Guideline on IT infrastructure needs to deal with task dependent situations. Different situations need to be treated with different methods. Cyber vulnerabilities occur variously and unexpectedly and therefore every occurrence should be treated as a new occurrence with a new procedure to respond to it. Figure A1 depicts the continual improvement process of ITIL v3. The Guideline should include how to improve management processes with reference to annex A Figure 1.

There are many best practice guidelines on cyber maritime security by BIMCO, CLIA, ICS, INTERCARGO, INTERTANKO, OCIMF and IUMI.

ISO 27001 provides Information technology - Security techniques - Information security management systems - Requirements.

Also, NIST which is United States National Institute of Standard and Technology published a NIST Framework for improving Critical Infrastructure Cybersecurity.

The implementation and operation of a system for ship reporting is a significant investment. Careful planning should be undertaken to ensure that the system is implemented effectively, achieves its objectives and is sufficiently resourced and funded on an ongoing basis.

When planning and implementing a system for ship reporting, a project management approach is recommended to ensure that the major deliverables, assumptions and constraints are clearly documented. This will assist in defining the scope of the system and its goals and objectives that need to be met. Project management is considered as a discipline with the purpose to achieve specific goals and objectives by planning, organizing, motivating, and controlling resources.

Relevant international guidance prepared and published by appropriate international organizations regarding project management should be considered, or where there are national requirements for project management, these should be used.

ISO 21500 Guidance on Project Management is an international standard issued by the International Organization for Standardization (ISO). In summary, the standard:

• Provides high-level description of concepts and processes that are considered to form good practice in project management.
• Can be used by any type of organization, including public, private or community organizations, and for any type of project, irrespective of complexity, size or duration.

Project management is undertaken in phases in order to improve control and quality. At the end of each phase, a review is typically conducted on the deliverables as well as on the performance of the project team. This helps the team ascertain whether the project proceeds to the next phase or undergoes revision.

This section provides an overview of the five project management phases and the key areas for consideration as they relate to ship reporting:

1. Initiating - This marks the beginning of the project. The goal of this phase is to define the project at a broad level and develop a business case.
2. Planning - During this phase, the scope and goals of the project are defined and a project management plan is developed. It involves identifying the cost, quality, available resources, and a realistic timetable.
3. Implementing - This is the phase where deliverables are developed and completed.
4. Controlling – This phase is invariable carried out simultaneously with Phase 3 (Implementing), thereby ensuring that project objectives and deliverables are met. This phase is about measuring project progression and performance and ensuring that everything happening aligns with the project management plan.
5. Closing - The closing processes are used to formally establish that the project phase or project is finished.

Where possible all concerned shore-based stakeholders should be engaged to ensure that their experience and input in these processes are taken into account. This will also provide a sense of "ownership" with the final result.