Deliverable 3.2 Conceptual Model

Document name:
E2 – D3.2 Conceptual Model
Deliverable 3.2
Conceptual Model
Project no. 636329

Project acronym: EfficienSea2
EFFICIENSEA2 – efficient, safe and sustainable traffic at sea
Funding scheme: Innovation Action (IA)
Start date of project: 1 May 2015

End date of project: 30 April 2018
Duration: 36 months
“This project has received funding from

Page 1 of 26
the European Union’s Horizon 2020
research and innovation programme
under grant agreement No 636329”.
D3.2 Conceptual Model 01.00
D3.2 Conceptual Model
Document information
Project Title EfficienSea2

Deliverable Name Conceptual Model
Deliverable ID D3.2
Edition 01.00
Due date of deliverable 25 January 2016
Actual submission date 27 January 2015
Revised submission date N/A
Organisation in charge of
Frequentis
deliverable
Task contributors
Frequentis (Task Leader), DMA, OFFIS, LYNGSØE MARINE, IALA, FTA
Abstract
Based on the Analysis Report from Task 3.1 this deliverable describes the key concepts, data flows and
components forming the Maritime Cloud. It is the point of reference for all subsequent more technical tasks
targeted at both technical and non-technical audience. The conceptual model aims to be an executive summary
facilitating a common understanding of the Maritime Cloud not only among the project partners but also between
the project and possible future stakeholders.
The level of detail in this document has been chosen intentionally in order to give the target audience a high-
level overview about the components forming the Maritime Cloud and the concepts to be followed. The
description is about the general scope of the MC. Technical implementation details shall be elaborated based on
the conceptual model and described later in Deliverable D3.5 “Technical Specification”.
It is important to mention that this deliverable describes the Conceptual Model for the Maritime Cloud as being
deployed in the future. The scope of the maritime cloud demonstrator to be developed in work-package WP3.4
of the EfficienSea2 Project may differ from the fully developed and finally deployed version of the Maritime
Cloud, as implementing a fully validated (and standardized) Maritime Cloud would go far beyond the scope of
the EfficienSea2 Project.

Page 2 of 26 the European Union’s Horizon 2020
Document Status
Authoring & Approval
Prepared by – Authors of the document

Name Organisation Date
C. Rihacek Frequentis 12.10.2015
T. Lutz Frequentis 30.10.2015
B. Weinert OFFIS 30.10.2015
A. Bolles OFFIS 26.11.2015
K. Nielsen DMA 04.11.2015
J. K. Jensen DMA 26.11.2015
Reviewed by – Reviewers internal to the project

Edward Hosken UKHO 04.01.2016
Christoph Schreyer DGA 07.01.2016
Reviewed by – Reviewers external to the project

Document History
Version Date Status Author Description

00.01 12.10.2015 DRAFT Frequentis Initial version
00.02 02.11.2015 DRAFT Frequentis Contributions from OFFIS and Frequentis included
00.03 04.11.2015 DRAFT Frequentis Contributions from DMA included
00.04 16.11.2015 DRAFT Frequentis Reorder chapters / introduce new chapters
00.05 25.11.2015 DRAFT Frequentis Update “Service Registry / Service Management”
Update “General implementation conditions”
00.06 27.11.2015 DRAFT Frequentis Update “Identity Management and Security”
Update “Alice & Bob – A maritime cloud story”
Resolution of review comments
Completion of missing sections
00.07 03.12.2015 DRAFT Frequentis Review by Task 3.1 members
00.08 07.12.2015 DRAFT Frequentis Refinement of “Alice & Bob – A maritime cloud story”
00.09 07.01.2016 DRAFT Frequentis UKHO and DGA comments included
01.00 20.01.2016 FINAL Frequentis Final review

Table of Contents
1 Vision for the Maritime Cloud ................................................................................................ 5

1.1 Mission Statement .......................................................................................................... 5
1.2 Vision statement ............................................................................................................. 5
2 General Conditions ............................................................................................................... 7
3 Maritime Architecture Framework ......................................................................................... 9
4 Outline ................................................................................................................................ 11
4.1 Alice & Bob – A maritime cloud story ........................................................................... 11
5 Management Summary....................................................................................................... 13
6 Core Components of the Maritime Cloud ............................................................................ 14
6.1 Service Registry / Service Management ...................................................................... 14
6.2 Identity Management and Security ............................................................................... 16
6.3 Almanac ....................................................................................................................... 18
6.4 Maritime Messaging Service ........................................................................................ 19
6.5 Maritime Cloud Client Component................................................................................ 21
6.6 Data Flows ................................................................................................................... 22
7 References ......................................................................................................................... 24
Abbreviations ......................................................................................................................... 25
Table of Figures
Figure 1: Use case mapping process .................................................................................... 10

Figure 2: Service Management Concept................................................................................ 14
Figure 3: Interactions with the Maritime Cloud Almanac Component .................................... 18

1 Vision for the Maritime Cloud

The Maritime Cloud concept has been derived as “A communication framework enabling
efficient, secure, reliable and seamless electronic information exchange among all authorized
maritime stakeholders across available communication systems”, based on the IMO e-
navigation strategy. The vision reaches beyond the IMO strategy, matching the goals of the
EU e-maritime initiative and more.
1.1 Mission Statement
The mission of the Maritime Cloud is to enable an open and vendor-neutral platform for the
maritime sector that facilitates information exchange easily and securely across various
communication channels, such as the Internet, satellite or digital radio links. It will allow for
interconnecting heterogeneous software systems onboard various ship types, on offshore
structures or on shore, including dedicated type-approved systems (e.g., ECDIS) and more
ubiquitous personal devices, like smartphones, tablets and personal computers, according to
standardized interfaces, protocols and access control rights.
At this stage, the Maritime Cloud shall not be considered as a product aimed at end users
such as mariners or ship owners. Instead, it is a framework providing standardized protocol
and functional support for identity and role management, authentication, encryption,
authenticity validation, service discovery and bandwidth efficient messaging in a geographic
context. This enables easy development of innovative solutions targeted at maritime end
users in a context of global interoperability. The Maritime Cloud shall be regarded much like
the Internet as the enabler of interoperable systems for email, VoIP, webpages, blogs, social
networks, or online shopping sites.
1.2 Vision statement
By making the Maritime Cloud a key part of the EfficienSea2 project, we aim in the coming
three years to lay the foundation for a widely used framework, that through facilitation of
interoperable solutions:
• Will enhance the safety and efficiency of the maritime sector, through information
technology innovations that bridge gaps between information islands.
• Will follow established and robust international standards wherever feasible
• Will facilitate the development of, and transition towards, globally standardized
information services for the maritime sector.
• Will provide tools and guidelines facilitating the development of software that may
safeguard the confidentiality and verify the authenticity of data exchanged between
individuals and organizations.
• Will minimize operating costs by efficient usage of available bandwidth in the maritime
sector.

• Will lower development cost and improve software quality, usability and time to market
for commercial and non-commercial software products.
• Will ultimately be recognized, governed and supported by a sustainable community,
including important international, regional and commercial organizations in the
maritime domain (such as IMO, IALA, IHO, CIRM, BIMCO and EU).

2 General Conditions
The introduction of new communication frameworks has the potential to have a big effect on
international seafaring. At present, vessels and shore-based facilities are equipped with a
variety of heterogeneous maritime systems such as AIS or GMDSS which contribute to safe
navigation. The IMO e-navigation strategy initiates a holistic approach to improve
standardization of digital information and infrastructure within the maritime transportation
process.
The e-navigation strategy comes with an overarching architecture, covering the (civil)
maritime domain. The architecture divides the domain into ship-side and shore-side. This
separation contributes to the deviant technologies and regulations on both sides. The e-
navigation architecture is based on the principle of exchanging data and information between
ship and shore (but also between ship and ship as well as between shore and shore). The
conceptual basis for the Common Maritime Data Structure (CMDS) is the IHO-Geospatial
Information Register, also called the S-100 Register. S-100 is a framework, which provides a
repeatable data specification development methodology and general provision for the data
specification process. The circumstance that the S-100 framework is based on the ISO
19100 series of geographic standard guarantees the compatibility within the maritime
domain, but also with other spatial data created according to the relevant ISO standards.
Resulting to this, current activities such as the development of the maritime cloud concept
have to take care about existing (and upcoming) maritime systems and need to be
“embedded” in the maritime environment.
This results in a high need to ensure interoperability among different systems. Therefore,
there is a high need to identify gaps and overlaps between heterogeneous systems and
identify possible interoperability issues among them.
Besides the human parts, (maritime) systems rely upon systems architectures, which include
concepts, properties and structures as well as design principles and relationships to their
environment. Existing system architectures (and the associated systems) diverge in a high
degree. Those systems and their application are subjected to regulations given by
international or national authorities. With the upcoming e-navigation strategy, stakeholders in
the maritime domain (see [5]) face the challenge to harmonize existing systems and to
integrate new approaches into existing structures. The maritime cloud, with the demand of an
interoperable communication framework, has to consider these aspects.
Therefore, there is a high need to align the relevant architectures to each other and
coordinate the development of the maritime cloud between application, technology and
related stakeholders within the maritime sector.
As a result, the EfficienSea2 project partners initiate the Maritime Architecture Framework as
a solution to coordinate the development of new systems considering technology issues,
governance aspects and users in-between existing architectures. This framework takes into

account technical and governance issues as well as the (civil) maritime domain as specified
in IMO’s e-navigation strategy.

3 Maritime Architecture Framework

Enterprise Architecture (EA) frameworks such as TOGAF and Zachman are used to develop
strategic and architecture solutions within enterprise architecture engineering. They cover
business objectives and regulations as well as required IT alignments [1]. ISO/IEC42010
describes an Architecture Framework as “Conventions, principles and practices for the
description of architectures established within a specific domain of application and/or
community of stakeholders”. In 2008, an initiative in the electric utilities domain adapted the
Framework-Approach and introduced the Smart Grid Architecture Model (SGAM) to present
the design of related use cases regarding interoperability and standardization aspects for
business and governance as well as for technical issues [2].
The Maritime Architecture Framework (MAF) adapts this framework approach and provides
methods and tools to discuss, align, design and handle existing or future system
architectures and architectural reference models within the maritime domain. The envisioned
goal of MAF is to compare different maritime IT-architectures and systems including related
regulations to set them in context to each other in a consistent and harmonized manner. This
results in the possibility to identify gaps, overlaps or interoperability issues between different
maritime concepts and technologies. MAF is oriented towards the design principles of SGAM
and provides a consistent terminology and takes into account IMO’s e-Navigation Strategy
Implementation Plan [3] and e-Navigation implementation process [4].
The main objective of MAF is a stakeholder oriented analysis of existing and projected
services and (reference) architectures. The stakeholders are defined by IMO’s Maritime
Safety Committee [3]. As released by IMO, an initial list of service portfolios of the maritime
domain is derived from NCSR1.28 [4], and the FAL Convention. In addition to that, the
interoperability aspects are derived from existing architectural frameworks (in this case Smart
Grid Architecture Model (SGAM) [2]. This top-down approach was accompanied by a bottom-
up collection of structural elements of international interest groups, institutions and
organizations.
MAF captures different aspects of maritime architectures mapped to a multidimensional

space with different orthogonal dimensions subdivided in layers. The framework provides a
mapping process starting with the definition of the related use cases and derives
interoperability aspects for governance and regulation issues as well as for technical
components (Figure 1).

Figure 1: Use case mapping process
MAF offers a three dimensional structure of architectural aspects, assembled in a meaningful

way in the MAF-Cube. This Cube represents subsections of the maritime domain using the
three dimensions Interoperability axis, Topological axis and Hierarchical axis.
• The layers of the Hierarchical axis reflect the hierarchy and aggregation of
management and control systems in the maritime domain.
• The Topological axis covers the elements and its interrelationship of maritime domain.
It is an adaption of IMO’s e-Navigation architecture.
• The layers of the Interoperability axis of the Maritime Architecture Framework define
the required definitions and agreements to ensure interoperability.
In this case, the framework will be used as the theoretical basis to support the
development of maritime service infrastructures within the Maritime Cloud (and
SeaSWIM - System-wide Information Management) and its corresponding technical
services. It will be used to support the architectural development of the Maritime Cloud
within the two projects EfficienSea2 and STM. The main aim of SeaSWIM is to ensure
the interoperability of services (developed throughout the STM project) and to facilitate
data sharing using a common information environment and structure (e.g., the
Maritime Cloud).
This framework is developed as an open governance concept to cover all social-technical

IT-systems within the maritime domain and intermodal logistics. Therefore, the MAF is open
for future extensions. Contributions from further maritime stakeholders are explicitly welcome.
Upcoming extensions and changes will be discussed and defined in an open governance
group.

4 Outline
In the following outline, we illustrate a common use case for the Maritime Cloud, aiming to
point-out potential benefits for the stakeholders, when having the Maritime Cloud in place.
4.1 Alice & Bob – A maritime cloud story
Bob is a 56 year old ship master of the Emma Cologne, a 380 meters long and 17000 TEU
container vessel. He is on his 16 day voyage from Rotterdam to New York and currently the
vessel is in the middle the northern Atlantic Ocean. In this region the connection to the
internet is intermittent (meaning that many connection losses could occur). When the internet
connection is available for a sufficient long time, Bob receives a digitally signed storm
warning message for the western part of the northern Atlantic. Bob takes notice of this
message and realizes that he will need external support by means of new weather routing, to
arrive efficiently and safely in his next port of call. Fortunately, Bob’s vessel is equipped with
Maritime Cloud components, which allow him to find an adequate weather routing service.
Based on his current position and intended route, he looks up available weather routing
services in this region using the Service Registry of the Maritime Cloud (in the same way he
would search for carpenter numbers in the yellow pages). The Maritime Cloud automatically
provides him adequate services for that region where the upcoming part of his voyage route
traverses. Having this list available, Bob selects for instance a service provided by Alice.
Since his navigational equipment is cloud compatible, it automatically knows how to connect
to Alice’s service.
Bob’s navigational equipment establishes the connection to the service and in parallel
validates Alice’ authenticity and authenticates himself. Bob now requests weather information
and alternative routes by providing his current position and his planned route. As a response
to this request, Bob’s equipment receives weather information for the region his route is
planned to go through and a suggestion for an alternative route in a standardized format.
This information is automatically displayed on his navigational equipment. Bob is lucky,
because the suggested alternative route allows him to arrive at his next port of call in a safe
way and only with little delay. Bob thinks: “Hey, Alice’s weather service is very accurate.
Wouldn’t it be a good idea for receiving updates of weather information automatically in
future? I will try this.” So, Bob subscribes to Alice’s service for automatic updates.
Meanwhile Alice constantly updates the forecast data available via her service. Whenever
she has an updated report available, she authenticates herself to the Maritime Cloud and is
then able to provide her new forecast, digitally signing it to prove it’s authentic.
Two days later: Bob has already travelled 1.000 nautical miles to the West. By means of the
Maritime Messaging Service, which is another cloud component, Bob suddenly receives an
update of the weather information from Alice’s service (based on Bob’s current position). The
storm went to the East and Bob’s has already passed the critical region. Bob is lucky, since

he does not have to follow Alice’ alternative route anymore, but can change the course
directly to the Port of New York saving 12 hours.
While making the journey over the Atlantic Ocean Bob’s internet connection breaks down
temporarily. Suddenly a radio based message about an iceberg warning arrives from an
unknown source. Normally, the authenticity of the message could be validated by contacting
the identity registry and see if the sender of the message is a valid maritime actor. However,
with no internet connection the navigation equipment instead automatically turns to the
Almanac which contains an easily updatable offline version of the identity and service
registry. Having successfully verified the authenticity of the message Bob diverts the course
and avoids a collision with the iceberg.
After 17 days, Bob finally reached the port of New York in an efficient and safe way. As he
has seen in the Almanac that Alice service Station is located in this port of call, he decides to
visit the service centre and potentially meet Alice.

5 Management Summary
The Maritime Cloud is a collection of infrastructure services, standards and
governance facilitating secure information exchange in the maritime domain.
Services can be easily registered,

discovered and used.
Identities can be verified and used to

digitally sign communication.
Messages can be exchanged between

components connected to the cloud, these
can be either clients operated by humans
or services.
Geographic and organizational contexts

(e.g., a vessel’s location) are used as key
parameters for service discovery, identity verification and message exchange.
The maritime cloud offers a so-called Service Registry. You

can imagine this component as an automated switchboard.
Components connected to the cloud call the “operator”/service

registry asking for a route to a service.
Depending on the request (Name, Type, Location …) the end

user is provided with possible dialogue partners and can then
choose to whom to speak.
Nowadays, daily processes include a lot of paper work. Documents need to

be signed to prove authenticity. The Maritime Cloud offers means to digitally
assure the identity of the communicating partners.
Every message can be certified using state-of-the art technologies.
The maritime cloud does not include data storage or application hosting.
This remains the responsibility of service providers and organizations.
Focusing on improving communication and digital interactions based on open

standards, while reusing existing components and infrastructure within the current
organizations enables a smooth transition.
To the extent possible, there is no organizational change necessary.

6 Core Components of the Maritime Cloud

6.1 Service Registry / Service Management
Enabling services providers to deliver their services to customers with increased

security and productivity while decreasing the cost and effort.
Services themselves and the service based economy are a central part of the vision of the
Maritime Cloud. In the context of service-oriented architecture, a service usually refers to a
set of related software functionalities that can be reused for different purposes, together with
policies that governs and controls its usage. The Maritime Cloud comprises a much broader
scope that also includes services that do not solely rely on machine to machine
communication such as services delivered over telephone calls (voice or fax), email,
websites, Navtex and other “primitive” solutions.
The service registry is a central part of that vision. A registry contains service specifications
according to an envisioned Service Specification Standard and provisioned service instances
implemented according to these service specifications. The service registry aims at improving
the visibility and accessibility of available maritime information and services. This enables
service providers, consumers, and regulatory authorities to share a common view on service
standards and provisioned services. The service registry does not provide actual maritime
information but a specification of various services, the information they carry, and the
technical means to obtain it. The service registry also provides the mechanisms to manage
the life cycle of service specifications and service instances.
As depicted below, the service registry enables the “provider” to “publish” information related
to its service instances so that the “consumer” is able to “discover” them and obtain
everything (e.g. interface information) required to ultimately use these services.
Figure 2: Service Management Concept

The service registry is intended to facilitate or implement the Maritime Service Portfolio
(MSP) concept by providing a repository for the specification of operational and technical
services and provisioned service instances. The service registry is intended to comprise all
maritime services, not only digital services, thereby making it a single reference point for
provisioning and discovery.
The users of the service registry are primarily thought to fall within one of the following
categories.
Role Description
Service Consumer uses service instances provided by service providers.

Consumers
All users within the maritime domain can be service customers, e.g.,
ships and their crew, authorities, VTS stations, organizations (e.g.,
meteorological), commercial service providers, etc.
Service Provides instances of services according to a service specification.

Providers
All users within the maritime domain can be service providers, e.g.,
authorities, VTS stations, organizations (e.g., meteorological),
commercial service providers, etc.
Service Administrators handling the life-cycle of service instances.

Provisioning
administrators The provider of a service instance will be the owner and administrator
of each instance of service.
Service Administrators handling the life-cycle of service specifications e.g.

Specification adoption, retirement, etc.
Administrators
The issuer of a service specification will be the owner and administrator
of each specification.
Service Implementers of services from the service provider side and/or the
Specification service consumer side.
Implementers
Everybody can be a service implementer but mainly this will be
commercial companies implementing solutions for shore and ship.
Service Producers of service specifications in accordance with the Service

Specification Specification Standard.
Producers

6.2 Identity Management and Security
Identity management is an area that deals with identifying individuals such as users,
devices and computer systems and controlling their access to resources within some
kind of organizational context such as a private company, country, or a whole
industry.
Computer security is the protection of information systems from theft, disruption or
misdirection to the hardware, software, and information on them.
The identity of a ship is often addressed in terms of a ship’s name and IMO number. On
communication systems, the identity of a ship may be a callsign, MMSI number or system
specific terminal number. These identifiers are however just numbers – and there is no
guarantee that a signal identified by a specific callsign or MMSI number corresponds
correctly to a unique ship. Also none of these identity systems or registers takes into account
the need for dealing with actors who are not ships and don’t necessarily have their own radio
station, such as ship owners or service providers.
The lack of a global digital identity of users/vessels/systems is a serious bottleneck in starting
a digital maritime evolution across different companies and individuals. Just like human to
human communication on a worldwide scale would be impossible without having global
unique telephone numbers/email addresses. The same may be the case when trying to
integrate maritime systems on a global scale without a globally agreed upon concept of a
digital maritime identity for all the various actors that participate.
In order to alleviate this problem as well as addressing other issues that require
confidentiality and integrity, the Maritime Cloud provides a Maritime Identity Registry. This
registry provides an overview of managed identities of organizations, users, devices and
systems that need to communicate with each other in some way. There is no requirement
that the communication must take place over Maritime Cloud services such as the Maritime
Messaging Service. The registry can be integrated with any form of external information
carrier using standard security protocols.
The registry allows for managed human users to only need a single identity
(password/certificate) that can be used across many maritime systems. While
username/password is the initial focus, future versions will also support biometrics
(fingerprints, etc.) or devices (cell phones, smart cards) to be used for authentication of
users, as well as combinations of these into multi factor security.
The identity registry also supports a public key-infrastructure in order to provide digital
certificates and support confidentiality through encryption. This is primarily used for machine
to machine communication. For example, you can install a digital certificate on a ship or a
shore based station that will encrypt any message (if the communication protocol supports it)
being transmitted. Encrypted messages can then be decrypted only by intended recipients.
This infrastructure function also allows human actors to digitally sign messages or
documents. Making sure that nobody has tampered with the contents of important documents

is a mechanism that will allow other users or systems to validate messages for authenticity
and integrity later on.
Another core functionality provided by the Identity Registry is the support for federated
identity management. Most organizations that will use the Maritime Cloud will already have
their own Identity Management Systems managed by their IT departments. Since managing
private and highly confidential data is a sensitive topic, handing over the Identity
Management to a third party will not be possible for most organizations. Instead the Maritime
Cloud allows for integration with existing identity management systems in order to “reuse” the
identities already setup internally in an organization.
Security aspects may also require addressing less tangible issues such as recommendations
and guidelines on privacy or confidentiality of information shared, in order to facilitate
provision of information services. For example, many potential services could be location-
based. Locations might be considered sensitive, for example, when sailing in pirate waters,
or simply for reasons of privacy. Hence, it makes sense to provide (strict) guidelines on how
service providers should handle information about clients’ positions or other information
shared between providers and consumers of services, since it is impossible to provide
centralized control.

6.3 Almanac
The Almanac is an offline version of parts of the Identity and Service Registry, acting
as a ‘white/yellow pages phone book’.
The data stored in the Almanac can be updated, whenever a (suitably low cost or flat rate)
data connection is available. By using the Almanac, it is possible to automatically look-up
e.g., the MMSI number for a DSC call, VHF working channel or e-mail address, phone
numbers or other contact information of a VTS center, Port, the nearest MRCC or another
ship you may wish to contact. An on-board system or person might also look-up which
providers of a specific information service are available along a planned voyage.
Figure 3: Interactions with the Maritime Cloud Almanac Component
The basic architecture would be a single logical Almanac server that gathers updates from
the service and identity registry. Each ship can then query the Almanac server for updates
whenever a suitable connection is available. The Almanac server will typically be accessed
through the Maritime Cloud Client Component that is part of the reference implementation of
the Maritime Cloud. This client also takes care of storing updates and provides an interface
for querying the data stored in the Almanac. Equipment manufactures would not need to
implement any details of the protocol as all access to the actual data would flow through high
level interfaces exposed by the almanac client.

6.4 Maritime Messaging Service
The Maritime Messaging Service (MMS) is a proposed Messaging Service intended to

offer transparent seamless information transfer across different communication links
in a carrier agnostic and geolocation context sensitive manner.
The MMS primarily addresses ship-shore connectivity and will be based on internet
connectivity, yet any number of alternative communication services may be connected to and
utilized by the Maritime Messaging Service via dedicated gateways. This way, a message
sent by one specific ship using INMARSAT access to the MMS, may be received via a VSAT
terminal on another ship, an HF data connection on yet another ship, or a VTS operator on a
DSL landline internet connection.
Each communication service will impose technology and situation specific limitations in terms
of restrictions to capabilities, bandwidth availability, size of transferrable data packages,
latencies, etc. – but basic transfer of text or structured data (e.g., XML) will be possible.
Thus, when a maritime actor wishes to transfer information to another maritime actor or in
need of multicasting information to a group of actors, the MMS can ensure delivery across
whichever communication link is currently active at each relevant actor. Actors in a multicast
group thus do not need to be within range of a single communication link, and actors inside a
geographic multicast may be addressable by an information provider, although the identity
and exact position of the actors are unknown to the provider of information. In case a ship
temporarily has no active communication link, the MMS will function as a prioritized store-
and-forward queue of messages where the validity period can be defined for the messages
sent.
Through mechanisms of protocol level acknowledgements, the delivery of information via the
MMS can be quality assured.
The MMS mechanism requires each actor to maintain a persistent connection or regularly
establish a connection to the MMS, maintaining knowledge of which data links are open
towards each mobile actor. At each connect, or regularly, mobile actors provide a position
update at protocol level to the MMS, enabling a geographical awareness of the position of
each actor at the MMS. The geographical awareness may be strengthened through the
supplement of (satellite) AIS, providing high resolution but requiring no additional
communication. The geographic awareness enables ‘Geocasting’ – i.e. actors may logically
‘broadcast to’ or ‘listen to’ an area around their own position, regardless of which
communication link is used for broadcasting or listening in to the broadcast. Shore entities (or
military or law enforcement units) may ‘listen’ to geocasts of an area of interest without
specifying their position, and ships may listen to its current geographic context, without
exposing its own position to anyone else than the MMS, ensuring the privacy of own position
information.

Priority information such as safety-related information may be priority queued for delivery
according to priority, ensuring that messages with higher priority are handled before routine
traffic.

6.5 Maritime Cloud Client Component
The services of the Maritime Cloud will be provided to ship- and shore-side
applications by a Maritime Cloud client component.
This component allows for keeping the Maritime Cloud services abstracted from the physical
components and encapsulates the complexities of communication roaming. The Maritime
Cloud client will function as a local information hub, connected to relevant sensors,
navigation displays and communication equipment through relevant firewall arrangements.
The component's API will provide services for
• Secure authentication, signing and encryption support through online use of the
Maritime Identity Registry or offline use provided by the Almanac.
• Service discovery through online use of the Maritime Service Registry or offline use
provided by the Almanac.
• Service provision of dynamic services, e.g. a vessel providing its own position and
navigational data to a trusted party.
• Communication via the MMS through generic communication functions, providing

seamless roaming via available communication systems based on a user defined rule
set.

6.6 Data Flows
Data can be exchanged directly or using the Maritime Messaging Service.
Note: Data to be exchanged via the Maritime Cloud shall comply with defined and agreed
data modelling frameworks (e.g., IHO S-100 for e-navigation MSP’s).
Components connected to the Maritime Cloud can use two possible ways to communicate
with each other.
Both data flows are described using the same Actors, Maritime Cloud Core Services and
initial steps. On the actor side there are:
• A Weather Forecaster Alice – the Service Provider

• A Bridge Officer Bob – the Service Consumer
Participating system components are:
• Server– providing a Weather Forecast

• Client – providing the capability to display the Weather Forecast data
• Identity Registry – Maritime Cloud Core Service
• Service Registry – Maritime Cloud Core Service
The initial steps are always the same, and described in more detail in other sections of this
document.
1. Bridge Officer Bob requests a weather forecast via his client

2. Client automatically connects to the Service Registry and asks for a suitable weather
forecast service
3. Service Registry may, as any other service, utilize Identity Registry to authenticate the
Client’s request, where needs for access control apply
4. Service Registry provides a list of available Services (and instructions how to connect
to them) to the Client
5. Bridge Officer Bob decides to work with the Weather Forecast Service operated by
Alice

Then, the “switchboard” steps required before being

able to use the Maritime Cloud, are completed.
Now, there are two options possible for further data

exchange, dependent on a service design choice
made by Alice’s organization earlier.
(For the sake of simplicity the interactions with the

Maritime Cloud Core Services are not described in full
detail.)
Point To Point Communication Maritime Messaging Service
Alice decided to make her service available Alice decided to utilize the data transport
directly, and thus the Maritime Cloud is not capabilities of the Maritime Cloud, the
involved anymore in the communication Maritime Messaging Service (MMS).
between the server and the client. 6. Bob’s client connects to a MMS
6. Bob’s client connects directly to Server, and sends a request for a
Alice’s server, e.g., using standard weather forecast provided by Alice’s
web technologies, server,
7. Alice’s server verifies Bob’s identity 7. The MMS Server verifies Bob’s identity
using the Identity Registry, using the Identity Registry,
8. Bob can work with Alice’s weather 8. The MMS Server forwards the request
forecast. Bob’s request to Alice’s server
9. Alice’s Server provides a response
(the weather forecast) to the MMS
Server,
10. The MMS Server verifies Alice’s
identity using the Identity Registry,
11. Bob’s client picks up the weather
forecast from the MMS Server.

7 References
[1] DNV GL Strategic, “SHIP CONNECTIVITY.” April 2015.
[2] “Smart Grid Reference Architecture,” CEN-CENELEC-ETSI Smart Grid Coordination

Group, Nov. 2012.
[3] “NCSR 1-28 - Report to the Maritime Safety Committee, Annex 7” International
Maritime Organization, Sub-Committee on navigation communications and search and
rescue, Jul. 2014.
[4] “MSC85-26, Report Of The Maritime Safety Committee On Its Eighty-Fifth Session,
Addendum 1, paragraph 9,” Jan. 2009.
[5] EfficienSea2 Project (No 636329) Deliverable D3.1 “Analysis Report on Maritime
communication and infrastructure”

8 Abbreviations
AIS Automatic Identification System

API Application Programming Interface
BIMCO The Baltic and International Maritime Conference
World's largest international shipping association
CIRM Comité International Radio-Maritime
Principal international association for marine electronics
companies
DSL Digital Subscriber Line
EA Enterprise Architecture
ECDIS Electronic Chart Display and Information System
EU European Union
FAL Facilitation of International Maritime Traffic
GI Geospatial Information
GMDSS Global Maritime Distress and Safety System
IALA International Association of Marine Aids to Navigation and
Lighthouse Authorities
IEC International Electrotechnical Commission
IHO International Hydrographic Organization
IMO International Maritime Organization
IP Internet Protocol
ISO International Organization for Standardization
IT Information Technology
MAF Maritime Framework Architecture
MC Maritime Cloud
MMS Maritime Messaging Service
MMSI Maritime Mobile Service Identity
MRCC Maritime Rescue Coordination Centre
MSP Maritime Service Portfolio
NAVTEX NAVigational TEXt Messages
NCSR Navigation, Communications and Search and Rescue

SGAM Smart Grid Architecture Model

STM Sea Traffic Management
SWIM System Wide Information Management
TOGAF The Open Group Architecture Framework
VHF Very High Frequency
VoIP Voice Over IP
VTS Vessel Traffic Service
XML Extensible Markup Language


Deliverable 3.2 Conceptual Model

Uploaded by

Copyright:

Available Formats

Deliverable 3.2 Conceptual Model

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deliverable 3.2 Conceptual Model

Uploaded by

Copyright:

Available Formats

Document name:

E2 – D3.2 Conceptual Model

Project no. 636329

Start date of project: 1 May 2015

“This project has received funding from

D3.2 Conceptual Model

Project Title EfficienSea2

“This project has received funding from

Authoring & Approval

Prepared by – Authors of the document

Reviewed by – Reviewers internal to the project

Reviewed by – Reviewers external to the project

Version Date Status Author Description

“This project has received funding from

1 Vision for the Maritime Cloud ................................................................................................ 5

Figure 1: Use case mapping process .................................................................................... 10

“This project has received funding from

1 Vision for the Maritime Cloud

1.1 Mission Statement

1.2 Vision statement

“This project has received funding from

“This project has received funding from

“This project has received funding from

“This project has received funding from

3 Maritime Architecture Framework

MAF captures different aspects of maritime architectures mapped to a multidimensional

“This project has received funding from

Figure 1: Use case mapping process

MAF offers a three dimensional structure of architectural aspects, assembled in a meaningful

This framework is developed as an open governance concept to cover all social-technical

“This project has received funding from

4.1 Alice & Bob – A maritime cloud story

“This project has received funding from

“This project has received funding from

Services can be easily registered,

Identities can be verified and used to

Messages can be exchanged between

Geographic and organizational contexts

The maritime cloud offers a so-called Service Registry. You

Components connected to the cloud call the “operator”/service

Depending on the request (Name, Type, Location …) the end

Nowadays, daily processes include a lot of paper work. Documents need to

Every message can be certified using state-of-the art technologies.

Focusing on improving communication and digital interactions based on open

To the extent possible, there is no organizational change necessary.

“This project has received funding from

6 Core Components of the Maritime Cloud

Enabling services providers to deliver their services to customers with increased

Figure 2: Service Management Concept

“This project has received funding from

Service Consumer uses service instances provided by service providers.

Service Provides instances of services according to a service specification.

Service Administrators handling the life-cycle of service instances.

Service Administrators handling the life-cycle of service specifications e.g.

Service Producers of service specifications in accordance with the Service

“This project has received funding from

6.2 Identity Management and Security

“This project has received funding from