D2.2 Connectivity and Information Management

(1)

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

D2.2

Connectivity

and

Information

Management

Due date of deliverable: 28/02/2014 Actual submission date: 03/02/2014 Start date of project: 01/02/2012 Duration: 36M Organisation name of lead contractor for this deliverable: eBOS Technologies Ltd Revision : Final

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

(2007‐2013)

Dissemination Level

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

Commission Services)

(2)

(3)

(4)

Contents EXECUTIVE SUMMARY ... 5 GLOSSARY ... 8 1 INTRODUCTION ... 9 1.1 Overview of the D2.2 Deliverable ... 10 1.2 Objectives of the D2.2 Deliverable ... 12

2 THE EMAR SYSTEM ARCHITECTURE ... 13

2.1 E‐Maritime Systems Framework (EMSF) ... 13

2.2 eMAR Technology Ecosystem ... 14

2.3 eMAR Architecture Layers ... 15

3 EMAR CONNECTIVITY ARCHITECTURE AND MESSAGE EXCHANGE ... 18

3.1 Connectivity Architecture Overview ... 18

3.2 eMAR Message Exchange Focus Areas ... 19

3.3 Challenges to e‐Maritime Message Exchange ... 22

3.4 eMAR Connectivity Services ... 23

3.5 eMAR Connectivity Standard Models ... 23

4 EMAR ACCESS POINTS ... 25

4.1 Overview ... 25

4.2 Exchange Security: ... 25

4.3 Quality and Reliability ... 26

4.4 Ownership of Information ... 27

5. THE EMAR API LIBRARY ... 28

5.1 Port Operations ... 29 5.2 Transport Logistics ... 32 5.3 Third Party Digital Services ... 34 5.4 Ship Operations ... 37 6 CONCLUSION ... 39 7 REFERENCES ... 40

APPENDIX A – EMAR API LIBRARY ... 41

APPENDIX B ‐ EMAR ACCESS POINTS ... 67

B.2 The Service Metadata Locator and Service Metadata Publishing ... 68 B.3 Process Identifier ... 68 B.4 The Lightweight Message Exchange Profile ... 69 B.5 Secure Trusted Asynchronous Reliable Transport (START) ... 71 B.6 eMAR Access Points: Component View ... 73 B.7 eMAR Access Points: Business View ... 75 B.8 eMAR Access Points: Message Channels ... 76

(5)

Document Summary Information

Authors and contributors

Initial Name Organisation Role

SC Dr SteliosChristofi eBOS Author

AT Aaron Trant eBOS Author

PC Phanos Christofi eBOS Author

RP Ritsa Pitta eBOS Author

CK Charalambos Koptides eBOS Author

ML Maria Lambrou ILS Contributing Author

ZP Zissis Palaskas ILS Contributing Author

GK Gerasimos Kouloumbis CLMS Contributing Author

Revision history

Revision Date Who Comment

Final V1 03/02/14 RP Final release

Quality control

Role Who Date

Quality manager JTP 03/02/2014 Project manager JG 03/02/2014 Technical manager TK 03/02/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.

(6)

Executive Summary

The present document delivers the work carried out in the task T2.2 “Connectivity and

Information Management Services”, which focus on the implementation of eMAR software

platform APIs (ST2.2.1).

This document provides a description of the eMAR software Ecosystem, the principle of Access

Points and how the eMAR Project will integrate and enhance Information Management tools

according to the eMAR architecture. Moreover, it presents a comprehensive description

regarding several operations related with Maritime domain and how these functionalities can

be used from business users and what are the benefits in terms of cost and efficiency. The

outputs from this task will feed D2.5 with standardization requirements for communication

security and common information sharing.

(7)

List of Tables Figure 1.1: eMAR Connectivity Architecture Overview ... 11 Figure 2.1: eMAR system to service publication / access through Ecosystem Architecture ... 15 Figure 2.2: eMAR Architecture Layers ... 16 Figure 3.1: eMAR Connectivity of Stakeholders though the Ecosystem, using Access Points ... 18 Table 3.1: Message exchange areas for logistics chain ... 20 Table 3.2: Message exchange areas for ship operations ... 20 Table 3.3: Port reporting messages ... 22 Table 5.1: Method Parameters ... 28 Table 5.2: Method Reponse ... 28 Table 5.3: Method Response Errors ... 29 Table 5.4: Method Return Values ... 29 Figure 5.1: Port Operations in eMAR Ecosystem ... 29 Table 5.5: PCS Operations for Login and Administration Services ... 30 Table 5.6: PCS opearations for terminal instruction services ... 31 Figure 5.2: Transport Logistics Operations in eMAR Ecosystem ... 32 Table 5.7: Operations for Transport Logistics ... 33 Table 5.8: Operations for eRecruitment ... 34 Figure 5.3: eMAR eRecruitment as part of Crew Management ... 35 Table 5.9: Operations for Maritime Financials ... 36 Figure 5.4: Ship Operations in eMAR Ecosystem ... 37 Table 5.10: Operations for Ship Operations ... 38 Table A.1.1: Login Parameters ... 41 Table A.1.2: Login Response ... 41 Table A.1.3: Login Response Errors ... 42 Table A.1.4: Login Return Value ... 42 Table A.1.5: Check Session Parameters ... 43 Table A.1.6: Check Session Response ... 43 Table A.1.7: Check Session Response Error ... 44 Table A.1.8: Change Password Parameters ... 44 Table A.1.9: Change Password Response ... 44 Table A.1.10: Change Password Response Errors ... 45 Table A.2.1: Get TVA Model Equipment Parameters ... 45 Table A.2.2: Get TVA Model Equipment Response ... 45 Table A.2.3: Get TVA Model Equipment Response Errors ... 46 Table A.2.4: Get TVA Model Equipment Return Value ... 47 Table A.2.5: Search Equipments Parameters ... 48 Table A.2.6: Search Equipments Response ... 48 Table A.2.7: Search Equipments Response Errors ... 49 Table A.2.8: Search Equipments Return Value ... 49 Table A.2.9: Save Equipment List Document Parameters ... 50

(8)

Table A.2.10: Save Equipment List Document Response ... 51 Table A.2.11: Save Equipment List Document Response Errors ... 51 Table A.2.12: Save Equipment List Document Return Value ... 51 Table A.3.1: Tracking & Tracing Services Parameters ... 54 Table A.3.2: Tracking & Tracing Services Response ... 54 Table A.3.3: Tracking & Tracing Services Response Errors ... 54 Table A.3.4: Tracking & Tracing Services Return Value ... 55 Table A.4.1: Find Candidates Crew Applications Parameters ... 56 Table A.4.2: Find Candidates Crew Applications Response ... 56 Table A.4.3: Find Candidates Crew Applications Response Errors ... 57 Table A.4.4: Find Candidates Crew Applications Return Value ... 57 Table A.4.5: Find Recruitment Requests ‐ Parameters ... 58 Table A.4.6: Find Recruitment Requests ‐ Response ... 58 Table A.4.7: Find Recruitment Requests – Response Errors ... 59 Table A.4.8: Find Recruitment Requests – Return Value ... 59 Table A.5.1: Maritime Accounting and M.I.S. Parameters ... 61 Table A.5.2: Maritime Accounting and M.I.S. Response ... 61 Table A.5.3: Maritime Accounting and M.I.S. Response Errors ... 61 Table A.5.4: Budgeting System Parameters ... 61 Table A.5.5: Budgeting System Response ... 62 Table A.5.6: Budgeting System Response Errors ... 62 Table A.5.7: Payment Module Parameters ... 62 Table A.5.8: Payment Module Response ... 62 Table A.5.9: Payment Module Response Errors ... 63 Table A.6.1: Ship Status Parameters ... 63 Table A.6.2: Ship Status Response ... 63 Table A.6.3: Ship Status Response Errors ... 64 Table A.6.4: Parameters ... 64 Table A.6.5: Ship Status Response ... 64 Table A.6.6: Ship Status Response Errors ... 65 Table A.6.7: Cargo Details Parameters ... 65 Table A.6.8: Cargo Details Response ... 65 Table A.6.9: Cargo Details Response Errors ... 66 Figure B.1: Endpoint lookup with SMP and SML ... 68 Figure B.2: The Lightweight Message Exchange [5] ... 70 Figure B.3: The START Transport Protocol [3] ... 73 Figure B.4: Tiered Component Diagram of the Access Point ... 74 Figure B.5: Business view of Access Point ... 75 Figure B.6: Participant sending a message for delivery (Operations on OutMC) ... 76

(9)

List of Figures Figure 1.1: eMAR Connectivity Architecture Overview ... 11 Figure 2.1: eMAR system to service publication / access through Ecosystem Architecture ... 15 Figure 2.2: eMAR Architecture Layers ... 16 Figure 3.1: eMAR Connectivity of Stakeholders though the Ecosystem, using Access Points ... 18 Figure 5.1: Port Operations in eMAR Ecosystem ... 29 Figure 5.2: Transport Logistics Operations in eMAR Ecosystem ... 32 Figure 5.3: eMAR eRecruitment as part of Crew Management ... 35 Figure 5.4: Ship Operations in eMAR Ecosystem ... 37 Figure B.1: Endpoint lookup with SMP and SML ... 68 Figure B.2: The Lightweight Message Exchange [5] ... 70 Figure B.3: The START Transport Protocol [3] ... 73 Figure B.4: Tiered Component Diagram of the Access Point ... 74 Figure B.5: Business view of Access Point ... 75 Figure B.6: Participant sending a message for delivery (Operations on OutMC) ... 76

Glossary

Maritime Stakeholders All the involved parties in the maritime industry: Shipping

Companies, Shipping Agencies, Port Authorities, etc.

Maritime Logistics Chain All successive steps comprising a logistic‐process in maritime

industry.

Ecosystem A System of interconnecting and interacting parts.

Information Sharing The exchange of data between a sender and a receiver.

API An Application Programming Interface (API) specifies how some

software components interact with each other.

Web Service A web service is a software function provided at a network

address and allows the communication between two electronic

devices over a network.

Access Point A software function that enables the communication between

electronic devices by providing a single connection point for

controlled and secured access to information and services.

(10)

1

Introduction

The eMAR project has been established to design solutions and define standards that will

enable the participation of the European Maritime public, business and research community

stakeholders in a knowledge sharing and economic development process. By exploiting existing

technologies and components, it will support the implementation of the e‐Maritime Strategic

Framework which will provide a common understanding and interpretation of the e‐Maritime

concept along with a coherent view of the way Maritime Transport could operate in future. The eMAR Ecosystem and the enabling eMAR conceptual architecture are the key contributors

to the above goals as they allow different stakeholder groups to convert their existing systems

into services that can be combined in innovative solutions and facilitating exchange information in a trusted and efficient way. Furthermore, eMAR will demonstrate how a distributed Maritime

information management system could be developed using in the main, existing technologies.

This solution will greatly increase the interoperability between the different Maritime

stakeholders, applications and services and so eMAR has reviewed communication strategies as part of its architectural blueprint.

eMAR aims at integrating a wide range of services in order to cover the main operations

performed in the Maritime community. This includes multi‐stakeholder, multifaceted strategic, economic, security, environmental and information technology perspectives. In this way eMAR

will demonstrate how the Maritime industry can deal more effectively with Maritime threats

and opportunities, in particular by promoting open innovation based on service‐oriented

methodologies and software technology. Hence, eMAR addresses changes in the rationale and

power balance underpinning Maritime governance and emerging e‐Maritime business models. Specifically, eMAR enhances the EU e‐Maritime Programme by providing:

1. The e‐Maritime Strategic Framework (EMSF) facilitates the achievement of the mission

and strategic goals specified by a multi‐stakeholder orientated process and the relevant eMAR empirical testing/market surveys. This can be done by specifying a coherent view of the way Maritime Transport could operate at a future date (i.e. 2020). EMSF aims also

at utilizing internet based solutions to support the development of an efficient and

sustainable waterborne transport system fully integrated throughout Europe.

Additionally through the EMSF, different performance imperatives will be addressed

such as quality, flexibility, transparency and innovation in order to meet European

economic, social and safety, security and environmental needs.

2. A secure low cost connectivity infrastructure in order to empower the European

Maritime sector in offering efficient quality shipping services fully integrated in the

overall European transport system.

3. A wide range of common digital resources which can be used in several of forms such as

data, knowledge, applications, and optimizations services. This will also assist the

execution of key activities of the EMSF framework which can be combined and used

(11)

Apart from the above background, another significant purpose of eMAR is to develop and empirically test, the vision of the e‐Maritime Ecosystem in an integrated, holistic and coherent

manner. This can be done by addressing and challenging the prevailing Maritime governance

structures. The eMAR project will simulate various policy and strategic cases by utilising the

eMAR integrated e‐Maritime strategic framework and IT Ecosystem. Thus the eMAR Ecosystem

provides a digital environment and a collection of domain models that are used by the eMAR

Ecosystem participants for three basic goals:

 To confirm that the existing technologies and models will provide the appropriate

environment for current and future Maritime operations in order to meet stakeholders’ strategic needs.

 To assist the development of new software applications and e‐services compatible with

the EMSF that are available over the eMAR Ecosystem and platform. This will lead to the

creation of a standardized connectivity infrastructure which will facilitate Maritime

stakeholders to amplify their co‐operation capabilities.

 To facilitate the exchange of data between existing Maritime stakeholders and services

within the Maritime Community that utilise the eMAR standard messages and

associated Access Points

In summary, the eMAR Ecosystem and its varied business and technical components will

become the blueprint for Maritime e‐governance models. The eMAR Ecosystem with its

conceptual framework which aligns the EMSF and eMAR architecture artifacts into a coherent

whole that will provide a robust and usable roadmap that can be offered to Maritime logistics

organizations in pursuit of sustainable operations in the digital era.

1.1

Overview

of

the

D2.2

Deliverable

The development of a sharing and collaboration culture in the Maritime professional and

research community, “Share more‐Develop less", is about the exchange and customization of

applications among the key stakeholders which includes shipping and port organizations,

agents and other Maritime entities and Maritime Logistics IT providers, over the eMAR

Ecosystem. eMar encourages the creation of innovative solutions along with the sharing and

exchange of application software and Maritime know‐how. This is inspired by the use of free,

open source software and participation in FOSS communities. Open source solutions can be

viable for Maritime entities as they do not cost as much while being equally robust to

proprietary software solutions. Where existing open software and applications are not

available, cloud solutions can be attractive, cost effective solutions. Additionally, sharing on

cloud‐based solutions and data is more easily deployed across large numbers of entities.

“Spending‐less”, re‐using software and minimizing infrastructure investments is a pertinent

value proposition of eMAR. Standardization of the communication solutions will also accelerate technology diffusion and market acceptance of the eMAR ecosystem.

The primary value proposition of the eMAR Ecosystem is its potential as a technology oriented

and long term enabler of Maritime clusters, in the digital era. It bridges the gap between the

(12)

stakeholders. eMAR details the view of an open and user needs oriented innovation Ecosystem

which is “fit for purpose” with the interests and needs of Maritime and Maritime multimodal

freight transport stakeholders. These maritime stakeholders include shipping companies,

manning agents, port authorities, logistics organizations and Maritime and transport IT vendors.

The eMAR ecosystem is comprised of a cooperation framework and synergy linkages between

internet research, Maritime policies and an open innovation framework include sharing of

resources and experimentation facilities.

The second value element of the eMAR Ecosystem is comprised of tools for the delivery of

Maritime economic policies among stakeholders, namely ship owners, ship managers,

shipbuilders, charterers, the Maritime administrations, port authorities and terminal operators,

classification societies, insurers and financiers and also policy‐makers interested in concrete,

business‐oriented solutions. All can exploit the EMSF and eMAR technical capabilities towards

supporting or even fully realizing their objectives.

At the heart of this deliverable lies the Access Point concept and technology which allows

parties within the defined Maritime network to communicate using messages without the need

for a centralized platform. Access points are analogous to email, in which the user simply

creates a message from their system, enters the destination address and presses “send”.

Security using certificates define user profiles in address lists which defines the message

standard that is used by the receiver. Users do not need to handle transformations/ mappings. This is taken care of in the Access Point or through services utilizing semantic technologies. The eMaritime Network concept as illustrated:

Figure 1.1: eMAR Connectivity Architecture Overview

The key advantages provided by this solution are that it is;

• Single connection point for applications (data integration)

• Equivalent to secure e‐mail for e‐Maritime communications

(13)

1.2

Objectives

of

the

D2.2

Deliverable

WP2 of the eMAR project is aimed at producing the eMAR Software Maritime Ecosystem to

facilitate the implementation of the e‐Maritime Strategic Framework. The e‐Maritime

Ecosystem intends to offer an e‐Maritime SOA software Ecosystem including semantic

technologies among stakeholder systems to enable different stakeholder groups develop

upgraded e‐Maritime efficiency solutions. The Core of this solution is described in D2.2

deliverable which provides the service interfaces to support interoperability among the

Maritime community and their systems. Specific objectives of D2.2 include:

 Referencing an e‐Maritime Ecosystem that extends the EMSF to specify in detail

information interchanges and controls between stakeholders at different levels:

transport networks, national authorities, EU agencies and international organizations.

 Provide connectivity and communication technologies that support each stakeholder

group to interface existing applications with the eMaritime Ecosystem.

 Provide specific intercommunication solutions that will form inputs into the

development of simulation services to aid the visualization of end to end transport chain services, based on the EMSF models, with increased levels of automation in information exchanges between different stakeholders.

 Analysis of potential standardization activities focused on the common information

sharing environment and communications security.

The provided application protocols interfaces (APIs) from eMAR Ecosystem cover a wide range

of business users by offering a broad range of typical eMaritime services such as security,

shipping, port operations, and transport logistics. Additionally, the eMAR APIs offer both

dedicated and customizable services since use varies over time and a large number of

stakeholders use them for different purposes. This has led to the establishment of a

collaborative connectivity infrastructure which enables the communication between public and

private parties and facilitates the development of the next generation of eMaritime

infrastructure, applications and services.

Another objective of D2.2 is to provide a high level of compatibility in order to support each

stakeholder group interface existing applications with the eMAR platform and Ecosystem which

will result in an increase in collaboration capabilities. Additionally, the utilization of eMAR

standard messages through the APIs will increase the levels of automation in information

exchange and will also facilitate a shared understanding within eMAR Ecosystem between

stakeholders.

Thus, this deliverable aims to describe an upgraded connectivity and information management solution that will promote coherent, transparent, efficient and simplified solutions in support of

cooperation, interoperability and consistency between member States, sectors, business and

(14)

2

The eMAR System Architecture

2.1

E

‐

Maritime

Systems

Framework

(EMSF)

The e‐Maritime Strategic Framework (EMSF) aims to create a common language enabling

networking and computer supported co‐operation between the principal maritime transport

stakeholder groups by bringing together into a coherent whole concepts, processes, standards and technologies.

eMAR intends to establish a Pan‐European (and beyond) conceptual business architecture for

everything to do with electronic communication within the area of Maritime transport, building

on results from relevant previous projects. The intention of the eMAR conceptual business

architecture, or the e‐Maritime Strategic Framework Specification (EMSF), is to describe generic solutions that can be used in all regions in Europe and globally.

Despite the many differences between local, national, regional and global situations, the role

responsibilities are by and large similar. Some core responsibilities are mandated by directives

and agreements, and as a result are always present. For a role to accomplish its responsibilities

it must execute one or more tasks. In reality, roles need to cooperate in order to perform

required and coordinated actions. This cooperation implies exchange of information between

roles. By means of the EMSF the information needs and communication requirements are

analyzed for each role. The development of the eMAR Base Ecosystem is closely associated with

standardization and the forms that this may take, often seen as a prerequisite for the

development of e‐services.

Based on the EMSF, a road map will be constructed showing milestones for the implementation

of e‐Maritime services and their interaction with on‐going developments. The road map may

also be augmented with assessments and projections for the future development of key

enabling technologies such as telecommunications and surveillance systems. The eMAR

Ecosystem (D2.1) will implement the following features:

 Specify the strategy and architecture for meeting both business and regulatory

requirements/goals

 Improve compliance with data protection regulations, international rules, EU

directives, standards and applicable confidentiality agreements

 Balance the interests, responsibilities and benefits of all stakeholders

 Standardize information required by supervisory bodies for regulatory compliance

(and integration of that information in the supply chain)  Identify key business drivers  Define business, environmental and safety performance indicators  Develop suitable organizational models  Facilitate collaboration at regional, national and EU levels  Be complementary to the Common Framework

(15)

2.2

eMAR

Technology

Ecosystem

The eMAR Technology Ecosystem provides the technology infrastructure and integrated

standards based technologies and infrastructures that are used to build an Ecosystem of

Maritime Logistics Entities. Developing a loosely coupled environment involves Collaborative

Planning, the composition of services in the Maritime logistic chains, the re‐planning of

Maritime logistics chains, the optimization of resources, and monitoring of environmental

Indexes [6].

The Technology Ecosystem architecture is loosely coupled and allows extreme scalability

because the events do not know about the consequences of their cause and so, for instance, an RFID sensor fires an event when something happen but the sensor itself does not need to know that other objects will add information as a reaction to this event.

The most relevant eMAR Ecosystem architecture features are the following:

 It envisions the creation of Ecosystems based of Persistent Logistic Objects.

 It shifts from a purely service oriented architecture to a more comprehensive virtual

object oriented approach to provide solutions supporting autonomous decision

capabilities.

 It is based on a semantically enriched architecture that supports not only the

implementation of the internal services but also the integration with external

applications and legacy systems. Semantics are used to enable global reasoning through

the entire eMAR environment. Based on a standardized knowledge structure (ontology)

extended with rules, relations and facts (actual measurements), trends and unusual

deviations are determined and this contributes to the eMAR infrastructure and service

intelligence.

 It implements semantic technologies to bridge differences within and between business

communities. For the purpose of standardization, the Common Framework provides

generic information models and message standards.

The guidance of the participants to the overall development of eMAR Ecosystem SOA solutions will take place by adopting related Open Group Architecture Framework (TOGAF) principles and

guidelines which constitute a framework for enterprise architectures widely used [1, 7, 10].

TOGAF's primary orientation is to support enterprise architecture implementation and

maintenance, as in the case of collaborating eMAR Ecosystem participants. It considers having

two concepts depending upon the context:

 A detailed plan of the system at component level to guide its implementation or/and a

formal description of a system.

 The structure of components (such as eMAR Ecosystem components), their inter‐

relationships, and the principles and guidelines governing their design and evolution

over time

A Technology Ecosystem relies on common interfaces and protocols to allow combining the

(16)

 business applications to implement the business level innovations defined before;

 generic components to support data exchange between organizations and intelligent

cargo object;

 an infrastructure, called a Hybrid Service Network for smart deployment of these

applications and components. The lower infrastructure layer delivers cross‐

functionalities for the implementation and deployment of these applications and

components.

The following figure shows how the users applications interact with the Ecosystem exposing

data through published services and external devices.

Figure 2.1: eMAR system to service publication / access through Ecosystem Architecture

This description of the eMAR Ecosystem is very high level. For a more detailed description of

the Ecosystem and its components, refer to D2.1 eMAR Ecosystem Architecture and

Technology.

2.3

eMAR

Architecture

Layers

The eMAR Ecosystem prescribes a Maritime governance framework that guides Maritime

stakeholders through a rapidly changing environment of technologies, societal determinants

and business models. State of the art service‐oriented business‐IT alignment methods can be

approached as pertaining into three layers: enterprise level, process level, and IT infrastructure

level. The EMSF and eMAR Architecture, as developed in the eMAR project, primarily address

this need for a systematic approach and constitute a set of distinct elements in all three above interlinked layers.

To achieve this, the systems network architecture is proposed with the n‐tiered architecture in mind [2, 9, 12] and can be divided into 5 main layers, the Presentation Layer, the Service Layer,

(17)

Figure 2.2: eMAR Architecture Layers

2.3.1 Presentation Layer

The user interface is a way for users to interact with the systems network and it helps in

acquiring and validating data coming in from users. Model View Controller (MVC) is used for the

implementation of user interfaces. MVC is a widely used software pattern that separates

internal representations of information from the ways that information is presented to or

accepted from the user. The user interface provides:  A consistent development environment that is also used for creating other components of the Ecosystem.  User interface data binding.  Component‐based user interfaces with controls.  Access to the security model. 2.3.2 Service Layer The hybrid network will provide services to other applications, as well as implementing features

to support clients directly, through a services layer that exposes the whole functionality of the

application.

2.3.3 Process Layer

The Process layer reflects the macro‐level activities of the eMar Ecosystem. The core processes

will be encapsulated by workflow components that orchestrate one or more business

components to implement a process.

(18)

2.3.4 Domain Layer

The Domain Layer is a software engineering practice of compartmentalizing. This layer usually

separates the application logic from other modules, such as the data access layer and user

interface. This practice allows software application development to be more effectively split

into teams, with each team working on a different tier simultaneously.

Within a Domain Layer objects can further be partitioned into business processes (business

activities) and business entities. Business process objects typically implement the controller

pattern, i.e. they contain no data elements but have methods that orchestrate interaction

among business entities. Business entities typically correspond to entities in the logical domain

model, rather than the physical database model. Domain entities are a super‐set of data layer

entities or data transfer objects, and may aggregate zero or more Data Transfer Objects. 2.3.5 Data Access Layer

This layer governs all data access and converts relational data into objects and back again. It is a “bridge” between the Domain Model and the Data Source Model.

The Ecosystem will implement its data access layer independently from the database server. It

will support multiple database types, supporting and implementing all calls into the database

repository, making it easier to port the Ecosystem to other database systems.

(19)

3

eMAR Connectivity Architecture and Message Exchange

3.1

Connectivity

Architecture

Overview

The eMAR Ecosystem will support the development of interoperable applications which can

exchange information with other applications using eMAR messages through existing standards

or eMAR Access Points. The project focus can be specified with reference to the EMSF which

has been materialized in a modular way to allow components to be developed with a clear

focus and to promote flexible take‐up by stakeholders.

The eMAR connectivity architecture primarily aims to facilitate the interfacing of different

Maritime services with the eMAR Ecosystem and platform, through the information exchange

between the different stakeholders groups. The key characteristics of the particular

architecture such as reliability, flexibility, secure, low cost and availability will assist the EU

Maritime transport sector to develop capabilities for managing highly dynamic business

systems serving a wide range of stakeholder interests. The implementation of the connectivity

architecture using the eMAR standard messages will also increase the interoperability and

collaboration between public and private parties.

The eMAR connectivity architecture consists of three categories of applications:

 Transport Networks applications, relating to ports, ship operations, and transport logistics;

 Third party digital services and applications.

 Administration and Regulatory Systems from EU, National Administrations and regulatory

authorities

The figure below shows how the connectivity infrastructure will contribute to the connectivity

through Access Points and the collaboration between stakeholders letting them to optimize

Maritime operations through collaborative processes and transparent access to services.

Figure 3.1: eMAR Connectivity of Stakeholders though the Ecosystem, using Access Points

(20)

3.2

eMAR

Message

Exchange

Focus

Areas

3.2.1 Logistics Chains Management Components

The main objective of Logistics Chains in the logistics Ecosystem is the utilization of Common

Framework messages. The specific framework provides a well defined structure by describing

standard roles and interactions in the logistic chain. It can be also used to structure business

applications, allowing the eMAR Ecosystem to build upon the results of previous developments, and design shared knowledge on the base of well‐established logistic models. Some of the main

messages of common framework are the Transport Service Description (TSD), Transport

Execution Plan (TEP) or GS1 Booking, Transportation Status (TS), Goods Item Itinerary (GII),

Multimodal e‐Waybill (MWB). In order to present a definition for each of the above messages we should first introduce the main roles involved in the logistics chain:

Transport User (TU): Represents the person that needs to have cargo transported. He also

provides the Transport Service Provider with instructions and detailed information about the

transport items to be transported.

Transport Service Provider (TSP): Responsible to ensures the transport of the cargo from the

origin to the destination. Specifically TSP provides management of the transport services and

the operation of the transport means and handling equipment. He provides also other

administrative services required for moving the cargo.

Transport Network Manager (TNM): Responsible for extracting all information available

regarding the infrastructure (static or dynamic) related to planning and executing transport and

makes this information available to the Transport User and the Transport Service Provider.

Planning includes the advertisement of services from TSP to TU in a common format in terms of

a schedule and a freight rate. Execution is the management of physical transport of the goods

which includes exchanging information on the status of the shipment with the TU and the

status of the transport infrastructure with TNM.

Transport Regulator: Responsible for receiving all mandatory reporting (and checks if reporting

has been carried out) in order to ensure that all transport services are completed according to

existing rules and regulations.

Below is the definition for the messages listed above:

Transport Service Description (TSD): The document is sent from Transportation Network

Manager to Transport Service Provider giving a status on the transport operation.

Transport Execution Plan (TEP): The document is used in the negotiation of a transport service

between a transport user and a transport service provider.

Transportation Status (TS): A message to report the transport status and/or change in the

(21)

Goods Item Itinerary (GII): Sent from TNM to TSP giving a status on the transport operation and the routes will be followed.

Multimodal e‐waybill (MWB): Issued by the party who acts as an agent for the carrier or other

agents, to the party who gives instructions for the transportation services (shipper, consignor,

etc.) stating the details of the transportation, charges, and terms and conditions under which

the transportation service is provided.

Table 3.1: Message exchange areas for logistics chain

Area eMAR Message description Related developments eMAR services Opti‐modal planning Data model on information to be supplied by ship to port/terminal system responsible for terminal and hinterland operation Linked to extended gateway concept/ practices Possible link with TEP and TS Extended services for optimized hinterland services

Ship loading eBoL to be linked to

waybill of e‐Freight and industry

developments from FIATA

3.2.2 Ship Operation

In close co‐operation with e‐Navigation and S100 standard, e‐Navigation is an International

Maritime Organization (IMO) led concept based on the harmonization of marine navigation

systems and supporting shore services driven by user needs.

Table 3.2: Message exchange areas for ship operations

Area eMAR Message description Related developments eMAR services Shipping Service descriptions Use and test Transport Service Description from e‐ Freight A ‘universal’ distributed directory of shipping services

(22)

Ship Voyage

Monitoring – Noon report

Standard data model for ship monitoring particularly addressing environmental issues IMO Energy Efficiency Operational Indicator (EEOI) Also outputs from Flagship

SVM service for on‐ board use and office use

Global ship status database Ship voyage optimization services Statement of Fact Standard data model for communicating statement of fact information handled normally by ship agents Log management service with data quality checks and distribution management e‐Recruitment Standard data model for CVs in line with STCW Posting and viewing information about vacancies and job applicants Class Exchange Planned maintenance data model interfacing with Classification portals Benchmarking of shipping services Standard data model for shipping service benchmarking Service to be hosted by association or EU agency

(23)

3.2.3 Port Operation

Port Operations consist of the exchange of commercial and logistic messages between port

associated companies and between the public and private sector. It contains also the provision of information about vessels to the authorities.

Table 3.3: Port reporting messages

Port costs services and restrictions Data model Integrated information services Port Clearance including SSN notifications Maritime Single Window based on CRS Building blocks

3.3

Challenges

to

e

‐

Maritime

Message

Exchange

Challenges considered by the eMAR project for the end‐to‐end transfer of messages within the supply chain include;

 Supply chain stakeholders do not have the same level or maturity of ITC infrastructures. It

is unlikely that any one method for the transfer of messages will suffice as a practical

solution in the near term.

 Some institutions do not have common guidelines for all the employees to enable them

to handle changes in their working procedures.

 Human factors can also make some incompatibilities within the system. Very often there

needs to be human intervention to gain approval to move through the loading and

discharging processes. These steps can be difficult to change / improve.

 There may be additional process steps at individual ports that are non‐standard and

require consideration.

 Other problems in message exchange:

 Some documents contain duplicated records/data.

 Different authorities may have to be provided with the duplicates of the same

documents.  Delays in the processing of electronic information can have a direct effect on delays in cargo handling. As a result of these challenges to an integrated e‐messaging solution within a defined Maritime community, it has been decided to utilize both Access Points and standard connectivity models in order to maximize the potential uptake by the different Maritime stakeholders.

(24)

3.4

eMAR

Connectivity

Services

eMAR connectivity services can be established using different tools that produce services which

can be used by Ecosystem participants to produce their own solutions. The emphasis in eMAR

will be to connect or provide ‘small’ apps with high level of robustness and usability addressing

the needs of Maritime SMEs and close functionality gaps to promote integration for Maritime

services in the EU transport system as specified in D1.1 to D1.3 of the eMAR project.

Connectivity services in eMAR will support different groups of stakeholders in the following

three approaches:

 Compose

 Integrate

 Collaborate

Regarding the compose approach, will enable the connectivity between eMAR Ecosystem and

platform and existing applications.

The integrate approach support the collection of information from different sources and share

them across the e‐Maritime applications.

The third approach will help out the users of eMAR Ecosystem to collaborate via the supported eMAR applications.

3.5

eMAR

Connectivity

Standard

Models

The connectivity models consist of primarily existing technologies and standards which are

widely used for systems communication. The fact will enforce the eMAR Ecosystem and

platform to provide the required security levels and will enable also the different stakeholders

group for collaboration. The most important connectivity models which are used in business

domain are described below.

3.5.1 Representational State Transfer (REST)

REST describes a lightweight way for establishing communication between different types of

systems. It uses the HTTP request to post data and thus can also use all the supported

operations which the specific protocol provides (Create, Read, Update, and Delete). In the REST

architectural style, data and functionality are considered resources and are accessed using

Uniform Resource Identifiers (URIs), typically on the Web. Restful solutions are very simple

types of connectivity models and moreover are fully‐featured including security levels via

secure sockets.

(25)

3.5.2 Simple Object Access Protocol (SOAP)

As the REST, SOAP is lightweight way of communication that is independent from platform,

transport or operating system. There are two types of SOAP requests. The first is the Remote

Procedure Call (RPC) style request similar to other distributed architectures. This is usually

synchronous; the client sends a message and waits to get a response or fault message back

from the server. The second type of SOAP request is the document request. In this case, a full

XML document is passed to/from the client and server, inside a SOAP message. SOAP is not as

simple as REST. Usually a good analogy that is used to compare these two types is the example

of mailing a letter. With SOAP an envelope is used, but with REST just a postcard, which is

easier to handle, waste less paper and have less content. 3.5.3 Web Service Description Language (WSDL)

The mechanics of the message exchange are documented in a Web Service Description (WSD).

The WSD is a machine‐process‐able specification of the Web service's interface, written in Web

Service Description Language (WSDL). It defines the message formats, data types, transport

protocols, and transport serialization formats that should be used between the requester agent

and the provider agent. It also specifies one or more network locations at which a provider

agent can be invoked, and may provide some information about the message exchange pattern

that is expected. In essence, the service description represents an agreement governing the

mechanics of interacting with that web service.

While the service description represents a contract governing the mechanics of interacting with a particular service, the web service semantics represent a contract governing the meaning and

purpose of that interaction. The dividing line between these two is not necessarily rigid. As

more semantically rich languages are used to describe the mechanics of the interaction, more

of the essential information may migrate from the informal semantics to the service

description. As this migration occurs, more of the work required to achieve successful

interaction can be automated.

(26)

4

eMAR Access Points

4.1

Overview

Access Points (APs) enable eMAR Ecosystem users to communicate each other in a secure and

reliable way using electronic messages. In the eMAR Ecosystem, APs are the main entry points

and provide controlled access to software services. Access Points can be considered as a

“gateway” or “bridge” between the eMAR Ecosystem members. The way access points

operates represents the concept of email in which the user simply creates a message from

relevant data, enters the destination address and presses “send”. The fact that no central

platform is required and with the adoption of a public key infrastructure, access points

addresses also the three important issues arising from electronic information exchanged:

Security, Quality and Reliability and Ownership of Information.

Access Points hold a major role to the establishment of a scalable, secure and efficient

connectivity infrastructure. The main advantage arises by the adoption of Access Points is that

it can be utilized from a large number of participants in the European Maritime Community.

The above capabilities together with the efficient discovery functions provide the means to

stakeholders to enter and quickly become part of the Ecosystem without the need to rely on

point‐to‐point connections in order to establish the supported comprehensive set of Maritime

Logistics Services. Access Points can be considered as the transport infrastructure for Logistics

Ecosystem by providing a standard set of information types which Common Framework

supports as mentioned in the previous section.

The communication protocol and the implementation of Access Points has been highly

influenced and is largely compatible with the European Standard implementation of Pan‐

European Public Procurement Online (PEPPOL) project Access Points and also comply with the

Business Document Exchange Network standard (BUSDOX). BUSDOX is document agnostic,

meaning participants can transfer ANY kind of electronic document between ANY network. The

main difference between BUSDOX and other document exchange systems is that BUSDOX is

designed to support what is known as a 4‐corner model. The 4‐corner refers to the fact that the trading participants (such as buyer and seller) may exchange their documents via two (or more)

intermediary service providers. An important advantage of this approach is that it gives the

possibility to participants to access the network using their own Access Points provider and

have immediate connectivity with all other participants on the network.

4.2

Exchange

Security:

Security and integrity of the messages exchange through the Ecosystem Transport

Infrastructure relies on using a Public Key Infrastructure (PKI) to establish a trusted network.

When Access Point or Service Metadata Provider (SMP) providers sign the Ecosystem Transport

Infrastructure Agreement they receive a Digital Certificate. This certificate contains the key

(27)

This allowing a reviever of a message to confirm the identification of the sender and ensures that the message has not been modified in transit. In summary, it ensures tnat only known and trusted providers have access to the Transport Infrastructure.

4.3

Quality

and

Reliability

The BUSDOX communication specifications (LIME for the communication between the

participants and the Access Points; START for the communication between APs).are used to

ensure the quality of the information and the quality and reliability of the communication

channels.

4.3.1 Lightweight Message Exchange Profile (LIME)

The Lightweight Message Exchange Profile (LIME) is an optimal solution for small and medium

Enterprises (SMEs) to access BUSDOX infrastructure from the economic and the performance

point of view. This is because the establishment of a communication using the LIME does not

require hosting online endpoints; hence no firewall crossing and no server infrastructure.

Additionally there are no requirements for supporting “advanced” WS‐* standards such as WS‐ Trust, WS‐Reliable Messaging. Additionally only minimal requirements are necessary to support WS‐Security (authentication headers only).

The main advantage of the Lightweight Message Exchange Profile is that it allows different

systems to participate in the BUSDOX infrastructure without needing to access service

metadata or host an Access Point. Instead, they rely on an Internet Service Provider (ISP) to

provide LIME services to them. A simple analogy is Internet email: Large companies may run

their own Simple Mail Transport Protocol (SMTP) server and proprietary email clients to create and read messages, but individuals or small companies rely on an ISP to provide an SMTP Relay and POP3 or IMAP server. A summary of benefits that LIME brings to the eMAR solution include:  It provides access over a simple HTTPS‐protected channel.  It utilizes existing standards where appropriate.  It lowers the cost of entry for SME’s and individuals.

4.3.2 Secure Trusted Asynchronous Reliable Transport (START)

BUSDOX infrastructure is created through the communication of Access Points in a peer‐to‐peer

model across the internet. The requirements for the form of the specific infrastructure and for

the communication to take place are that each AP should know the endpoint address of others AP. This can be achieved with the use of BUSDOX Service Metadata Publishing Infrastructure [3]

which enables the exchange of digital certificates and endpoint URLs and therefore automates

the inclusion of new or modified APs. Such an exchange is achieved by holding the actual

metadata information for a given participant identifier and document type combination.

Moreover AP may communicate via optional Transport Profiles, but they must always offer a

(28)

B.1.1 Advantages of START The goal of START is to support the message exchange between two or more ends, in a reliable and secure way using web services [7]. The profile is designed to:  Enable the different implementers to build and therefore to gain access to BUSDOX with no further requirements or adjustments to implement other transport profiles.  Provide detail description of the transport level requirements in a single document.

 Provide an efficient and interoperable communications pattern that APs can use to

communicate very easy.

 Define the message exchange formats and patterns clearly.

 Guarantee that AP uses a secure transport protocol and thus the messages are reliably

delivered between APs. This also includes provision of prerequisites for logging and

proof‐of‐delivery for messages at the transport level.

 Guarantee confidentiality of exchange messages using transport‐level encryption.

 Guarantee integrity and authenticity of received messages using digital signatures and

validation of these signatures.

 Support transfer of messages that are opaque to the Access Point

 Provide different formats of headers within the message envelope so Access Points can

forward/transfer messages without requiring access to the business message.

 Provide a standard message for the authentication events in BUSDOX infrastructure in

the form of SAML 2.0 assertions / tokens.

 Recipients can assume that senders have been authenticated by their token Issuers and

obtain further proof via cryptographically signed tokens.

(29)

Appendix B ‐ eMAR Access Points sections 4 and 5.

4.4

Ownership

of

Information

APs are independent from the traditional approach where the exchange of data involves

multiple isolated systems. APs follow an entity centric approach that achieves the exchange of

all the digital data in the Technology Ecosystem to be directly managed by each single resource

(AP). A participating organization registers to an Access Point and via this; it is possible to

exchange information all the other participants in the ecosystem.

More details about the APs are provided in the Appendix B for the interested reader.

(30)

5.

The eMAR API Library

In eMAR the principal objective of API’s is to facilitate the creation of an upgraded and low cost

connectivity infrastructure through the provision of efficient and quality shipping services fully

integrated in the overall European transport system. Additionally, eMAR API’s will support the

Service Oriented Architecture (SOA) which is one of eMAR main targets in order to provide the ability for automated application lifecycle management.

eMAR API’s comprised of four main categories and which are described in details in the next

sections: 1. Port Operations 2. Ship Operations 3. Transport Logistics 4. Third Party Digital Services The eMAR API Template includes the following: 1. Methods : The supported methods of API

2. Connectivity Protocol: The types of connectivity protocols are used to support the

methods

3. Parameters (input, output): Details of all the input and output parameters along with

description of values that can be passed.

4. Description: Detailed description of the API and methods

Each method of the API includes the following tables: Parameters

Table 5.1: Method Parameters

Response

Table 5.2: Method Reponse

Parameter Name Type Description

Required parameters Required Parameter Name Type of parameter Detailed description of required parameter Optional parameters Optional Parameter Name Type of parameter Detailed description of optional parameter Response Name Type Description

(31)

Errors

Table 5.3: Method Response Errors

Return Value

Table 5.4: Method Return Values

5.1

Port

Operations

The diagram in Figure 5.1 gives an overall description regarding the port operations which will

be included in eMAR Ecosystem and Platform.

Figure 5.1: Port Operations in eMAR Ecosystem

As indicated in Figure 5.1 the most important system which is widely used in most of EU ports

today is the Port Community System (PCS) and thus the main goal is the provision of some

services from the particular system. The main operation of PCS is to support the exchange of

commercial and logistic messages in a port environment on a business level. PCS are also

closely related to Port Single Windows which are used for providing information about the

vessel to the authorities on a port level, B2A (Business to Administration).

Error Code Error Type User Message

The code of the error displayed

on user’s applications.

Type of Error The message displayed on user’s

application

Field Name Error Type User Message

(32)

5.1.1 eMAR API for Port Community Systems (PCS)

The API for Port Community Systems can play a major role in facilitating the more efficient

movement of goods while allowing Customs and other government departments to maintain

effective controls. Such API’s can also have a significant contribution as Europe moves towards the Single Window concept.

The stakeholder groups which can use the API consist of private companies on the one hand

(shipping agents, terminal operators, forwarders, Customs brokers, etc.) and of public or

government agencies (Customs or Port Authorities) on the other hand. Moreover, in terms of

the client structure, shipping lines and freight forwarders play the most important role,

followed by importers and exporters in general or Customs and shipping agents. In this way the

API will form a cost effective connectivity infrastructure through the eMAR Ecosystem which

will enable a number of ports to connect and hence to create an efficient collaboration

between the key authorities and stakeholders.

The eMAR API for Port Community Systems (PCS) provides different login/administration

services and terminal instruction services. The provided services consist of the submission of

different electronic documents and information offering the guarantee of a secure and reliable storage solution. Additionally, it provides the ability to search electronic documents on specific fields. A more detail description of the provided services is mentioned in the next sections.

The table below lists the supported operations by Login and Administration Services. For a

more comprehensive description see section 0.

Table 5.5: PCS Operations for Login and Administration Services

Method Connectivity Protocol Input and Output Description Log In 1. REST / Get 2. WSDL

See section 0 Initiate a session in PCS and enables the

interaction with Terminal Instruction

Services. Check Session 1. REST / Get 2. WSDL

See section A.1.2 Allows the user to verify that the initiated

session is still active. Change Password 1. REST / Get 2. WSDL

See section A.1.3 Allows the user to change the current

(33)

5.1.1.1 Login and Administration Services

The Login and administration services can provide additional security mechanisms of identity

and access management. Using these mechanisms the API can verify that a user is the entity

that it claims to be, and also for determining which actions an authenticated principal is

allowed to perform. This will ensure the continued operation of the provided services. Also the

particular services are prerequisite in order for the user to be able to interact with Terminal

Instruction Services. The provision of such operation in the API will lead to a secure connectivity

infrastructure which will support an improved information exchange between Administrations

and business (A2B & B2A) under the eMAR Ecosystem and Platform.

5.1.1.2 Terminal Instruction Services

The Terminal Instruction Services allows shipping agents to send the vessel loading and

discharge lists to the container terminals and obtain the appropriate confirmations or feedback for the submission of those lists. The main benefits of terminal instruction services are:  Provides the possibility for integration with all the container terminals  Ability to produce any document separately  Ability to capture the customs information and obtain information on customs declarations to compile cargo manifest.  Ability to provide tracking and tracing information to all parties involved  Increased control of the information and documentation processed and reduction in errors. The terminal instruction services through trusted protocols ensure the appropriate information is received only by those that need it, when they need it. The reliable connection increase also

levels of automation in information exchanges between different stakeholders which will set

the foundations for cooperative networking strategies through the eMAR Ecosystem.

The table below lists the supported operations by Terminal Instructions Services. For a more

comprehensive description see section A2.

Table 5.6: PCS opearations for terminal instruction services

Method Connecti

vity Protocol