National Single Window Prototype

Transcription

1 National Single Window Prototype Overview and Leading Principles Version Date: 15/10/2015 Applicable to NSW Prototype version 1.3

2 Document History Date Changes Prepared by 15/10/2015 Initial version, corresponding to NSW system version 1.3 PDU, CAB Table of Contents 1. Background The Reporting Formalities Directive 2010/65/EU Overview of the National Single Window Prototype SafeSeaNet Leading principles System context Formalities supported Information flow Content of Notifications Quality requirements Cancellation of port call Re-use of information Clearance Acknowledgment Configuration of Ship Data Providers Access to data by Ship Data Providers Configuration of Authorities System Overview System Interfaces System interface with Ship Data Providers Journal Number Voyage Number Consolidation of notifications System interface with SafeSeaNet Use of reference data from SafeSeaNet central databases Page 2 of 13

3 List of Abbreviations AIE AIS CRG EMSA EU GI Hazmat IMP ISO MS NSW RC SSN UI XML Authority Information Exchange Automatic Identification System Common Reporting Gateway European Maritime Safety Agency European Union Graphical Interface Hazardous Material - Dangerous and Polluting Goods Integrated Maritime Policy International Organisation for Standardization Member State National Single Window Resources Console SafeSeaNet User Interface Extensible Mark-up Language List of Annexes Annex 1: NSW Prototype Data Mapping Annex 2: COTS of NSW Prototype Annex 3: NSW Prototype System Interface Guide

4 This document and its annexes, as well as other documentation of the Prototype such as user manuals, system interface documentation and brochure, are publicly available on the EMSA website at the following address: 1. Background This section describes the business environment and underlying systems that connect to and make use of the National Single Window (NSW) Prototype. 1.1 The Reporting Formalities Directive 2010/65/EU The purpose of the Directive is to: simplify and harmonise the administrative procedures applied to maritime transport by making the electronic transmission of information standard by rationalising reporting formalities. The Annex of the Directive lists 14 reporting formalities which are to be submitted electronically, either prior to or on arrival or departure of a ship in an EU port, through a single window. In addition, Member States (MS) may require other reporting formalities in accordance with their national legislation. The information is then made available to the different public authorities who require such information to carry out their legal obligations and is made available in the SafeSeaNet (SSN) system for exchange with other MSs. 1.2 Overview of the National Single Window Prototype The development of the NSW prototype started at the beginning of 2013 as part of an Integrated Maritime Policy (IMP) project. It is conducted by EMSA, in cooperation with six (MSs), each with its own NSW prototype. Other MSs were provided access to a common NSW prototype to familiarize themselves with the implemented functionalities. These NSW prototypes are hosted at EMSA. Three MSs have also hosted the NSW software on their IT environment. The purpose of the prototype was to develop software and service components that would be used by the MS for testing NSW solutions. The prototype allowed MS to choose the solution that best fits their needs and to reduce costs and time for the implementation of their NSW by re-using the technical documentation or the software components built by EMSA. In this regard, software components of the national single window (with web and machine-to-machine interfaces) were developed to: Implement the national single window application and its interfaces with the ship data providers, other national systems, and the central SSN system; Implement the common functionalities (e.g. clearance, acknowledgement, data quality checks) of the NSWs; Provide services related to the reference databases (e.g. geographic locations and ship particulars); and Test the compilation of ship positioning data with the relevant reporting formalities and distribution of the combined data to the various authorities via a graphical interface. 1.3 SafeSeaNet SSN is the Union maritime information and exchange system established to enable the exchange of vessel and voyage related information between EU MSs, to provide the Commission with the relevant information in accordance with EU legislation, and to support MSs in satisfying their operational information needs. Page 4 of 13

5 The objective of the SSN system is to support the Commission and Member States activities for the purpose of maritime safety, port and maritime security, marine environment protection and the safety and efficiency of maritime traffic. SSN is a network of national systems in Member States which are linked to a central SSN system hosted by EMSA that acts as a nodal point. The central SSN system has different interfaces available to facilitate different means of transmission. In addition, SSN features Central Databases of reference information, such as ship particulars and location codes. Due to the Reporting Formalities Directive 2010/65/EU, SSN was upgraded to support the exchange of additional reporting formalities in electronic format. 2. Leading principles 2.1 System context The NSW Prototype: Collects information from reporting formalities required before or at ship s arrival or departure; Distributes the information to the relevant national and local authorities; Records decisions and comments from the authorities and communicates them to the ship data providers. In addition, the NSW interconnects with the SSN system in order to retrieve information from previous port calls from other MSs. Ship data providers can submit notifications via the XML System Interface (based on the ISO standard) and the Web User Interface, which also includes the possibility to upload XLS files. Relevant information is made available to authorities using the Web User Interface. Fig.1: Submission of notifications by the Ship Data Provider to Authorities At any stage, a notification can be saved as a draft. Draft notifications are not sent to authorities but the ship data provider can update them at any time. Notifications are only sent to authorities once they are submitted. Acknowledgment messages with decisions and comments from authorities are provided back to ship data providers via the XML system Interface and the Web User Interface. notifications are sent to authorities and ship data providers to warn them of new and updated notifications or decisions.

6 Fig.2: Report of authorities decisions and comments to the ship data providers 2.2 Formalities supported The following reporting formalities may be fulfilled through the NSW: Reporting formalities resulting from legal acts of the Union: 1. Notification for ships arriving in and departing from ports of the Member States (Article 4 of Directive 2002/59/EC establishing a Community vessel traffic monitoring and information system), 2. Border checks on persons (Article 7 of Regulation (EC) No 562/ Schengen Borders Code), 3. Notification of dangerous or polluting goods carried on board (Article 13 of Directive 2002/59/EC establishing a Community vessel traffic monitoring and information system), 4. Notification of waste and residues (Article 6 of Directive 2000/59/EC on port reception facilities for ship-generated waste and cargo residues), 5. Notification of security information (Article 6 of Regulation (EC) No 725/2004 on enhancing ship and port facility security), 6. Entry summary declaration (Council Regulation (EEC) No 2913/92 - Community Customs Code and Regulation (EC) No 450/ Modernised Customs Code), Although not mentioned in the Annex to Directive 2010/65/EU the prototype also includes the requirements of Directive 2009/16/EC on Port State Control: 7. 72h pre-arrival notice for ships eligible to expanded inspections (article 9), 8. Actual arrival and departure notifications (article 24), FAL forms and formalities resulting from international legal instruments: 9. FAL form 1: General Declaration, 10. FAL form 2: Cargo Declaration, 11. FAL form 3: Ship s Stores Declaration, 12. FAL form 4: Crew s Effects Declaration, 13. FAL form 5: Crew List, 14. FAL form 6: Passenger List, 15. FAL form 7: Dangerous Goods, 16. Maritime Declaration of Health, Information resulting from national legislation: 17. Cargo related formalities: Declaration of Temporary Storage, cargo manifest, 18. Waste delivery receipt, 19. Bunkers remaining on board, 20. Civil Liability Certificate for Oil Pollution Damage, Page 6 of 13

7 21. Civil Liability Certificate for Bunker Oil Pollution Damage, 22. Ship defects. All the data elements from these formalities are described using structured data in alpha-numeric characters and are handled either as individual data elements or as a group of data elements. The identification of the data elements which are required to be reported in the NSW is done through configuration by the NSW administrator depending on national legal provisions. Data groups and individual data elements may also be removed through configuration. 2.3 Information flow Information is reported to the NSW in notifications, sent before arrival ("arrival notifications"), before departure ("departure notifications") and at arrival/departure (included in arrival / departure notifications ) through the Web User Interface or the System Interface. Data elements can be reported in distinct notifications by one or several ship data providers. Updates of previously provided information are accepted (in order to update or correct parts of the information). For each received notification the NSW returns a technical receipt. A positive receipt means that the notification has been received by the NSW and will be processed and communicated to the relevant authorities. Communication of authorities decisions is done through an acknowledgment message. All ship data providers who submitted the initial notification or an update are communicated with the acknowledgment message. The message is sent through the System Interface, notified by , and can be consulted in the Web User Interface. Fig.3: Information flow in the NSW 2.4 Content of Notifications Data elements in a notification depend on the type of the notification (arrival or departure). Only the fields relevant for the notification type are included in the Web User Interface forms. When the NSW receives a notification through its System Interface, only data elements which are relevant for the notification type are considered by the NSW and the others are ignored.

8 Depending on its configuration, the NSW will handle all data elements or a group of data elements. The configuration of the NSW will depend on the legislation and requirements applicable in the MS. One or several cargo declarations may be reported per notification. A cargo declaration includes one or several consignments. A consignment includes one or several cargo items. Details on dangerous and polluting goods are reported within the structure of cargo data as part of the cargo item details. Fig.4: Structure of cargo data in a notification The list of data elements and data groups and their mapping with the reporting formalities is provided in Annex 1 Data mapping. 2.5 Quality requirements The NSW does not check whether notifications are reported in time, and does not check if all reporting formalities are completed for a specific ship, or if reporting formalities are possibly wrongly done by a ship. If technically correct (i.e. positive receipt), the notifications are processed (regardless whether legislative constraints are met since no validation takes place) and the data is forwarded to the authorities. It is up to the authorities to take enforcement actions if ships do not report correctly or when it is necessary. 2.6 Cancellation of port call Cancellation of a vessel call is possible before the actual arrival of the ship (i.e. before ATA is reported). The result of cancelling the call is that all reported notifications with underlying data is marked as deleted and considered as not being reported. Cancellation can only be done by the ship data provider who submitted the initial notification. 2.7 Re-use of information The NSW allows the ship data provider to re-use notifications previously submitted in the NSW for other calls of the same ship in order to prepare pre-arrival notifications. The ship data provider will only have to check the information and update the data which has changed from the other call. Page 8 of 13

9 The NSW also allows the ship data provider to re-use data from SSN for preparing pre-arrival notifications. In this case, the NSW requests information from SSN to populate the notifications. The ship data provider will only have to check the information and update it. Information provided by SSN includes: Ship identification and ship particulars; Voyage, pre-arrival, arrival and departure information; Dangerous and polluting goods details; Waste disposal information; Security information, and Crew and passengers information. Note: The re-use of crew and passenger data through SafeSeaNet is only possible for testing purpose in the scope of the NSW Prototype project. Such exchange of information is not supported by the operational SafeSeaNet system. In order to prepare the pre-departure notification, the NSW allows the ship data provider to re-use information from the pre-arrival notification submitted for the same port call. The ship data provider will only have to check the information and update it. 2.8 Clearance Three clearance models are implemented in the NSW: No clearance: no acknowledgement messages is sent by the NSW. Communication of the authorities decisions is done outside of the NSW. Silent clearance: acknowledgement messages are only communicated when the notification is rejected. The notification is considered by default as accepted once received by the NSW (with a positive receipt). Systematic clearance: acknowledgment messages are always communicated to the ship data provider regardless of the decision taken by the authorities. The NSW will only apply one of the above models for all notifications received. The clearance model is configured by the NSW administrator through modification of a configuration file at the installation of the system. 2.9 Acknowledgment Decisions may be done by one or more authorities. Several acknowledgment messages may be provided for a unique notification. Values of status codes are Accepted or Not accepted. Acknowledgment messages with status code Not accepted are provided as soon as an authority rejects the notification. Acknowledgment messages with status code Accepted are provided only once all relevant authorities have accepted the notification. Authorities may record a textual comment as regards each decision they record. The comments are provided in the Acknowledgment message. When information from an update notification is received, previous decisions issued by the relevant authorities, which were based on the original information, have to be reconsidered and are therefore cancelled Configuration of Ship Data Providers Ship data providers are configured by the NSW administrator. The NSW administrator will define the ports covered by the ship data provider, the data element that he/she may report and the agencies that he/she represents. A ship data provider can only send notifications regarding calls in the ports that he/she covers. Notifications can only contain data elements which are permitted to the ship data provider. Ship data providers are associated to one or several agencies. An agency is an organisation which the ship data provider, generally a shipping agent, works for. Agencies generally have contractual relationships with shipping

10 companies which allow them to represent them and fulfil reporting obligations on their behalf. Agencies are maintained by the NSW national administrator Access to data by Ship Data Providers Information from the following groups of data elements can only be read and updated by ship data providers associated with the same agency as the ship data provider who submitted the data group: Security (if the ship security level reported in the notification is 2 or 3), Passengers, Crew, Crew's Effects, Health, Individual cargo declarations (including dangerous and polluting goods details). Information from other data groups can be read and updated by ship data providers of both the same agency and of other agencies Configuration of Authorities An authority is a user who is involved in the decision to accept or reject a notification. An authority is associated to one or more agencies. An agency is an organisation with which the user works and which generally is a public organisation. Agencies are used by the NSW system to consolidate decisions from authorities and define whether a notification is approved. Authorities are configured by the NSW administrator. The NSW administrator will define the ports covered by the Authority, the data element that he/she may process and the agencies that he/she represents. Authorities are communicated with the information from the data groups of the notification based on their configuration. An authority may cover all, several or one port of his/her country. They receive only the information regarding calls in the ports they cover. 3. System Overview The following diagram depicts the architecture of the NSW prototype. Page 10 of 13

11 The following modules form part of the NSW prototype: Fig.5: System architecture overview a) The Common Reporting Gateway (CRG Core) that provides a standardized interface where ship data providers can submit notifications and view decisions by authorities. The CRG features its own User Interface (CRG UI) and a system-to-system interface. b) The NSW Core includes the Authority Information Exchange (AIE). It distributes the information reported in notifications by the ship data providers to the participating authorities, records decisions from authorities and includes a messaging interface with the central SafeSeaNet system. The AIE features is own User Interface (AIE UI). c) The Resources Core (RC) which facilitates the technical administration (i.e. user management and system configuration). The RC features its own User Interface (Resources Mng UI). d) The Graphical Interface (GI) which offers a view of ships and their notifications on a map to the users for CRG and of AIE. Due to its dependency with data from the SSN database, this module is only available in the NSWs hosted at EMSA. A data replication mechanism is implemented between the SSN and NSW databases, allowing the former to source ship positioning information to be stored in the latter. The replicated ship position data is enriched with ship call specific data from the NSW to facilitate the consultation of information. The NSW Prototype is implemented in two forms: A version using proprietary software (e.g. Oracle for the database and Oracle WebLogic for the application server), A version using open-source software (PostgreSQL for the database, Apache Tomcat for the application server).

12 The description of the software products required for the installation of the NSW prototype is provided in Annex 2 - COTS of NSW Prototype. 4. System Interfaces 4.1 System interface with Ship Data Providers The NSW Prototype offers a system-to-system interface to ship data providers system. Its specifications are provided in Annex 3 - System Interface Guide. The XML message structure is derived from the ISO standard for Electronic Port Clearance. A mapping between the data elements of the NSW Prototype and the XML message elements is provided in Annex 1 Data mapping. 4.2 Journal Number All notifications, receipts and acknowledgments for a port call must be associated to an identifier of the port call, called the journal number. The journal number is unique for each arrival or departure of a ship in the ports of the MS and is provided by the NSW (The journal number is different for the arrival notification and for the departure notifications regarding the same ship port call). In the Web User Interface the unique identifier is generated by the NSW and requires no input by the ship data provider. When a notification is transmitted via the System Interface the NSW provides the journal number in the receipt message sent at reception of the first notification. Further update notifications must quote the journal number. 4.3 Voyage Number As alternative to the Journal Number, the NSW may consider the voyage number as provided by the ship data provider in the notification to link notifications regarding the same port call. The voyage number is provided by the ship data provider in the original notification and is considered by the NSW when receiving an update notification without a journal number. As the voyage number is defined by the ship data provider, there is no guarantee that it is unique for arrival and departure in the ports of the MS. The ship data provider has the responsibility to ensure that the voyage number in an update notification matches the voyage number of the original notification. 4.4 Consolidation of notifications The NSW consolidates the data elements received through notifications and distributes the consolidated information to all relevant authorities. Consolidation is based on the journal number (or voyage number if journal number is not provided). All notifications received with the same number are merged. Information regarding the arrival is consolidated and stored separately from information regarding the departure. 4.5 System interface with SafeSeaNet The NSW Prototype fulfils the reporting obligations to SSN in terms of pre-arrival notifications, arrival and departure notifications, notifications of dangerous and polluting goods, security notifications and waste notifications. In addition the NSW Prototype allows the exchange of crew and passengers lists through SSN (exchange of crew and passengers lists is only allowed by SSN in the context of the NSW Prototype project). Each time that a Notification is received from a ship data provider, the NSW will send a PortPlus message with the consolidated notification information to SSN. Page 12 of 13

13 When receiving a Request message from SSN regarding dangerous and polluting goods, waste, security, or crew and passengers details, the NSW will prepare and send a the Response message to SSN with the corresponding data. The NSW will also use the SSN services when requested by the hip data provider in order to retrieve the list of previous port calls of a ship and request the dangerous and polluting goods, waste, security, and crew and passengers details in order to re-use them for preparing a new Notification A mapping between the data elements of the NSW Prototype and the XML elements of the SSN messages is provided in Annex 1 Data mapping. 4.6 Use of reference data from SafeSeaNet central databases The NSW Prototype is designed to receive updates of ship particulars and of location codes from the Central Databases of the SSN system. This aims at facilitating the configuration and maintenance work of the NSW database.

14