Guide for the implementation of SSN/ NSW – related ...emarproject.eu/uploadfiles/D4.3 Appendix...

of 72

Grant Agreement number: 265851

Project acronym: EMAR

Project title: e‐Maritime Strategic Framework and Simulation based Validation

Funding Scheme: SST.2010.5.2‐5

Guide for the implementation of SSN/ NSW – related e‐Maritime services and the interoperability of these

services with National and EU systems

Attached as Appendix D to the Deliverable D.4.3: eMAR D4.3 ‐ Interfacing e‐Maritime with SSN and

related developments (v2)

Document Author: UPRC

First definite version

Project co‐funded by the European Commission within the Seventh Framework Programme (2007‐2013)

Dissemination Level

PU Public

eMAR D4.3 ‐ Appendix D

of 72

This eMAR report is licenced under a Creative Commons licence

Attribution-NonCommercial-ShareAlike 4.0 International

https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode


Page 3 of 72

Contents Abbreviation and Definitions……………………………………………………………………………………………..……..4

Executive Summary…………………………………………….…………………………………………………………………..13

1 REFERENCE DOCUMENTS ............................................................................................................ 15

1.1 INTERNATIONAL STANDARD/ DE‐FACTO STANDARDS ..................................................................................... 15

1.2 LEGISLATIVE REFERENCES ........................................................................................................................ 15

1.2.1 Reporting formalities resulting from legal acts of the Union ........................................................ 15

1.2.2 FAL forms and formalities resulting from international legal instruments .................................... 16

1.2.3 Any relevant national legislation .................................................................................................. 16

1.2.4 EU legislation related to eManifest .............................................................................................. 17

2 E‐MARITIME SERVICES PORTFOLIO (SSN/ NSW‐RELATED) ............................................................ 17

2.1 INTRODUCTION .................................................................................................................................... 17

3 SERVICES PORTFOLIO (SSN/ NSW‐RELATED) PROPOSED BY THE EMAR PROJECT .......................... 20

3.1 COMMON FUNCTIONAL BLOCKS IN EMAR APPLICATIONS FOR REPORTING FORMALITIES ........................................ 21

3.2 PROPOSAL ON A CONCEPTUAL DATA MODEL (CORE OBJECTS) .......................................................................... 24

3.2.1 eFreight CRS adaptation to the eMAR requirements ................................................................... 24

3.2.1.1 ISO 28005 relevant messages .................................................................................................. 24

3.2.1.2 ICS relevant messages ............................................................................................................. 24

3.2.1.3 «Custom» messages to be used for complementary data exchange between eMAR_CRS‐compliant business applications ............................................................................................................... 25

3.2.1.4 SSN reference messages .......................................................................................................... 25

3.2.1.5 «Custom» messages to be used for complementary data exchange between eMAR_CRS‐compliant Authority applications and eMAR_CRS‐compliant single windows .......................................... 25

3.2.2 eMAR domain model – Core objects ............................................................................................ 25

4 FUNCTIONAL REQUIREMENTS APPLICABLE ON THE COMMON MODULES OF THE EMAR APPLICATIONS .................................................................................................................................... 31

4.1 EPC MESSAGE TRANSFORMER & INTERFACE ................................................................................................ 31

4.1.1 Requirements specific to eMAR Common Reporting Gateway (CRG) applications ........................ 31

4.2 EPC DATA ENTRY AND CONSULTATION ........................................................................................................ 33

4.3 MANAGEMENT AND CONFIGURATION ........................................................................................................ 49

4.4 DATA PROCESSING AND STORAGE (REFERENCE DATA) .................................................................................... 51

4.5 REFERENCE DATA EXCHANGE ................................................................................................................... 51

4.6 DATA PROCESSING AND STORAGE (SHIP OPERATIONS) ................................................................................... 51


4.7 VESSEL TRACKER ................................................................................................................................... 60


4.8 TRANSACTION TRACING & LOGGING .......................................................................................................... 62

4.9 ACCESS CONTROL & SECURITY .................................................................................................................. 63


Page 4 of 72

List of tables TABLE 1 PORTFOLIO OF E-MARITIME SERVICES PROPOSED BY EMAR ....................................................... 20

TABLE 2 CORE BUSINESS CONCEPTS FOR EMAR APPLICATIONS FOR SHIP/ CARGO REPORTING FORMALITIES 27

TABLE 3 ROLES THAT COULD BE ASSIGNED TO AN ACTOR BASED ON THEIR BUSINESS PROFILE ................. 64

TABLE 4 ACCESS RIGHT TYPES .............................................................................................................. 67

TABLE 5 FUNCTIONS AND THEIR DEFAULT SET OF RESTRICTIONS (INDICATIVE) ........................................... 68

TABLE 6 FUNCTIONS FOR THE LOCALCALLREPORTER (SHIPAGENT) AND VOYAGEPLANNER ROLES

(INDICATIVE) ................................................................................................................................ 71

List of figures FIGURE 1 APPLICATION LANDSCAPE IN EUROPE FOLLOWING THE IMPLEMENTATION OF THE RFD ................. 18

FIGURE 2 COMMON FUNCTIONAL BLOCKS IN EMAR- COMPLIANT APPLICATIONS FOR BUSINESS AND/ OR

GOVERNMENT .............................................................................................................................. 21

FIGURE 3 LOGICAL MODEL FOR EMAR APPLICATIONS/ CORE BUSINESS OBJECTS ...................................... 26

FIGURE 4 WIRE-FRAME OF THE DASHBOARD FOR THE PORT CALL PLANNER & SHIP REPORTER APPLICATION 38

FIGURE 5 MOCK-UP OF THE DASHBOARD BASED ON I-SHIP REPORTING PROTOTYPE IMPLEMENTATION OF A THE

PORT CALL PLANNER & SHIP REPORTER APPLICATION ..................................................................... 39

FIGURE 6 MOCK-UP OF THE DASHBOARD TO BE USED BY A SHIP AGENT USING THE SHIP/ CARGO REPORTER

APPLICATION ................................................................................................................................ 40

FIGURE 7 MOCK-UP OF THE DASHBOARD TO BE USED BY AUTHORITIES USING AN MSW APPLICATION .......... 41

FIGURE 8 MOCK-UP OF WEB-FORMS ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO THE

SHIPCALL/ PSC FORMALITY GROUP(S) (1/2) .................................................................................. 42

FIGURE 9 MOCK-UP OF WEB-FORMS ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO THE

SHIPCALL/ PSC FORMALITY GROUP(S) (2/2) .................................................................................. 43

FIGURE 10 MOCK-UP OF WEB-FORM ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO THE

SECURITY FORMALITY GROUP ........................................................................................................ 44


WASTE FORMALITY GROUP ............................................................................................................ 45

FIGURE 12 MOCK-UPS OF WEB-FORMS ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO

THE BORDER FORMALITY GROUP .................................................................................................... 46


HEALTH FORMALITY GROUP ........................................................................................................... 47


CARGO/ HAZMAT FORMALITY GROUPS ............................................................................................ 48

FIGURE 15 MOCK-UP OF PORT PROFILE CONFIGURATION FORM ................................................................ 50


Page 5 of 72

Document summary Information

Authors and contributors

Initial Name Organisation Role

IM Ilias Maglogiannis UPRC Main Author

IK Ioannis Koliousis UPRC Contributor

NT Nikos Tsirkas UPRC Contributor

Revision history

Revision Date Who Comment

Draft 0.1 1/08/14 IM Table of Contents of the deliverable

Vfidr 16/09/14 NT and IM

First Complete Draft for project team review

Vfinal 30/09/14 IM First definite release (to the project Coordinator for delivery to the Commission)

Quality control

Role Who Date

Quality manager JTP 30/09/2014

Project manager JG 30/09/2014

Technical manager TK 30/09/2014

Disclaimer

The content of the publication herein is the sole responsibility of the publishers and it does not

necessarily represent the views expressed by the European Commission or its services.

While the information contained in the documents is believed to be accurate, the authors(s) or any

other participant in the EMAR consortium make no warranty of any kind with regard to this material

including, but not limited to the implied warranties of merchantability and fitness for a particular

purpose.

Neither the EMAR Consortium nor any of its members, their officers, employees or agents shall be

responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or omission

herein.

Without derogating from the generality of the foregoing neither the EMAR Consortium nor any of its

members, their officers, employees or agents shall be liable for any direct or indirect or

consequential loss or damage caused by or arising from any information advice or inaccuracy or

omission herein.


Page 6 of 72

Abbreviations & Definitions Term Definition Access Component

(eMAR D4.2 introduced term) Access component in the domain model of an eMAR‐compliant e‐Maritime application defines:

A web interface that an Actor will use to notify or visualize data

A way of interaction between an actor and an eMAR‐compliant application that the Actor shall utilize to notify data (e.g. a web service)

A way of interaction made available to an Actor to receive and/ or request data from an external application connected to the one that the Actor uses

Actor (eMAR D4.2 introduced term) Actor is party (that is an organization or individual) authorized to access an application’s resource and execute a number of functions based on a set of restrictions associated to the functions

Aggregation (of information)

(Definition from the CISE Architecture Vision Document)A function where requested information from multiple sources are grouped together to form a single response e.g. a list or a set.

Agreement (Definition from the CISE Architecture Vision Document)A contract between one or more authorities acting as information providers and one or more authorities acting as information consumer to define the term and conditions for accessing and providing services. Can be bi‐lateral (between 2 authorities) or community agreement (between more than 2 authorities). May include service level specifications in the form of Service Level Agreements (refer to SLAs).

AIS Regional Server

(Definition from SSN IFCD)A server that a group of MSs agrees to maintain1 in accordance with the security and reliability requirements of the SSN system and to use to relay AIS data from their national SSN systems to the central SSN system. It may include data collection, storage, backup and re‐distribution, as well as monitoring the availability and quality of the data. For these functionalities, and as long as the MSs concerned request to use it as an alternative to the direct connection to the central SSN system, the AIS Regional Server will be considered to be a component of the central SSN system.

Application (Definition from the CISE Architecture Vision Document)Software designed to perform specific tasks and that exposes certain functionalities through interfaces.

Architecture (Definition from the CISE Architecture Vision Document)The structure of components, their inter‐relationships, and the principles and guidelines governing their design and evolution over time.

Architecture building blocks

(Definition from the CISE Architecture Vision Document)A constituent of the architecture model that describes a single aspect of the overall model. These elements typically describe required capability and shape the specification of Solution Building Blocks.

Authentication

(Definition from SSN IFCD)The process of determining whether someone or something is who or what it is declared to be.

Authorisation

(Definition from SSN IFCD)The process of granting access rights to a user.

Authority (or public authority)

(Definition from the CISE Architecture Vision Document)Any organisation that has an interest in maritime data. An authority can be local, regional,

national or European level.

Throughout this document, the terms authority and public authority are used interchangeably.

Broadcasting (Definition from the CISE Architecture Vision Document)


Page 7 of 72

Term Definition

A type of message distribution where a message is sent to all members, rather than specific members, of a group such as a department or enterprise.

Central SafeSeaNet system

(Definition from SSN IFCD)This comprises those SSN components (both technical and procedural) which act as the

central/nodal point for the exchange of information between national SSN systems. Such

components are the responsibility of the Commission, in close cooperation with the MSs, and

are administered by EMSA on their behalf.

Classified information

(Definition from SSN IFCD)Any information and material, an unauthorised disclosure of which could cause varying degrees of prejudice to EU interests, or to one or more of its Member States, whether such information originates within the EU or is received from Member States, third States or international organisations (in accordance with Commission Decision 2001/844/EC amending its internal Rules of Procedure by annexing Commission Provisions on Security).

Clustered system

(Definition from the CISE Architecture Vision Document)An architecture that ties together authority systems with the use of nodes. Clustering provides access to all files from any of the clustered nodes regardless of the physical location of the file.

Commercial sensitive information

(Definition from SSN IFCD)Information that is likely to prejudice the commercial interest of any person (a person may be an individual, a company, the public authority or any other legal entity).

Commissioning tests

(Definition from SSN IFCD)Tests which assess whether national SSN systems support the reliable, timely and accurate exchange of information within the SSN system (as defined in the MS Commissioning Tests Plan). The commissioning process covers all SSN messages transmitted to/from the central SSN system.

Complexity (Definition from the CISE Architecture Vision Document)The number of relationships between elements.

Acts as an information sharing barrier in technology architectures.

Confidentiality

(Definition from SSN IFCD)The process that ensures that information is not made available or disclosed to unauthorized entities.

Consignment (eMAR CRS introduced term)

“Consignment” is 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).

Correlation (of information)

(Definition from the CISE Architecture Vision Document)A function where requested information from multiple sources are analysed to determine what relationships between the information exist.

Data (Definition from the CISE Architecture Vision Document)Facts represented in a readable language (such as numbers, characters, images, or other methods of recording) on a durable medium. Data on its own carries no meaning, but when given context, data becomes information.


Page 8 of 72

Term Definition Data Set (eMAR D4.2 introduced term)

A data set defines a set of objects within the eMAR domain model that allows an abstract grouping of data elements stored in the database of an eMAR compliant application.. The content of a data set will directly reflect:

A decision of an international for a about the data elements to be included in a specific data set that should be notified within a message (e.g. the “Port call” group or the “Pre‐arrival 72 hrs notification” group as defined in the eMS data mapping)

The data elements of a web form

The data elements that are corresponding to a complex type and/ or a set of complex types defined in one of the CRS compliant formats (e.g. the complex type of ISO 28005‐2 “epc:ShipIDType” containing the information on Ship identity could be defined in the domain model of an eMAR‐compliant application as a “data set”

For each attribute linked to a data set are maintained in the database information for:

If its inclusion in the data set is mandatory or optional

If it should be visible to the user completing a form related to the dataset

If it represents a list of repeated data elements of the same type

If it is valideatable and a textual reference to the business rule rule

Data user (Definition from SSN IFCD)An authorised SSN user requesting information required by the SSN legal framework from other MSs through the SSN system.

Declaration (AnNA definition) A coherent set of data elements related to one or more “reporting formalities”

Digital Certificate

(Definition from SSN IFCD)A digitally signed statement that certifies the binding between the owner’s identity information and his/her electronic public key.

EIS European Index Server (one of the central SSN system applications)

eMS Group of experts from EU Member States dealing with maritime administrative simplification and electronic information services.

Encryption (Definition from SSN IFCD)The Cryptographic transformation of data into a form that conceals the data's original meaning to prevent it from being known or used by unauthorized entities.


Page 9 of 72

Term Definition Formality (eMAR D4.2 introduced term)

A “formality” defines a set of objects within the eMAR domain model that allows alternative groupings of data elements stored in the database of an eMAR compliant application. The content of a “formality” will directly reflect a decision of an international fora about the data elements to be forwarded to an Authority due to a legal requirement (e.g. the data element in the column A3‐DPG or B1‐FAL1 in the data mapping of eMs Group may define a “formality” set within the domain model of an eMAR compliant application . Similarly the content of a declaration defined by AnNA , e.g. PAX”, WAS or MDH may also define a formality) A formality may relate to one or more “reporting formalities “ as per the applicable legal Acts and their corresponding “declaration (s)”

To facilitate access rights enforcement, preparation of the data to be included in declarations and alerting users (in case e.g. of “overdue” declarations) the “formalities” are . grouped in the following groups:

Formality Group

(Example content of the group based on eMS declaration definitions and AnNA declaration definitions)

ShipCall MAI, NOA, NOD, ETA, ETD, COA, A1 – Port, B1 ‐ FAL1

PSC ATA, C1 ‐ PSC Arrival , ATD, C2 ‐ PSC Departure, EXP, C2 ‐ PSC 72h pre‐arrival

Security SEC, A5 – Security

Waste WAS, A4 – Waste

Border PAX, B4 ‐ FAL4, B5 ‐ FAL5 A2‐Border , B6 ‐ FAL6

Health MDH, B8 – MDH

Cargo STO, B3 ‐ FAL3, ENS, A6 – ENS, C3 ‐ eManisfest (as to be defined by DG TAXUD), C3 ‐ Arrival Notification (for Customs), B2 ‐ FAL2, SDT, C3 ‐ Summary Declaration of Temporary Storage)

Hazmat HZA, HZD, A3 – DPG,, B7 ‐ FAL7

Function (eMAR D4.2 introduced term) Function defines a set of pre‐defined actions that an Actor may execute in case he (she) is duly authorized. Examples of functions are e.g. the ”CargoConsignment_DataEntry”,” CargoConsignment_DataConsult”, etc.

Fusion (of information)

(Definition from the CISE Architecture Vision Document)A function where requested information from multiple sources are blended to form a single

response.

Fusion of data fills information gaps and can reduce the uncertainty in information received from various sources.

Gateway (Definition from the CISE Architecture Vision Document)A connection point in a network. The gateway converts information, data or other

communications from one protocol or format to another.

Implements specifications e.g. commonly agreed information exchange model, transport protocol and service interface.

Group (eMAR D4.2 introduced term) Group class in the domain model identifies a set of roles that could be allocated to an Actor


Page 10 of 72

Term Definition

High Level Steering Group on SafeSeaNet (HLSG)

(Definition from SSN IFCD)The group defined in Annex III of Directive 2002/59/EC (as amended), which comprises MS and Commission representatives, and which has the tasks defined in Commission decision 2009/584/EC of 31 July 2009. The HLSG shall: – make recommendations to improve the effectiveness and security of SafeSeaNet;

– provide appropriate guidance for the development of SafeSeaNet;

– assist the Commission in reviewing the performance of SafeSeaNet, and;

– approve the IFCD document and any amendments thereto.

Information Contextual meaning associated with, or derived from, data.

Information consumer

(Definition from the CISE Architecture Vision Document)A role assumed by a participant to facilitate interaction and connectivity in the use of services.

Information exchange model

(Definition from the CISE Architecture Vision Document)A logical representation to illustrate the structure, semantics, and relationships of information.

Information owner

(Definition from the CISE Architecture Vision Document)A user who ensures the consistency and validity of information. They define the security

needs of the information for which they are responsible.

Information ownership means identifying which participants have the right to change information, together with their obligation to determine impact and notify all impacted parties. Typically, each authority as the owner of its information may define the rules for access to its information.

Information provider

(Definition from the CISE Architecture Vision Document)A role assumed by a participant to facilitate interaction and connectivity in the exchange of information.

Information source

Authentic provenance of the information.

Integrity (Definition from SSN IFCD)The process that ensures the accuracy and completeness of information.

Interoperability

Definition from the CISE Architecture Vision Document)Interoperability, within the context of European public service delivery, is the ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems.

Interoperability agreement

(Definition from the CISE Architecture Vision Document)Means of reaching consensus on a common information sharing interface (also referred to as service interface) through which services can be offered. There are 3 different types of interoperability agreements: semantic, technical and organisational

Interoperability framework

(Definition from the CISE Architecture Vision Document)An interoperability framework is an agreed approach to interoperability for organisations that wish to work together towards the joint delivery of public services. Within its scope of applicability, it specifies a set of common elements such as vocabulary, concepts, principles, policies, guidelines, recommendations, standards, specifications and practices.

Intricacy (Definition from the CISE Architecture Vision Document)The state of containing a large number of parts or details.

Acts as an information sharing barrier in technology architectures.

License (Definition from the CISE Architecture Vision Document)A licence is a document containing provisions allowing or restricting actions and uses normally reserved for the copyright holder.


Page 11 of 72

Term Definition

Local Competent Authority (LCA)

(Definition from SSN IFCD)These are authorities or organisations designated by MSs to receive and transmit information

pursuant to the SSN legal framework (e.g. port authorities, coastal stations, Vessel Traffic

Services, shore‐based installations responsible for a mandatory ship’s routing system or a

mandatory ship reporting system approved by the IMO and bodies responsible for

coordinating search and rescue operations).

MS Member States

MSW Maritime Single Window

National Competent Authority (NCA)

(Definition from SSN IFCD)The body which assumes responsibility for a national SSN system and its management on behalf of a MS. It is responsible for the operation, verification and maintenance of the national SSN system, and for ensuring that the standards and procedures comply with the requirements described within the IFCD and with the agreed technical and operational documentation. The NCA responsibilities are defined in Annex

National SafeSeaNet system (national SSN system)

(Definition from SSN IFCD)This comprises technical and procedural SSN elements which support the provision, retrieval and use of information required to implement the SSN legal framework within an MS. These elements are the responsibility of the relevant MS and can be administered either directly by the NCA, via the establishment of LCAs or by setting up other appropriate arrangements with third parties.

Node (Definition from the CISE Architecture Vision Document)A connection point in a network that clusters authority systems or other nodes. In general, a

node has programmed or engineered capability to recognise and process (e.g. aggregate) or

forward messages to other nodes or authority systems.

Implements specifications e.g. commonly agreed information exchange model, transport protocol and service interface.

Non‐repudiation

(Definition from SSN IFCD)The process that ensures that the entities involved in a communication cannot deny having participated (e.g. sending entity cannot deny having sent a message).

Notification (eMAR definition) A coherent set of data elements related to one or more “reporting formalities” In this document the term “notification” is used as a synonym to “declaration”

NSW National Single WindowOrganisation (eMAR D4.2 introduced term)

Organisation is a class in the eMAR domain model providing details on an organization, sub‐organization, fulfilling a role in a business process.

Party (eMAR D4.2 introduced term) Party is a class in the eMAR domain containing references to the organisations or persons whose data are maintained in the eMAR application database

PCS Port Community SystemPerson (eMAR D4.2 introduced term)

A class in the domain model of eMAR providing basic information of a person

Personal Data

(Definition from SSN IFCD)Any information relating to an identified or identifiable natural living person (‘data subject’); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number.


Page 12 of 72

Term Definition Profile (Country/ Location or Voyage, message)

(eMAR D4.2 introduced term) (Country/ Location or Voyage/ message ) Profile is set of configuration parameters defining the reporting formality groups and specific reports per group applicable for reporting for the specific Country/ Location or Voyage/ message

Profile (person)

(eMAR D4.2 introduced term) Profile is a class in the domain model of eMAR defining a business process or processes executed by an Organisation or individual (“person”)

Protocol (or transport protocol)

(Definition from the CISE Architecture Vision Document)A set of procedures in information exchange that the authority systems or nodes use to send messages back and forth. Networks and systems cannot communicate unless they use the same protocol or make use of a gateway.

PSC Port State Control

PSC Directive Directive 2009/16/EC on port State control

PSW Port Single Window

Reporting formalities

(eMAR definition extending the AnNA definition) ‘Reporting formalities’ mean:

The information set out in the Annex of Directive 2010/65/EU which, in accordance with the legislation applicable in a Member State, must be provided for administrative and procedural purposes when a ship arrives in or departs from a port in that Member State

The information set out in the EU Custom Regulation which, in accordance with the legislation applicable in a Member State, must be provided for administrative and procedural purposes to Custom Authorities

Request (or information request)

(Definition from the CISE Architecture Vision Document)A message sent from an information consumer to an information provider, asking for information according to a certain criteria with the use of a common information exchange model.

Requirement (Definition from the CISE Architecture Vision Document)Determine the expectations of the stakeholders with regards to information sharing and discovery, information assurance and security, collaboration, organisation, etc.

RFD Reporting Formalities Directive A Directive of the European Commission coming into force on 1/6/2015 dealing with the reporting formalities for ships arriving in and/or departing from ports of the MSs

Role (eMAR D4.2 introduced term) Role class in the domain model identifies a set of functions that could be allocated to an Actor

Routing (Definition from the CISE Architecture Vision Document)Functionality of forwarding messages without the information consumer and provider having to know each other. Usually present in nodes and coordinators.

SafeSeaNet authority (SSN authority)

(Definition from SSN IFCD)These are authorities defined as NCAs, LCAs and EMSA, on behalf of the European Commission

for the central SSN system. This covers both “Competent authorities” and “Port authorities” as

defined in Article 3 of 2002/59/EC as amended.

SafeSeaNet system (SSN system)

(Definition from SSN IFCD)This comprises both the national and central SSN systems.

Service interface

(Definition from the CISE Architecture Vision Document)A point of access where a service is made available to another application.


Page 13 of 72

Term Definition

Service Level Agreement

(Definition from the CISE Architecture Vision Document)A service‐level agreement (SLA) is a contract between an information provider and an

information consumer that specifies, usually in measurable terms, what services the

information provider will furnish. Some metrics that SLAs may specify include:

What percentage of the time services will be available;

The number of users that can be; served simultaneously;

Specific performance benchmarks;

Help desk response time.

SOAP Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of web services in computer networks

Solution Building Block

(Definition from the CISE Architecture Vision Document)Represent the actual components that will be used to implement the required capability.

Subscription (Definition from the CISE Architecture Vision Document)An agreement between the information provider and the information consumer for providing, receiving or making use of information in a continuing or periodic nature.

UN/LOCODE (Definition from SSN IFCD)The United Nations Code for Trade and Transport Locations (UN/LOCODE) is an international,

geographical coding scheme which has been developed and maintained by the United Nations

Economic Commission for Europe (UNECE).

VAS Value adding Service

VTMIS Directive

Directive 2002/59/EC (as amended by the 2009/17/EC) establishing a Community vessel traffic monitoring and information system and repealing Council Directive 93/75/EEC

XML Extensible Markup Language (XML) is a computer language that defines a set of rules for encoding documents in a format that is both human‐readable and machine‐readable


Page 14 of 72

Executive summary This document, having as a target audience the e‐Maritime application designers, includes public

information on the following:

The eMAR‐proposed portfolio of the SSN/ NSW‐relevant applications. These are

“interoperable” web‐based applications, which could be utilized within a multi‐node B2B,

B2A and A2A environment for the collection , distribution and consultation of information

related to port and cargo clearance.

The domain model and overarching logical architecture of the proposed applications

Guiding principles and functional requirements for the core functional blocks of the

proposed applications.

Prepared by UPRC, the editors and authors of the report “eMAR D4.3 ‐ Interfacing e‐Maritime with

SSN and related developments (v2)”, this first edition of the present document is annexed as

Appendix D to D4.3. However, it is intended to be a “living” document continuously improved,

during the whole lifecycle of the eMAR project (from potential additional contributions of other

eMAR project partners). As, from one side, the work on application prototyping advances in time,

within the project and, from the other side, the situation in the regulatory domain is better clarified

(e.g. following the potential issuance of guidelines from the Commission on the eManifest content

and structure) it is to be expected that the content of the document will be further elaborated,

updated and improved in the near future.


Page 15 of 72

1 Referencedocuments

1.1 InternationalStandard/De‐factostandardsThe following documents1 be also taken into account by the application designers, depending on the

specific user requirements, as they include reference specification complementing those provided in

this document:

[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

Note: Regarding the ISO standards, in [1], [2] should be also taken into account the proposals for potential changes/ refinement of the existing specifications (reference is made to those changes stemming from the current tests of EMSA and Members states in the IMP demonstrator project).

[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]. Updates of CRS specification published by eMAR project

[6]. WCO standards adopted by AnNA project and reflected to theAnNA Message

Interface Guide.

[7]. SSN XML Reference specifications (e.g. the XML reference Guide)

[8]. (eMs and/ or EMSA issued) Guidelines for the implementation of Single

window including their data mapping references

[9]. AnNA Message Interface Guide

[10]. Guidelines on NSW implementation issued by the eMAR project

1.2 LegislativereferencesThe references here‐below constitute the principal legislative references related to the functional

requirements presented here‐in.

1.2.1 ReportingformalitiesresultingfromlegalactsoftheUnionThis category of reporting formalities includes the information that shall be provided in accordance

with the following provisions:

1. Notification for ships arriving in and departing from ports of the Member States

Article 4 of Directive 2002/59/EC of the European Parliament and of the Council of 27 June

2002 establishing a Community vessel traffic monitoring and information system (OJ L 208,

5.8.2002, p. 10).

1 Their most recent release at the time a decision is taken for the development of an application.


Page 16 of 72

2. Border checks on persons

Article 7 of Regulation (EC) No 562/2006 of the European Parliament and of the Council of

15 March 2006 establishing a Community Code on the rules governing the movement of

persons across borders (Schengen Borders Code) (OJ L 105, 13.4.2006, p. 1).

3. Notification of dangerous or polluting goods carried on board

Article 13 of Directive 2002/59/EC of the European Parliament and of the Council of 27 June

2002 establishing a Community vessel traffic monitoring and information system.

4. Notification of waste and residues

Article 6 of Directive 2000/59/EC of the European Parliament and of the Council of 27

November 2000 on port reception facilities for ship‐generated waste and cargo residues (OJ

L 332, 28.12.2000, p. 81).

5. Notification of security information

Article 6 of Regulation (EC) No 725/2004 of the European Parliament and of the Council of

31 March 2004 on enhancing ship and port facility security (OJ L 129, 29.4.2004, p. 6).

6. Entry summary declaration

Article 36a of Council Regulation (EEC) No 2913/92 of 12 October 1992 establishing the

Community Customs Code (OJ L 302, 19.10.1992, p. 1) and Article 87 of Regulation (EC) No

450/2008 of the European Parliament and of the Council of 23 April 2008 laying down the

Community Customs Code (Modernised Customs Code) (OJ L 145, 4.6.2008, p. 1).

1.2.2 FALformsandformalitiesresultingfrominternationallegalinstrumentsThis category of reporting formalities includes the information that shall be provided in accordance

with the FAL Convention and other relevant 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

1.2.3 AnyrelevantnationallegislationMember States may include in this category the information, which shall be provided in accordance

with their national legislation. Such information shall be transmitted by electronic means.


Page 17 of 72

1.2.4 EUlegislationrelatedtoeManifest

[in future releases of this Guide should be listed here the legislative references (e.g. Existing

regulations / directives that will be amended or new regulation/ directive related to the introduction

of the eManifest]

2 e‐Maritimeservicesportfolio(SSN/NSW‐related)

2.1 IntroductionThe Figure 1, in the next page, depicts the anticipated situation in the application landscape

following the launch of National single Windows in Europe (the target launch date, as per the RFD, is

mid June 2015). More specifically the following should be observed:

1. Ship representatives (ship masters/ agents/ staff at ship manager/ operator premises) and

authorized maritime carriers will provide (depending on their profile and access rights) the

notifications required for electronic port clearance and/ or customs clearance via 3 types of

“business” applications and/ or via the web interfaces offered by gateway system connected

to maritime single windows and custom offices. The business applications are:

a) An application installed at ship operator premises (provisionally identified in this

document as “Port Call planner & ship reporter” (PCPSR) application.

b) An application installed at ship agent or authorized carrier premises (provisionally

identified in this document as “ship/ cargo reporter” (SCR) application).

c) Third‐party trusted, Internet based, services offered to ship representatives

(provisionally identified in this document as “On line broker ship/ cargo reporting

services” (OSCR) application).

2. The typical type of interface between business and government application shall be a web‐

services based interface, however one may also envisage the maintenance of legacy

mechanisms used nowadays (like EDIFACT). Furthermore one should not exclude a

possibility of some EU MS allowing the submission of notifications via e‐mail.

3. The “government” application domain shall incorporate: The maritime single window (MSW)

and the eCustom applications (this might be merged in a single NSW in some MS). These

shall be built eventually either “from scratch” or shall evolve from the present legacy

systems operated by the MS. The MSWs shall provide for the reception of notification two

types of interface systems:

Built‐in gateways

Gateways hosted by port single windows, port community systems or even eCustom

compliant custom offices.

4. MSWs shall interoperate with EU systems and with systems managed operated by national

Authorities via “adaptor” applications that shall be either built‐in and/ or hosted at distinct

servers (e.g. the “SSN NCA” server.

5. In case MSWs are used by a MS as a unique centralized location for all types of maritime

reporting, they may also incorporate “Events” gateways, utilized e.g. to report incidents in

accordance with the VTMIS directive.


Page 18 of 72

Figure 1 Application landscape in Europe following the implementation of the RFD

The schema attempts to demonstrate the situation created from “contradicting” (to each other)

requirements in regards to the applicable legislation. For instance the applicable Custom code

requires the ENS to be submitted in a Custom Office (refer to the [3]). At this stage, taking into

account the present state of discussions among EU Member States in the eMS Group and other for a

(e.g. AnNA project), it cannot be envisaged with certainty if the “custom functions” (e.g. the

collection of ENS) shall be always integrated within the MSWs. Some MS may decide to integrate

these functions in the NSW but it is safer to assume at this stage that the interaction shall be realized

via a potential connection between the MSW and the “national” eCustom node. The stakeholders

acknowledge that this is not an optimum situation therefore, within the framework of the on‐going

BlueBelt initiative, one may hope for the inclusion of alternative approaches (e.g. at least an

interaction of Custom Authorities with the central SSN system). However, at the time of drafting this

report, this scenario is highly unlikely to take place in a short/ medium term (before 2018), that is

before a potential amendment to the applicable custom and/ or maritime legislation is agreed and

applied.

The schema also highlights the realistic business opportunities for new product developments (e.g.

products developed on the basis of eMAR framework and a to‐be‐modified CRS) identifying (in


Page 19 of 72

yellow colour). All these applications could be implemented by the eMAR IT partner companies, in

the short/ medium term, in supporting the application of EU legislation related to reporting

formalities.

In consideration of the aforementioned and as depicted in figure 1, eMAR project proposes the

design and implementation of the applications listed in the Table 1 below. In practical terms the

focus should be in the creation of a web‐based collaborative environment for ship managers and

their core business partners enabling:

a. Ship managers to introduce voyage information

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

The data introduce may or may not include cargo consignment information

b. Cargo consignors to introduce cargo consignment data

Been aware (or not) of the specific cargo movements (which are decided by the ship

operator)

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

clearance related formalities to MSWs

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

eManifest) or Custom Authorities

e. Maritime Authorities interact with Industry via MSWs

f. Custom Authorities interact with Industry submitting the ENS and/ or eManifest either

directly via the eCustoms application or infrastructure or via the MSWs

eMAR D4.3 ‐ Appendix D.

Page 20 of 72

3 Servicesportfolio(SSN/NSW‐related)proposedbytheeMARprojectTable 1 Portfolio of e‐Maritime services proposed by eMAR

Application family

Proposed Service / Application

2

Relevant‐maritime Domains Applicability3 Notes

eMAR Common Reporting Gateway

Ship/ Cargo Reporter

Submitting data to and from Port Electronic Data Systems

Obtaining updates to berth/terminal/port services and restrictions

Communicating with clients/ shippers/ forwarders regarding transport planning and freight monitoring

Submitting information to administrative and regulatory bodies/ authorities

Obtaining real time information on affecting ETA

Daily communication with trading partners, or logistics agents

B2B, B2A Web Client/ server application hosted customised for ship or cargo agents. It communicates with web services with business associates (ship managers, cargo consignors) and reporting nodes (port community system or MSW, Customs) in the area of operation of the company hosting the application

PortCall planner & Ship reporter

B2B, B2A Web Client/ server application hosted by a ship management company. It communicates with web services with business associates (cargo partners, ship agents) and reporting nodes (port community system or MSW, Customs) in Europe

On‐line ship/ cargo reporting services

B2B, B2A

“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. The service could be hosted by a ship operator or a service broker that will provide services to several shipping actors (managers or agents). The service broker could be a private company or a public /private partnership. . One possibility is that the service is made available by eMAR to EU MSs to be used for creating a harmonised MSW interface to industry.

EPC Gateway B2A Web client/ server application acting as a B2A front‐end for an MSW or Port single window system. It offers a web interface and a system interface

eMAR Maritime Single Window

NRI adaptor for MSWs

A2A Web client/ server application acting as A2A front‐end for an MSW enabling national maritime or custom Authorities to be notified for declarations submitted by the industry.. It offers a web interface and system interface (s) for connection to the system of each Authority

Events Gateway A2A Web client/ server application acting as A2A front‐end for an MSW or SSN NCA enabling SSN coastal Stations to submit/ consult incident reports. It offers a web interface to SSN coastal stations designated to handle incidents

SSN adaptor for maritime MSWs

A2A Web client/ server application realising a system interface between a MSW and SSN central system for submitting/ querying reporting formalities and incident reports.

2 Refer to chapter 6 3 B2B:Business2business, B2A:Business2Administation, A2A:Administration2Administration


Page 21 of 72

3.1 Common functional blocks in eMAR applications for reportingformalities

One should note that although the applications mentioned in the previous Section aim at different

user needs; they have a lot of functional commonalities. As indicated in Figure 2, the logical

structure of all the applications that could be developed on the basis of the eMAR framework would

incorporate a number of “standard” modules based on a set of business objects and relationships

between these objects. Objects and relationships should be easily adapted to meet the specific

functional requirements of each separate application or service.

Figure 2 Common functional blocks in eMAR‐ compliant applications for Business and/ or Government


Page 22 of 72

As shown in the figure, the following functional blocks, properly configured, would be present in

most of the applications implemented using the eMAR reference specifications.

epc Message transformer & interface

This module will be used for:

1. Exchange (receive from/ send to) eMAR‐compliant CRS 4 messages and/ or alternatively

(configurable) in the ISO 28005 (ship/voyage/ cargo information), AnNA and ICS‐compliant

messages (ENS for the moment)

2. Accepting messages for ship/ cargo information provided in EDIFACT and/ or XML proprietary

format s and transforming them into eMAR CRS format or a format accepted by a legacy system

interfaced with the application.

epc data entry and consultation

This module will be used as a web –based front end for authorized data providers to create / update

voyage/port call/ incident/ cargo information and submit e.g. port clearance notifications, eManifest

related notifications or ENS.

Management and configuration

This module will consist a web – based front end interface used for:

the configuration of the application/ communication methods .

the grouping of data elements in accordance with the distribution logic applicable per MS

and/ or port visited by ships.

the management of users and their profiles/ access rights .

the creation/ maintenance of reference data (vessels, locations, persons, organisations,

parties).

Vessel tracker

This module will be used for:

1. Interacting with position transponders (terrestrial or satellite AIS, LRIT, etc.) on board ships

and / or third‐party trusted vessel tracking internet‐based applications in order to receive

ship position information in real or “near real time” and record them in a ship position

database.

4 As explained in 0, the eMAR‐compliant CRS should encompass complex data types that are based (but not restricted to) on UBL data types, ISO 28000‐5 data types, WCO data types (Those to be adopted by AnNA project), SSN data types and ICS data types for ICSENS. It is modification or an extension of the CRS delivered by the eFreight project properly amended to cover ship/ cargo‐related reporting formalities


Page 23 of 72

2. Acting as one of the data processors linked to the data entry interface enabling authorized

users to calculate / plan ship routes

3. Generating warnings enabling scheduling the timely submission of ship reporting formalities.

Data processing and storage (reference data)

This module will be used for processing/ storing reference information for ship operations (e.g. ship

company, vessel/ crew, port/ port facility information) including history of changes in the reference

data.

Reference data exchange

This module will comprise a message interface enabling:

The update of the reference data maintained by the application (e.g. port locations) with

information in external reference sources.

The update of the reference data used by the application with updates in the reference data

in an external database linked with the application.

Data processing and storage (ship operations)

This module will be used for processing/ storing data concerning ship voyages/ cargo and port calls

enabling the clear distinction of information concerning the arrival and departure notification

related to a port call. The module will handle all the information required to be stored process in line

with the EU Directives.

Access control & security

This module will provide access control for the information managed by the application and secures

the transactions.

Transaction tracing and logging

This module will be used for keeping logs of all transactions (e.g. a log of all the messages exchanged

via the message interface or forms submitted via the web interface) managed by the application.

In the following section the following information is provided:

i) an outline description of functional blocks, which in the context of system architecture

could be incorporated in each of the applications identified with “yellow” colour in the

Figure 2 and, in this sense, could be considered as “common” modules; and

ii) a description of the “common” business objects that should be defined for each of the

applications identified in yellow in the Figure 2.


Page 24 of 72

3.2 Proposalonaconceptualdatamodel(Coreobjects)

Figure 3 and Table 2 below identify the core business objects proposed for the eMAR domain model.

This model would form the basis for a potential amendment of the CRS to become actually a

“container” / overarching specification incorporating a variety of standards that could be adopted by

the EU MS for their NSWs. .

3.2.1 eFreightCRSadaptationtotheeMARrequirementsGiven the current state of practice, it is strongly recommended that an adaptation of the CRS is

undertaken. CRS should effectively “encompass” the capability to support the exchange of port or

cargo formalities in “unison” (i.e. consignments created/ updated during the insertion of a voyage/

port call in the database of the application) and/ or “independently using two totally independent

workflows, each one “unaware of the other).

In this sense an amended CRS could not be based on the exchange of a single type of “CRS” message

as it was envisaged by the eFreight project but, instead, it should enable the transmission /

reception and interpretation of messages that are provided in a variety of formats and may be

exchanged as part of a maritime reporting (MRF) formalities workflow or as parts of “Customs”

formalities workflow

In this respect the eMAR_CRS should:

1. Include data types that could be mapped to the existing standards or de‐facto standards

identified in the chapter 4. As a general rule the design of maritime formalities related data

types (excluding those that are related to custom clearance) in the CRS would be based on

ISO standard 28005‐2, while the custom related data types definition would be based on

ICS/ DDNIA. The WCO/ EDIFACT/ SSN data types would be directly or directly mapped into

the eMAR domain model and in the eMAR_CRS.

2. The following messages (and the associated operations related to the messages) should be

included in the eMAR_CRS protocol and associated XSD and WSDL files.

3.2.1.1 ISO28005relevantmessages

MRFNotification ( ISO ClearanceRequest)/ MRFNCancel (ISO cancel) / MRFNReceipt

(ISO Receipt)/ MRFNAck (ISO Ack) / MRFNComment (ISO comment)

3.2.1.2 ICSrelevantmessages

crs315/ crs318/ crs328/ crs313/ crs304/ crs305/ crs351/ crs318/ crs302/ crs303/

crs325/ crs324/ crs323 (relevant to the IE315/ IE318/

IE328/IE313/IE304/IE305/IE351/IE318/IE302/IE303/IE325/IE324/IE323)

AnNA messages

crsMAI, crsNOA, crsCOA, crsETA,crsATA,crsNOD, crsEXP, crsSEC, crsWAS, crsPAX,

crsMDH, crsSTO, crsENS, crsSDT, crsHZA, crsHZD equivalent to the declarations

included in the B2MSW message framework). In addition the messages (based on

definitions still under definition by AnNA) completing the framework (e.g. the


Page 25 of 72

eManifest‐related and the message with response to data provider confirming the

receipt or failure in the submission of the declaration and the messages to be

established for communication between the MSW (maritime single window) and the

Authorities for dissemination of the information received from the data providers),

should be included.

3.2.1.3 «Custom» messages to be used for complementary data exchange betweeneMAR_CRS‐compliantbusinessapplications

crsConsignment (will be an extension of IE315 )

crsManifest (will be an XML representation of EDIFACT CUSCAR including the

additional information to be required for the eManifest)

crsVoyageIDrequest (used by the Reporter@ship or Reporter@Agent l applications

to request the voyage reference number from the Reporter@ShipOperator

application)

crsVoyageIDresponse (used by the Reporter@ShipOperator to provide the response)

crsVoyageListUpdates (used by the Reporter@ShipOperator to provide the updates

to the new ship voyages created in the Reporter@ShipOperator during a

configurable period, e.g. the last hour)

crsPortCallInformationUpdate (used by the Reporter@Agent or Reporter@Ship to

provide updates of a shipcall to ensure synchronization with the data kept at

Reporter@ShipOperator)

3.2.1.4 SSNreferencemessages

crsPortPlus_Not/ crsMS2SSNShipCall_Req/ crsSSN2MSShipCall_Res/

crsSSN2MSShipCall_Req/ crsMS2SSNShipCall_Res/ crsIncidentDetail_Not/

crsIncidentReport_Req/ crsIncidentReport_Res/ crsSSNReceip

3.2.1.5 «Custom» messages to be used for complementary data exchange betweeneMAR_CRS‐compliant Authority applications and eMAR_CRS‐compliant singlewindows5

crsPortAuthorityNotice/ crsBorderAthorityNotice/ crsDPGnotice / crsWasteNotice/

crsSecurityNotice/ crsPSCArrivalNotice/ crsPSC DepartureNotice/

crsPSC72hprearrivalNotice/ crsAuthorityReceipt

3.2.2 eMARdomainmodel–Coreobjects

The figure 3 and table 2 here‐after are not intended to provide an exhaustive list of the objects that

need to be introduced in the eMAR data model but only those which relate to core functions of the

applications modules identified in section 3.1

5 For these are required, for consultation, the definitions to be introduced by AnNA for MSWtoAuthority messages


Page 26 of 72

Figure 3 Logical model for eMAR applications/ Core business objects


Page 27 of 72

Table 2 Core business concepts for eMAR applications for ship/ cargo reporting formalities

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). This class could be associated to the Person class, if there is a need to maintain the personal information of a passenger for re‐use

Consignment

“Consignment” is class referring to 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).

A Boolean attribute ““IsDelivered” would indicate if the good items of a consignment have been unloaded to the unloading port of the consignment.

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

Based on its content the Custom message consignment could be instantiated as an entry summary declaration (ENS) for goods of Non‐Union status 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, If one crew member possesses both cigarettes and alcohol, the list contain two entries with the same Crew member Reference


Page 28 of 72


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

Although, based on the current state of discussions it appears that the manifest provided to Authorities shall be always submitted on the arrival of a ship in the port, the proposed model envisages the options for registering in the application of eManifest. For the purposes of this document an eManifest could be instantiated as: Cargo manifest consolidating information on all consignments on board during a voyage eManifest consolidating information on all consignments left for Temporary Storage in a port eManifest consolidating information on all consignments to be unloaded at a port on arrival. eManifest consolidating information on all consignments loaded on board on departure from a port

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

Depending on its content the IR report could be configured a a pollution notifying report, a ”situation” report, a feedback report, etc.in line with the definitions within the XML RG v.07.Provides Information for the health condition of persons and animals on board the ship.

Item A class describing an item of trade

Interfaces in thus sense are the web interfaces made a available by an application to its users as well as the system2system interface between two applications. It includes a generic description applicable to all examples of the item together with optional subsidiary descriptions of any number of actual instances of the type

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


Page 29 of 72


MRF message

A class providing the identification elements of a message exchanged between two applications. The message shall contain information related to ship reporting formalities for a given port Call

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

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.

This class could be associated to the Person class, if there is a need to maintain the personal information of a passenger for re‐use

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 Main Ship certificates that are used are: Registration Certificate, Security Certificate and Health Certificate.

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 the eMAR 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


Page 30 of 72


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

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.


Page 31 of 72

4 FunctionalrequirementsapplicableonthecommonmodulesoftheeMARapplications

4.1 epcMessagetransformer&interface

INTER_1

To support the exchange of messages with external applications in a variety of formats, in the database of the eMAR application shall be defined:

1. The Access components (see definition in the section “definitions and abbreviations”) that an Actor shall use to interact with external applications. The information to be stored shall be include all the required data to define the interface with the external application. The following should be defined:

a. protocol to be used ‐ e.g. ISO 28005‐2, SSN, CRS, etc.), b. security‐related tokens if any, c. information provider and information requestor urls

2. The data sets (refer to the relevant definition in “abbreviations/ definitions section) mapping the message content for each protocol supported by the module.

3. The reporting formalities potentially exchanged using a specific access component

The implementation of an access component shall allow the association of an XSD file to each access component An access component should be linked to one only family of standards (e.g. AnNA , ISO,ICS, etc.)

4.1.1 Requirements specific to eMAR Common Reporting Gateway (CRG)applications

INTER_2

Each message notification provided by a CRG node to a Port or single Window may contain the data element specific to one or more “formalities” (see relevant definition). The structure of the message will comply with the data exchange protocol specified by the NSW for the declaration (s) reported.

INTER_3 The message submission workflow will comply with the applicable message exchange Guide adopted by the NSW

INTER_4

The CRG application shall enable authorised consignors or their representatives (including the carrier) to submit the following type of cargo eManifest:

i. “Arrival” (or voyage) eManifest Cargo manifest consolidating information on all consignments on board during a voyage until ship arrival to the Port of Call of the voyage It includes and/ or refers to (depending on the processing rules included in 1.2.4) those consignments from previous voyages


Page 32 of 72

remaining on board upon ship departure for the voyage, those loaded at voyage’s departure port and, those loaded during ship to ship operations, if any, during the voyage.

ii. “Departure” eManifest

Cargo manifest consolidating information on all consignments on board for her next voyage The departure manifest includes and/ or refers to (depending on the processing rules included in 1.2.4) all the consignments that were carried by the ship during her voyage which were not unloaded in the Port of Call plus those loaded to the ship in the Port of Call of the voyage.

iii. Declaration of temporary storage

Cargo manifest consolidating information on all consignments carried on board during the voyage but unloaded to the port of Call for temporary storage.

For supporting the notification of dangerous cargo on board (in line with the applicable legal acts) shall be possible to extract from the above manifests (i) or (ii) the information related to dangerous goods and include them in the declarations of dangerous cargo required by the Maritime Authorities.

INTER_5

Subject to the specific guidelines from an operator of a national or port single window, the arrival eManifest could be submitted:

1. In a single modular message before the arrival of a ship to an EU port by an authorized reporting party, or

2. In a set of “eManifest” declarations, each declaration sent by consignors or their representatives.

The CRG application should support both ways of submission.

INTER_6 The information (data elements) to be included in an eManifest is “protocol”‐specific. For the minimum requirements (applicable for all protocols) refer to the section 1.2.4. The structure of the eManifest will allow distinguishing the specific consignments included in the declaration. Each consignment will be identified by its UCR and, if applicable, the MRN of the ENS provided before the loading of the consignment at the loading port.

INTER_7 The custom messages proposed in 3.2.1.3 could be utilised to pull or push data from an existing ERP (Enterprise resource planning) systems of ship operators or cargo consignors


Page 33 of 72

4.2 epcdataentryandconsultation

WEB_1 Web forms shall be implemented for all the functions requiring human computer interaction in support of a business process (e.g. preparation of a notification).

WEB_2

The content of each web form used to create/ update data in the database or to prepare an message shall be mapped to a data set in the database. The visibility of a specific web form field or its optionality shall be based in the definitions of the corresponding data set and the business rules that are applicable.

WEB_3

The main form utilized by users to interact with the application shall be a “dashboard” form whose design shall depend on the operational goals served by the eMAR application. For “Dashboard” form mock‐ups refer to the following:

In the Figure 4 is provided an example wireframe for the dashboard to be made available for the “Port Call planner “ship reporter” application and in the figure 5 a mock‐up of this application based on the i‐ship reporting application prototype. The wireframe clarifies the anticipated content for each sector in the dashboard

In figure 6 is provided a mock‐up of a dashboard application for a ship Agent interface utilising the Ship/ Cargo reporter application. The dashboard shall allow o Selection (highlight) of a port from those the user is authorised to

submit notifications. o Indication on the dashboard of the Expected/ Planned arrivals,

Recent departures, Recently arrived ships for selected port. o If a user will highlight a different port the views will change

accordingly. o If a user will select a ship, the application will pick up the current

voyage of the vessel and, depending to its status (Refer to PROCOP_13_Voyage11) will fill the relevant screens.

In figure 7 is provided a mock‐up of the dashboard application for Maritime Authorities provided by an MSW o Clearance status shows to all the Authorities the results of

“clearance process” by other authorities too. Authorities will only be able to update the status of notifications for which they are authorized to provide clearance. The three sections of the dashboard split the notifications on the basis of the function an authority shall execute (e.g. the Security clearance Authority will see in the pending approval section of the dashboard only those notifications that still lack the authority approval)

o A message will be sent back to the ship only in case the clearance model adopted by the MSW allows it.

o Notifications could be filtered in the dashboard based on the following conditions. “Arrived?” filter identifies notifications for port calls for which at

the time of application of the filter (the “system time) the ATA is available (or in case of ATA absence ETA Port of Call “is in the past” with respect to the system time) , there is no record of ATD and the ETD Port of Call is still in the future with respect to the system time).

Expected? identifies notifications for port calls for which at the


Page 34 of 72

time of application of the filter (the “system time) ATA is not yet registered and the ETA is still in the future with respect to system time (that is with reference to PROCOP_13_Voyage11 the port calls to be considered here are those related to voyages with status “on‐going” or “expected?” or “planned”)

“Completed?” identifies notifications for port calls for which at the time of application of the filter (the “system time) the ATD Port of Call is available (registered in the system) or in case of absence of ATD, the ETA/ ATA and ETD Port of call is “in the past” with respect to the system time”.

o Default view (upon login) will show only the notifications concerning the ports related to the Authority user. Pending will be sorted on the bases of “nearest ETA to “Now” for the expected?, “nearest ATA to Now” for the “Arrived?”, “nearest ETD/ATD in the past to Now” for the “completed?

o If the users will choose to show notifications following a search for ships or ports the notification views will be amended accordingly. Search for ports and Ships will allow multi choice (more than one ships and ports). Port and ship criteria could be “combined” (AND relation). Filtering could be made on the basis of notifications in “Arrived? Status, Expected? Status, Completed? Status

WEB_4

The application configuration shall allow the creation of visual warning in the dashboard (or eMail alerts) to warn users to take a required action. The visual warnings shall be formality group specific (refer to formality group definition in the definitions section) and shall allow the presentation of the following warnings: In CRG dashboards for ship/ cargo representatives:

1. “Notification submission overdue” concerning formalities whose

submission is already due.

2. “Notification submission time approaching” concerning formalities

whose submission deadline is due in a configurable timestamp e.g.

within the next 3 hours.

3. “Notification submission pending but still adequate time to submit”

concerning formalities whose submission deadline is still in the

future.

4. “All required notifications concerning the formality were

submitted” concerning formalities for which all the required

information was made available to the Authorities for clearance

decision

5. “Authority requests more information” concerning formalities for

which the clearance Authority requested additional or updated

data

6. “Clearance Given” concerning formalities for which the clearance

Authority granted clearance

7. “Clearance denied” concerning formalities for which the clearance

Authority denied clearance

In MSW dashboards for Authorities:


Page 35 of 72

1. “Authority requests more information” concerning formalities for

which the clearance Authority requested additional or updated

data

2. “Clearance Given” concerning formalities for which the clearance

Authority granted clearance

3. “Clearance denied” concerning formalities for which the clearance

Authority denied clearance

4. “Clearance Approval pending” concerning formalities for which the

clearance decision is pending

WEB_5

All the “search fields made available in the web interface should allow “contextual” search, that is search based on more than one attribute concerning the data searched. That is in case of a location search , the search could be based on LOCODE, name of the Location. In case of a ship could be based on her IMO, MMSI, ShipName, CallSign.

WEB_6

In the CRG family of applications, the design of the web forms shall allow grouping the data in an user‐friendly and ergonomic manner allowing the creation /update/ submission of all the data related to ship / cargo reporting formalities..). Each of the forms shall be related to a “data set” (refer to definitions). The content of the web‐form data sets and the optionality or not of the fields shall be configurable taking into consideration the requirements of the MSW (s) interfaced with the CRG application Indicative mock‐ups of forms (from i‐ship reporting application) are provided in the figures 8 to 13.

WEB_7

When the user creates a voyage in the web interface, he (she) should always identify her "previous one. In this respect, the system will propose to the user a list of the voyages with ETA PortOfCall / ATA Port of Call "in the past" with respect to the ETA Port of Call of the voyage that is created and the Port of Call of the voyages shown in the list will be the departure port of the voyage under creation. The voyages in the list to be presented will be sorted according to their ATA Port of Call (or in case of absence) ETA Port of Call with the one with "closest" ATA/ ETA with the to‐be‐created voyage ETA. In case there are no voyages for the ship in the database of the CRG the previous voyage entry will not be required. A button "create previous voyage" should be made available and would allow the opening of a pop‐up in order to enable the creation of the previous voyage

WEB_8

(With reference to INTER_4 and cargo rules in the section 4.6) The CRG application shall enable authorised consignors or their representatives (including the carrier) to: 1. Create a consignments and link shipment stages to it. In this respect in a

distinct section of the web interface will be made available a data entry form for introducing consignment information.

2. Update consignment information. In this respect in a distinct section of the web interface will be made available a “consignment” dashboard, providing the following groupings (lists) of consignment data already entered in the system:


Page 36 of 72

i) “All” consignmentsii) Unassigned consignments without a shipment stage assigned iii) Scheduled consignments for voyages in “on‐going” /

“expected?” status‐ iv) Scheduled consignments for voyages with status “at port” or

“arrived?” v) Consignments already marked as “Delivered” vi) Unassigned Consignments will shipments stages “in the past”

(all the shipment stages assigned to the consignments have an ATAShipmentStage or ETAShipmentStage “in the past” compared with the timestamp of the query creating the “dashboard” lists

vii) Planned consignments 3. Create/ update the arrival eManifest as part of the voyage data entry

workflow. 4. Create/ update the arrival / departure eManifest and relevant

declarations of dangerous cargo or declarations of temporary storage as part of the arrival/ departure notification process respectively

5. Up‐load cargo eManifest or relevant declarations Information using the templates defined in 1.1 ([8] to [10])

WEB_9

The web application would enable users to create/ update messages concerning:

1. Reporting formalities relevant to port / cargo clearance procedures prior to/ at ship entry to a port(“arrival” notification)

2. Reporting formalities relevant to port / cargo clearance procedures prior related to ship exit from a port (“departure” notification)

The following restrictions apply

a. If an arrival notification already exists for a voyage a user may execute update actions on it (including a potential cancellation). He (she) may not create another arrival notification for the same voyage except if a previously created arrival notification for the voyage has been cancelled.

b. If a departure notification already exists for a voyage a user may execute update actions on it (including a cancellation). He (she) may not create another arrival notification for the same voyage except if the departure notification has been cancelled.

In case of cancellation of a Port‐Call, all the information available for the Call could be re‐used except those defining time of departure/ arrival times and Port Call information associated to the cancelled call

WEB_10

With reference to PROCOP_2, appropriate web forms will be made available allowing authorised users to define a “voyage profile” referring to:

a. The specific formalities binding for the voyage, b. The associated alerting thresholds related to the submission of the

formalities included in the voyage profile c. The applicable exemptions for the voyage (indicating the

formalities on which the ship is obliged to make information available on request but there is no obligation to include such


Page 37 of 72

information in the notifications submitted to Authorities) The “voyage profile” is a customisation of the formalities profile applicable for the Port of Call location of the voyage taking into account the specific regulations binding for the ship (e.g. based on the specific cargo the ship carries for the voyage or the ship type, etc)

WEB_11

During the message creation (arrival or departure notification workflow) the user authorised to submit the notification may consult the formalities’ profile of the voyage and choose the specific reporting formalities to be reported within a specific message. Based on the choices made by the user and referring to the forms in WEB_6, the application shall adapt the content (data fields) to be presented (for data entry or update) to the user in line with the business rules applicable for the formalities to be submitted.


Page 38 of 72

Notifications log

Voyages pending reporting

Ships with no recent precise schedule

Color codes (notification/ Voyage windows): Red (additional info must be sent – reporting threshold as per call profile violated), Yellow (threshold due to expire),Green (no violation of reporting threshold), Blue (all required data as per reporting profile were submitted

Figure 4 Wire‐frame of the dashboard for the Port Call planner & ship reporter application

Notification Type (Arrival, Departure), Ship, Voyage Reference No, Call Identification, ETA/ATA PortOfCall, ETD/ATDPort of Call, Shape‐

based codes showing reporting formalities already fulfilled, Shaped based codes showing reporting formalities pending, Clearance status

(based on colour codes), checking button for e‐mail warning

Initially Sorted by Color code, then by ETA/ ATAPortOfCall, then by port , then by Notification Type (departure / arrival). Each column

should allow users changing the sorting .

Voyage refer number, Last Port, Port of Call, ETA/ ATA

PortOfCall

Initially Sorted by Color code, then by ETA/ ATAPortOfCall,

then by port , then by ship

Also a “create new voyage” button should be included

here

Ship IMO, MMSI, CALL, SIGN , Name , flag (icon)

+magnifier icon to open Ship details page

Sorted by ship name

For users with relevant access write a create Ship button

shall be presented too


Page 39 of 72

Figure 5 Mock‐up of the dashboard based on i‐Ship reporting prototype implementation of a the Port Call planner & ship reporter application


Page 40 of 72

Figure 6 Mock‐up of the dashboard to be used by a Ship Agent using the Ship/ Cargo Reporter application


Page 41 of 72

Figure 7 Mock‐up of the dashboard to be used by Authorities using an MSW application


Page 42 of 72

Figure 8 Mock‐up of web‐forms allowing the data entry/ submission of the data related to the ShipCall/ PSC formality group(s) (1/2)


Page 43 of 72

Figure 9 Mock‐up of web‐forms allowing the data entry/ submission of the data related to the ShipCall/ PSC formality group(s) (2/2)


Page 44 of 72

Figure 10 Mock‐up of web‐form allowing the data entry/ submission of the data related to the security formality group


Page 45 of 72

Figure 11 Mock‐up of web‐form allowing the data entry/ submission of the data related to the waste formality group


Page 46 of 72

Figure 12 Mock‐ups of web‐forms allowing the data entry/ submission of the data related to the border formality group


Page 47 of 72

Figure 13 Mock‐up of web‐form allowing the data entry/ submission of the data related to the Health formality group


Page 48 of 72

Figure 14 Mock‐up of web‐form allowing the data entry/ submission of the data related to the cargo/ Hazmat formality groups


Page 49 of 72

4.3 Managementandconfiguration

CONF_1

Each eMAR application shall include a set of web forms (each one corresponding to a data set stored in the database) to allow the execution of administration functions by authorized administrators. The following generic configuration applies (to be customized for each specific eMAR application) • User Management

Create Organisation

Create Person

Create Actor (possible sub‐tabs “ clone” existing, “manual” creation)

Create Role (possible sub‐tabs “ clone” existing, “manual” creation

Create Group

Search/Update Organisation

Search/Update Person

Search/Update Actor

Search/Update Group

Search/Update Role • Location Management

Upload UNECE Location

Upload port facility information

Create Location/ Port facility

Search/Update Location/ Port Facility • Area Management

Create IntArea

Create SeaArea

Create Country/ MID

Create County

Search/Update IntArea

Search/Update Country/ MID

Search/Update County • Vessel Management

Create Vessel

Search/Update Vessel • Application management

Notification/ application parameters

Dataset/ Formality management

System Monitoring

Web Users Activity Monitoring

Logs Search Logs (structured and free text search)

CONF_1

With respect to PROCOP_2, web forms shall be made available for creating/ updating the default formality and alerting threshold profile for a country and/ or location. An indicative mock‐up for Port profile configuration form is included in the figure 15 below


Page 50 of 72

Figure 15 Mock‐up of port profile configuration form


Page 51 of 72

4.4 Dataprocessingandstorage(referencedata)

PROCREF_1 UNECE database of LOCODES shall be utilized for the initial population with date of the LOCODE tables of the eMAR application

PROCREF_2 IMO GISI database shall be the source of the codes used for port facilities

PROCREF_3 Equasis, LLI and HIS databases could be utilized for vessel information

4.5 Referencedataexchange

REFEX_1

The on line access to external databases for verification / validation purposes should be performed using the service that the external reference data provider shall provide. In this respect, within the eMAR application, the relevant access component and the corresponding data sets shall be defined. The verification/ validation procedure (against the reference data ) shall be based on the business rules included in the SLA with the external service provider

4.6 Dataprocessingandstorage(shipoperations)

PROCOP_1

All the validations executed to the data elements exchanged with external applications shall be based to:

(As minimum requirement) To the business rules agreed by the MS as drawn within the relevant eMS Group documents and the eMS Group data mapping

(as specific requirement) To the rules applicable for the specific message/ protocol (e.g. for the data elements in SSN Portplus , the data validations shall be based on the XML reference Guide v3.0 )

PROCOP_2

To streamline the submission of reporting formalities and the

enforcement of business rules and the avoidance of business validation

errors during notification submission, the application design should

enable the creation of “formality and alert thresholds” profiles

(maintained in the database).

These profiles will indicate

1 At Country level: a. Which reporting formality groups (e.g. Ship Call, PSC, Hazmat,

Border, etc.) are generally required for ships visiting the ports of a

Country and which are the specific formalities (e.g. A1_Port, MAI,

etc.) required to be submitted for each group.

b. Which are the alerting thresholds, if applicable, associated to

each reporting formality. A threshold would provide an indication

of specific timing requirements associated to a formality (e.g. the


Page 52 of 72

threshold for the security notifications is 24h before ETA to Port

of Call, as this is the requirement imposed by the national /

international legal Acts).

2 At specific port location level: a. Which reporting formality groups are specifically required for

ships visiting the port of a Country and which are the specific

formalities among those defined in the Country profile required

to be submitted in this particular port.

b. Which are the alerting thresholds, if applicable, associated to

each reporting formality required by the local Authorities.

3 At specific voyage level: a. Which are the binding reporting formalities for the specific

voyage (e.g. based on the ship type and specific cargo for the

voyage) taking into account the national/ international

regulations.

b. Which are the exemptions, if any, applicable for the specific

voyage of the ship. An exemption refers to specific formalities on

which the ship is obliged to make information available on

request. However there is no obligation to include exempted

information in the notifications submitted to Authorities).


PROCOP_3_Vogage1

Acceptable values for the departure Port of a voyage, the destination port of it, the arrival port of the next voyage and the departure port of the previous voyage are:l

1. ZZUKN (Unknown designation). 2. A “waypoint” 5‐digit LOCODE (“XZ…”) defining a location at

open sea. 3. An unspecified port in a Country ([ISO CountryCode]888,

i.e GR888, IT888). 4. A specific port location defined by its 5‐digit LOCODE.

PROCOP_4_Vogage2

1. Every voyage should be linked to zero or more waypoint objects and zero or more PortCall objects.

2. A voyage should be linked at least to one PortCall or waypoint object unless the destination of the voyage is set to ZZUKN

3. Inside the voyage database, at a given time, only one voyage for a given ship may have unknown destination.

4. If more than one PortCall records are linked to the voyage only one record at the time shall have the “Cancelled” attribute set to FALSE. This call is the “Active” call for the voyage

Taking into consideration the above when a voyage record is


Page 53 of 72

created in the CRG database, a PortCall or a waypoint record should be created too (unless the destination of the voyage is set to ZZUKN)..

PROCOP_5_Vogage3

In case of cancellation of Port call linked to a voyage a new Port Call record should be created for the new destination unless the new destination is unknown. The PortOfArrival information and arrival/ departure information associated to it (estimated or actual) must be automatically updated in the voyage record as soon as the active call of the ship will change.

PROCOP_6_Vogage4 The fields carrying estimated and actual information on times of arrival departure can be “Null”

PROCOP_7_Vogage5 In case the destination of the voyage is set to ZZUKN the relevant ETAPortOfCall is set to Null automatically

PROCOP_8_Vogage6

ZZUKN is not allowed as the value for the PortOfCall attribute in the PortCall object. The PortOfCall value can be:

1. An unspecified port in a Country ([ISO CountryCode]888, i.e GR888, IT888)

2. A specific port location defined by its 5‐digir LOCODE

PROCOP_9_Vogage7

A voyage can be linked as “shipment stage” to zero to many consignments During the creation or the update of the association of a voyage to a shipment stage the user should also indicate if the shipment stage is completed or is on‐going. The status of shipment stages associated to voyages for which an ATAPortOfCall is registered will be automatically updated to “Completed”

PROCOP_10_Vogage8 Entry Key of the Port Call should be given the format to be approved by AnNA

PROCOP_11_Vogage9 In case a Port Call is cancelled and at least an declaration message has been provided for it, a cancelation message should be sent to the Authority responsible for the changed Port.

PROCOP_12_Vogage10 To ensure that cargo consignments can be linked to voyages reliably, the PortOfDeparture information for a voyage should be always provided when a voyage is created.

PROCOP_13_Voyage11

(Determination of the “current” ship voyage at query timestamp). At the timestamp (datetime) of executing a query to the system database (timestamp being the current system time or a timestamp set “in the past” or “in the future” with respect to the system time), the application would allow identifying if a voyage is:

1. “Completed” meaning that the ATD from Port of Call of the voyage is set in the past with respect to the query timestamp;

2. “Completed?” meaning that the ETA Port of Call (or ATA


Page 54 of 72

Port of Call and ETD Port of call, if available) is “in the past” with respect to the query time

3. “On‐going” meaning that the ATD from the departure port of the voyage is set in the past with respect to the query timestamp and the ETA Port of Call is available and still in the future with respect to the query time stamp. In the case that more than one voyage in the database meet the “ETA Port of Call is “in the future” condition” the on‐going voyage is the one with the ETA Port of Call “closest” in the future, with respect to the query time stamp ,

4. “At port” meaning that the ATA Port of Call of the voyage is set in the past with respect to the query timestamp while the ATD Port of Call is not available or , if it is available, it is set in the “future” with respect to the query timestamp

5. “Arrived?” meaning that the ETA Port of Call “is in the past” with respect to the query timestamp, there is still no record of ATA, ATD and the ETD Port of Call is still in the future with respect to the query timestamp

6. “Expected?” meaning that the ETD Port or departure is in the past with respect to the query time and the ETA Port of Call is still in the future with respect to query timestamp.

7. “Planned” meaning that the ATD departure port , if available, or the ETD departure port (in case of no registration of the ATD departure) is in the “future” with respect to the query timestamp,. Furthermore the ETA Port of call is available and set in the future with respect to the query timestamp

The current voyage of the ship at query timestamp is a voyage meeting the condition 3 or 4 above. If there is no voyage meeting the conditions 3 or 4, the current voyage is the one, among the voyages meeting the “arrived?” condition or the “Expected?” condition whose ETA Port of call is the closest in time (in the past or future) to the query time stamp

PROCOP_14_Cargo1

The UCR of a consignment of the consignment and should be always quoted upon data entry.

To facilitate tracing good movements, the application would allow splitting a consignment in parts transported under different transport reference. There cannot exist more than one records in the consignment registry in the database having the same UCR+TransporDocumentID+PlaceOfDicharge combination.

The TransportDocumentID associated to a consignment used for the transportation of a consignment should be always quoted as soon as consignment is assigned at least one shipment stage.

PROCOP_15_Cargo2 Shipment stage in the CRG will describes one stage of

movement of a consignment .


Page 55 of 72

A shipment stage is always linked to a single means of transport (i.e. a ship)

A voyage can be identified as the shipment stage of many different consignments.

Boolean indicators in the Shipment Stage object ( Label “Completed”, “Current”), regularly updated (via user actions or via database jobs) shall indicate if a shipment stage is among those already concluded or if it is the “on‐going” shipment stage or if it is a still expected ship stage (for “future shipment stages both Boolean indicators mentioned above have value “false”)

An additional Boolean indicator (Label “Discharge”) will be used to identify the completed shipment stage during which the discharge of goods from the ship took place.

A shipment stage registered in the system should have either a voyage associated to it or has at least the ETAshipmentStage and ShipmentStageArrivalLocation defined .

PROCOP_16_Cargo3

Ship voyages registered in the system can be linked to cargo consignments as “shipment stages”

If a voyage is linked to a shipment stage the ETAshipmentStage is derived automatically by the ETAtoPortOfCall of the voyage and the ShipmentStageArrivalLocation from the PortOfArrival of the voyage

PROCOP_17_Cargo4

1 For each consignment shall be always possible to identify in the database: a. One or more “Completed” shipment stage (s)” for which

the associated voyage (via ship/ rail/ road) is “Completed” or “Completed?” or “at port” (refer to the PROCOP_13_Voyage11)

b. An “current” shipment stage for which the associated voyage (via ship/ rail/ road) is “On‐going” or “Expected?” (refer to the PROCOP_12_Voyage11).

c. The shipment stage during which the discharge of goods took place from the means of transport. For this shipment stage both “Discharge” and “Completed” indicators become “TRUE”

d. The planned shipment stages (linked with voyages with “planned” status at query time

2 The application shall allow:

The amendment of the status of shipment stages via the web‐interface

The automatic change of the status of shipment stages by a scheduled automatic check at configurable time period (e.g. every hour).

3 Upon manual introduction of the data for the shipment stage

of a consignment, the user may introduce/ update the ATAShipmentStage and ATD Shipment stage fields . This action would result to an amendment of the ATA/ ATD Port of Call


Page 56 of 72

field for the voyage linked to the shipment stage only in the event that the ATA/ ATD Port of Call fields for the voyage are “null” except if the user introducing the cargo data have the appropriate access rights to amend the PSC formality group data for the voyage.

In the case that the user has the access right to amend the PSC information, the application should prompt the user to submit the relevant declaration to the Maritime Authorities.

PROCOP_18_Cargo5

“Unassigned” is a consignment registered in the system for which, at the time of query action, the “on‐going” shipment stage is not known. All the following conditions apply (at query datetime):

1. “IsDelivered” attribute for the consignment is FALSE 2. The consignment has no shipment stage linked to it, or the

shipment stage (s) associated to it are registered in the system as “completed” shipment stage(s)

3. There is no shipment stage associated with the consignment with the “Discharge” indicator set to TRUE.

“Planned” is a consignment registered in the system for which, at the time of query action, all the shipment stage assigned to it are still “planned”. All the following conditions apply (at query datetime):

1. “IsDelivered” attribute for the consignment is FALSE 2. The consignment has no shipment stages assigned to it

where the ETD from departure port for the voyage linked to the shipment stage is “in the future” with respect to the query time.

3. There is no shipment stage associated with the consignment with the “Discharge” indicator set to TRUE.

PROCOP_19_Cargo6

“Delivered” is a consignment for which the “Discharge” shipment stage is known. The following conditions apply.

1. “IsDelivered” attribute in the consignments table in the database is set to TRUE,

2. The PlaceOfDischarge location for the items linked to the consignment is not NULL and equal with the ShipmentStageArrivalLocation of the shipment stage linked to the consignment during which the discharge took place.

PROCOP_20_Cargo7 “Scheduled” is consignment for which, at query time, the “on‐going” shipment stage is known and the “IsDelivered” attribute of the consignment is FALSE.

PROCOP_21_Cargo8

1 IsDelivered attribute can be set to TRUE for a consignment only after the ATAshipmentStage is registered in the system for the on‐going stage of a consignment.

2 In this respect, when the “discharge” indication of the


Page 57 of 72

shipment stage of a consignment is set to TRUE, the application should prompt the user to include the ATAshipmentStage (in case the ATAshipmentStage for the shipment stage of discharge is null).

PROCOP_22_Cargo9 At least one consignment should be defined for each “shipment stage” registered in the system

PROCOP_23_Cargo10

On consignment record creation/ update, the user may link to consignments one or more shipment stages indicating their status.

On consignment record update, the user may assign a new “on‐going” shipment stage to the consignment. This automatically will update the status indicator of the previously assigned as on‐going to “Completed” and prompt user to introduce the

PROCOP_24_Cargo11

(These rules are applied only when the user prepares the arrival eManifest for a voyage during the voyage data creation/ update or during the submission of a notification of reporting / cargo formalities related to the entry of a ship to a port) 1. When users prepare the arrival manifest for a voyage the system will fetch with a query for potential use: a. All the consignments for which the voyage is already linked

as shipment stage. b. The Unassigned consignments with at least one or more

completed shipment stage where at least one of the completed shipment stages is associated to the “previous” voyage of the ship (the one prior to voyage A).

c. Unassigned consignments without any shipment stage associations

The lists presented to the user as per point 1a,b,c above include only those consignments conforming with the access right permissions of the user (i.e. a consignor cannot access data of consignments of other consignors, if he (she) is not granted the access right.

2. The consignments that are part of the list as per bullet point (a) will be already “pre‐selected” to be included in the eManifest. However If an error is detected (i.e. the user detects an erroneous assignment of the consignment to the ship or her voyage or he (she) detects an erroneous consignment status code) the user will be given the option to alter the amend the consignment/ shipment stage information and even remove the consignment from the ship cargo. He will also be given the option to assign additional shipment stages for the consignments even if these shipment stages refer to different transport means.

3. The user shall be given the option to create new consignments and link them to the eManifest.

4. In the event that the arrival manifest concerns a voyage (A) whose status, at the time of data entry, is “on‐going” or “expected?” all the consignments included in the eManifest shall be identified as “scheduled” for the Voyage (A).

5. In the event that the arrival manifest concerns a voyage (A)


Page 58 of 72

whose status, at the time of data entry, is “at port”/ “arrived?”or “completed”/”completed?” the user will be given the possibility to identify the consignments that were unloaded to the Port of Call. In this case the rules in PROCOP_21_Cargo8 are applicable.

6. In the event of introduction of the data of a new consignment during the arrival manifest creation for a voyage (A) whose status, at the time of data entry, is “planned”, the system shall not allow the identification of the consignment as “completed” or “scheduled”.

PROCOP_25_Cargo12

(These rules are applied only when the eManifest completion is done during the creation of a departure notification of the voyage by an authorized user ) 1. When a user creates the departure eManifest for the Port Call

of Voyage A (for the cargo remaining on board ship after the unloading operations at the Port of Call of voyage A as well as for the cargo loaded for the next voyage “B”) the application will fetch for potential use: a. The remaining scheduled consignments for voyage “A”

(those not marked as delivered to the arrival port of voyage A), if any.

b. All the consignments for which the “next” voyage B is already linked as shipment stage.

c. Unassigned consignments with at least one completed shipment stage where at least one of the completed shipment stages is associated to the voyage A

d. Unassigned consignments without any shipment stage associations.

e. Planned consignments where at least one shipment stage refers to future voyages of the ship having as departure port the Port of Call of Voyage A.

2. The consignments that are part of the list as per bullet points

(a), (b) will be already “selected to be included in the departure eManifest. However If an error is detected (i.e. the user detects an erroneous assignment of the consignment to the ship or her voyage B or he (she) detects an erroneous consignment status code) the user will be given the option to alter the amend the consignment/ shipment stage information and even remove the consignment from the ship cargo. He will also be given the option to assign additional shipment stages for the consignments even if these shipment stages refer to different transport means.

3. The user shall be given the option to create new consignments, link them to the eManifest and assign the voyage B (not the A) as shipment stage to the consignment

4. For the consignments to be selected from the lists as per 1b or 1c , following the completion of the cargo assignment to the voyage, the voyage (B) will be linked to the consignment as shipment stage.


Page 59 of 72

5. If at the moment of the submission of the departure notification the status of voyage (A) is “at port”/ arrived? or the voyage (B) has already started (status for the voyage B is “on‐going” or “expected?” according to the rules PROCOP_13_Voyage11 ) all the consignments included in the departure eManifest will be given the status “scheduled” (for Voyage B)

PROCOP_26_Voyage12

An arrival notification for a voyage cannot be submitted if the period configured in the management console of the application (i.e 24 hours after the ATA Port of Call) (or the ETA Port of call in case of non‐registration of ATA) is elapsed.

PROCOP_27_Voyage13

A departure notification for a voyage cannot be submitted if the period configured in the management console of the application (i.e 24 hours after the ATD Port of Call) (or the ETD Port of call in case of non‐registration of ATD) is elapsed.

PROCOP_28_Cargo13

During the creation/ update of an arrival eManifest a user may already indicate which consignments are candidate to be unloaded for temporary storage at the port of Call of the voyage. The data concerning consignments to be unloaded for temporary storage shall be automatically included in a “Declaration of temporary storage” which may be subsequently submitted to the authorities according to the applicable national rules, at times defined by the applicable national rules (refer e.g. to the rules defined by AnNA project in 1.1[9]). In the event that the submission of the Declaration for temporary storage is done after the arrival of the ship to the Port of discharge of the goods , the system will check, prior to the submission of the declaration if all the consignments included in the declaration of the temporary storage are marked as “delivered” (isDelivered indicator value is set to TRUE). If not will prompt the user to check / amend the isDelivered status. Consignments not finally discharged should be removed from the declaration.

PROCOP_29_Cargo14

Whenever, upon consignment data update, a shipment stage is removed from a consignment and for the voyage associated to the shipment stage a eManifest declaration (arrival and/ or departure) has been registered in the system , the application should warn the user that the eManifest declaration will be amended accordingly . In the event that notifications has been already submitted to authorities related to the eManifest (s) amended (i.e. a notification on arrival/ departure on cargo, dangerous cargo, temporary storage) has been already submitted) the application should also prompt the user to re‐submit the relevant declarations. The re=submission will be made only if the user will choose so and only within the time constraints defined in PROCOP_26_Voyage12 and/ or PROCOP_27_Voyage13.


Page 60 of 72

4.7 Vesseltracker


TRACKER_1 The system should keep a record (geographical coordinates) of all the ship positions captured by the transponder device (s) (satellite or terrestrial) interfaced with the tracker application.

TRACKER_2 A Geographical information system (GIS) – based web interface will be implemented allowing the identification of the latest ship position on the map.

TRACKER_3

The icon representing the ship position of the ship will also give visual indications on the following:

Whether the ship is carrying dangerous cargo

Which is the ship type in accordance with the classification of ship types applicable for AIS transponder devices

Which is course of the ship

If any special condition is applicable (e.g. banning or detention, etc.)

TRACKER_4

On receipt of new ship positions, the application should identify the “current“ voyage of the vessel at position timestamp (for determining the current voyage refer to PROCOP_13_Voyage11).

1. Upon user “hovering” over the icon displaying the ship position on the GIS interface, the system would display the visual warnings associated to the notifications submitted to as well as (configurable) a ship identifier (i.e. IMO or MMSI or Ship Name) and information of ship flag, speed and/ or course. See mock‐up next

2. Upon single‐click on the icon representing the ship position, the GIS interface would display apart from the alert warnings additional information concerning the ship and its voyage. Sources for the information displayed would be the data transmitted by the ship transponder or the basic Port Call information associated to the Ship Call formality Group (e.g. departure/ arrival port, ETA/ ETD information). See mock‐up.


Page 61 of 72

TRACKER_5

Via the pop‐up window presented to user on single clicking, the user be provided access to the following: 1. The user dashboard (refer to 4.2) 2. A tab embedded in the tracker web application providing detailed

information on the ship 3. A tab embedded in the tracker web application providing detailed

information on the recently completed (last 10 voyages), the current and the planned voyages of the ship. For each ship call presented in this tab, visual warnings shall be provided associated to the latest notification provided for the voyage. A mock‐up of the way port arrival/ departures could be presented in this tab is provided below.

4. A tab embedded in the tracker web application providing detailed

information on the Port of Call for the current voyages. This tab would provide information on recent arrivals, departures and expected arrivals (similar sub‐forms as in figure 6 above). A mock‐up is provided below for reference below


Page 62 of 72

4.8 Transactiontracing&logging

LOG_X

Logging must serve the purpose of audit trail of transactions. Notification Logs need to be available, and searchable. The XML content of messages related to a transaction will be stored in the database.


Page 63 of 72

4.9 Accesscontrol&security

ACS_1 When a function is granted to an Actor as part of a role assigned to an actor, the function could be restricted in the way identified in the Table 4 below.

ACS_2 An indicative list of functions that are to be supported by the eMAR application (depending on their operational scope) is include below in the Table 5

ACS_3 Table 3 provides a list of roles that could be allowed for an Actor based on their business profile (this profile is created when the information related the Organisation or Person information for the Actor is stored in the database). Within a role there will be grouped functions that a user have permissions to execute. Table 6 provides an example of the way functions are to be associated to the LocalCallReporter role (the basic role for a “ship agent”) and the VoyagePlanner role (a basic role for ship management companies’ staff)

ACS_4 Each actor shall be long to a Group. Within each group the application Administrator may group a number of roles.

ACS_5 When functions are assigned to a role a default set of permissions is defined for the function (the default restrictions are defined in the Table 5. When however the role is assigned to an Actor the administrator may change the set of restrictions associated to the function.

ACS_6 The way restrictions applicable for a function are enforced (AND or OR relationship) is configurable by the administrator when a role is created


Page 64 of 72

Table 3 Roles that could be assigned to an Actor based on their business profile

Functional Role6 Description Comment

Agriculture authority Competent authority for Agriculture

Admittance of agricultural products.

Clearance authority Competent authority for vessel clearance.

Entry/exit clearances of vessels before entry/exit to/from territorial areas, ports, etc. The clearance process may also involve coordination with other authorities.

Customs authority Competent authority for the cross‐border movement of goods

Levying of duties and taxes on imported goods. Control over the export and import of goods such as control over prohibited goods and security purposes.

Defense authority Competent authority for defense.

Protection of the territorial waters against foreign armed forces.

Health authority Competent authority for public health.

Entry of people or objects that may cause a health risk.

Immigration authority Competent authority for immigration.

Enforcement of regulations and laws applicable to persons requesting entry to a country or territory.

Policing authority Competent authority for policing.

Enforcement of civil law applicable to vessels and their presence in territorial waters.

Port State inspection authority

Competent authority for the inspection of ships visiting ports.

Port State inspection (of coastal State). Inspection of certificates, adherence to safety regulations and testing of safety and other equipment.

Registry authority Competent authority for ship registry (flag State).

Establishment and maintenance of ship registry. Issues certificate of registry.

SAR authority Competent authority for search and rescue (SAR).

Responsible for the SAR policy for an area and for bilateral agreements on SAR regions.

6 For the roles related to Authorities see FAL.5/Circ.36 (9 November 2011) “Guidelines for setting up a single window system in maritime transport”


Page 65 of 72


Safe working inspection authority

Competent authority for the use of equipment.

Responsible for rules and regulations on how equipment is used in relation to transport, loading, unloading and trans‐shipment.

Safe working procedures authority

Competent authority for healthy and safe work procedures.

Responsible for rules and regulations on how work related to transport, loading, unloading and transhipment is executed.

Safety authority Competent authority for safety at sea.

Responsible for emergency response and the final decisions on how to handle emergencies or incidents, e.g. decisions on place of refuge to be used.

Security authority Competent authority for security.

Ship inspection authority

Competent authority for ship inspections and the implementation of IMO and national rules on flag State ships.

Flag State inspection (of flag State).Inspection of certificates, adherence to safety regulations and testing of safety and other equipment.

Statistics authority Competent authority for statistics and systematic collection of data and facts.

Veterinary authority Competent authority for animals (dead or alive).

Entry/exit of animals and animal products.

Environmental authority Competent authority for environmental protection.

Protection and preservation of the marine environment and marine species.

Waste authority Competent authority for compliance with legislation on waste.

Monitoring and reporting of waste disposals from ships (according to legislation on waste). Compliance with legislation on waste.

Pollution response authority Competent authority with respect to pollution.

The establishment of rules and regulations with respect to pollution control.

Local security authority Competent authority with respect to security in ports.

Enforcement of ISPS Code.

Local safety authority Competent authority with respect to nautical safety in local areas.

Needs information about dangerous goods, use of port facilities, etc.


Page 66 of 72


VTMS authority

Competent authority for the definitions of vessel traffic management system (VTMS) areas and for the regulations concerning these areas. Also responsible for the enforcement of laws and regulations for transport and maritime traffic.

Knowledge of the position of vessels in the territorial waters. Establishment of regulations for transport and maritime traffic. Enforcement of laws and regulations for transport and maritime traffic.

Ship representatives roles (indicative)

VoyagePlanner, Call Reporter

(Global) , Ship Master,

Company Security Officer, Call

Reporter (National), Call

Reporter (Local),

Cargo partners roles (indicative)

Cargo Administrator, Authorised Consignor, Registered Carrier CargoAgent

Application Administrator roles (indicative)

ApplAdmin,

SystemAdministrator,

CompanyAdministrator,

FleetAdministrator


Page 67 of 72

Table 4 Access Right types

Restriction Note

AccessComponent The function assigned to an actor is restricted by the Access Components related to the Actor

Fleet The function assigned to an actor is restricted by the ships related to the Actor (ref table ActorFleet)

Company The function assigned to an actor is restricted to all the ships operated by the Company he (she) works and/ or represent (ref ActorCompany table)

SeaArea The function assigned to an actor is restricted by the Sear Areas related to the Actor (ref table ActorSeaArea)

IntArea The function assigned to an actor is restricted by the International Areas related to the Actor (ref table ActorInternationalArea)

Country The function assigned to an actor is restricted to all the locations of the countries related to the actor (ref: ActorCountry table)

County The function assigned to an actor is restricted to all the locations of the Counties related to the actor (ref: ActorCounty table)

Location The function assigned to an actor is restricted actor is restricted to all the locations of the Counties related to the actor (ref: ActorCounty table)

Flag The function assigned to an actor is restricted to all the ships carrying specific flags (ref table ActorFlag)

PSCOffice The function assigned to an actor is restricted to the port locations belonging to specific PSCOffice

Actor (Use only for “delegation” type of functions. It designates the actor that will execute an operation “on behalf” of another actor

Formality The action to be taken based on a function where this restriction applies relates to specify formality from those listed in the formality table.

None No restriction applicable.

“0wn” Applicable for some functions to indicate that an actor has the right to edit/ change information that he (she) owns or he (she) provided

ISO28005 Defines the data transmission protocol as based on ISO28005 messages

B2MSW Defines the data transmission protocol as based on B2MSV messages

ICS Defines the data transmission protocol as based on DG TAXUD ICS messages

EDIFACT Defines the data transmission protocol as based on EDIFACT messages

CRS Defines the data transmission protocol as based on eMAR CRS messages

SSN Defines the data transmission protocol as based on SSN messages (based on SSN XML reference guide)

ISRG Restriction relates to users accessing the ISRG (business actors)

IE IE restriction to actors accessing IE functions (Maritime Authorities, Businesses)


Page 68 of 72

Table 5 Functions and their default set of restrictions (indicative)

Function name Description Applicable restrictions (default at

function level)

Actor_management Manage actor accounts. None,ISRG, IE

Role_management Manage role definition. None

Group_management Manage group definition None

Function_management Assign/ Edit default restrictions associated to a function None

AccessComponent_Manageme

nt

Create/ Update Access components and assign protocol, end points and security

tokens

None, Location, NonSSN, SSN

DataSet_definition Manage (create/ update/ delete) datasets for the application to support marhalling ,

unmarhalling of messages and define data to be inserted in forms

None

TransportMeans_management Manage transport means (including ships, road vehicles, train/ wagon) definition. None, Company, Flag

OrganisationPerson_managem

ent

Manage organization/ person definition None, Company, Flag

PersonalData_management Manage the personal information and credential of an Actor that is a “person” None,ISRG (Intelligent Ship

Reporting Gateway), IE

(Information Exchange), Own

LocationPortFacility_managem

ent

Manage single location definition. None, Country, County, Location.

Country_management Manage country definition None

Area_management Manage definition of areas (county, IntArea, SeaArea, etc.) None

VoyageShipCall_Data_Entry Permission to insert (create/ update, delete) information related to shipment

stages/ voyages. Shipcalls/ voyage itineraries via the web interface of the application

None, Fleet, Country, Location

VoyageShipCall_Data_Consult Permission to consult information related to shipment stages/ voyages. Shipcalls/

voyage itineraries via the web interface of the application

None, Fleet, Company, IntArea,

Country, County, Location, Flag


Page 69 of 72


function level)

CargoConsignment_DataEntry Permission to insert (create/ update, delete) information related to cargo

consignments via the web interface of the application

None, Fleet, Company

CargoConsignment_CRFmessag

eDataConsult

Permission to consult information related to cargo consignments via the web

interface of the application

None, Fleet, Company, Location,

IntArea, Country, County,

Dataprovider (OR with the other

given)

Formality_provision Permission enabling an actor to provide information contained in the specific data‐

groups related to the formality assigned here

None, Fleet, Company, IntArea,

Country, County, Location, Flag,

Formality (group)

Formality_consultation Permission enabling an actor to consult information contained in the specific data‐

groups related to the formality assigned here

None, Fleet, Company, SeaArea,


Location, Flag, PSCOffice,

Formality, Dataprovider (OR with

the other given)

Clearance Permission to provide approval or denial of clearance for the specific formality

related to the function

None,IntArea, Country, County,

Location, Formality (All, ShipCall,

PSC, Security, Waste, Border ,

Health, Cargo , Hazmat)

DelegationTo_enable If the delegation_enable function is assigned to a user , then the MRF or custom

message exchange with an external application will be made utilizing the relevant

AccessComponent associated to the Actor defined for the delegationTo_ enable

function

ActorAccessComponent, Actor,

Waypoint_definition None

Tracker_ShipPosition_Visualisat Enables Ship position visualization on a map None, Fleet, Company, SeaArea


Page 70 of 72


function level)

ion

Tracker_PointOrShapeVisualisat

ion

Enables a point or a shape object visualization on a map None, Own, Common

DataExchangeProtocol Defines the protocol to be used for exchanging messages ISO28005, B2MSW, ICS, EDIFACT,

CRS, SSN, country, intArea

Passenger_DataEntry Enable users granted the function to identify a person as crew member None, Fleet, Company, SeaArea

Tracker_FormalitySubmissionW

arnings_Visualisation

None, Fleet, Company, SeaArea,


Location, Flag, PSCOffice,

Formality, Dataprovider (OR with

the other given)

VessellBanning Permission allowing a user to change the “banning” status of a vessel in vessel

management

None

VessellDetention Permission allowing a user to change the “Detention” status of a vessel in vessel

management

None

Crew_DataEntry Enable users granted the function to identify a person as crew member None, Country, County, Location

Customise_Dashboard_Thresho

lds

Enables customizing default thresholds for specific MRF notifications None


Page 71 of 72

Table 6 Functions for the LocalCallReporter (ShipAgent) and VoyagePlanner roles (indicative)

Applicable Restrictions ( default at function level)

Loca

lCal

lRe

po

rte

r

Vo

yage

Pla

nn

er

None, Fleet, Company, Location, IntArea, Country, County, Dataprovider

CargoConsignment_CRFmessageDataConsult

Location OR DataProvider None

None, Fleet, Company

CargoConsignment_DataEntry None None

None, Country, County, Location

Crew_DataEntry

Fleet Fleet

None Define_Dashboard_Thresholds Fleet Fleet

None DataSet_definition

None, Own Customise_Dashboard_Thresholds Own Own

AccessComponent, Actor

DelegationTo_enable AccessComponent, Actor

AccessComponent, Actor

None, Fleet, Company, SeaArea, IntArea, Country, County, Location, Flag, PSCOffice, Formality, Dataprovider

Formality_Dataconsult

Fleet, Location, Formality (All)

Fleet, Formality (All)

None, Fleet, Company, IntArea, Country, County, Location, Flag, Formality

Formality_provision (submit formality) Fleet, Company, County, Location, Formality (All)

Function

Ro

le


Page 72 of 72

Applicable Restrictions ( default at function level)

Loca

lCal

lRe

po

rter

Vo

yage

Pla

nn

er

None, Fleet, Company, SeaArea

Passenger_DataEntry Fleet Fleet

None,ISRG (Intelligent Ship Reporting Gateway), IE (Information Exchange), Own

PersonalData_management

Own Own

None, Own, Common

Tracker_PointOrShapeVisualisation None, Fleet None, Fleet

None, Fleet, Company, SeaArea

Tracker_ShipPosition_Visualisation None, Fleet None, Fleet

None, Fleet, Company, SeaArea, IntArea, Country, County, Location, Flag, PSCOffice, Formality, Dataprovider (OR with the other given)

Tracker_FormalitySubmissionWarnings_Visualisation

Fleet, Location, Formality (All)

Fleet, Formality (All)

None, fleet, Country, Location

VoyageShipCall_Data_Entry (Create/ update voyage/ shipcall without submitting)

None, fleet, Country, Location

None Waypoint_definition None

Function

Ro

le

Guide for the implementation of SSN/ NSW – related ...emarproject.eu/uploadfiles/D4.3 Appendix...

Documents

Transcript of Guide for the implementation of SSN/ NSW – related ...emarproject.eu/uploadfiles/D4.3 Appendix...