D4.6 e MAR NSW application - e-Mar projectemarproject.eu/uploadfiles/D4.6 e-MAR NSW...

Grant Agreement number:265851 Project acronym: EMAR Project title: e‐Maritime Strategic Framework and Simulation based Validation Funding Scheme: SST.2010.5.2‐5

D4.6 e‐MAR NSW application

Due date of deliverable: 30/09/2014 Actual submission date: 20/11/2014 Start date of project: 01/02/2012 Duration: 36M

Organisation name of lead contractor for this deliverable: ILS

Revision [Final]

Project co‐funded by the European Commission within the Seventh Framework Programme

(2007‐2013)

Dissemination Level

RE Restricted to a group specified by the consortium (including the

Commission Services)

PU Public

EMAR D4.6

of 25

Document summary Information

Authors and contributors

Initial Name Organisation Role

TK Takis Katsoulakos INLECOM Author

GD Giorgos Doslaris INLECOM Author

YZ Yannis Zorgios CLMS Author

AM Antonis Migiakis CLMS Author

KA Konstantinos Athanasakos CLMS Author

Revision history

Revision Date Who Comment

V1.0 16/11/14 TK First version sent for reviews

V1.1 19/11/14 TK Final refinements

Quality control

Role Who Date

Deliverable leader TK 19/11/14

Quality manager JTP 19/11/14

Project manager JR 19/11/14

Technical manager TK 19/11/14

EMAR D4.6

of 25

1. Introduction This deliverable reports on developments carried out during the 3nd year of the eMAR

project in the field of the Maritime Single Window focusing on the business side. The

deliverable expands on the MSW developments focusing on the Authorities which was

reported in the earlier versions.

The application developed is the intelligent Ship Reporting Gateway (i‐Ship) is an innovative

software application, enabling shipping Industry representatives to fulfil their reporting

obligations to European Maritime & Custom Authorities, in accordance to the European

Commission Directives:

• 2009/17/EC: 24h pre‐arrival notice, Hazmat, notices to maritime reporting systems

and vessel traffic services.

• 2009/16/EC: 72h pre‐arrival notice, actual arrival / departure notifications

• 2010/65/EC: ship reporting formalities such as waste, security, FAL forms, maritime

declaration of health, entry summary declaration, passenger list, crew effects, cargo

manifests, etc.

i‐Ship facilitates the interconnection of ships with operational stakeholders and reporting

authorities can be used to automate reporting formalities needed for entry and departure

from ports and sailing through controlled waters according to the specific needs of a

shipping company. All the related tasks are carried out in a timely and correct manner taking

into account the type of ship and applicable regulations to a voyage.

Figure 1: i‐Ship interconnects ships with operational stakeholders and reporting

authorities

EMAR D4.6

of 25

2. i‐Ship Users i‐Ship offers a web‐based collaborative reporting environment for ship managers and their

business partners;

• Ship managers introduce voyage information

− Directly using the i‐ship web application or via connection to the company’s

ERP and /or other applications (e.g booking, or chartering)

− The data introduced may or may not include cargo consignment information

• Ship representatives (i.e. agents at a specific port) and/or ship masters to submit

port clearance related formalities to MSWs or related authority systems

• Cargo consignors to introduce cargo consignment data being aware (or not) of the

specific cargo movements (which are decided by the ship operator)

• Cargo representatives to submit cargo clearance formalities to MSWs (e.g. ENS/

eManifest) or to Custom Authorities (e.g. ICS, ECS)

Figure 2: i‐Ship: a complete solution for ship formalities and compliance management

3. Ship reporting requirements fulfilled by i‐Ship By the definition in Article 2(a) of Directive 2010/65/EU, “reporting formalities” are the

information required by three different categories: A) reporting formalities resulting from

the legal acts of the Union; B) FAL forms and formalities resulting from international

agreements(such as International Maritime Organization ‐ IMO or International Health

Regulation ‐ IHR); and C) Any relevant national legislation. Therefore, the common data sets

will have to be aligned according to the Directive. Art.5 (1) §1 specifies that MS shall accept

EMAR D4.6

of 25

the fulfilment of reporting formalities in electronic format and their transmission via their

national single window. The data to be exchanged is already partly regulated by the

Directive 2002/59/EC or the requirements of ICS and ECS according to the Community

Customs Code,

Ship reporting requirements fulfilled by i‐Ship are given in the following table

Reporting

requirement Legal basis

Potential submission formats (currently implemented or planned by June 2015)

Pre‐arrival notice

According to EU legal Acts (Article 4 of Directive 2002/59/EC) and similar regulations adopted by Norway and Iceland a notification for ships arriving in ports of the Member States is required (submitted at least 24 hours before arrival and including ETA and person on board information)

XML‐based (ISO 28005/ EMSA epc xsd edition) XML‐based (WCO‐based AnNA format) XML‐based (e‐Mar

CRS)

Passenger and Crew lists

According to EU legal Acts (Article 7 of Regulation (EC) No 562/2006) passenger and crew and stowaways information for border checks on persons is notified to border control Authorities

Notification of dangerous or polluting goods carried on board

According to EU legal Acts (Article 13 of Directive 2002/59/EC) and similar regulations adopted by Norway and Iceland, a notification of dangerous or polluting goods carried on board is required

Notification of waste and residues

According to EU legal Acts (Article 6 of Directive 2000/59/EC) and similar regulations adopted by Norway and Iceland a notification of waste and residues is required (submitted at least 24 hours before arrival)

information on ship security level and on last 10 calls at port facilities)

According to EU legal Acts (Article 6 of Regulation (EC) No 725/2004) and similar regulations adopted by Norway and Iceland a notification of security information (including e.g. the information on ship security level and on last 10 calls at port facilities)is required (submitted at least 24 hours before arrival).

Entry summary declaration (ENS)

According to EU Custom regulations an Entry summary declaration (ENS) for cargo consignments loaded at non Union ports has to be lodged at the Custom office of first entry in the Union or at an ENS office of lodgment at least 24h before the departure of the ship from the port where the consignment was originally loaded.

XML‐based (ISO 28005/ EMSA epc xsd edition) XML‐based (WCO‐based AnNA format) XML‐based (e‐Mar CRS) XML‐based DDNIA

EMAR D4.6

of 25

Cargo Manifest

According to specific Customs regulations applicable in European countries a cargo manifest is to be lodged for ships arriving and/ or leaving EU ports. Furthermore a declaration of goods unloaded for temporary storage might be required.

format (DG TAXUD)

FAL forms:

National regulations may require the submission of individual FAL forms for ships arriving or departing.

EDIFACT XML‐based (ISO 28005) XML‐based (e‐Mar CRS)

Berth requests National regulations may require the electronic submission of berth allocation

EDIFACT (BERMAN) XML‐based (e‐Mar CRS)

The framework of standards would be based on the following reference specifications:

1. ISO/DIS: Electronic port clearance (EPC) —Part 1: Message structures —

Implementation of a maritime single window system

2. ISO 28005‐2: Electronic port clearance (EPC) —Part 2: Core Data elements

3. DG TAXUD ‐ Design Document for National Import Application (DDNIA)

4. EDIFACT standards referenced in the revised IMO compendium on facilitation

and electronic business (FAL.5/Circ.40/ 4, July 2013)

5. WCO standards adopted by AnNA project and reflected to theAnNA Message

Interface Guide.

6. SSN XML Reference guide

Regarding the ISO standards, it should be expected that changes/ refinement of the

specifications are likely (reference is made to those changes stemming from the current

tests of EMSA and Members states in the IMP demonstrator project).

Reporting exceptions as listed in the following table are automatically managed.

Directive Reference Exemption

relates to:

Text

2002/59/E

C as

amended

by

2009/17/E

C

Article 15 Notification

prior to

entry into

ports of the

Member

States

Notification

1. Member States may exempt scheduled services performed between ports located on their territory from the requirements of Articles 4 and 131 provided the following conditions are met: (a) the company operating those scheduled

services keeps and updates a list of the ships concerned and sends that list to the competent authority concerned,

1 Notification of dangerous or polluting goods carried on board

EMAR D4.6

of 25


relates to:

Text

of

dangerous

or polluting

goods

carried on

board

(b) for each voyage performed, the information listed in Parts 12 or 33, as appropriate, of Annex I is kept available for the competent authority upon request. The company shall establish an internal system to ensure that, upon request 24 hours a day and without delay, such information can be sent to the competent authority electronically, in accordance with Article 4(1) or Article 13(4), as appropriate.

(c) any deviations from the estimated time of arrival at the port of destination or pilot station of three hours or more are notified to the port of arrival or to the competent authority in accordance with Article 4 or Article 13, as appropriate;

(d) exemptions are only granted to individual vessels as regards a specific service. For the purposes of the first subparagraph,

the service shall not be regarded as a

scheduled service unless it is intended to

be operated for a minimum of one month.

Exemptions from the requirements of

Articles 4 and 13 shall be limited to voyages

of a scheduled duration of up to 12 hours.

2. When an international scheduled service is operated between two or more States, of which at least one is a Member State, any of the Member States involved may request of the other Member States that an exemption be granted to that service. All Member States involved, including the coastal States concerned, shall collaborate in granting an exemption to the service concerned in accordance with the conditions laid down in paragraph 1.

3. Member States shall periodically check that the conditions set out in paragraphs 1 and 2 are being met. Where at least one of these

2 Information to be notified in accordance with Article 4 — General information

3 Information to be notified in accordance with Article 13

EMAR D4.6

of 25


relates to:

Text

conditions is no longer being met, Member States shall immediately withdraw the benefit of the exemption from the company concerned.

4. Member States shall communicate to the Commission a list of companies and ships granted exemption under this Article, as well as any updates to that list.

2000/59/E

C

Article 9 Waste

notification

1. When ships are engaged in scheduled traffic with frequent and regular port calls and there is sufficient evidence of an arrangement to ensure the delivery of ship‐generated waste and payment of fees in a port along the ship's route, Member States of the ports involved may exempt these ships from the obligations in Article 64, Article 7(1)5 and Article 86.

2. Member States shall inform the Commission of exemptions granted in accordance with paragraph 1 on a regular basis, at least once a year.

2004/725/

EC

(Regulatio

n)

Article 7 Provision of

security

information

prior to

entry into a

port of a

Member

State

1. Member States may exempt scheduled services performed between port facilities located on their territory from the requirement laid down in Article 67 where the following conditions are met: (a) the company operating the scheduled

services referred to above keeps and updates a list of the ships concerned and sends it to the competent authority for maritime security for the port concerned,

(b) for each voyage performed, the information referred to in paragraph 2.1 of regulation 98 of the special measures to enhance maritime security of the SOLAS Convention is kept available for the competent authority for maritime security upon request. The company must establish an internal system to ensure that, upon

4 Notification of waste and cargo residues to be notified before entry into port 5 Delivery of all ship‐generated waste to a port reception facility 6 Fees for ship‐generated waste 7 Provision of security information prior to entry into a port of a Member State 8 Regulation 9 refers to control and compliance measures . Paragraph 2.1 of 9 refers to information to be provided to officers duly authorised by that Government

EMAR D4.6

of 25


relates to:

Text

request 24 hours a day and without delay, the said information can be sent to the competent authority for maritime security.

2. When an international scheduled service is operated between two or more Member States, any of the Member States involved may request of the other Member States that an exemption be granted to that service, in accordance with the conditions laid down in paragraph 1.

3. Member States shall periodically check that the conditions laid down in paragraphs 1 and 2 are being met. Where at least one of these conditions is no longer being met, Member States shall immediately withdraw the privilege of the exemption from the company concerned.

4. Member States shall draw up a list of companies and ships granted exemption under this Article, and shall update that list. They shall communicate the list and updates thereof to the Commission and any Member State concerned.

5. Notwithstanding the provisions of paragraphs 1 and 2, a Member State may, on security grounds and on a case‐by‐case basis, request the provision of the information referred to in paragraph 2.1 of regulation 9 of the special measures to enhance maritime security of the SOLAS Convention prior to entry into a port.

4. Key i‐Ship Reporting Features 1. Full compliance with European Union legal requirements on ship and cargo reporting

(taking into account exceptions for regular shipping. Additional reporting requirements

are included based on a case‐by‐case request of a customer particularly for destinations

with Single Windows (e.g. US eNOAD).

2. Easy configuration of the:

• Communication with the Maritime, Custom and Border Control Authorities

systems in a variety of electronic formats and in accordance with the rules

applicable per country and/ or port visited by the reporting ships;

• Users’ profiles/access rights.

EMAR D4.6

of 25

3. Easy maintenance and preloading of data repeated frequently in notifications (e.g. ship

particulars, port location codes)

4. Easy customisation of the application in order to be utilised, based on specific company

practices:

• Ashore, by Ship Managers/Operators/Ship Agents/Cargo Consignors and

forwarders

• On board ships, by Ship’s authorised staff (e.g. ship masters)

5. Interfacing to existing ship applications and other information sources for automated

extraction of required data

6. Warning when sailing into Emission Control Areas (ECA) and managing related records

7. Automated updating of data models to adhere to new regulations

5. Benefits 1. A highly flexible and user‐friendly tool (for use on‐board and ashore) for linking voyage/

ship cargo information with port formalities reporting.

2. Streamlining of the reporting work‐flows facilitating the exchange of ship and cargo

information among all the actors involved in reporting, respecting their access rights on

a “need‐to‐know” basis.

3. Visibility of the reporting /compliance status of the fleet by the shipping management

team – possibly for the first time

4. Extensible Rule Engine that can be adjusted to the user needs and extended to conform

to the latest legislation, without technical complexity

5. Reduction of the reporting burden (from hours to minutes) allowing ship personnel to

focus on efficiency and safety of operations.

6. Reduction of the overall cost of reporting by eliminating non‐adding value

intermediaries.

7. Reduction of IT complexity. Easy integration / sharing of information with other

company “in‐house” systems providing reference data for fulfilling reporting

requirements and/ or vessel tracking.

8. Compliance with international standards (e.g. ISO 28005, WCO, EDIFACT) and EU specific

formats and requirements.

EMAR D4.6

of 25

6. i‐Ship Innovation ‐ Technological advantages

6.1 Building on knowledge from FP7 projects during last 5 years The i‐Ship solution has been developed as part of the eMAR Project building on:

• Partners’ inputs and developments in:

− eFreight project deliverables related to Common Reporting Schema CRS

(mainly the part related to cargo data elements)

− COMCIS project integration of ENS messages to ICS Customs systems using

CRS

− e‐Freight, SUPPORT, CONTAIN, ICargo (connectivity infrastructure, semantic

integration technologies,Cloud and Smart Systems)

• Work of DG TAXUD on ENS‐related messages

• Work of eMS Group on data elements definition/business rules

− Data mapping‐related reports

• Work of AnNA project on data elements/messages definition

− B2MSW reports and relevant messages

• Work of EMSA on IMP demonstrator project and SSN

− Documents published in EMSA web site

6.2 Supported by the model driven development platform zAppDev9

1. i‐Ship Reporting is based on a Model‐Driven Architecture utilizing the eMaritime

Strategic Framework (EMSF)

2. The Domain Model of the application can be available in various platforms (JAVA,

.NET, etc.) and formats (binary, XSD, RDF, etc.)

3. Code and documentation are automatically generated and therefore customization

is easy and robustness guaranteed

4. Easy, low‐cost maintenance and extensibility both to company and regulatory

changes

5. Tools are available utilizing semantic technologies for integrating with company

specific IT systems

9 http://www.clmsuk.com/platform/

EMAR D4.6

of 25

6.3 A unifying ship reporting domain model for Maritime Single Windows (MSWs)

The data elements that are included in the MSW can be derived by the relevant

legislation/directives. A minimum data set can be specified with reference to 2010/65.

However all related directives should be addressed, including national legislation and port

specific laws were applicable. Further, harmonisation with other modes has advantages, so

additional data elements could be added.

The CRS (Common Reporting Schema) as the name implies supports a unified solution for

regulatory information management associated with trade and transport at both National,

EU and international levels.

CRS2 was developed in eMAR to provide the data model and messages for MSWs with

knowledge of current standards and harmonised with similar initiatives such as the AnNA

project and data mapping activities carried out by eMS Group and EMSA IMP.

A major advantage of CRS (ubl) is that it is structured to represent accurately both a cargo

and ship / voyage perspectives. It has been constructed talking into account the main

international standards, particularly WCO and EPC. CRS2 is part of the eMAR Framework

EMSF and therefore provides i9nteroperability with eMaritime applications.

Figure 3: CRS2 provides compatibility with MSW models and remains simple and extensible

The CRS2 has been tested for submission of formalities under various scenarios, including

submissions to Customs ICS systems, submissions to SSN via National Single Windows, and

submissions by the DNV Navigator and other ship applications particularly with DANAOS.

More recently eMAR tested EPS messages with the MSW prototype produced by EMSA

(IMP) establishing a B2A integration between a shipping company (DANAOS) and the EMSA

(IMP). Testing entailed a specific set of formalities (i.e. A1‐Port, A2‐Border, A3‐DPG, A4‐

Waste, A5‐Security) and the various business rules that are related to these

EMAR D4.6

of 25

The CRS2 model shown in Figure 4 indicating the objects from ISO/WCO and the CRS objects

under UBL /WCO standards

Objects definition Based on ISO/ WCO Based on CRS (UBL/ WCO)

Figure 4: CRS2 Model

EMAR D4.6

of 25

The main objects are listed in the following table. Object Purpose/ Definition Notes

Crew List A class providing contact details for a Crew Member on a specified ship during one or more voyages. An ”Organization” or ”Contact” authorized to exchange information (provide or request/ receive and/ or both) by utilizing an application

Crew Member A class providing contact details and Identification for a Crew Member, on a specified ship.

A Crew Member is defined for a period of time, for a specific ship (e.g. can be crew member for one or more voyages of the ship).

Consignment An identifiable collection of one or more goods items to be transported between a consignor and a consignee. This information may be defined within a transport contract. A consignment may include items from more than one shipment (e.g., when consolidated by a freight forwarder).

IsDelivered” would indicate good items of a consignment have been unloaded.

Custom message

A class providing the identification elements of a message sent to a Custom Authority providing details of one or more cargo consignments

could be instantiated as an entry summary declaration (ENS) or an eManifest declaration containing data for goods of Union and Non Union Status

Dutiable Crew Effects

A class used to register all crew effects that may be dutiable.

e.g, for cigarettes and alcohol, the list contain two entries with the same Crew member Reference

eManifest An electronic document containing consolidated cargo information for goods of Union or ”Non Union” status

General Description of DG

A class providing information about the list of all dangerous goods on board the ship during a passage

Good Item A “sister” class to item describing a separately identifiable quantity of goods of a single product type

Health Declaration

A class containing general Health information related to ship during a passage

Provides Information for the health condition of persons and animals on board the ship.

Item A class describing an item of trade

Location A class describing a place (e.g. a port) visited by ship

MDH Attachment

Maritime Declaration of Health is a class with list of health information related to a specific Passenger / Crew Member or Stowaway during a passage

MRF message A class providing the identification elements of a message exchanged between two applications. The message shall contain information related to ship reporting

the MRF message could be instantiated as a FAL form or a set of FAL forms or a 24h, 72h, waste security, etc. notification

EMAR D4.6

of 25

formalities for a given port Call

Organisation A class providing contact details for a public Authority or a private company identified in a notification and/ or sharing data using an application

Passenger A class providing contact details and Identification for a passenger.

Passenger List A class providing contact details for a List of passengers, for a specific ship passage.

Person A class providing basic information of a person

Port Call A class comprising all the information related to a visit of a ship to a port

For a PortCall two “child” classes could be also defined. The ”VoyageArrivalNotice” class and the ”VoyageDepartureNotice” class

Port facility A class identifying a specific area in a port bound by specific security rules

Security Information

A class that that contains some of the Security information for a ship that should be sent with Arrival Notice.

Ship A class comprising the ship identity identifiers and particulars of ship structure and operational status

A child class may describe the dynamic ship particulars changing during ship operations

Ship Certificate

A class providing details about the ship certificates

Ship Itinerary Is class providing information for all the passages defined for a Cruise ship at a given period

Ship position Notification

A class containing ship position information. The position could be derived from sensors installed on board ships such as AIS or LRIT transponders and communicated to i‐Ship application via an appropriate protocol

Ship Store A class with a description of the dutiable stores that the ship carries

This is a list of the ship's stores, including type, quantity and location onboard

Shipment Stage

A class describing one stage of movement in a transport of goods

Stowaway A class providing contact details for a Stowaway on Board

Stowaway List A class providing a list of Stowaways for a specific passage

Transport Equipment

A class describing a piece of equipment used to transport goods

Transport Handling Unit

A class describing a uniquely identifiable unit consisting of one or more packages, goods items, or pieces of transport equipment.

Transport Means

A data set describing a particular vehicle or vessel used for the conveyance of goods or persons

EMAR D4.6

of 25

Voyage (based on the definition used in the SSN XML RG v.07) A class the ship passage from the port of departure to the port of arrival

Voyage Arrival Notice

A class providing information related to the ship’s arrival at the port of call

Voyage Departure Notice

A class providing information related to the ship’s departure from a port of call

Waste Disposal Information

A class with a list of waste per type, providing condition for waste types on board the ship

Waste Information

A class that contains general information on ship waste This are the information that should be sent to a port in conjunction with an arrival as recommended by [MEPC 644] and as required by [2000/59/EC] for ships visiting European ports

Way‐point A class identifying a location at sea of interest where a ship called at a given time‐stamp

Could be used for defining the location/time of an incident at sea, the entry or exit location/ time to a reporting area at sea, etc.

EMAR D4.6

of 25

7. i‐Ship Functional Details

7.1 Administrator and reporting party functions

Figure 5: i‐Ship Administrator and reporting party functions

7.2 i‐Ship Web interface design principles The web interface design (data entry forms) is “inspired” from EMSA work on IMP, but gives

emphasis on usability with the introduction of :

• A “Dashboard” (to facilitate choice of actions) • Voyage formality and alerts set-up form (to facilitate business rule

enforcement)

Figure 6: i‐Ship Web interface design

Administrator

• Party (Person or Organisation) management

• Application user management

• Location management (e.g. Ports, Port Facilities, Areas)

• Vessel management

• Formality/ System interfaces (Access components) management

Ship Reporter

• Voyage/Port Call creation/ update

• Cargo consignment and/ or cargo manifest creation/ update

• Formality status tracking

• Formality submission to MSW / Customs

ShipVoyage and port callPre‐arrival (PSC)

Cargo (including DPG)Waste

Ship storesSecurityCrew

PassengerHealth DeclarationMDH AttachmentPersons on board

Data entry forms (Voyage or declaration)

EMAR D4.6

of 25

7.3 i‐Ship “Dashboard” form The three main areas are:

1. Ships 2. Voyages 3. Notifications

Figure 7: i‐Ship Web interface design

EMAR D4.6

of 25

EMAR D4.6

of 25

The “ships’ area” presents a list of the ships that the user is authorized to handle, be this in

terms of editing ship data, or in terms of creating voyages. Specifically, the user may access

a ship in order to update information regarding ship particulars, and even mark a certain

ship as detained or banned in a particular port. However, the “ships’ area” is mostly used in

order to create future voyages or log previous ones.

The “voyages” area presents a list of all voyages that the logged‐in user can manage. This list

may be subsequently filtered through text search or even be filtered by a specific ship. Users

may choose to update a specific voyage. This operation allows modifying all available

information regarding a voyage, which includes the port of call, the expected time of arrival

(ETA), crew list, cargo information, etc. Moreover, users may modify the alerting

preferences of a single voyage, which include the time thresholds for sending

notifications/alerts for reporting obligations. Finally, users may select a single voyage and

choose to create a reporting message. The system will then prompt the user to select the

formalities which will be included based on the profile that has previously been created for

the specific voyage.

The top area of the dashboard presents a list of the reporting obligations for the current

user, on which users may act upon by filling reporting messages and submitting these to the

reporting gateways. In order to present the status of each message, the formalities that a

message consists of are grouped into Formality Groups. In each group, a flag indicates the

status of the corresponding group with respect to the formalities that are pending

submission, having been submitted or authorized, etc. Specifically, the following statuses

are available per group:

1. Notification submission time approaching. 2. Notification submission overdue. 3. Notification submission pending, but still adequate time to submit. 4. All required notifications concerning the formalities were submitted. 5. Clearance approval pending. 6. Authority requests more information. 7. Clearance denied. 8. Clearance granted.

7.4 i‐Ship: Alerting and business rules enforcement The process of reporting maritime formalities is subject to business rules with respect to

the time thresholds within which messages are to be sent as well as in terms of the

actual content that needs to be submitted. Also applicable exceptions need to be taken

into account. However these business rules are usually being inherited from the national

legislation and even specific port bylaws, which dictates the way of handling these rules

at the application level. As such, the system enables authorized users to configure

thresholds according to national legislation, as well as modify these settings to

accommodate port level requirements. Exceptions are also visible here.

EMAR D4.6

of 25

Similarly, authorized users may configure the set of applicable formalities. These

preferences are inherited at port level, but may be modified, thus allowing for further

customization. Finally, upon initiation of a reporting session, the user is prompted to

select the formalities that will be included to the message based on the underlying

country and port profiles.

Finally, when creating or updating a single voyage, the user is able to specify the set of

formalities from which the current ship is exempted for the specific voyage.

EMAR D4.6

of 25

Figure 8 i‐Ship: Alerting and business rules enforcement

EMAR D4.6

of 25

7.5 Integration with MarineTraffic Work is progressing tom enable the i‐Ship reporting gateway to share information with

MarineTraffic.com, access information maintained in the database of the MarineTraffic.com

platform and be invoked as an add‐on service via the Web Interface of MarineTraffic.com.

The integration of the two systems will create a unique product that will be of significant

value to the members of the shipping community. Agents and ship‐owners will take

advantage of their data being already present on the MarineTraffic.com database, and will

get the added value of being able to manage their voyages as well as reporting and

exchanging formalities with national Single Window (NSW) systems in accordance with

Directive 2010/65/EU.

At the same time, users will have access to real‐time vessel positions and smart ETA

estimation provided by MarineTraffic.com, allowing for automatic alerts regarding the

obligations towards Maritime Authorities based on the current Voyage profile. Finally, the

integrated product will encompass the rich user experience provided by the

MarineTraffic.com intuitive map interface displaying current Vessel positions and voyage

estimates.

Last but not least, i‐Ship will also benefit in terms of exposure, as MarineTraffic offers a

prime sales channel, given the strong brand and the wide reach; more than 5 million people

use the service each month, including a large portion of the shipping industry.

The entry point for the service will be the MarineTraffic.com website. The user

registration process occurs in the MarineTraffic system while users obtain access and

control over their vessels through an offline procedure that requires supplying certain

ownership certificates; this process is already setup and in‐place by MarineTraffic. Following

this step, users may request access to the reporting service which will result in registering

the user account in i‐Ship. The newly created user account will also be linked to a company

account; the company account will be identified using the IMO Company Number and will

be created if it does not already exist. To accommodate the exchange of the above

information, the Corporate and User Account structures that are already being used by

MarineTraffic will be mapped to the corresponding Company and User account structures of

i‐Ship. The registration process is also shown in Figure 9.

EMAR D4.6

of 25

Figure 9. User Registration to MarineTraffic and i‐Ship

Connectivity between the two systems will be achieved through a centralized token‐

based Authentication service provided by MarineTraffic.com, which will enable Single‐Sign‐

On and Single‐Sign‐Off in both systems. With regards to Authorization, a set of predefined

roles will be agreed between the two systems, so that i‐Ship is aware of the operations to

which each user is granted access.

8. Deployment details i‐Ship is offered as a SAAS (software as service), but can also be available on private clouds

or on premise. Currently deployed in Microsoft's Azure WebSites infrastructure. It is

monitored and can be auto‐scaled to meet demand and SLA terms.

The application is configured to use SSL and RSA encryption for securing data exchange. I‐

Ship has its own user management module which provides authentication and identity

control.

Access control is done with Roles, Permissions, and Attribute filtering which are all

configurable by application administrators.

Access from the application to the database is made with an additional security layer.

EMAR D4.6

of 25

9. Conclusions i‐Ship is a “Cloud”‐based collaborative environment for ship managers and their associates

(cargo/ ship agents and cargo consignors) acting as “European common reporting gateway

to all reporting nodes” (port community system or MSW, Customs) in Europe. It provides a

single link for shipping companies to submit their reporting requirements in EU waters. The

service could be hosted by a ship operator or a service broker providing services to several

shipping actors (managers or agents).

The main advantage of i‐Ship compared to other solutions is that it is based on a domain

model is compatible with recent developments both in maritime single windows (AnNa,

IMP) and e‐Freight (CRS). This coupled with the model driven development platform used

creates unique integration options for shipping companies and offers a potential solution

for unified front end to EU Member States MSWs.

To this end i‐Ship can be used as web client/ server application acting as a B2A front‐end for

an MSW or Port single window system. These web interface and a system interface

components are available to EU member states as a contribution to ongoing efforts for a

unifying g EU implementation of the reporting formalities directive.

The i‐S hip is currently available in the market as beta version and pilot operation continues

with DANAOS and discussions for pilot operation are at an advanced stage with some 10

shipping companies. An agreement has also been reached for common pilots with AnNA.

Partnership Inlecom offers i‐Ship with partners including BMT, CLMS, DANAOS, EBOS, MarineTraffic

D4.6 e MAR NSW application - e-Mar projectemarproject.eu/uploadfiles/D4.6 e-MAR NSW...

Documents

Transcript of D4.6 e MAR NSW application - e-Mar projectemarproject.eu/uploadfiles/D4.6 e-MAR NSW...