guide for the implementation of ssn/ nsw – related ...emarproject.eu/uploadfiles/d4.3 appendix...
Post on 22-Mar-2018
217 Views
Preview:
TRANSCRIPT
Page 1 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
Page 2 of 72
This eMAR report is licenced under a Creative Commons licence
Attribution-NonCommercial-ShareAlike 4.0 International
eMAR D4.3 ‐ Appendix D
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.6.1 Requirements specific to eMAR Common Reporting Gateway (CRG) applications ........................ 52
4.7 VESSEL TRACKER ................................................................................................................................... 60
4.7.1 Requirements specific to eMAR Common Reporting Gateway (CRG) applications ........................ 60
4.8 TRANSACTION TRACING & LOGGING .......................................................................................................... 62
4.9 ACCESS CONTROL & SECURITY .................................................................................................................. 63
eMAR D4.3 ‐ Appendix D
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
FIGURE 11 MOCK-UP OF WEB-FORM ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO THE
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
FIGURE 13 MOCK-UP OF WEB-FORM ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO THE
HEALTH FORMALITY GROUP ........................................................................................................... 47
FIGURE 14 MOCK-UP OF WEB-FORM ALLOWING THE DATA ENTRY/ SUBMISSION OF THE DATA RELATED TO THE
CARGO/ HAZMAT FORMALITY GROUPS ............................................................................................ 48
FIGURE 15 MOCK-UP OF PORT PROFILE CONFIGURATION FORM ................................................................ 50
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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)
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
Page 26 of 72
Figure 3 Logical model for eMAR applications/ Core business objects
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
Page 28 of 72
Object Purpose/ Definition Notes
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
eMAR D4.3 ‐ Appendix D
Page 29 of 72
Object Purpose/ Definition Notes
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
eMAR D4.3 ‐ Appendix D
Page 30 of 72
Object Purpose/ Definition Notes
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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:
eMAR D4.3 ‐ Appendix D
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:
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
Page 40 of 72
Figure 6 Mock‐up of the dashboard to be used by a Ship Agent using the Ship/ Cargo Reporter application
eMAR D4.3 ‐ Appendix D
Page 41 of 72
Figure 7 Mock‐up of the dashboard to be used by Authorities using an MSW application
eMAR D4.3 ‐ Appendix D
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)
eMAR D4.3 ‐ Appendix D
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)
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
Page 50 of 72
Figure 15 Mock‐up of port profile configuration form
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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).
4.6.1 Requirements specific to eMAR Common Reporting Gateway (CRG)applications
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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 .
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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)
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
Page 60 of 72
4.7 Vesseltracker
4.7.1 Requirements specific to eMAR Common Reporting Gateway (CRG)applications
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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.
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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”
eMAR D4.3 ‐ Appendix D
Page 65 of 72
Functional Role6 Description Comment
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.
eMAR D4.3 ‐ Appendix D
Page 66 of 72
Functional Role6 Description Comment
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
eMAR D4.3 ‐ Appendix D
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)
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
Page 69 of 72
Function name Description Applicable restrictions (default at
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,
IntArea, Country, County,
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
eMAR D4.3 ‐ Appendix D
Page 70 of 72
Function name Description Applicable restrictions (default at
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,
IntArea, Country, County,
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
eMAR D4.3 ‐ Appendix D
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
eMAR D4.3 ‐ Appendix D
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
top related