DIGIT – DIRECTORATE GENERAL INFORMATICS
DG MARE – DIRECTORATE GENERAL MARITIME AFFAIRS AND FISHERIES
Draft CISE Architecture Vision Document
Date:
Version:
11/12/2012
1.05
Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11.
Office: 05/45. Telephone: direct line (32-2) 2999659.
Commission européenne, L-2920 Luxembourg. Telephone: (352) 43 01-1.
Draft CISE Architecture Vision Document
Document Control Information
Settings
Document Title:
Project Name:
Document Authors:
Value
Draft CISE Architecture Vision Document
CISE Support
DIGIT;DG MARE
Project Managers:
Marta Silva-Mendes (DIGIT); Olivier Fontaine (DG MARE)
Revision Status:
1.05
Issue Date:
11/12/2012
Document Approver(s):
(All Approvers are required. Records of each approver must be maintained.)
Approver Name
[Name]
Role
Choose Role.
Choose Role.
Choose Role.
Document Reviewers: (Records of each required reviewer must be maintained.)
Reviewer Name
[Name]
Role
Choose Role.
Choose Role.
Choose Role.
Summary of Changes:
The Document Author is authorised to make the following types of changes to the document without
requiring that the document be re-approved:
 Editorial, formatting, and spelling
 Clarification
To request a change to this document, contact the Document Author or Owner.
Changes to this document are summarised in the following table in reverse chronological order (latest version
first).
Revision
Date
Created by
Short Description of Changes
Configuration Management: Document Location
The latest version of this controlled document is stored in [this location].
Date: 11/12/2012
Version: 1.05
i
Draft CISE Architecture Vision Document
TABLE OF CONTENTS
0. HOW TO READ THIS DOCUMENT ........................................................................................................ IV
0.1. How to provide comments on this document ........................................................................................ iv
1. INTRODUCTION.....................................................................................................................................1
1.1. Overview .................................................................................................................................................. 1
1.2. Why is an architecture vision document needed? ................................................................................... 1
1.3. Approach .................................................................................................................................................. 2
1.4. Visions at a glance .................................................................................................................................... 5
1.5. Defining CISE in simple terms .................................................................................................................. 8
1.6. Selecting a preferred target operating model for CISE ............................................................................ 9
1.7. Where can I find information about the as-is state of maritime surveillance? ..................................... 10
1.8. Glossary .................................................................................................................................................. 11
1.9. Acronyms ............................................................................................................................................... 14
2. ARCHITECTURE VISIONS FOR CISE ....................................................................................................... 16
2.1. How to read the architecture visions ..................................................................................................... 16
2.2. Background information ........................................................................................................................ 17
Vision 1 – Interconnected Public Authority Systems .................................................................................... 19
Vision 2 – Interconnected Public Authority Gateways .................................................................................. 27
Vision 3 – Interconnected National Gateways .............................................................................................. 35
Vision 4 – Interconnected National Nodes ................................................................................................... 43
Vision 5 – Sea-Basin Coordinated National Nodes........................................................................................ 52
Vision 6 – EU Coordinated National Nodes ................................................................................................... 61
Vision 7 – Interconnected User Community Nodes ...................................................................................... 70
3. PRINCIPLES OF CISE ............................................................................................................................. 76
4. REQUIREMENTS FOR CISE ................................................................................................................... 79
4.1. Sharing of information ........................................................................................................................... 80
4.2. Discovery of information ....................................................................................................................... 81
4.3. Information assurance ........................................................................................................................... 81
4.4. Information security .............................................................................................................................. 82
4.5. Collaboration between CISE participants ............................................................................................... 83
4.6. Organisational aspects ........................................................................................................................... 84
4.7. Recommendations to CISE participants ................................................................................................. 84
4.8. Additional requirements ........................................................................................................................ 85
5. OPERATIONAL WORKFLOWS............................................................................................................... 87
6. BIBLIOGRAPHY .................................................................................................................................... 88
END NOTES ............................................................................................................................................. 89
ANNEX 1
ARCHIMATE REFERENCE ....................................................................................................... 90
Date: 11/12/2012
Version: 1.05
ii
Draft CISE Architecture Vision Document
Urgency and a strong guiding team
are necessary but insufficient
conditions for major change. Of the
remaining elements that are always
found in successful
transformations, none is more
important than a sensible vision –
John P. Kotter [5]
Date: 11/12/2012
Version: 1.05
iii
Draft CISE Architecture Vision Document
0. HOW TO READ THIS DOCUMENT
This document provides an understanding of the possible target states for the Common Information Sharing
Environment for maritime surveillance of the European Union (CISE). To achieve this, the reader is
recommended to:

Read the introduction in Chapter 1 before reading the visions described in Chapter 2.
The first chapter explains how the visions are organised and their link to the European Interoperability
Framework.

Read section 2.1 of Chapter 2 before reading the structured descriptions of each vision.
The second chapter explains each aspirational vision for CISE in a structured way. The template is
explained in the first section of this chapter.

Consult chapter 3 to know more about the principles of CISE.
The third chapter shows the Identified and documented principles of CISE.

Consult chapter 4 to know the requirements of CISE. This is work in progress and this catalogue will
continue to be updated.
The fourth chapter shows the Identified and documented requirements of CISE.

Consult chapter 5 to understand the operational requirements that CISE should support.
The fifth chapter presents the operational workflows of CISE.
The last chapter lists the bibliography used in this document.
This document provides a “big picture” view of how CISE will operate in the future. Once the Architecture
Vision is agreed, it will be used as the basis for developing more detailed designs including the identification
of actual Solution Building Blocks. This document deals with the conceptualization of CISE’s Architectural
Building Blocks and how they may be implemented.
This document is written to support decision-making, therefore:

It does not embrace every detailed aspect of CISE, instead, it focuses on those aspects that are
relevant for an agreement on CISE’s target operating model;

It uses several images and diagrams to convey the “vision” – these visual elements summarise the
textual explanations in the document;

It provides a structure for discussing about how CISE should be implemented and what the next steps
should do to ensure that this happens.
Please provide your comments concerning this document in line with the guidelines provided in the following
section 0.1 “How to provide comments on this document”; and address them to the project managers
indicated in this document’s control information.
0.1. How to provide comments on this document
As per CISE governance structure, all major deliverables produced in the context of CISE undergo a “Review
Cycle”, during which key stakeholders are invited to provide their comments.
Date: 11/12/2012
Version: 1.05
iv
Draft CISE Architecture Vision Document
Since the document authors needs to collect, compare and analyse the feedback from 27 Member States on
the same document –potentially leading to a large number of comments – a tool is used that allows for easy
extraction and aggregation of the comments from MS Word documents. In order for this tool to be able to
capture all of your comments, please apply the following guidelines when commenting on this document:





All comments are to be written in plain English. Comments provided in other languages cannot,
unfortunately, be taken into account.
The comments must be specific to and must relate to the text (sentence and/or paragraph) being
revised.
In case that you want to provide general comments or remarks that are not specific to a part of the
text of this document, please provide them in a separate document and/or e-mail.
Please use simple wording and be as specific, concise and clear as possible in order to avoid
ambiguities.
When referring to specific terms, acronyms or abbreviations that are common in your daily jargon,
but that are not defined in the Glossary of this document, please define them first.
An MS Word comment is typically displayed as a red balloon in the right margin of the document and usually
starts with the abbreviation of your name and the timestamp of when the comment was written. Depending
on your version of MS Word, use the following steps for inserting a comment:
MS Word 2007 and MS Word 2010:
1. Write your comments directly in this MS Word document by first selecting a word, a part of a
sentence or a paragraph (this can be done for example by double-clicking on a word or by dragging
your mouse over parts of the text while keeping the left mouse button pressed).
2. Open the Review ribbon, select New Comment in the Comments section;
3. In the balloon that appears in the right margin, type your comment;
4. Click anywhere in the document to continue editing the document.
MS Word 2003:
1. Write your comments directly in this MS Word document by first selecting a word, a part of a
sentence or a paragraph (this can be done for example by double-clicking on a word or by dragging
your mouse over parts of the text while keeping the left mouse button pressed).
2. From the Insert menu, select Comment (or click on the New Comment button on the Reviewing
toolbar);
3. In the balloon that appears in the right margin, type your comment;
4. Click anywhere in the document to continue editing the document.
The text will have coloured lines surrounding it, and a dotted coloured line will connect it to the comment. To
delete a comment, simply right click on the balloon and select Delete Comment.
Attention:

Please note that a minimum of 4 characters must be selected in order for our commenting tool to
grab the comment. Furthermore, comments on diagrams and embedded pictures are also not taken
into account. In such cases, please select the caption text underneath the diagram or image.
Date: 11/12/2012
Version: 1.05
v
Draft CISE Architecture Vision Document



Please do not use the MS Word “track changes” tool and do not write your comments as plain text in
the MS Word file.
In case you need to translate this document to another language, and then translate your comments
back to English, please make sure that your comments are provided in the form described above and
that they have not been altered or moved to another section of the text during the translation
process.
If the comment is considered very important, please include the prefix 'MAJOR' in your comment.
Date: 11/12/2012
Version: 1.05
vi
Draft CISE Architecture Vision Document
1. INTRODUCTION
1.1. Overview
Maritime surveillance refers to the effective understanding of all activities carried out at sea that could impact
the security, safety, economy or environment of the European Union and its Member States. Seven different
user communities are relevant for maritime surveillance: law enforcement, customs, maritime environment,
maritime safety and security, defence, fisheries control and border control. The current maritime surveillance
operating model does not enable information sharing across communities, leading to inefficiencies and
duplication of efforts. To join forces between maritime authorities in the EU Member States, several
initiatives, at several levels, have emerged over the past years to tackle cross-border interoperability barriers.
The next step is to remove the cross-sectoral barriers which prevent information from flowing between
communities. This is why, since 2009, the European Commission and the EU Member States have been
working on a Common Information Sharing Environment for maritime surveillance.
The Common Information Sharing Environment for maritime surveillance of the European Union is being
defined by the European Commission and the EU Member States since 2009. In the last years, in preparation
for CISE, several initiatives have been set into motion to initiate the exchange of maritime information not
only across borders, but also across sectors. Among these initiatives are the “MARSUNO” pilot project in the
Northern sea-basins; and the “BLUEMASSMED” pilot project in the Mediterranean sea-basin. Furthermore,
and as explained before, EU-systems are already operational in several maritime surveillance sectors e.g.
SafeSeaNet (vessel traffic monitoring and information system).
For the time being, several aspirational visions for CISE coexist through the different existing initiatives and
stakeholders. This document describes each one of these aspirational visions and presents them in a
structured and factual manner as to allow for the selection of the preferred vision(s) for the realisation of
CISE. In simple terms, the purpose of this document is to support Member States in the selection of a
preferred target vision, by which CISE can realise its value proposition.
1.2. Why is an architecture vision document needed?
Conceiving well structured visions for CISE (also referred to as architecture visions) is imperative as a decision
making tool for selecting the preferred target vision and in setting a commonly agreed direction for the
project as a whole. The Architecture Visions document defines the architectural options for CISE by drawing
inspiration from related initiatives and by building on the study of “current surveillance IT landscape” [1]. Each
vision is therefore described in a structured template based on defined terminology. This allows for easy
comparison of visions, which in turn facilitates the selection of a target state according to well defined
criteria. Describing aspirational visions for CISE is imperative because creating an information sharing
environment without a defined target state and an agreed way forward is likely to lead to an unsuccessful
result. The Architecture Visions document makes visible the possible levels of intricacy (i.e. the number of
different elements) and complexity (i.e. the number of relationships between elements) of all possible future
target states. Several studies show that the more intricacy and complexity:
 start-up costs tends to increase;
 speed to scale tends to decrease; and
 support and maintenance costs will tend to increase.
Therefore, it should be kept in mind that CISE should, where possible, avoid having too many elements and
minimise the number of relationships needed between them, as long as being sufficiently rich to meet the
agreed requirements. The next sections will explain how interoperability agreements are a way to remove
Date: 11/12/2012
Version: 1.05
1
Draft CISE Architecture Vision Document
complexity and intricacy, as well as other information sharing barriers. The key difference between the
architecture vision document and the technical specifications study of CISE lies in the level of detail. The
architectural vision operates at a high level of abstraction with less detail and does not prescribe solution
building blocks. The technical specifications study will define the lower level of abstraction of the preferred
architecture vision(s). The solution building blocks elements at the technical level, prescribed in the preferred
architecture vision(s), will be designed by the technical specifications study in a similar way as the cooperation
project will do at the semantic level.
1.3. Approach
The visions for CISE could have been created following a classic “top-down” approach, i.e. starting from the
requirements of CISE, or a “bottom-up” approach starting from the analysis of the systems which will share
information through CISE. A combination of both approaches was used to put together the six visions
described in this document.
EU Coordinated National Nodes
Vision 6
Sea-Basin Coordinated National Nodes
Vision 5
Interconnected National Nodes
Vision 4
Interconnected National Gateways
Vision 3
Interconnected Authority Gateways
Vision 2
Vision 1
Interconnected Authority Systems
As-is
Figure 1 – Architecture Visions
The visions were collected from the several ongoing initiatives without any “pre-judgement” of their fit. This is
why the requirements of CISE are not the starting point of the visions. Applying selection criteria, including
the requirements coverage, comes as a second step. Each vision is described using a template structured
according to the European Interoperability Framework (EIF) of the EU programme for “Interoperability
Solutions for European Public Administrations” (ISA Programme)1. ISA sponsors the CISE project, as it aims at
facilitating efficient and effective digital interaction between public administrations in Member States. ISA’s
interoperability framework is “an agreed approach to interoperability for organisations that wish to work
together towards the joint delivery of public services”. This framework describes four levels of interoperability,
which deserve special attention when implementing cross-border/cross-sector services. The several visions
are organised in a way that interoperability agreements are gradually added to the present condition, one on
top of the other. As explained in the EIF, interoperability agreements are the means through which
participants of large ICT projects formalise cooperation with one another. These agreements aim at leaving
each Member State with maximum internal autonomy, while creating an area of cooperation where
information can flow without interoperability barriers. In other words, interoperability agreements remove
barriers for information sharing across borders and sectors.
Date: 11/12/2012
Version: 1.05
2
Draft CISE Architecture Vision Document
Legal interoperability
• Aligned legislation so that exchanged data is accorded
proper legal weight
Organisational Interoperability
• Coordinated processes in which different
organisations achieve a previously agreed and
mutually beneficial goal
Semantic Interoperability
• Precise meaning of exchanged information which is
preserved and understood by all parties
Technical Interoperability
• Planning of technical issues involved in linking
computer systems and services
Impact assessment
Architectural Vision
document
Figure 2 – Interoperability levels of the European Interoperability Framework
The architecture visions explained in this document answer three main questions:
A.
What is the desired level of technical interoperability among CISE participants?
At technical level, CISE’s participants will offer services to one another. In this document, a service is defined
as a unit of functionality that a Member State or the Commission exposes to other participants of CISE. These
services are accessible through an interface. These interfaces will support a message-driven interaction model
similar to the one used in most EU-wide information exchange projects such as CCN/CSI of TAXUD, the Large
Scale Pilots of DG CONNECT, VIS and SIS II of DG HOME, etc. This means that CISE participants will interact
with each other by exchanging messages. This does not apply to the real-time collaborative features of CISE
such as video, voice and instant messaging. A message exchange will happen when CISE participants share
information on request or when they communicate notifications. CISE participants will play the role of
“Provider” when offering a service and of “Consumer” when using a service. Interacting with services has the
following implications:
 The services’ functional details must be specified. This includes specifying the syntax and semantics
of the services’ messages e.g. the headers of these messages;
 The services’ communication details must be specified. This includes specifying which network
transport protocols and application-level protocols are supported;
 The services’ security details must be specified. This includes specifying how consumers are
authorised and authenticated;
 The services’ behaviour must be specified. This includes specifying the services’ interaction patterns
such as request/ response or notification.
To conclude, technical interoperability agreements mean reaching consensus on a common information
sharing interface (also referred to as service interface) through which services can be offered.
Date: 11/12/2012
Version: 1.05
3
Draft CISE Architecture Vision Document
B.
What is the desired level of semantic interoperability among CISE participants?
In the context of semantics, interoperability agreements mean reaching consensus on CISE’s data model for
information sharing. This encompasses specifying a common data dictionary, common controlled vocabularies
(e.g. code lists) and the semantics of the data payload(s) which will be exchanged within the services’
messages. For sharing and reusing of information to happen, an access rights model and a licensing
framework need to be defined.
C.
What is the desired level of organisational interoperability among CISE participants?
In the organisational context, interoperability agreements imply consensus on CISE’s organisational model at
national, sea basin or EU level. Alternatively, these agreements may also be reached between user
communities, please refer to the figure below.
Defence
Law Enforcement
Border Control
Customs
Maritime Environment
Fishery Control
Maritime Safety and Security
CISE’s User communities
European Union
Sea Basin
Member State
Authority
CISE’s
organisational
levels
Figure 3 - Organisational levels and User communities
This document does not touch upon the legal interoperability layer. Nevertheless, as it touches upon
technical, semantic and organisational choices that involve political decision making at EU and national level,
it is meant to be complementary to a parallel impact assessment. Indeed, such impact assessment will
examine various political options on how to remove legal barriers to cross-sectoral information exchange
while taking account of the costs and benefits of doing so. The assessment of the legal options should also
take into account the principles of subsidiarity and proportionality, established in Article 5 of the Treaty on
EU, are fundamental to CISE. These principles together determine the level of power EU can exercise, limiting
EU’s involvement to relevant areas of competence. In fine, the architectural visions of this document should
be combined with the results of the impact assessment with a view to finding common grounds for proposing
the appropriate choice. Finding such common grounds, expressed in interoperability agreements, is a process
that needs to be achieved by the Commission together with the Technical Advisory Group (TAG) and the
Member States Expert subGroup (MSEsG) on integration of maritime surveillance. The figure below maps the
several ongoing initiatives of CISE to the EIF.
Date: 11/12/2012
Version: 1.05
4
Draft CISE Architecture Vision Document
Political context
Legal interoperability
MS Expert group
TAG
Policy
Option 1
Policy
Option 2
Policy
Option 4
Policy
Option 5
EC and MSs
Policy
Option 3
Organisational Interoperability
Vision 6
Impact
Assessment
Architecture Visions document
composed of:
- 6 Visions for CISE’s Target
Operating Model
- Principles and Requirements
Vision 5
Semantic Interoperability
Vision 4
Vision 3
Vision 2
Vision 1
Technical Interoperability
As-is
Figure 4 – EIF mapped to CISE initiatives
1.4. Visions at a glance
As explained in the previous sections, six architecture visions were collected, taking inspiration from existing
initiatives. The visions are presented in such an order that each vision gradually adds the level interoperability
agreements, one on top of the other. The visions are summarised in the table below with a summary of the
interoperability agreements that are required to realise each vision.
Date: 11/12/2012
Version: 1.05
5
Draft CISE Architecture Vision Document
Vision Vision Name
Nr.
1
Interconnected
Authority
Systems
2
3
4
Description
Interoperability agreements
Each maritime authority independently exposes a set of services using a
commonly agreed information exchange model (the technical service
interface and transport protocol are not standardised). Authorities acting
as service consumers have to find and connect point-to-point to the
services of the information sources of their interest. Technical bilateral
agreements are needed to overcome the lack of a commonly agreed
service interface.
Interconnected Each authority, as service consumer, needs to understand which services
Authority
are made available by the authorities in each Member State and User
Gateways
Community. To facilitate information exchanges, a standardised
“gateway” is specified. It consists of an information exchange model, a
transport protocol and the technical service interface. Each information
source uses the gateway specifications to enable access to its
information. Information consumers also rely on the gateway
specifications to use services from other authorities.
Interconnected Each authority independently implements a set of services using a
National
commonly agreed information exchange model, transport protocol and
Gateways
service interface through a standardised “gateway” at national level. The
national gateway is used by all public authorities in a Member State. The
gateway has routing functionalities, meaning that public authorities no
longer need to be aware of where to get information. Service consumers
request information through the national gateway (which is
interconnected to other national gateways), which routes the request to
the authorities offering that information. Point-to-point connections are
possible between 2 authorities if needed.
•
•
•
•
•
•
•
•
•
Interconnected Each authority connects its information sources holding information •
National
relevant to maritime surveillance to a national node. The node stores the
Nodes
information from the several information sources within a Member State,
Date: 11/12/2012
Version: 1.05
Organisational – None.
Semantic – Commonly agreed
information exchange model; access
rights and licensing model.
Technical – None.
Page
Reference
19
Organisational – None.
27
Semantic – Commonly agreed
information exchange model; access
rights and licensing model.
Technical –transport protocol and
technical service description, packaged
as gateway specifications and reference
implementation.
Organisational – Connections to national 35
gateway, based on a community
agreement. This enables cross-sector
information exchanges.
Semantic – Commonly agreed
information exchange model; routing
rules; access rights and licensing model.
Technical –transport protocol and
technical service description, packaged
as gateway specifications and reference
implementation.
Organisational – Connections to national 43
node, based on a community agreement.
This enables cross-sector information
6
Draft CISE Architecture Vision Document
5
6
Sea-Basin
Coordinated
National
Nodes
EUCoordinated
National
Nodes
Date: 11/12/2012
pre-processes it and exposes a set of services to CISE users through a
commonly defined service interface, transport protocol and information
exchange model. Authorities retrieve maritime surveillance information
by connecting to their national node (which is interconnected to other
national nodes). Unlike the previous visions, the node is an advanced
gateway, which could fuse information. Point-to-point connections are
possible between 2 authorities if needed.
Each authority connects its information sources holding information
relevant to maritime surveillance to a national node. The node stores
information from several information sources within a Member State,
pre-processes it and exposes a set of services to CISE users through a
commonly defined interface and information exchange model. These
nodes are then clustered per sea-basin to a higher level node that
coordinates information sharing within the given sea basin area.
Authorities retrieve maritime surveillance information by connecting to
their national node, which is interconnected to the sea basin node (which
in turn is interconnected to other sea basin nodes). Point-to-point
connections are possible between 2 authorities if needed.
•
•
•
•
•
Each authority connects its information sources holding information •
relevant to maritime surveillance to a national node. The node stores
information from several information sources within a Member State,
pre-processes it and exposes a set of services to CISE users through a
commonly defined interface and information exchange model. These
nodes are then connected to a single, central coordinator that •
coordinates information sharing between all Member States. Authorities
consuming information services connect to their national node, which is
interconnected to the central coordinator. Point-to-point connections are
possible between 2 authorities if needed.
•
Version: 1.05
exchanges.
Semantic – Commonly agreed
information exchange model; routing
rules; access rights and licensing model;
aggregation rules.
Technical – Node specifications and
reference implementation.
Organisational – Connections to national 52
node, based on a community agreement.
This enables cross-sector information
exchanges. Agreement on single access
point in sea-basin.
Semantic – Commonly agreed
information exchange model; routing
rules; access rights and licensing model;
aggregation rules.
Technical – Node and coordinator
specifications and reference
implementation.
Organisational – Connections to national 61
node, based on a community agreement.
This enables cross-sector information
exchanges. Agreement on single access
point in EU.
Semantic – Commonly agreed
information exchange model; routing
rules; access rights and licensing model;
aggregation rules.
Technical – Defines node and
coordinator specifications and reference
implementation.
7
Draft CISE Architecture Vision Document
To create a sharing environment among seven maritime surveillance communities, CISE participants will
formalise their intent to cooperate with each other through interoperability agreements. The figure below
further details the interoperability agreements in the six visions described in this document. The multi-vision
structure starts from a vision with only the most fundamental agreements at semantic level. The other visions
are formed by adding agreements at the technical and organisational levels. This means that each vision
roughly builds on top of the other sequentially. To remove sectoral barriers to information sharing, it is
essential that Member States implement a single access point at national level. Otherwise, CISE participants
would need to understand the organisational diversity of one another. If the organisational level is left
untouched, important barriers to information sharing across sectors will not be removed. It is logical to say
that if information sharing is imposed at policy level, the more barriers to information sharing across borders
and sectors should be removed. If these are not removed, CISE will be significantly less effective.
Independently of the vision to be selected, further agreements can always be reached through voluntary
action by the Member States e.g. through bilateral agreements.
Organisational
Interoperability
agreements
As-is
Vision 1
Vision 2
Vision 3
Vision 4
Vision 5
Vision 6
National single
access point
Sea basins with single
access point
EU single access
point
Semantic
Access rights and
licensing model*
Information
exchange model
Routing rules
Aggregation rules
Technical
Standardised
Gateway
Standardised node
Sea basin
coordinator
EU coordinator
*
It is debatable whether the access rights should be classified at this level, the rationale for doing it is that it strongly relates to the datasets themselves
EU-wide interoperability agreements to reduce cross-border and cross-sector barriers
Voluntary bilateral agreements
Figure 5 – Summary of interoperability agreements
1.5. Defining CISE in simple terms
Having in mind the previous section, CISE can be defined as a set of interoperability agreements that enable
Member States to setup information sharing services and a set of supporting, common services. Although not
tightly linked to the information sharing specifications, the common services should support them. The
common services are loosely coupled from the interoperability agreements for information sharing as they
Date: 11/12/2012
Version: 1.05
8
Draft CISE Architecture Vision Document
require less consensus building i.e. they do not need to be implemented by each Member State. We can
further precise what CISE is, by looking at this definition in more detail.
1.5.1. CISE is a set of interoperability agreements
The interoperability agreements of each architecture vision hold CISE’s common specifications for information
sharing. To ensure that they evolve over time they should be maintained by a central authority at EU level.
This entity should co-ordinate their further improvement, support their adoption and operate change
management processes.
1.5.2. CISE is a set of common services
In addition to the interoperability agreements for information sharing, CISE will also encompass a set of
common services. They are common because they are specified at the EU level for all CISE participants. These
common services will include applications such as a common register of CISE participants and a common
register of CISE services. The common services support CISE participants in sharing, retrieving and discovery of
information.
1.6. Selecting a preferred target operating model for CISE
As explained in the previous sections, this document presents not one, but six choices for the target operating
model of CISE. The figure below shows that these visions move along two axes: “the number of points of
contact” and “the number of common specifications”.
Access rights and
licensing model
Access rights and
licensing model
Access rights and
licensing model
Access rights and
licensing model
Information
exchange model
Information
exchange model
Information
exchange model
Information
exchange model
Information
exchange model
Aggregation
rules
Aggregation
rules
Routing rules
Routing rules
Routing rules
Standardised
Gateway(s)
Standardised
Node(s)
Std. Node(s) &
Coordinator
Custom
Interfaces
Standardised
Gateway(s)
Semantic
Custom
Interfaces
Access rights and
licensing model
Vision 3
Vision 6
Single point
at EU level
Vision 5
Sea basins
with single
access point
Single
national point
of access
Vision 4
Several
national points
access
As-is
-
Vision 1
Organisational
Common Points of Contact
+
Technical
Each
organisation has
it own point of
access
Vision 2
Common specifications
+
Figure 6 – Drivers of the architecture visions
The selection framework shown in the visions is designed to assist Member States in selecting a single vision
for implementation. If more than one is selected, it is not recommended to choose dissimilar visions.
Date: 11/12/2012
Version: 1.05
9
Draft CISE Architecture Vision Document
Combining unalike visions is not recommended because that would lead to CISE participants being exposed to
the organisational diversity of one another. Visions with a similar set of common specifications and contact
points may be selected together. As they look alike, similar visions can coexist with fewer unanticipated and
undesired consequences. In other words, CISE’s target state should not allow too many variations among
Member States so that it does not end up resembling the current state. Should this happen, the EU
investment on CISE would not have led to a state where maritime surveillance is integrated and cross-sectoral
barriers have effectively been removed. Instead it would just lead to a different kind of complexity, meaning
that the time required to access information would not be reduced and the decisional process would not be
improved.
It should be highlighted that the visions explained in the next chapters have a degree of space for Member
States to implement them according to their own context. As explained in the previous section, Member
States can always add more interoperability agreements to a given vision. It also happens that they are also
able to “scale down” a chosen vision. The arrows in the diagram below show the degree of freedom of each
vision. This will be further explained in the structured description of each vision.
Access rights and
licensing model
Access rights and
licensing model
Access rights and
licensing model
Access rights and
licensing model
Information
exchange model
Information
exchange model
Information
exchange model
Information
exchange model
Information
exchange model
Aggregation
rules
Aggregation
rules
Routing rules
Routing rules
Routing rules
Standardised
Gateway(s)
Standardised
Node(s)
Std. Node(s) &
Coordinator
Custom
Interfaces
Standardised
Gateway(s)
Semantic
Custom
Interfaces
Access rights and
licensing model
Vision 3
Vision 6
Single point
at EU level
Vision 5
Sea basins
with single
access point
Single
national point
of access
Vision 4
Several
national points
access
As-is
-
Vision 1
Organisational
Common Points of Contact
+
Technical
Each
organisation has
its own point of
access
Vision 2
Common specifications
+
Figure 7 – Possible variants of each vision
1.7. Where can I find information about the as-is state of maritime surveillance?
A study on the current surveillance IT landscape and the resulting high-level options for CISE was conducted
by a contractor earlier this year (2012). The objectives of this study included e.g. ensuring a better
understanding of the initiatives and projects that could potentially be reused in view of establishing CISE; and
to perform technical analyses of a set of information systems for information availability and exchange [1].
Date: 11/12/2012
Version: 1.05
10
Draft CISE Architecture Vision Document
1.8. Glossary
Term
Definition
Aggregation (of information)
A function where requested information from multiple sources are
grouped together to form a single response e.g. a list or a set.
Agreement
A contract between one or more authorities acting as information
providers and one or more authorities acting as information consumer to
define the term and conditions for accessing and providing services. Can
be bi-lateral (between 2 authorities) or community agreement (between
more than 2 authorities). May include service level specifications in the
form of Service Level Agreements (refer to SLAs).
Application
Software designed to perform specific tasks and that exposes certain
functionalities through interfaces.
Authority (or public authority)
Any organisation that has an interest in maritime surveillance
information. An authority can be local, regional, national or European
level.
Throughout this document, the terms authority and public authority are
used interchangeably.
Architecture
The structure of components, their inter-relationships, and the principles
and guidelines governing their design and evolution over time.
Architecture building blocks
A constituent of the architecture model that describes a single aspect of
the overall model. These elements typically describe required capability
and shape the specification of Solution Building Blocks.
Broadcasting
A type of message distribution where a message is sent to all members,
rather than specific members, of a group such as a department or
enterprise.
Clustered system
An architecture that ties together authority systems with the use of
nodes. Clustering provides access to all files from any of the clustered
nodes regardless of the physical location of the file.
Complexity
The number of relationships between elements.
Acts as an information sharing barrier in technology architectures.
Coordinator
A type of a node that clusters other nodes. Similarly to nodes,
coordinators can have programmed or engineered capability to recognise
and process (e.g. aggregate) or forward messages to other nodes or
authority systems.
Implements specifications e.g. commonly agreed information exchange
model, transport protocol and service interface.
Correlation (of information)
A function where requested information from multiple sources are
analysed to determine what relationships between the information exist.
Data
Facts represented in a readable language (such as numbers, characters,
images, or other methods of recording) on a durable medium. Data on its
Date: 11/12/2012
Version: 1.05
11
Draft CISE Architecture Vision Document
own carries no meaning, but when given context, data becomes
information.
Fusion (of information)
A function where requested information from multiple sources are
blended to form a single response.
Fusion of data fills information gaps and can reduce the uncertainty in
information received from various sources.
Gateway
A connection point in a network. The gateway converts information, data
or other communications from one protocol or format to another.
Implements specifications e.g. commonly agreed information exchange
model, transport protocol and service interface.
Information
Contextual meaning associated with, or derived from, data.
Information consumer
A role assumed by a participant to facilitate interaction and connectivity
in the use of services.
Information exchange model
A logical representation to illustrate the structure, semantics, and
relationships of information.
Information owner
A user who ensures the consistency and validity of information. They
define the security needs of the information for which they are
responsible.
Information ownership means identifying which participants have the
right to change information, together with their obligation to determine
impact and notify all impacted parties. Typically, each authority as the
owner of its information may define the rules for access to its
information.
Information provider
A role assumed by a participant to facilitate interaction and connectivity
in the exchange of information.
Information source
Authentic provenance of the information.
Interoperability
Interoperability, within the context of European public service delivery, is
the ability of disparate and diverse organisations to interact towards
mutually beneficial and agreed common goals, involving the sharing of
information and knowledge between the organisations, through the
business processes they support, by means of the exchange of data
between their respective ICT systems.
Interoperability agreement
Means of reaching consensus on a common information sharing interface
(also referred to as service interface) through which services can be
offered. There are 3 different types of interoperability agreements:
semantic, technical and organisationa.
Interoperability framework
An interoperability framework is an agreed approach to interoperability
for organisations that wish to work together towards the joint delivery of
public services. Within its scope of applicability, it specifies a set of
common elements such as vocabulary, concepts, principles, policies,
guidelines, recommendations, standards, specifications and practices.
Date: 11/12/2012
Version: 1.05
12
Draft CISE Architecture Vision Document
Intricacy
The state of containing a large number of parts or details.
Acts as an information sharing barrier in technology architectures.
License
A licence is a document containing provisions allowing or restricting
actions and uses normally reserved for the copyright holder.
Node
A connection point in a network that clusters authority systems or other
nodes. In general, a node has programmed or engineered capability to
recognise and process (e.g. aggregate) or forward messages to other
nodes or authority systems.
Implements specifications e.g. commonly agreed information exchange
model, transport protocol and service interface.
Notification
A service that can be used to inform many authorities at once (e.g. by
broadcast).
Payload
The essential bits of data that are being carried within a message
“packet”. The payload does not include the “overhead” data required to
get the packet to its destination.
Principle
They provide for a high level design rationale, which must always be
taken into account when creating, changing or removing any CISE-related
element.
Proportionality
Similarly to the principle of subsidiarity, the principle of proportionality
regulates the exercise of powers by the European Union. It seeks to set
actions taken by the institutions of the Union within specified bounds.
Under this rule, the involvement of the institutions must be limited to
what is necessary to achieve the objectives of the Treaties. In other
words, the content and form of the action must be in keeping with the
aim pursued.
The principle of proportionality is laid down in Article 5 of the Treaty on
European Union. The criteria for applying it is set out in the Protocol (No
2) on the application of the principles of subsidiarity and proportionality
annexed to the Treaties.
Protocol (or transport protocol)
A set of procedures in information exchange that the authority systems
or nodes use to send messages back and forth. Networks and systems
cannot communicate unless they use the same protocol or make use of a
gateway.
Request (or information request)
A message sent from an information consumer to an information
provider, asking for information according to a certain criteria with the
use of a common information exchange model.
Requirement
Determine the expectations of the stakeholders with regards to
information sharing and discovery, information assurance and security,
collaboration, organisation, etc.
Routing
Functionality of forwarding messages without the information consumer
and provider having to know each other. Usually present in nodes and
coordinators.
Date: 11/12/2012
Version: 1.05
13
Draft CISE Architecture Vision Document
Sea basin
This refers to the following sea regions: Baltic Sea, Black Sea,
Mediterranean Sea, North Sea, the Atlantic and the Arctic Ocean.
Service
A unit of functionality that an authority exposes to other participants of
CISE. These services are accessible through a service interface.
Service interface
A point of access where a service is made available to another
application.
Service Level Agreement
A service-level agreement (SLA) is a contract between an information
provider and an information consumer that specifies, usually in
measurable terms, what services the information provider will furnish.
Some metrics that SLAs may specify include:
What percentage of the time services will be available;
The number of users that can be; served simultaneously;
Specific performance benchmarks;
Help desk response time.
Solution Building Block
Represent the actual components that will be used to implement the
required capability.
Subscription
An agreement between the information provider and the information
consumer for providing, receiving or making use of information in a
continuing or periodic nature.
Subsidiarity
The principle of subsidiarity aims at determining the level of intervention
that is most relevant in the areas of competences shared between the EU
and the Member States. This may concern action at European, national or
local levels. In all cases, the EU may only intervene if it is able to act more
effectively than Member States.
Translator
An application that converts the information of an authority legacy
system to the structure of the commonly agreed information exchange
model of CISE and vice versa. Without the translator information cannot
be exchanged between CISE participants.
User community
A user community is composed of a set of public authorities, which are
bound together by their function e.g. customs, marine environment,
maritime safety and security, defence, fisheries control, border control.
1.9. Acronyms
CISE
Common Information Sharing Environment
DG MARE
Directorate-General for Maritime Affairs and Fisheries
DIGIT
Directorate-General for Informatics
EIF
European Interoperability Framework
EU
European Union
ISA
Interoperability Solutions for European Public Administrations
Date: 11/12/2012
Version: 1.05
14
Draft CISE Architecture Vision Document
MSEsG
Member State Expertise sub-Group
TAG
Technical Advisory Group
Date: 11/12/2012
Version: 1.05
15
Draft CISE Architecture Vision Document
2. ARCHITECTURE VISIONS FOR CISE
2.1. How to read the architecture visions
The CISE architecture visions are presented in the following format. An introductory section and a diagram
convey the most important elements of the vision.
 “At a glance”: this introductory section describes the key characteristics of the vision, how it differs
from the previous vision in terms of complexity and intricacy (this is described in section 2.2.1) and
how it contributes to improving maritime surveillance. This section is immediately followed by a
diagram.
 Diagram: a visual representation of the architecture description. The diagram illustrates how
maritime authorities are interconnected. The vision’s architecture is represented using the
Archimate modelling language2. A description of the Archimate elements is included in (Annex 1 ). In
every diagram the following scenario is modelled:
 3 Member States;
 2 Member State having 2 Authorities, 1 Member State having a single Authority.
 A community initiative with a centralised database using data from 2 Authorities from 2
Member States.
The architecture vision is then described in terms of organisational, semantic and technical interoperability (as
defined in the EIF).
 Organisational interoperability: this section details how:
 Public authorities are organised in CISE;
 The organisational agreements that are required to support their interactions; and
 How CISE would be operated. Operating CISE is described from four viewpoints:
 Technical management;
 Application management;
 IT operations management; and
 Service desk operations.
 Semantic interoperability: this section focuses on how the exchanged information is made
understandable to and usable by all maritime authorities and how additional context, such as
through aggregation, can be added.
 Technical interoperability: this section describes technical interoperability aspects on sharing,
discovering and retrieving information. This section goes into detail how authority systems can
expose and use services and how information can be securely exchanged. Virtual collaboration is
also covered.
An architecture vision also defines the Architecture Building Blocks that need to be further specified in the
next CISE initiatives by Member States and sectoral initiatives. If variants are possible, these are also
described.
 Architecture Building Blocks that need to be specified: this section identifies all elements that need
to be further specified to realise the vision. The architecture building blocks can either be
specifications or software that needs to be developed (according to the defined specifications). It
also assigns ownership of these building blocks and identifies the actions Member States and
authorities need to take to implement the architecture vision.
 Variants: this section describes implementation variants of each vision.
Date: 11/12/2012
Version: 1.05
16
Draft CISE Architecture Vision Document
Each architecture vision is concluded by two sections to support the decision-making process. They provide a
qualitative and quantitative assessment of the vision:
 SWOT analysis: this section evaluates the strengths, weaknesses, opportunities and threats of the
vision compared to the as-is situation. The SWOT analysis provides a qualitative assessment of the
vision against the as-is situation as described in [1].
 Selection criteria: this section details the vision’s effectiveness (improvements to maritime
surveillance and requirements coverage), efficiency (short-term costs and benefits) and
sustainability (long-term costs and benefits). They provide a quantitative assessment of the vision.
The selection criteria are described further in section 2.2.2.
2.2. Background information
2.2.1. Complexity and intricacy of interconnecting maritime authorities
The first step of the CISE Roadmap [2] was the identification of all relevant authorities for maritime
surveillance, grouped in seven User Communities. The work done under this step resulted in about 400
relevant authorities having been identified at national level that handle information relevant for maritime
surveillance. This number is used in the architecture visions to provide an indication of the vision’s complexity
and intricacy.
The results of the first step of the CISE Roadmap [3] further clarified that this number is an approximation: an
unknown number of communal authorities are also involved in certain cases. This estimation is nonetheless
valuable to assess the complexity and intricacy of each vision in the extreme case in which all authorities are
interconnected.
To determine the number of connections, it is also assumed that each authority has exactly one information
system that will either provide or use information through CISE. There is no exact figure on the number of
information systems at present. A connection between information systems is also assumed to be
independent of the services provided or used; a single connection between information systems is established
to handle all information exchanges.
2.2.2. Selection criteria
2.2.2.1. Effectiveness
In order to understand how each vision contributes to the improvement of maritime surveillance, the
assessment of “effectiveness” will look at the different vision’s ability to solve the existing problem
statements and to meet stakeholder requirements.
In [1] five problem statements were identified as barriers to cross-border and cross-sector sharing of
information relevant for maritime surveillance. Two problem statements were formulated from the viewpoint
of authorities needing information:
 I need some information from another authority and I know where to the information (“direct pull”).
 I need some information from another authority and I do not know where to get the information
(“indirect pull”).
Two additional problem statements were described from the viewpoint of authorities having information:
 I have some information that I want or that I need to share and I know who needs this information
(“direct push”).
Date: 11/12/2012
Version: 1.05
17
Draft CISE Architecture Vision Document
 I have some information that I want or that I need to share and I do not know who needs this
information (“indirect push”).
A fifth problem statement was formulated to cover the case of the undefined unknown:
 I do not know that I have or that I need information.
These problem statements are reused in the selection criteria to understand each vision’s effectiveness in
improving maritime surveillance. This is done by describing how the vision contributes to solving the problem
statements.
The effectiveness of a vision is also determined by how well it fulfils the requirements for CISE (described in
section 4). This section will include a summary of the requirements coverage.
2.2.2.2. Efficiency
The efficiency of a vision describes how it vision can turn economical resources can be converted into results.
Efficiency focuses on the implementation of the vision and includes the short-term costs and time required to
realise the vision. This selection criterion will be based on the results on a costing study [4].
2.2.2.3. Sustainability
The sustainability of a vision describes the probability of each vision to realise continued, long-term benefits
and the long-term costs that are incurred. It focuses on operating CISE in the long-term. This selection
criterion will be based on the results of a costing study[4].
Date: 11/12/2012
Version: 1.05
18
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
Vision 1 – Interconnected Public Authority Systems
The vision at a glance
Description
Each public authority independently exposes a set of services using a commonly agreed information
exchange model (it should be noted that the technical service interface and transport protocol are not
standardised). Authorities acting as service consumers have to find and connect point-to-point to the
services of the information sources of their interest. Authorities acting as service consumers have to
find the services of the information sources of their interest through the Common Register of
Authorities and the Common Register of Services. Technical bilateral agreements are needed to
overcome the lack of a commonly agreed service interface.
How does this vision improve maritime surveillance?
Improves maritime surveillance by encouraging information systems, holding information relevant for
integrated maritime surveillance, to share this information using a commonly agreed information
exchange model.
What changes in this vision, compared to the as-is situation?
To support maritime authorities wanting to exchange information, a commonly agreed information
model is defined. This model helps reducing complexity by ensuring that information exchanged
between maritime authorities is presented in a standardised structure. To facilitate exchanges of
classified information, this vision also uses a commonly agreed information classification scheme and
commonly agreed access profiles framework. The information received by public authorities is as it is
sent by the information provider; there is no aggregation or fusion of information.
In vision 1, public authorities independently define and manage their own interfaces and access rights.
This could lead to as many as 400 different interfaces and a high level of intricacy (CISE has the
objective of interconnecting 400 public authorities). Each authority can define a service specification;
decide on its own transport protocol; etc.
Common elements are deployed to facilitate collaboration between public authorities:
Common Register of Authorities: a contact directory containing contact details and information about
the CISE participants.
Common Register of Services: a directory describing what services are offered by what public
authorities. It also details how these services can be used.
Common Collaborative Platform: a set of tools that allows virtual collaboration between public
authorities. This can include audio and video communication, instant messaging, etc.
Date: 11/12/2012
Version: 1.05
19
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
Diagram
Date: 11/12/2012
Version: 1.05
20
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
Each authority, in its role as service consumer, needs to understand which services are made available
by the authorities in each Member State, as well as User Community initiatives. They can use the
Common Register of Authorities and the Common Register of Services to retrieve this information. Each
authority then decides, based on their specific business needs, which services to consume.
Authorities are free to organise themselves as they see fit. If they choose to collaborate internally and
create a single CISE access point at national level), they are free to do so.
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
The only constraint imposed by this vision is that all bilateral technical agreements between maritime
authorities, for accessing and providing services, need to refer to the commonly agreed information
exchange model.
Broadcasting notifications, to all authorities interested in information relevant to maritime surveillance,
cannot be implemented by interconnecting all information sources, because the number of possible
interconnections is too high. Hence, this vision does not impose participants to expose notification
services based on commonly agreed specifications. Nevertheless, a notification system could be
implemented using existing tools (e.g. e-mail or SMS) or through the Common Register of Authorities.
How would CISE be operated?
Service desk: As every public authority offers services independently, each authority maintains its own
service desk with its own service level, working hours, languages, etc.
Application management: Each authority is responsible for its own information sources and associated
services. The commonly agreed information exchange model, the Common Register of Authorities, the
Common Register of Services and the Common Collaborative Platform are maintained by a central
authority.
IT operations management: Authorities are individually responsible for operating their information
systems. Each authority, acting as an information source, is responsible for respecting and monitoring
the agreements with other authorities.
Technical management: At national, sea-basin or sectoral level, no common technical management is in
place. Authorities are free to make any technological choice they prefer and change it whenever they
like. From an effectiveness and efficiency perspective, the common registers should be managed by a
central authority.
Date: 11/12/2012
Version: 1.05
21
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
Semantic interoperability
How is information made understandable and usable?
Information is shared using a commonly agreed information exchange model. The model describes how
information is structured and what controlled vocabularies and taxonomies are used to describe it.
How are access rights decided on?
Authorities manage the access rights for the information they own. If they do not own the information,
they must respect the applicable licensing.
How is information licensed?
A licensing model needs to be established together with the commonly agreed information exchange
model. This framework must define how information can be redistributed.
Is additional context given to the exchanged information?
Processing of information (i.e. aggregation) is entirely up to the public authority receiving the
information.
Technical interoperability
How would authorities be able to share information?
Each authority owning an information source manages its own service interface including the transport
protocol, the service’s metadata and the associated bi-lateral agreements for accessing and providing
services. However, it must use CISE’s commonly agreed information exchange model.
Authorities can publish information about the services they offer in a Common Register of Services.
Are there specificities for national and sea-basin authorities?
National and sea-basin authorities are considered to be at the same level as the individual public
authority. This means they are free to decide how they participate in CISE by balancing costs and
benefits. On the effort side, they need to consider that they should both establish an interconnection
and maintain it.
Are there specificities for User Community initiatives?
User Community initiatives are considered to be at the same level as the individual public authority.
This means they are free to decide how to participate in CISE. An initiative with a central database at
EU-level could offer services using the commonly agreed information exchange model. If the initiative
does not use a central database and the data is stored in each Member State, the Member State nodes
could offer services independently of one another.
How would authorities be able to add new services?
Authorities can add new services autonomously. They only need to ensure that the service uses the
commonly agreed information exchange model, but they are otherwise free in their choice of
Date: 11/12/2012
Version: 1.05
22
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
availability, authentication, authorisation and technologies.
When adding a new service, public authorities can publish the technical details in the Common Register
of Services.
How would authorities discover information relevant for them?
The Common Register of Authorities and the Common Register of Services can be consulted to retrieve
information about the authorities that offer services and how they offer them.
How would authorities retrieve information relevant for them?
Authentication credentials would be managed independently by each authority offering services (and
this can vary per service). Authorisation would be managed independently by each authority providing
services.
Similar information may be passed to the requestor several times from different information sources if
the requestor uses similar services from multiple authorities. As aggregation of information is
implemented by each consumer, i.e. the authority itself, this may lead to inconsistencies or incorrect
interpretation of received information.
As the information exchanged through the exposed services is not aggregated at any level, their
consumers need to develop a software component to manage the many point-to-point connections to
each information source and to aggregate the information coming from them (and eliminate
duplicates). These developments would happen independently i.e. each authority would develop its
own software component based on the services it decides to consume. Each software component
would also be maintained independently. This would be done in addition to the adaptations required in
the end-user applications of each authority in order to use the information retrieved through CISE.
How are authentication and authorisation handled?
Authorisation is managed by the information providers, respecting any constraints imposed by the
information owner. Each CISE participant should implement an information access management system
based on the commonly agreed access profiles.
Authorities are responsible for classifying their information according to the commonly agreed
information classification scheme. They do not have to modify their internal classification scheme
however.
Authorities are responsible for assigning one or more CISE access profiles to their end-users. They are
responsible for authenticating their end-users. When an authenticated end-user requests or sends
information, their assigned CISE access profiles will be used in the information exchange.
The authentication of CISE information exchanges is done by each authority individually, respecting the
commonly agreed information classification scheme and the access profiles.
How is trust between participants established?
Establishing trust between the different CISE participants system can be enhanced by:
 Building a CISE security policy, specifying minimal security requirements that all CISE users and
entities shall respect.
 Applying a commonly agreed information classification scheme. Correct information classification by
Date: 11/12/2012
Version: 1.05
23
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
all CISE members is a key factor to prevent disclosure of information. There should be a common
understanding among all CISE members of what are the implications of applying the information
classification scheme.
 Applying a commonly agreed access profile. Following the same principles as for information
classifications, there should be a common understanding of the CISE access level profiles.
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Architectural building blocks that need to be specified
What is defined in CISE?
Type
Building block
Project
SP
Information Exchange Model (including
classification scheme and access profiles)
Test Project on Cooperation
SP
Information Licensing Model
Test Project on Cooperation
SP
Common Register of Authorities
Technical Study
SP
Common Register of Services
Technical Study
SP
Common Collaborative Platform
Technical Study
What should the Member States do?
Type
Building block
Owner
SP
Transport protocol and metadata
Each authority independently
SP
Service interface specifications
Each authority independently
SP
Specifications for information consuming
application
Each authority independently
SW
Implementation of information
consuming application
Each authority independently
SP
Any agreement applicable for providing
and accessing services
Each authority independently
SW
Common Register of Authorities
MSs
SW
Common Register of Services
MSs
SW
Common Collaborative Platform
MSs
Acronyms
SP
Specification
SW
Software
MS
Member State
Date: 11/12/2012
Version: 1.05
24
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
Variants
What are variants of this vision?
Authorities and Member States are free to organise themselves as they see fit. The only constraint is
that information exchanges need to use the commonly agreed information exchange model (including
commonly agreed information classification scheme and commonly agreed access profiles). Maritime
authorities are free to voluntarily agree on a set of specifications, such as the transport protocol and
service interface. If all maritime authorities would decide to use the same specifications, this would
ultimately lead to vision 2.
SWOT analysis
What are the strengths of this vision?
What are the weaknesses of this vision?
The commonly agreed information exchange
model increases commonalities in information
exchanges.
The common elements, i.e. the commonly
agreed information exchange model, the
Common Register of Authorities and the
Common Register of Services, need to be
maintained.
Risk of receiving duplicate and contradictory
information.
Information processing, e.g. aggregation or
fusion, cannot be implemented in a standardized
manner.
Could lead to 79.800 unique interconnections
(based on 400 authorities).
End-user authentication has to be performed by
the information providers.
What are the opportunities associated with this
vision?
N/A
What are the threats associated with this vision?
Participants are exposed to the organizational
complexity of one another.
Participants
manage
their
services
autonomously, each having its own specificities
and service lifecycles.
Managing access rights and licensing in a
harmonised way might not be possible.
Information providers have to open up their
information systems to external systems,
Date: 11/12/2012
Version: 1.05
25
CISE Support Draft CISE Architecture Vision Document
Vision 1 – Interconnected Public Authority Systems
thereby increasing the risk of external attacks.
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
26
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
Vision 2 – Interconnected Public Authority Gateways
The vision at a glance
Description
Each authority, in its role as service consumer, needs to understand which services are made available
by the authorities in each Member State, as well as User Community initiatives. To facilitate
information exchanges, a standardised software component, known as a “gateway”, is specified. It
consists of an information exchange model specifying the information exchanged, a transport protocol
detailing how the information is exchanged between providers and consumers of information and the
technical service interface that describes how authorities can request or subscribe to the information.
Each information source uses the gateway specifications and therefore a commonly agreed transport
protocol and service interface to enable access to its information. Information consumers also rely on
the gateway specifications to use services from other maritime authorities.
How does this vision improve maritime surveillance?
Improves maritime surveillance by encouraging information systems holding information relevant for it
to share information using a commonly agreed information exchange model and gateway.
What changes in this vision, compared to vision 1?
Vision 2 builds on vision 1 by not only prescribing a commonly agreed information exchange model, a
commonly agreed information classification scheme and access profiles; but by also prescribing the
transport protocol and the technical service interfaces. The 3 are referred to as “gateway”
specifications. A reference implementation can be provided to the public authorities to facilitate their
adoption of the specifications (and becoming a CISE participant). The information received by public
authorities is the one stored by each information owner; there is no aggregation or fusion of
information.
In vision 1, public authorities are required to define and manage their own interfaces. This could lead to
as many as 400 different interfaces and a high level of intricacy (CISE has the objective of
interconnecting 400 public authorities). By relying on common technical service interfaces, the number
of unique interfaces is reduced to a single one in this vision.
Vision 1, having each public authority connected with every other, leads to a maximum number of
79.800 unique connections. Vision 2 does not reduce this number (because each authority may have its
own gateway), but connections are now standardised because they are defined in the gateway
specifications, leading to a further reduction in complexity.
In addition to the central elements in vision 1, the gateway specifications allow to deploy additional
common elements because all public authorities use the same technical service interface descriptions:
Common Monitoring Services: monitors performance and availability of services and can retrieve and
aggregated statistics.
Common Authentication Services: manages all aspects of authentication (i.e. management of
certificates)
Date: 11/12/2012
Version: 1.05
27
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
Diagram
Date: 11/12/2012
Version: 1.05
28
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
Each authority, in its role as service consumer, needs to understand which services are available
through the several authorities in each Member State, as well as sectoral and European initiatives. They
can use the Common Register of Authorities and the Common Register of Services to retrieve this
information. Authorities then need to decide which services to consume based on their specific
business needs.
Authorities are free to organise themselves as they see fit. If they choose to collaborate internally and
create a single CISE access point at national level (e.g. at the national level), they are free to do so.
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
As standardised gateways (i.e. the specifications are commonly agreed by all participants) are used,
community agreements for accessing and providing services can be created, enforced and maintained.
From an efficiency perspective, the common registers should be managed by a central authority.
How would CISE be operated?
Service desk: Each authority is responsible for setting up its own service desk. A common service desk
would be organised to address issues regarding the gateway specifications and its reference
implementation.
Application management: Each authority is responsible for its own information sources. The commonly
agreed information exchange model, the gateway specifications, the Common Register of Authorities,
the Common Register of Services, the Common Authentication Services, the Common Monitoring
Services and the Common Collaborative Platform are maintained by a central authority.
IT operations management: Authorities are individually responsible for operating their information
systems and their gateway. Each authority, as information source, is responsible for respecting and
monitoring the agreements with other authorities with regards to accessing and providing services (if
applicable). From an effectiveness and efficiency perspective, the Common Monitoring Services should
be managed by a central authority.
Technical management: Authorities are responsible for the technical management of their information
systems. Authorities can choose to use the reference gateway implementation or to develop the
gateway themselves based on the commonly agreed specifications. From an effectiveness and
efficiency perspective, the common registers should be managed by a central authority.
Date: 11/12/2012
Version: 1.05
29
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
Semantic interoperability
How is information made understandable and usable?
Information is shared using a commonly agreed information exchange model. The model describes how
information is structured and what controlled vocabularies and taxonomies are used to describe it.
How are access rights decided on?
Authorities manage the access rights for the information they own. If they do not own the information,
they must respect the applicable licensing.
How is information licensed?
A licensing model needs to be established together with the commonly agreed information exchange
model. This framework must define how information can be redistributed.
Is additional context given to the exchanged information?
Processing of information (i.e. aggregation) is entirely up to the public authority receiving the
information.
Technical interoperability
How would authorities be able to share information?
Each authority owning an information source must use a standardised gateway to expose CISE
compliant services and respect any applicable lateral agreement for accessing and providing them.
Authentication can be managed centrally (e.g. by a Common Authentication Services that hands out
certificates). Authorities have to implement an authorisation system to manage access rights to their
information individually however.
Authorities can publish information about the services they offer in a Common Register of Services.
Are there specificities for national and sea-basin authorities?
National and sea-basin authorities are considered to be at the same level as the individual public
authority. This means they are free to decide how they participate in CISE by balancing costs and
benefits. On the effort side, they need to consider that they should both establish an interconnection
and maintain it.
Are there specificities for User Community initiatives?
User Community initiatives are considered to be at the same level as the individual public authority.
This means they are free to decide how to participate in CISE. An initiative with a central database at
EU-level could offer services using the commonly agreed information exchange model. If the initiative
does not use a central database and the data is stored in each Member State, the Member State nodes
could offer services independently of one another.
How would authorities be able to add new services?
Date: 11/12/2012
Version: 1.05
30
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
Authorities adding a new service need to ensure that it uses the commonly agreed information
exchange model and that it is compliant with the gateway specifications.
When adding new services, authorities can publish the technical details in the Common Register of
Services.
How would authorities discover information relevant for them?
The Common Register of Authorities and the Common Register of Services can be consulted to retrieve
information about the authorities that offer services..
How would authorities retrieve information relevant for them?
As the gateway specifications provide standardisation for the information exchange model, the
transport protocol and the service specifications; authorities can connect without additional technical
effort to all other authorities implementing the same specifications.
Similar information may be passed to the requestor several times from different information sources if
the requestor uses similar services from multiple authorities. As aggregation of information is
implemented by each consumer, i.e. the authority itself, this may lead to inconsistencies or incorrect
interpretation of received information.
As the information exchanged through the exposed services is not aggregated at any level, their
consumers need to develop a software component to manage the many point-to-point connections to
each information source and to aggregate the information coming from them. These developments
would happen independently i.e. each authority would develop its own software component based on
the services it decides to consume. Each software component would also be maintained independently.
This would be done in addition to the adaptations required in the end-user applications of each
authority in order to use the information retrieved through CISE.
How are authentication and authorisation handled?
Authorisation is managed by the information providers, respecting any constraints imposed by the
information owner. Each CISE participant should implement an information access management system
based on the commonly agreed access profiles.
Authorities are responsible for classifying their information according to the commonly agreed
information classification scheme. They do not have to modify their internal classification scheme
however.
The authentication of CISE participants is done through Common Authentication Services in accordance
with the commonly agreed information classification scheme and access profiles. The use of common
authentication services is made possible by the standardisation of the transport protocol and the
technical service interface descriptions.
Authorities are responsible for assigning one or more CISE access profiles to their end-users. They are
responsible for authenticating their end-users. When an authenticated end-user requests or sends
information, their assigned CISE access profiles will be used in the information exchange.
Authentication of CISE information requests and subscriptions is done at the level of the public
authority. Individual end-users are not authenticated in the Common Authentication Services.
The definition of the common services are to be defined, whether these should include specifications,
Date: 11/12/2012
Version: 1.05
31
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
reference implementation and/or services.
How is trust between participants established?
Establishing trust between the different CISE participants system can be enhanced by:
 Building a CISE security policy, specifying minimal security requirements that all CISE users and
entities shall respect.
 Applying a commonly agreed classification scheme. Correct information classification by all CISE
members is a key factor to prevent disclosure of information. There should be a common
understanding among all CISE members of what are the implications of applying the information
classification scheme.
 Applying a commonly agreed access profile. Following the same principles as for information
classifications, there should be a common understanding of the CISE access level profiles.
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Architectural building blocks that need to be specified
What is defined in CISE?
Type
Building block
Project
SP
Information Exchange Model (including
classification scheme and access profiles)
Test Project on Cooperation
SP
Information Licensing Model
Test Project on Cooperation
SP
Transport protocol and metadata
Technical Study
SP
Service interface specifications
Technical study
SP
Common Register of Authorities
Technical Study
SP
Common Register of Services
Technical Study
SP
Common Collaborative Platform
Technical Study
SP
Common Authentication Services
Technical Study
SP
Common Monitoring Services
Technical Study
What should the Member States do?
Type
Building block
Owner
SW
Reference implementation of the
gateway
MSs
SP
Specifications for information consuming
application
Each authority independently
SW
Implementation of information
consuming application
Each authority independently
SP
Any agreement applicable for providing
and accessing services
MSs
Date: 11/12/2012
Version: 1.05
32
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
SW
Common Register of Authorities
MSs
SW
Common Register of Services
MSs
SW
Common Collaborative Platform
MSs
SW
Common Authentication Services
MSs
SW
Common Monitoring Services
MSs
Acronyms
SP
Specification
SW
Software
MS
Member State
Variants
What are variants of this vision?
Authorities and Member States are free to organise them as they see fit. The only constraint is that
information exchanges need to use the commonly agreed information exchange model and the
gateway specifications. Within a Member State, maritime authorities are free to voluntarily organise
themselves to collaborate even further by e.g. sharing a single gateway. If all maritime authorities in a
Member State decide to use the same gateway, this would lead to vision 3.
SWOT analysis
What are the strengths of this vision?
The commonly agreed information exchange
model and the gateway specifications increase
commonalities in information exchanges.
Connections are standardised, allowing
additional common elements: the Common
Monitoring Services and the Common
Authentication Services. The standardised
connections also allow implementing a
broadcast notification system.
Security measures to guarantee secure
transmission of information can be installed at
the level of the secure gateway. The security
measures will be homogeneous across all
gateways (no weak points).
Date: 11/12/2012
What are the weaknesses of this vision?
The common elements, i.e. the commonly
agreed information exchange model, the
Common Register of Authorities and the
Common Register of Services, need to be
maintained
Risk of receiving duplicate and contradictory
information.
Information processing, e.g. aggregation or
fusion, cannot be implemented in a standardised
manner due to the simplicity of the gateway.
Could
lead
to
79.800
standardised
interconnections (based on 400 authorities).
The number of gateways can be high, thus
increasing the complexity of managing (in
operational terms) the technical security
measures.
Version: 1.05
33
CISE Support Draft CISE Architecture Vision Document
Vision 2 – Interconnected Public Authority Gateways
What are the opportunities associated with this
vision?
A standard gateway implementation can be
provided to spur adoption.
What are the threats associated with this vision?
Establishing a community agreement is required;
this can be difficult due to the large number of
public authorities involved.
There can be a standardised approach for the
technical security measures, thus acting as a
standard security baseline.
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
34
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
Vision 3 – Interconnected National Gateways
The vision at a glance
Description
Each public authority independently implements a set of services using a commonly agreed information
exchange model, transport protocol and service interface. These are implemented in a standardised
software component known as “gateway”. The public authority makes the service available through a
standardised gateway at national level. The national gateway is used by all public authorities in a
Member State. The national gateway has routing functionalities, meaning that public authorities no
longer need to be aware of where to get information. They request information through the national
gateway, which routes the request to the public authorities offering that information (in case the
service is offered by a public authority within the same Member State) or to the other national
gateways.
Although information requests are made through a national gateway, the information provider can
send its response directly to the requesting authority if the information exchange requires a secure,
point-to-point connection between authorities.
How does this vision improve maritime surveillance?
Improves maritime surveillance by encouraging information systems holding information relevant for it
to share information using a commonly agreed information exchange model and to expose services
through a national gateway. Maritime authorities no longer need to be aware of where to get
information; this functionality is now handled by the national gateways.
What changes in this vision, compared to vision 2?
In vision 2, each public authority connects to its own gateway. The gateway is either a reference
implementation or a custom implementation (the Member State choosing the latter needs to ensure
the custom implementation is compliant with the gateway specifications). In this vision, maritime
authorities no longer implement their own gateway, but to a shared gateway at national level. These
national gateways are then interconnected. Maritime authorities no longer need to be aware of whom
to send a request to; the national gateway operates as a router. The information received by maritime
authorities is as it is sent by the information provider; there is no aggregation or fusion of information.
As in vision 2, vision 3 also features 2 standardised interfaces: one used by the maritime authorities to
connect to their national gateway; one used to interconnect the national gateways. The level of
intricacy is similar to vision 2.
In vision 2, the maximum number of standardised connections between all authorities is very high.
Because each of the 400 public authorities needs to connect with all other authorities, this number
amounts to 79.800. This number is drastically reduced in this vision to 751. Now, all 400 authorities only
need to connect to their national node (400 standardised connections). The national nodes are then
interconnected (for 27 Member State nodes, this would amount to 351 standardised connections).
Complexity is thus drastically reduced in this vision.
Date: 11/12/2012
Version: 1.05
35
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
Diagram
Date: 11/12/2012
Version: 1.05
36
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
Each Member State makes available a single standardised gateway to connect all maritime authorities
within the Member State and expose their services through a single access point. The national gateway
makes it possible to exchange cross-sector information. The national gateways are then interconnected
to allow cross-border information exchanges. In each Member State, a national authority ensures the
availability and quality of the services of the national gateway.
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
This vision requires cross-sectoral information sharing agreements between Member States, which
could be established through community agreements.
How would CISE be operated?
Service desk: The service desk would have to be set up on national level in conjunction with the
national gateway. A central help desk supports the implementations of the national gateway
specifications.
Application management: Application management of the end-user system that manages connections
to the national gateway is dealt with at each individual authority. The commonly agreed information
exchange model, the national gateway specifications, the Common Register of Authorities, the
Common Register of Services, the Common Authentication Services and the Common Collaborative
Platform are maintained by a central authority.
IT operations management: Authorities as information sources are responsible for respecting the
community agreements for accessing and providing services. Member States are responsible for
ensuring the national gateway fulfils the community agreement for accessing and providing services. A
Common Monitoring Services is used to monitor performance and to collect statistics from the national
gateways.
Technical management: Within a Member State, authorities are responsible for the technical
management of their information systems. Member States can choose to use the reference national
gateway implementation or to develop the gateway themselves based on commonly agreed
specifications. From an effectiveness and efficiency perspective, the common registers should be
managed by a central authority.
Semantic interoperability
How is information made understandable and usable?
Information is shared using a commonly agreed information exchange model. The model describes how
information is structured and what controlled vocabularies and taxonomies are used to describe it.
How are access rights decided on?
Date: 11/12/2012
Version: 1.05
37
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
Authorities manage the access rights for the information they own. If they do not own the information,
they must respect the applicable licensing.
How is information licensed?
A licensing model needs to be established together with the commonly agreed information exchange
model. This framework must define how information can be redistributed.
Is additional context given to exchanged information?
The national gateway implements routing functionality. This gives authorities the option of sending
requests and subscriptions without first having to know who has the information. A national gateway
with routing functionality also supports sending information or notifications to all other authorities. An
authority needs only to send the information or notification, the interconnected gateways will route it
to all other authorities.
The commonly agreed information exchange model supports the routing of requests, subscriptions and
notifications. Processing of information (i.e. aggregation) is entirely up to the public authority receiving
the information.
Technical interoperability
How would authorities be able to share information?
Each authority owning an information source must connect to a standardised gateway at national level
to expose CISE compliant services; and respect any applicable agreement for accessing and providing
services. Authentication can be managed centrally (e.g. by a Common Authentication Services that
hands out certificates). Authorities have to implement an authorisation system to manage access rights
to their information individually however.
Are there specificities for national and sea-basin authorities?
National and sea-basin authorities are considered to be at the same level as the individual public
authority. This means they are free to decide how they participate in CISE by balancing costs and
benefits. On the effort side, they need to consider that they should both establish an interconnection
and maintain it.
Are there specificities for User Community initiatives?
User Community initiatives are considered to be at the same level as the national gateway. An initiative
with a central database at EU-level could offer services using the commonly agreed information
exchange model. If the initiative does not use a central database and the data is stored in each Member
State, the User Community gateways in each Member State could offer services independently of one
another.
How would authorities be able to add new services?
Authorities adding a new service need to ensure that it uses the commonly agreed information
exchange model and that it is compliant with the national gateway specifications.
Date: 11/12/2012
Version: 1.05
38
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
How would authorities discover information relevant for them?
An authority sends an information request to its national gateway. The national gateway in turn routes
the request to those national gateways that can provide information to the request. Each authority
must use the common information exchange model defined in the context of CISE, in order for the
information request to be understood by the other national gateways.
In case of notifications, the common information exchange model is used to notify other authorities of
events relevant to them. An authority can broadcast a notification to all authorities by sending the
notification to the national gateway which in turn forwards it to the connected authorities (within the
same Member State) and to the other national gateways (who send it to their connected public
authorities). Broadcasting is enabled due to the notification service being a default service of the
gateway specifications.
How would authorities retrieve information relevant for them?
Authorities wishing to consume information services must establish an interface with their own
national gateway. They are responsible for adjusting their legacy applications so that they are capable
of retrieving information through the national node.
Similar information may be passed to the requestor several times from different information sources if
the requestor uses similar services from multiple authorities. As aggregation of information is
implemented by each consumer, i.e. the authority itself, this may lead to inconsistencies or incorrect
interpretation of received information.
As the information exchanged through the exposed services is not aggregated at any level, their
consumers need to develop a software component to manage the many connections to each
information source and to aggregate the information coming from them. These developments would
happen independently i.e. each authority would develop its own software component based on the
services it decides to consume. Each software component would also be maintained independently.
This would be done in addition to the adaptations required in the end-user applications of each
authority in order to use the information retrieved through CISE.
How are authentication and authorisation handled?
Authorisation is managed by the information providers, respecting any constraints imposed by the
information owner. Each CISE participant should implement an information access management system
based on the commonly agreed access profiles.
Authorities are responsible for classifying their information according to the commonly agreed
information classification scheme. They do not have to modify their internal classification scheme
however.
The authentication of CISE participants is done through Common Authentication Services in accordance
with the commonly agreed information classification scheme and access profiles. The use of common
authentication services is made possible by the standardisation of the transport protocol and the
technical service interface descriptions.
Authorities are responsible for assigning one or more CISE access profiles to their end-users. They are
responsible for authenticating their end-users. When an authenticated end-user requests or sends
information, their assigned CISE access profiles will be used in the information exchange.
Date: 11/12/2012
Version: 1.05
39
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
Authentication of CISE information requests and subscriptions is done at the level of the public
authority. Individual end-users are not authenticated in the Common Authentication Services.
The definition of the common services are to be defined, whether these should include specifications,
reference implementation and/or services.
How is trust between participants established?
Establishing trust between the different CISE participants system can be enhanced by:
 Building a CISE security policy, specifying minimal security requirements that all CISE users and
entities shall respect.
 Applying a commonly agreed classification scheme. Correct information classification by all CISE
members is a key factor to prevent disclosure of information. There should be a common
understanding among all CISE members of what are the implications of applying the information
classification scheme.
 Applying a commonly agreed access profile. Following the same principles as for information
classifications, there should be a common understanding of the CISE access level profiles.
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Architectural building blocks that need to be specified
What is defined in CISE?
Type
Building block
Project
SP
Information Exchange Model (including
classification scheme and access profiles)
Test Project on Cooperation
SP
Information Licensing Model
Test Project on Cooperation
SP
Transport protocol and metadata
Technical Study
SP
Service interface specifications
Technical study
SP
Routing rules
Technical study
SP
Common Register of Authorities
Technical Study
SP
Common Register of Services
Technical Study
SP
Common Collaborative Platform
Technical Study
SP
Common Authentication Services
Technical Study
SP
Common Monitoring Services
Technical Study
What should the Member States do?
Type
Building block
Owner
SW
Reference implementation of the
gateway
MSs
SP
Specifications for information consuming
application
Each authority independently
Date: 11/12/2012
Version: 1.05
40
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
SW
Implementation of information
consuming application
Each authority independently
SP
Any agreement applicable for providing
accessing services
MSs
SW
Common Register of Authorities
MSs
SW
Common Register of Services
MSs
SW
Common Collaborative Platform
MSs
SW
Common Authentication Services
MSs
SW
Common Monitoring Services
MSs
Acronyms
SP
Specification
SW
Software
MS
Member State
Variants
What are variants of this vision?
Member States can decide to use multiple national gateways instead of only one. They can also decide
to add more functionality to the gateway (e.g. aggregation). If maritime authorities decide to add
aggregation functionality to their national gateways, this would lead to vision 4. Vision 4 is a standard
variant of vision 3, in which all national gateways use aggregation.
SWOT analysis
What are the strengths of this vision?
The commonly agreed information exchange
model and the gateway specifications increase
commonalities in information exchanges.
Connections are standardised, allowing
additional common elements: the Common
Monitoring Services and the Common
Authentication Services. The standardised
connections also allow implementing a
broadcast notification system.
The number of standardised interconnections
could be reduced to 751 because authorities
connect only to the national gateway. The
national gateways are then interconnected.
What are the weaknesses of this vision?
The common elements, i.e. the commonly
agreed information exchange model, the
Common Register of Authorities and the
Common Register of Services, need to be
maintained.
Risk of receiving duplicate and contradictory
information.
Information processing, e.g. aggregation or
fusion, cannot be implemented in a standardised
manner due to the simplicity of the gateway.
Authorities send their requests to the (single)
Date: 11/12/2012
Version: 1.05
41
CISE Support Draft CISE Architecture Vision Document
Vision 3 – Interconnected National Gateways
national gateway. Hence, authorities no longer
need to know where to get or where to send
information. This promotes cross-sectoral
information exchanges.
Security measures to guarantee secure
transmission of data can be installed at the
level of the secure gateway. The security
measures shall be homogeneous across all
gateways (no weak points).
What are the opportunities associated with this
vision?
A standard gateway implementation can be
provided to spur adoption.
There can be a standardised approach for the
technical security measures, thus acting as a
standard security baseline.
In the case of attacks, there can be a better
coordination
with
security-enforcement
agencies (e.g. EU or national CERTs).
What are the threats associated with this vision?
Establishing a community agreement is required;
this can be difficult due to the large number of
public authorities involved.
Creating routing rules is not straightforward.
A gateway at national level can be perceived as a
single point of failure for the public authorities
connected to it. It the gateway fails, the public
authorities are no longer able to use and provide
services through CISE.
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
42
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
Vision 4 – Interconnected National Nodes
The vision at a glance
Description
Each authority connects its information sources holding information relevant to maritime surveillance
to a national node. The node stores the information from the several information sources within a
Member State, pre-processes it and exposes a set of services to CISE users through a commonly defined
service interface, transport protocol and information exchange model. Authorities retrieve maritime
surveillance information by connecting to their national node (which is interconnected to other national
nodes). Although information requests are made through a national node, the information provider can
send its response directly to the requesting authority if the information exchange requires a secure,
point-to-point connection between authorities. Unlike the previous visions, the node is an advanced
gateway which facilitates the fusion of information.
Although information requests are made through a national node, the information provider can send its
response directly to the requesting authority if the information exchange requires a secure, point-topoint connection between authorities.
How does this vision improve maritime surveillance?
Improves maritime surveillance by encouraging information systems holding information relevant for it
to share information using a commonly agreed information exchange model and a (single) national
node. Through the national node, Member States share cross-sector consolidated information.
What changes in this vision, compared to vision 3?
This vision builds upon vision 3 by using national nodes, rather than national gateways. A node is more
advanced than a gateway because it supports information processing (such as aggregation and fusion of
information). Visions 3 and 4 have identical levels of complexity and intricacy, as the number of
interfaces and connections remain the same. The information received by maritime authorities is
however aggregated, as the national node aggregates information from the various maritime
authorities that are connected to it.
A reference implementation for the national node can be distributed to all participants.
Date: 11/12/2012
Version: 1.05
43
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
Diagram
Date: 11/12/2012
Version: 1.05
44
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
Each Member State makes available a set of services based on cross-sectoral information collected
nationally to all authorities relevant for maritime surveillance. The national nodes are then
interconnected to allow cross-border information exchanges. In each Member State, a national
authority ensures the availability and quality of the services of the national node.
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
This vision requires cross-sectoral information sharing agreements between Member States, which
could be established through community agreements.
How would CISE be operated?
Service desk: The service desk would have to be set up on national level by Member States in
conjunction with the national node to assist the authorities. A central help desk supports the
implementations of the national node specifications.
Application management: Application management of the end-user system that manages connections
to the national node is dealt with at each individual authority. The commonly agreed information
exchange model, the national node specifications, the Common Register of Authorities, the Common
Register of Services, the Common Authentication Services and the Common Collaborative Platform are
maintained by a central authority.
IT operations management: Authorities as information sources are responsible for respecting the
community agreements for accessing and providing services. Member States are responsible for
ensuring the national node fulfils the community agreement for accessing and providing services. A
Common Monitoring Services is used to monitor performance and to collect statistics from the national
nodes.
Technical management: Within a Member State, authorities are responsible for the technical
management of their information systems. Member States can choose to use the reference national
node implementation or to develop the node themselves based on commonly agreed specifications.
From an effectiveness and efficiency perspective, the common registers should be managed by a
central authority.
Semantic interoperability
How is information made understandable and usable?
Information is shared using a commonly agreed information exchange model. The model describes how
information is structured and what controlled vocabularies and taxonomies are used to describe it.
How are access rights decided on?
Date: 11/12/2012
Version: 1.05
45
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
Authorities manage the access rights for the information they own. If they do not own the information,
they must respect the applicable licensing.
How is information licensed?
A licensing model needs to be established together with the commonly agreed information exchange
model. This framework must define how information can be redistributed.
Is additional context given to exchanged information?
The national node also implements routing functionality. This gives authorities the option of sending
requests and subscriptions without first having to know whom to send it to. The commonly agreed
information exchange model supports the routing of requests, subscriptions and notifications.
Processing of information (i.e. aggregation) can be implemented in the national node; this way,
authorities receive more readily usable information.
Technical interoperability
How would authorities be able to share information?
Each authority owning an information source must connect to its national node; and respect any
applicable agreement for accessing and providing services.
The national node serves as information storage for the numerous information sources within a
Member State, allowing adding meta-information such as quality, provenance etc. The node preprocesses information and exposes it through a commonly defined service interface, transport protocol
and information exchange model. This node also pre-processes information (e.g. correlation, fusion,
analysis, etc). The node could also offer a nationally useful maritime picture or a user interface.
Each authority is responsible for developing and maintaining software applications capable of treating
the information received from the several national nodes; and for adapting their end-user applications.
Are there specificities for national and sea-basin authorities?
Each Member State is responsible for implementing a single national node, which stores information
from all information sources. Member States are responsible for ensuring the national node fulfils the
community agreement for accessing and providing services. The national nodes use the Common
Authentication Services to authenticate requests. National nodes are also responsible for authorising
requests, hereby respecting the authorisation rules defined by the public authority that provided the
information.
Are there specificities for User Community initiatives?
User Community initiatives are considered to be at the same level as the national node. An initiative
with a central database at EU-level could offer services using the commonly agreed information
exchange model. If the initiative does not use a central database and the data is stored in each Member
State, the Member State nodes could offer services independently of one another.
Date: 11/12/2012
Version: 1.05
46
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
How would authorities be able to add new services?
Authorities adding a new service need to ensure that it uses the commonly agreed information
exchange model. The national node needs to be aware of the new service and needs to be adapted if
any additional information processing (e.g. aggregation) is required.
When adding new services, authorities and the responsible for the national node can publish the
technical details in the Common Register of Services.
How would authorities discover information relevant for them?
An authority sends an information request to its national node. The national node in turn routes the
request to those national nodes that can provide information to the request. Each authority must use
the common information exchange model defined in the context of CISE, in order for the information
request to be understood by the different national nodes.
In case of notifications, the common information exchange model is used to notify other authorities of
events relevant to them. An authority can broadcast a notification to all authorities by sending the
notification to the national node which in turn forwards it to the connected authorities (within the
same Member State) and to the other national nodes (who send it to their connected public
authorities). Broadcasting is enabled due to the notification service being a default service of the node
specifications.
How would authorities retrieve information relevant for them?
Authorities wishing to consume information services must establish an interface with its own national
node. They are responsible for adjusting their legacy applications so that they are capable of retrieving
information through the national node.
As the information exchanged through the exposed services is aggregated at the level of national
nodes, consumers need to develop a software component to manage the many connections to their
national information source and to aggregate the information coming from them. As information is
aggregated at the national level, information consumers do not need to handle the responses from
individual authorities but from the Member State nodes. These developments would happen
independently i.e. each authority would develop its own software component based on the services it
decides to consume. Each software component would also be maintained independently. This would be
done in addition to the adaptations required in the end-user applications of each authority in order to
use the information retrieved through CISE.
How are authentication and authorisation handled?
Authorisation is managed by the information providers, respecting any constraints imposed by the
information owner. Each CISE participant should implement an information access management system
based on the commonly agreed access profiles.
Authorities are responsible for classifying their information according to the commonly agreed
information classification scheme. They do not have to modify their internal classification scheme
however.
The authentication of CISE participants is done through Common Authentication Services in accordance
with the commonly agreed information classification scheme and access profiles. The use of common
Date: 11/12/2012
Version: 1.05
47
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
authentication services is made possible by the standardisation of the transport protocol and the
technical service interface descriptions.
Authorities are responsible for assigning one or more CISE access profiles to their end-users. They are
responsible for authenticating their end-users. When an authenticated end-user requests or sends
information, their assigned CISE access profiles will be used in the information exchange.
Authentication of CISE information requests and subscriptions is done at the level of the public
authority. Individual end-users are not authenticated in the Common Authentication Services.
The definition of the common services are to be defined, whether these should include specifications,
reference implementation and/or services.
How is trust between participants established?
Establishing trust between the different CISE participants system can be enhanced by:
 Building a CISE security policy, specifying minimal security requirements that all CISE users and
entities shall respect.
 Applying a commonly agreed classification scheme. Correct information classification by all CISE
members is a key factor to prevent disclosure of information. There should be a common
understanding among all CISE members of what are the implications of applying the information
classification scheme.
 Applying a commonly agreed access profile. Following the same principles as for information
classifications, there should be a common understanding of the CISE access level profiles.
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Date: 11/12/2012
Version: 1.05
48
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
Architectural building blocks that need to be specified
What is defined in CISE?
Type
Building block
Project
SP
Information Exchange Model (including
classification scheme and access profiles)
Test Project on Cooperation
SP
Information Licensing Model
Test Project on Cooperation
SP
Transport protocol and metadata
Technical Study
SP
Service interface specifications
Technical study
SP
Node specifications
Technical Study
SP
Routing rules
Technical Study
SP
Aggregation rules
Technical Study
SP
Common Register of Authorities
Technical Study
SP
Common Register of Services
Technical Study
SP
Common Collaborative Platform
Technical Study
SP
Common Authentication Services
Technical Study
SP
Common Monitoring Services
Technical Study
What should the Member States do?
Type
Building block
Owner
SW
Reference implementation of the node
MSs
SP
Specifications for information consuming
application
Each authority independently
SW
Implementation of information
consuming application
Each authority independently
SP
Any agreement applicable for providing
accessing services
MSs
SW
Common Register of Authorities
MSs
SW
Common Register of Services
MSs
SW
Common Collaborative Platform
MSs
SW
Common Authentication Services
MSs
SW
Common Monitoring Services
MSs
Acronyms
SP
Specification
SW
Software
MS
Member State
Date: 11/12/2012
Version: 1.05
49
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
Variants
What are variants of this vision?
Member States can decide to use multiple national nodes instead of only one. They can also decide to
reduce the functionality of the node (e.g. without aggregation). If authorities decide to implement
multiple nodes with reduced functionality, this would lead to vision 3. Vision 3 is a standard variant of
this vision, in which nodes have been reduced to the simpler gateways.
SWOT analysis
What are the strengths of this vision?
The commonly agreed information exchange
model and the node specifications increase
commonalities in information exchanges.
Connections are standardised, allowing
additional common elements: the Common
Monitoring Services and the Common
Authentication Services. The standardised
connections also allow implementing a
broadcast notification system.
The number of standardised interconnections
could be reduced to 751 because authorities
connect only to the national node. The
national nodes are then interconnected.
What are the weaknesses of this vision?
The common elements, i.e. the commonly
agreed information exchange model, the
Common Register of Authorities, the Common
Register of Services, the node specifications and
the standard node implementation need to be
maintained.
The national node is more advanced than a
gateway and requires additional specifications
and implementation efforts (e.g. creating
aggregation
or
fusion
rules
is
not
straightforward).
Authorities send their requests to the (single)
national node. Hence, authorities no longer
need to know where to get or where to send
information. This promotes cross-sectoral
information exchanges.
Security measures to guarantee secure
transmission of data can be installed at the
level of the secure node. The security
measures shall be homogeneous across all
nodes (no weak points).
The national node can increase CISE
functionalities (i.e. aggregation or fusion of
information) and can improve performance by
storing information from public authorities
within the Member State.
There can be 2 layers of security: at the
Date: 11/12/2012
Version: 1.05
50
CISE Support Draft CISE Architecture Vision Document
Vision 4 – Interconnected National Nodes
transport level and at the services level.
Technical security measures can be included at
both. This increases the overall protection.
The pilot projects have implemented and
tested similar architectures. Their experiences
can be used as lessons learned.
What are the opportunities associated with this
vision?
A standard node implementation can be
provided to spur adoption.
There can be a standardised approach for the
technical security measures, thus acting as a
standard security baseline.
In the case of attacks, there can be a better
coordination
with
security-enforcement
agencies (e.g. EU or national CERTs).
What are the threats associated with this vision?
Establishing a community agreement is required;
this can be difficult due to the large number of
public authorities involved.
A node at national level can be perceived as a
single point of failure for the public authorities
connected to it. It the node fails, the public
authorities are no longer able to use and provide
services through CISE.
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
51
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
Vision 5 – Sea-Basin Coordinated National Nodes
The vision at a glance
Description
Each authority connects its information sources holding information relevant to maritime surveillance
to a national node. The node stores information from several information sources within a Member
State, pre-processes it and exposes a set of services to CISE users through a commonly defined
interface and information exchange model. These nodes are then clustered per sea-basin to a higher
level node that coordinates information sharing within the given sea-basin area. Authorities retrieve
maritime surveillance information by connecting to their national node, which is interconnected to the
sea-basin node (which in turn is interconnected to other sea-basin nodes).
Although information requests are made through a national node, the information provider can send its
response directly to the requesting authority if the information exchange requires a secure, point-topoint connection between authorities.
How does this vision improve maritime surveillance?
Improves the maritime surveillance by encouraging information systems holding information relevant
for it to share information through cross-sector and cross-border services per sea-basin.
What changes in this vision, compared to vision 4?
Vision 5 adds an additional grouping of nodes based on region or sea-basin. National nodes are no
longer interconnected, but connect to the coordinator node of their region.
The information received by authorities is aggregated at national level and (potentially) at sea-basin
level. The national node aggregates information from the authorities that are connected to it; the seabasin nodes can potentially also aggregate information (if done in accordance with the licensing model).
There are now 3 standardised interfaces: one for the public authorities to connect to the national node;
one for the national nodes to connect to the sea-basin node; the third one to interconnect the seabasin nodes. The level of intricacy is slightly higher than in vision 4 due to the need for a third interface.
Because there are fewer sea-basin nodes than national nodes, the maximum number of connections is
further reduced to 448: 400 standardised connections from public authorities to their national node, 33
standardised connections from national nodes to sea-basin coordinators and 15 standardised
interconnections between 6 sea-basin coordinators. This results in a slightly lower complexity than
vision 4.
A reference implementation for the national node and sea-basin node can be provided by a central
authority.
Date: 11/12/2012
Version: 1.05
52
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
Diagram
Date: 11/12/2012
Version: 1.05
53
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
Each Member State makes available a set of services based on cross-sectoral information collected
nationally. National nodes then connect to one or more sea-basin nodes, which are interconnected, to
also provide for cross-border information to all authorities relevant for maritime surveillance. Per
Member State, a national authority ensures the availability and quality of the services of the national
node. At sea-basin level, a central authority must ensure the availability and quality of the services
offered through the sea-basin coordinators.
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
This vision requires cross-sectoral and cross-border information sharing agreements between Member
States, which could be established through community agreements.
How would CISE be operated?
Service desk: The service desk would have to be set up on national level by Member States in
conjunction with the national node to assist the authorities. A central help desk supports the
implementations of the national node specifications and to assist with the sea-basin coordinators.
Application management: Application management of the end-user system that manages connections
to the national nodes and that aggregates information from different sea-basins is dealt with at each
individual authority. The management of national nodes is the responsibility of the Member States. The
sea-basin coordinators are managed by a central authority, as are the commonly agreed information
exchange model, the national node specifications, the Common Register of Authorities, the Common
Register of Services, the Common Authentication Services and the Common Collaborative Platform are
maintained by a central authority.
IT operations management: Authorities as information sources are responsible for respecting the
community agreements for accessing and providing services. The commonly agreed information
exchange model, nodes’ specifications and the node reference implementations are to be maintained
centrally. There should be a central registry for users, roles and access rights to be used by each
national node for user authentication. Sea-basin coordinators use the same user access register to
authenticate national nodes; national nodes authenticate requests and verify the “level” of access to
information that can be provided to requestors. A central authority would be set up to monitor the
overall system, to host a central platform with collaboration tools and to build and maintain a central
catalogue of authorities and CISE compliant services.
Technical management: Within a Member State, authorities are responsible for the technical
management of their information systems. Member States are responsible for the technical
management of the national nodes. Member States can choose to use the reference national node
implementation or to develop the node themselves based on commonly agreed specifications. From an
effectiveness and efficiency perspective, the common registers should be managed by a central
authority.
Date: 11/12/2012
Version: 1.05
54
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
Semantic interoperability
How is information made understandable and usable?
Information is shared using a commonly agreed information exchange model. The model describes how
information is structured and what controlled vocabularies and taxonomies are used to describe it.
How are access rights decided on?
Authorities manage the access rights for the information they own. If they do not own the information,
they must respect the applicable licensing.
How is information licensed?
A licensing model needs to be established together with the commonly agreed information exchange
model. This framework must define how information can be redistributed.
Is additional context given to exchanged information?
The national node and the sea-basin coordinator implement routing functionality. This gives authorities
the option of sending requests and subscriptions without first having to know whom to send it to. The
commonly agreed information exchange model supports the routing of requests, subscriptions and
notifications.
Processing of information (i.e. aggregation) can be implemented in the national node; this way,
authorities receive more readily usable information.
Technical interoperability
How would authorities be able to share information?
Each authority owning an information source must connect to its national node; and respect any
applicable agreement for accessing and providing services.
The national node serves as information storage for the numerous information sources within a
Member State, allowing adding meta-information such as quality, provenance etc. The node preprocesses information and exposes it through a commonly defined service interface, transport protocol
and information exchange model. This node also pre-processes information (e.g. correlation, fusion,
analysis, etc). The node could also offer a nationally useful maritime picture or a user interface.
The national nodes are then connected to the sea-basin coordinators, these coordinators become a
facade towards a group of connected national nodes. The sea-basin node could also offer a regionally
useful maritime picture or a user interface.
Each authority is responsible for developing and maintaining software applications capable of treating
the information received from the several sea-basin nodes; and for adapting their end-user
applications.
Are there specificities for national and sea-basin authorities?
Each Member State is responsible for implementing a single national node, which stores information
Date: 11/12/2012
Version: 1.05
55
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
from all information sources. Member States are responsible for ensuring the national node fulfils the
community agreement for accessing and providing services. The national nodes use the Common
Authentication Services to authenticate requests. National nodes are also responsible for authorising
requests, hereby respecting the authorisation rules defined by the public authority that provided the
information. Sea-basin coordinators use the same user access register to authenticate national nodes.
Are there specificities for User Community initiatives?
User Community initiatives are considered to be at the same level as the national node. An initiative
with a central database at EU-level could offer services using the commonly agreed information
exchange model. If the initiative does not use a central database and the data is stored in each
Member State, the Member State nodes could offer services independently of one another. The User
Community nodes connect to all sea-basin coordinators (Member State nodes connect only to those
relevant for the sea-basin they are in).
How would authorities be able to add new services?
Authorities adding a new service need to ensure that it uses the commonly agreed information
exchange model. The national node needs to be aware of the new service and needs to be adapted if
any additional information processing (e.g. aggregation) is required.
When adding new services, authorities and the responsible for the national node can publish the
technical details in the Common Register of Services.
How would authorities discover information relevant for them?
An authority sends an information request to its national node. The national node forwards the request
to the sea-basin coordinator. The coordinator can then route the request to those national nodes that
can provide information to the request. If no connected node can provide information, the sea-basin
coordinator forwards the request to the other sea-basin coordinators. Each authority must use the
common information exchange model, in order for the information request to be understood by the
different national and sea-basin nodes.
In case of notifications, the common information exchange model is used to notify other authorities of
events relevant to them. An authority can broadcast a notification to all authorities by sending the
notification to the national node which forwards it to the sea-basin coordinator. The sea-basin
coordinator then forwards the request to all other sea-basin coordinators. The sea-basin coordinators
send the request to their connected national nodes, which ultimately forward it to the public
authorities. Broadcasting is enabled due to the notification service being a default service of the node
specifications.
How would authorities retrieve information relevant for them?
Authorities wishing to consume information services must establish an interface with its own national
node. They are responsible for adjusting their legacy applications so that they are capable of retrieving
information through the national node.
Information is aggregated on the level of sea-basin nodes; therefore, similar information may be passed
to the requestor several times from different sea-basin nodes if the requestor uses similar services from
multiple sea-basin nodes. As aggregation of information is implemented by each consumer, i.e. the
Date: 11/12/2012
Version: 1.05
56
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
authority itself, this may lead to inconsistencies or incorrect interpretation of received information.
As the information exchanged through the exposed services is aggregated at the level of sea-basin
nodes, consumers may want to develop a software component to manage the connections to sea-basin
information sources and to aggregate the information coming from them. These developments would
happen independently i.e. each authority would develop its own software component based on the
services it decides to consume. Each software component would also be maintained independently.
This would be done in addition to the adaptations required in the end-user applications of each
authority in order to use the information retrieved through CISE.
How are authentication and authorisation handled?
Authorisation is managed by the information providers, respecting any constraints imposed by the
information owner. Each CISE participant should implement an information access management system
based on the commonly agreed access profiles.
Authorities are responsible for classifying their information according to the commonly agreed
information classification scheme. They do not have to modify their internal classification scheme
however.
The authentication of CISE participants is done through Common Authentication Services in accordance
with the commonly agreed information classification scheme and access profiles. The use of common
authentication services is made possible by the standardisation of the transport protocol and the
technical service interface descriptions.
Authorities are responsible for assigning one or more CISE access profiles to their end-users. They are
responsible for authenticating their end-users. When an authenticated end-user requests or sends
information, their assigned CISE access profiles will be used in the information exchange.
Authentication of CISE information requests and subscriptions is done at the level of the public
authority. Individual end-users are not authenticated in the Common Authentication Services.
The definition of the common services are to be defined, whether these should include specifications,
reference implementation and/or services.
How is trust between participants established?
Establishing trust between the different CISE participants system can be enhanced by:
 Building a CISE security policy, specifying minimal security requirements that all CISE users and
entities shall respect.
 Applying a commonly agreed classification scheme. Correct information classification by all CISE
members is a key factor to prevent disclosure of information. There should be a common
understanding among all CISE members of what are the implications of applying the information
classification scheme.
 Applying a commonly agreed access profile. Following the same principles as for information
classifications, there should be a common understanding of the CISE access level profiles.
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Date: 11/12/2012
Version: 1.05
57
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
Architectural building blocks that need to be specified
What is defined in CISE?
Type
Building block
Project
SP
Information Exchange Model (including
classification scheme and access profiles)
Test Project on Cooperation
SP
Information Licensing Model
Test Project on Cooperation
SP
Transport protocol and metadata
Technical Study
SP
Service interface specifications
Technical study
SP
Node specifications
Technical Study
SP
Coordinator specifications
Technical Study
SP
Routing rules
Technical Study
SP
Aggregation rules
Technical Study
SP
Common Register of Authorities
Technical Study
SP
Common Register of Services
Technical Study
SP
Common Collaborative Platform
Technical Study
SP
Common Authentication Services
Technical Study
SP
Common Monitoring Services
Technical Study
What should the Member States do?
Type
Building block
Owner
SW
Reference implementation of the node
MSs
SW
Reference implementation of the
coordinator
MSs
SP
Specifications for information consuming
application
Each authority independently
SW
Implementation of information
consuming application
Each authority independently
SP
Any agreement applicable for providing
accessing services
MSs
SW
Common Register of Authorities
MSs
SW
Common Register of Services
MSs
SW
Common Collaborative Platform
MSs
SW
Common Authentication Services
MSs
SW
Common Monitoring Services
MSs
Acronyms
SP
Specification
SW
Software
MS
Member State
Date: 11/12/2012
Version: 1.05
58
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
Variants
What are variants of this vision?
Member States can decide to use multiple national nodes instead of only one. They can also decide to
reduce the functionality of the node (e.g. without aggregation) and use a gateway instead.
User Community initiatives can connect to all the national nodes (similar to vision 4) instead of to all
sea-basin coordinators.
SWOT analysis
What are the strengths of this vision?
The commonly agreed information exchange
model and the node specifications (both
national
and
sea-basin)
increase
commonalities in information exchanges.
Connections are standardised, allowing
additional common elements: the Common
Monitoring Services and the Common
Authentication Services. The standardised
connections also allow implementing a
broadcast notification system.
The number of standardised interconnections
could be reduced to 448 because authorities
connect only to the national node. The
national nodes then connect to the
interconnected sea-basin coordinators.
What are the weaknesses of this vision?
The common elements, i.e. the commonly
agreed information exchange model, the
Common Register of Authorities, the Common
Register of Services, the node specifications, the
standard node implementation and the sea-basin
coordinator need to be maintained.
The national node is more complex than a
gateway and requires additional specifications
and implementation efforts (e.g. creating
aggregation
or
fusion
rules
is
not
straightforward).
Authorities send their requests to the (single)
national node. Hence, authorities no longer
need to know where to get or where to send
information. This promotes cross-sectoral
information exchanges.
Security measures to guarantee secure
transmission of data can be installed at the
level of the secure node. The security
measures shall be homogeneous across all
nodes (no weak points).
The national node can increase CISE
functionalities (i.e. aggregation or fusion of
information) and can improve performance by
storing information from public authorities
Date: 11/12/2012
Version: 1.05
59
CISE Support Draft CISE Architecture Vision Document
Vision 5 – Sea-Basin Coordinated National Nodes
within the Member State.
There can be 2 layers of security: at the
transport level and at the services level.
Technical security measures can be included at
both. This increases the overall protection.
What are the opportunities associated with this
vision?
Standard implementations of a national node
and sea-basin coordinator can be provided to
spur adoption.
The sea-basin coordinators enable improved
performance across sea-basins.
There can be a standardised approach for the
technical security measures, thus acting as a
standard security baseline.
What are the threats associated with this vision?
Establishing a community agreement is required;
this can be difficult due to the large number of
public authorities involved. Agreement on the
single point of contact at sea-basin level may not
be straightforward.
A node at national level can be perceived as a
single point of failure for the public authorities
connected to it. It the node fails, the public
authorities are no longer able to use and provide
services through CISE.
The sea-basin coordinator can be perceived as a
second single point of failure. A fallback mode
based on interconnected national nodes could be
considered in case of major attacks or
unavailability of the sea-basin coordinator.
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
60
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Vision 6 – EU Coordinated National Nodes
The vision at a glance
Description
Each authority connects its information sources holding information relevant to maritime surveillance
to a national node. The node stores information from several information sources within a Member
State, pre-processes it and exposes a set of services to CISE users through a commonly defined
interface and information exchange model. These nodes are then connected to a single, central
coordinator that coordinates information sharing between all Member States. Authorities consuming
information services connect to their national node, which is interconnected to the central coordinator.
Although information requests are made through a national node, the information provider can send its
response directly to the requesting authority if the information exchange requires a secure, point-topoint connection between authorities.
How does this vision improve maritime surveillance?
Improves the maritime surveillance by encouraging information systems holding information relevant
for it to share information through cross-sector and cross-border services through a national node and
a central coordinator.
What changes in this vision, compared to vision 5?
Vision 6 removes the clustering per sea-basin and uses a single, central coordinator to facilitate
information exchanges between the Member States.
The information received by authorities is aggregated at national level and at European level. The
national node aggregates information from the authorities that are connected to it; and the central
coordinators aggregates information from the national nodes.
There are 2 standardised interfaces: one for the public authorities to connect to the national node; one
for the national nodes to connect to the central coordinator. The level of intricacy is slightly lower than
in vision 5, which required 3 standardised interfaces.
The maximum number of connections is further reduced to 427 in this vision: 400 standardised
connections from public authorities to their national node, 27 standardised connections from national
nodes to the central coordinator. This results in a slightly lower complexity than vision 5.
A reference implementation for the national node can be provided by a central authority.
Date: 11/12/2012
Version: 1.05
61
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Diagram
Date: 11/12/2012
Version: 1.05
62
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
Each Member State makes available a set of services based on cross-sectoral information collected
nationally. National nodes then connect to the central coordinator to also provide for cross-border
information to all authorities relevant for maritime surveillance. Per Member State, a national authority
ensures the availability and quality of the services of the national node. In addition, a central authority
must ensure the availability and quality of the services offered through the central coordinator.
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
This vision requires cross-sectoral and cross-border information sharing agreements between Member
States, which could be established through community agreements.
How would CISE be operated?
Service desk: The service desk would have to be set up on national level by Member States in
conjunction with the national node to assist the authorities. A central help desk supports the
implementations of the national node specifications and to assist with the central coordinator.
Application management: Application management of the end-user system that manages connections
to the national nodes is dealt with at each individual authority. The management of national nodes is
the responsibility of the Member States. The central coordinator is managed by a central authority, as
are the commonly agreed information exchange model, the national node specifications, the Common
Register of Authorities, the Common Register of Services, the Common Authentication Services and the
Common Collaborative Platform are maintained by a central authority.
IT operations management: Authorities as information sources are responsible for respecting the
community agreements for accessing and providing services. The commonly agreed information
exchange model, nodes’ specifications and the node reference implementations are to be maintained
centrally. There should be a central registry for users, roles and access rights to be used by the national
nodes for user authentication. The central coordinator uses the same user access register to
authenticate national nodes; national nodes authenticate requests and verify the “level” of access to
information that can be provided to requestors. A central authority would be set up to monitor the
overall system, to host a central platform with collaboration tools and to build and maintain a central
catalogue of authorities and CISE compliant services.
Technical management: Within a Member State, authorities are responsible for the technical
management of their information systems. Member States are responsible for the technical
management of the national nodes. Member States can choose to use the reference national node
implementation or to develop the node themselves based on commonly agreed specifications. From an
effectiveness and efficiency perspective, the common registers should be managed by a central
authority.
Date: 11/12/2012
Version: 1.05
63
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Semantic interoperability
How is information made understandable and usable?
Information is shared using a commonly agreed information exchange model. The model describes how
information is structured and what controlled vocabularies and taxonomies are used to describe it.
How are access rights decided on?
Authorities manage the access rights for the information they own. If they do not own the information,
they must respect the applicable licensing.
How is information licensed?
A licensing model needs to be established together with the commonly agreed information exchange
model. This framework must define how information can be redistributed.
Is additional context given to exchanged information?
The national nodes and central coordinator implements routing functionality. This gives authorities the
option of sending requests and subscriptions without first having to know whom to send it to. The
commonly agreed information exchange model supports the routing of requests, subscriptions and
notifications.
Processing of information (i.e. aggregation) can be implemented in the national node and central
coordinators; this way, authorities receive more readily usable information.
Technical interoperability
How would authorities be able to share information?
Each authority owning an information source must connect to its national node; and respect any
applicable agreement for accessing and providing services.
The national node serves as information storage for the numerous information sources within a
Member State, allowing adding meta-information such as quality, provenance etc. The node preprocesses information and exposes it through a commonly defined service interface, transport protocol
and information exchange model. This node also pre-processes information (e.g. correlation, fusion,
analysis, etc). The node could also offer a nationally useful maritime picture or a user interface.
The national nodes are then connected to the central coordinator that facilitates information
exchanges between Member States. The central coordinator does not feature information storage.
Are there specificities for national and sea-basin authorities?
Each Member State is responsible for implementing a single national node, which stores information
from all information sources. Member States are responsible for ensuring the national node fulfils the
community agreement for accessing and providing services. The national nodes use the Common
Authentication Services to authenticate requests. National nodes are also responsible for authorising
requests, hereby respecting the authorisation rules defined by the public authority that provided the
Date: 11/12/2012
Version: 1.05
64
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
information. The central coordinator uses the same user access register to authenticate national nodes.
Are there specificities for User Community initiatives?
User Community initiatives are considered to be at the same level as the national node. An initiative
with a central database at EU-level could offer services using the commonly agreed information
exchange model. If the initiative does not use a central database and the data is stored in each
Member State, the Member State nodes could offer services independently of one another.
How would authorities be able to add new services?
Authorities adding a new service need to ensure that it uses the commonly agreed information
exchange model. The national node needs to be aware of the new service and needs to be adapted if
any additional information processing (e.g. aggregation) is required.
When adding new services, authorities and the responsible for the national node can publish the
technical details in the Common Register of Services.
How would authorities discover information relevant for them?
An authority sends an information request to its national node. The national node forwards the request
to the central coordinator. The coordinator can then route the request to those national nodes that can
provide information to the request. Each authority must use the common information exchange model,
in order for the information request to be understood by the different national nodes.
In case of notifications, the common information exchange model is used to notify other authorities of
events relevant to them. An authority can broadcast a notification to all authorities by sending the
notification to the national node which forwards it to the central coordinator. The central coordinator
then forwards the request to all other national nodes, which ultimately forward it to the authorities.
Broadcasting is enabled due to the notification service being a default service of the node
specifications.
How would authorities retrieve information relevant for them?
Authorities wishing to consume information services must establish an interface with its own national
node. They are responsible for adjusting their legacy applications so that they are capable of retrieving
information through the national node.
How are authentication and authorisation handled?
Authorisation is managed by the information providers, respecting any constraints imposed by the
information owner. Each CISE participant should implement an information access management system
based on the commonly agreed access profiles.
Authorities are responsible for classifying their information according to the commonly agreed
information classification scheme. They do not have to modify their internal classification scheme
however.
The authentication of CISE participants is done through Common Authentication Services in accordance
with the commonly agreed information classification scheme and access profiles. The use of common
authentication services is made possible by the standardisation of the transport protocol and the
Date: 11/12/2012
Version: 1.05
65
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
technical service interface descriptions.
Authorities are responsible for assigning one or more CISE access profiles to their end-users. They are
responsible for authenticating their end-users. When an authenticated end-user requests or sends
information, their assigned CISE access profiles will be used in the information exchange.
Authentication of CISE information requests and subscriptions is done at the level of the public
authority. Individual end-users are not authenticated in the Common Authentication Services.
The definition of the common services are to be defined, whether these should include specifications,
reference implementation and/or services.
How is trust between participants established?
Establishing trust between the different CISE participants system can be enhanced by:
 Building a CISE security policy, specifying minimal security requirements that all CISE users and
entities shall respect.
 Applying a commonly agreed classification scheme. Correct information classification by all CISE
members is a key factor to prevent disclosure of information. There should be a common
understanding among all CISE members of what are the implications of applying the information
classification scheme.
 Applying a commonly agreed access profile. Following the same principles as for information
classifications, there should be a common understanding of the CISE access level profiles.
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Date: 11/12/2012
Version: 1.05
66
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Architectural building blocks that need to be specified
What is defined in CISE?
Type
Building block
Project
SP
Information Exchange Model (including
classification scheme and access profiles)
Test Project on Cooperation
SP
Information Licensing Model
Test Project on Cooperation
SP
Transport protocol and metadata
Technical Study
SP
Service interface specifications
Technical study
SP
Node specifications
Technical Study
SP
Coordinator specifications
Technical Study
SP
Routing rules
Technical Study
SP
Aggregation rules
Technical Study
SP
Common Register of Authorities
Technical Study
SP
Common Register of Services
Technical Study
SP
Common Collaborative Platform
Technical Study
SP
Common Authentication Services
Technical Study
SP
Common Monitoring Services
Technical Study
What should the Member States do?
Type
Building block
Owner
SW
Reference implementation of the node
MSs
SW
Reference implementation of the
coordinator
MSs
SP
Specifications for information consuming
application
Each authority independently
SW
Implementation of information
consuming application
Each authority independently
SP
Any agreement applicable for providing
accessing services
MSs
SW
Common Register of Authorities
MSs
SW
Common Register of Services
MSs
SW
Common Collaborative Platform
MSs
SW
Common Authentication Services
MSs
SW
Common Monitoring Services
MSs
Acronyms
SP
Specification
SW
Software
MS
Member State
Date: 11/12/2012
Version: 1.05
67
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Variants
What are variants of this vision?
Member States can decide to use multiple national nodes instead of only one. They can also decide to
reduce the functionality of the node (e.g. without aggregation) and use a gateway instead.
SWOT analysis
What are the strengths of this vision?
The commonly agreed information exchange
model and the node specifications (both
national and EU coordinator) increase
commonalities in information exchanges.
Connections are standardised, allowing
additional common elements: the Common
Monitoring Services and the Common
Authentication Services. The standardised
connections also allow implementing a
broadcast notification system.
The number of standardised interconnections
could be reduced to 427 because authorities
connect only to the national node. The
national nodes then connect with the single
EU coordinator.
What are the weaknesses of this vision?
The common elements, i.e. the commonly
agreed information exchange model, the
Common Register of Authorities, the Common
Register of Services, the node specifications, the
standard node implementation and the EU
coordinator need to be maintained.
The national node is more complex than a
gateway and requires additional specifications
and implementation efforts (e.g. creating
aggregation
or
fusion
rules
is
not
straightforward).
Authorities send their requests to the (single)
national node. Hence, authorities no longer
need to know where to get or where to send
information. This promotes cross-sectoral
information exchanges.
Security measures to guarantee secure
transmission of data can be installed at the
level of the secure node. The security
measures shall be homogeneous across all
nodes (no weak points).
The national node can increase CISE
functionalities (i.e. aggregation or fusion of
information) and can improve performance by
storing information from public authorities
within the Member State.
There can be 2 layers of security: at the
transport level and at the services level.
Date: 11/12/2012
Version: 1.05
68
CISE Support Draft CISE Architecture Vision Document
Vision 6 – EU Coordinated National Nodes
Technical security measures can be included at
both. This increases the overall protection.
What are the opportunities associated with this
vision?
Standard implementations of a national node
and sea-basin coordinator can be provided to
spur adoption.
The sea-basin coordinators enable improved
performance across sea-basins.
There can be a standardised approach for the
technical security measures, thus acting as a
standard security baseline.
What are the threats associated with this vision?
Establishing a community agreement is required;
this can be difficult due to the large number of
public authorities involved. Agreement on the
single point of contact at EU level may not be
straightforward.
A node at national level can be perceived as a
single point of failure for the public authorities
connected to it. It the node fails, the public
authorities are no longer able to use and provide
services through CISE.
The EU coordinator can be perceived as a second
single point of failure. A fallback mode based on
interconnected national nodes could be
considered in case of major attacks or
unavailability of the sea-basin coordinator.
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
69
CISE Support Draft CISE Architecture Vision Document
Vision 7 – Interconnected User Community Nodes
Vision 7 – Interconnected User Community Nodes
The vision at a glance
Description
How does this vision improve maritime surveillance?
What changes in this vision?
Date: 11/12/2012
Version: 1.05
70
CISE Support Draft CISE Architecture Vision Document
Vision 7 – Interconnected User Community Nodes
Diagram
Date: 11/12/2012
Version: 1.05
71
CISE Support Draft CISE Architecture Vision Document
Vision 7 – Interconnected User Community Nodes
Organisational interoperability
How would authorities (at national, sea-basin, sectoral and European level) organise themselves to share
information relevant for maritime surveillance to one another?
What agreements would be needed to enable authorities to share information relevant for maritime
surveillance?
How would CISE be operated?
Service desk:
Application management:
IT operations management:
Technical management:
Date: 11/12/2012
Version: 1.05
72
CISE Support Draft CISE Architecture Vision Document
Vision 7 – Interconnected User Community Nodes
Semantic interoperability
How is information made understandable and usable?
How are access rights decided on?
How is information licensed?
Is additional context given to exchanged information?
Technical interoperability
How would authorities be able to share information?
Are there specificities for national and sea-basin authorities?
Are there specificities for sectoral and European initiatives?
How would authorities be able to add new services?
How would authorities discover information relevant for them?
How would authorities retrieve information relevant for them?
How are authentication and authorisation handled?
How is trust between participants established?
How would this vision enable virtual collaboration between authorities?
Authorities can use a Common Collaborative Platform to interact with one another.
Date: 11/12/2012
Version: 1.05
73
CISE Support Draft CISE Architecture Vision Document
Vision 7 – Interconnected User Community Nodes
Architectural building blocks that need to be specified
Date: 11/12/2012
Version: 1.05
74
CISE Support Draft CISE Architecture Vision Document
Vision 7 – Interconnected User Community Nodes
Variants
What are variants of this vision?
SWOT analysis
What are the strengths of this vision?
What are the weaknesses of this vision?
What are the opportunities associated with this
vision?
What are the threats associated with this vision?
Selection criteria
What is this vision’s effectiveness in improving maritime awareness?
[To be completed]
How efficient is this vision in terms of economical resources needed in the short-term?
[To be completed]
How sustainable is this vision? What are the continued long-term benefits?
[To be completed]
Date: 11/12/2012
Version: 1.05
75
CISE Support Draft CISE Architecture Vision Document
3. PRINCIPLES OF CISE
The principles of CISE provide for a high level design rationale. It is a rationale that must always be taken into
account when creating, changing or removing any CISE-related element.
[To be completed]
Date: 11/12/2012
Version: 1.05
76
CISE Support Draft CISE Architecture Vision Document
ID
Title
Description
P1
CISE must allow interlinking any public authority in The objective of CISE is to improve maritime awareness by improving the maritime user
the EU and in the EEA involved in maritime
communities’ abilities to monitor, detect, identify, track and understand cross-border activities in
surveillance.
order to find reasoned grounds for reaction measures on the basis of combining new information
with existing knowledge.
P2
CISE must increase maritime awareness based on
need-to-know and responsibility-to-share
principles.
The need-to-know principle promotes the idea of user communities needing and being able to
access information from other communities in order to enhance their maritime situational picture.
The responsibility-to-share principle promotes the idea of user communities voluntarily sharing
information with other communities to support them in their decision-making processes by
contributing to a more complete maritime situational picture.
P3
CISE must privilege a decentralised approach at
EU-level.
CISE must be based on a decentralised approach, meaning that public authorities should be able to
work interoperable, based on common standards, while respecting access rights to the exchanged
information.
P4
CISE must allow interoperability among civilian
and military information systems.
CISE must support interactions between civilian and military systems to allowing for the most
complete maritime situational picture.
P5
CISE must allow interoperability among
information systems at the European, national,
sectoral and regional level.
Improving maritime awareness requires making information available to maritime authorities that
previously encountered barriers in trying to obtain that information. CISE participants must be able
to access information from national, regional, sectoral and European authorities in a flexible way.
P6
CISE must privilege reuse of existing tools and
technologies.
CISE must build on prior work and should favour reusing existing tools, technologies and systems as
much as possible.
P7
CISE must allow seamless and secure exchanges of CISE must be able to handle all types of information relevant to maritime information, including
any type of information relevant for maritime
non-sensitive, sensitive and highly-secure information. Information must be exchanged
surveillance.
P8
CISE must be sector-neutral.
Date: 11/12/2012
All communities should have equal options of participating, without requiring them to modify their
own internal structures and systems.
Version: 1.05
77
CISE Support Draft CISE Architecture Vision Document
P9
Date: 11/12/2012
CISE must make it possible for information
providers to change their service offering.
Information providers are at all times free to decide on the services they offer.
Version: 1.05
78
CISE Support Draft CISE Architecture Vision Document
4. REQUIREMENTS FOR CISE
The tables below describe the requirements for CISE. Each requirement is defined by an ID, a title and a
description. They are categorised using the below scheme:
 Information sharing: these describe the basic information workflows in terms of requesting and
subscribing to information and notifications.
 Information discovery: information discovery details how CISE participants can find information
using CISE.
 Information assurance: information exchanged through CISE will give the receiver the ability to
assess the value of the information.
 Information security: CISE must be able to handle non-secure, secure and highly sensitive
information.
 Collaboration between CISE participants: CISE participants must not only be able to exchange
information, they must also be able to (virtually) collaborate and get in touch with each other.
 Organisational aspects: CISE must be managed, requiring certain organisational functions.
 Recommendations to CISE participants: any constraints or requirements that would need to be
addressed by CISE partners. These are not requirements in se but they are formulated as
recommendations.
Date: 11/12/2012
Version: 1.05
79
CISE Support Draft CISE Architecture Vision Document
4.1. Sharing of information
ID
Requirement
Description
SI1
CISE must support sending information upon
request, subscription or spontaneously.
[To be completed]
SI2
CISE must support sending notifications upon
subscription or spontaneously.
[To be completed]
SI3
CISE must support requesting information.
[To be completed]
SI4
CISE must support subscribing and unsubscribing to
information at any time.
[To be completed]
SI5
CISE must support subscribing and unsubscribing to
notifications at any time.
[To be completed]
SI6
CISE must support requesting or subscribing to
information using a vessel, an area or an operation
as input parameter, without knowing who the
provider of the information is.
[To be completed]
SI7
CISE information requests can specify the timeframe for which the information is requested.
[To be completed]
SI8
CISE must rely on a common data model for
[To be completed]
information exchanges which is as language-neutral
as possible.
SI9
CISE must support exchanges of large files, such as
satellite images and maps.
[To be completed]
SI10
CISE information exchanges must be file format
neutral.
[To be completed]
Date: 11/12/2012
Version: 1.05
80
CISE Support Draft CISE Architecture Vision Document
4.2. Discovery of information
ID
Requirement
Description
DI1
CISE must allow retrieving contact information
about CISE participants.
[To be completed]
DI2
CISE must allow looking up what information CISE
participants can provide and how they can provide
that information.
[To be completed]
DI3
CISE must allow information providers making
available how their services can be used, including
parameters such as the refresh rate.
[To be completed]
DI4
CISE must allow verifying if the services offered by a [To be completed]
data provider are available.
4.3. Information assurance
ID
Requirement
IA1
CISE information exchanges must include a
[To be completed]
confidence value and must indicate who provided it.
The confidence value must be a commonly agreed
coded value.
IA2
CISE information requests must include an optional [To be completed]
priority level reflecting the urgency of the request.
The priority level must be a commonly agreed coded
value.
IA3
CISE information exchanges must contain relevant
characteristics about the information, such as its
Date: 11/12/2012
Description
[To be completed]
Version: 1.05
81
CISE Support Draft CISE Architecture Vision Document
provenance and precision.
4.4. Information security
ID
Requirement
Description
IS1
CISE information exchanges must respect agreed
data access rights through access profiles
[To be completed]
IS2
CISE must support information access rights that can [To be completed]
be changed dynamically (respecting a commonly
agreed SLA) by the information owner in accordance
with relevant international and national legislation
IS3
CISE must support information providers providing a [To be completed]
service to allow requesting access to their
information
IS4
CISE information exchanges are authenticated at the [To be completed]
level of the CISE participants and in respect of the
CISE access profiles.
IS5
CISE access profiles must support non-secure, secure [To be completed]
and highly-trusted information exchanges.
IS6
CISE information exchanges must respect a
[To be completed]
commonly agreed information classification scheme
in order for them to use the appropriate secure
channels
IS7
CISE information requests and subscriptions can
include one or more access profiles (e.g. one per
user community).
Date: 11/12/2012
[To be completed]
Version: 1.05
82
CISE Support Draft CISE Architecture Vision Document
IS8
CISE information exchanges must use channels that
support confidentiality.
[To be completed]
IS9
CISE must use a transport protocol that ensures
[To be completed]
ensures a minimum level of integrity of information
exchanges between consumer and provider. The
transport protocol must also ensure higher levels of
integrity depending on the classification level of the
information.
IS10
The communication channels between CISE
participants must support non-repudiation.
IS11
CISE must support interconnecting networks of
[To be completed]
different security levels, including public and private
networks.
[To be completed]
4.5. Collaboration between CISE participants
ID
Requirement
Description
CO1
CISE must support secure exchange of unstructured
information.
[To be completed]
CO2
CISE must support secure audio communication.
[To be completed]
CO3
CISE must support secure video communication.
[To be completed]
CO4
CISE must support secure instant messaging.
[To be completed]
CO5
CISE must support secure white-boarding.
[To be completed]
Date: 11/12/2012
Version: 1.05
83
CISE Support Draft CISE Architecture Vision Document
4.6. Organisational aspects
ID
Requirement
Description
OA1
CISE must support an encompassing
[To be completed]
administrational handler function that is required to
maintain all the commonly agreed elements.
4.7. Recommendations to CISE participants
ID
Recommendation
Description
RE1
CISE participants providing information must
provide statistics per service on information
exchanged through CISE.
[To be completed]
RE2
CISE participants must be able to retrieve statistical
information from CISE information providers.
[To be completed]
RE3
Information shared through CISE must have been
[To be completed]
pre-approved (so that it can be shared with all other
participants) or requestable to the information
providers.
RE4
CISE participants are responsible for authenticating
their own end-users and assigning a CISE access
profile to them.
RE5
CISE participants should agree with availability levels [To be completed]
defined in a bilateral, multilateral or community
Service Level Agreement.
RE6
CISE participants should agree on a common set of
file formats in order to maximise the usability of
Date: 11/12/2012
[To be completed]
[To be completed]
Version: 1.05
84
CISE Support Draft CISE Architecture Vision Document
exchanged information.
4.8. Additional requirements
The table below describes requirements that need to be further investigated.
Requirement
CISE must allow an acknowledgement for data transmission in certain cases (previously: Information exchanges must be guaranteed and duplicate
exchanges must be avoided).
CISE information exchanges must guarantuee confidentiality.
CISE must support exchange with one participant, a thematic group of participants or with any participant interested.
CISE must offer access to a directory of participant and thematic group of participants (grouped for instance by community/profile, by state or
region).
CISE must support the transmission of highly updated information with a short delay of transmission (defined in a SLA).
CISE must be able to handle different version of the interface and a backward compatibility.
CISE must allow cancelling or correcting information previously sent.
CISE must allow providing an explanation when no response is possible after a request (access right, technical problem, no information found,
unknown reference...).
CISE must allow the recipient to send to the provider a feed back about the quality of the information.
CISE must inform any participant of the availability of a service or the period of unavailability planned for a service (a service could be also partially
available, ex: 2 AIS based station are out, the 20 others are fine). This information must also be available in a format allowing integration in
standard monitoring systems.
CISE must have the capability to link several messages together (if they are related to the same request or if they are related to the same operation
for example).
The information sent must carry the date/time it was updated and the date/time it was sent.
Date: 11/12/2012
Version: 1.05
85
CISE Support Draft CISE Architecture Vision Document
CISE must specify the behaviour in case of rupture of communication during an exchange (or should it be in a global SLA?).
CISE participants must be approved (the environment is not open to anybody).
Date: 11/12/2012
Version: 1.05
86
CISE Support Draft CISE Architecture Vision Document
5. OPERATIONAL WORKFLOWS
[To be completed. This section describes the basic information flows in CISE.]
Date: 11/12/2012
Version: 1.05
87
CISE Support Draft CISE Architecture Vision Document
6. BIBLIOGRAPHY
[1] Deloitte, “Study on the current surveillance IT landscape and resulting options,” 2012. [Online]. Available:
https://webgate.ec.europa.eu/maritimeforum/content/2959.
[2] DG MARE, “Integrating Maritime Surveillance: Communication from the Commission to the Council and
the European Parliament on a Draft Roadmap towards establishing the Common Information Sharing
Environment for the surveillance of the EU maritime domain,” 2010. [Online]. Available: http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52010DC0584:EN:NOT.
[3] DG MARE, Draft progress report on the Roadmap to Establishing the Common Information Sharing EU
nvironment (“CISE”) for the surveillance of the EU maritime domain, 2012.
[4] DG MARE, Terms of references for costing of technical options study, 2012.
[5] J. P. Kotter, Leading Change, 1996.
Date: 11/12/2012
Version: 1.05
88
CISE Support Draft CISE Architecture Vision Document
END NOTES
1
ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf
2
http://www.opengroup.org/subjectareas/enterprise/archimate
Date: 11/12/2012
Version: 1.05
89
CISE Support Draft CISE Architecture Vision Document
ANNEX 1 ARCHIMATE REFERENCE
Meaning of colours
The table below describes the meaning of colours that are used in the CISE Architecture Vision diagrams.
Colour
Meaning
An element of CISE that is common to all participants. It is defined in a community
agreement.
Identifies a legacy authority system or a part thereof.
Identifies a new authority system or part thereof. It is not legacy, because it is
specified and implemented to interact with CISE. These elements are not defined in a
community agreement. Every authority is free to define and implement them as they
see fit.
Identifies an organisational grouping of elements relevant to CISE.
Identifies a new authority system or part thereof. It is not legacy, because it is
specified and implemented to interact with a user community system. Depending on
the user community system in question, these elements may or may not be specified
by the user community.
Identifies an organisational grouping of elements relevant to a user community.
Meaning of elements
The table below describes the Archimate elements that are used in the CISE Architecture Vision diagrams.
Concept
Notation
Definition
Application
component
Date: 11/12/2012
An application component is
defined as a modular, deployable,
and replaceable part of a system
that encapsulates its contents and
exposes its functionality through
a set of interfaces.
Version: 1.05
90
CISE Support Draft CISE Architecture Vision Document
An application component is a
self-contained unit of
functionality at the application
level. It performs one or more
application functions.
It is re-usable, and replaceable. It
is only accessible through a set of
application interfaces.
Application
interface
An application interface declares
how a component connects with
its environment.
An application interface specifies
how the functionality of a
component can be accessed by
other components. It can also
specify which functionality the
component requires from its
environment.
An application interface specifies
how the functionality of a
component can be accessed by
other components (provided
interface), or which functionality
the component requires from its
environment (required interface).
Composition
relation
An application interface
composes an application
component; an application
component is composed of
application interface(s).
The composition relationship
indicates that an object consists
of a number of other objects.
In contrast to the aggregation
relationship, an object can be part
of only one composition.
Date: 11/12/2012
Version: 1.05
91
CISE Support Draft CISE Architecture Vision Document
Used by
relation
An application interface is used by
an application component; an
application component uses an
application interface.
The used by relationship models
the use of services by processes,
functions, or interactions and the
access to interfaces by roles,
components, or collaborations.
Contract
A contract is defined as a formal
or informal specification of an
agreement that specifies the
rights and obligations associated
with a product.
This type of notation can be used
to indicate e.g. the commonly
agreed information exchange
model.
Date: 11/12/2012
Version: 1.05
92