Activity 3 Report. Support to Regulation Compliance Systems in MoS

Transcription

1 Activity 3 Report. Support to Regulation Compliance Systems in MoS Document Version: 1 Page 1

2 ABSTRACT In close cooperation with the process developed by the Commission expert group coordinating the implementation of Directive-2010/65/EU on reporting formalities for ships and in coordination with Customs Administrations and Transport Minis tries of Germany, UK, Greece, Slovenia, Italy and Spain, B2MoS has prepared pilot actions that have assisted port authorities, port community systems and business stakeholders to efficiently comply with the requirements of Directi ve-2010/65/eu and with new National Single Windows. From June 1, 2015 it is compulsory to announce vessel calls at European ports electronically through a national single window. The parties mainly affected by the electronic announcement and vessel call notification are ship owners, shipping companies, shipping agents, ship masters and their representatives. The electronic announcement through a single point of data entry provides advan tages for all parties involved: Data exchange by paper is no longer required Data quality will be improved by electronic data exchange Information will be provided only once: no more redundancies Data will be transmitted faster to the respective authorities Harmonised notification obligations will allow easier data transmission bet ween the maritime transport sector and the respective authorities. 27 partners and many shipping agents and ship owners have participated in pilots led by DBH, DAKOSY, MCP, e-puerto Bilbao, PORTIC, valenciaportpcs.net, Italian Ministry of Infrastructure and Transport, Luka Koper and Port Authority of Piraeus. Pilots involving the port community systems (PCS) of the ports of Hamburg, Bre merhaven, Felixstowe and other 11 UK ports, Bilbao, Barcelona, Valencia, Livorno, Civitavecchia, Ravenna, Koper and Piraeus have been carried out to guarantee that the transition to these new systems results in the easiest method for our users. Whenever possible, modifications to simplify processes have been introdu ced and the suggestions and recommendations received from external users par ticipating in the pilots have been incorporated in the new PCS prototype modules. The connections of these new prototype modules developed in prominent PCS have been tested in those countries where the new national single windows (NSW) have been implemented before the end of 2015 (Germany, Spain, Italy and Slove nia). The prototype PCS modules fully compliant with the requirements of Direc tive-2010/65/eu have been tested in Greece and the UK with shipping agencies and ship owners and these programmes will be ready to be connected with the Greek and UK NSW respectively whenever those new systems will be available. Page 2

3 Just to give an example of the work carried out in this activity, the Spanish work in this activity is briefly summarised next. In Spain, a Royal Decree (1334/2012) was published for information requirements formalities for vessels arriving and/or de parting from Spanish ports. This regulation is, in fact, the transposition of Directive 2010/65/EU. Article 4 nominates the port authorities as the National Single Win dows through which all information formalities will be presented in electronic form. Within this context, the Ports Authorities of Bilbao, Barcelona and Valencia and their port community systems have been working in the B2MoS project framework to prototype systems that meet the new regulatory requirements and help their respective port communities in this transition. The main changes affecting this new declaration form involve these messages: Passenger and Crew List, Waste management notification, Dangerous goods de claration and Maritime Health Declaration. These changes include new information requirements that will result in some be nefits such as: port-to-port validation; PSC inspection validation from port to port; waste management validation from port to port and pre-arrival identification of the ship location. In addition, there will be a special treatment for dangerous goods. It will be mandatory to indicate: packing group, cargo description, cargo location and consignor and consignee identification. This document presents the reports elaborated by by each partner participating in Activity 3. DISCLAIMER "The sole responsibility of this publication lies with the author. The European Union is not responsible for any use that may be made of the information contained therein." AUTHORS: Jonas Mendes Constante, Fundación Valenciaport José García, Autoridad Portuaria de Valencia Jaime López, Fundación Valenciaport Eva Pérez, Fundación Valenciaport Fabio Tollini, IB Page 3

4 Maurizio Ricci, IB Ekaterina Kuznetcova, IB Caterina Cerrini, IB Davide Sansonetti, AP Civitavecchia Edoardo Morea, RINA Evelyn Eggers, Dakosy Gunter Klein, DBH Martina Grzañcic, Luka Kopler Jana Barba, Intereuropa Dimitris Spyrou, Piraeus Port Authority WITH CONTRIBUTIONS FROM: AP Civitavecchia (Porti di Roma), RCT (Roma Cruise Terminal), Port Mobility, IB, RINA, Costa Crociere, Port of Barcelona, PortIC. VERSION HISTORY Date Document Version Document Revision History Document Author/Reviser 29 April First Draft (vs 1) Jaime López 11 May Second Draft (vs 2) Jonas Constante 9 Nov Final version Jonas Constante APPROVALS Date Document Version Document Approved by TABLE OF CONTENTS ABSTRACT... 2 DISCLAIMER... 3 Page 4

5 AUTHORS:... 3 WITH CONTRIBUTIONS FROM:... 4 VERSION HISTORY... 4 APPROVALS... 4 TABLE OF CONTENTS... 4 INDEX OF TABLES... 8 INDEX OF GRAPHS AND FIGURES... 9 GLOSSARY OF ABBREVIATIONS INTRODUCTION MAIN OBJECTIVE OF THE ACTIVITY SCOPE REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN VALENCIAPORTPCS.NET PARTNER(S) RESPONSIBLE FOR THIS REPORT: PORT AUTHORITY OF VALENCIA AND FUNDACIÓN VALENCIAPORT LEGAL CONTEXT FORMER AND CURRENT COMMUNICATION SCHEMES PROTOTYPE ADAPTATIONS IN VALENCIAPORTPCS.NET PROTOTYPING, PILOTS AND IMPLEMENTATION IN VALENCIAPORTPCS.NET REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN CIVITAVECCHIA AND BARCELLONA PARTNER(S) RESPONSIBLE FOR THIS REPORT: AP CIVITAVECCHIA, IB, RINA, PORT OF BARCELONA LEGAL CONTEXT FORMER AND CURRENT COMMUNICATION SCHEMES PILOTS DESCRIPTION CIVITAVECCHIA PILOT MAIN PURPOSE ACTORS INVOLVED...43 Page 5

6 3.4.3 BUSINESS AND TECHNICAL GOALS PILOT SCENARIO PROTOTYPE ADAPTATIONS IN GIADA PCS BARCELONA PILOT MAIN PURPOSE ACTORS INVOLVED BUSINESS AND TECHNICAL GOALS PILOT SCENARIO PROTOTYPING, PILOTS AND IMPLEMENTATION ANNEXES ANNEX PMI TECHNICAL SPECIFICATIONS ANNEX GIADA WEB SERVICE SPECIFICATIONS REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN TINO AND INTEREUROPA SYSTEM PARTNER(S) RESPONSIBLE FOR THIS REPORT: LUKA KOPER, PORT AND LOGISTIC SYSTEM, D.D LEGAL CONTEXT FORMER AND CURRENT COMMUNICATION SCHEMES PROTOTYPE ADAPTATIONS PILOTS MAIN PROBLEMS ENCOUNTERED FOR EACH NEW APPLICATION AND SOLUTIONS PROVIDED DURING THE PILOT PERIOD LIST OF PROBLEMS THAT REMAIN UNSOLVED ANNEXES REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PCS OF HAMBURG PARTNER(S) RESPONSIBLE FOR THIS REPORT: MCP PILOTS IN ACTIVITY 3 DIRECTIVE 2010/65/EU LEGAL CONTEXT Page 6

7 5.2 UK FORMER AND CURRENT COMMUNICATION SCHEMES UK PROTOTYPE ADAPTATIONS AND PILOTS REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PCS OF BREMEN AND BREMERHAVEN PARTNER(S) RESPONSIBLE FOR THIS REPORT: DBH LOGISTICS IT AG LEGAL CONTEXT FORMER AND CURRENT COMMUNICATION SCHEMES FORMER COMMUNICATION SCHEME CURRENT COMMUNICATION SCHEME PROTOTYPE ADAPTATIONS IN PCS OF BREMEN AND BREMERHAVEN MODIFICATIONS ON EXISTING PCS MODULES NEW COMMUNICATION STRUCTURES NEW DEVELOPPED FUNCTIONALITIES IN ANSW (NEW PCS MODULE) PROTOTYPING, PILOTS AND IMPLEMENTATIONIN PCS OF BREMEN AND BREMERHAVEN ANNEXES Annex: dbh - ANSW_User_Manual_EN.pdf Annex 2: dbh - ANSW_XML_Example.xml REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PCS OF HAMBURG PARTNER(S) RESPONSIBLE FOR THIS REPORT: DAKOSY DATENKOMMUNIKATIONSSYSTEM AG LEGAL CONTEXT FORMER AND CURRENT COMMUNICATION SCHEMES COMMUNICATION SCHEME PRIOR THE IMPLEMENTATION OF DIRECTIVE 2010/65/EU COMMUNICATION SCHEME AFTER THE IMPLEMENTATION OF DIRECTIVE 2010/65/EU PROTOTYPE ADAPTATIONS IN DAKOSY EDECLARATION FOR CARRIERS GEGIS MONITORING DANGEROUS CARGO IN HAMBURG Page 7

8 7.3.3 EDECLARATION FOR AUTHORITIES PILOTS SOLUTIONS PROVIDED DURING THE PILOT PERIOD TASKS FOR THE NEAR FUTURE ANNEXES DAKOSY REPORT Annex 1: DAKOSY - Fact sheet edeclaration for Carrier Annex 2: DAKOSY - Reference Sartori & Berger GmbH Co. KG a pilot user of edeclaration for Carriers Annex 3: DAKOSY - XSD of NSW interface REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PORT COLLABORATIVE COMMUNITY SYSTEM (PCCS) OF PIRAEUS PORT AUTHORITY PIRAEUS PORT AUTHORITY LEGAL CONTEXT FORMER AND CURRENT COMMUNICATION SCHEMES PROTOTYPE ADAPTATIONS IN PCCS OF PIRAEUS PORT AUTHORITY PROTOTYPING, PILOTS AND IMPLEMENTATION INDEX OF TABLES Table 1 - Forms with changes in the valenciaportpcs.net Table 2 - Formalities at arrival (before implementation) Table 3 Formalities at departure Table 4 - Formalities at arrival (after implementation) Table 5 Formalities at departure (after implementation) Table 6 Overview DACOM Table 7 Overview SIS Table 8 Overview EDI Communication System Table 9 Reporting Classes (uncontrolled sequence) Table 10 Overview Functionalities (Main Reporting Types) in ANSW Page 8

9 Table 11: Communication schemes in Hamburg prior to the implementation of Directive 2010/65/EU INDEX OF GRAPHS AND FIGURES Figure 1. Dueport (Spain National Single Window System) structure Figure 2 - The relation between Dueport and a Spanish PCS Figure 3 - Main adaption: documents cannot be sent using messages anymore Figure 4 Berth request - Old form Figure 5 Berth Request - After the implemenation Figure 6 Vessel Data - Old form Figure 7 Vessel Data - After the implementation Figure 8 Vessel Data Old form Figure 9 Vessel Data After the implementation Figure 10 ISPS - Old form Figure 11 ISPS - After the implementation Figure 12 Berthings - Old form Figure 13 Berthings - After the implementation Figure 14 Attachments - Old form Figure 15 - Attachments After the implementation Figure 16 Passenger List - Old form Figure 17 Passenger List - After the implementation Figure 18 Passenger Data - Old form Figure 19 Passenger Data - After the implementation Figure 20 Passenger Crew Data- Old form Figure 21 Passenger Crew Data - After the implementation Figure 22 Waste Management - Old form Figure 23 Waste Management - After the implementation Figure 24. Former Italian Communication Scheme Figure 25 - Current Italian Communication Scheme Figure 26 Push pattern Page 9

10 Figure 27 - Pull Pattern Figure 28 - The CCSA Message Handling System (Marine Standard Messagge as in AnNA Project) 42 Figure 29 Target scenario Figure 30 Pilot scenario Figure 31- Information before and after GIADA implementation Figure 32 List of movements Figure 33 - Movements related to cruise ships of Costa Cruises Figure 34 Berth data Figure 35 Passenger s details Figure 36 Aggregated data Figure 37 Pilot description, Port of Barcelona Figure 38 - Screenshot of the entry page of NEO (source: Maritime Administration of the RS) Figure 39 - Screenshot of the NEO, including data needed for Luka Koper Figure 40 - Screenshot of the NEO, details on dangerous cargo Figure 41- screenshot of the TinO (NPID module) that includes the NEO number Figure 42 Screenshot of the TinO (NPID module) with vessel details Figure 44 - Prototype in Intereuropa resoult generated Figure 43 - Prototype in Intereuropa macros in background Figure 45 Example reporting formalities in Bremen Figure 46 Former Communication Scheme Figure 47 Current Communication Scheme Figure 48 Status monitor ANSW (in extracts) Figure 49 Different Reporting-Classes for different Authorities Figure 50 Example Reporting Class description xls (HAZD) Extract Figure 51 Example Reporting Class description xsd (HAZD) - Extract Figure 52 Example Data Flow Diagram Dangerous Goods Figure 53 Communication Flow Regional Authorities Figure 54 Communication Flow Federal Authorities Figure 55 Functionality General Overview (Extract) Figure 56 Functionality Arrival Notification (Extract) Page 10

11 Figure 57 Functionality Details Arrival/Departure (Extract) Figure 58 Functionality Port notification (Extract) Figure 59 Functionality Departure Notification (Extract) Figure 60 Functionality Security (Extract) Figure 61 Functionality Preannouncement 72 hour (Extract) Figure 62 Functionality Border Police (Extract) Figure 63 Functionality Maritime Health Declaration (Extract) Figure 64 Functionality Dangerous Goods Arrival (Extract) Figure 65 Functionality Dangerous Goods IMDG-Item Figure 66 Functionality Waste Management Figure 67 Functionality Configuration Access Rights Figure 68 - Offline Excel ANSW file (Example Sheet Overview ) Figure 69 Offline Excel ANSW file (Example Sheet Ship Notification ) Figure 70: Reporting formalities in a German port on a timeline Figure 71: Reporting formalities when transiting the Kiel Canal Figure 72 - Communication scheme with the German NSW (courtesy of WSV) Figure 73: Example for a single register class: STAT Ships details Figure 74: The Single Register Classes of the German National Single Window ZMS Figure 75: Example of a communication scheme for single register classes (courtesy of WSV) Figure 76: Communication flow reporting formalities with edeclaration Figure 77: Reporting formalities shared tasks between ship and land Figure 78: edeclaration for carriers the 4 modules Figure 79: Screenshot edeclaration module On-board solution Figure 80: 2nd Screenshot edeclaration module On-board edeclaration Figure 81: Screenshot edeclaration module Web - Overview Figure 82: Screenshot edeclaration module Web ship details Figure 83: Screenshot edeclaration module Web User configuration of alerts Figure 84: The GEGIS - Network Figure 85: The one roof concept of GEGIS Figure 86: edeclaration for Authorities Page 11

12 Figure 87: Screenshot edeclaration module Web - non-discriminatory access Figure 88: Screenshot edeclaration module Web Dashboard Figure 89: PRISE- Port River System Elbe Figure 90 - graphical representation of the integration of PCCS with the National Single Window Figure 91: Standalone application allows the communication with PCCS Figure 92: Logging of Lavrio Harbour Master in the PCCS using the web interface Figure 93: New message for the Lavrio Habrour Master Figure 94: Visibility of transaction for message reception GLOSSARY OF ABBREVIATIONS CCSA CSV EMSA ETA ETD EU FTP GISIS IMO ISSC LOCODE M2M MMSI MoS MSM NMSW PCS PMI TEN-T Costa Crociere System Adaptor Comma-separated values European Maritime Safety Agency Estimate Time of Arrival EstimateTime of Departure European Union File Transfer Protocol Global Integrated Shipping Information System International Maritime Organization International Ship Security Certificate United Nations Code for Trade and Transport Locations Machine-to-machine Maritime Mobile Service Identity Motorways of the Sea Marine Standard Message National Maritime Single Window Port Community System Port Message Integrator Trans-European Networks - Transport Page 12

13 1 INTRODUCTION The Business to Motorways of the Sea (B2MoS) global project aims to provide a suitable array of measures in order for ports to become efficient gateways. The ultimate goal is to boost the ability of short sea shipping to compete in more door-to-door corridors and facilitate the development of the TEN-T Motorways of the Sea network connecting Europe, bridging the gaps between the TEN-T corridors and revitalising the peripheral regions. Despite the progress achieved in recent years in maritime transport information systems, there are a number of underlying problems affecting efficiency, performance and quality of services related to maritime transport. Major European ports have advanced information systems, which deliver considerable quality and efficiency gains. However, the interoperability between port community systems is practically non-existent, limiting the potential for new services and economies of scale. Small ports may not be equipped with electronic data transmission systems at all. Most frequently, at each port of call, the same data has to be entered repeatedly and often manually by the shipmaster or agent, resulting in wasted time and errors. The B2MoS global project aims to sustain efficient communication procedures and collaborative information exchanges among public and private stakeholders with a view to simplifying the compliance with regulations and administrative procedures while maintaining or even enhancing control requirements for security and safety in transport. In order to address these underlying problems and in anticipation of a new era of information technology, the B2MoS global project is supporting the implementation of relevant EU directives, such as the Reporting Formalities for Ships Arriving in and/or Departing from Ports (2010/65/EU), the Framework for the Deployment of Intelligent Transport Systems in the Field of Road Transport and for Interfaces with Other Modes of Transport (2010/40/EU), the VAT directive (2006/112/EC) and the Electronic Signatures Directive (1999/93/EC). 1.1 MAIN OBJECTIVE OF THE ACTIVITY This activity gave support to port authorities and MoS business stakeholders for them to comply effectively with regulations affecting MoS. The introduction of prototype tools, components and services in port community systems and port management systems that help to Page 13

14 comply with regulations taking into account European, national and local rules were one of the main objectives of this activity. Activity 3 was based on the minimum requirements agreed by institutional platforms where most Member States were represented and it was contributed to with pilots from the business side of the sector. This activity mainly dealt with regulation compliance systems for Directive 2010/65/EU. Directive 2010/65/EU Of The European Parliament And Of The Council Of 20 October 2010 On Reporting Formalities For Ships Arriving In And/Or Departing From Ports Of The Member States And Repealing Directive 2002/6/EC, transposed and published by the EU Member States before 19 May 2012, establishes that ship reporting formalities in the EU need to be simplified and harmonised without prejudice to the nature and content of the information required and without introducing any additional reporting requirements for ships. Member States shall accept the fulfilment of reporting formalities in electronic format and their transmission via a single window as soon as possible and in any case no later than 1 June Directive 2010/65/EU deals with how the information procedures can be simplified and harmonised along with how the information could be gathered more effectively. Its implementation will require the creation of national single windows and new information communication procedures that will affect the functioning of current port management systems, port community systems and business systems (mainly those of shipowners, sea carriers and shipping agencies). 1.2 SCOPE To prepare port authorities, port community systems and business stakeholders systems to efficiently comply with the requirements of Directive 2010/65/EU and with new National Single Windows, this activity was divided into four sub-activities: (i) analysis, (ii) prototyping, (iii) piloting and (iv) Public demonstration. Analysis: This sub-activity started with the analysis of the work and results of the Commission expert group coordinating the implementation of Directive 2010/65/EU on ship reporting formalities. It followed on the progress in the EU e-maritime initiative and will closely coordinate with TEN-T potential future actions supported by Maritime and Customs Administrations of the EU Member States dealing with the creation of the National Single Windows. This analysis will be made in order to know how the Directive is proposed to be implemented in each of the Member States involved in B2MoS. An in-depth study of the new Page 14

15 information procedures proposed and how these new processes affect port management systems, port community systems (PCS) and business stakeholders systems was conducted. It analysed the modifications that port management, PCS and business systems will require in order for them to comply with the new requirements and to communicate with the National Single Windows. Prototyping: The prototyping phase of Activity 3 started at the beginning of This subactivity built the necessary modifications and adaptation of processes in business systems in order for them to comply effectively with the minimum requirements and design of the National Maritime Single Windows to provide different prototypes in different EU ports piloted. The three kinds of systems that were revisited and improved via prototyping and piloting changes in processes and messages were: Port management systems, Port community systems (PCS), Business stakeholders systems, mainly those of shipping agencies and logistic operators. Piloting: The goal of the piloting sub-activity was to test different prototypes in the following representative ports participating in B2MoS: Hamburg, Bremerhaven, Felixstowe, Valencia, Barcelona, Livorno, Koper and Piraeus. This sub-activity demonstrated how the introduction of compliance regulation systems at the port level helped to comply with the requirements established by the Directive and at the same time, fostered the better use of MoS by introducing trade and transport facilitation measures. It also assessed the benefits of such measures and identified the different factors along with the required agreements that will drive the success of the introduction of this new Directive in European ports. Public demonstration: The Activity 3 country pilot leaders together with the partners participating in the national pilot they lead and with the support of the communication project office organised public demonstrations of the prototypes piloted in this activity. These public demonstrations were organised in coordination with the representatives of the Member States leading the creation of National Single Windows. They focused on the adaptations and changes required in MoS business stakeholders, port community systems and port authorities systems for them to comply with Directive 2010/65/EU and to be able to efficiently communicate with the National Single Windows. These public demonstrations are the fourth milestone in the B2MoS project. All B2MOS partners and implementing bodies have participated in Activity 3. Page 15

16 2 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN VALENCIAPORTPCS.NET PARTNER(S) RESPONSIBLE FOR THIS REPORT: PORT AUTHORITY OF VALENCIA AND FUNDACIÓN VALENCIAPORT 2.1 LEGAL CONTEXT Directive 2010/65/EU of The European Parliament and of The Council Of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States and repealing directive 2002/6/EC, transposed and published by the EU Member States before 19 May 2012, establishes that ship reporting formalities in the EU need to be simplified and harmonised without prejudice to the nature and content of the information required and without introducing any additional reporting requirements for ships. Member States shall accept the fulfilment of reporting formalities in electronic format and their transmission via a single window as soon as possible and in any case no later than 1 June Directive 2010/65/EU deals with how the information procedures can be simplified and harmonised and how the information could be gathered more effectively. Its implementation will require the creation of national single windows and new information communication procedures that will affect the functioning of current port management systems, port community systems and business systems (mainly those of shipowners, sea carriers and shipping agencies). In Spain, a Royal Decree (1334/2012) was published on 21st of September for information requirements formalities for vessels arriving and/or departing from Spanish ports. This regulation is, in fact, the transposition of Directive 2010/65/EU. Article 4 nominates the port authorities as the National Single Windows through which all information formalities will be presented in electronic form. The regulation also determines that Puertos del Estado shall establish and maintain the National SafeSeaNet System, which allows the exchange of maritime information among authorised users, under the responsibility of the Ministry of Public Works, who is the National Competent Authority (NCA). Puertos del Estado is the competent body responsible for defining the format for the provision (including structure and syntax) of all the information concerning maritime traffic to the rest of the competent bodies that require the information introduced in the Spanish SafeSeaNet System. After the Royal Decree (1334/2012), the normative Orden FOM 1498/2014 was introduced by the Minister of Development to regulate the integrate vessel berth request procedures in general interest ports. Page 16

17 Within this context, in this project the Port Authority of Valencia, Port Authority of Bilbao and the Port Authority of Barcelona have been working on the changes and new structures and syntax that will be established in the National Single Window by Puertos del Estado. After the initial period of analysis, prototypes for the modifications that port community systems (PCS) and port authority management systems require in order for them to comply with the new requirements and for them to communicate with the National Single Windows were designed and piloted. 2.2 FORMER AND CURRENT COMMUNICATION SCHEMES Before entering in the details of PCS changes is important to describe the changes in Dueport, the Spanish National Single Window System. Dueport System is the single point where the reporting formalities, related to the arrival or departure of a vessel form a Spanish port, are submitted once. Puertos del Estado made the information available to other national competent authorities, other Member States, or EMSA. Port Authorities act as the local point of entry to the National Single Window. In order to have interoperable and compatible systems, Puertos del Estado defines the data model, the structured format, the harmonised messages for the electronic transmission of the information, and the applicable procedures and Business Rules. Error! No se encuentra el origen de la referencia. shows the structure of Dueport and its links with other authorities. Page 17

18 Figure 1. Dueport (Spain National Single Window System) structure To adjust to this new legal context Puertos del Estado have introduced the following changes in Dueport system: Vessel identification (IMO, MMSI, call sign+bandera) Before and After Port Validations The Captain s Nationality Validation of the vessel registration port and registration certificate port Validation of the vessel PSC last inspection port Validation of the waste delivery port Consignee validation (through NIF) Required to declare shipping code ( PdE code ) Mandatory dispatch time (date and duration ) Declare berthing operations and stevedoring company (except supplies and passage) Pre -Arrival indicating port or geographical position of the vessel Page 18

19 In HAZMAT is required: packing group, description of goods, location (goods / equipment), consignor (HAZMAT output), recipient (HAZMAT input), ISO 6346 standard of the equipment. The relation between Dueport and a Spanish PCS (ie. valenciaportpcs.net) is explained in Error! No se encuentra el origen de la referencia.. It starts with the shipping agencies using the ValenciaPort PCS, which updates information to and from customs and other authorities in real time. The communication of the operation is reported to the National Single Window, which also has links with customs and the SafeSeaNet System. Figure 2 - The relation between Dueport and a Spanish PCS 2.3 PROTOTYPE ADAPTATIONS IN VALENCIAPORTPCS.NET Prior to the implementation some information was exchanged by transferring digitalised documents (in pdf, jpg, format etc.). They now need to be transmitted introducing the data in the forms of the system. This structured format allows the use of the information without any previews treatment. Figure 3 - Main adaption: documents cannot be sent using messages anymore Page 19

20 In the valenciaportpcs.net the main change is in the management of passenger lists, which was previously not required by the port authority to berth in its ports. PAV will require passenger lists (which must be sent by the introduction of these data in the system) when the vessel comes from a port located outside the European Union. The system allows the use of this data by the shipping companies, taking advantage of the Single Window system, when other authorities request the same information. In the following valenciaportpcs.net forms changes have been introduced: Table 1 - Forms with changes in the valenciaportpcs.net 1. Berth request 2. Berth request - Vessel data 3. Berth request - ISPS 4. Berth request - Berthings 5. Berth request Attachements 6. Passenger List 7. Passenger List Passenger Data 8. Passenger List Crew Data 9. Waste management (WASDIS) For each change listed above, the following items describe how the forms were before the implementation and how they are now. 1) Berth request The new way to identify the vessel: If it has the IMO number, then the identification uses this. If not, it will use the MMSI number (Maritime Mobile Service Identity). In case there is no MMSI, it needs to use the CallSign + Flag of the vessel. At least one of these values is required to identify the vessel. Each one of these identifications is unique. It is not posible to have two vessels with the same MMSI. The vessel name is still required in all cases. The captain s nationality, in the arrival and departure, should be a valid UNLOCODE. The description of the cargo was introduced for departure Page 20

21 Figure 4 Berth request - Old form Page 21

22 Figure 5 Berth Request - After the implemenation 2) Berth request Vessel data The new way to inform vessel data: If a berth request is being changed, the vessel cannot be modified. It is not possible to change the value used to identify the vessel. For example, in the case that the vessel was identified by MMSI, it is possible to introduce an IMO number and change the CallSig + Flag of the vessel, but not the MMSI. In a berth request, after introducing one of the three values to find the vessel, the information corresponding FTB will be inserted and remain fixed, allowing the modification of the other qualifiers and data. The shipping company is not in the FTB, but in the berth request form. Page 22

23 The address data of shipping company was excluded. Figure 6 Vessel Data - Old form Figure 7 Vessel Data - After the implementation Page 23

24 Other changes in the vessel data form: When you specify that the vessel has a certified IGS, the date, the certificate number and the entity that signs it must be entered. In the FTB, the certificate of registration number and date of issue fields were added as optional. New validation for the tonnage certificates and registration: the delivery date must be prior to the date of submission. Figure 8 Vessel Data Old form Page 24

25 Figure 9 Vessel Data After the implementation 3) Berth Request ISPS Changes made in this form: Indication if the vessel has the ISSC (International Ship Security Certificate) o In case it indicates the ISSC number, dispatching administration and expiry date o If the vessel does not have this information, it should be indicated why this is the case. Protection Officer of the vessel and its telephone number was added. Geographical location of the vessel through the port UNLOCODE or geographical location was added. Security level in which the vessel operates was added. Indication if the vessel has a Vessel Security Plan (VSP) approved on board. o Indication if there is other information regarding protection. Indicate if it has followed the security procedures in accordance with the VSP. Page 25

26 o In case it has not, it shall be informed, in one of the 10 port facilities, beginning and ending dates of activities, description of the activity and description of alternative measures taken. Indicate if special measures of protection were taken. o If they were, the actions that were taken should be reported in any of the 10 port facilities. For the last 10 port facilities, it also should be informed: o Identification of the installation: through GISIS code or name of the facility o Port ( LOCODE ) o Arrival and departure dates o Level of protection Figure 10 ISPS - Old form Page 26

27 Figure 11 ISPS - After the implementation 4) Berth Request Berthings For berthing, a cancellation is allowed to modify the dates (ETA and ETD). Checking for damage in the berthing was added. The FTB observations were excluded. The cargo description field was added. The start and end of operations are mandatory if there is loading or unloading operation, even in the case of cruise vessel. Page 27

28 Figure 12 Berthings - Old form Figure 13 Berthings - After the implementation Page 28

29 5) Berth Request Attachments Scanned documents are no longer allowed. It is possible to upload a CSV file. The date of departure from the previous port (optional) was added. The full name should be separated by "/" The " type ID " and the expiry date of identification are needed. Figure 14 Attachments - Old form Figure 15 - Attachments After the implementation Page 29

30 6) Passenger List Figure 16 Passenger List - Old form Figure 17 Passenger List - After the implementation Page 30

31 7) Passenger List - Passenger Data Now the sex of the person, date of departure and arrival and vehicle (number, brandname and model) data are needed. The identification number and expiry date of this identification is mandatory. Figure 18 Passenger Data - Old form Figure 19 Passenger Data - After the implementation Page 31

32 8) Passenger Crew Data Changes in the crew required data: The fields departure date, last arrival date, duration of working journey and duration of daily rest are removed. The insurance company field was removed. If cargo is reported as "Other ", a text description should be provided. Figure 20 Passenger Crew Data- Old form Figure 21 Passenger Crew Data - After the implementation Page 32

33 9) Waste Management (WASDIS) Added new types of waste (for types 1 and 5) Added the indication discharge mode (land side or maritime side) Figure 22 Waste Management - Old form Figure 23 Waste Management - After the implementation Page 33

34 2.4 PROTOTYPING, PILOTS AND IMPLEMENTATION IN VALENCIAPORTPCS.NET The development of the prototypes occurred from May 2014 to February After this period the pilot phase started on 26 th March 2015 and took one month to complete. During this period until the middle of April 2015 some problems were encountered and new adjustments were provided in the application. On April 26 th the pilot period with shipping agencies and shipowners was completed. After that, more pilots were carried out between the PCS and Dueport until 1 June The following companies have participated in the pilots phase: Agunsa Europa, S.A. American President Lines, Ltd Arola Aduanas Y Consignaciones, S.L. Cesa Stevedoring, S.A. Hanjin Spain, S.A. Maraza Sagunto, S.L. Navarro Y Boronad, S.L. Simon Montolio Y Cia., S.A. Agencia Marítima Evge Valencia, S.A. Camar Agencias Marítimas, S.L. China Shipping (Spain) Agency, S.L. Cma Cgm Iberica S.A.U. Coll Marítima, S.L. Consignaciones Marítimas Internacionales,S.A. Cosco Iberia, S.A. Hapag Lloyd Spain, S.L. Ership, S.A. Grimaldi Logística España, S.L. Bollore Transport Logistic Spain, S.A.U. Intramediterráneo Valencia, S.A. Logística Puerto Sagunto, S.L. Macandrews, S.A. Marítima Dávila Valencia, S.A. Marítima Del Mediterráneo, S.A. Martico Valencia, S.L. Hijo De J.M. Masiques, S.A. Pérez Y Cía, S.L. Roca Monzó, S.L. Romeu Y Cía., S.A. Rosport Shipping, S.L.U. Transportes Y Consignaciones Marítimas, S.A. Transitainer, S.A. Transocean Transit, S.L. Universal Marítima, S.L. Valship, S.A. Arkas Spain, S.A. Cia. Transmediterranea, S.A. Vapores Suardiaz Mediterraneo, S.A. Evergreen Shipping Spain, S.L. Compañia Sudamericana De Vapores Agencia Maritima, S.L. Eurolineas Maritimas, S.A. (Balearia) Canarship,S.L. Consignaciones Maritimas Y Logistica, S.L. (Colmar) Combalia Agencia Marítima, S.A Page 34

35 W.E.C. Lines España, S.L.U. E. Erhardt Y Cia Berge Marítima, S.L. Operinter Valencia, S.L. Gimeno Marítima, S.L. Miller Y Cía., S.A. Soluciones Integrales Marítimas, S.L.U. Uasac Iberia S.L. M.S.C. España, Slu Wilhelmsen Ships Services, S.L. The problems encountered during the pilot period are as follows: When there is an error in the csv importation, a message is not displayed for the user It is not possible to update a csv file in English There were differences in the same server error messages when you compare it with the English and Spanish version The Captain's declaration cannot be sent as an attachment For roro vessels, it is been shown an erroneous description (Vessel name invalid) in the validation: it is mandatory indicate at least one ramp if the vessel type is >='030' or <='040 It is necessary to add in the favourites folder passengers and crew the following data: document type and expiry date The following improvements actions were made during the pilot phase: Added document type and expiry date fields for the favourite passengers and crew Updated passenger list using csv file in English Passengers list - added new validation for passengers that came from outside the Schengen area Passengers list added new validation allow or not inclusion of blank spaces in the brand/model description of the vehicle Updated the management of favourites Excluded obsolete branch codes associate with BERTH Reviewed the berthing copy process Reviewed error messages Passengers list added option to download csv file Passengers list added option to partial upload using csv file Included total of registers in the passengers list Reviewed user s interfaces Reviewed reports. Page 35

36 3 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN CIVITAVECCHIA AND BARCELLONA PARTNER(S) RESPONSIBLE FOR THIS REPORT: AP CIVITAVECCHIA, IB, RINA, PORT OF BARCELONA. 3.1 LEGAL CONTEXT Directive 2010/65/EU of The European Parliament and of The Council Of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States and repealing directive 2002/6/EC, transposed and published by the EU Member States before 19 May 2012, establishes that ship reporting formalities in the EU need to be simplified and harmonised without prejudice to the nature and content of the information required and without introducing any additional reporting requirements for ships. Member States shall accept the fulfilment of reporting formalities in electronic format and their transmission via a single window as soon as possible and in any case no later than 1 June Directive 2010/65/EU deals with how the information procedures can be simplified and harmonised and how the information could be gathered more effectively. Its implementation will require the creation of national single windows and new information communication procedures that will affect the functioning of current port management systems, port community systems and business systems (mainly those of shipowners, sea carriers and shipping agencies). 3.2 FORMER AND CURRENT COMMUNICATION SCHEMES Italian NMSW is based on the existing Maritime Authority reporting system (PMIS, an ad hoc version of which is operating in each major port), the existing e-custom s system (AIDA) and PCSs. The former architectural scheme is that shown in Figure 24. Page 36

37 Figure 24. Former Italian Communication Scheme The current architecture is shown in Figure 25, as the result of both AnNa and B2MOS projects. Figure 25 - Current Italian Communication Scheme Page 37

38 3.3 PILOTS DESCRIPTION The Pilot activities have been developed by the Port of Civitavecchia (Porti di Roma) and IB, both Implementing Bodies of MIT (Italian Ministry of Transport), under the coordination of MIT and RINA; Italian shipowner Costa Crociere has been involved as B2MOS stakeholder representing one of the major Cruise shipping companies. Further exploitation of the Pilot have been carried out with the Port of Barcelona. The main purpose is to facilite the CREW and PAX list management. Details about the two pilots are provided in the following paragraphs of this document. Here below there is the description of the ICT systems and communication technologies that have been used in the implementation of both the pilots. Costa Crociere involved ICT sistems are the following: SAPI: used for managing crew and pax data (and therefore data related to all persons on board) Data on the lists are sent once a day; Deployment: used for managing voyage data. It is a static data source containing the information about ETA (Estimated Time of Arrival) of all Costa ships; MXP: exposes web services with voyage information of all Costa Crociere ships. MXP has been studied and it could be involved in future projects. PaxManifest Costa file includes the following data: # Data element Description 1 SHIP Code of the ship 2 SubjectID ID of the subject in SAPI 3 TTGPaxID TTG code of passenger 4 Surname surname of the person 5 Second Surname second surname of the person 6 Name name of the person 7 Booking N Booking number 8 Type type of person: crew/ passenger/group/staff Page 38

39 9 Cabin cabin number 10 Costa Card Costa card number 11 Master Cruise master cruise TTG code 12 Birth Date date of birth 13 Place of Birth place of birth 14 Age Range infant/child/adult 15 Commercial Condition TTG commercial condition 16 Sex gender 17 Need of Assistance yes/no flag 18 Nationality nationality code 19 Language language code 20 Document Type type of identity document 21 Document Number number of identity document 22 Emission Place place of emission of identity document 23 Emission Date date of emission of identity document 24 Expiration Date expiration date of identity document 25 Embark Port port of embarkation 26 Embark Date date of embarkation 27 Disembark Port port od disembarkation 28 Disembark Date date of disembarkation 29 contact of the person 30 Address address of the person 31 City city of residence of the person 32 Country country of the person 33 Postal Code postal code 34 State State where person lives 35 District district where person lives 36 Phone contact phone number Page 39

40 37 Mobile contact mobile number 38 Fax contact fax number 39 Emergency First Name First name of the contact in case of emergency 40 Emergency Last Name Last name of the contact in case of emergency 41 Emergency Phone Number Phone number of the contact in case of emergency 42 Visitors Flag yes/no if the person is a visitor 43 ID ID of the crew/staff 44 Position Onboard position on board of crew/staff 45 State state on board 46 Bkg Off Code Booking office code 47 Categ cabin category 48 Dining With dining field as in TTG 49 Staff Cabin number of cabin SAPI system is interfaced with CCSA - Costa Crociere System Adaptor through FTP communication. For each port call of each ship, Costa sends to CSSA a PaxManifest file in CSV format (Comma separated Values), containing the list of all persons on board. CSSA, according to defined rules and voyage information, generate structured Messages of Pax and Crew list of the ships. Such Messages are then converted, according to defined rules, to be useful information in compliance with receiver System Standard data. Messages to be sent are available in PUSH pattern; nevertheless the system is already supporting also PULL pattern. In push pattern the source delivers the message contacting the target system via a Web Service provided by the receiver or via an AS2/ebMS gateway (see figure 26). PUSH Pattern is the common way used by a private stakeholder to send a document to the Italian NSW. Page 40

41 Figure 26 Push pattern Meanwhile in the PULL pattern the source notifies the target about the information availability. The target contacts the source through a web service published by sender or via HTTP/HTML user interface. The Receiver, to download the message, can contact the Sender on an event basis (when it receives a notification) or on a schedule basis (with its own defined period). Figure 27 - Pull Pattern Page 41

42 Information managed in CCSA are embedded inside the Message Handling System named MSM (Marine Standard Message). MSM message is designed for transmission via SOAP Web Services and is composed by: Header: Is used to store technical and Web Service security info if used (e.g. Certificates, Digital Signature); Body: It contains the basic information needed for Data exchange in XML format, e.g. Sender, Receiver, Document Type, etc.; Attachment: The attachment is an e-files (e-edi proprietary, e-message, e-document). Figure 28 - The CCSA Message Handling System (Marine Standard Messagge as in AnNA Project) It is to underline that the Messages management through attachments, allow to manage all kind of documents in any format. Thus it will be feasible to transmit simultaneously files in proprietary format or standard, as well as added files such as Certificates, documents copies, etc. 3.4 CIVITAVECCHIA PILOT The Port of Civitavecchia is strategic for the access to important Italian tourist destinations and important Mediterranean cruise routes. Development works of the wharfs and passenger Page 42

43 welcoming structures have granted the possibility of recording a significant increase in cruise liners, going from 50 ships in 1996 to 600 in Civitavecchia aims at increasing the tourist flow with the target of becoming the most important cruise port in the Mediterranean. In 2013 the port of Civitavecchia maintained the national cruise leadership with 2,6 millions of tourists in transit at the seaport, with 6% increase respect previous year MAIN PURPOSE The aim of the Pilot is to demonstrate the benefits for the port's clients (i.e. the industry/shipowners/agents, etc.), and the benefits for national and local authorities about receiving up-to-date PAX and CREW lists and in particular by: 1. Providing proper tools to shipping companies in order to set up an automate communication between shipowner and PCS; 2. Adapt those tools to directly communicate with NMSW (PMIS). In this pilot the information are made available to PCS logistic operators (RCT and Port Mobility) in order to improve their services ACTORS INVOLVED MIT, RINA, AP Civitavecchia, IB, Roma Cruise Terminal, Port Mobility, Costa Crociere BUSINESS AND TECHNICAL GOALS Allow AP Civitavecchia to receive up-to-date information. Improve the communication between actors involved. Allow port services providers to be updated on persons disembarking at Civitavecchia port. Improve the logistic processes within the port. Increase efficiency of services provider and enhance port community competitiveness. Processes optimization. Page 43

44 Data exchange simplification by obtaining real time data PILOT SCENARIO As part of the transition towards a paperless management of all documents and considering the increase of the number of passengers on cruise ships, the following scenario was defined: as per fig.29 a target scenario whereas PAX and CREW lists are sent to the PCS by NMSW; as per fig.30 the scenario adopted to the pilot scope. The target scenario represents the objective to be achieved at national level possibly after the conclusion of B2MOS project. The pilot scenario is, instead, the picture of the actually implemented. Figure 29 Target scenario Page 44

45 Figure 30 Pilot scenario The outcome of this protoptyping is to test both processes and technical tools able to allow shipping companies to be fully compliant with next implementation steps towards the target scenario. In accordance to the target scenario, in the pilot pax and crew lists are transmitted from CCSA to PMI (Port Message Integrator) in M2M (Machine To Machine) by using an agreed XML format. The information is then made available by PMI to the PCS of Civitavecchia named GIADA via Web Services. This PCS is a hub application, that centralizes data generated by the various users, relates them to each other, for creating the necessary added value that allows sharing and allocating of resources in port. For other data of interest the manual entry on GUI exposed by GIADA will remain available. Main features of GIADA System are listed below: Page 45

46 Shipping Companies manage ships season scheduling, departures and arrivals of liners; Shipping Agencies send berth requests for cruise and cargo ships; Coast Guard is assisted in the issue of service orders, accordingly to a daily set schedule programmed on the basis of the port calls; Port Authority receives information about movements 1 and port operations, with details about number of passengers, amount of cargo and work shifts, allowing several activities as billing of port fees, producing statistics and monitoring port operations; Port Authority s Environmental Division can monitor the weather and environmental data from the environmental monitoring network; Port community operators can access to the on line services to know the position of ships in real-time. In this pilot Costa Crociere sends to PMI information regarding ETA and ETD in the port of Civitavecchia, as well as pax and crew list. PMI is an interoperability layer that collects these messages and exposes them to GIADA through a web service. Costa Crociere sends information about ship voyage, berth and passengers within 7 days before the ship arrival forecast. its database. GIADA, at fixed intervals, calls the PMI services to retrieve information and update data in GIADA processes data and makes it available to companies that provide logistic, safety and security services, improving organization and work and resources planning. The information are made available in two ways: By exposing services (Web services) to third party systems; Via specific interactive functionalities to its own users. 1 In GIADA System a movement stands as any operation of a ship within the Civitavecchia harbour (arrival, departure and movements within the port). Page 46

47 In the port of Civitavecchia, the port services related to passengers are operated by two companies: a) Roma Cruise Terminal (RCT); Roma Cruise Terminal (RCT) is a provider of cruise services in port of Civitavecchia. It performs all activities related to the management of services connected to the traffic of passengers on cruise ships. The information systems of the company are focused on the management of secure access to restricted areas, for implement the security plan approved by the competent authority. Currently RCT's systems manage the data necessary and useful for the issuing of permits for temporary or permanent access to individuals (visitors, hostesses, tour guides etc) who require access to restricted areas managed by RCT, according to port regulations approved by the Harbour. Receiving data in electronic format allows to have the information in advance and to create a more efficient and effective planning of embarking/disembarking operations. RCT receives data from GIADA PCS both berth and passengers data, in M2M (Machine To Machine) by using an agreed XML format. (For GIADA Web services technical specifications see Annex 2). b) Port Mobility (PM) The Port Mobility company (PM) manages mobility services within the port of Civitavecchia. In order to properly plan the services offered to its members, it would take great benefit from the availability of data on passengers of cruise ships in transit in the port. The information about berths and passengers are made available by GIADA to PM by specific functionalities through interactive access to the system. Page 47

48 3.4.5 PROTOTYPE ADAPTATIONS IN GIADA PCS Currently, information related to berths of cruise ships is submitted by shipping agencies in PCS GIADA. These data concerns information about ship voyage, berth and number of embarking / disembarking or transit passengers. Before the pilot, the passenger list was not present in the database of PCS GIADA. The list was provided by by electronic unstructured documents (pdf) directly to RCT mainly for security purposes. This procedure had the inconvenience that information could not be automatically processed and therefore it had to be managed manually. The pilot demonstrated the feasibility of receiving the passenger lists in a structured format. Prior to implementation Post implementation RCT RCT A batch process, at constant intervals, calls the services provided by PMI to retrieve the list of expected berths of the cruise ships in the port of Civitavecchia and data that characterize them. The ships will be recognized by the following data: IMO Number; Call Sign if it is not recognized by the IMO Number. The recognition of the ship will imply the creation of a berth request in GIADA database with information related to berth and scheduled date of arrival. If the best request is already available in GIADA, this will be updated. If the ship is unknown in GIADA database, the process creates a new instance of the vessel using data provided by the PMI service; these data may be completed afterwards by a user with the required rights. Page 48

49 Figure 31- Information before and after GIADA implementation The movements can be displayed and processed by a specific form that has been extended allowing the user to access the details of cargo. A form that allows the user to display the list of passengers and the detailed information of each passenger - as name, address, date of birth, etc. has been added. Note: the personal data about passengers will be exposed in accordance to the current privacy legislation. GIADA makes available to RCT, and to any other interested party, a service that provides the list of Costa Crociere ships arriving and departing from the port of Civitavecchia. Each berth is identified by a unique recognition code. GIADA also provides an additional service that makes available the list of passengers of each Costa Crociere ship, identified by a recognition code. The GIADA services technical specifications are given in ANNEX. Page 49

50 Changed features / additions in GIADA. Each berth generates a movement in GIADA. The movements can be listed by the appropriate functionality (Figure 32). Figure 32 List of movements Page 50

51 Using a filter it is possible to search the movements of Costa Crociere cruise ships (Figure 33). (Figure 34). Figure 33 - Movements related to cruise ships of Costa Cruises Selecting the movement it is possible to access the specific section showing berth data Figure 34 Berth data Page 51

52 From berth data details it is possible to select passengers data including: general and personal Passengers data; aggregated data such as: o total number of passengers; o number of passegengers on board; o number of crew members; o number of passegengers grouped by nationality; o number of passegengers that need assistance; o number of passegengers grouped by age range. It is also possible to export the passenger list or a sub-selection of it in different formats (txt, csv, xls, xml). Figure 35 Passenger s details Page 52

53 Figure 36 Aggregated data 3.5 BARCELONA PILOT A further implementation of the pilot has been done with the involvement of Port of Barcelona. The port of Barcelona, has a 2000-year history and great contemporary commercial importance as one of Europe's ports in the Mediterranean, as well as Catalonia's largest port. In 2014 the Port of Barcelona recorded a total of 2,364,292 cruise passenger movements. Cruise activity in Barcelona generates total turnover of 796 million and contributes million a year to Catalonia's Gross Domestic Product (GDP), according to the results of a study commissioned by the Port of Barcelona. The objective, in this pilot, is to exploit a scenario whereas an automatic submission of ship formalities to the NMSW is already on going. Currently, in Spain, ports are acting as gateway to the NMSW (Puertos del Estado); Ship Formalities have to be submitted to PCS systems which are linked to the National System. In Barcelona Port the PCS PortIC is transmitting SF to the NMSW, in Page 53

54 the required format (i.e. Puerto del Estado standard). In particular for crew and pax lists, Spain Administration defined a specific implementation of PROTECT S EDIFACT PAXLST MAIN PURPOSE The aim of the Pilot is to demonstrate the benefits for the port and its clients (i.e. the industry/shipowners/agents, etc.), and the benefits for national and local authorities about receiving up-to-date PAX and CREW lists ACTORS INVOLVED Costa Crociere, IB, Barcelona Port Authority, Barcelona PCS PortIC BUSINESS AND TECHNICAL GOALS Allow Costa Crociere to send pax and crew lists to Barcelona Port Authority in M2M way. Improve the communication between actors involved. Processes optimization. Data exchange simplification by obtaining real time data PILOT SCENARIO In this scenario, Costa Crociere, by using its dedicated system environment CCSA, is able to collect information about persons on board and create PAX and CREW lists to be sent in M2M communication to the PCS responsible for the current port of call (PortIC for Barcelona). Differently from the previous pilot, PAX and CREW lists are Ship Formalities and they must be provided in the context of a port call. Moreover in this case, the information sent is an official declaration of the ship owner and has a legal validity. Page 54

55 Figure 37 Pilot description, Port of Barcelona On March 2015 Puertos del Estado published the Spanish MIG (Message Implementation Guidelines) that must be implemented by Port Authorities in order to communicate with the Spanish Maritime Single Window. In particular, for crew and passengers lists, a specific implementation of the PAXLST in EDIFACT format has been defined. The information sent by CCSA already satisfies the requirements of Puertos del Estado s MIG, in terms of format, code lists and information content. A test has been successfully done by sending a Crew list to the Port of Barcelona in the context of a simulated port of call. The connection between Costa Crociere system and PortIC system has been done via FTP. An acknowledge message is returned from the Port Authority to the sender confirming the correct reception of the message; in case of errors, a notification is sent. The pilot demonstrates the possibility to provide Ship Formalities in M2M mode to Barcelona Port Authority through the PCS. This feature can be easily extended to all Spanish ports Page 55

56 by properly configuring CCSA. Moreover the pilot demonstrates a facilitation for the shipowner calling an European port able to automatically provide required data in the required format. 3.6 PROTOTYPING, PILOTS AND IMPLEMENTATION After the conclusion of the analysis, the prototyping (including the assessment of the systems and processes involved) occurred from April 2014 to March After this period the pilot phase started and it has been closed in October During this period until the middle of July 2015 some problems were encountered and new adjustments were provided in the application. MIT: The following companies have participated in the pilots phase under the supervision of RINA Civitavecchia Port Authority Roma Cruise Terminal Roma Port Mobility IB Costa crociere Barcelona Port Authority PortIC The problems encountered during the pilot with port of Civitavecchia are as follows: 1) Connection issues between PMI and GIADA; 2) Communication issues between Costa Crociere system and PMI due to the size of passenger list file. The following improvements actions were made during the pilot phase with port of Civitavecchia: 1) Firewall settings have been changed; Page 56

57 2) Enabled MTOM features to web service. The problems encountered during the pilot with port of Barcelona are as follows: 1) Sender ID must be the vessel agent country+id and the receiver ID must be the Port Authority of Barcelona s ID; 2) In the UNH segment must be sent the unique reference per message; 3) Vessel agent ID must be informed in the NAD+CV segment; 4) Some passenger names exceed 35 chars; 5) The format of the port call number must be RFF+ATZ format: PPPPPYYYYCCCCC (P=port s locode, Y=year, C=port call number); 6) The BGM segment is too long; 7) No consignee code in the UNH segment is reported; 8) Problem with file uploading in PortIC. The following improvements actions were made during the pilot phase with port of Barcelona: 1) Modified Sender ID generation 2) message reference included in the UNH segment 3) Vessel agent ID reported in NAD+CV segment 4) Passenger names truncated to 35 chars 5) Modified port call number format 6) BGM segment truncated to 35 chars 7) Added consignee code in the UNH segment 8) Switched to FTP active mode All the problems encountered have been successfully resolved and there are not open issues. Page 57

58 3.7 ANNEXES ANNEX PMI TECHNICAL SPECIFICATIONS ANNEX GIADA WEB SERVICE SPECIFICATIONS Page 58

59 4 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN TINO AND INTEREUROPA SYSTEM PARTNER(S) RESPONSIBLE FOR THIS REPORT: LUKA KOPER, PORT AND LOGISTIC SYSTEM, D.D. 4.1 LEGAL CONTEXT National laws and decrees transposing Directive 2010/65 to national regulation. Dates when these regultaions entered in force. The Directive 2010/65 was transposed to the Slovenain legal order with the Decree on reporting formalities for ships in year 2012 (Official Gazette of the RS nr. 69/12). 4.2 FORMER AND CURRENT COMMUNICATION SCHEMES Former (prior to implementation of Directive 2010/65) and new (post implementation) communication schemes between shipping agencies, PCS, national single window, Customs, Merchant Marine and other authorities. A study developed by the Maritime Administration of the Republic of Slovenia (Krovna študija za opredelitev izvedbe vzpostavitve enotnega okna za pomorska promet v RS, IPMIT, 2013) in the framework of the Action AnNA (Advanced National Network for Administrations) has analysed the existing communication schemes regarding announcement of vessel formalities as reported below, where since the publication of the study some developments have occurred regarding the submission of the vessel and cargo manifest to Customs administration ELM.pdf Page 59

60 Formalities at arrival: Table 2 - Formalities at arrival (before implementation) Formality Description of the formality Way of acquisition of information Entry summary declaration for customs Carrier or its representative lodges the entry summary declaration to customs authority for all the cargo that enters the EU customs area. Data are basis to perform the risk analysis. In case of transport in the Mediterranean information shall be sent to customs authorities at least two hours before reaching the first port in the EU customs area. The Entry summary declaration is lodged electronically in the system ICS of the customs authority HAZMAT notification Carrier transporting dangerous cargo shall send the requested information to the Maritime Administration when leaving the port of loading or immediately when the port of destination is known. Data acquisition takes place through the web form of the SI SSN system. 72-hours pre-arrival notification to the Maritime Administration Carrier shall inform the Maritime Administration about arrival of vessel on which an expanded expection should be Data acquisition takes place through the web form of the SI SSN system. Page 60

61 performed at least 72 hours before the arrival 24-hours pre-arrival notification to the Maritime Administration Announcement of vessel arrival to Maritime Administration shall be done at least 24 hours before arrival or whenever possible. Data acquisition takes place through the web form of the SI SSN system. Arrival notification to the Maritime Administration Carrier fills information about vessel, journey, cargo (separately for normal and dangerous cargo). Attachments include among others FAL forms, declaration of healt, ISPS announcement. The notification must be given 24 hours before arrival or at least when the vessel leaves the former port in case the trip lasts less than 24 hours or as soon as the data are available in case the port of call is not known or in case of changes of the port of call.the notification can be updated till the vessel arrival. After arrival the shipping line can update data on cargo. Data acquisition takes place through the web form of the SI SSN system. It is possible to import data on cargo from xml files. FAL forms and cerfificates acquired in a non structured form (attachments). Some information forwarded to Police and Luka Koper. Customs and Police have reading rights in the SI SSN system. Arrival notification to the Police border inspection of Carrier shall provide information from FAL forms Forms FAL5,6, stowaway list sent through SI SSN to police Page 61

62 people 5,6, the stowaway list, if necessary visa numbers and cruising plans. At latest at vessel arrival the shipping line shall denounce all passengers without a valid document for border crossing. in non-structured form. All the other information sent directly to Police. Arrival notification to Luka Koper Shipping agent announces vessel arrival few weeks before vessel arrival, requires the call number, the entry disposition for cargo announcement, the work order and FAL 6 in case of passenger vessels. Port Facility Security Officer needs the ISPS announcement, the declaration of health, crew list and passenger list as well as the list of people without a valid document to cross border. Luka Koper INPO needs the waste form. Information sent through various applications to TinO. A connection between Si SSN and TinO tested during MOS4MOS Action for preannouncements, although present legal obstacles for implementation. Declaration of health and ISPS announcement sent from SI SSN to addresses of the Port Facility Security Officer, which is Luka Koper employee. Form 6 sent by shipping agent to address at Luka Koper. Information for the Health inspectorate Maritime Administration examines the declaration of health. In case the declaration is expired, the Maritime Administration informs the In case a vessel is coming from an infected area or in case of presence of illnesses or deaths on board, telephonic communication between Page 62

63 shipping agent who lodges the request for a new declaration by the Health inspectorate of the RS. Maritime Administration and Health inspectorate takes place. Vessel and Cargo manifest for Customs The vessel manifest is submitted by the vessel s agent, while the cargo manifest by cargo agents. The cargo manifest and the vessel manifest can be submitted electronically in the system ELM. Arrival notification to the Custom administration The notification of arrival contains information necessary to identify the lodged entry summary declaration related to cargo present on the vessel Information sent electronically to the ICS system (IE347). Information for the Statistical office of the RS Maritime Administration is preparing statistical data about port traffic for the needs of the Statistical office of the Republic of Slovenia on a monthly basis. Data available in Si SSN. Formalities at departure: Table 3 Formalities at departure Formality Description of the formality Way of acquisition of information Page 63

64 Vessel manifest For cargo leaving the customs territory of the EU the risk analysis must be done. When the cargo is not included in the customs declaration, the exit summary declaration must be lodged. The carrier announces that cargo will be loaded onto the vessel by submitting the exit vessel manifest. The vessel exit manifest is paper based. Departure notification to the Maritime Administration Carrier (shipmaster) has to announce vessel departure at least one hour before departure. Structure of data is similar to the arrival, where the content is related to vessel departure. Data acquisition is made through web forms of the SI SSN system. The possibility to import xml files is assured. FAL Forms and certificates are submitted as attachment (non structured form). Customs and police have reading rights in SI SSN. Border control of people Border control of people takes place in case of cruising vessel that is bound for non member states. The carrier has to notify changes in the list of crew or passengers. In practice changes are notified through FAL5 and FAL6. FAL5 and FAL6 are sent as pdf or Excel files (attachments) through SI SSN. There is in place currently no automatic notification to the Police. Page 64

65 After the implementation of the NEO system in Slovenia, the communication of the vessel formalities shall follow the sheme indicated below in the table. Formalities at arrival: Table 4 - Formalities at arrival (after implementation) Formality Description of formality Way of acquisition of information Entry summary declaration Carrier or its representative lodge the entry summary declaration to customs authority for all the cargo that enters the EU customs area. Data are basis to perform the risk analysis. In case of transport in the Mediterranean information shall be sent to customs authorities at least two hours before reaching the first port in the EU customs area. The Entry summary declaration is lodged electronically in the system ICS of the customs authority HAZMAT notification Carrier transporting dangerous cargo shall send the requested information to the Maritime Administration when leaving the port of loading or immediately when the port of destination is known. Data acquisition will take place through NEO. Relevant data will be used in the system SI SSN and forwarded to the Port Facility Security Officer and to the Police for certain dangerous cargo (groups 1 and 7). Page 65

66 72-hours pre-arrival notification to the Maritime Administration Carrier shall inform the Maritime Administration about arrival of vessel on which an expanded expection should be performed at least 72 hours before the arrival Data acquisition will take place through NEO. Relevant data will be used in SI SSN and forwarded to Luka Koper. Arrival notification to the Maritime Administration Carrier fills information about vessel, journey, cargo, including FAL forms, declaration of healt, ISPS announcement and some other documents that doesn t derive from the Decree on formalities for vessels as well as vessel certificates.. The notification must be given 24 hours before arrival or at least when the vessel leaves the former port in case the trip lasts less than 24 hours or as soon as the data are available in case the port of call is not known or in case of changes of the port of call. The notification can be updated till the vessel arrival. After arrival the shipping line can update data on cargo. Data acquisition will take place through NEO in a structural form for the majority of data. Such data will be available to Maritime Administration (system SI SSN), Police (emisk), customs (ELM) and Luka Koper (TinO). Customs and Police will have reading rights in the system SI SSN. Arrival notification to the Carrier shall provide Data will be acquired in NEO Page 66

67 Police border inspection of people information from FAL forms 5, 6, the stowaway list, if necessary visa numbers and cruising plans. At latest at vessel arrival the shipping line shall denounce all passengers without a valid document for border crossing. and forwarded to the Police s emisk system. Arrival notification to Luka Koper Shipping agent announces vessel arrival few weeks before vessel arrival, requires the call number, the entry disposition for cargo announcement, the work order and FAL 6 in case of passenger vessels. Port Facility Security Officer needs the ISPS announcement, the declaration of health, crew list and passenger list as well as the list of people without a valid document to cross border. Luka Koper INPO needs the waste form. All data with the exception of personal data will be acquired through NEO and forwarded to TINO. The Port Facility Security Officer will be granted reading rights in the system SI SSN (crew list, passenger list). Information for the Health inspectorate Maritime Administration examines the declaration of health. In case the declaration is expired, the Maritime The Health inspectorate will have insight in the Si SSN. No data exchange is foreseen. Page 67

68 Administration informs the shipping agent who lodges the request for a new declaration by the Health inspectorate of the RS. Vessel and Cargo manifest for Customs The vessel manifest is submitted by the vessel s agent, while the cargo manifest by cargo agents. The cargo manifest and the vessel manifest can be submitted electronically in the system ELM. Arrival notification to the Custom administration The notification of arrival contains information necessary to identify the Information sent electronically to the ICS system (IE347). lodged entry summary declaration related to cargo present on the vessel Information sent electronically to the ICS system (IE347). Information for the Statistical office of the RS Maritime Administration is preparing statistical data about port traffic for the needs of the Statistical office of the Republic of Slovenia on a monthly basis. Data available in Si SSN. Formalities at departure: Page 68

69 Table 5 Formalities at departure (after implementation) Formality Description of formality Way of acquisition of information Vessel manifest For cargo leaving the customs territory of the EU the risk analysis must be done. When the cargo is not included in the customs declaration, the exit summary declaration must be lodged. The carrier announces that cargo will be loaded onto the vessel by submitting the exit vessel manifest. The vessel exit manifest is paper based. Departure notification to the Maritime Administration Carrier (shipmaster) has to announce vessel departure at least one hour before departure. Structure of data is similar to the arrival, where the content is related to vessel departure. Data acquisition will be made through NEO in a structural form for the majority of data. Data will be sent to Maritime Administration (system SI SSN), police, (emisk), customs and Luka Koper (TinO). Border control of people Border control of people takes place in case of cruising vessel that is bound for non member states. The carrier has to notify changes in the list of crew or passengers. In practice changes are notified through FAL5 and FAL6. Data will be acquired by NEO and sent to Police s system emisk. Page 69

70 The system NEO, which is under development by the Maritime Administration of the Republic of Slovenia, is co-financed by the TEN-T through the AnNA project. NEO will act as the national single window and will be put beside the existing SI SSN system, which is run by the Maritime Administration. The major news in comparison to the current situation regards the request to send structured data and not just attachments, since only structured data can be further sent to other machines and elaborated automatically. Due to opposition of shipping agents about the obligation of sending structured messages, the compromise solutions consists in the availability of Excel templates that can be filled up by shipping agents and uploaded to NEO. NEO will be receiving information from carriers or for them shipping agents, storing and forwarding information to relevant institutions such as Police, customs and Luka Koper. Nevertheless Entry summary declaration, Arrival notification to customs authorites and vessel and cargo manifest will still be sent directly to systems of customs authorities, bypassing NEO. Since the Health inspectorate doesn t dispose of any system to support overview and arhiving of declarations of health, those will be available in the SI SSN for the use of the Health inspectorate. 4.3 PROTOTYPE ADAPTATIONS Through B2MOS, Luka Koper continued the work started already under the umbrella of MOS4MOS and that aimed at connecting TinO with the system of the Maritime Administration to be able to receive vessel announcement from such system and therefore to avoit double entrances of (almost) same data from shipping agents. The solution prototyped under MOS4MOS couldn t be implemented due to technical (need to harmonize code lists, need to gather further information of procedures and limitations of both the systems) and legal limitations. Nevertheless with the development of the new system NEO, which is prototyped under the AnNA project, the plan is to connect Luka Koper with NEO and not with the SI SSN system as planned within MOS4MOS. Page 70

71 Although the report should sum up work carried out by Luka Koper in the framework of the Action, it is to explain that the development done in the framework of B2MOS shall be considered together with the work carried out by the Maritime Administration of the Republic of Slovenia in the framework of AnNA. In fact the NEO prototype that is being developed by the Maritime Administration has incorporated conditions and needs set by Luka Koper s prototype. For example the GUI created as the AnNA result, containes also data fields that are needed for planning of vessel arrivals that is done by Luka Koper. Similarly business rules concerning time conditions of announcements have to be done are adapted also to Luka Koper needs. The setting up of the prototype consisted in the following schanges to the existing systems (TinO and entry point): - Setting up the necessary logic on the entry point to support communication with the system NEO - Setting up a web service on the entry point to support communication with the system NEO - Upgrade of the system TinO to support following functions: o Reception and processing of messages regarding vessels announcements and preparation of responses to the announcements o Reception and processing of messages for code lists (automatic messages about changes in the code lists, generated by NEO) o Business logic concerning vessel announcement rejection o Extension of vessels code list with the sign MMSI and call sign o Translation table for vessel type o Extension and supplementation of shipping lines code list with the IMO sign o Extension of attributes to improve the process (ex. ATA and data about departure) o Extension of the announcement with data about dangerous cargo in arrival and departure o All further necessary upgrades related to the new workflow, in particular in the module NPID, which is devoted to vessel announcements. Intereuropa on the other hand created a link to the NSW prototype. Page 71

72 The main functionalities of the Luka Koper s prototype consists in the ability of TinO (and the entry point) of receiving data from the national single window (NEO) regarding vessel announcements/visits and of retourning messages, which could be confirmations or rejections in case information is innacurate or missing. Intereuropa s (Interagent, shipping agency) link to NSW prototype has the following functionalities: - Enable shipping agency to report according to the new Directive for the A3 reporting formality - dangerous goods and adjusting to the technical specification, requested by National Maritime Administration in Slovenia (new XML sheme for Dangerous Goods). o Receiving the dangerous goods data from the Carrier. o Converting dangerous goods data to specified technical sheme, requested by NMA in Slovenia. o Sending and uploading dangerous data to the national maritime single window. o Dealing with mistakes and response messages. Screenshots of new prototypes Figure 38 - Screenshot of the entry page of NEO (source: Maritime Administration of the RS) Source: Maritime Administration of the RS Page 72

73 Figure 39 - Screenshot of the NEO, including data needed for Luka Koper Source: Maritime Administration of the RS Figure 40 - Screenshot of the NEO, details on dangerous cargo Source: Maritime Administration of the RS Page 73

74 Figure 41- screenshot of the TinO (NPID module) that includes the NEO number Source: Maritime Administration of the RS Page 74

75 Figure 42 Screenshot of the TinO (NPID module) with vessel details Intereuropa s prototype enables to generate data for dangerous goods in XML sheme, as requested by the National Maritime Administration, as shown below and uploading it to the NSW. Page 75

76 Figure 43 - Prototype in Intereuropa macros in background Figure 44 - Prototype in Intereuropa resoult generated Page 76

77 Flow of communication for each new prototype To represent the procedure of vessel announcement, we are reporting the description of the whole communication flow and not just the part that concerns Luka Koper and NEO: 1. The reporting entity prepares a message to be sent to NEO. NEO accepts the message and verifies the XML scheme and the content. Based on the verification it sends the feedback as RECEIPT. 2. NEO, after receiving and sending the RECEIPT, disposes of available data in NEO for NEO users. Only certain data is sent in a message MSW2G to Luka Koper. 3. Luka Koper accepts the message MSW2G, verifies the message and retourns a feedback as RECEIPT. 4. In the meantime the NEO content administrator verifies the original message received by the reporting entity and sends back the message RESPONSE. The vessel visit can be either confirmed or rejected. 5. The reporting entity receives the message and retourns the RECEIPT message. 6. In the meantime the Luka Koper administrator verifies the received message and decides about the visit (confirmation or rejection) and retourns the RESPONSE message to NEO. 7. After receiving the RESPONSE from LUKA KOPER NEO sends a RECEIPT to Luka Koper. Afterwards it send the Luka Koper s decision regarding the vessel visit to the reporting entity as RESPONSE. 8. As feedback to the RESPONSE the reporting entity retourns a RECEIPT. Page 77

78 Souce: Maritime Administration of the RS Page 78

79 Set of data needed by TinO: Najava ladje obvezna vnosna polja neobvezna vnosna polja šifranti/ obrazložitve komentarji podatki o ladji podatki o najavi 1 Šifra ladje/4 mestna alfanumerična koda bo moral sistem sistem dodeliti 2 IMO nimajo vse ladje IMO 3 Ime ladje tekst kot ga najavi agent 4 Dožina (m) 5 Širina ladje (m) trenutno ni obvezen podatek, bo pa postal 6 BRT (t) 7 Ugrez (m) 8 Ugrez premec (m) 9 Ugrez krma (m) Tip ladje (BC, CT, FI, GC, OT, PA, RF, RO, TA, TU) BC - Ladje za sipke - razsute tovore CT - Ladje za kontejnerje FI - ribiške ladje GC - Ladje za generalni tovor OT - Ostale - namenske ladje PA - Potniške ladje RF - Ladje za frigo tovore RO - Ladje za vozila TA - Ladje za vse tekoče tovore Kaj bodo kratice razumljive, če bodo najave na skupnem obrazcu oz če bodo v prihodnje najavljali principali? 10 TU - Vlačilci 11 Agent iz šifranta - glej tretji list 12 Ladjar iz šifranta - glej drugi list 13 Država mednarodni šifrant 14 Nosilnost (t) 15 Število grotel št. ladijskih skladišč 16 Leto izdelave 17 opis dvigal prosti tekst aktivna ladja (kljukica) bo moral sistem sistem samodejno preverjati obvezna vnosna polja 1 Vrsta najave (n,p,s) 2 Storitev (b, n, r, o) 3 Datum in ura prihoda Organizacijska enota (EET, TTT, GT, TL, TS, TZ, KT RRO, TA TST, TGL, SIL, POT, PET, OPP) neobvezna vnosna polja n - najava p - potrditev s - storno b -nakladanje in razkladanje n - nakladanje r - razkladanje o - ostalo EET - evropski energetski terminal Kaj bodo kratice razumljive, če bodo najave na TTT - terminal tekočih tovorov skupnem obrazcu oz če bodo v prihodnje najavljali GT - generalni tovori principali? TL - terminal sadje TS - terminal sipki tovori TZ - terminal za živino KT - kontejnerski terminal RRO - ro-ro terminal TA - terminal za avtomobile TST - terminal za sipke tovore TGL - terminal glinica SIL - silos POT - potniški terminal PET - petrol 4 OPP - operativno planiranje 5 Agent iz šifranta - glej tretji list ni nujno, da je enak kot pri odpiranju ladje 6 Agent (co-loaderji)/ KT trenutno se ročno vnašajo podatki na KT 7 Prejemnik: prosti tekst prosti tekst 8 Potovanje (KT) Potovanje prosti tekst 9 Linija (KT) Linija 2MMS 2M SERVIS 10 Tovor prosti tekst 11 Količina (t) IMO/IMDG prosili še za uskladitev glede razpoložljivih 1 EKSPLOZIVI 12 podatkov na URSP 13 Ladjar iz šifranta - glej drugi list lahko tudi drugi kot pri odpiranju 12 Ladja iz šifranta 15 Ugrez lahko drugačen kot pri odpiranju ladje 16 Ugrez premca lahko drugačen kot pri odpiranju ladje 17 Ugrez krme lahko drugačen kot pri odpiranju ladje obvezna vnosna polja neobvezna vnosna polja dplutju ladje Page 79

80 The development in Luka Koper started in May 2015, while testing took place from the 26 th of October 2015 till the 6 th of November The prototype in Intereuropa was built in September 2015, piloted in October-November 2015, panned to be implemented in January PILOTS List of companies that have participated in testing Luka Koper s pilot: Maritime Administration of the Republic of Slovenia, pilot idea, pilot development Ixtlan team d.o.o., pilot idea, pilot development, preparation of test scenarios, testing Luka Koper d.d., pilot idea, pilot development Actual IT d.d., pilot idea, pilot development, preparation of test scenarios, testing List of companies that have participated in testing Intereuropa s pilot: Intereuropa Interagent, shipping agency has participated in tests and pilot. Maritime Administration of the Republic of Slovenia, pilot idea, pilot development Dates for the pilots of the different new prototype applications Date of the pilots for Luka Koper: Date of the pilots for Intereuropa: MAIN PROBLEMS ENCOUNTERED FOR EACH NEW APPLICATION AND SOLUTIONS PROVIDED DURING THE PILOT PERIOD During the pilot phase the main problem was the synchronisation of the code lists. Since every system has its own code list for the same type of data transformation rules and data tables were implemented on both sides. This transformation took a lot of time because of the huge amount of data needed to be synchronised. Harmonization of vessel details data was particulary difficult due to the out dated vessel information in the TinO ship register. Every vessel was hand checked and Page 80

81 manually corrected in the system TinO. Another challenge was loosen business rules for the vessel pre-arrival phase. TinO vessel announcement business process required more data for the first vessel announcement than it was provided by the system NEO. This was fixed by correcting all the rules in the announcement workflow. During the pilot phase NEO also implemented support for data which is needed by the Terminal Operating System of the Port of Koper and not needed for the URSP ( cargo co-loaders and voyage numbers ). We noticed that during the test phase this two data caused problems since TOS rejected NEO messages, because the data provided was not in compliance with the data TOS business rules. 4.6 LIST OF PROBLEMS THAT REMAIN UNSOLVED Since part of NEO still needs to be developed, the prototype can not be implemented yet. Moreover it is expected that after the full implementation of NEO changes will still needed due to unpredicted circumstance. According to information gathered during the Koper demo day (13 th of October 2015), it is to be expected that the public procurement procedures to continue with the development of NEO will start by the end of year Since Luka Koper was not included as as receiver of information from the national single window in the Decree on electronic formalities for vessels, there is no legislative ground for Luka Koper at present to be receiving information from NEO, although right at the time of the preparation of the report an amendment to the Maritime Code is under parliamentary discussion, which in article 65.a) proposes to include the concessionaire as data receiver. For testing purposes the prototype the problem was solved by foreseeing for the shipping agent the possibility to choose if he wants to use NEO to announce data to Luka Koper (instead of announcing the vessel 2 times in 2 different systems). Page 81

82 4.7 ANNEXES Examples of new messages exchanged using the new prototype applications. Message sent from NEO to Luka Koper entry point: <?xml version="1.0"?> <soapenv:envelope xmlns:soapenv=" <soapenv:header/> <soapenv:body> <msg> <MSW2G xmlns:ns2="urn:wco:datamodel:wco_ds:1" xmlns="urn:wco:datamodel:wco:1"> <MetaData> <CommunicationMetaData> <ApplicationReferenceID>neo</ApplicationReferenceID> <TestIndicator> <ns2:indicator>false</ns2:indicator> </TestIndicator> <SequenceNumeric>1.0</SequenceNumeric> </CommunicationMetaData> </MetaData> <MAI> <FunctionCode>9</FunctionCode> <DecSeqNr>1</DecSeqNr> <FunctionalReferenceID>URSP_2015_ </FunctionalReferenceID> <IssueDateTime> <ns2:datetimestring> t </ns2:datetimestring> </IssueDateTime> <TypeCode>MAI</TypeCode> <ArrivalDateTime> <ns2:datetimestring> t </ns2:datetimestring> </ArrivalDateTime> <StayID>SIKOP </StayID> <BorderTransportMeans> <ID> </ID> <IdentificationTypeCode>IMO</IdentificationTypeCode> </BorderTransportMeans> <Itinerary> <ID>SIKOP</ID> </Itinerary> <Declarant> <ID>SI </ID> <IMOID> </IMOID> </Declarant> </MAI> Page 82

83 D.O.O.</Name> <NOA> <TypeCode>NOA</TypeCode> <Agent> <Name>ISS-NAVIGO, POMORSKA AGENCIJA, <ID>SI </ID> <TypeCode>AGN</TypeCode> <Contact> <Name>Ciril Zlobec</Name> </Contact> <Communication> <TypeCode> </TypeCode> </Communication> </Agent> <CallPurpose> <NameCode>16</NameCode> </CallPurpose> <BorderTransportMeans> <Name>DUKE I</Name> <TypeCode>DHT</TypeCode> <RegistrationNationalityCode>PA</RegistrationNationalityCode> <GrossWeightMeasure>24997</GrossWeightMeasure> <NetWeightMeasure>10170</NetWeightMeasure> <CargoDescription>Brief textual description of cargo.</cargodescription> <DPGListIndicator> <ns2:indicatorstring>n</ns2:indicatorstring> </DPGListIndicator> <WidthMeasure unitcode="mtr">31</widthmeasure> <DraughtLevelAftMeasure unitcode="mtr">8</draughtlevelaftmeasure> <DraughtLevelForMeasure unitcode="mtr">8.1</draughtlevelformeasure> <CargoWeightMeasure>0</CargoWeightMeasure> </BorderTransportMeans> <Itinerary> <ID>SIKOP</ID> <SequenceNumeric>0</SequenceNumeric> <ArrivalDateTime> <ns2:datetimestring> t </ns2:datetimestring> </ArrivalDateTime> <DepartureDateTime> <ns2:datetimestring> t </ns2:datetimestring> </DepartureDateTime> <VoyageDescription>NEO to TinO connection test.</voyagedescription> Page 83

84 <Line>ATUR</Line> <AnchorageIndicator> <ns2:indicatorstring>n</ns2:indicatorstring> </AnchorageIndicator> <OrganisationUnit>KT</OrganisationUnit> </Itinerary> <Itinerary> <ID>HRRJK</ID> <SequenceNumeric>-1</SequenceNumeric> <DepartureDateTime> <ns2:datetimestring> t </ns2:datetimestring> </DepartureDateTime> </Itinerary> <Itinerary> <ID>ITVCE</ID> <SequenceNumeric>1</SequenceNumeric> <ArrivalDateTime> <ns2:datetimestring> t </ns2:datetimestring> </ArrivalDateTime> </Itinerary> <Master/> <TotalPersons> <TypeCode>C</TypeCode> <QuantityQuantity>0</QuantityQuantity> </TotalPersons> <TotalPersons> <TypeCode>P</TypeCode> <QuantityQuantity>0</QuantityQuantity> </TotalPersons> <TotalPersons> <TypeCode>S</TypeCode> <QuantityQuantity>0</QuantityQuantity> </TotalPersons> </NOA> </MSW2G> </msg> </soapenv:body> </soapenv:envelope> Messege sent by Luka Koper entry point to NEO: <soap:envelope xmlns:soap=" <soap:body> <reply> <XMLMSGREPLY xmlns=" <Header> <MsgID>125554</MsgID> Page 84

85 </Header> <Status>2</Status> </XMLMSGREPLY> </reply> </soap:body> </soap:envelope> Message sent from NEO to Luka Koper entry point / case of dangerous goods: <MSW2G xmlns="urn:wco:datamodel:wco:1" xmlns:ds="urn:wco:datamodel:wco_ds:1" xmlns:ns2="urn:wco:datamodel:wco_ds:1" xmlns:xsi=" xsi:schemalocation="urn:wco:datamodel:wco:1"> <MetaData> <CommunicationMetaData> <ApplicationReferenceID>neo</ApplicationReferenceID> <TestIndicator> <ns2:indicator>false</ns2:indicator> </TestIndicator> <SequenceNumeric>1.0</SequenceNumeric> </CommunicationMetaData> </MetaData> <MAI> <FunctionCode>4</FunctionCode> <DecSeqNr>2</DecSeqNr> <FunctionalReferenceID>URSP_2015_ </FunctionalReferenceID> <IssueDateTime> <ns2:datetimestring> t </ns2:datetimestring> </IssueDateTime> <TypeCode>MAI</TypeCode> <ArrivalDateTime> <ns2:datetimestring> t </ns2:datetimestring> </ArrivalDateTime> <StayID>SIKOP </StayID> <BorderTransportMeans> <ID> </ID> <IdentificationTypeCode>IMO</IdentificationTypeCode> </BorderTransportMeans> <Itinerary> <ID>SIKOP</ID> </Itinerary> <Declarant> <ID>SI </ID> <IMOID> </IMOID> </Declarant> <PreviousDocument> <ID>URSP_2015_ </ID> </PreviousDocument> </MAI> Page 85

86 <NOA> <TypeCode>NOA</TypeCode> <Agent> <Name>ISS-NAVIGO, POMORSKA AGENCIJA, D.O.O.</Name> <ID>SI </ID> <TypeCode>AGN</TypeCode> <Contact> <Name>Ciril Zlobec</Name> </Contact> <Communication> <TypeCode> </TypeCode> </Communication> </Agent> <CallPurpose> <NameCode>16</NameCode> </CallPurpose> <BorderTransportMeans> <Name>DUKE I</Name> <TypeCode>DHT</TypeCode> <RegistrationNationalityCode>PA</RegistrationNationalityCode> <GrossWeightMeasure>24997</GrossWeightMeasure> <NetWeightMeasure>10170</NetWeightMeasure> <CargoDescription>Brief textual description of cargo.</cargodescription> <DPGListIndicator> <ns2:indicatorstring>n</ns2:indicatorstring> </DPGListIndicator> <WidthMeasure unitcode="mtr">31</widthmeasure> <DraughtLevelAftMeasure unitcode="mtr">8</draughtlevelaftmeasure> <DraughtLevelForMeasure unitcode="mtr">8.1</draughtlevelformeasure> <CargoWeightMeasure>3.373</CargoWeightMeasure> </BorderTransportMeans> <Itinerary> <ID>SIKOP</ID> <SequenceNumeric>0</SequenceNumeric> <ArrivalDateTime> <ns2:datetimestring> t </ns2:datetimestring> </ArrivalDateTime> <DepartureDateTime> <ns2:datetimestring> t </ns2:datetimestring> </DepartureDateTime> <VoyageDescription>NEO to TinO connection test.</voyagedescription> <Line>ATUR</Line> <AnchorageIndicator> <ns2:indicatorstring>n</ns2:indicatorstring> </AnchorageIndicator> <OrganisationUnit>KT</OrganisationUnit> Page 86

87 Page 87 </Itinerary> <Itinerary> <ID>HRRJK</ID> <SequenceNumeric>-1</SequenceNumeric> <DepartureDateTime> <ns2:datetimestring> t </ns2:datetimestring> </DepartureDateTime> </Itinerary> <Itinerary> <ID>ITVCE</ID> <SequenceNumeric>1</SequenceNumeric> <ArrivalDateTime> <ns2:datetimestring> t </ns2:datetimestring> </ArrivalDateTime> </Itinerary> <Master/> <TotalPersons> <TypeCode>C</TypeCode> <QuantityQuantity>0</QuantityQuantity> </TotalPersons> <TotalPersons> <TypeCode>P</TypeCode> <QuantityQuantity>0</QuantityQuantity> </TotalPersons> <TotalPersons> <TypeCode>S</TypeCode> <QuantityQuantity>0</QuantityQuantity> </TotalPersons> </NOA> <HZA> <TypeCode>HZA</TypeCode> <DPGContact> <GivenName>Franco</GivenName> <FamilyName>Franchi</FamilyName> <Communication> <ID> </ID> <TypeCode>PHONE</TypeCode> </Communication> </DPGContact> <BorderTransportMeans> <Bunker> <SequenceNumeric>1</SequenceNumeric> <Commodity> <CargoDescription>Crude oil bunker.</cargodescription> <Classification> <Name>CRUDE OIL</Name> <IdentificationTypeCode>MARPOL1</IdentificationTypeCode> <MarpolGroup>OILS</MarpolGroup> </Classification>

88 </Commodity> <GoodsMeasure> <NetNetWeightMeasure>1500</NetNetWeightMeasure> <NetNetWeightMeasureUnit>KGM</NetNetWeightMeasureUnit> </GoodsMeasure> <GoodsLocation> <Name> </Name> </GoodsLocation> </Bunker> </BorderTransportMeans> <Consignment> <SequenceNumeric>1</SequenceNumeric> <ConsignmentItem> <SequenceNumeric>1</SequenceNumeric> <Commodity> <CargoDescription>Some cargo description</cargodescription> <Classification> <Name>TERTIARY BUTANOL</Name> <UnCode>1122</UnCode> <IdentificationTypeCode>IMDG</IdentificationTypeCode> </Classification> </Commodity> <GoodsLocation> <Name> </Name> </GoodsLocation> <GoodsMeasure> <GrossMassMeasure unitcode="kgm">1520</grossmassmeasure> <GrossMassMeasureUnit>KGM</GrossMassMeasureUnit> <NetNetWeightMeasure unitcode="kgm">1370</netnetweightmeasure> <NetNetWeightMeasureUnit>KGM</NetNetWeightMeasureUnit> </GoodsMeasure> <Packaging> <QuantityQuantity>17</QuantityQuantity> <TypeCode>WD</TypeCode> </Packaging> <TransportEquipment> <ID>ABCD </ID> </TransportEquipment> </ConsignmentItem> <ConsignmentItem> <SequenceNumeric>2</SequenceNumeric> <Commodity> <CargoDescription>some other cargo description</cargodescription> <Classification> <Name>VINYL METHYL ETHER INHIBITED</Name> <UnCode>1087</UnCode> Page 88

89 Page 89 <IdentificationTypeCode>IMDG</IdentificationTypeCode> </Classification> </Commodity> <GoodsLocation> <Name> </Name> </GoodsLocation> <GoodsMeasure> <GrossMassMeasure unitcode="kgm">2217</grossmassmeasure> <GrossMassMeasureUnit>KGM</GrossMassMeasureUnit> <NetNetWeightMeasure unitcode="kgm">2003</netnetweightmeasure> <NetNetWeightMeasureUnit>KGM</NetNetWeightMeasureUnit> </GoodsMeasure> <Packaging> <QuantityQuantity>10</QuantityQuantity> <TypeCode>BG</TypeCode> </Packaging> <TransportEquipment> <ID>ABCD </ID> </TransportEquipment> </ConsignmentItem> <LoadingLocation> <ID>HRRJK</ID> </LoadingLocation> <UnloadingLocation> <ID>SIKOP</ID> </UnloadingLocation> <TransportContractDocument> <ID>BL </ID> </TransportContractDocument> <AdditionalInformation>Some additional information</additionalinformation> </Consignment> </HZA> <HZD> <TypeCode>HZD</TypeCode> <DPGContact> <GivenName>Cicio</GivenName> <FamilyName>Ingrassia</FamilyName> <Communication> <ID> </ID> <TypeCode>PHONE</TypeCode> </Communication> </DPGContact> <Consignment> <SequenceNumeric>1</SequenceNumeric> <ConsignmentItem> <SequenceNumeric>1</SequenceNumeric> <Commodity> <CargoDescription>Description.</CargoDescription>

90 <Classification> <Name>BUTANE</Name> <UnCode>1011</UnCode> <IdentificationTypeCode>IMDG</IdentificationTypeCode> </Classification> </Commodity> <GoodsLocation> <Name> </Name> </GoodsLocation> <GoodsMeasure> <GrossMassMeasure unitcode="kgm">3222</grossmassmeasure> <GrossMassMeasureUnit>KGM</GrossMassMeasureUnit> <NetNetWeightMeasure unitcode="kgm">3120</netnetweightmeasure> <NetNetWeightMeasureUnit>KGM</NetNetWeightMeasureUnit> </GoodsMeasure> <Packaging> <QuantityQuantity>7</QuantityQuantity> <TypeCode>GB</TypeCode> </Packaging> <TransportEquipment> <ID>ABCD </ID> </TransportEquipment> </ConsignmentItem> <LoadingLocation> <ID>SIKOP</ID> </LoadingLocation> <UnloadingLocation> <ID>ITVCE</ID> </UnloadingLocation> <TransportContractDocument> <ID>BL AB2</ID> </TransportContractDocument> </Consignment> </HZD> </MSW2G> Intereuropa s example of the XML message for dangerous goods: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <ShipImoCargoData xmlns=' xmlns:xsi=' <ShipVoyageData> <ShipData ShipName="JOGELA" IMONumber=" " ></ShipData> <VoyageData Port="SIKOP" ETA=" T09:36:00" ></VoyageData> </ShipVoyageData> <Containers> <ContainerData Number="DVRU " PositionOnShip="271282" LoadPort="CNSHA" UnloadPort="SIKOP" ContainerType="33" TransportDocumentID="BL1" > Page 90

91 <Cargo> <CargoData ImoContact=" " UNNumber="3082" MassKg="19360" PackageType="QA" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, LIQUID, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="111284" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" TransportDocumentID="BLNUMBER1" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg=" " OriginCountry="USBAL" FinalDestCountry="HUBUD" PackageType="QA" NoOfPackages="1" AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="ECMU " PositionOnShip="171182" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3262" MassKg="2320" AdditionalInformation="CORROSIVE SOLID, BASIC, INORGANIC, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="INKU " PositionOnShip="20986" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="1950" MassKg="248" AdditionalInformation="AEROSOLS (maximum 1 litre)" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="100682" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" TransportDocumentID="BL2" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="4908" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> <CargoData ImoContact=" " UNNumber="3268" MassKg="4844.3" AdditionalInformation="AIR BAG MODULES, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="111082" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="32" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg=" " AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="ECMU " PositionOnShip="90982" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="31" > <Cargo> <CargoData ImoContact=" " UNNumber="1405" MassKg="24060" AdditionalInformation="CALCIUM SILICIDE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="SEGU " PositionOnShip="90984" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="2117" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TRLU " PositionOnShip="260884" LoadPort="CNCWN" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3496" MassKg="238.9" AdditionalInformation="BATTERIES, NICKEL-METAL HYDRIDE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="251284" LoadPort="CNSHA" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="1224" MassKg="9405" AdditionalInformation="KETONES, LIQUID, N.O.S." ></CargoData> </Cargo> Page 91

92 </ContainerData> <ContainerData Number="TRLU " PositionOnShip="111282" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg=" " AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="111084" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg=" " AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TGHU " PositionOnShip="171184" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3496" MassKg="814.2" AdditionalInformation="BATTERIES, NICKEL-METAL HYDRIDE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TCKU " PositionOnShip="100484" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="7614" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="GESU " PositionOnShip="100686" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="3633.7" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> <CargoData ImoContact=" " UNNumber="3268" MassKg="5079.4" AdditionalInformation="AIR BAG MODULES, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="251282" LoadPort="CNSHA" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3077" MassKg="25500" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="ECMU " PositionOnShip="90782" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" TransportDocumentID="BL3" > <Cargo> <CargoData ImoContact=" " UNNumber="1405" MassKg="24060" AdditionalInformation="CALCIUM SILICIDE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="91284" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg="15463" PackageType="QA" NoOfPackages="1" AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="SEGU " PositionOnShip="100482" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="2366.3" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> <CargoData ImoContact=" " UNNumber="3268" MassKg="6393.7" AdditionalInformation="AIR BAG MODULES, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TCLU " PositionOnShip="91282" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> Page 92

93 <CargoData ImoContact=" " UNNumber="2794" MassKg=" " AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TEMU " PositionOnShip="100486" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="8226" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="ECMU " PositionOnShip="271284" LoadPort="CNSHA" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3082" MassKg="8226" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, LIQUID, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="100684" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3268" MassKg="2822.1" AdditionalInformation="AIR BAG INFLATORS, PYROTECHNIC" ></CargoData> <CargoData ImoContact=" " UNNumber="3268" MassKg="6050.8" AdditionalInformation="AIR BAG MODULES, PYROTECHNIC" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="GESU " PositionOnShip="20984" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="1044" MassKg="271.7" AdditionalInformation="FIRE EXTINGUISHERS, with compressed or liquefied gas" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TCKU " PositionOnShip="91082" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg="16896" AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="ECMU " PositionOnShip="90784" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="1405" MassKg="24060" AdditionalInformation="CALCIUM SILICIDE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TEMU " PositionOnShip="31084" LoadPort="CNSHA" UnloadPort="ITTRS" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3296" MassKg="3985" AdditionalInformation="HEPTAFLUOROPROPANE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TGHU " PositionOnShip="260410" LoadPort="KRPUS" UnloadPort="HRRJK" ContainerType="34" TransportDocumentID="BL4" > <Cargo> <CargoData ImoContact=" " UNNumber="3077" MassKg="12096" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3077" MassKg="1008" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3077" MassKg="8870.4" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3077" MassKg="1814.4" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="CMAU " PositionOnShip="250404" LoadPort="KRPUS" UnloadPort="HRRJK" ContainerType="33" > Page 93

94 <Cargo> <CargoData ImoContact=" " UNNumber="2923" MassKg="13598" AdditionalInformation="CORROSIVE SOLID, TOXIC, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="GESU " PositionOnShip="270404" LoadPort="KRPUS" UnloadPort="HRRJK" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3337" MassKg="10875" AdditionalInformation="REFRIGERANT GAS R 404A" ></CargoData> <CargoData ImoContact=" " UNNumber="3340" MassKg="1490" AdditionalInformation="REFRIGERANT GAS R 407C" ></CargoData> <CargoData ImoContact=" " UNNumber="3163" MassKg="1504" AdditionalInformation="LIQUEFIED GAS, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3159" MassKg="3340" AdditionalInformation="1,1,1,2-TETRAFLUOROETHANE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="GESU " PositionOnShip="20984" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="1044" MassKg="271.7" AdditionalInformation="FIRE EXTINGUISHERS, with compressed or liquefied gas" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TCKU " PositionOnShip="91082" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="2794" MassKg="16896" AdditionalInformation="BATTERIES, WET, FILLED WITH ACID, electric storage" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="ECMU " PositionOnShip="90784" LoadPort="KRPUS" UnloadPort="SIKOP" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="1405" MassKg="24060" AdditionalInformation="CALCIUM SILICIDE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TEMU " PositionOnShip="31084" LoadPort="CNSHA" UnloadPort="ITTRS" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3296" MassKg="3985" AdditionalInformation="HEPTAFLUOROPROPANE" ></CargoData> </Cargo> </ContainerData> <ContainerData Number="TGHU " PositionOnShip="260410" LoadPort="KRPUS" UnloadPort="HRRJK" ContainerType="34" > <Cargo> <CargoData ImoContact=" " UNNumber="3077" MassKg="12096" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3077" MassKg="1008" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3077" MassKg="8870.4" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> <CargoData ImoContact=" " UNNumber="3077" MassKg="1814.4" AdditionalInformation="ENVIRONMENTALLY HAZARDOUS SUBSTANCE, SOLID, N.O.S." ></CargoData> </Cargo> </ContainerData> <ContainerData Number="GESU " PositionOnShip="270404" LoadPort="KRPUS" UnloadPort="HRRJK" ContainerType="33" > <Cargo> <CargoData ImoContact=" " UNNumber="3337" MassKg="10875" AdditionalInformation="REFRIGERANT GAS R 404A" ></CargoData> <CargoData ImoContact=" " UNNumber="3340" MassKg="1490" AdditionalInformation="REFRIGERANT GAS R 407C" ></CargoData> <CargoData ImoContact=" " UNNumber="3163" MassKg="1504" AdditionalInformation="LIQUEFIED GAS, N.O.S." ></CargoData> Page 94

95 <CargoData ImoContact=" " UNNumber="3159" MassKg="3340" AdditionalInformation="1,1,1,2-TETRAFLUOROETHANE" ></CargoData> </Cargo> </ContainerData> </Containers> </ShipImoCargoData> Page 95

96 5 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PCS OF HAMBURG PARTNER(S) RESPONSIBLE FOR THIS REPORT: MCP Pilots in Activity 3 Directive 2010/65/EU 5.1 LEGAL CONTEXT Directive 2010/65/EU has not been transposed into UK legislation, the Department for Transport (DfT) have maintained that existing UK legislation and Statutory Instruments will facilitate transition of the reporting requirements into the National Maritime Single Window (NMSW) as currently projected. However, the DfT is reviewing and working with Other Government Agencies to co-ordinate the actual requirements from a legal perspective and this may therefore initiate amendments to current guidance notes. 5.2 UK FORMER AND CURRENT COMMUNICATION SCHEMES FAL Forms 2 - Almost 100% of manifests are now received electronically into Destin8, predominantly using the UN/EDIFACT CUSCAR message and which therefore fulfils the data requirements of the FAL2 form. FAL Form 7 - For imports, exports and remaining on board (ROB) cargo, the CUSCAR (Customs Manifest), COPARN (Container Pre-Arrival Notification), IFTDGN (International Freight Transport Dangerous Goods Notification) UN/EDIFACT messages include segment groups for Dangerous & Polluting Goods (DPG) declarations. This data is supplied by the carrier in the respective message thus enabling all DPG carried on a vessel to be reported to the relevant authority as appropriate. The DPG information is stored on Destin8 for use by the port s safety department in cases of incident or emergency. The DPG data, together with details of the carrying vessel/voyage, is also available for use by the Maritime Coastguard Agency the UK national authority responsible for maritime safety and notifications - and where necessary, are sent to the MCA CERS2 system, fulfilling the requirements of the Vessel Traffic Monitoring Directive (Directive 2002/59/EC, as amended by Directive 2009/17/EC & Directive 2011/15/EU). FAL Forms 1, 3, 4, 5, 6 and the Health Declaration - currently sent direct to the HMRC National Clearance Hub. ISPS Declarations currently sent direct to the Port Security Officer at the port of arrival as part of the Port Arrival Notification documentary processes regulated by the DfT. Page 96

97 Waste Notifications the Destin8 system provides functionality fulfilling the requirements of the Port Waste Directive (Directive 2000/59/EC). Non-Destin8 locations are using local and pre-dominantly paper based notification processes. 5.3 UK PROTOTYPE ADAPTATIONS AND PILOTS Due to extensive delays in establishing a preferred approach to the reporting requirements, the lead agency in the UK the DfT have yet to fully define and implement a national solution (or systems) in the UK. Any actual prototype development or pilots have therefore not been possible as part of the B2MoS project. In the short to medium term, the UK implementation of the Directive also known as the FAL or Reporting Facilities Directive will be facilitated through an updated interface to the existing Maritime & Coastguard Agency CERS2 system and a new National Maritime Single Window (NMSW) provided by the DfT. The MCA have only very recently selected a new supplier and aim to the have the new system (CERS3) up and running by the end of the year. It is anticipated CERS3 will then handle the existing vessel movement and dangerous goods reporting in addition to the new extended vessel waste and ISPS declarations. Once the new interface specifications have been agreed, existing Destin8 functionality will be enhanced to accommodate the new reporting requirements. It is expected that the ISPS and Waste declaration will be based on Excel Spreadsheets formats underpinned by XML and that the current PortPlus message will continue to be used for DPG and Vessel Movement reporting. The DfT is also hoping to launch the new prototype Window (NMSW) in the next few weeks on a pilot basis and alongside existing reporting methods. They have indicated that there will not be any duplication with CERS (either the current version or CERS3), and the data sent* via NMSW will only be accessible by Government for the time being, although this may change when the NMSW comes fully online (and required to be used) next year. The DfT will be issuing guidance explaining what needs to be reported* and a training programme is being developed. Page 97

98 *DfT are not intending to provide a system to system interface to the NMSW initially, however, submission of FAL forms 1, 3, 4, 5 and 6 plus the Health Declaration will be based on a range of Excel and Word templates being uploaded directly by the responsible party to the NMSW. 6 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PCS OF BREMEN AND BREMERHAVEN PARTNER(S) RESPONSIBLE FOR THIS REPORT: DBH LOGISTICS IT AG 6.1 LEGAL CONTEXT Directive 2010/65/EU of The European Parliament and of The Council Of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States and repealing directive 2002/6/EC, transposed and published by the EU Member States before 19 May 2012, establishes that ship reporting formalities in the EU need to be simplified and harmonised without prejudice to the nature and content of the information required and without introducing any additional reporting requirements for ships. Member States shall accept the fulfilment of reporting formalities in electronic format and their transmission via a single window as soon as possible and in any case no later than 1 June Directive 2010/65/EU deals with how the information procedures can be simplified and harmonised and how the information could be gathered more effectively. Its implementation will require the creation of national single windows and new information communication procedures that will affect the functioning of current port management systems, port community systems and business systems (mainly those of shipowners, sea carriers and shipping agencies). In Germany manly the Internal Waters (Entering Requirements) Ordinance 3 is reflection reporting formalities for the arrival departure of German ports. In addition to that, most of the ports in the different federal states have their own laws and directives. In Bremen and Bremerhaven are these for example 3 Ordinance on the requirements for vessels entering the internal waters of the Federal Republic of Germany from sea areas seaward of the delimitation of the German territorial sea and for vessels leaving such internal waters. Page 98

99 Bremische Hafenordnung HafenO (Port Regulation of Bremen) Bremischen Hafensicherheitsgesetz BremHaSiG (Port Security Law of Bremen) Abfallauffangseinrichtungsgesetz - BremHSLG (Law for Waste Collection) In Bremen especially the port regulation has been changed on 5 th of May 2015 in regard to the Directive 2010/65/EU and the new reporting process in Bremen and Bremerhaven. Figure 45 Example reporting formalities in Bremen 6.2 FORMER AND CURRENT COMMUNICATION SCHEMES Before describing the individual amendments and implementation steps with regard to the PCS of Bremen and Bremerhaven integration to the National Single Window, below the main systems are briefly described in which essential software technical changes in functionality due to the integration of the PCS into the NSW have taken place. Page 99

100 System: Table 6 Overview DACOM DACOM (DANGEROUS CARGO ONLINE MANAGEMENT) Primary used by: Port Authority / Coast Guard / Fire Department Main Functions: Administration of dangerous goods information Data exchange to the ZMGS and Port Authority Description: The DACOM system is operated of dbh on behalf the port authorities of the Bremen ports. In this system all messages regarding handled dangerous goods are collected, stored and managed. There where primary three different possibilities for communication Data collection via web Interface DACOM Sending EDIFACT IFTDGN message by interface via EDI-Communication Platform Transmit Dangerous Goods (DG) information in Port Order BHT the extract and communication of DG information was done by EDI-Communication Platform It s also used as information system both for security authorities and announces data to the Central German Reporting System for Dangerous Cargo on Sea and Shipping (ZMGS) by interface and from ZMGS to the European Maritime Safety Agency (EMSA) also via interface. System: Table 7 Overview SIS SIS (SHIP INFORMATION SYSTEM) Primary used by: Ship Owner / Agents / Freight Forwarders / Ship Reporting Service Main Functions: Administration of ship master data Overview for ship voyages Ship declaration Description: The completion of goods stream in the port requires also information about arrivals and departures of ships. With the ship voyage data acquisition the ship-referred data are made available, which are relevant with the respective shipping company representatives for the charge reservation by the Freight Forwarders. Besides are these ship travel data among other things for the port order preparation necessarily. This information s are the basis for all ship-referred procedures within the systems involved. Beyond these tasks a ship declaration must be made with the port authorities for each ship, which starts the port. Also this functionality is a component of SIS. Page 100

101 System: Table 8 Overview EDI Communication System EDI COMMUNICATION SYSTEM Primary used by: Direct or indirect by all stakeholders they integrated in the data exchange in the environment of the port community system in Bremen, Bremerhaven or Wilhelmshaven. Main Functions: Data conversion Data distribution Communication control Data exchange... Description: The EDI communication system is a dbh internal product, with which data e.g. can be converted, restructured, archived and distributed. The system is within the environment of dbh as data turntable in use and based on the Convertersystem OSIS what is original developed by LS GmbH Syke. Integrated is the complete data exchange between the internal modules in the environment of the Port Community System as well as the tied up systems of further, at the Supply Chain participating stakeholders like e.g. customers and authorities. System: BREPOS 3 Primary used by: Port Authority / Fire Department Main Functions: Traffic management of ships in Bremen and Bremerhaven Administration of dangerous goods information in combination with DACOM Description: BREPOS 3 is a system for the traffic management of ships in Bremen and Bremerhaven. Administered are among other things information s regarding like berth and demurrages, arrivals and departures of ships as well as information s for lock allocations. In connection with DACOM it serves beyond that for the administration of dangerous goods with the port authority. BREPOS 3 had a graphic data preparation it makes possible to illustrate a port map, in which ships as well as appropriate containers with dangerous goods are represented. Via interfaces the necessary data from the Port Community System are conveyed. The system is operated by the coworkers of the port authority and developed and hosted by dbh Logistics IT AG. Page 101

102 6.2.1 FORMER COMMUNICATION SCHEME The following graphic illustrates the former communication flow before the adaptions in the PCS of Bremen and Bremerhaven was done: Figure 46 Former Communication Scheme The data exchange between the PCS and the ZMGS referred exclusively to information on dangerous goods in UN/EDIFACT format IFTDGN. Furthermore, extracts of the data exchange between the SIS and the corresponding affiliated systems referred to the General Declaration (FAL-Form 1) as well as the Waste Notification. Both messages were transmitted in bilateral internal data formats. Page 102

103 6.2.2 CURRENT COMMUNICATION SCHEME The following graphic illustrates the current flow of communication where essentially the data exchange below is no longer included: General Declaration between SIS and BREPOS Waste Disposal between SIS and BREPOS Dangerous Goods message between DACOM and ZMGS in a direct way The new added functionalities as well as a detailed description of the changes are described in the following section, Prototype Adaptions in PCS of Bremen and Bremerhaven. Figure 47 Current Communication Scheme Page 103

104 6.3 PROTOTYPE ADAPTATIONS IN PCS OF BREMEN AND BREMERHAVEN Due to the integration of the PCS into the NSW (National Single Window), changes in the PCS-modules SIS, DACOM, BREPOS and EDI-Communication Platform were necessary. Furthermore, a new application ANSW (Advanced National Single Window) as a module of PCS was developed. This module is comparable to a Port Single Window. About that module, comprehensive functionalities concerning to reporting formalities will be transacted and the communication to the NSW which is hosted by Central Command for Maritime Emergencies (Havariekommando, located in Cuxhaven, Germany) will be transacted MODIFICATIONS ON EXISTING PCS MODULES In PCS module SIS the existing functionality of reporting the General Declaration (FAL- Form 1) was switched of as the data collection and reporting of this information actually was integrated as a new function in ANSW. Furthermore the function Waste Disposal was also switched off and integrated in ANSW. A Visit-ID as new unique identifier for every port visit in Germany will be assigned by the NSW. SIS has been enhanced so that now a Visit-ID can be automatically requested and adopt by the system. SIS serves since these changes primary as a sailing list and provides these operational data to other systems like BHT. The module DACOM has no more functionality to capture dangerous goods messages pursuant to Directive 2010/65/EU on a dialog of the application. In addition, the direct data exchange to the ZMGS has been transferred to the ANSW module. In PCS module BREPOS the "Post Inbox Function" where the General Declaration has been checked first before final acceptance by the Port Authority, was turned off and replaced by a new development. So far, the Post Inbox was served by the SIS module via an interface. This functionality will now be taken over by ANSW. Furthermore BREPOS now is able to process the Visit-ID's. Within the EDI Communication Platform many existing communication gateways and modes of communication as UN/EDIFACT formats primarily in regard to SIS, BREPOS and DACOM has been changed. A more detailed description is provided in section New Communication Structures. Page 104

105 6.3.2 NEW COMMUNICATION STRUCTURES REPORTING CLASSES The data exchange of the PCS with the German NSW takes place in data format XML. The XML data fields have been defined by the technical working group within the framework of 28 different reporting classes and was been implemented based on XSD schemas. By using different reporting classes information has to be collected only for one time and can be (re)used in different reports again. So the requirement from Directive 2010/65/EU in reference to unique information collection is achieved. The reporting classes are listed in Table 4 Reporting Classes. Table 9 Reporting Classes (uncontrolled sequence) Visit: Visit-ID SEC: Sea Security Note Transit: Transit-ID ATA: Approved Time of Arrival NAME: Name of Captain NOA-NOD: Notification of Arrival/Departure ATD: Actual Date of Departure TIEFA: Draught on Arrival TEIFD: Draught on Departure STAT: Vessel Details POBA: Person on Board Arrival POBD: Person on Board - Departure BKRA: Bunker Arrival BKRD: Bunker Departure WAS: Waste Message CREW: Crew List PAS: Passenger List BPOL: Reporting Border Patrol PRE72: 72 Hours Pre Announcement LADG: Cargo INFO: Shipping Area HAZA: Hazard on Arrival SERV: Service HAZD: Hazard on Departure Page 105

106 MDH: Declaration of Health TOWA: Towage on Arrival TOWD: Towage on Departure Reporting Party Whether, and which reporting class has already been transmitted successfully by the reporting party to the NSW, can be seen on a status monitor in the module ANSW. Figure 48 Status monitor ANSW (in extracts) Another view to the status monitor is available for different Authorities e.g. the Port Authority of Bremen or Bremerhaven. In opposition to the view of the reporting parties which is basically able to have access to his own Visit-ID s, the Port Authority of Bremen or Bremerhaven is able to see information s of all Visit-ID s from those vessels, which arrive or depart the Port of Bremen or Bremerhaven. Page 106

107 The following graphic illustrates exemplary which different reporting classes (means information) will be required at different times by various authorities. All information will be recorded only once and transmitted in regard to the relevant message like General Declaration or Dangerous Goods Notification. The respective message classes can be transmitted immediately after data collection separately, or they can be collected and send to the NSW in a summarized form. Figure 49 Different Reporting-Classes for different Authorities NEW DATA FORMATS Existing information formats like UN/EDIFACT message IFTDGN for Dangerous Goods Message or WASDIS for the Waste-Notification was adapted to the new XML structures of the reporting classes so that it s possible to convert incoming UN/EDIFACT messages to the new XML Page 107

108 format. Outgoing messages, like status acknowledgements for the customers, will be converted also from the ANSW XML format to UN/EDIFACT. For communication on the technical level both internal (for example between ANSW and BREPOS) and external (for example between ANSW and NSW) different Web-Services have been developed. The graph in figure 30 shows exemplarily and in extracts the syntax of the XML format for the reporting class Dangerous Goods Message at port departure. An example of a XML message with different reporting classes is attached in appendix 2. This xml file contains the following reporting classes (names in this file have been adjusted retrospectively for privacy): Reporting Party NOA_NOD SEC POBA POBD NAME TIEFA TIEFD BKRA BKRD STAT INFO MDH WAS BEPOL Page 108

109 Figure 50 Example Reporting Class description xls (HAZD) Extract Page 109

110 The following graph shows in extract how the defined schema in the table of.xls in regard to the reporting class HAZD was implemented in a XSD format, so that a correct mapping based on other data formats like UN/EDIFACT is possible. Figure 51 Example Reporting Class description xsd (HAZD) - Extract Page 110

111 DATA FLOW DIAGRAMM S To support the realization on a technical level, data flow diagrams of the main functionalities was developed. However, those diagrams are exclusively in German. An English version was not created due to internal usage for development only. Figure 52 Example Data Flow Diagram Dangerous Goods Page 111

112 COMMUNICATION FLOW Referring the communication flow there are two basically ways which are mainly different in dependence whether a receiving Authority of a message is regional or federal. In case of data exchange with regional Authorities, the PCS-Module ANSW is generally responsible to send the message to the Authority directly after receiving an acknowledgement from the NSW. Figure 53 Communication Flow Regional Authorities Page 112

113 In case of data exchange with federal Authorities, the message will send directly from the NSW to the Authority after receiving it from the ANSW. Figure 54 Communication Flow Federal Authorities NEW DEVELOPPED FUNCTIONALITIES IN ANSW (NEW PCS MODULE) GENERAL Within workshops held by German technical and operational working groups, specifications and procedures were developed which was obligatory for the communication of German PCS with the NSW. These requirements made it necessary to develop a new module for data collection, data processing and data communication with the NSW within the existing PCS. The new Page 113

114 developed module (ANSW) is connected to the NSW via a for Germany uniform defined interface and mainly includes the following main types of Report, which cover the different functionalities in terms of Reporting Formalities. More information regarding the reporting classes is located in section New Communication Structures". The module ANSW is available on both ways, via a Graphical User Web Interface as well as a data interface for automatically data exchange for our customers. The implementation of the module ANSW carried out based on the dbh own A3 Framework which is based on the programming language JAVA. ANSW is a web application and thus available without software installation from any PC with Internet connection and Internet browser functionality. System standards, such as multi-client capability, user administration, user rights and rules, export and print functions, etc. are included in the system and will not be further described in the context of this report. Table 10 Overview Functionalities (Main Reporting Types) in ANSW 1. Arrival Notification 2. Details Arrival/Departure 3. Port Notification 4. Departure Notification 5. Security 6. Preannouncement (72 hour) 7. Border Police 8. Maritime Health Declaration 9. Dangerous Goods Arrival 10. Dangerous Goods Departure 11. Waste management The following chapters do not describe the operation of each function in detail or detailed contents of the different dialogs. For this purpose the user manual in English (which is attached) describes the "how to" of the module ANSW. Rather, the main functions are displayed based on screenshots, and the essential functionalities are explained partly in form of notes. In addition it is mentioned (partly in brackets), which different reporting classes are in regard to the shown dialog Page 114

115 as well as the reference to the main data contents to IMO-FAL-Forms, if this information is available GENERAL OVERVIEW (VISIT ID) The General Overview is primary no dialog for data collection but rather an overview in regard to the current state of the jurney based on the Visit-ID. However, here is also a possibility to cancel the complete Visit/Transit. Figure 55 Functionality General Overview (Extract) The different areas for representation of information are Visit / Transit Information Reporting Status o Status of reporting classes o Access rights o Change history o Messages e.g. violation or hints Page 115

116 ARRIVAL NOTIFICATION The functionality of the Arrival Notification reflect partly the data contents of FAL-Form 1 General Declaration. Figure 56 Functionality Arrival Notification (Extract) The different areas for collection of data are Actual Time of Arrival (ATA) Draught on Arrival (TIEFA) Person on Board Arrival (POBA) Bunker on Arrival (BKRA) Towage on Arrival (TOWA) The reporting party is automatically assigned based on the user information which was given during the user registration at ANSW. This circumstance is the same in every reporting section of the application and therefore not longer mentioned in the following descriptions of the functions. Page 116

117 DETAILS ARRIVAL/DEPARTURE The functionality of the Details Arrival/Departure also reflect primary the data contents of FAL- Form 1 General Declaration. Figure 57 Functionality Details Arrival/Departure (Extract) The different areas for collection of data are Notification of Arrival/Departure (NOA-NOD) Vessel Details (STAT) Page 117

118 PORT NOTIFICATION The functionality of the Port Notification reflect partly the data contents of FAL-Form 2 IMO Cargo Declaration. Figure 58 Functionality Port notification (Extract) The different areas for collection of data are Master (NAME) Info (INFO) Services (SERV) Cargo (LADG) Page 118

119 DEPARTURE NOTIFICATION The functionality of the Departure Notification reflect partly the data contents of FAL- Form 1 General Declaration. This function is nearly equal to the function Arrival Notification. Figure 59 Functionality Departure Notification (Extract) The different areas for collection of data are Actual Time of Departure (ATD) Draught on Departure (TIEFD) Person on Board Departure (POBD) Bunker on Departure (BKRD) Towage on Departure (TOWD) Page 119

120 SECURITY There are two possibilities to report the Security Notification. On one hand you have to insert requested information in every data fields which are shown, and on the other hand you have the possibility to send a simplificated security report. The last mentioned option is only possible, if you already reported a full Security Notification in the last port of call and no information has changed since that time of reporting. The only condition is that this last notification was reported to a port of Germany. Figure 60 Functionality Security (Extract) This function is divided in three different areas / tabs. The different areas for collection of data are Security Notification (shown in hard copy) Last 10 Ports facilities called Ship-to-ship-activities during last 10 Ports facilities called Page 120

121 PRE-ANNOUNCEMENT (72 HOUR) Figure 61 Functionality Preannouncement 72 hour (Extract) In this form, most of the data fields are especially for tanker vessels. This report has to be sending 72 hours before port arrival to the NSW. The final recipient of this report is the Port Authority. The reporting class referring to this functionality is PRE72 H. Page 121

122 BORDER POLICE The functionality of the Border Police Notification reflect partly the data contents of FAL- Form 5 (Crew List) and FAL-Form 6 (Passenger List). Figure 62 Functionality Border Police (Extract) This function is divided in three different areas / tabs. The different areas for collection of data are Border Police (BPOL) - shown in hard copy Crew List (CREW) Passenger List (PAS) MARITIME HEALTH DECLARATION There are two possibilities to report the Maritime Health Declaration. On one hand you have to fill out every data fields which are shown and on the other hand you have the possibility to send a simplificated Health report. The last one is possible if you already reported a full Maritime Health Declaration in the last port of call and no information has changed since that time. The only condition is that this last notification was reported to a port of Germany. Page 122

123 Figure 63 Functionality Maritime Health Declaration (Extract) This function is divided in two different areas / tabs. The different areas for collection of data are Maritime Health Declaration (MDH) Ports of Call of last 30 days DANGEROUS GOODS ARRIVAL The functionality of the Dangerous Goods Arrival reflect primary the data contents of FAL-Form 7 Dangerous Goods Declaration. Page 123

124 Figure 64 Functionality Dangerous Goods Arrival (Extract) This function is divided in five different areas / tabs. The different areas for collection of data are IMDG IBC Items IGC Items IMSBC Items MARPOL Annex 1 Items The reporting Class referring to this functionality is HAZA DANGEROUS GOODS DEPARTURE The functionality of the Dangerous Goods Departure reflect also the data contents of FAL-Form 7 Dangerous Goods Declaration. This function is nearly equal to the function Dangerous Goods Arrival. Page 124

125 As also the both dialogs are nearly the same, in the following screenshot is shown the dialog to record the IMDG information. Figure 65 Functionality Dangerous Goods IMDG-Item This function is divided in five different areas / tabs. The different areas for collection of data are IMDG Items IBC Items IGC Items IMSBC Items MARPOL Annex 1 Items The reporting class referring to this functionality is HAZD WASTE MANAGEMENT Page 125

126 This functionality includes some information which was requested in FAL-Form 1 (General Declaration. The UN/EDIFACT message type was formally WASDIS if this notification wasn t a direct part of FAL-Form 1.. Figure 66 Functionality Waste Management This function is divided in four different areas / tabs. The different areas for collection of data are WAS Waste Waste Oil Waste Garbage Sewage & Cargo The reporting Class referring to this functionality is WAS Page 126

127 ADDITIONAL FUNCTIONS In addition to the described and shown functionalities, in ANSW the following Add-On s are implemented: Authorization grant for Visit-ID It is possible that the vessel operator authorize persons (e.g. customers) to read or edit messages with regard to certain Visit-ID s or as "default template" access. Figure 67 Functionality Configuration Access Rights messaging Within this Add-On it s possible to define one or more account on which will be send information on each switchover of a status. User manual / online help functionality Page 127

128 A user manual is available both in English (annexed) and in the German language as a.pdf version. In addition, an online help from the system directly in both languages in HTML format can be called. Offline-Excel Function All entries that can be made directly on the application ANSW as shown can also be record in a specially developed Excel macro file. This is useful if, for example, at sea currently no Internet connection is available. Once the Internet connection has been rebuilt, an XML file can be created via the "Create Message File" button, which will then be sent via to a predefined address of dbh. The subsequent data import is fully automated, so that within a few seconds all information is provided in ANSW and the reporting classes or messages are ready to be send to the NSW. The individual reports are in different worksheets of the.xlsm file available and represent the respective message classes. Figure 68 - Offline Excel ANSW file (Example Sheet Overview ) Page 128

129 Figure 69 Offline Excel ANSW file (Example Sheet Ship Notification ) 6.4 PROTOTYPING, PILOTS AND IMPLEMENTATIONIN PCS OF BREMEN AND BREMERHAVEN The development phase of the prototype of ANSW starts in September 2014 deferred to the phase of analysis and specification and partly takes place in German working groups. The internal testing phase starts already in parallel to the prototyping phase in March On 27 th of May 2015 the ANSW in Germany the decision was made to connect the ANSW to the NSW and use for the reporting formalities only the defined electronically way. Some problems which was detected during the following pilotphase was bypassed by workarounds, until final solutions was implemented. These workarounds concerned mostly to the communication and data processing within other internal PCS modules. Because these problems are based on deep technical functionalities, they are not more explained in this report. But as the Page 129

130 biggest challenge is to be noted that the whole functionality was override at once and a complete test with the stakeholders for technical reasons do not take place in the ram-up-phase. As one of the primary reasons why to test the pilot with stakeholder was not possible is because the stakeholder systems at this point of time have no interface to the ANSW. Most of the todays customers which are directly connected with the ANSW develop the interfaces after the 27 th of May Furthermore during the pilot phase some add-on s, e.g. Excel-Makro-Tool where developed by dbh. The pilot phase for dbh ends on 1 st of September although there are already first changes and extensions based on national requirements are necessary and have to be realized until the end of year ANNEXES ANNEX: DBH - ANSW_USER_MANUAL_EN.PDF ANNEX 2: DBH - ANSW_XML_EXAMPLE.XML Page 130

131 7 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN PCS OF HAMBURG PARTNER(S) RESPONSIBLE FOR THIS REPORT: DAKOSY DATENKOMMUNIKATIONSSYSTEM AG 7.1 LEGAL CONTEXT The national law in Germany regarding reporting formalities is known under the acronym of AnIBV (Anlaufbedingungsverordnung), or in English, Internal Waters (Entering Requirements) Ordinance. It transposes several international requirements into national law. The necessary adjustments resulting from Directive 2010/65/EU will become effective in the first quarter of In addition to the AnlBV, the federal states with ports have regional and local directives. Since the national law has not yet been adopted, the federal states have released new directives or modified existing ones in order to allow reporting formalities in accordance with the new rules of the National Maritime Single Window ZMS. Electronic reporting to the NSW will only be mandatory as of the moment the law takes effect. With these directives, federal states make reporting to the NSW sufficient according to the law, replacing the former reporting methods. The federal states and their individual directives: Bremen/Bremerhaven o Bremische Hafenordnung HafenO (Port Regulation of Bremen) o Bremischen Hafensicherheitsgesetz BremHaSiG (Port Security Law of Bremen) o Abfallauffangseinrichtungsgesetz - BremHSLG (Law for Waste Collection) The particular regulation HafenO (Port Regulation of Bremen) became effective as of 5 th of May 2015 with regard to the Directive 2010/65/EU and the new reporting process in Bremen and Bremerhaven. Hamburg As of June 1 st 2015, Hamburg has begun to accept electronic reporting via the NSW, while the directive was released a month later in July: Page 131

132 o Verordnung zur Anpassung der Meldeformalitäten für Schiffe vor dem Einlaufen in den Hamburger Hafen from Juli, 21st 2015 With this new directive for amendments of reporting formalities for ships when entering the port of Hamburg, Hamburg expanded/amended all directives with a focus on ships calling at the port. Examples of the amended directives are: Hafenverkehrsordnung Directive Harbour Traffic Gefahrgut- und Brandschutzverordnung Hafen Hamburg Dangerous Goods and Fire protection regulations for Hamburg Hafensicherheits-Durchführungsverordnung Port Security Directive Niedersachen (Lower Saxony) On April 23 rd, 2015, the following two directives were released declaring the electronic reporting to the NSW as sufficient for carriers to fulfil the reporting formalities: o Allgemeinverfügung zur Bestimmung eines Datenverarbeitungssystems für Meldeund Informationspflichten von Seeschiffen beim Ein- und Auslaufen o Zulassung eines elektronischen Übermittelungsweges für die Meldung der Seegesundheitserklärung von Seeschiffen Schleswig-Holstein is a late starter. The directive will be published in October 2015 and will declare as other federal states previously have electronic reporting to the NSW as sufficient to fulfil the reporting obligations. Page 132

133 7.2 FORMER AND CURRENT COMMUNICATION SCHEMES The reporting formalities prior to as well as post implementation of Directive 2010/65/EU - follow the timeline of either a ship s port call or its transit through the Kiel Canal. Figure 70 and use both the commonly used descriptions/names of the forms to be reported and arrange the formalities on a timeline. Figure 71: Reporting formalities when transiting the Kiel Canal Figure 70: Reporting formalities in a German port on a timeline Page 133

134 7.2.1 COMMUNICATION SCHEME PRIOR THE IMPLEMENTATION OF DIRECTIVE 2010/65/EU Taking the Port of Hamburg as an example, the reporting formalities, local and national authorities and the method of delivering forms can be listed as follows: Table 11: Communication schemes in Hamburg prior to the implementation of Directive 2010/65/EU Reporting formalities resulting from legal acts of the Union [Directive 2010/65, Annex A] FAL forms and formalities resulting from international legal instruments [Directive 2010/65, Annex B] Authority Notification for ships arriving in and departing from ports of the Member States FAL 1 General Declaration Border checks on persons FAL 5 Crew List FAL 6 Passenger List HPA Hamburg Port Authority BIS - Behörde für Inneres und Sport Hamburg Ministry of the Interior and Sport, especially the department waterpolice BIS, especially the department waterpolice Reporting Channel, involved systems/platforms EDI or Fax (System PRISE) Paper EXCEL, format Pre Arrival Report Notification of dangerous or polluting goods carried on board FAL 7 Dangerous Goods BIS, especially the department waterpolice EDIFACT (GEGIS) Notification of waste and residues WASTE Declaration BUE- Behörde für Umwelt und Energie Hamburg - Ministry of Urban Development and Environment Word or PDF as attachement Notification of security information Security Report BIS EXCEL, format Pre Arrival Report FAL 3 Ship s Stores Declaration FAL 4 Crew s Effects Declaration Customs 4 Paper Entry summary declaration FAL 2 Cargo Declaration Customs4 EDI Maritime Declaration of Hamburg Port Health Health Center Paper Any relevant national legislation [Directive 2010/65, Annex C] Port State Control Adressat Meldeweg 4 In Germany all communication with Customs were defined as not part of the project Directive 2010/65/EU. Page 134

135 Reporting formalities resulting from legal acts of the Union [Directive 2010/65, Annex A] pre arrival notification (72 hrs before) FAL forms and formalities resulting from international legal instruments [Directive 2010/65, Annex B] Authority BG Verkehr Berufsgenossenschaft Verkehr Hamburg professional association traffic Reporting Channel, involved systems/platforms Paper As described in Table 7 above, prior to Directive 2010/65/EU there existed a mixture of paper, fax, files forwarded via and real EDI: The PRISE system was established in 2013 and monitors the movement of ships. Data may be filed via EDI or via Fax to the FLZ, andflz then enters the data. The so-called Pre Arrival Report is an EXCEL-application developed by DAKOSY which offers supporting functionalities when entering data. The EXCEL-file can be sent via DAKOSY to the relevant authorities, per request DAKOSY can extract the data into XMLformat. The reporting of Dangerous Goods via EDI in Hamburg has been mandatory since All formalities regarding Customs in Germany were excluded from the project of enacting the Directive 2010/65/EU, thus they will not be part of this report COMMUNICATION SCHEME AFTER THE IMPLEMENTATION OF DIRECTIVE 2010/65/EU In Germany, it was decided by the National Steering Committee to expand the NSW for Dangerous Goods to become the new (Maritime) National Single Window. ZMGS (Zentrale Meldestelle für Gefahrgut) became ZMS Zentrale Meldestelle. The responsible department for development and operation is the WSV - Wasser- und Schifffahrtsverwaltung (Administration of Waterways and Shipping). The new communication scheme developed in working groups under the collaboration of representatives of authorities, the industry and the PCSs of Germany is shown in the following graphic: Page 135

136 Figure 72 - Communication scheme with the German NSW (courtesy of WSV) The German NSW offers the reporting parties a web-client for manual data-input or the access via a certified PCS. Data for the authorities is stored in an outbox, allocating one outbox per authority. It is the responsibility of the authorities to empty the outbox, either by establishing an EDI-link on their own or with the help of a licenced provider a PCS REGISTRATION AND SERVICE LEVEL AGREEMENTS In order to creat a safe and secure environment, the WSV has published a Guideline. The guiding principle is high availability and data protection. Therefore a mixture of different measures has been established, i.e.: A user of the web-client (only available for reporting parties) has to register formally. A provider normally a PCS - needs to be licenced. The NSW has established Service Level Agreements to be followed by licenced PCSs. The corresponding forms, concept and other documents have been published on the official webpage For registered users of the web-client this is also the address of their web-client VISIT-/TRANSIT-ID AND SINGLE REGISTER CLASSES As a connecting element for a voyage the so-called VISIT- ID and the Transit-ID have been created. For each call in a port or when transiting the Kiel Canal this registration-number has to be obtained prior to all reporting processes. Page 136

137 In order to comply with the requirement of having to report data only once, the NSW clustered the data into so-called single register classes. The register classes are used to generate multiple forms. Forms such as the medical declaration of health are comprised of several classes. Figure 73 shows the example of one of these register classes. Figure 73: Example for a single register class: STAT Ships details Figure 74: The Single Register Classes of the German National Single Window ZMS In setting up the database and the register classes, ZMS followed the recommendations of the ANNA-Project ( Page 137

138 Consequently the communication scheme for a register class used in various forms is a bit more complex, allowing data filed only once to be used for several use cases/forms: Figure 75: Example of a communication scheme for single register classes (courtesy of WSV) Page 138

139 7.3 PROTOTYPE ADAPTATIONS IN DAKOSY DAKOSY established various working groups with representatives of carriers, agents, software companies of carriers and agents, local authorities and WSV. As a result of these working groups, DAKOSY has designed and realized 3 prototypes (for detailed descriptions see the following subchapters below): edeclaration for Carriers GEGIS edeclaration for Authorities The communication flow is always via DAKOSY to and from the NSW, and in some cases (Dangerous Goods, Sailing List) the local authorities (Waterpolice, Port Authority) will get a copy in advance, to be replaced later by data from the NSW (see Figure 86: edeclaration for Authorities). Figure 76: Communication flow reporting formalities with edeclaration The guiding principles for all prototypes: Respect existing investments / interfaces / routines, meaning as few changes as possible Setup of a safe and secure environment DATA PROTECTION (for instance encryption of data) Page 139

140 7.3.1 EDECLARATION FOR CARRIERS One of the findings of the working groups is that most of messages originate on ship. The whole process demands a close cooperation between office / land and ship. Figure 77: Reporting formalities shared tasks between ship and land Consequently the prototype developed for carriers consists of four modules: Figure 78: edeclaration for carriers the 4 modules Page 140

141 EDI: An EDI-interface allowing carriers to send data via DAKOSY to the NSW. The webdashboard of edeclaration may be used for support and supervisory purposes. On-board solution: An intelligent EXCEL-application modeled on the existing Pre Arrival Report, but now with autofill-assistance and master data like code-lists and more services. The captured data can be extracted in an encrypted XML-file to be sent via satellite to DAKOSY. Figure 79: Screenshot edeclaration module On-board solution Figure 80: 2nd Screenshot edeclaration module On-board edeclaration Page 141

142 edeclaration Web: The edeclaration WebAPP allows carriers/agents to capture data manually as well as to edit data uploaded via EDI or On-board-solution, such offering another component in order to allow the close co-operation between land and ship, between offices of carriers and multiple agents. The captain may send data which needs refinement by the carrier/agent. Figure 81: Screenshot edeclaration module Web - Overview Following the workflow-engine configured by the user, the data received from ship may either be sent by the solution directly to the NSW or can wait for checks and correction by the office of the carrier or agent. Figure 82: Screenshot edeclaration module Web ship details Page 142

143 Communication with authorities is logged automatically,while warning and alert notifications may be configured. Figure 83: Screenshot edeclaration module Web User configuration of alerts Page 143

144 7.3.2 GEGIS MONITORING DANGEROUS CARGO IN HAMBURG Since 1997 the filing of DANGEROUS CARGO information has been mandatory in Hamburg. The established network is large Figure 84: The GEGIS - Network and sophisticated. In order to respect the investments in the system GEGIS - with its existing interfaces for carriers and to the National Single Window for DANGEROUS GOODS ZMGS it was decided to expand GEGIS. Within edeclaration only an index about communication with GEGIS is shown, the communication channel for dangerous goods towards the NSW is still GEGIS. The adaptions are: Process Visit-ID/Transit-ID: The new Identification number became part of both the user-interface in the web and the EDI-interface. In order to assist the carriers in the ID-request-process a routine was installed to check with the NSW when DG-data without ID-number was filed whether a Visit-ID/Transit-ID for the ship s port-call already existed or not. In the latter case an ID is requested automatically by GEGIS. Amendment of interfaces to carriers / agents and NSW: According the published EDI-manuals of the NSW, the existing interfaces to GEGIS (following the standardized IFTDGN message of the PROTECT-group) needed amendments. The message-standard IFTDGN itself consequently needed to be updated. DAKOSY - as member of the PROTECT-group is discussing the amendments within the group; the new version will be published in the web ( Page 144

145 The 1 roof and multiple Slot-Charters -concept: With the implementation of the new regulations it is no longer allowed for multiple carriers to send DG-messages for the Figure 85: The one roof concept of GEGIS same ship. NSW requires consolidated DG-messages for a ship with the ship s owner as the sole sender. GEGIS offers a consolidation-routine for carriers, allowing the various charterers of a ship to still send as they have been accustomed to messages for their part of the cargo. GEGIS will consolidate and send the clustered messages in the name of the roof, i.e. the owner of the ship EDECLARATION FOR AUTHORITIES With edeclaration for authorities DAKOSY has developed a prototype for authorities. Figure 86: edeclaration for Authorities Similar to edeclaration for carriers, the prototype solution offers standardized services: A web-application to view data retrieved by DAKOSY from the relevant outbox of the NSW The single register classes may be consolidated (= parked ), until all register classes for a certain form have been lodged by the reporting parties and / or a final date has been reached. The authority will only receive completed forms. Page 145

146 The communication channel can be chosen by the authority. For instance, during the prototype phase, DAKOSY has developed a PDF (keeping the layout of the former document) to be sent as an -attachement to BUE. The Hamburg Port Health Center requires an XML-message-format, other authorities will use the web-application. 7.4 PILOTS The analysis and design phase ended in November The prototypes were ready for testing starting on April 1 st The launch of the pilots started on May 27, The pilot for the web-application edeclaration for authorities will start in November 2015, with authorities of the final federal state (Schleswig-Holstein) to start accepting electronic reporting then. Regular service is planned to begin at the end of The period of the pilot phase is being used to refine the service and implement value added services for all parties. Some of the amendments stemming from comments of the piloting companies are described below. In addition to the cooperation between users and the project team, there have been regular workshops involving users, representatives of authorities and NSW. This collaboration allows the streamlining not only of the service but also of the interface and the business rules defined by NSW and authorities SOLUTIONS PROVIDED DURING THE PILOT PERIOD Interfaces of the NSW, routines, and processes DAKOSY hosted several working groups with the NSW and representatives of authorities and the industry in order to streamline the process and to adapt the routines and the interface according the results of the pilot phase. Upload passengerlist as csv-file Manual capture of long passenger lists proved to be a problem mainly for cruise ship operators. edeclaration is now offering the option to upload passenger-lists as a CSV-file. The On-board solution confronted DAKOSY with major challenges: Page 146

147 o During the pilot phase, DAKOSY discovered that the condition of hard- and software on ships is sometimes even lower than previously expected. The On-board solution had to be made downward compatible to EXCEL 97. o The low bandwidth of the satellite connections became quite a problem. The EXCEL-file as well as the encrypted XML needed downsizing. DAKOSY had to develop two versions of the EXCEL: SMART (very small, with fewer code-lists and automation) and CLASSIC. The XML was also streamlined. As a result, the rollout of new versions of the On-board solution via satellite as well as the operation on board is possible. The transmission of the XML-file to the NSW via DAKOSY can take place even with extremely low bandwidth. o The green border around the symbols of the register classes caused problems for people with red-green-color blindness. A checkmark was added in order to allow Figure 87: Screenshot edeclaration module Web - non-discriminatory access non-discriminatory access. o Inspection officers insisted on seeing the certificate of Health on paper, signed by the captain. In order to avoid duplicated work for the captain, the On-board solution was enhanced: data for the certificate of Health input for transmission to the NSW can now be printed on demand. Page 147

148 edeclaration - Web: The overview-list function with its status-flags (see Figure 79 edeclaration module Onboard solution) proved not to be the best solution for web-users. In order to help visualize the process, DAKOSY developed a graphic dashboard, using the familiar timelinefigure. Colours signal the current status of a form. The forms are hyperlinked, by clicking on the link the user is directed to the relevant form. Figure 88: Screenshot edeclaration module Web Dashboard VISIT-ID/Transit-ID: Previously, it was planned only to use edeclaration web or the GEGIS interface for the request of a VISIT-ID/Transit-ID. Since all carriers use the IFTSAI message to report their sailing schedules to the harbour, the solution VIP Vessel Information SHIP and the IFTSAI-messages have been amended. With the new VIP-routine, the carrier can request a VISIT-ID/Transit-ID at NSW when filing IFTSAI. PRISE: The Port River Information System Elbe, responsible for monitoring the movement of ships within the harbour, has been amended to work with the VISIT-ID. The berthing registration now requires a VISIT-ID. Page 148

149 Figure 89: PRISE- Port River System Elbe Alerts: During the pilot phase there was a constant demand for additional trigger on events and dates TASKS FOR THE NEAR FUTURE NSW: Updating interfaces, routines, processes This will remain an on-going process, demanding a lot of work. The next update for the interface has been scheduled for the first quarter of Alerts: Authorities asked for additional alerting routines, configurable by the user. For instance, a database with reporting simplifications for certain ships or cases, normally valid for only a certain period. Another request was for a list of ports which trigger an alert when visited by the ship prior to the actual port call. On-board solution: Some carrier do not use MS Office, but Open Office. The solution has to be adapted. And DAKOSY is working constantly to try to minimize the size of the EXCEL-file. Page 149

150 7.5 ANNEXES DAKOSY REPORT ANNEX 1: DAKOSY - FACT SHEET EDECLARATION FOR CARRIER ANNEX 2: DAKOSY - REFERENCE SARTORI & BERGER GMBH CO. KG A PILOT USER OF EDECLARATION FOR CARRIERS ANNEX 3: DAKOSY - XSD OF NSW INTERFACE 8 REPORT FOR THE PROTOTYPE ADAPTATIONS AND PILOT IN Port Collaborative Community System (PCCS) OF PIRAEUS PORT AUTHORITY PIRAEUS PORT AUTHORITY 8.1 LEGAL CONTEXT The legal context that masters the activities of this prototype is DIRECTIVE 2010/65/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States that repeals Directive 2002/6/EC. The purpose of this Directive is to simplify and harmonise the administrative procedures applied to maritime transport by standardising the electronic transmission of information and rationalising reporting formalities. It applies to the reporting formalities applicable to maritime transport for ships arriving in and ships departing from ports situated in Member States. Directive 2010/65/EU has been adopted by the Greek Legislation with the Presidential Degree 221 of November 8 th FORMER AND CURRENT COMMUNICATION SCHEMES Currently the reporting formalities are executed with various ways depending on the IT capacity of each company, the recipient organization as well as the applicable legislation. For example, customs documents are submitted electronically in ICIS.net, some of the documents required for the execution of port related activities are submitted electronically while other in paper. For the latter, as soon as PCCS of Piraeus Port Authority will become operational in real life conditions, a Page 150

151 full coverage of the documents required will be provided. For the Ship Formalities, as regulated by SafeSeaNet, are sent by to the Harbour Master. Other documents/reports are submitted in paper, while some remain at ship. 8.3 PROTOTYPE ADAPTATIONS IN PCCS OF PIRAEUS PORT AUTHORITY According to Directive 2010/65/EU the following documents are requested to be submitted electronically: A. Reporting formalities resulting from legal acts of the Union 1. Notification for ships arriving in and departing from ports of the Member States 2. Border checks on persons 3. Notification of dangerous or polluting goods carried on board 4. Notification of waste and residues 5. Notification of security information 6. Entry summary declaration B. FAL forms and formalities resulting from international legal instruments 1. FAL form 1: General Declaration 2. FAL form 2: Cargo Declaration 3. FAL form 3: Ship s Stores Declaration 4. FAL form 4: Crew s Effects Declaration 5. FAL form 5: Crew List 6. FAL form 6: Passenger List 7. FAL form 7: Dangerous Goods 8. Maritime Declaration of Health In the context of the present prototype and taking into consideration the common needs between PPA and PPA Harbour Master, the following documents have been adopted in order to comply with the Directive requirements: Page 151

152 - Ship PreArrivalNotice (24 hours) - Notification of waste and residues - FAL form 5: Crew List - FAL form 6: Passenger List - FAL form 7: Dangerous Goods PCCS had in its list of e-documents the Ship Pre Arrival Notice and Dangerous Goods. Thus, changes in terms of before & after can be presented for these two documents. The following figures present the old structure and highlight changes in the new ones. 8.4 PROTOTYPING, PILOTS AND IMPLEMENTATION By the time that the present report is submitted, the National Maritime Single Window implementation in Greece is under consultation progress. PPA by reacting in a proactive way has adapted its PCCS in order to be able to cooperate as and when the Maritime Single Window will be in place. The PCCS consists of the communication and administrative platforms that have been implemented in past initiatives of PPA (M4MOS). Namely the PCCS consists of two core platforms i.e. the Administrative one that provides enhanced security through a set of mechanisms that ensures the access only to authorized users. The Communication one that supports the transactions of all participants within the port community using different message structures (e.g. EDIFACT, XML, etc) and different communication protocols (e.g. SMTP, FTP, etc). A graphical representation of the integration of PCCS with the National Single Window is presented in the figure below. Page 152

153 Figure 90 - graphical representation of the integration of PCCS with the National Single Window The main functionality of the Communication Platform of PCCS that allows the integration with the National Single Windows is the Message Automated Control. It provides a set of services that are executed in the background allowing the communication, control and validation of the electronic messages exchanged. In particular, the e-document communication and control functionality supports the communication using different information and communication protocols. Message validation provides all the operations required for the checking of incoming and outgoing electronic messages in terms of structure and content, where applicable. Finally, a translation mechanism performs messages transformation using internal generic/ reference message structures. This approach allows the use of custom message structures on the client side, thus facilitating stakeholders with IT competence to integrate their existing e-documents with minimum modifications. In order to test, piloting and promote the activities of Activity 3, PPA has introduced the following: - A standalone application for the Harbour Master that simulates the communication with PCCS The standalone system (see Figure 91) has the following capabilities: Page 153

154 Activity 3 Report Store Incoming/ Outgoing messages in local folders View and search messages stored locally in a user friendly manner Preview and print Incoming/ Outgoing messages Manage automatically the communication with PCCS to send/ receive electronic messages without the need of the user to log into the web front end of PCCS Client MIS Harbour Master Manage the digital certificates Store Incoming/ Outgoing messages Search message capabilities Print Incoming/ Outgoing messages Manage Secure Communication with PCCS Create outgoing messages - Optional Inbound Data Outgoing flow XML (PCCS)+ XML ISO (NSW) Outgoing flow Inbound Messages Custom structure IF 1 Custom structure Incoming flow Standalone application XML (PCCS) Incoming flow IF 2 TCP/IP PCCS NSW Outbound Data Mapping Mechanisms Secure communication with PCCS to send/ receive messages Mapping Mechanisms Outbound Messages Standalone APP Repository Figure 91: Standalone application allows the communication with PCCS Due to the fact that the National Single Window is not in place, the following scenario that serves the need to submit only once the e-document has been introduced; i.e. a Ship Pre arrival notification is submitted to PCCS. The application allows the Harbour Master to receive e- messages. The incoming messages are collected from the PCCS and stored in a local storage area, in the final XML format. Then the Harbour Master can decide on how these messages will be used i.e. uploaded to SSN, stored etc. The reverse way is applicable when a message is submitted for the first time in the client application. - Access to messages through a web interface provided by PCCS Considering the current situation, it is simulated that a Ship pre arrival notice is submitted in the PCCS (as a single submission point). This e-document must be submitted to the Harbour Master. Page 154

155 Thanks to activities of Initiative 13 Clustering of ports in region, the Harbour Master can access PCCS and get the required information. The Harbour Master logs in the PCCS using the credentials provided by the administrator Figure 92 and check for new messages (Figure 93). In this case, the Ship Pre Arrival Notice has been received. The Harbour Master has a full record of all actions taken place internally for message validation etc (Figure 94) and has the capability to store the message, export in xls /pdf for further use etc. Figure 92: Logging of Lavrio Harbour Master in the PCCS using the web interface Page 155

156 Figure 93: New message for the Lavrio Habrour Master Figure 94: Visibility of transaction for message reception Page 156