Which lessons learned and good practices can CISE leverage from peer-developments? : final report of the project “Consolidation of Common Information Sharing Environment (CISE) development”.
Date: 2018-07-27
Institutions: Directorate-General for Maritime Affairs and Fisheries
Subjects: added value, cooperation policy, digital technology, exchange of information, fisheries policy, maritime safety, maritime surveillance, maritime transport, report, shipping policy

SC430DI07171 

Final Report of the project “Consolidation of Common 
Information Sharing Environment (CISE) 
development” 

Which lessons learned and good practices can CISE 
leverage from peer-developments? 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Manuscript completed in June 2018. 

1st edition 

Neither the European Commission nor any person acting on behalf of the Commission is responsible for 
the use that might be made of the following information. 

Luxembourg: Publications Office of the European Union, 2018 

© European Union, 2018 
Reuse is authorised provided the source is acknowledged.  
The reuse policy of European Commission documents is regulated by Decision 2011/833/EU (OJ L 330, 
14.12.2011, p. 39). 
For any use or reproduction of photos or other material that is not under the EU copyright, permission 
must be sought directly from the copyright holders. 

PDF 

ISBN 978-92-79-88771-0  doi:10.2771/099541 

KL-01-18-721-EN-N 

KL-01-18-721-EN-N 
ISBN 978-92-79-88771-0 

Getting in touch with the EU 
In person 
All over the European Union there are hundreds of Europe Direct information centres. You can find the 
address of the centre nearest you at: https://europa.eu/european-union/contact_en 
On the phone or by email 
Europe Direct is a service that answers your questions about the European Union. You can contact this 
service: 
– by freephone: 00 800 6 7 8 9 10 11 (certain operators may charge for these calls), 
– at the following standard number: +32 22999696 or  
– by email via: https://europa.eu/european-union/contact_en 

Finding information about the EU 
Online 
Information about the European Union in all the official languages of the EU is available on the Europa 
website at: https://europa.eu/european-union/index_en 
EU publications  
You can download or order free and priced EU publications at: 
https://publications.europa.eu/en/publications. Multiple copies of free publications may be obtained by 
contacting Europe Direct or your local information centre (see https://europa.eu/european-
union/contact_en). 
EU law and related documents 
For access to legal information from the EU, including all EU law since 1952 in all the official language 
versions, go to EUR-Lex at: http://eur-lex.europa.eu 
Open data from the EU 
The EU Open Data Portal (http://data.europa.eu/euodp/en) provides access to datasets from the EU. 
Data can be downloaded and reused for free, for both commercial and non-commercial purposes. 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Document Metadata 

Property 

Value 

Date 

Status 

21/06/2018 

Approved 

Version 

1.01 

Authors 

Reviewed by 

Max Stahlecker – PwC EU Services 
Andrea Marcato – PwC EU Services 
Lora Van Looveren – PwC EU Services 
Nikos Loutas – PwC EU Services 
Alexandru Chiric – DG MARE 
David Berger – JRC 
Jesus Hermida - JRC 

Approved by  

Alexandru Chiric – DG MARE 

This study was prepared for the ISA Programme by: 

PwC EU Services 

Disclaimer: 

The views expressed in this report are purely those of the authors and may not, in 
any  circumstances,  be  interpreted  as  stating  an  official  position  of  the  European 
Commission. 

The  European  Commission  does  not  guarantee  the  accuracy  of  the  information 
included in this study, nor does it accept any responsibility for any use thereof. 

Reference  herein  to  any  specific  products,  specifications,  process,  or  service  by 
trade name, trademark, manufacturer, or otherwise, does not necessarily constitute 
or  imply  its  endorsement,  recommendation,  or  favouring  by  the  European 
Commission. 

All  care  has  been  taken  by  the  author  to  ensure  that  s/he  has  obtained,  where 
necessary, permission to use any parts of manuscripts including illustrations, maps, 
and  graphs,  on  which  intellectual  property  rights  already  exist  from  the  titular 
holder(s) of such rights or from her/his or their legal representative. 

 
 
 
 
 
 
Table of Contents 

EXECUTIVE SUMMARY ....................................................................................................................... 1 

1 

INTRODUCTION ............................................................................................................. 8 

1.1 
1.2 
1.3 
1.4 
1.5 

2.1 
2.2 

3.1 
3.2 
3.3 
3.4 

4.1 
4.2 
4.3 

2 

3 

4 

5 

PURPOSE AND SCOPE OF THE STUDY ................................................................................................ 8 
KEY RESEARCH QUESTION ............................................................................................................. 9 
STUDY METHODOLOGY ............................................................................................................... 10 
STRUCTURE OF THE REPORT......................................................................................................... 10 
INTENDED READERSHIP ............................................................................................................... 11 

CONTEXT – OVERVIEW OF CISE ..................................................................................... 12 

KEY ELEMENTS AND MAIN CHARACTERISTICS OF THE CISE INITIATIVE ................................................... 12 
CHALLENGES FOR CISE .............................................................................................................. 13 

COMPARISON BETWEEN CISE AND THE SELECTED PEER-DEVELOPMENTS ...................... 16 

QUALITATIVE COMPARISON WITH MISE ........................................................................................ 19 
QUALITATIVE COMPARISON WITH SEAVISION ................................................................................. 22 
QUALITATIVE COMPARISON WITH IFC ........................................................................................... 24 
QUALITATIVE COMPARISON WITH SWIM (SESAR) ......................................................................... 26 

LESSONS LEARNED AND GOOD-PRACTICES THAT CISE COULD LEVERAGE ...................... 30 

VISION AND DEVELOPMENT STRATEGY ........................................................................................... 32 
OVERALL ARCHITECTURE AND DESIGN ............................................................................................ 38 
GOVERNANCE AND ORGANISATION STRUCTURE ............................................................................... 43 

CONCLUSION ............................................................................................................... 47 

ANNEX I 

STUDY METHODOLOGY ................................................................................................ 48 

ANNEX II  MAIN CHARACTERISTICS OF CISE .................................................................................. 51 

ANNEX III 

DETAILED ANALYSIS OF MISE AND SEAVISION IN THE USA ............................................ 56 

ANNEX IV 

DETAILED ANALYSIS OF THE INFORMATION FUSION CENTRE IN SINGAPORE ................. 66 

ANNEX V 

DETAILED ANALYSIS OF THE SYSTEM WIDE INFORMATION MANAGEMENT IN EU ......... 69 

ANNEX VI 

GLOSSARY .................................................................................................................... 76 

List of Figures 

Figure 1: Key research question and areas of study ..................................................................................... 2 

Figure 2. Analysed peer-developments, long-list and short-list ................................................................... 3 

Figure 3: Areas of study ................................................................................................................................ 9 

Figure 4: Study methodology ..................................................................................................................... 10 

Figure 5: Visualisation of the produced documents and their relation to each other ............................... 11 

Figure 6: Key milestones in the evolution of CISE ...................................................................................... 13 

List of Tables 

Table 1: Key characteristics of CISE and resulting challenges ...................................................................... 3 

Table 2: High-level qualitative comparison between CISE and the peer-developments ............................. 6 

Table 3: Overview of 15 lessons learned and good practices from peer-developments ............................. 7 

 
 
Table 4: Key research questions of the study ............................................................................................... 9 

Table 5: Challenges of CISE in the areas of study ....................................................................................... 13 

Table 6. Levels of similarity to CISE ............................................................................................................ 17 

Table 7. High-level qualitative comparison between CISE and the peer-developments ........................... 18 

Table 8: Qualitative comparison between CISE and MISE .......................................................................... 19 

Table 9: Qualitative comparison between CISE and SeaVision .................................................................. 22 

Table 10: Qualitative comparison between CISE and IFC ........................................................................... 24 

Table 11. Qualitative comparison between CISE and SWIM (SESAR) ......................................................... 26 

Table 12: Structure of lessons learned and good practices ........................................................................ 30 

Table 13: Overview of 15 lessons learned and good practices of peer-developments .............................. 30 

Table 14: Introduction to CISE .................................................................................................................... 51 

Table 15: Key findings of CISE analysis ....................................................................................................... 52 

Table 16: Introduction to MISE ................................................................................................................... 56 

Table 17: Key findings of MISE analysis ...................................................................................................... 56 

Table 18: Introduction to SeaVision ........................................................................................................... 62 

Table 19: Key findings of SeaVision analysis ............................................................................................... 63 

Table 20: Introduction to IFC ...................................................................................................................... 66 

Table 21: Key findings of IFC analysis ......................................................................................................... 66 

Table 22: Introduction to SWIM (SESAR) .................................................................................................... 69 

Table 23: Key findings of SWIM (SESAR) analysis ....................................................................................... 70 

Table 24: Glossary ...................................................................................................................................... 76 

EXECUTIVE SUMMARY 

This report is the final deliverable of the Specific Contract following the request for 
services  ABC 
following 
III-000401-6000466383-REQ-01-ATT-01  having 
objective. 

the 

the  Commission 

Support 
interoperability 
achievements enabling enhanced information sharing in USA and among other 
non-EEA  maritime  states  to  assess  their  potential  to  support  maritime 
Common Information Sharing Environment (CISE) development. 

in  exploring 

relevant 

IT 

The  Maritime  Common  Information  Sharing  Environment  (CISE)  is  a  European 
initiative  that  aims  at  creating  a  political,  organisational,  technical  and  legal 
environment that fosters cooperation and information sharing across the authorities 
involved in maritime surveillance.  

This report provides the final outcome of the study having as objective to discover 
and  analyse  similar  large-scale  initiatives  (i.e.  peer-developments)  around  the 
world,  preferably  in  the  maritime  domain,  to  derive  lessons  learned  and  good 
practices  that  could  be  useful  for  consolidating  CISE  in  general  and  its 
interoperability solutions in particular.  

The study adopted the following key research question. 

Which lessons learned and good practices can CISE leverage from 
peer-developments? 

The  research  focused  on  three  areas  of  study  for  each  peer-development:  vision 
and applied development strategy, overall architecture and design, and governance 
and  organisation  structure.  Interoperability  aspects  were  also  studied  as  part  of 
each of these areas.  

The  research  results  touched  upon  three  stages  of  CISE’s  evolution:  the  current 
development in the short-term, the operational phase in the medium term, and the 
implications in the long-term.  

The scope and mandate of this analysis covered the discovery of findings applicable 
to the first stage. However, to enhance the practical value of this work, this study 
highlighted  if  lessons  learned  and  good  practices  are  also  applicable  to  the  other 
two stages of CISE’s evolution.  

The following figure depicts the key research question, the three different stages of 
CISE’s evolution, and the areas of study. 

21/06/2018 

Page 1 of 83 

 
 
 
Figure 1: Key research question and areas of study 

The study used a structured approach, to select two additional peer-developments 
to  be  analysed  along  with  the  U.S.  Maritime  Information  Sharing  Environment 
(MISE).  

Based  on  desk  research  and  in  agreement  with  the  Commission,  the  study  first 
identified  a  long-list  of  ten  peer-developments.  With  the  help  of  pre-defined 
qualitative  and  quantitative  criteria  (e.g.  number  of  participating  countries, 
regulatory  support,  information  services),  a  preliminary  analysis  was  conducted  to 
assess the relevance of these peer-developments, leading to a short-list of four.  

Subsequently,  the  study  evaluated  the  short-listed  peer-developments  in  more 
detail, highlighting the pros and cons of a further analysis, including their estimated 
relevance to each area of study. During the analysis of MISE, U.S. representatives 
suggested to also analyse Sea Vision, a web-based maritime situational awareness 
tool where users can view and share a broad array of maritime information. 

In  total,  the  study  selected  four  peer-developments  for  analysis  as  shown  in  the 
picture below. 

21/06/2018 

Page 2 of 83 

 
 
 
 
 
Figure 2. Analysed peer-developments, long-list and short-list 

In particular: 

•  The Maritime Information Sharing Environment (MISE) in the U.S. was 

selected upfront as one of the peer-developments to be analysed. 

•  SeaVision  was  selected  based  on  the  suggestion  of  the  MISE  team  as  a 

widely-used Maritime Domain Awareness tool already operational. 

•  The  Information  Fusion  Centre  (IFC)  of  Republic  of  Singapore  was 
selected  due  to  being  operational,  its  large  number  of  participating 
countries, and high relevance in maritime information sharing, especially for 
piracy combating activities. 

•  The  System  Wide  Information  Management  (SWIM)  environment 
within  SESAR  Programme  for  EU  air  traffic  management  domain  was 
selected  as  it  connects  many  legacy  systems  in  a  distributed  network,  it 
leverages  standards  to  foster  interoperability  among  a  large  number  of 
European countries, and as it is currently being implemented in Europe.  

Before  analysing  the  selected  peer-developments  in  detail,  the  study  performed  a 
first  brief  survey  of  the  current  status  of  CISE,  highlighting  its  key  characteristics 
and  main  challenges,  which  are  summarised  in  the  table  below.  Knowledge  and 
understanding  of  CISE  were  refined  using  the  same  analysis  process  (indicators) 
performed  for  peer-developments.  This  allowed  the  research  team to  set  the  right 
focus with agility during the subsequent phases of the study. 

Table 1: Key characteristics of CISE and resulting challenges 

Area of study 

Vision and 
development 
strategy 

Main evolution 
milestones 

Main characteristics and challenges  

•  Multiple countries, institutions and organisations with different missions, goals 

and interests shaped the evolution of CISE. 

  Challenge of aligning development timelines amongst a huge 

number of stakeholders. 

21/06/2018 

Page 3 of 83 

 
 
 
 
 
 
Area of study 

Main characteristics and challenges  

Vision, principles, 
value proposition 

•  The vision on what the sharing environment should entail is very broad, as the 

maritime CISE is a voluntary collaborative process seeking to achieve a 
political, organisational, technical and legal environment enabling cross-border 
and cross-sector information sharing between different national authorities 
involved in maritime surveillance. 

  Challenge of sticking to a broad vision, including many 

stakeholders, different sectors with different needs, and 
expectations. 

•  Target: 31 countries (including EEA); 
•  Current: 18 countries (participants to EUCISE2020 and national 

Countries 

interoperability projects). 

Sectors (user 
communities) 

Political and regulatory 
support (for adoption) 

Solution architecture 
approach 

Overall 
architectural 
approach 

Main building blocks 

  Challenge of alignment amongst member states, who have 
different distribution of responsibilities and legislation. 
•  7 different user communities (e.g. fisheries control, customs, border control) 

across the participating countries with different needs and wishes. 

  Challenge of alignment amongst stakeholders from various user 
communities with different operational needs and ways of 
working.   

•  Political endorsement by MSs and EU Institutions; 
•  No binding legislation; 
•  Voluntary participation. 

  Challenge of ensuring sustained buy-in on voluntary basis so that 

stakeholders are engaged in the next steps of CISE, e.g. 
implementation and day-to-day operations. 

•  To accommodate the needs, wishes and constraints of the different 

participating countries, several architecture alternatives had to be developed 
and evaluated in terms of cost-effectiveness and sustainability. This process 
resulted in a federated middleware implementing a hybrid and fully distributed 
infrastructure. 

  Challenge of finding and implementing a solution architecture 

fitting the needs and constraints of every participant. 

•  CISE Gateway / Node implementing functionality to enable the fully 

distributed infrastructure without central building blocks: 
o  CISE Services 
o  Service Registry 
o  Authority Registry 
o  Certificate Authority 

•  CISE Adaptor implementing CISE data model allows connecting Legacy 

Systems to Gateways or Nodes in different ways. 

  Challenge of defining and implementing building blocks in a fully 
distributed architecture that provide advanced data management 
functions with no central authorities. 

21/06/2018 

Page 4 of 83 

 
 
 
 
 
 
 
 
 
Area of study 

Main characteristics and challenges  

Data model 

Service model 

Strategic and 
operational 
governance (incl. 
SLAs) 

Governance 
and 
organisation 
structure 

IT Service 
Management & 
Information security 

• 

•  The data model leverages several vocabularies from different data standards 
e.g. ISA core vocabularies, American National Standards Institute (ANSI), 
International Association of Marine Aids to Navigation and Lighthouse 
Authorities (IALA), European Maritime Safety Agency (EMSA), International 
Maritime Organization (IMO), International Organization for Standardization 
(ISO), International Telecommunication Union (ITU), Open and Analysed 
Shipping Information System (OASIS), the U.S. Coast Guard, United Nations 
(UN), and World Wide Web Consortium (W3C); 
 The data model contains the several data entities: 
o  Vessel 
o  Operational assets 
o  Cargo 
o  Movement 
o  Location 
o  Action 
o  Incident 
o  Anomaly 
o  Risk 
o  Person 
o  Organization 
o  Document. 

  Challenge of defining and implementing a data model that is 

suitable to CISE stakeholders in different sectors when no 
standards exist that fits all business needs. 

•  CISE not only provides messaging services but also envisions more enhanced 

services such as fusion, simulation and collaboration services. 

  Challenge of providing advanced services in a fully distributed 

architecture. 

•  Current governance structure of CISE involves stakeholders from the different 
user  communities  plus  representatives  form  seven  relevant  European 
Agencies; 

•  The structure to govern CISE during the operational phase is under discussion. 
•  SLAs policies and management during the operational phase of CISE are being 

defined under EUCISE 2020 project. 

  Challenge  of  defining  the  suitable  governance  of  CISE  in  the 
transitional phase and in the steady-state operational phase. 

•  The  way  IT  services  are  managed  and  their  security  during  the  operational 

phase of CISE are being investigated under EUCISE 2020 project. 

•  The ultimate responsibility of information access rights lies within information 

owners. 

Key  challenges  of  CISE  in  IT  service  management  and  information 
security include the following elements? (): 

  The management of CISE’s IT services needs to take into account 
CISE’s  nature  of  being  a  hybrid  and 
fully  distributed 
infrastructure  with  different  stakeholders  (i.e.  countries  and 
agencies) and services; 

  CISE  (i.e.  the  environment  itself  and  its  management)  needs  to 
the  handling  of  classified  data  such  as  EU 

facilitate 
CONFIDENTIAL; 

  CISE information security framework for the operational phase of 

CISE is not yet defined. 

Based  on  this  insight,  the  study  conducted  a  thorough  analysis  of  the  peer-
developments, focusing on the above-mentioned areas of study.   

In  parallel,  a  qualitative  comparison  between  CISE  and  the  peer-
developments revealed that none of the peer-development is exactly similar 
to  CISE  in  all  areas  of  study.  Nonetheless,  the  comparison  allowed  for  an 
interesting and very useful identification of different levels of similarity in each 
areas of study, which are summarised in the following table. 

21/06/2018 

Page 5 of 83 

 
 
 
 
 
 
 
 
 
 
Table 2: High-level qualitative comparison between CISE and the peer-developments 

Area of study 

MISE 

SeaVision 

IFC 

SWIM 
(SESAR) 

Vision and 
development 
strategy 

Overall 
architectural 
approach 

Governance and 
organisation 
structure 

Legend: 

Main evolution milestones 

Vision, principles, value 
proposition 

Countries 

Sectors (user communities) 

Political and regulatory 
support (for adoption) 

Solution architecture 

Main building blocks 

Data model 

Service model 

Strategic & operational 
governance (incl. SLAs) 

IT Service Management & 
Information Security 

Similar to CISE 

  Partially similar to CISE 
  Not so similar to CISE 

?  Unknown 

? 

? 

? 

? 

? 

? 

tools 

(literature  analysis, 

While for the analysis of MISE, SeaVision and SESAR the study could use different 
research 
interviews  and 
questionnaires),  in  the  case  of  IFC  the  study  could  rely  only  on  publicly  available 
information. Moreover, as the available information did not reveal sufficient details, 
IFC was not taken into account for deriving lessons-learned and good practices 
in the context of this study. 

research, 

internet 

As result of the analysis, the study identified 15 main lessons learned and good 
practices  derived  from  the  key  findings  on  MISE,  SeaVision  and  SESAR  SWIM. 
(See chapter 4) 

During  the research  process,  the applicability  of  the  identified  lessons  learned  and 
good practices were ensured by gaining knowledge iteratively on:  

• 

• 

• 

the key characteristics and related challenges of CISE, 

the findings from the peer-developments, and 

the similarities of peer-developments to CISE per area of study. 

For  each  of  the  15  lessons  learned  and  good  practices,  PwC’s  expert  advice 
provided additional  ideas or recommendations on how these can be applied to the 
current development of CISE, to its operational phase, and to support its long-term 
sustainability. 

The following table presents these lessons learned and good practices.  

21/06/2018 

Page 6 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Table 3: Overview of 15 lessons learned and good practices from peer-developments 

Lessons learned and good practices from the peer-developments 

Vision and applied development strategy 

1 

2 

3 

4 

5 

To foster awareness and commitment to a voluntary participation, peer-developments 
rely on a strong value proposition and clear communication.  
To ease and speed-up adoption and implementation, peer-developments leverage fit-for-
purpose regulatory support. 
To manage complexity of the implementation processes, peer-developments apply a 
step-by-step approach. 
To foster interoperability and  its implementation, peer-developments embrace and 
propose standards. 
To facilitate uptake and participation of stakeholders, peer-developments promote 
standalone initiatives that develop and manage selected building blocks (e.g. data model, 
network, service model).  

Overall architecture and design 

6 

7 

8 

9 

10 

To better manage complexity and communicate functional and technical aspects, peer-
developments apply an Enterprise Architecture approach.  
To better manage services and foster organisational interoperability, peer-developments 
implement a standard service reference model and service registry. 
To improve semantic interoperability, peer-developments provide clear documentation 
and guidance for the use of their data models. 
To optimise implementation efforts, peer-developments group infrastructure capabilities 
into coherent sets (profiles) adapted to different user needs. 
To ensure secure cross-border information exchange, peer-developments are developing 
information security frameworks based on agreed security standards.  

Governance and organisation structure 

11 

12 

13 

14 

15 

To facilitate suitable governance of strategic, operational and technical layers, peer-
developments set up a tailored structure with dedicated governance bodies. 
To speed-up implementation and coordinate efforts of stakeholders, peer-developments 
worked on establishing a dedicated governance structures as early as possible 
To have a smooth collaboration between R&D activities and implementation, peer-
developments have established an "innovation pipeline" between dedicated governance 
bodies. 
To enable and ensure exchange of information, peer-developments develop legal 
frameworks (SLA, MoUs, etc.) 
To leverage industry expertise during R&D, peer-developments establish public-private-
partnerships. 

This study acknowledged, as an overall conclusion, that none of the identified 
peer-developments  has  the  same  key  characteristics  of  CISE.  Nonetheless,  their 
similarities  per  area  of  study  allowed  to  identify  15  applicable  lessons  learned 
and  good  practices  that  could  help  CISE  overcome  its  development  and 
implementation challenges in the short, medium and long-term.  

Finally, the study suggests that these lessons learned and good practices could be 
useful in the upcoming in-depth analysis/ reviews of this initiative to be performed 
by the Commission in 2018. 

21/06/2018 

Page 7 of 83 

 
 
 
 
 
 
1  INTRODUCTION 

This  introductory  section  provides  an  overview  of  the  study  and  clarifies  its 
purpose. Then, the  methodology  of  the  study  is  presented  at high-level.  Finally, it 
elaborates  on  the  intended  readership  of  this  final  report  and  on  the  structure  of 
the next sections. 

1.1  Purpose and scope of the study 

The  Maritime  Common  Information  Sharing  Environment  (CISE)  is  a  European 
initiative  that  aims  at  creating  a  political,  organisational,  technical  and  legal 
environment  that  fosters  information  sharing  across  sectors  and  borders  between 
the authorities involved in maritime surveillance.  

CISE  thus  aims  to  support  a  more  efficient  and  effective  maritime  surveillance, 
which has been hampered by legal, organisational, semantic, and technical barriers. 
By  exploring  similar  large-scale  IT  interoperability  initiatives,  identifying  their 
distinctive traits and their success factors, this report will propose relevant lessons 
learned for the future steps of CISE. 

“Each  and  every  of  these  peer-developments  probably  had  to 
overcome certain obstacles initially. CISE can learn from these.”  

For  this  purpose,  this  study  gathered  relevant  information  on  the  Maritime 
Information Sharing Environment (MISE) in the U.S., the System Wide Information 
Management  (SWIM)  of  the  Single  Sky  ATM  Research  (SESAR)  Programme  in  the 
EU,  and  the  Information  Fusion  Centre  (IFC)  in  Singapore.  Analysing  these  three 
similar  initiatives  will  enable  to  identify  lessons  learned  and  good  practices. 
Moreover,  this  project  could  also  serve  the  purpose  to  establish  the  exchange  of 
ideas between CISE and the peer-developments. 

“We  see  this  study  as  initiator  for  future  cooperation  with  the  peer-
developments.  The  idea  is  that  collaboration  and  interaction  should 
continue also after this study.” 

The  scope  of  the  study  includes  developing  a  detailed  methodology  for  the 
collection and analysis of the aforementioned information according to the following 
subjects, also summarised in Figure 3 below. 

•  Vision and the applied development strategy, with focus on the values, 

goals and objectives, scope and constraints; 

•  Overall IT architectural approach and design, including architectural 
principles, patterns, use cases, architectural building blocks, data models 
and information services; 

•  Governance and the organisation structure in place to achieve strategic 
objectives, manage risks, and enable stakeholder engagement and buy-in; 
and 

•  Interoperability aspects at legal, organisational, semantic and technical 
level will also be investigated within each of the three areas mentioned 
above.  

21/06/2018 

Page 8 of 83 

 
 
 
Vision and applied 
development 
strategy 

Overall technical 
architecture and 
design  

Governance and 
organisation 
structure 

Interoperability aspects 

Figure 3: Areas of study 

1.2  Key research question 

To put this report in its wider context, the following key research question has been 
used to guide the analysis. 

Which lessons learned and good practices can CISE leverage 
from peer-developments? 

When  it  comes  to  evaluating  peer-developments,  this  key  research  question 
touches three stages of CISE’s evolution: the current development, the operational 
phase and the long-term sustainability. 

Table 4: Key research questions of the study 

Which lessons learned and good practices can CISE leverage from peer-
developments? 

Stage 1 - Lessons learned and 
good practices from peer-
developments that could be 
relevant to the current 
development of CISE. 

Stage 2 - Lessons learned and 
good practices from peer-
developments which the CISE 
initiative could leverage to 
support the operational phase 
of CISE. 

Stage 3 - Lessons learned and 
good practices from peer-
developments which the CISE 
initiative could leverage to 
support the long-term 
sustainability of CISE. 

•  Vision and development 

strategy; 

•  Overall architecture and design; 
•  Governance and organisation 

structure. 

•  Agreement on vision, business 
model and operating model; 

• 

Implementation planning and 
choice between rapid 
deployment vs. a “consolidate & 
deploy” approach; 

•  Governance of the transition 

period. 

• 

Focus on adding value and 
meeting stakeholders’ needs; 

• 

Integration of future research 
outcomes into the operational 
CISE, in order to make CISE 
flexible and agile to changes; 
•  Continuous improvement, i.e. 
efficiency and effectiveness of 
the governance. 

The  scope  and  mandate  of  this  analysis  covers  the  discovery  of  findings  that  are 
applicable  to  the  first  stage  only.  However,  to  enhance  the  practical  value  of  this 

21/06/2018 

Page 9 of 83 

 
 
 
 
 
 
 
 
 
 
 
work, this report will highlight if findings or interesting traits are also applicable to 
the other two stages of CISE’s evolution. 

1.3  Study methodology  

The study methodology consisted of three phases. 

1.  The scoping phase determined how the analysis was going to be conducted 
and  identified  –  based  on  selection  criteria  –  2  other  peer-developments 
(preferably in the maritime sector) in addition to MISE. 

2.  The  data  collection  phase 

the  developed  analysis 
first 
methodology, using CISE as a test case, and – where needed – refined the 
methodology.  This  allowed  to  have  the  right  focus  before  going  on  to 
gathering information from the other 3 peer-developments. 

tested 

3.  The  analysis  phase  evaluated  the  peer-developments  and  derived  lessons 

learned and good practices for CISE. 

2. Determine a 
framework for 
analysis and 
evaluation

4. Perform a brief 
survey on the 
current status of 
CISE.

1. Set the analysis 
objective and 
approach

3. Identify and 
select similar 
projects
(in addition to 
MISE)

5. Collect 
information on the 
shortlisted 
projects following 
the analysis 
framework

6. Elicit lessons 
learned, good practices 
and recommendations

Figure 4: Study methodology 

Further details are available in Annex I. 

1.4  Structure of the report 

This study report is structured along 4 sections, which are supported by 5 annexes: 

•  Section 1, this  section,  introduces  this  report.  It  contains  the  purpose  and 
scope of the project, the key research question, the study methodology and 
intended readership. 

•  Section  2  provides  an  overview  of  CISE  by  describing  its  key  aspects, 
including  EUCISE2020.  It  serves  as  a  solid  basis  for  further  discussion  and 
for the comparison of CISE with the three other peer-developments.  

•  Section  3  contains  a  comparison  between  CISE  and  each  of  the  selected 

peer-developments. 

•  Section 4 provides the consolidated lessons learned and good practices that 
have been found while analysing the peer-developments, with references to 

21/06/2018 

Page 10 of 83 

 
 
 
 
the  corresponding  key  findings  and  peer-development  they  were  deducted 
from. 

•  Section  5  includes  a  wrap-up  of  the  study  and  provides  an  advice  for 
Directorate-General  for  Maritime  Affairs  and  Fisheries  (DG  MARE)  and  Joint 
Research Centre (JRC) regarding the further development of CISE.  

•  Finally,  Annex  I  contains  the  detailed  methodology  used  throughout  the 
project, Annex II provides some introductory information on CISE. Annex 
III,  and  Annex  IV  and  Annex  V  briefly  introduce  the  analysed  peer-
developments and present the key findings gathered from their analysis. 

This  final  study  report  aggregates  the  information  from  various  other  key 
documents  produced  during  this  study.  The  following  figure  facilitates  the 
understanding of how the different key documents of this study relate to each other 
and what each of those documents contain. 

Final study report

• Similarity to CISE
• Key findings

Detailed analysis 
of MISE and 
SeaVision

• Areas of study
• Selected peer-developments

Detailed 
methodology  
for the analysis 
of peer-
developments

• Detailed study activities
Long-list of peer-developments
•
• Evaluation of short-listed peer-

developments

Detailed analysis 
of SESAR

• Vision and applied 

development strategy
• Overall architectural 

approach

• Governance and 

organisation structure

Detailed analysis 
of IFC

Figure 5: Visualisation of the produced documents and their relation to each other 

1.5  Intended readership 

This  study  report  addresses  readers  who  are  concerned  with  maritime  information 
sharing. These include: 

•  Representatives from the European Commission (e.g. DG MARE, JRC); 

•  Partners of EUCISE 2020 project;  

•  CISE’s stakeholders; and  

•  Any persons interested in aspects of (maritime) information sharing. 

The potential needs that this study report aims to fulfil include: 

•  Consolidation  of  available  information  on  relevant  information  sharing 

initiatives, that is CISE and its peer-developments; and 

•  Provision of insights on how CISE could evolve over time, based on lessons 

learned and good practices from the peer-developments. 

21/06/2018 

Page 11 of 83 

 
 
 
 
2  CONTEXT – OVERVIEW OF CISE 

This section presents the key aspects of CISE and EUCISE2020 that are relevant for 
this study. This will serve as basis for further discussion and for the comparison of 
CISE  with  the  three  peer-developments  under  investigation.  First,  the  overall 
history on the evolution of CISE is outlined, then the most important challenges of 
CISE covering the three areas of study are presented.  

More detailed information on CISE is available in Annex II.  

2.1  Key  elements  and  main  characteristics  of  the  CISE 

initiative 

In  2005,  the  first  step  towards  the  birth  of  CISE  was  taken  via  the  European 
Commission’s Strategic Objectives for 2005-2009, including “The particular need for 
an all-embracing maritime policy aimed at developing a thriving maritime economy 
and  the  full  potential  of  sea-based  activity  in  an  environmentally  sustainable 
manner”. 

Several papers and policies were then set out that would lead to CISE’s actual birth 
in  2009  as  part  of  the  EU’s  Integrated  Maritime  Policy.  Until  2014,  guidelines, 
roadmaps  were  crafted  and  other  preliminary  steps  (such  as  pilot  projects, 
consultations,  impact  assessments,  studies,  etc.)  were  taken  towards  the 
establishment  of  CISE,  with  continuous  support  from  the  Parliament  and  the 
Council  and  with  the  Commission  playing  the  role  of  coordinator  between  Member 
States.  

Then,  to  provide  a  real-world  demonstration of  the  potential  of  the CISE, the pre-
operational  validation  (POV)  project  EUCISE  2020  was  kicked  off  in  2014.  It  was 
then  initiated  with  the  “initial  definition  phase”  and  in  2016,  the  preparatory  and 
execution phase started, which is ongoing to date. At the end of 2020, CISE will be 
fully operational. 

The  figure  below  is  a  timeline  of  CISE  that  represents  the  key  milestones  in  its 
evolution. 

21/06/2018 

Page 12 of 83 

 
 
 
 
 
Figure 6: Key milestones in the evolution of CISE 

2.2  Challenges for CISE 

Before diving into the analysis of CISE and its peer-developments, it is important to 
note  the  challenges  that  CISE  needs  to  tackle.  This  table  is  the  result  of  the  brief 
survey  of  CISE  which  helped  to  set  the  baseline  for  the  comparisons  with  peer-
developments presented later in section 3.  

Table 5: Challenges of CISE in the areas of study 

Area of study 

Main challenges of CISE 

Vision and 
development 
strategy 

Main evolution 
milestones 

Vision, principles, 
value proposition 

Countries 

Sectors (user 
communities) 

•  Multiple countries, institutions and organisations with different missions, goals 

and interests shaped the evolution of CISE. 

  Challenge of aligning development timelines amongst a huge 

number of stakeholders. 

•  The vision on what the sharing environment should entail is very broad, as the 

maritime CISE is a voluntary collaborative process seeking to achieve a 
political, organisational, technical and legal environment enabling cross-border 
and cross-sector information sharing between different national authorities 
involved in maritime surveillance. 

  Challenge of sticking to a broad vision, including many 

stakeholders, different sectors with different needs, and 
expectations. 
•  Target: 31 countries (EEA); 
•  Current: 18 countries (EUCISE2020 participants). 

  Challenge of alignment amongst stakeholders from many 

jurisdictions, who have different needs, ways of working and 
legislation. 

•  7 different user communities (e.g. fisheries control, customs, border control) 

across the participating countries with different needs and wishes. 

  Challenge of alignment amongst stakeholders from various user 

communities with different needs and ways of working.   

21/06/2018 

Page 13 of 83 

 
 
 
 
 
 
 
Area of study 

Main challenges of CISE 

Political and regulatory 
support (for adoption) 

Solution architecture 
approach 

Main building blocks 

Overall 
architectural 
approach 

Data model 

Service model 

Governance 
and 
organisation 
structure 

Strategic and 
operational 
governance 

•  Political endorsement by MSs and EU Institutions; 
•  No binding legislation; 
•  Voluntary adoption. 

  Challenge of ensuring sustained buy-in on voluntary basis so that 

stakeholders are engaged in the next steps of CISE, e.g. 
implementation and operation. 

•  To accommodate the needs, wishes and constraints of the different 

participating countries, several architecture alternatives had to be developed 
and evaluated in terms of cost-effectiveness and sustainability. This process 
resulted in a Federated middleware implementing a hybrid and fully 
distributed infrastructure. 

  Challenge of finding a solution architecture fitting the needs and 

constraints of every participant. 

•  CISE Gateway / Node implementing functionality to enable the fully 

distributed infrastructure without central building blocks: 
o  CISE Services 
o  Service Registry 
o  Authority Registry 
o  Certificate Authority 

•  CISE Adaptor implementing CISE data model allows connecting Legacy 

Systems to Gateways or Nodes in different ways. 

  Challenge of defining and implementing building blocks in a fully 
distributed architecture that provide advanced data management 
functions with no central authorities. 

• 

•  The data model leverages several vocabularies from different data standards 
e.g. ISA core vocabularies, American National Standards Institute (ANSI), 
International Association of Marine Aids to Navigation and Lighthouse 
Authorities (IALA), European Maritime Safety Agency (EMSA), International 
Maritime Organization (IMO), International Organization for Standardization 
(ISO), International Telecommunication Union (ITU), Open and Analysed 
Shipping Information System (OASIS), the U.S. Coast Guard, United Nations 
(UN), and World Wide Web Consortium (W3C); 
 The data model contains the several data entities: 
o  Vessel 
o  Operational assets 
o  Cargo 
o  Movement 
o  Location 
o  Action 
o  Incident 
o  Anomaly 
o  Risk 
o  Person 
o  Organization 
o  Document. 

  Challenge of defining a data model that is suitable to CISE 

stakeholders in different sectors when no standards exist that fits 
all business needs. 

•  CISE not only provides messaging services but also envisions more enhanced 

services such as fusion, simulation and collaboration services. 

  Challenge of providing advanced services in a fully distributed 

architecture. 

•  Current governance structure of CISE involves stakeholders from the different 
user  communities  plus  representatives  form  seven  relevant  European 
Agencies; 

•  The structure to govern CISE during the operational phase is under discussion. 
•  SLAs policies and management during the operational phase of CISE are being 

defined under EUCISE 2020 project. 

  Challenge  of  defining  the  governance  of  CISE  in  the  transitional 

phase and in the steady-state phase. 

21/06/2018 

Page 14 of 83 

 
 
 
 
 
 
 
 
 
 
Area of study 

Main challenges of CISE 

IT Service 
Management & 
Information security 

•  The  way  IT  services  are  managed  and  their  security  during  the  operational 

phase of CISE are being investigated under EUCISE 2020 project. 

•  The ultimate responsibility of information access rights lies within information 

owners. 

Key  challenges  of  CISE  in  IT  service  management  and  information 
security include the following. 

  The management of CISE’s IT services needs to take into account 
CISE’s  nature  of  being  a  hybrid  and 
fully  distributed 
infrastructure  with  different  stakeholders  (i.e.  countries  and 
agencies) and services; 

  CISE  (i.e.  the  environment  itself  and  its  management)  needs  to 
facilitate the handling of data classified as EU CONFIDENTIAL; 
  CISE  information  security  framework  during  the  operational 

phase of CISE is not yet defined. 

21/06/2018 

Page 15 of 83 

 
 
 
 
 
 
3  COMPARISON  BETWEEN  CISE  AND  THE  SELECTED  PEER-

DEVELOPMENTS 

To  answer  the  key  research  question,  this  study  explored  large  scale  IT 
interoperability  initiatives  similar  to  CISE  to  identify  lessons  learned  and  good 
practices that can be useful for CISE1. 

The exploratory research found 10 candidate initiatives: 

•  Australia-Japan-US maritime cooperation2 

•  The Northeast Asia Logistics Information Service Network (NEAL-NET)3 

•  The Piracy Reporting Centre (PRC) based in Malaysia4 

•  The Maritime Safety and Security Information System (MSSIS)5 

•  The Information Sharing Centre (ISC) based in Singapore6 

•  NATO’s Maritime Surveillance System7 

•  The Information Fusion Centre (IFC) based in Singapore8 

•  The West Africa Police Information System (WAPIS) Programme9 

•  The ECCAS Maritime Security Strategy10 

•  The  System  Wide  Information  Management  infrastructure  (SWIM),  part  of 

the Single European Sky ATM Research (SESAR) Programme11. 

Among these, only the IFC and SESAR’s SWIM were selected as the most relevant 
for this study according to the agreed criteria. Then, as a project requirement, the 
study  included  a  survey  on  the  U.S.  Maritime  Information  Sharing  Environment 
(MISE).  In  addition,  also  SeaVision  was  added  to  the  study,  following  the 
suggestion of U.S. representatives. 

In summary, the following peer-developments were analysed in detail. 

•  The Maritime Information Sharing Environment (MISE) in the U.S. was 

selected upfront as one of the peer-developments to be analysed. 

1 More detailed information on the study methodology is available in Annex I. 
2 See: https://spfusa.org/event/21st-century-trilateral-maritime-cooperation/ 
3 See: http://www.nealnet.org 
4 See:  

- 
- 

https://www.icc-ccs.org/piracy-reporting-centre  
https://bookshop.iseas.edu.sg/account/downloads/get/18222 

5 See: https://mssis.volpe.dot.gov/Main/ 
6 See: http://www.recaap.org  
7 See: http://www.cmre.nato.int/research/maritime-situational-awareness  
8 See:  

- 
- 

http://www.infofusioncentre.gov.sg  
http://bueger.info/a-role-model-for-information-sharing-visiting-the-singapore-ifc/ 

9 See:  

- 
- 

https://www.sesarju.eu/  
http://www.sesardeploymentmanager.eu/  

10 See: http://www.consilium.europa.eu/en/meetings/fac/2015/03/st07168_en15_pdf/ 
11 See: https://www.interpol.int/es/content/download/18670/166659/version/ 

15/file/Brochure%20WAPIS%20EN_2016%2007_2_LR.pdf  

21/06/2018 

Page 16 of 83 

 
 
 
                                                 
 
 
•  SeaVision  was  selected  based  on  the  suggestion  of  the  MISE  team  as  a 

widely-used Maritime Domain Awareness tool already operational. 

•  The  Information  Fusion  Centre  (IFC)  of  Republic  of  Singapore  was 
selected  due  to  being  operational,  its  large  number  of  participating 
countries, and high relevance in maritime information sharing, especially for 
piracy combating activities. 

•  The  System  Wide  Information  Management  (SWIM)  environment 
within  SESAR  Programme  in  EU  air  traffic  management  domain  was 
selected  as  it  connects  many  legacy  systems  in  a  distributed  network,  it 
leverages  standards  to  foster  interoperability  among  a  large  number  of 
European countries, and as it is currently being implemented in Europe. 

From  this  exploration  exercise,  the  uniqueness  of  CISE  was  confirmed  by  the  fact 
that  no  peer-development  was  found  being  similar  to  CISE  in  all  areas  of  study. 
Different  peer-developments  showed  different  levels  of  similarity  on  the  different 
areas of study, which can nonetheless provide useful insight.  

To  ensure  the  relevancy  and  applicability  of  answers  to  the  key  research  question 
and  to  appropriately  position  the  identified  lessons  learned  and  good  practices  in 
the  right  context, these  different  levels  of  similarity  are presented in  the  following 
tables. The study differentiates between the following levels of similarity to CISE. 

Levels of similarity to CISE 

Definition 

Table 6. Levels of similarity to CISE 

Similar to CISE 

Partially similar to CISE 

  Not so similar to CISE 

? 

Unknown 

The peer-development is comparable to CISE, therefore any 
identified lessons-learned and good practices of the peer-
development have a high probability of being relevant to CISE. 

The peer-development is somewhat comparable to CISE, 
therefore any identified lessons-learned and good practices of the 
peer-development have a medium probability of being relevant to 
CISE. 

The peer-development is not comparable to CISE, therefore any  
identified lessons-learned and good practices of the peer-
development have a low probability of being relevant to CISE. 

Insufficient information on the peer-development was available 
to properly determine the level of similarity to CISE. Thereofore, 
any identified lessons-learned and good practices of the peer-
development might not be relevant to CISE. 

The below table shows a high-level qualitative comparison overview between CISE 
and  the  selected  peer-developments  regarding  the  three  areas  of  study.  A  more 
detailed  qualitative  comparison  between  each  specific  peer-development  and  CISE 
can be found further on in this section. 

21/06/2018 

Page 17 of 83 

 
 
 
 
 
 
 
Table 7. High-level qualitative comparison between CISE and the peer-developments 

Area of study 

MISE 

SeaVision 

IFC 

SESAR 
(SWIM) 

Vision and 
development 
strategy 

Overall 
architectural 
approach 

Governance and 
organisation 
structure 

Legend: 

Main evolution milestones 

Vision, principles, value 
proposition 

Countries 

Sectors (user communities) 

Political and regulatory 
support (for adoption) 

Solution architecture 

Main building blocks 

Data model 

Service model 

Strategic & operational 
governance (incl. SLAs) 

IT Service Management & 
Information Security 

 Similar to CISE 

  Partially similar to CISE 
  Not so similar to CISE 

  ?  Unknown 

? 

? 

? 

? 

? 

? 

The following  four  tables  elaborate  in  more  detail  the  qualitative  level  of  similarity 
CISE.
between 

peer-developments’ 

each 

four 

and 

the 

of 

21/06/2018 

Page 18 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3.1  Qualitative comparison with MISE 

Table 8: Qualitative comparison between CISE and MISE 

Area of study 

MISE 

Comparison to CISE 

•  Maritime Domain Awareness (MDA) related policies in response 

Main evolution 
milestones 

to 9/11  
Partnership with NIEM for the data model. Several small-scale 
demonstration with military, and a pilot.  

•  Both MISE and CISE are not yet operational 
•  MISE did not have large-scale research and pilot projects as CISE has been doing.  
•  MISE has no target date for implementation and deployment, whereas the target 

date for CISE is 2020. 

Vision, 
principles, 
value 
proposition 

Countries 

Sectors (user 
communities) 

Political and 
regulatory 
support (for 
adoption) 

Solution 
architecture 

Vision and 
development 
strategy 

Overall 
architectural 
approach 

•  MISE is not yet operational 
•  MISE vision is to establish a national-level enterprise 
architecture to enhance Maritime Domain Awareness. 

•  MISE and CISE’s vision are similar. Both seek to establish information sharing in 

the maritime domain. 

•  CISE values proposition also includes the provision of advanced services (e.g. 

fusion)  

•  Maximum: U.S. government + international partner nations 
•  Actual: None. 
•  Not formally listed.  
•  Identified as the members of the “Global Maritime Community 

of Interest (GMCOI)”  

•  Political endorsement by the Maritime Domain Awareness 

Executive Steering Committee12 and National Security Council. 

•  MISE involves possibly U.S. partner nations worldwide, whereas CISE targets the 

European Economic Area only. 

•  CISE and MISE target very similar stakeholders in the maritime domain. 
•  CISE’s user communities are listed in COM (2010) 584.  
•  MISE’s user communities are not formally listed. 
•  Both CISE and MISE are endorsed at political level. 
•  Participation in both CISE and MISE is voluntary. 

•  No binding legislation. 
•  Voluntary participation. 

•  Hub and spoke architecture implementing a centralised 

infrastructure 

•  MISE has a more centralised architecture than CISE’s, however, as MISE is not yet 
operational, implementation details on the actual architecture are not available. 

•  Definition of SOA architecture paradigm based on NIEM and 

web standards 

12 The Maritime Domain Awareness Executive Steering Committee (MDA ESC) is comprised of senior executive-level Principals designated by their respective departmental 

Executive Agents (EA) for MDA from cabinet-level departments (currently Defence, Transportation, and Homeland Security) and the designated maritime representative of the 
Intelligence Community (IC).  

21/06/2018 

Page 19 of 83 

 
 
 
                                                 
 
 
 
 
 
 
 
 
 
 
 
Main building 
blocks 

Data model 

Service model 

•  Information Sharing Infrastructure (ISI) implementing: 
o  Service interfaces for providers and consumers. 
o  Information Management, which includes an intermediary 

caching mechanism. 

o  Entitlement Management, which enforces access rights. 
o  Logging and auditing 

•  Centralised Public Key Infrastructure (called Trust Fabric) 

•  Vocabularies:  

o  NIEM and NIEM-Maritime  
o  NIEM Maritime Domain Awareness Enterprise Information 

Exchange Model (EIEM) 

•  Data entities (defined as NIEM IEPDs): 

o  Vessel position 
o  Notice of arrival 
o  Indicators and notifications 
o  Vessel Information 
o  Consolidated Vessel Information and Security Reporting 

(CVISR) 

For each data entity of MISE data model (i.e. for each IEPD), two 
services are defined: 
•  Search service, allowing consumers to search for data using 

fixed sets of parameters. 

•  (optional) Publish service to the intermediary cache hosted in 

the ISI. 

•  From a functional perspective, MISE and CISE are similar. 
•  In MISE, several data management functions are performed by the ISI building 

block (filtering, caching), whereas in CISE the nodes perform these activities having 
a more distributed approach. 

•  Both CISE and MISE implement Public Key Infrastructures. However in MISE, the 

Trust Fabric relies on a central authority (the MISE Management body) that 
manages the list of trusted systems and issues certificates. In CISE, there is no 
central authority and the approach is more federated. 

•  CISE and MISE share information on similar topics. 
•  CISE and MISE data models reuse existing standards in the maritime domain. 
•  For historical reasons, the evolution of MISE data model followed a more modular 

approach than CISE’s, where the original NIEM core was extended with NIEM-M and 
ad-hoc MISE-specific vocabularies. CISE data model was developed from the 
beginning in CISE-specific R&D projects. 

•  Both CISE and MISE define services for each data entity in the data model. 
•  MISE implements only synchronous messaging patterns, while CISE implements 

only asynchronous messaging patterns. 

•  From the consumer perspective, MISE requires a periodic polling mechanism to 

fetch updates, whereas CISE implements a publish/subscribe pattern that work also 
if consumers and providers do not know each other in advance.  

•  MISE supports fixed set of parameters for each service, while in CISE a “Query by 

example” mechanism is also implemented. 

Governance 
and 
organisation 
structure 

Strategic & 
operational 
governance 
(incl. SLAs) 

•  Governance  at  political  level  consists  of:  MDA  Executive 
Steering  Committee 
Intelligence 
Community),  MDA  Stakeholders  board,  Information  hubs 
(vessel,  cargo,  people,  infrastructure,  architecture),  which  all 
lie within U.S. Government. 

(DOD,  DOT,  DHS, 

•  Governance  at  level  of  MISE  operations  consists  of:  Board  of 
Directors (BOD), MISE Management, and Configuration Control 
Board. 

•  Strategic governance of MISE and U.S. Maritime Domain Awareness is led by U.S. 
government, whereas in CISE efforts are conducted by Member States and EU 
Commission collectively. 

•  At the level of information sharing environment governance, MISE identified the 

need of having governance structures in place to manage the day-to-day 
operations of the sharing environment and its evolution. In this regard, no 
comparison is possible as CISE governance is not yet defined. 

•  In MISE, high-level concepts on SLAs have been proposed. In CISE these are being 

•  The  MISE  Management  body  is  responsible  for  IT  service 

investigated under EUCISE 2020 project. 

Management and SLAs 

21/06/2018 

Page 20 of 83 

 
 
 
 
 
 
 
•  IT Service Management concepts are defined in MISE at high-

•  In MISE, high-level description of IT Service Management aspects are identified.  In 

IT Service 
Management & 
Information 
Security 

level. 

•  MISE Management is responsible for information security of the 
environment and is in charge for setting and managing the 
public key infrastructure (Trust Fabric). 

•  Trusted Systems owners are responsible of enforcing security 

attributes to data and to the users. 

CISE these are being investigated under EUCISE 2020 project. 

•  In CISE the ultimate responsibility of information security lies within information 

owners. In MISE, the MISE Management function is responsible for the centralised 
aspects of information security (i.e. setting up and maintenance of the PKI). 

21/06/2018 

Page 21 of 83 

 
 
 
 
 
 
 
 
3.2  Qualitative comparison with SeaVision 

 Table 9: Qualitative comparison between CISE and SeaVision 

Area of study 

SeaVision 

Comparison to CISE 

•  SeaVision was developed as a web-based interface for MSSIS 13 
and became a standalone web application in recent years. 

•  Unlike CISE, SeaVision is operational.  
•  Unlike CISE, SeaVision was originally conceived as a component of a 

Main evolution 
milestones 

Vision, principles, 
value proposition 

•  SeaVision publishes data using NIEM data model. 
• 

 The long-term strategy of SeaVision is to transition its 
functionality into a DoD program of record (POR) to provide an 
enterprise unclassified information sharing platform. 

•  SeaVision’s value proposition is in line with the U.S. National 

MDA Architecture and MISE’s value proposition.  

Vision and 
development 
strategy 

Countries 

•  Target: SeaVision was originally foreseen for use by 

NAVAF/NAVEUR for use with their international partners for 
partnership building. 

•  Actual: US Government (US Navy), over 60 US partner nations, 

other government and non-government organizations. 

different system (MSSIS). 

•  SeaVision’s long term strategy is to be embedded into a multi-purpose 

portal. CISE is envisioned to stay a standalone initiative. 

•  CISE focuses on interoperability between existing systems. SeaVision is 
promoted mainly as a specific application. SeaVision focus is being a 
mission-specific tool, not an environment or set of standards as in CISE. 

•  SeaVision aims users outside national borders. 
•  Actors from private sector are out of scope both in CISE and SeaVision 

Sectors (user 
communities) 

Political and 
regulatory support 
(for adoption) 

•  SeaVision target sectors are not formally defined, however they 

•  SeaVision has stronger focus on military than CISE. 

can be identified as Defence and any sector involved in achieving 
MDA 

•  As SeaVision is one initiative within U.S. DOD, its political 

support lies within U.S. DOD itself, which is committed to provide 
funds. 

•  No binding legislation exists to support SeaVision’s adoption, 

which is on a voluntary basis. 

•  SeaVision is solely funded by the U.S. Department of Defence. 
•  Both CISE and MISE are not mandated by legal provisions. Therefore 

they both rely on voluntary adoption.  

Overall 
architectural 

Solution 
architecture 

•  Hybrid-cloud based, multi-tier architecture implementing a 

•  SeaVision has a centralised web-based application architecture. CISE 

centralised web application 

implements a distributed network of nodes for exchanging information 
between end-user applications. 

13 The Maritime Safety and Security Information System (MSSIS) is a “freely-shared, unclassified, near real-time data collection and distribution network. Its member countries 

share data from Automatic Identification Systems (AIS)”. MSSIS is run by the U.S. Department of Transportation's Volpe Center. 

21/06/2018 

Page 22 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
                                                 
 
 
Area of study 

approach 

Governance 
and 
organisation 
structure 

Main building 
blocks 

Data model 

Service model 

Strategic and 
operational 
governance (incl. 
SLAs) 

IT Service 
Management & 
Information 
Security 

SeaVision 

Comparison to CISE 

SeaVision’s building blocks are: 

o  Common Maritime Picture: a web-based user interface. 
o  Analytics engine. 
o  Administration. 
o  Data layer for storage and data integration from several 

sources. 

•  SeaVision uses a proprietary data model for internal processing. 
•  SeaVision publishes NIEM-Maritime data for consolidated vessel 

information. 

•  SeaVision is experimenting NIEM data publishing according to the 

MISE’s specification (Search service). 

•  Most roles of SeaVision’s governance lie within U.S. DoD / Navy, 

•  SeaVision building blocks provide application level features like analytics 
and maps-based user interface. CISE building blocks are focused on 
providing data management functions among distributed nodes. 

•  SeaVision relies on an internal data model that is tailored to its analytics 
engine. NIEM is used only for data publication. CISE data model is the 
cornerstone of the sharing environment that enables interoperability 
among CISE nodes. 

•  At the time of writing, systems connecting to SeaVision can only use the 
search service to fetch NIEM data. CISE exchanges are bi-directional. 
•  Governance of SeaVision is led by U.S Navy. CISE governance will be in 

as the Office of Primary Responsibility (OPR). 

accordance to the views of EU Member States. 

•  No specific information on SLAs management has been found. 

•  An attribute-based approach is implemented for access control, a 

concept derived from MDA Architecture Plan and MISE. 

•  The idea of a PKI (the Trust Fabric from MISE) is not 

implemented. At the time of writing, authentication is done via 
username and password. 

•  Both CISE and SeaVision implement an attribute-based approach. In 
SeaVision access control is centralised and is done by SeaVision 
application itself. In CISE, access control is a distributed responsibility 
that is performed by information providers. 

21/06/2018 

Page 23 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
3.3  Qualitative comparison with IFC 

Area of study 

IFC 

Comparison to CISE 

 Table 10: Qualitative comparison between CISE and IFC 

Main evolution 
milestones 

Vision, principles, 
value proposition 

Vision and 
development 
strategy 

Countries 

Sectors 

Political and 
regulatory support 

Overall 
architectural 
approach 

Solution 
architecture 

Main building 
blocks 

Service model 

•  Persistent problem of piracy attacks and other illicit activities in the 

region around Singapore since 1980. 

•  The Republic of Singapore Navy was the driver in the development 

of IFC, gradually involving other countries by hosting their 
representatives (Information Liaison Officers) for facilitating 
communication between navies.   

•  IFC is operational since 2009. 
•  IFC’s value proposition is focused on strengthening maritime 
security in the region through the exchange of information. 

•  23 countries take part in information exchange (mainly within the 
Southeast Asia region, but also including European countries such 
as France and the United Kingdom) 

•  The Republic of Singapore Navy is the main driver of IFC evolution. 
CISE evolution is the result of collaboration between several EU 
Member States.  

•  The IFC is operational, while CISE is not yet. 

•  IFC and CISE both establish a voluntarily collaborative process 

seeking to enable information sharing between different authorities in 
many countries. 

•  CISE and IFC have similar number of participating countries. 
•  CISE is focused on countries from the European Economic Area. IFC 

has a global outlook.  

•  National law enforcement agencies (customs, defence, 

•  IFC’s sectors are those affected by piracy, including shipping 

immigration, etc.) 

•  National maritime security agencies (mainly military) 
•  Shipping industry  
•  Legal basis of IFC operations (no detailed information was 

available): 
o 

Memoranda of Understanding (MoU) between Singapore and 
participating countries; 
Data sharing agreements with other maritime security 
centres. 

o 

industry. Besides the private sector, IFC’s sectors are a subset of 
CISE’s. 

•  Both IFC and CISE are based on voluntary participation. 
•  In IFC, political support came first from the government of one 
country (Singapore). In CISE, political support results from the 
collective endorsement of the EU institutions and Member States. 

•  Funding commitment mainly by government of Singapore 
•  Participation is voluntary 
•  Open interface architecture that can be customized to different 

needs. No further details are available 

The main building blocks of IFC architecture are: 
•  Open and Analysed Shipping Information System (OASIS) 
•  Sense-Making, Analysis and Research Tool (SMART) 
No detailed information is available. 
Information not available 

Insufficient information available for comparison 

Insufficient information available for comparison  

Insufficient information available for comparison  

? 

? 

? 

21/06/2018 

Page 24 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
Area of study 

IFC 

Comparison to CISE 

•  The IFC deals with the following information entities. No 

Data model 

o 

information on the data model was found. 
o 

8 types of maritime security incidents: IUU fishing, piracy, 
irregular migration, arms trafficking, general maritime 
incidents, contraband trafficking, natural disasters, terrorism. 
Vessel data (IMO, Automatic Identification System - AIS, 
LRIT) 

Insufficient information available for comparison, although IFC’s 
information seem a subset of CISE’s. 

Governance 
and 
organisation 
structure 

Strategic and 
operational 
governance (incl. 
SLAs) 

IT Service 
Management & 
Information 
Security 

o  Weather and geographical data 

•  111 International Liaison Officers (ILOs) are the national linkages 
between Singapore and the other countries and are in charge of 
day-to-day work and decision making of the IFC.  

Insufficient information available for comparison  

•  Information not available 

Insufficient information available for comparison  

21/06/2018 

Page 25 of 83 

? 

? 

? 

 
 
 
 
 
3.4  Qualitative comparison with SWIM (SESAR) 

Area of study 

SWIM (SESAR)  

Comparison to CISE 

 Table 11. Qualitative comparison between CISE and SWIM (SESAR) 14 

Vision and 
development 
strategy 

Main 
evolution 
milestones 

Vision, 
principles, 
value 
proposition 

•  The Single European Sky Air Traffic Management research (SESAR) 

programme was launched as the technology pillar of the Commission’s 
Single European Sky initiative aiming to reform (Air Traffic Management) 
ATM in Europe.  

•  SESAR programme is structured in three phases: 

o 
o 
o 

Definition phase (2005-2008) 
Development phase (2008-2024) 
Deployment phase (2015-2035) 

•  In SESAR definition phase, a System Wide Information Management 
(SWIM) environment was envisaged as key enabler for efficient 
information exchange underpinning the entire Air Traffic Management 
architecture in Europe.  

•  SESAR’s planning horizon (2005-2035) is wider than CISE’s (combined: 
2010-2020), as SESAR focuses not only on aviation infrastructure but 
also it deeply concerns the evolution of the whole ATM sector and its 
stakeholders. 

•  Being organised as a programme almost from its start, SESAR evolution 

has been following a more structured approach than CISE. 

•  SESAR R&D and deployment activities are now running in parallel in an 
iterative fashion, while CISE has been following a sequential evolution. 

•  SWIM development and deployment are now running in parallel. 

Deployment of the most mature SWIM solutions is being performed in the 
framework on the Pilot Common Project (PCP) regulation. 

•  SESAR programme overall business vision is communicated through KPIs 

•  CISE and SESAR’S SWIM share similar values of promoting 

related to improved air and ground capacity, improved flight safety, 
reduced environmental impact and reduced overall cost of ATM. 

interoperability through service orientation and common standards. 
•  SESAR programme sets high-level quantitative targets on the ATM 

•  SWIM vision is to enable information exchanges by promoting 

interoperability at levels of standards, technology and governance. 

•  SWIM principles include accessibility to information, flexibility of 

implementation, performance, service orientation. 

business aspects. In CISE, potential benefits have been quantified, but 
these have not yet translated into KPIs that can be used to monitor 
implementation. 

14 The comparison table takes into account the relevant comparable aspects of CISE and SESAR regardless of the obvious difference of business domains (i.e. air traffic control vs. 

maritime surveillance). 

21/06/2018 

Page 26 of 83 

 
 
 
 
 
 
 
                                                 
 
Area of study 

SWIM (SESAR)  

Comparison to CISE 

Countries 

•  Target: Stakeholders within EU and possibly worldwide.  
•  Current: deployment is in progress according to the PCP in: 

o 
o 

o 

25 airports across 13 MSs and 1 non-EU country (Turkey) 
22 area control centres across 9 MSs and 3 non-EU countries 
(Serbia, Switzerland, Turkey) 
22 terminal manoeuvring areas and their respective control towers 
across 12 MSs and 2 non-EU countries (Norway, Switzerland) 

•  Both SWIM and CISE are currently targeting a subset of their potential 

stakeholders. 

•  SWIM has the ambition to scale to worldwide level and it proved its 

feasibility in 2016 global demonstration. 

Sectors 

•  SWIM targets all stakeholders involved in ATM (actors in public and 

private sector) 

Political and 
regulatory 
support 

•  SWIM, and SESAR in general, enjoyed strong political and regulatory 

support for the development and gradual deployment of mature solutions. 

•  SESAR deployment activities have been made mandatory by EU law 
through the Pilot Common Project and the establishment of the 
Deployment Manager. 

•  SWIM targets both public and private stakeholders (e.g. airlines) in the 
aviation domain. CISE targets public authorities in 7 maritime sectors. 
•  The definition and development phases of SESAR and CISE have been 
both driven by strong political support by the EU Institutions and 8 
Member States. 

•  SESAR deployment activities have been made mandatory by EU law. In 

the case of  CISE, adoption by stakeholders is voluntary. 

•  SWIM overall architecture is distributed. The architecture of some 

•  SWIM architecture foresees common components that have centralised 

Solution 
architecture 

common components has been proposed and is still being refined and is 
to be implemented in a centralised/federated way (Registry and Identity 
Management). 

aspects. CISE aims to be fully distributed. 

•  In both cases implementation and deployment aspects of the common 
components are still under discussion and might result in a similar 
approach, e.g. a federated solution. 

Overall 
architectural 
approach 

Main 
building 
blocks 

•  SWIM Technical Infrastructure (SWIM-TI) Functional Blocks and functions 

•  Both CISE and SWIM nodes are a logical concept with no particular 

are distributed across SWIM Nodes (logical entities) 

•  SWIM Registry Functional Block is the place to discover and publish the 

available services. 

•  SWIM Identity Management Functional Block for security functions. 
•  SWIM-TI Profiles defining groups of technology standards/protocols that 

deployment constraints. In the case of CISE, reference implementation of 
nodes and gateways have been developed to facilitate deployment. 
•  The idea of SWIM profiles provides stakeholders with options for the 
choice of technical protocols. In CISE there is one commonly agreed 
protocol stack. 

the services shall implement according to coherent needs. 

•  Both SWIM and CISE provide a service registry. In both cases the final 

•  Network connectivity on IP-based networks (public Internet first, then  

steady-state registries are not yet in place. 

PENS 15) 

•  Both SWIM and CISE will rely on a dedicated IP-based network. SWIM 
strategy being implemented under the PCP regulation. In the case of 
CISE, a dedicated network will be used for security reasons. 

15 The Pan-European Network Service (PENS) network is a ground network that interconnects all European ATM stakeholders. Work towards the modernisation of PENS and the establishment 

of the “NewPENS” is being performed under SESAR programme. The deployment of NewPENS is included in the PCP regulation. 

21/06/2018 

Page 27 of 83 

 
 
 
 
 
 
 
 
 
 
                                                 
 
 
 
Area of study 

SWIM (SESAR)  

Comparison to CISE 

•  The ATM Information Reference Model (AIRM) provides the common 

•  AIRM provides a generic data model on ATM that can be used by service 

Data model 

reference data model for the payload of SWIM services. 

providers to develop their own specific extensions or subsets if 
necessary. In CISE, the data model already defines all information 
entities that are needed by CISE participants, therefore no custom 
extensions are permitted to safeguard semantic interoperability. 

Service 
model 

Governance 
and 
organisation 
structure 

Strategic 
and 
operational 
governance 
(incl. SLAs) 

•  The Information Service Reference Model (ISRM) is the service model 

•  In SWIM, in principle, freedom is given to service providers to develop 

allowing freedom of specifications. The ISRM Rulebook specifies generic 
rules for documenting SWIM-compliant services. 

•  Accordingly, the PCP regulation specifies a set of services to be 

their own services as long as they respect the ISRM rulebook and use the 
AIRM data model. In CISE there is a one-to-one correspondence between 
data model entities and services in CISE specifications 

implemented: 
o 
o 
o 
o 

Aeronautical data e.g. airspace usage information and plans. 
Meteorological data, e.g. forecasts, wind speed. 
Cooperative network data, e.g. information on airport capacity. 
Flight data, e.g. flight plans, status, routes. 

•  Governance of the deployment of SWIM is made of several actors at 

different levels. (These levels are also applicable to the SESAR 
programme) 
o 

At policy level, European Commission and Member States are 
responsible for the identification and definition of Common Projects 
(e.g. the PCP) in the areas that need timely and coordinated action. 
At management level, the SESAR Deployment Manager (DM) acts as 
coordinator for implementing projects and as gateway to public 
funds. 
At implementation level, SWIM stakeholders are responsible to 
submit implementation projects to the SESAR DM in accordance to 
the common projects defined by the Commission. SWIM stakeholders 
are the ultimate responsible for implementation. 

o 

o 

•  Acting in parallel with deployment activities, SESAR Joint Undertaking is 
responsible for residual R&D and validation activities of technologies that 
are not yet mature. 

•  Governance of SWIM in operations defines the following elements, which 

•  In SWIM, the PCP regulation mandates which services shall be deployed 
first. In CISE, no prioritisation has been agreed between Member States 
yet. 

•  In SESAR and SWIM, work on dedicated R&D activities have been led by 
a public-private legal entity (SESAR JU). In CISE R&D work been led by 
the EU Commission and Member States and a dedicated body has not yet 
been defined. 

•  In SESAR and SWIM, coordination of deployment activities has been 

delegated to a dedicated body (SESAR DM). In CISE this aspect is not yet 
defined. 

•  Governance of SWIM in operations has been defined and is under 
implementation in the Pilot Common Project. In the case of CISE, 
governance is to be discussed as part of EUCISE 2020. 

are currently under further refinement. 
o 

Information Management (IM) functions: steering functions, policy 
management functions, governed functions. 
Governance groups and structure: steering group, expert group, 
management unit, SWIM users (service consumers and providers) 
which are mapped to IM functions. 
Governance processes, e.g. Service Design Management Process, 
Standards Management Process, Stakeholder Management Process. 

o 

o 

•  As part of SWIM governance framework, common policies for service 
monitoring and SLAs are still being defined and are not yet in place. 

21/06/2018 

Page 28 of 83 

 
 
 
 
 
 
 
 
Area of study 

SWIM (SESAR)  

Comparison to CISE 

IT Service 
Management 
& 
Information 
Security 

•  As part of SWIM governance framework, common policies for IT service 

•  In both SWIM and CISE, information IT service management and a 

management are still being refined and not yet in place. 

•  Information security framework around Public key infrastructure (PKI) is 

security framework involving a PKI are under definition and not yet in 
place. In CISE, discussion on PKI is part of EUCISE 2020. 

under development in the context of the PCP. 

•  The main idea of SWIM PKI is to introduce a common bridge certificate 

authority (CA) that each stakeholder’s local CA shall trust. This approach 
would ensure minimal impact on existing infrastructures.  

•  Discussion on the governance of the KPI is still ongoing. 

21/06/2018 

Page 29 of 83 

 
 
 
 
 
 
 
4  LESSONS  LEARNED  AND  GOOD-PRACTICES  THAT  CISE  COULD 

LEVERAGE  

This  section  provides  the  results  of  the  study  on  the  peer-developments.  It 
streamlines the conclusions of the research work, around a set of 15 main lessons 
learned and good practices that are considered relevant for CISE. . 

For  each  lesson  learned  or  good  practice,  a  detailed  description  is  provided  from 
several  points  of  view.  First,  an  explanation  is  given  on  the  supporting  findings 
discovered during the analysis of peer-developments. Then, PwC’s expert advice is 
provided on how the findings can be applied to the current development of CISE, to 
its operational phase, and to support its long-term sustainability. 

The  lessons  learned  and  good  practices  are  presented  according  to  the  following 
structure. 

Table 12: Structure of lessons learned and good practices 

[ID] – [Title] 

Facts 

A contextual explanation provides more details by putting together relevant 
findings which are taken solely from the analysis of peer-
developments. 

PwC advice is provided on how the mentioned findings, lessons learned and 
good practices can be useful for the current development of CISE (stage 
1). 

If applicable, additional advice is provided on how the mentioned findings, 
lessons  learned  and  good  practices  can  be  useful  to  support  the 
operational phase of CISE (stage 2). 

If applicable, additional advice is provided on how the mentioned findings, 
lessons  learned  and  good  practices  can  be  useful  to  support  the  long-
term sustainability of CISE (stage 3). 

Supporting 
findings 

Reference  to  key  findings.  Summary  tables  per  peer-development  are 
provided in Annex III, IV and V. 

Before  diving  into  the  details,  the  following  table  provides  an  overview  of  the  15 
lessons learned and good practices divided by area of study and with reference to 
the originating peer-developments. 

Note: the information gathered on the IFC was insufficient to draw insights at the 
same  level  of  detail  as  the  other  peer-developments,  therefore  the  IFC  is  not 
included in the table. 

In the table, the colour key on the right columns indicates the level of similarity of 
the  corresponding  peer-development  to  CISE  in  the  relevant  area  of  study,  where 
applicable. 

Table 13: Overview of 15 lessons learned and good practices of peer-developments 

Lessons learned and good practices from the peer-
developments 

21/06/2018 

Source peer-
developments 
(incl. similarity 
level to CISE) 

Page 30 of 83 

 
 
 
 
 
   
 
 
 
 
 
E
S
I
M

a
e
S

n
o
i
s
i
V

R
A
S
E
S

M
I
W
S

Vision and strategy 

1 

2 

3 

4 

5 

To foster awareness and commitment to a voluntary 
participation, peer-developments rely on a strong value 
proposition and clear communication. 
To ease and speed-up adoption and implementation, peer-
developments leverage fit-for-purpose regulatory support. 
To manage complexity of the implementation process, peer-
developments apply a step-by-step approach. 
To foster interoperability and participation, peer-developments 
embrace and propose standards. 
To facilitate uptake and participation of stakeholders, peer-
developments promote standalone initiatives that develop and 
manage selected building blocks (e.g. data model, network, 
service model). 

Overall architecture and design 

6 

7 

8 

9 

10 

To better manage complexity and communicate functional and 
technical aspects, peer-developments apply an Enterprise 
Architecture approach. 
To better manage services and foster organisational 
interoperability, peer-developments implement a standard 
service reference model and service registry. 
To improve semantic interoperability, peer-developments 
provide clear documentation and guidance for the use of their 
data models. 
To optimise implementation efforts, peer-developments group 
infrastructure capabilities into coherent sets (profiles) adapted to 
different user needs. 
To ensure secure cross-border information exchange, peer-
developments are developing information security frameworks 
based on established security standards.  

Governance and organisation structure 

11 

12 

13 

14 

15 

To facilitate suitable governance of strategic, operational and 
technical layers, peer-developments set up a tailored structure 
with dedicated governance bodies. 
To speed-up implementation and coordinate efforts of 
stakeholders, peer-developments aim to establish a governance 
structure as early as possible. 
To have a smooth collaboration between R&D activities and 
implementation, peer-developments establish an "innovation 
pipeline" between dedicated governance bodies. 
To enable exchange of information, peer-developments develop 
frameworks of agreements (SLA, MoUs, etc.) 
To leverage industry expertise during R&D, peer-developments 
establish public-private-partnerships. 

21/06/2018 

Page 31 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
  
 
  
  
 
  
  
 
 
  
  
 
 
 
 
 
 
 
 
 
 
  
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Legend: 

 Similar to CISE 

  Partially similar to CISE 
  Not so similar to CISE 

  ?  Unknown 

4.1  Vision and development strategy 

1 – To foster awareness and commitment to a voluntary participation, 
peer-developments rely on a strong value proposition and clear 
communication. 

Facts 

Findings from peer-developments suggest that communicating a strong 
value proposition, along with its vision and principles, contributes to 
enhance stakeholder engagement and buy-in. Such a “pull” strategy was 
performed in MISE, SeaVision and SESAR through several elements that 
promoted their missions and raised awareness among their stakeholders. 

1.  Defining and agreeing on a clearly formulated vision on topics 
such as: interoperability, cost-effectiveness, privacy, security, 
standards-based approach, user convenience, industry 
convenience [M.V.12, SV.V.6, SW.V.11, SW.V.12]. 

2.  Defining quantitative business-related KPIs for strong benefit 

communication and tracking [SW.V.10]. 

3.  Making documentation available in a central, coherent, navigable 

and interactive repository [M.V.13]. 

4.  Organising raise-awareness activities e.g. conferences, 

workshops, trainings, and best-in-class events [SW.V.9]. 

5.  Having the highest political stakeholders endorse the key 
technical elements constituting the information sharing 
environment (e.g. architecture, data model) [M.V.18, M.V.19, 
M.V.21] 

6.  On the basis of the above, involving stakeholders beyond the 
original geographical area for achieving global reach via 
international partnerships [SV.V.1, SV.V.7, SV.V.8, SW.V.13]. 

Engaging stakeholders with clear communication and a strong value 
proposition can be beneficial to CISE’s current development and beyond. 
Based on the existing but distributed material, CISE should formulate a 
strong value proposition which describes the different products and 
services offered, including their measurable benefits to CISE participants. 
One model for formulating such value proposition is Osterwalder’s Value 
Proposition Canvas16. 

Next to the value proposition, the existing information should be 
organised and be made easily available in a central repository. Key 
questions and information needs of (potential) CISE participants can be 

16 See: https://strategyzer.com/canvas/value-proposition-canvas  

21/06/2018 

Page 32 of 83 

 
 
 
 
 
 
 
 
   
 
                                                 
 
used to structure the repository. 

Furthermore, marketing activities can help to raise awareness and 
increase adoption, for instance: on-boarding support material, 
workshops, raise-awareness events. 

In the transitional phase towards operations, a strong value proposition, 
an accessible document repository and targeted marketing activities can 
help to sustain buy-in from users and all relevant stakeholders.  

For the long term sustainability of CISE, communication activities will 
remain relevant to foster voluntary participation and further evolution of 
the sharing environment, especially if regulatory options are not 
foreseen.  

In addition, a formulated value proposition helps to assess (a) if the 
offered products and services fit the users’ needs, and (b) if CISE’s key 
activities and resources efficiently and effectively support the value 
delivery. 

Supporting 
findings 

•  MISE: M.V.12, M.V.13, M.V.18, M.V.19, M.V.21 

•  SeaVision: SV.V.1, SV.V.6, SV.V.7, SV.V.8 

•  SESAR: SW.V.9, SW.V.10, SW.V.11, SW.V.12, SW.V.13 

21/06/2018 

Page 33 of 83 

 
 
 
 
 
 
 
2 – To ease and speed-up adoption and implementation, peer-
developments leverage fit-for-purpose regulatory support. 

Facts 

Issuing  specific  legislation,  as  “push”  strategy  to  boost  participation  and 
implementation,  can  encourage  the  transition  from  R&D  to  deployment 
activities. Findings from SESAR [SW.V.15, SW.V.16] show that, to be more 
effective, some points of attention can be addressed by putting in place the 
following countermeasures. 

1.  Performing  an  upfront  maturity  assessment  of  solutions  and 
stakeholder readiness in order to set realistic deadlines and manage 
expectations. 

2.  Making  references  to  technical  concepts  or  existing  standards  in 
precise  unambiguous  terms,  as  any  room  for  interpretation  can 
cause uncertainties and delays. 

3.  Including  governance  and  organisational  structures,  both  for  the 
transition phase towards operations and for the steady-state phase.  

4.  Planning  the  deployment  of  governance  structures,  even  if  in 
simplified form, as early as possible to avoid implementation delays 
due 
coordination  and  decision-making 
mechanisms. 

to  uncertainty  on 

5.  Establishing  incentives  that  prevent  stakeholders  to  bypass  the 
governance  structures  so  that  interoperability  is  safeguarded  and 
guaranteed. 

6.  Foreseeing legislation reviewing cycles to re-scope the activities and 

to address residual ambiguities or interpretation issues. 

If issuing new legislations is chosen as one option to drive the adoption and 
implementation of CISE, the points of attention outlined above can be useful 
to lower risk of delays due to uncertainty and to improve legislation 
effectiveness to suit stakeholders’ needs. 

In the operational phase, legislation reviewing cycles could be foreseen 
within the first implementation deadlines to address legal issues in an agile 
way.  

For the long term sustainability of CISE, review cycles at periodic intervals 
(e.g. 2-3 years) could be foreseen to keep legislations aligned to the 
evolving context and stakeholders’ needs. In case legislation review cycles 
are not feasible, authority should be delegated to CISE governance to 
address the points of attention 1, 2, 5 outlined above. 

e
c
i
v
d
A
C
w
P

Supporting 
findings 

SESAR: SW.V.15, SW.V.16 

21/06/2018 

Page 34 of 83 

 
 
 
 
 
 
 
 
 
 
 
3 – To manage complexity of implementation, peer-developments apply a 
step-by-step approach. 

Facts 

SESAR and SeaVision suggest that a step-by-step (incremental) approach 
is  the  preferable  option  for  implementation  activities.  SESAR  showed  that 
implementation activities can run also in parallel with R&D in an agile way.  

1.  Organising  the  necessary  work  as  a  programme,  it  is  possible  for 
dedicated  actors  to  coordinate  R&D  and  implementation  activities 
by establishing an agile, integrated pipeline [SW.V.2, SW.V.3] 

2.  The  starting  point  for  implementation  could  be  the  most  mature 
stakeholders and the technology building blocks that are ready for 
industrialisation [SW.V.3b] 

3.  Early  adopters  could  be  promoted  as  “champions”  [SW.V.7, 
SW.V.8, SW.V.9, SV.V.1], which would further contribute to:  

o 

o 

o 

the growth of confidence in the solutions delivered,  

the gradual adoption by stakeholders, and 

the increase of data exchanges in the environment. 

4.  Implementation planning should take into account the proper time 
for  industrialisation  after  formal  validation  of  the  solutions 
[SW.V.6]  

If an incremental approach is chosen for the implementation of CISE, a 
maturity assessment of technologies and stakeholders could help draft and 
promote the work plans. This would help to reduce the complexity of the 
implementation. The incremental approach would also allow CISE and its 
participants to learn from the experience gained by early adopters. 

If CISE envisages further R&D activities during the operational phase, the 
SESAR innovation pipeline can be a useful example for structuring 
collaboration and hand-over between R&D and implementation activities. 

Future evolution of CISE need to take into account different maturity levels 
of participants and involved technologies. Hence, an incremental approach 
and a structured collaboration & hand-over between R&D and 
implementation activities is beneficial. 

e
c
i
v
d
A
C
w
P

Supporting 
findings 

SeaVision: SV.V.1 

SESAR: SW.V.2, SW.V.3, SW.V.3b, SW.V.6, SW.V.7, SW.V.8, SW.V.9 

21/06/2018 

Page 35 of 83 

 
 
 
 
 
 
 
 
 
 
 
4 – To foster interoperability and participation, peer-developments 
embrace and propose standards. 

Facts 

Findings  from  MISE,  SeaVision  and  SESAR  highlighted  the  importance  of 
leveraging  existing  successful  initiatives  by  either  reusing  them  as 
standards de facto or by proposing them as new standards. In particular:  

• 

• 

Leveraging  the  success  of  existing  mature  initiatives  can  be  done 
by  establishing  partnerships  at  governance  level,  or  simply  by 
reusing the most suitable components [M.V.4, SV.V.3]. 

Proposing new standards is also a way to consolidate the output of 
R&D  efforts  and  foster  adoption.  On  this  regard,  several  lessons 
learned can be drawn from SESAR [SW.V.17] 

o  To  allow  flexibility  and  further  evolution,  it  is  better  to 
standardise  frameworks  or  rulebooks  rather  than  the 
implemented  products  (e.g.  the  ISRM  Rulebook  was 
standardised, not the specific service instances).  

o  Standardisation  should  be  triggered  by  sufficiently  large 
number  of  parties  agree  to  consolidate  the  output  of  R&D 
activities. 

o  The  process  should  be  driven  by  relevant  international 
standardisation bodies, in coordination with early adopters 
and with the sharing environment governance bodies, once 
they are in place. 

e
c
i
v
d
A
C
w
P

CISE standardisation activities should take into account the lessons 
learned from SESAR to consolidate the output of R&D efforts and foster 
participation.  

In the operational phase standards should be periodically reviewed to be 
aligned with the evolving context. 

CISE’s long term sustainability can benefit from reusing mature and 
components like those developed by the European Commission’s 
interoperability initiatives, e.g. ISA2 solutions and CEF building blocks 

Supporting 
findings 

MISE: M.V.4 

SeaVision: SV.V.3 

SESAR: SW.V.17 

21/06/2018 

Page 36 of 83 

 
 
 
 
 
 
 
 
 
 
 
5 – To facilitate uptake and participation of stakeholders, peer-
developments promote standalone initiatives that develop and manage 
selected building blocks (e.g. data model, network, service model). 

Facts 

e
c
i
v
d
A
C
w
P

Findings from peer-developments showed the common practice to manage 
key  elements  of  an  information  sharing  environment  as  products.  This 
approach  includes  activities  such  as  strategic  planning,  release  planning, 
requirement management, user involvement, support and marketing.  

In  particular,  the  following  aspects  emerged  from  MISE,  SeaVision  and 
SESAR: 

• 

In  the  context  of  MISE,  the  architecture  was  developed  and 
managed  by  a  single  entity  acting  as  “product  owner”  [M.V.3, 
M.G.3].  Also,  MISE  data  model  exists  as  a  separate  initiative 
(NIEM)  having  its  own  strategy,  governance,  management  and 
communication activities [M.V.4, M.G.5, M.G.6]. 

•  SeaVision  embeds  several  product  management  ideas,  including 
both  a  formal  and  an  agile  requirement  management  processes 
[SV.G.2]. 

•  SWIM  data  model  (AIRM)  and  the  network  layer  (PENS)  are 
managed  as  a  product  with  its  own  specific  strategy,  governance 
processes, and management [SW.A.15, SW.A.13].    

CISE’s current development could benefit from consolidating efforts on 
several components and from marketing them as products. (e.g. the CISE 
data model is a candidate element for “productization”) 

During the operational phase, productized components would have a 
dedicated evolution and maintenance activities. 

A product-driven approach might also help to strengthen the value 
proposition of CISE as a whole and contribute to its long-term 
sustainability. To be most effective, activities should be aligned to a 
common plan and evolve in a coordinated way. 

Supporting 
findings 

MISE: M.V.3, M.G.3, M.V.4, M.G.5, M.G.6 

SeaVision: SV.G.2 

SESAR: SW.A.13, SW.A.15 

21/06/2018 

Page 37 of 83 

 
 
 
 
 
 
 
 
 
4.2  Overall architecture and design 

Before diving into the details on architecture, some contextual remarks can help 
put the information in context. 

•  Some of the lessons learned might be difficult to apply to CISE in the short 
term, as its architecture and building blocks are already defined and are 
undergoing validation. 

•  MISE and SESAR’s SWIM are not yet fully operational, therefore several 

topics are still being defined, so it is advisable to follow-up on them closely 
to gather additional insight in the future. 

•  The network layer of SESAR SWIM was not analysed in detail as it is a 

separate initiative. It is however mentioned for the sake of completeness. 

6 – To better manage complexity and communicate functional and 
technical aspects, peer-developments apply an Enterprise Architecture 
approach. 

Facts 

e
c
i
v
d
A
C
w
P

The  study  found  a  common  approach  to  document  architecture  according 
to  views,  which  is  considered  a  good  practice,  commonly  found  in 
Enterprise  Architecture 
to  communicate 
complexity. In particular: 

frameworks, 

that  helps 

•  MISE  architecture  consists  of:  Data  Architecture  View,  Services 
Architecture  View,  Security  Architecture  View,  and  Technical 
Operations Architecture View [M.A.3]. 

•  SESAR  SWIM  architecture  consists  of:  Functional  View,  Technical 

View, Deployment View [SW.A.4]. 

Restructuring the documentation of CISE’s architecture and components 
helps to understand and manage complexity during implementation and 
prevents ambiguity. This would positively impact the overall value 
proposition of CISE. The European Interoperability Reference Architecture 
(EIRA)17 can be the starting point for documentation. 

During the operational phase, maintenance of structured documentation 
would be the point of reference for new joiners and all stakeholders 
facilitating their integration efforts. 

In the long-term, PwC experience shows that leveraging Enterprise 
Architecture frameworks helps to better understand, communicate and 
manage the different building blocks and their dependencies. Enterprise 
Architecture helps to manage the complexity of a cross-border information 
sharing environment. 

Supporting 
findings 

MISE: M.A.3 

SESAR: SW.A.4 

17 See: https://ec.europa.eu/isa2/solutions/eira_en  

21/06/2018 

Page 38 of 83 

 
 
 
 
 
 
 
 
 
                                                 
 
7  –  To  better  manage  services  and  foster  organisational  interoperability, 
peer-developments  implement  a  standard  service  reference  model  and 
service registry. 

Facts 

e
c
i
v
d
A
C
w
P

SESAR  Information  Service  Reference  Model  (ISRM)  and  SWIM  Registry 
provide  a  good  example  on  how  a  standard  service  model  and  a  service 
registry  can  help  foster  organisational  interoperability  and  situational 
awareness in SOA context.  

The  ISRM  describes  how to  document  functionality,  behaviour and  logical 
interfaces  of  services.  Its  core  document  the  ISRM  Foundation  Rulebook 
describes  a  set  of  standard  rules  that  should  be  followed  to  produce 
SWIM-compliant  descriptions  of  services  [SW.A.18,  SW.A.19,  SW.A.20, 
SW.A.21]. 

The  SWIM  Registry  will  evolve  from  a  databased  used  at  “design-time”, 
containing  mostly  specifications  in  unstructured  format,  to  a  “run-time” 
registry hosting machine-readable metadata, which will allow the dynamic 
discovery  of  services,  their  policy  and  the  monitoring  of  status  [SW.A.8, 
SW.A.9]. 

For the current development of CISE, the insight gathered from SESAR 
can be useful for structuring the service registry and for defining services. 
CISE can also leverage ITIL, a good practice in IT service management, 
and ISA2 Catalogue of Services18  

Having a service reference model and service registry in place us essential 
to the operational phase of CISE, therefore they should be set up as soon 
as possible. 

As above. 

Supporting 
findings 

SESAR: SW.A.8, SW.A.9, SW.A.18, SW.A.19, SW.A.20, SW.A.21 

18 See:  

21/06/2018 

Page 39 of 83 

 
 
 
 
 
 
 
 
 
 
 
                                                 
 
8 – To improve semantic interoperability, peer-developments provide clear 
documentation and guidance for the use of their data models. 

Facts 

The  analysis  of  SESAR  and  MISE  showed  the  importance  of  organising  a 
data model so that information exchanges are clearly defined, understood 
and harmonised between stakeholders.  

•  SESAR AIRM can provide a good example on how to structure the 
approach  and  the  documentation  of  a  data  model.  In  particular, 
the  AIRM  Foundation  Rulebook  provides  principles,  rules  and 
recommendations for modellers creating contributions to the AIRM 
or developing and maintaining the AIRM [SW.A.14]. 

• 

In addition, EUROCONTROL’s specifications referencing AIRM show 
how to provide guidance to document semantic correspondence to 
a  data  model  when  stakeholders  draft  new  information  definitions 
[SW.A.17]. 

•  NIEM  and  its  Maritime  extension  provide  a  good  example  of  data 
model used in the maritime domain. Modular approach, availability 
of  tools  and  organisational  support  are  its  key  strengths.  In 
particular,  NIEM  is  structured  as  follows  [M.A.10,  M.A.11,  M.A.12, 
M.A.13, M.A.14, M.A.15]: 

o  NIEM core defines universal objects (e.g. people, locations, 

organisations). 

o  NIEM  extensions  enrich  the  NIEM  core  including  domain 
specific data components (e.g. NIEM Maritime extension) 

o  NIEM-based  models,  external  models  and  custom  models 
can  be  combined  into  local  reusable  dictionaries,  or 
“Enterprise  Information  Exchange  Models”  (EIEM).  In  the 
case  of  MISE,  the  Maritime  Domain  Awareness  EIEM  is 
defined. 

o  Entities  defined  in  the  MDA  EIEM  are  subsequently 
combined  into  several  IEPDs,  which  are  finally  the  unit  of 
information that is published and consumed in the MISE. 

e
c
i
v
d
A
C
w
P

In the context of current development of CISE, the documentation of CISE 
data model could be restructured to follow the applicable lessons learned 
found in this study, e.g. development rulebooks, guidance material. In 
addition, the data model could be managed as a separate initiative, see 
also lesson learned #5. 

During the operational phase, maintenance of structured documentation of 
CISE data model would be the point of reference for existing stakeholders 
and potential new joiners. 

Future evolutions of CISE data model could foresee compatibility or 
mapping with NIEM, to foster international cooperation. 

Supporting 
findings 

MISE: M.A.10, M.A.11, M.A.12, M.A.13, M.A.14, M.A.15 

SESAR: SW.A.14, SW.A.17 

21/06/2018 

Page 40 of 83 

 
 
 
 
 
 
 
 
 
 
 
9 - To optimise implementation efforts, peer-developments group 
infrastructure capabilities into coherent sets (profiles) adapted to 
different user needs. 

Facts 

In SESAR SWIM, the idea of bundling messaging technologies,  protocols, 
security features and performance requirements into coherent sets (i.e. 
the SWIM-TI Profiles [SW.A.2, SW.A.7]) was proven useful for several 
reasons:  

• 

• 

• 

It reduced the implementation burden for stakeholders with limited 
resources, as the low-end SWIM-TI Yellow Profile relies on widely 
adopted standards and the public Internet. 

It enabled a gradual deployment approach, as the lower-end 
profiles can be deployed first, while the most advanced ones are 
kept for later phases. 

It addresses the needs of the military, as a dedicated SWIM-TI 
Profile tailored was equipped with enhanced reliability, security and 
dedicated network infrastructure. 

In EUCISE 2020, some kind of profiling was already put in place with the 
three different types of Nodes (A, B and C) depending on the features and 
capacity of the participant. Therefore, CISE could further explore the idea 
of having of a modular approach to technical specification of protocol 
stacks and quality of services (e.g. highly-secured nodes vs low-secured)  

A modular approach of technical specifications can lower CISE’s barrier to 
implementation, as it would appeal also to stakeholders with limited 
resources.  

 - 

e
c
i
v
d
A
C
w
P

Supporting 
findings 

SESAR: SW.A.2, SW.A.7 

10 – To ensure secure cross-border information exchange, peer-
developments are developing information security frameworks based on 
established security standards. 

Facts 

The main challenge of Identity and Access Management in the context of 
cross-border information sharing environments is to put in place a 
federated architecture jointly governed by different stakeholders while 
having minimal impact on the infrastructures of participants. 

This study discovered: 

•  A dual federated approach in SWIM made of: 

o  A Public Key Infrastructure responsible for signing, 

emitting and maintaining X.509 certificates and revocation 
lists [SW.A.10], with a bridge certificate authority. 

o  A Security Token Infrastructure providing capabilities to 
manage security tokens and Identity stores [SW.A.10] 

•  A centralised approach in MISE where the list of trusted systems is 

maintained by a single body [M.G.10]. 

21/06/2018 

Page 41 of 83 

 
 
 
 
 
 
 
 
 
•  Attribute-based access control pattern for authorisation, which 
was found in SWIM, MISE [M.G.10] and SeaVision [SV.G.4]. 

The study found that a comprehensive information security framework for 
a cross-border environment based on a federated approach is still under 
development, within SESAR [SW.G.8, SW.G.9]. 

CISE should leverage the findings on SESAR, MISE and SeaVision to 
develop its own federated security framework. Discussions on CISE 
governance should also include this aspect. In addition, CISE could 
leverage existing Commission platforms and initiatives such as TESTA NG 
and CEF eDelivery building block. 

A comprehensive information security framework should be put in place to 
ensure information security is properly handled during the operational 
phase. 

A solid and harmonised information security framework across different 
jurisdictions can provide sustained engagement and buy-in from 
stakeholders in the long-term. 

e
c
i
v
d
A
C
w
P

Supporting 
findings 

MISE: M.G.10, M.G.11 

SeaVision: SV.G.4 

SESAR: SW.A.10, SW.G.8, SW.G.9 

21/06/2018 

Page 42 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
4.3  Governance and organisation structure 

11 – To facilitate suitable governance of strategic, operational and 
technical layers, peer-developments set up a tailored structure with 
dedicated governance bodies. 

Facts 

The study highlighted several examples applicable to the operational 
governance of an information sharing environment.  

In particular, the governance structure foreseen in MISE consists of a MISE 
Board of Directors, a MISE Management group, and the MISE Change 
Control Board hosting representatives from various data providers and 
consumers [M.G.1]. At strategic level, MISE governance is supported by 
the Maritime Domain Awareness (MDA) Information Enterprise Hubs, 
acting as the lead coordinator for data sharing in specific areas (vessel, 
people, cargo, infrastructure) [M.G.2]. 

Research on SeaVision showed the need of incorporating user feedback in 
an agile way if conventional processes are too rigid [SV.G.2]. 

Another example is SWIM’s approach to governance, which is composed 
of. 

•  Essential requirements; Governance Groups (Steering Group, 
Expert Group, Management Group, and User groups) and 
Information Management (IM) functions, 

•  Mapping between IM functions and governance groups.  

• 

Interactions between IM functions and the governance structure, 
which are documented as use cases and governance processes 
[SW.G.3].  

At the time of writing, however, several concepts of SWIM governance 
(e.g. Terms of reference, policies) are still under definition [SW.G.4] and 
the actual governance structure is not yet operational. 

The study highlighted that both in MISE and SESAR dedicated bodies are 
responsible for the governance of data models. In the context of MISE, the 
NIEM data model is an entirely separate initiative with working agreements 
with MISE governance [M.G.5, M.G.6]. In SESAR Programme, the AIRM is 
managed as a product with a dedicated governance [SW.A.14]. 

The elements outlined above can serve as source of inspiration for defining 
CISE governance. PwC experience shows that an iterative approach works 
bests: starting first with key governance principles and constraints, 
followed by a rough outline of the governance structure, then getting 
agreement and detailing functions, roles and responsibilities by iterative 
refinement. CISE could leverage COBIT19, an industry good practice for IT 
governance. If regulatory support for CISE is foreseen, governance should 
be clearly mentioned as a key element to be put in place (see also lesson 
learned #2). 

e
c
i
v
d
A
C
w
P

19 See: http://www.isaca.org/cobit/pages/default.aspx  

21/06/2018 

Page 43 of 83 

 
 
 
 
 
 
 
                                                 
 
Governance is essential for CISE operational phase, therefore CISE should 
clarify and implement the needed governance structures as soon as 
possible (see also lesson learned #12) 

CISE should periodically review its governance structure, functions, roles 
and responsibilities, processes to ensure an efficient and effective 
governance. 

Supporting 
findings 

MISE: M.G.1, M.G.2, M.G.5, M.G.6 

SeaVision: SV.G.2 

SESAR: SW.A.14, SW.G.3, SW.G.4 

12 – To speed-up implementation and coordinate efforts of stakeholders, 
peer-developments aim to establish a governance structure as early as 
possible. 

Facts 

Several findings indicate that delay in the establishment of governance at 
operational level is a major blocking factor for deployment activities of an 
information sharing environment. 

As indicated in the SESAR Deployment Programme, the delay of 
establishment of SWIM governance was recognised as one blocking factor 
for the full implementation of SWIM that could potentially affect 
deployment at European scale [SW.G.5]. A specific action plan was 
established to avoid this risk [SW.V.5]. 

Lack of operational governance, would have impact on the establishment 
of information security framework, service level governance, and 
standardisation activities, as seen in SESAR [SW.G.10, SW.V.17, SW.G.6]. 

In the context of CISE current developments, establishing an operational 
governance structure as early as possible can speed-up uptake and 
implementation activities.  

Not applicable 

Not applicable  

e
c
i
v
d
A
C
w
P

Supporting 
findings 

SESAR: SW.V.5, SW.V.17, SW.G.5, SW.G.6, SW.G.10 

13 – To have a smooth collaboration between R&D activities and 
implementation, peer-developments establish an "innovation pipeline" 
between dedicated governance bodies. 

21/06/2018 

Page 44 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
Facts 

e
c
i
v
d
A
C
w
P

The study found an example of governance structure that enables the 
smooth coordination of R&D with implementation and deployment 
activities. In the context of SESAR, the SESAR Deployment Manager 
(SDM) is a dedicated body that was established to coordinate deployment 
efforts of SWIM (and SESAR solutions in general) among stakeholders 
[SW.V.3b]. 

SESAR Joint Undertaking (SJU) and SDM established an “innovation 
pipeline” in which solutions are researched by SJU members and are 
deployed in a coordinated way by SDM and implementation partners 
[SW.V.4]. 

In this framework, the Joint Undertaking maintains the overall Master 
Plan, i.e. the high-level roadmap of the programme, while the Deployment 
Manager maintains the SESAR Deployment Programme, which focuses on 
synchronising the implementation of mature solutions. In addition, SESAR 
DM acts as the gateway between stakeholders and European funding for 
implementation [SW.G.2] 

If the option of having ad-hoc actors for CISE implementation is deemed 
viable, CISE should leverage SESAR experience with the role of the 
Deployment Manager and its responsibilities.  

See above. 

See above. 

Supporting 
findings 

SESAR: SW.V.3b, SW.G.2, SW.V.4 

14 – To enable exchange of information, peer-developments develop 
frameworks of agreements (SLA, MoUs, etc.) 

Facts 

C
w
P

e
c
i
v
d
A

This study discovered several ideas on service level agreements and their 
governance, however at the time of writing, the found elements are still 
at embryonal stage and are subject to further refinement. A 
comprehensive cross-border framework for SLAs is yet to be put in place. 

In MISE several ideas are provided on SLAs and on the main terms for 
executing service agreements [M.G.9]. Some topics are, for example: 
responsibilities of consumers and providers, reporting, performance levels 
guidelines, uptime requirements, redistribution policy. MISE Management 
body is responsible of IT Service Management and SLAs [M.G.7, M.G.8]. 

In SESAR SWIM, the Performance management functions of the SWIM 
Registry monitoring SLAs and reporting, however no guidelines are 
provided yet on how to structure the agreements. In principle, providing 
SLA guidelines and standards is under the responsibility of SWIM 
governance, but no detailed information has been found [SW.G.6, 
SW.G.7]. 

As part of the governance responsibilities, having a SLA framework in 
place early can help to foster buy-in and adoption. CISE should leverage 
the preliminary work of peer-developments to accelerate the 
development of its SLA management framework. Transitional agreement 
frameworks could be established for the development and implementation 
phase to speed-up user uptake, while their refinement could be foreseen 

21/06/2018 

Page 45 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
for later stages. 

Once in place, CISE should actively manage its frameworks of 
agreements by foreseeing specific activities, roles and responsibilities 
within its governance structure. 

As above. 

Supporting 
findings 

MISE: M.G.7, M.G.8, M.G.9 

SESAR: SW.G.6, SW.G.7 

15 – To leverage industry expertise during R&D, peer-developments 
establish public-private-partnerships.  

Facts 

The study highlights that the role of a public-private partnership, under 
the form of SESAR Joint Undertaking, has been evaluated positively. SJU is 
responsible for coordinating and concentrating efforts at European level to 
lead R&D activities in the modernisation of the ATM sector [SW.V.1, 
SW.G.1] 

In that context, SJU members from the private sector benefit from 
enhanced competitive advantage as they would be ready to sell 
SESAR/SWIM-compliant solutions earlier than competitors [SW.V.12] 

In case CISE chooses to leverage a public-private partnership for future 
R&D activities, CISE could leverage the experience of SESAR Joint 
Undertaking. 

Not applicable. 

Not applicable. 

e
c
i
v
d
A
C
w
P

Supporting 
findings 

SESAR: SW.V.1, SW.V.12, SW.G.1 

21/06/2018 

Page 46 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
5  CONCLUSION 

This  study  concludes  that  none  of  the  identified  peer-development  has  the  same 
key  characteristics  as  CISE.  However,  their  similarities  per  area  of  study  allowed 
this research work to identify 15 applicable lessons learned and good practices that 
can help CISE overcome its challenges.  

In addition, the study identified some industry best practices related to each lesson 
learned  that  can  help  CISE  during  the  different  stages  of  CISE’s  evolution:  the 
current development, the operational phase and the long-term sustainability.  

The  study  advises  to  take  these  lessons  learned  and  good  practices  into  account 
during  the  future  evolution  of  CISE.  The  research  work,  especially  its  lessons 
learned  and  good  practices,  also  serves  as  input  for  a  more  holistic  analysis  of 
CISE. 

21/06/2018 

Page 47 of 83 

 
 
 
Annex I  STUDY METHODOLOGY 

This annex provides more details on the methodology applied to this study. For the 
interested reader, the deliverable D1.2 - Detailed Methodology - Final contains 
the full details. 

The study methodology consisted of 3 phases: 

1.  The scoping phase;  

2.  The data collection phase; and  

3.  The analysis phase. 

These  phases  consists  of  several  steps,  according  to  the  following  picture  and 
explained afterwards. 

Scoping phase 

1.  Set the analysis objective and approach 

•  The  objective  of  this  study  is  to  analyse  the  Maritime  Information 
Sharing  Environment  (MISE)  in  the  U.S.  and  two  similar  peer-
developments around the world. 

•  The  analysis  aims  at  identifying  lessons  learned  and  good  practices 

that could be useful for CISE. 

2.  Determine a framework for analysis and evaluation 

The proposed framework focuses on three areas: 

•  Vision and applied development strategy; 

•  Governance and organisation structure; and 

•  Technical architecture and design. 

Interoperability,  being  a  cross-domain  topic,  is  investigated  under  all  three 
areas. 

For each area, a detailed list of relevant aspects was developed to guide the 
research and to drive the interviews with representatives. 

3.  Identify and select similar projects (in addition to MISE) 

To identify the peer-developments to be compared with CISE, the following 
information sources were used: 

• 

Inputs received from the European Commission; 

•  Desk research; 

•  PwC’s network of experts. 

As  result,  a  first  long-list  of  10  peer-developments  shown  below  was 
identified: 

21/06/2018 

Page 48 of 83 

 
 
 
•  Australia-Japan-US maritime cooperation20 

•  The  Northeast  Asia  Logistics  Information  Service  Network  (NEAL-

NET)21 

•  The Piracy Reporting Centre (PRC) based in Malaysia22 

•  The Maritime Safety and Security Information System (MSSIS)23 

•  The Information Sharing Centre (ISC) based in Singapore24 

•  NATO’s Maritime Surveillance System25 

•  The Information Fusion Centre (IFC) based in Singapore26 

•  The West Africa Police Information System (WAPIS) Programme27 

•  The ECCAS Maritime Security Strategy28   

•  Single European Sky ATM Research (SESAR) Programme29 

The candidate peer-developments were evaluated on the following criteria in 
order to assess their relevance of this study. 

•  Number of countries involved, 

•  Architectural approach of the technical infrastructure and use cases 

•  Regulatory support 

• 

• 

• 

Information domains 

Information services 

Information confidentiality 

•  Standardisation activities 

•  Availability of contact point 

From the long-list, four peer-developments were selected according to their 
selection  criteria  and  resulting  relevance  to  the  purpose  of  the  study. 
Subsequently,  the  short-listed  peer-development  were  evaluated  in  more 
detail highlighting the pros and cons of further analysis. Finally, each peer-

20 See: https://spfusa.org/event/21st-century-trilateral-maritime-cooperation/ 
21 See: http://www.nealnet.org 
22 See:  
- 
- 

https://www.icc-ccs.org/piracy-reporting-centre  
https://bookshop.iseas.edu.sg/account/downloads/get/18222 

23 See: https://mssis.volpe.dot.gov/Main/ 
24 See: http://www.recaap.org  
25 See: http://www.cmre.nato.int/research/maritime-situational-awareness  
26 See:  
- 
- 
27 See:  
- 
- 

https://www.sesarju.eu/  
http://www.sesardeploymentmanager.eu/  

http://www.infofusioncentre.gov.sg  
http://bueger.info/a-role-model-for-information-sharing-visiting-the-singapore-ifc/ 

28 See: http://www.consilium.europa.eu/en/meetings/fac/2015/03/st07168_en15_pdf/ 
29 See: https://www.interpol.int/es/content/download/18670/166659/version/ 

15/file/Brochure%20WAPIS%20EN_2016%2007_2_LR.pdf  

21/06/2018 

Page 49 of 83 

 
 
 
                                                 
 
 
development  was  evaluated  for  its  estimated  relevance  to  each  area  of 
study. 

As  result,  the  Information  Fusion  Centre  of  Singapore  and  SESAR 
Programme were selected for further study, in addition to MISE. 

Data collection phase 

4.  Perform a brief survey of the current status of CISE. 

In  order  to  establish  a  comparison  baseline  and  validate  the  approach,  the 
analysis framework was briefly applied to CISE. 

5.  Collect information on the shortlisted projects following the analysis 

framework. 

The  following  steps  were  taken  to  collect  information  on  the  shortlisted 
projects: 

a.  Establish contact 

b.  Collect publicly available information 

c.  Organise preparatory call 

d.  Collect data interactively 

e.  Conduct  face-to-face  workshops  or  conference  calls  to  clarify 

questions. 

Analysis phase 

6.  Elicit lessons learned, good practices, and recommendations 

In  this  activity  the  information  collected  for  the  peer-developments  was 
consolidated,  analysed,  cross-related  and  reported.  The  lessons  learned, 
good practices and recommendations were organised around the three areas 
of the framework for analysis and evaluation. 

21/06/2018 

Page 50 of 83 

 
 
 
Annex II  MAIN CHARACTERISTICS OF CISE 

This  annex  briefly  introduces  the  CISE  initiative  with  the  help  of  a  high-level 
diagram and lists the key findings. 

Table 14: Introduction to CISE 

Idea behind CISE 
Maritime CISE is a voluntary collaborative 
process seeking to achieve a political, 
organisational, technical and legal 
environment enabling cross-border and cross-
sector information sharing between authorities 
involved in maritime surveillance. 
Key Milestones 

Vision and development strategy 
Status 
CISE technical elements are 
being refined and tested at 
EU level (EUCISE2020) and  
MS level (10 
interoperability projects) 

What’s next 
  EUCISE2020 expected end 

is mid-2018. 

  Work is in ongoing on: 
−  Transition strategy to 

operations 

−  Longer-term strategy 

Overall architecture and design 

  Service-oriented architecture of a highly distributed network of 

nodes/gateways connecting legacy systems (providers and consumers). 

  Nodes implement CISE services (e.g. messaging, discovery, user 
management, advanced and innovative services) and data model. 
  Shared functions are federated so to avoid centralised components. 

Governance and organisation 

Current Governance model: 
  Governing level: EP and Council. 
  Steering level: the Member State Expert sub-Group (MSEsG) and the 

technical advisory group (TAG). 

  Directing level: EC. 
  Managing level: EC and MS authorities through IOP projects. 
The governance to cover the transition and operational phases of CISE is 
currently under discussion. 

The  following  table  contains  the  key  findings  on  CISE  supporting  the  derived 
recommendations. 

21/06/2018 

Page 51 of 83 

 
 
 
 
 
 
 
 
 
 
Table 15: Key findings of CISE analysis 

Vision and development strategy 

Main evolution milestones 

C.V.1  Due  to  extensive  consultations,  technical  pilot  projects  and  policy 
research efforts, it took 5 years from the initial conception of a maritime 
information  sharing  environment  (2009)  to  establish  a  large-scale 
implementation  which  analyses  the  benefits  of  the  CISE  in  practical 
terms,  i.e  EUCISE2020  (end  2014).  The  launch  of  EUCISE2020  can  be 
seen  as  a  turning  point  in  the  development  of  CISE  towards  delivering 
tangible results/benefits to Member States. 

Vision, guiding principles, value proposition 

C.V.2   A  formally  agreed  “vision  statement”  of  CISE  is  not  found  in  public 
documents  as  such.  However  many  hints  on  the  purpose  of  CISE  and 
goals have been continuously refined and fine-tuned since its inception. 

C.V.3 

C.V.4 

C.V.5 

C.V.6 

C.V.7 

The value proposition - “added value of integrating maritime surveillance” 
found  in  the  Commission’s  draft  roadmap  from  2010  is  formulated  in 
high-level and broad terms. 

Information  on  CISE  is  spread  across  many  policy  and  technical 
documents.  A  single  core  publication,  which  links  the  different  existing 
documents together and is kept up-to-date as the CISE takes form, is not 
yet  available.  A  short  reading  guide  to  understand  where  to  find  which 
information  is  missing,  e.g.  with  regards  to  history,  status,  costs  and 
benefits. 

So  far,  the  CISE  handbook  (which  could  include  the  abovementioned 
information) has not yet been published. 

The focus of EUCISE2020 has been so far on the design, develop and test 
solutions  of  different  software  components,  the  most  relevant  one  being 
the CISE Gateway and Node.  

The  approach  of  how  to  get  CISE  operational  (e.g.  big-bang  vs.  phased 
approach,  by  sea-basin,  use  case  or  user-community)  was  out  of  the 
scope  of  the  research  projects  conducted  so  far.  The  long-term 
development strategy of CISE has not been formally agreed yet. 

Political and regulatory support 

C.V.8 

C.V.9 

Being  based  on  a  voluntary  effort,  as  a  consequence,  CISE  needs  to 
stress  its  added  value  to  Member  States  and  authorities  participating  in 
Maritime Surveillance to ensure buy-in. 

The  viability  of  industrial  standardisation  of  certain  CISE  components  is 
being explored as CISE has been included in the European Commission’s 
2017 Rolling Plan for ICT standardisation. 

C.V.10  Given  its  interoperability  specificity,  one  option  for  CISE  is  to  become  a 
Digital Service Infrastructure embedded into the Digital Single Market by 
implementing  relevant  Connecting  Europe  Facility  –  Telecom  (CEF-T) 
building blocks. However, these long-term technology strategy aspects of 
CISE have not been formally agreed yet. 

21/06/2018 

Page 52 of 83 

 
 
 
Solution architecture approach 

Architecture 

C.A.1  Only four out of the nine use cases identified by the Cooperation Project 
(CoopP) were refined to a sufficient level of detail to highlight the use of 
CISE’s Common Services. No explicit mapping was found between the use 
cases  and  the  broader  spectrum  of  CISE's  services  (Core  and  Advanced 
services). 

C.A.2 

Information  on  CISE’s  business  and  technical  requirements,  uses  cases, 
architecture,  data  model  and  technical  implementation  was  developed  in 
the course of several projects (MARSUNO, BluMassMed, CoopP, Incubator, 
EUCISE  2020)  and  is  found  in  their  deliverables.  A  central  document  is 
not yet available which introduces the CISE's technical aspects, links the 
different  existing  technical  sources  and  specifications  together,  and  is 
kept up-to-date as the CISE evolves. As mentioned also in Section 2.3 of 
D.2.5.2 - Structured report on CISE, the role of this central artefact would 
be covered by the CISE Handbook, which is not yet available at the time 
of writing. 

Main architectural building blocks 

C.A.3 

C.A.4 

CISE’s  query-by-example  mechanism  allows  consumers  to  request  data 
entities that are similar to a given example, within some constraints. 

The implementation choices aim at providing a highly available distributed 
system 
federated  and  CISE 
Gateways/Nodes  play  a 
role.  Particularly,  each  CISE 
Gateway/Node provides the following features30: 

in  which  shared  components  are 

central 

o  A  local  Service  Registry  that  contains  information  about  the 
services  provided  by  the  local  Adaptors  connected  to  the 
Gateway/Node.  

o  A local Authority Registry, which contains information on the 
participating user and is automatically distributed across 
participants. 

o  A local Certificate Authority (CA). Only one CA shall be set up for 

each Member State. 

C.A.5 

In other words, no centralised building blocks are foreseen to support 
network discovery, identification, authentication and access control. The 
mechanisms rely only on multicast protocols and manual configuration in 
limited cases (e.g. Certificate Authorities). As a consequence, each 
Member State Authority retains its responsibility for its own Legacy 
Systems, users and provided information. 

30 According to our interviewees, this will be one of the lessons learnt from the EUCISE2020 project: 

“The authority/service registry and the CA should be distributed in the same way as the gateway/node. 
In practical terms, they should be deployed in the same facilities/server or they should be components 
of the gateway.” 

21/06/2018 

Page 53 of 83 

 
 
 
                                                 
 
C.A.6  Network topology is still under evaluation. The two alternatives are a full-

mesh topology vs. a hub-and-spoke approach.  

Data model 

C.A.7 

C.A.8 

The data model leverages several vocabularies from different data 
standards e.g. ANSI, IALA, EMSA, IMO, ISO, ITU, OASIS, the U.S. Coast 
Guard, UN, and W3C. 
The data model contains the several data entities: 

•  Vessel 
•  Operational assets 
•  Cargo 
•  Movement 
•  Location 
•  Action 
• 
Incident 
•  Anomaly 
•  Risk 
•  Person 
•  Organization 
•  Document. 

C.A.9 

The data model can handle data classified as EU CONFIDENTIAL. 

Service model 

C.A.10  CISE  not  only  provides  messaging  services  but  also  envisions  more 

enhanced services such as fusion, simulation and collaboration services. 

Strategic and operational governance (incl. SLAs) 

Governance   

C.G.1 

A  formal  governance  model  and  organigram  of  roles  and  responsibilities 
of  CISE  actors  is  missing.  Information  is  scattered  across  several  public 
documents. 

C.G.2 

The  organigram  for  EUCISE2020  is  available  as  part  of  an  introductory 
slide deck but more detailed documents are not publicly available. 

C.G.3 

The  responsibilities  of  the  different  roles  of  EUCISE2020  are  publicly  not 
available. 

C.G.4 

At  the  time  of  writing,  the  longer-term  governance  and  management 
structures  of  the  CISE  once  in  operations  are  still  undefined.  No 
information was found on potential options. 

C.G.5 

The  way  IT  services  and  corresponding  SLAs  are  managed  during  the 
operations is currently under discussion. 

IT service Management and Information Security 

C.G.6  The  management  of  CISE’s  IT  services  and  SLAs  needs  to  take  into 
account CISE’s nature of being a hybrid and fully distributed infrastructure 
with different stakeholders (i.e. countries and agencies) and services. 

C.G.7  CISE (i.e.  the  environment  itself  and  its  management) needs  to  facilitate 

the handling of data classified as EU CONFIDENTIAL. 

21/06/2018 

Page 54 of 83 

 
 
 
C.G.8  The  CISE’s  governance  and  management  of  data  protection  and 

information security during operations are currently under discussion. 

21/06/2018 

Page 55 of 83 

 
 
 
 
 
 
 
 
Annex III  DETAILED ANALYSIS OF MISE AND SEAVISION IN THE USA 

This  annex  briefly  introduces  the  MISE  and  SeaVision  initiative  with  the  help  of  a 
high-level  diagram  and 
the  derived 
recommendations.  The  report  containing  the  detailed  analysis  of  the  MISE  and 
SeaVision  initiatives  can  be  found  in  D2.5.2  -  Structured  report  on  MISE  and 
SeaVision. 

findings  supporting 

the  key 

lists 

Table 16: Introduction to MISE 

Vision and development strategy 

Idea behind MISE 

The MISE enables secure, standardized sharing of 
unclassified maritime information among a wide 
variety of federal, state and local agencies as well as 
international participants.  
MISE uses standard technology and existing 
capabilities in order to have lowest possible threshold 
of entry 

Key Milestones 

Status 
MISE’s architecture plan 
has been approved up to 
National Security Council. 
The implementation of 
MISE at full scale has 
not started yet. 
SeaVision piloting data 
mgmt. features 
What’s next 
  The MISE will probably 
be an interoperable 
environment rather 
than a single 
centralised system. 

Overall architecture and design 
  Architecture based on a centralised Information Sharing Infrastructure 

(ISI) system that exposes RESTful web services: 

  Providers may either publish data to the ISI cache periodically, or reply to 

requests from the ISI synchronously. 

  Consumers always query the ISI, which then routes the requests. 
  Data model, NIEM-Maritime, is based on NIEM (separate initiative). 

Governance and organisation 
  Governance bodies: BOD, MISE Management, Configuration Control Board 

(CCB). 

  Governance processes (briefly outlined): Request to Join, Help desk 

process, CCB process, On-boarding. 

  The operational governance is not yet in place. 

The  following  table  contains  the  key  findings  on  MISE  supporting  the  derived 
lessons learned. The last column indicates with symbol [✓] if the finding has been 
used to derive the recommendations in chapter 4.   

Table 17: Key findings of MISE analysis 

Vision and development strategy 

Main evolution milestones 

21/06/2018 

Page 56 of 83 

 
 
 
 
 
 
 
 
 
 
 
M.V.1 

M.V.2 

M.V.3 

M.V.4 

Initially,  the  main  driver  of  MDA-related  policies  was  the  response 
to 9/11 terrorist attacks, with the military (US Navy) mostly in the 
lead. 

The  scope  of  the  MDA  Concept  of  Operations  (CONOPS)  was  more 
far reaching than what proposed in the MDA Architecture Plan in the 
MISE.  The  MDA  CONOPS  envisaged  essentially  a  set  of  features 
enabling  content  discovery  and  delivery,  collaboration  and  portal 
services, all relying on a services-oriented architectural foundation. 
On  the  other  hand,  the  National  MDA  Architecture  Plan  and  MISE 
only seem to address the latter aspect. 

A  structured  and  centralised  approach  to  develop  the  architecture 
was  adopted  by  the  Architecture  Management  Hub.  The  DoD 
Department  of  the  Navy  Chief  Information  Office  (DoN  CIO)  was 
designated as lead agency for the hub. 

Instead  of  developing  an  entire  data  model  from  scratch,  the  MDA 
Architecture Hub Plan envisaged to leverage the existing successful 
efforts,  i.e.  the  NIEM  initiative  and  its  dedicated  maritime  domain 
extension. 

✓ 

✓ 

M.V.5 

The first evaluation of the MDA Architecture Plan and the MISE was 
in a military exercise with few international U.S. partners, while the 
first operational implementation was in the port of Baltimore. 

M.V.6  No information has been found on demonstrations, pilot projects or 
pre-operation  validations  conducted  at  a  large  scale,  for  instance 
among all US coastal States. 

M.V.7  Overall, the available documentation reviewed indicates that a top-
down  approach  was  followed,  in  which,  after  the  initial  policy  push 
at strategic level, work was carried on mostly by the U.S. Navy with 
no clear involvement of stakeholders at state and local level. 

M.V.8 

The MISE is not yet operational and its governance structure is not 
yet in place. 

M.V.9 

Besides  the  idea  of  adopting  “common  standards  for  common 
understanding”  the  concept  of  having  the  MISE  implemented  as  a 
single  system  seems  to  be  put  on  hold  in  favour  of  having  an 
interoperable ecosystem where mission-specific systems are able to 
communicate with each-other. 

Vision, guiding principles, value proposition 

M.V.10  The  overall  vision  of  the  United  States  regarding  MDA  “points 
toward  a  future  in  which  information  supports  national  security 
decision making by providing the right information, at any time, to 
authorized  users,  restricted  only  by  law  or  policy,  not  technology: 
and  where  safeguarding  measures,  to  include  a  comprehensive 
regimen of accountability, prevent the misuse of the information.” 

M.V.11  MISE’s mission can then be defined as to establish a “national-level 
MDA  enterprise  architecture  to  include:  Enterprise,  web-centric, 
cloud-based,  information  and  services;  common  data  standards; 
and data access policy” in the unclassified domain. 

21/06/2018 

Page 57 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
M.V.12  MISE’s  value  proposition  to  the  maritime  community  regards:  user 
interoperability,  cost-effectiveness,  privacy,  and 

convenience, 
security. 

M.V.13  MISE’s  user  convenience  and  cost-effectiveness  are  particularly 
includes 
communicated  by  a  wealth  documentation 
implementation  guides  and  code  samples.  These  online  guides  are 
addressed  to  system  integrators  and  administrators  who  want  to 
join  the  environment.  However,  documentation  on  the  inner 
working of the sharing environment are not available. 

that 

Countries involved 

M.V.14  Target:  the  MISE  was  originally  foreseen  for  use  within  the  United 

States and with possible use by international partners.  

M.V.15  Actual: none, as MISE is not operational. 

Sectors (user communities) 

M.V.16  The  sectors  or  user  communities  are  not  formally  listed  in  any 
reviewed source. Maritime domain stakeholders are identified in the 
MDA  CONOPS  under  the  term  “Global  Maritime  Community  of 
Interest” which is defined as follows. “GMCOI includes, among other 
interests,  the  federal,  state,  local  and  tribal  departments  and 
agencies  with  responsibilities  in  the  maritime  domain.  Because 
certain  risks  and  interests  are  common  to  government,  business, 
and  citizen  alike,  community  membership  also  includes  public, 
private  and  commercial  stakeholders,  as  well  as 
foreign 
governments and international stakeholders.” 

M.V.17  The  CONOPS  states  to  be  applicable  to  federal  agencies  within  the 

GMCOI. 

Political and regulatory support 

M.V.18  The  National  MDA  Architecture  Plan  describing  the  MISE  was 
approved by the agencies taking part in the MDA Executive Steering 
(Department  of  Defence,  Homeland  Security, 
Committee 
Transportation and Intelligence Community). 

M.V.19  The  National  MDA  Architecture  Plan  was  subsequently  approved  at 
the level for the National Security Council by the Maritime Security 
Interagency Policy Committee. 

M.V.20  Adoption of the Architecture Plan and the MISE remains completely 

voluntary. 

M.V.21  NIEM was endorsed by the Office of Management and Budget (OMB) 
as  “the  basis  for  developing  reference  information  exchanges  to 
support  specification  and 
implementation  of  reusable  cross-
boundary  services”.  Later,  the  Department  of  Defence  adopted 
NIEM  “as  the  best  suited  option 
for  standards-based  data 
exchanges”. 

✓ 

✓ 

✓ 

✓ 

✓ 

Solution architecture approach 

Architecture 

21/06/2018 

Page 58 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
M.A.1 

first  explained 

In the reviewed documentation, the requirements of the information 
from  a  business 
sharing  environment  were 
perspective  in  the  MDA  CONOPS.  Then,  the  National  MDA 
Architecture  Plan  lists  of  features  of  the  Information  Sharing 
Infrastructure 
Information 
Management,  Logger  &  Auditing)  and  its  two  technical  use  cases. 
The  relationship  between  the  requirements  in  these  documents  is 
not explicitly mapped, e.g. via a table or via business-oriented use 
case that could better link business and technical requirements. 

Entitlement  Management, 

(i.e. 

M.A.2 

The MISE consists of a hub-and-spoke architecture where a central 
building block (the Information Sharing Infrastructure) acts as the 
broker between information providers and consumers 

M.A.3 

The architecture of MISE is documented according to several views: 
Data, Services, Security, and Technical Operations view. 

✓ 

Main architectural building blocks 

M.A.4 

The main building blocks of the MISE are: 

o  Trusted  Systems, 

consumers; 

i.e. 

the 

information  providers  and 

o  NIEM-Maritime, which harmonise the data format exchanged 

between Trusted Systems; 

o 

Information  Sharing  Infrastructure  (ISI),  which  acts  as 
broker between Trusted Systems 

M.A.5 

M.A.6 

o  Trust Fabric, which ensures the security of the environment 

The Trust Fabric consists of a set of certificates that are deployed 
manually into the Trusted Systems and their reference is 
maintained by the MISE Management body in the Trust Fabric 
Document. 

Besides its functional requirements, further technical details on how 
the ISI is implemented are not available, therefore it is not clear 
whether the ISI is to be implemented as a single centralised system 
or as a more distributed network.  

M.A.7  No  specific  building  block  is  implemented  to  facilitate  information 
discovery,  e.g.  a  service  inventory  of  the  MISE.  An  IEPD 
clearinghouse  is  hosted  at  Department  of  Justice  (DOJ)  where  the 
definition of the maritime-related IEPDs can be found. However, the 
list of IEPDs available in the MISE is found only in the documents. 

M.A.8 

All 
interactions  between  Trusted  Systems  and  the  ISI  are 
synchronous  and  happen  via  RESTful  web  services  over  standard 
HTTP protocol. 

M.A.9 

A  caching  mechanism  in  the  ISI  decouples  publishers  and 
subscribers. 

Data model 

M.A.10  MISE’s  data  model  is  based  on  NIEM  and  its  maritime  domain 

extension. 

21/06/2018 

✓ 

Page 59 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
M.A.11  NIEM  core  defines  universal  objects  (e.g.  people,  locations, 

organisations). 

M.A.12  NIEM’s  maritime  domains  extend  the  NIEM  core  including  mission 

specific data components. 

M.A.13  NIEM-based  and  custom  entities  are  combined  into  the  reusable 
Maritime Domain Awareness Enterprise Information Exchange Model 
(EIEM). 

M.A.14  Entities  defined  in  the  MDA  EIEM  are  subsequently  combined  into 
several  IEPDs,  which  are  finally  the  unit  of  information  that  is 
published and consumed in the MISE. 

M.A.15  MISE defines the following IEPDs 

o  Vessel position 
o  Notice of arrival 
o 
o  Vessel Information 
o  CVISR 

Indicators and notifications 

Service model 

M.A.16  For  each  IEPD  implemented  in  the MISE,  two services  are  defined: 

search and retrieve.   

M.A.17  The  search  service  returns  a  list  of  records  matching  the  search 

query in RSS format. 

M.A.18  The  retrieve  service  returns  the  NIEM  content  of  the  requested 

record in XML format. 

Governance   

Strategic and operational governance (incl. SLAs) 

M.G.1 

At political level, information sharing efforts in the maritime domain 
between U.S. agencies are overseen by the MDA Stakeholder Board 
with  an  Executive  Steering  Committee  composed  of  agents  from 
Departments  of  Transportation,  Homeland  Security,  Defence  and 
from the Intelligence Community. 

M.G.2  One  level  below,  several  hubs  are  responsible  for  coordinating 
information sharing among the multiple agencies and organizations 
within  each  MDA  information  pillar:  vessels,  cargo,  people  and 
infrastructure. 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

M.G.3 

A  dedicated  enterprise  hub  is  responsible  for  managing  the  MDA 
enterprise architecture. 

✓ 

M.G.4 

At  the  level  of  MISE,  the  governance  structure  consists  of  MISE 
BOD,  MISE  Management,  and  the  MISE  CCB  with  representatives 
from various organizations, both providers and consumers). 

M.G.5  MISE’s  data  model,  NIEM-Maritime,  is  a  separate  initiative  with  a 

dedicated governance structure. 

✓ 

21/06/2018 

Page 60 of 83 

 
 
 
 
 
 
 
 
 
 
M.G.6 

Specific  agreements  between  NIEM  and  the  MDA  ESC  define  roles 
and responsibilities of the NIEM-M governance structure. 

M.G.7  MISE  Management  body  is  responsible  of  IT  Service  Management 

and SLAs. 

M.G.8  MISE  Management  has  the  authority  to  sign  any  service  Level 
Agreements  on  behalf  of  the  MISE.  Any  modifications  to  the 
standard  agreement  or  assignments  of  these  agreements  will 
require the BOD approval. 

M.G.9 

The National MDA Architecture plan touches upon what SLAs should 
define  and  what  should  be  the  main  terms  for  executing  service 
agreements. However these topics are not elaborated in detail. 

IT Service Management and Information security 

M.G.10  Information  security  is  a  responsibility  that  is  shared  among  MISE 

stakeholders. 

✓ 

✓ 

✓ 

✓ 

✓ 

o  MISE  Management  is  responsible  for  setting  up  the  Trust 
Fabric  among  Trusted  Systems  (i.e.  maintaining  the  Trust 
Fabric  Document  and  granting  the  right  attributes  to  the 
systems),  and  assuring  the  ISI  allows  access  to  data 
according to the right permissions.  

o  Trusted  Systems  owners  are  responsible  of  enforcing 

security attributes to data and to the users. 

21/06/2018 

Page 61 of 83 

 
 
 
 
 
 
 
Table 18: Introduction to SeaVision 

Vision and development strategy 

Idea behind SeaVision 
SeaVision is a web-based maritime situational 
awareness tool where users can view and share a 
broad array of maritime information (MSSIS, AIS, 
RADAR, vessel characteristics). Users can have 
historical view of ship tracks and define custom 
alerts on based on an analytical rule engine. 
Key Milestones 

Status 
SeaVision is operational  
Put as DoD Program  
Used by U.S. agencies 
(USCG, NOAA, State Dept.) 
and partners in Africa, S.E. 
Asia 
What’s next 
  Implementation of 
MISE concepts. 

  Publication of structured 
data (NIEM) is under 
development and test. 

  Long-term strategy, 
transition to DoD 
unclassified enterprise 
portal APAN. 

Overall architecture and design 

  Architecture implements a centralised web application. 
  Three core components: 
  C0mmon Maritime Picture: Google maps based geospatial visualisation. 
  Analytics: search and rules-based. 
  Administration: user and data mgmt. 
 
  Ad-hoc interfaces had to be developed for each information source. 

Implemented on AWS cloud  

Governance and organisation 

  Project Management: DoD Oceanographer of the Navy Staff (N2N6E) 
  Requirements management: U.S. Fleet Forces Command (U.S. Navy) 
  Technical management: Space and Naval Warfare Systems Command 

(SPAWAR) (Naval tech centre) + DoT Volpe Center. 

The  following  table  contains  the  key  findings  on  SeaVision  supporting  the  derived 
lessons learned. The last column indicates with  symbol [✓] if the finding has been 
used to derive the recommendations in chapter 4.   

21/06/2018 

Page 62 of 83 

 
 
 
 
 
 
 
 
  
 
Table 19: Key findings of SeaVision analysis 

Key findings for SeaVision 

Vision and development strategy 

Main evolution milestones 

SV.V.1 

SV.V.2 

SV.V.3 

SeaVision  was  developed  initially  by  DoT  Volpe  Center  as  a  web-
based  visualisation  tool  for  the  MSSIS  network.  When  US.  Naval 
Forces  Africa  (NAVAF)  saw  its  progress,  they  provided  funds  to 
advance the technology and further develop the tool. 

✓ 

In 2015, SeaVision was selected as the near-term solution to satisfy 
the  Navy’s  requirements  for  enterprise  access  to  maritime  data, 
automated  analytics  and  information  sharing  capabilities  to  support 
operational level MDA in an Unclassified/Non-PKI environment. 

In  2017,  SeaVision  was  equipped  with  advanced  data  management 
and  sharing  features  implementing  concepts  of  the  National  MDA 
Architecture Plan (NIEM data model, attribute-based access control). 
During  an  information  sharing  exercise  (Bold  Quest)  SeaVision  sent 
NIEM IEPDs to UK’s command and control system. 

✓ 

SV.V.4 

The  long-term  strategy  of  SeaVision  is  to  transition  its  functionality 
into  a  DoD  program  of  record  (POR)  to  provide  an  enterprise 
unclassified information sharing platform. 

Vision, guiding principles, value proposition 

SV.V.5 

SeaVision’s vision and inspiring principles are not clearly listed in the 
reviewed documentation. 

SV.V.6 

SeaVision’s  value  proposition  is  aligned  with  both  the  overall  vision 
regarding  MDA  and  MISE’s  own  value  proposition.  SeaVision’s  value 
can  be  summarised  in  cost-effectiveness,  interoperability,  user-
convenience, privacy and security. 

Countries involved 

SV.V.7 

Target: SeaVision was originally foreseen for use by NAVAF/NAVEUR 
for use with their international partners for partnership building. 

SV.V.8 

Actual:  US  Government  (US  Navy),  over  60  US  partner  nations, 
other government and non-government organizations. 

Sectors (user communities) 

SV.V.9 

SeaVision  user  communities  include  various  US  Government  entities 
and partner nations. 

SV.V.10  The main focus is towards the US government and enhancing ability 

to share maritime information with partner nations. 

Political and regulatory support 

SV.V.11  Within the U.S. Navy’s Fleet Forces, SeaVision has been identified as 
the  solution  satisfying  specific  requirements  of  non-classified 
information sharing capability with analytics. 

✓ 

✓ 

✓ 

Architecture 

21/06/2018 

Page 63 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Solution architecture approach 

SV.A.1 

SeaVision’s  architecture 
application. 

is  typical  of  a  multi-tier  web-based 

SV.A.2 

SeaVision only supports caching in a single central database. This is 
done for operational purpose to support its analytical features. 

Main architectural building blocks 

SV.A.3 

SeaVisions’s main building blocks can be organised conceptually into 
layers as follows. 

SV.A.4 

Presentation layer, a HTML-based graphical user interface. 

SV.A.5 

Application layer, which includes the core elements of SeaVision 
implemented as loosely-coupled modules. 

SV.A.6 

Application  Programming  Interfaces,  which  are  exposed  by  the  data 
layer. 

SV.A.7  Data  layer,  which  contains  information  about  users,  alerts,  rules, 

warnings, lists, shapes, tracks, etc. 

Data model 

SV.A.8 

Internally, SeaVision uses a custom data model. 

SV.A.10  SeaVision uses NIEM-M data model only for publishing vessel position 

to other systems. 

SV.A.11  In the future, new IEPDs will be developed to meet the requirements 

of sharing analytics-related information 

Service model 

SV.A.12  SeaVision  is  currently  in  the  process  of  implementing  the  service 
interfaces described in the MDA Architecture Plan for data publishing. 
The  actual  interfaces  will  differ  from  the  ones  described  in  the  MDA 
Architecture Plan, because SeaVision’s requirements are different and 
include sharing analytics-related information. 

SV.A.13  Besides  vessel  position,  all  the  information  that  SeaVision  stores  is 
available  via  its  web  interface  only.  Exporting functionality  of  Vessel 
Positions,  Vessel  Information,  Vessel  Lists,  Rule  Results,  and  Alert 
Results in various formats is available via the web interface. 

Strategic and operational governance (incl. SLAs) 

Governance   

SV.G.1  Most  roles  of  SeaVision’s  governance  lie  within  U.S.  DoD  /  Navy,  as 

the Office of Primary Responsibility (OPR). 

SV.G.2 

Requirement  management  process  follows  the  standard  procedure 
within U.S. Navy. This is done through an annual feedback gathering 
procedure.  SeaVision  team  is  working  for  including  the  voice  of  the 
user more rapidly in the feedback process. 

✓ 

SV.G.3  No specific information was found on SLAs nor on how IT services are 

managed. 

21/06/2018 

Page 64 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 IT service Management and Information Security 

SV.G.4 

Information  Security  is  enforced  per  record,  following  the  attribute-
based approach in the MDA Architecture Plan. 

✓ 

SV.G.5 

The Trust Fabric described for the MISE will not be implemented. 

21/06/2018 

Page 65 of 83 

 
 
 
 
 
Annex IV  DETAILED ANALYSIS OF THE INFORMATION FUSION CENTRE IN 

SINGAPORE 

This annex briefly introduces the IFC initiative with the help of a high-level diagram 
and  lists  the  key  findings  supporting  the  derived  recommendations.  The  report 
containing  the  detailed  analysis  of  the  IFC  initiative  can  be  found  in  D2.5.4  - 
Structured report on IFC. 

Table 20: Introduction to IFC 

Idea behind IFC 

IFC’s vision is to strengthening maritime security 
in the region and beyond, by building a common 
coherent maritime situation picture and acting as 
a maritime information hub for the region.  IFC 
aims to deliver actionable information to regional 
partners for further collaboration or to cue timely 
operational responses.  

Vision and development strategy 
Status 
IFC is operational since 
2009 by Republic of 
Singapore Navy. 
It is operated by 60 
international liaisons officers 
who coordinate with their 
home country agencies. 

Key Milestones 

What’s next 
No information available 

Overall architecture and design 

  Open interface architecture that can be customized to different needs 
  Open and Analysed Shipping Information System (OASIS) 
  Sense-Making, Analysis and Research Tool (SMART) 

Governance and organisation 

  111 International Liaison Officers (ILOs) are the national linkages and in 

charge of day-to-day work and decision making of the IFC. 
Information seem to be managed manually 

 

The  following  table  contains  the  key  findings  on  IFC  supporting  the  derived 
recommendations. The last column indicates with symbol [✓] if the finding has been 
used to derive the recommendations in chapter 4.   

Table 21: Key findings of IFC analysis 

Vision and development strategy 

Main evolution milestones 

I.V.1 

Persistent  problem  of  piracy  attacks  and  other  illicit  activities  in  the 
region around Singapore since 1980. 

21/06/2018 

Page 66 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
I.V.2 

The Republic of Singapore Navy was the driver in the development of 
their 
IFC,  gradually 
representatives 
facilitating 
communication between navies. 

involving  other  countries  by  hosting 
(Information  Liaison  Officers) 

for 

I.V.3 

IFC is operational since 2009. 

Vision, guiding principles, value proposition 

I.V.4 

IFC’s value proposition is focused on strengthening maritime security 
in the region through the exchange of information. 

Countries 

I.V.5 

23  countries  take  part  in  information  exchange  (mainly  within  the 
Southeast Asia region, but also including European countries such as 
France and the United Kingdom). 

Sectors 

I.V.6 

IFC target sectors are: 

•  National 

law  enforcement  agencies  (customs,  defence, 

immigration, etc.); 

•  National maritime security agencies (mainly military); and 

•  Shipping industry. 

Political and regulatory support 

I.V.7 

The legal basis of IFC operations is provided by: 

•  Memoranda  of  Understanding  (MoU)  between  Singapore  and 

participating countries; and 

•  Data  sharing  agreements  with  other  maritime  security 

centres. 

I.V.8 

Funding commitment is provided mainly by government of Singapore. 

I.V.9 

Participation in IFC is voluntary. 

Architecture 

Solution architecture  

I.A.1 

IFC’s architecture approach is an open interface architecture that can 
be customized to different needs. 

I.A.3 

IFC’s architecture approach is defined and implemented 

Main building blocks 

I.A.4 

The main building blocks of IFC architecture are: 

•  Open and Analysed Shipping Information System (OASIS) 

•  Sense-Making, Analysis and Research Tool (SMART) 

No detailed information is available. 

Service model 

Information not available 

21/06/2018 

Page 67 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Data model 

I.A.5 

The IFC deals with the following information entities. No information 
on the data model was found. 

•  8  types  of  maritime  security  incidents:  IUU  fishing,  piracy, 
trafficking,  general  maritime 

irregular  migration,  arms 
incidents, contraband trafficking, natural disasters, terrorism. 

•  Vessel  data  (IMO,  Automatic  Identification  System  -  AIS, 

LRIT) 

•  Weather and geographical data 

Governance   

Strategic and operational governance (incl. SLAs) 

I.G.1 

111  International  Liaison  Officers  (ILOs)  are  the  national  linkages 
between Singapore and the other countries and are in charge of day-
to-day work and decision making of the IFC. 

 IT service Management and Information Security 

I.G.2 

No detailed information is available. 

21/06/2018 

Page 68 of 83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
Annex V  DETAILED ANALYSIS OF THE SYSTEM WIDE INFORMATION 

MANAGEMENT IN EU 

This  annex  briefly  introduces  the  SESAR  initiative  with  the  help  of  a  high-level 
diagram  and  lists  the  key  findings  supporting  the  derived  recommendations.  The 
report  containing  the  detailed  analysis  of  the  SESAR  initiative  can  be  found  in 
D2.5.3 - Structured report on SWIM (SESAR). 

Table 22: Introduction to SWIM (SESAR) 

Vision and development strategy 

Idea behind SESAR’s SWIM 

SWIM is one of the key features of SESAR’s target 
concept. SWIM can be defined as standards, 
infrastructure and governance, enabling the 
management of ATM information and its 
exchange between qualified parties via 
interoperable services. 

Key Milestones 

Status 
Initial SWIM is being 
deployed in Europe in the 
context of the EU Pilot 
Common Project (PCP): 
common components, tech 
infrastructure, ground 
information exchanges over 
IP-network. 
What’s next 
  Air/Ground information 

sharing 

  Civil/Military information 

sharing 

  Common run-time 

registry 

  Federated identity 
management 

Overall architecture and design 

  Architecture implements a Service-oriented architecture (SOA) distributed 
network of nodes connecting SWIM-enabled systems and applications 

  SWIM nodes expose SWIM functionality to legacy systems 
  SWIM Registry allow the discovery of services (centralised component) 
  Services comply with different sets of standards and features (profiles) 

  SESAR Deployment Manager (SDM) coordinates implementation. 
  SESAR Joint Undertaking (SJU) coordinates R&D and maintains ATM 

Governance and organisation 

Master Plan. 

  At SWIM level: management functions, mapped to governance groups and 

governance processes. 

  SWIM governance framework is not yet fully in place. 

The  following  table  contains  the  key  findings  on  SESAR  (SWIM)  supporting  the 
derived recommendations. The last column indicates with symbol [✓] if the finding 
has been used to derive the recommendations in chapter 4.   

21/06/2018 

Page 69 of 83 

 
 
 
 
 
 
 
 
 
Table 23: Key findings of SWIM (SESAR) analysis 

Vision and development strategy 

Main evolution milestones 

SW.V.1 

SJU  Members  and  ATM  Stakeholders  have  highlighted  the 
importance of SESAR, and the SJU, as a key enabler of the wider 
SES  policy,  forming  an  “unprecedented  public-private  partnership 
that  co-ordinated  and  concentrates  effort  and  resources  at 
European level to achieve modernisation of ATM.” 

✓ 

SW.V.2 

The  high  level  strategy  (definition,  development,  deployment)  of 
SESAR  was  decided  upfront,  according  to  the  three  phases  from 
2005 to 2035. 

SW.V.3  Development  and  deployment  activities  are  now  running  in 
parallel.  Relationship  between  R&D  and  deployment  is  structured 
according  to  the  SESAR  innovation  pipeline  that  iteratively 
generates SESAR Solutions, comprising those projects are mature 
enough to be validated and industrialised. 

SW.V.3b  The  first  deployment  project  (the  Pilot  Common  Project)  included 
a subset of most important features and the ones who were most 
ready  to  deployment.  An  ad-hoc  body  was  established  to 
coordinate implementation (SESAR DM). 

SW.V.4 

SW.V.5 

SW.V.6 

SW.V.7 

SW.V.8 

The  Network  Manager  is  an  ad-hoc  body  that  was  created  to 
centralise  and  coordinate  certain  ATM-related  specific  functions. 
The body became the first SWIM pioneer (see below). 

Establishment of SWIM Governance was delayed and required new 
deadlines to be defined and a specific action plan to be drafted in 
SESAR Deployment Programme 2016. 

Time  for  proper  industrialisation  and  standardisation  is  needed 
between R&D and implementation, as “end of validation does not 
mean  straight  implementation.”  However,  in  SESAR  the  formal 
checks  to  identify  when  a  validated  solution  can  be  put  in 
production are not clearly specified. 

SWIM  strategy  has  been  decoupling  providers  from  consumers  of 
services,  i.e.  between  providers  and  consumers  of  information, 
allowing  gradual  growth  in  the  number  of  SWIM  participants  and 
diversification  in  their  nature,  as  well  as  a  continuous  increase  in 
SWIM enabled applications.  

The  first  early  adopter  of  SWIM  was  the  Network  Manager 
(EUROCONTROL)  in  2009  who  started  publishing  data  following 
SWIM  concepts.  This  encouraged  stakeholders  to  try  first-hand 
how  SWIM  works  and  to  incrementally  build  trust  and  embed 
these services in their own operational environments. As a result, 
NM B2B Web Services grew from 15 million queries made in 2011 
up to around 400 million in 2015. 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

SW.V.9 

Stakeholder  involvement  in  SWIM,  besides  funding,  was  fostered 
also 
through  annual  SESAR  SWIM  Master  Classes  and 
demonstrations within Europe  and  at  World  ATM Congress, which 

✓ 

21/06/2018 

Page 70 of 83 

 
 
 
 
 
 
promoted  early  adopters  as  SWIM  “champions”.  Moreover, 
workshops  around  the  world  increased  buy-in  towards  global 
interoperability,  which  culminated  in  the  SESAR  SWIM  Global 
demonstration  event.  In  SESAR  1  the  coordination  of  these 
activities was under the responsibility of a dedicated project. 

Vision, guiding principles, value proposition 

SW.V.10  At  policy  level,  the  main  value  proposition  of  SESAR  has  been 
communicated  by  the  Commission  with  KPIs  that  are  used 
throughout the program to evaluate overall results. 

SW.V.11  SWIM  vision  to  provide  relevant  and  commonly  understandable 
information  is  communicated  also  through  its  official  definition: 
“SWIM  consists  of  standards,  infrastructure  and  governance 
enabling  the  management  of  ATM  information  and  its  exchange 
between qualified parties via interoperable service”. 

SW.V.12  The  value  proposition  of  SESAR  and  SWIM  towards  industry 
stakeholders  is  being  in  the  position  to  develop  the  technology 
that  will  be  subsequently  adopted  as  standard.  This  will  give 
industry  stakeholders  in  competitive  advantage  as  they  will  be 
ready  to  sell  SESAR/SWIM-compliant  solutions  earlier  than 
competitors. 

Countries involved 

SW.V.13 

•  Target: EU and beyond. 

•  Actual: PCP countries 

Sectors (user communities) 

SW.V.14  All stakeholders in ATM are targeted by SESAR and SWIM. 

Political and regulatory support 

SW.V.15  SESAR and SWIM enjoy a strong regulatory and political support. 
However  implementation  and  compliance  to  regulations  is  still 
under  the  responsibility  of  Member  States.  SESAR  DM  acts  as 
intermediary  and  coordinator  but  it  is  not  mandatory  for  MS  to 
refer  to  it  in  order  to  implement  and  deploy  SESAR  solutions 
individually  without  funding.  Therefore,  the  risk  of  not having  full 
interoperable systems persist, as does the strong need to promote 
the value of cooperation and coordination. 

SW.V.16  PCP  regulation  allowed  room  for  interpretation  (as  seen  in 
Deployment  Programme)  and  did not  mention  SWIM  governance, 
whose  delay  is  a  blocking  factor.  For  this  reason  the  DM  had  to 
translate the regulation into a deployment programme that made 
reference,  for  example,  to  the  actual  services  resulting  from 
SESAR 1. However the deployment programme is non-binding and 
provides  only  guidance  and  recommendations.  These  limitations 
will be overcome by the Revised PCP that will, for example, make 
specific reference to SWIM governance. 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

SW.V.17  Standardisation  activities  are  triggered  when  a  sufficiently  large 
number  of  parties  agree  to  consolidate  the  output  of  R&D 

✓ 

21/06/2018 

Page 71 of 83 

 
 
 
 
 
 
 
 
activities 
into  standards.  Subjects  of  standardisation  are 
frameworks or rulebooks, not the implemented products (e.g. not 
the service instances), which allows flexibility and evolution. 

At  the  moment,  standardisation  is  managed  by  EUROCONTROL, 
but  it  will  be  with  the  sharing  environment  governance  bodies 
when they are in place. 

Solution architecture approach 

Architecture 

SW.A.1 

SWIM  approach  is  to  establish  a  Service  Oriented  Architecture 
leveraging open standards and mainstream technologies. 

SW.A.2 

The scope of SWIM is:  

✓ 

•  Harmonized definition of information exchanges as Services 

(using ISRM) 

•  Defined semantic interoperability of exchanged information 

(using AIRM) 

•  Technical  interoperability  achieved  through  standardized 

technological profiles (e.g. SWIM-TI Yellow Profile) 

• 

“Common  situational  awareness”  on 
information via the SWIM Registry. 

the  available 

SW.A.3 

ATM  business  processes,  i.e.  what  happens  behind  service 
interfaces, are out of scope of SWIM. 

SW.A.4 

SW.A.5 

is 
From  a  documentation  perspective,  SWIM  architecture 
organised in three views, which is a good practice: functional and 
technical views (normative), and a deployment view (illustrative). 

✓ 

SWIM  use  cases  describe  only  the  interaction  between  service 
information  provider  and  consumers  through  the  infrastructure. 
The  use  cases  focus  on  the  lifecycle  of  the  infrastructure  and  the 
evolution  of  service  evolution.  In  other  words,  the  uses  cases  do 
not enter into the details of ATM business processes.  

Main architectural building blocks 

SW.A.6 

SW.A.7 

SWIM  Node  is  a  logical  entity  with  no  specific  deployment 
constraints.  The  sole  purpose  is  to  group  SWIM  functional  blocks 
and allow a given system to use the SWIM-TI. Stakeholders have 
the 
the  best  suitable  deployment 
configuration according to their specific needs. 

freedom  of  choosing 

SWIM-TI profiles are limited sets of modular specifications that 
are grouped according to coherent needs. This allows for better 
technical interoperability than having single standard with large 
footprint. Different stakeholders may bind their service to the 
most suitable set of standards for their implementation of the 
service. 

SW.A.8 

The SWIM Registry is a common functional block that contains 
information about the services available via SWIM, will be central 
entity with data replication to affiliate registries for better query 

✓ 

✓ 

21/06/2018 

Page 72 of 83 

 
 
 
 
 
 
 
 
 
 
performance and availability.  

SW.A.9 

The  design-time  SWIM  Registry  will  be  replaced  by  a  run-time 
Registry which will allow for dynamic binding to services, provision 
of  routing  information  to  services,  provision  of  service  status 
information and lookup of policies. 

SW.A.10  SWIM-TI  Identity  Management  is  a  common  functional  block  that 

will take the form of two non-mutually-exclusive technologies: 

•  A Public Key Infrastructure responsible for signing, emitting 
and maintaining X.509 certificates and revocation lists. 

•  A  Security  Token  Infrastructure  providing  capabilities  to 

manage security tokens and Identity stores. 

SW.A.11  A  security 

framework 

the  deployment,  governance, 
management and operations of the SWIM-TI Identity Management 
functions is still under discussion.  

for 

SW.A.12  The  Shared  Object  functional  block  ensure  that  a  single  logical 
entity is kept up to date by all parties wishing to share information 
about  a  specific  object.  All  parties  use  the  shared  object  as  a 
reference  and  keep  it  updated  with  the  latest  information,  thus 
ensuring  consistency  and  freshness  of  data  across  systems.  In 
SESAR, this is the “Flight Object” shared object. 

is  an 

SW.A.13  At  network  level,  public  internet  is  used  at  first,  with  plan  to 
incrementally  use  the  PENS  (Pan-European  Network  Service), 
international  ground/ground  communications 
which 
implemented  by  EUROCONTROL  and 
infrastructure 
European  Air  navigation  service  providers  (ANSPs).  The  work  on 
establishing  and  evolving  PENS  is  also  performed  under  SESAR 
and  being  deployed  in  the  PCP. Nonetheless,  the  network  level  is 
not in the scope of SWIM. 

jointly 

Data model 

SW.A.14  The SESAR ATM Information Reference Model (AIRM) constitutes a 
semantic  baseline  for  definition  of  global  and  European  ATM 
information.  AIRM  represents  civil,  military  and  civil-military 
information/data constructs relevant to ATM and is managed as a 
product with dedicated governance. 

SW.A.15  Among  AIRM  constituting  elements, 

the  AIRM  Foundation 
Rulebook  provides  principles,  rules  and  recommendations  for 
modellers  creating  contributions  to  the  AIRM  or  developing  and 
maintaining the AIRM. 

SW.A.16  AIRM  is  explicitly  mentioned  in  the  PCP  regulation  as  the  data 

model for the services in SWIM.  

✓ 

✓ 

✓ 

✓ 

✓ 

SW.A.17  EUROCONTROL’s  specifications  referencing  AIRM  show  how  to 
provide guidance to document semantic correspondence to a data 
model when stakeholders draft new information definitions. 

✓ 

Service model 

21/06/2018 

Page 73 of 83 

 
 
 
 
 
 
 
 
SW.A.18  Information  Service  Reference  model  (ISRM)  is  a  model  that 
provides  each  service  with  a  complete  description  in  terms  of 
functionality, behaviour and logical interfaces. 

SW.A.19  As  prescribed  in  the  ISRM  Rulebook,  the  information  that  is 
exchanged  through  a  service  shall  be  traced  back  to  the  AIRM 
(ATM  Information  Reference  Model),  which  ensures  that  this 
exchanged information shares the same meaning at its origin and 
at its destination (i.e. semantic interoperability).  

SW.A.20  ISRM  is  a  platform-neutral  service  design  framework,  which 
means  that  there  are  no  platform  or  implementation  specific 
details. 

SW.A.21  ISRM is explicitly mentioned in the PCP regulation as the model for 

SWIM services. 

Governance   

Strategic and operational governance (incl. SLAs) 

SW.G.1 

SW.G.2 

At 
level  of  SESAR  research  and  development,  the  main 
governance  body  is  the  SESAR  Joint  Undertaking,  which  is 
responsible 
for  the 
maintenance of the ATM Master Plan. 

for  coordinating  research  project  and 

Coordination  of  deployment  activities  is  done  by  the  SESAR 
Deployment  Manager,  who  maintains  the  SESAR  Deployment 
Programme  and  acts  as  a  gateway  between  stakeholders  and 
European funding.  

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

SW.G.3 

At  level  of  SWIM,  the  first  ideas  for  the  governance  have  been 
defined in SESAR 1 and encompass the following aspects: 

✓ 

•  Essential  requirements  for  SWIM  Governance,  which  shall 
registry,  controlled 
include:  SWIM  authority,  SWIM 
vocabulary, standards and guidance to deploy SWIM, and a 
compliance framework. 

•  SWIM  Governance  Structure,  which  is  made  of  several 

governance groups. 

• 

• 

Information  Management  (IM) 
mapped to the governance groups. 

functions,  which  are 

Interactions  between  IM  functions  and  the  governance 
structure,  which  are  documented  as,  use  cases  and 
governance processes. 

SWIM  governance  is  being  refined,  in  particular  the  Terms  of 
Reference  for  the  Governance  bodies  as  well  as  the  essential 
policies guiding the SWIM Governance execution. The target date 
for completion is 2019. 

The  delay  of  establishment  of  SWIM  governance  is  recognised  as 
implementation  of  SWIM 
one  blocking 
technology  that  could  potentially  affect  the  whole  Pilot  Common 
Project. 

for  the 

factor 

full 

✓ 

✓ 

SW.G.4 

SW.G.5 

21/06/2018 

Page 74 of 83 

 
 
 
 
 
SW.G.6  Governance of service monitoring and SLAs is still not well defined 
in detail. Providing SLA guidelines and standards (e.g. agreement 
templates) is under the responsibility of SWIM governance, but no 
detailed information is available yet. 

SW.G.7 

Performance  management  functions  of  the  SWIM  Registry  shall 
include  functionalities  aiming  at  managing  policies  lifecycle, 
including  monitoring  and  reporting  SLAs,  however  no  details  are 
available yet. 

 IT service Management and Information Security 

SW.G.8 

SW.G.9 

SESAR Deployment programme addresses the topic of information 
security  and  cybersecurity  with  ATM  families  at  two  levels.  One 
family  (5.1.4)  deals  with  common  specifications  for  a  common 
Public  Key  Infrastructure  and  its  governance.  Another  family 
(5.2.3) focused on the implementation at the level of stakeholders 
(in  particular  ANSPs,  Airport  Operators,  Airspace  Users,  Network 
Manager, Military Authorities, MET Service Providers). 

The  deployment  programme  urges  stakeholders  to  explore  how 
current  technology  can  be  applied  to  the  ATM  domain.  A  PCP 
implementing  project  started  in  late  2017  with  the  purpose  of 
covering these common specifications for a comprehensive cross-
border  security  framework  and  is  expected  to  end  in  2019.  The 
main  idea  of  a  SWIM  Public  Key  Infrastructure  is  to  introduce  a 
common  bridge  certificate  authority  (CA)  that  each  stakeholder’s 
local  CA  shall  trust.  This  approach  would  ensure  minimal  impact 
on existing infrastructures 

✓ 

✓ 

✓ 

✓ 

SW.G.10  One  prerequisite  for  implementation  of  information  security 
concepts  is  the  establishment  of  SWIM  Governance  and  its 
governance processes. 

✓ 

SW.G.11  Establishing a solid security framework could help get buy-in from 

the military. 

21/06/2018 

Page 75 of 83 

 
 
 
 
 
 
 
Annex VI  GLOSSARY 

Table 24: Glossary 

AIRM 

AIS 

ANSI 

ANSP 

APAN 

API 

ATM 

AWS 

BOD 

CA 

CCB 

CEF 

CEF-T 

CISE 

COM 

Glossary 

ATM Information Reference Model 

Automatic Identification System 

American National Standards Institute 

Air navigation service provider 

All Partners Access Network 

Application Programming Interface 

Air Traffic Management 

Amazon Web Services 

Board of Directors 

Certificate Authority 

Configuration Control Board 

Connecting Europe Facility 

Connecting Europe Facility – Telecom 

Common Information Sharing Environment 

Commission of the European Communities 

CONOPS 

Concept of Operations 

CoopP 

CVISR 

Cooperation Project 

Consolidated Vessel Information and Security Reporting 

DG MARE 

Directorate-General for Maritime Affairs and Fisheries 

DoD 

DoJ 

Department of Defence 

Department of Justice 

DoN CIO 

Department of the Navy Chief Information Office 

DoT 

EC 

EEA 

Department of Transportation 

European Commission 

European Economic Area 

EMSA 

European Maritime Safety Agency 

EP 

EU 

EUMSS 

GMCOI 

HTML 

HTTP 

IALA 

ICT 

IFC 

European Parliament 

European Union 

European Union Maritime Security Strategy 

Global Maritime Community of Interest 

Hypertext Mark-up Language 

Hyper-text Transfer Protocol 

International Association of Marine Aids to Navigation and 
Lighthouse Authorities 

Information and Communication Technology 

Information Fusion Centre 

21/06/2018 

Page 76 of 83 

 
 
 
 
ILO 

IM 

IMO 

IOP 

ISI 

ISO 

ISRM 

iSWIM 

IT 

ITU 

JRC 

KPI 

LRIT 

LT 

International Liaison Officer 

Information Management  

International Maritime Organization 

Interoperability 

Information Sharing Infrastructure 

International Organization for Standardization 

Information Service Reference Model 

Initial SWIM 

Information Technology 

International Telecommunication Union 

Joint Research Centre 

Key Performance Indicator 

Long Range Identification and Tracking 

Long term 

MARSUNO 

Maritime Surveillance North  

MDA 

MISE 

MS 

MSEsG 

MSSIS 

NAVAF 

NIEM 

Maritime Domain Awareness 

Maritime Information Sharing Environment 

Member States 

Member State Expert sub-Group 

Maritime Safety and Security Information System 

Naval Forces Africa 

National Information Exchange Model 

NIEM EIEM 

NIEM Enterprise Information Exchange Model 

NIEM IEPDs 

NIEM Information Exchange Package Documentation 

NIEM- M 

NIEM- Maritime 

NOAA 

NSC 

OASIS 

PCP 

PENS 

PKI 

POC 

POV 

R&D 

RESTful 

S.E. Asia 

SDM 

SES 

National Oceanic and Atmospheric Administration 

National Security Council 

Open and Analysed Shipping Information System 

Pilot Common Project 

Pan-European Network Service 

Public Key Infrastructure 

Proof of Concept 

Pre-operational validation 

Research & Development 

Representational state transfer 

Southeast Asia 

SESAR Deployment Manager 

Single European Sky 

SESAR 

Single European Sky ATM Research 

SJU 

SLA 

21/06/2018 

SESAR Joint Undertaking 

Service Level Agreement 

Page 77 of 83 

 
 
 
SMART 

SOA 

Sense-Making, Analysis and Research Tool 

Service-oriented architecture 

SPAWAR 

Space and Naval Warfare Systems Command 

SWIM 

System Wide Information Management 

SWIM-TI 

SWIM Technical Infrastructure 

TAG 

ToR 

UN 

U.S. 

USCG 

VPN 

W3C 

XML 

Technical Advisory Group 

Terms of Reference 

United Nations 

United States 

United States Coast Guard 

Virtual Private Network 

World Wide Web Consortium 

Extensible Mark-up Language 

21/06/2018 

Page 78 of 83 

 
 
 
 
SC430DI07171 

Structured report on MISE and SeaVision 

Date: 21/06/2018 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Document Metadata 

Property 

Value 

Date 

Status 

21/06/2018 

Approved 

Version 

1.01 

Authors 

Reviewed by 

Andrea Marcato – PwC EU Services 
Lora Van Looveren – PwC EU Services 
Max Stahlecker – PwC EU Services 
Alexandru Chiric – DG MARE 
David Berger – JRC 
Jesus Hermida - JRC 

Approved by  

Alexandru Chiric – DG MARE 

This study was prepared for the European Commission under the auspices 
of the ISA Programme by: 

PwC EU Services 

Disclaimer: 

The views expressed in this report are purely those of the authors and may not, in 
any circumstances, be interpreted as stating an official position of the European 
Commission. 

The  European  Commission  does  not  guarantee  the  accuracy  of  the  information 
included in this study, nor does it accept any responsibility for any use thereof. 

Reference  herein  to  any  specific  products,  specifications,  process,  or  service  by 
trade  name,  trademark,  manufacturer,  or  otherwise,  does  not  necessarily 
constitute  or  imply  its  endorsement,  recommendation,  or  favouring  by  the 
European Commission. 

All  care  has  been  taken  by  the  author  to  ensure  that  s/he  has  obtained,  where 
necessary,  permission  to  use  any  parts  of  manuscripts  including  illustrations, 
maps,  and  graphs,  on  which  intellectual  property  rights  already  exist  from  the 
titular holder(s) of such rights or from her/his or their legal representative. 

21/06/2018 

Page i 

 
 
 
 
 
 
 
 
 
 
 
 
 
2.1 

2.1.1 

2.2 

2.2.1 
2.2.2 
2.2.3 
2.2.4 
2.2.5 

2.3 

2.3.1 
2.3.2 
2.3.3 

3 

2.4 

3.1 
3.2 
3.3 
3.4 

3.4.1 

3.5 

Table of Contents 

1 

INTRODUCTION ........................................................................................................... 1 

1.1 
1.2 

PURPOSE OF THIS DOCUMENT ...................................................................................................... 1 
STRUCTURE OF THIS DOCUMENT ................................................................................................... 1 

PART I –THE MARITIME DOMAIN AWARENESS ARCHITECTURE IN THE USA AND THE MISE ................. 2 

2 

VISION AND APPLIED DEVELOPMENT STRATEGY OF THE MDA ARCHITECTURE .............. 3 

VISION AND BUSINESS STRATEGY ................................................................................................... 3 
The evolution of MDA in the US and MISE ............................................................................ 3 
VISION AND MISSION STATEMENT, UNDERLYING VALUES, GOALS AND OBJECTIVES ................................. 10 
Vision .................................................................................................................................. 10 
Definition of MISE ............................................................................................................... 11 
Guiding principles ............................................................................................................... 12 
Value proposition ................................................................................................................ 13 
Customer segments ............................................................................................................ 13 
DEVELOPMENT STRATEGY OF MISE ............................................................................................. 13 
Scope, in terms of countries, agencies, and information services ...................................... 13 
Overall design, development, test and roll-out .................................................................. 15 
Constraints: legal/regulatory environment, resources, time and cost ............................... 16 
KEY FINDINGS ......................................................................................................................... 16 

OVERALL ARCHITECTURAL APPROACH ........................................................................ 19 

REQUIREMENTS ....................................................................................................................... 19 
USE CASES .............................................................................................................................. 20 
SOLUTION ARCHITECTURE .......................................................................................................... 21 
ARCHITECTURAL ELEMENTS ........................................................................................................ 21 
Key building blocks ............................................................................................................. 21 
TECHNICAL SOLUTION ............................................................................................................... 25 
Data model ......................................................................................................................... 25 

3.5.1 
3.5.2  Main technical solution(s) adopted to facilitate the implementation of the selected 

4 

3.6 

4.1 
4.2 
4.3 
4.4 

architecture ........................................................................................................................ 26 
KEY FINDINGS ......................................................................................................................... 27 

GOVERNANCE AND ORGANISATION STRUCTURE ......................................................... 30 

STRATEGIC GOVERNANCE AND OVERSIGHT .................................................................................... 30 
IT SERVICE GOVERNANCE ........................................................................................................... 34 
INFORMATION SECURITY ........................................................................................................... 35 
KEY FINDINGS ......................................................................................................................... 35 

PART II – SEAVISION .......................................................................................................................... 37 

5 

VISION AND APPLIED DEVELOPMENT STRATEGY ......................................................... 38 

5.1 

5.1.1 

5.2 

5.2.1 
5.2.2 
5.2.3 
5.2.4 
5.2.5 

5.3 

5.3.1 
5.3.2 
5.3.3 

VISION AND BUSINESS STRATEGY ................................................................................................. 38 
Strategy definition process: the evolution of SeaVision ...................................................... 38 
VISION AND MISSION STATEMENT, UNDERLYING VALUES, GOALS AND OBJECTIVES ................................. 39 
Vision .................................................................................................................................. 39 
Definition of SeaVision ........................................................................................................ 39 
Guiding principles ............................................................................................................... 40 
Value proposition ................................................................................................................ 40 
Customer segments ............................................................................................................ 40 
DEVELOPMENT STRATEGY OF SEAVISION ...................................................................................... 40 
Scope, in terms of countries, agencies, and information services ...................................... 40 
Overall design, development, test and roll-out .................................................................. 41 
Constraints: legal/regulatory environment, resources, time and cost ............................... 41 

21/06/2018 

Page ii 

 
 
 
 
 
 
 
5.4 

KEY FINDINGS ......................................................................................................................... 41 

6 

OVERALL ARCHITECTURAL APPROACH ........................................................................ 43 

6.1 
6.2 
6.3 
6.4 

REQUIREMENTS ....................................................................................................................... 43 
USE CASES .............................................................................................................................. 44 
SOLUTION ARCHITECTURE AND ARCHITECTURAL ELEMENTS ............................................................... 44 
TECHNICAL SOLUTION ............................................................................................................... 44 
Data model ......................................................................................................................... 44 

6.4.1 
6.4.2  Main technical solution(s) adopted to facilitate the implementation of the selected 

6.5 

7.1 
7.2 
7.3 
7.4 
7.5 

7 

8 

architecture ........................................................................................................................ 45 
KEY FINDINGS ......................................................................................................................... 47 

GOVERNANCE AND ORGANISATION STRUCTURE ......................................................... 49 

STRATEGIC GOVERNANCE AND OVERSIGHT .................................................................................... 49 
IT SERVICE GOVERNANCE ........................................................................................................... 49 
INFORMATION GOVERNANCE ..................................................................................................... 49 
INFORMATION SECURITY ........................................................................................................... 49 
KEY FINDINGS ......................................................................................................................... 50 

REFERENCES ............................................................................................................... 51 

List of Figures 

Figure  1.  Summary  of  evolution  of  MDA  policy  governance  and  technology  related  to  the  MDA 
Architecture Plan ................................................................................................................................ 4 

Figure 2: Building blocks of the MISE (physical view) ................................................................................. 22 

Figure 3: Four architectural views of MISE ................................................................................................. 23 

Figure 4: The MISE services ........................................................................................................................ 24 

Figure 5. MISE IT Architecture (hub and spoke) ......................................................................................... 26 

Figure 6: US MDA strategic governance structure ..................................................................................... 30 

Figure 7: MISE governance structure ......................................................................................................... 31 

Figure 8: NIEM governance structure......................................................................................................... 32 

Figure 9: NIEM-M domain governance structure ....................................................................................... 33 

Figure 10. SeaVision high-level IT architecture .......................................................................................... 45 

Figure 11. SeaVision deployment scheme on AWS .................................................................................... 46 

Figure 12. SeaVision user interface ............................................................................................................ 47 

21/06/2018 

Page iii 

 
 
 
 
 
 
 
 
 
 
 
 
List of Tables 

Table 1: MISE’s focus areas (i.e. information services) as reported in public documents 

Table 2. National MDA Architecture Plan Requirements: Entitlement Management 

Table 3. National MDA Architecture Plan Requirements: Information Management 

Table 4. National MDA Architecture Plan Requirements: Logger & Auditing 

Table 5: Building blocks of the MISE (explanation) 

15 

19 

20 

20 

22 

21/06/2018 

Page iv 

 
 
 
 
 
 
 
1  INTRODUCTION 

1.1  Purpose of this document 

This  document  provides  an  overview  of  the  United  States  Maritime  Information 
Sharing  Environment  (MISE)  and  of  a  maritime  domain  awareness  (MDA) 
application called SeaVision. The information has been gathered via desk research 
work and conference calls with the US Interagency representatives.  

The  initial  scope  of  the  research  covered  MISE  but  it  has  been  increased  with 
SeaVision,  following  the  US  interagency  representatives’  suggestion,  as  it  reuses 
several  elements  developed  under  the  MISE  and  plays  a  significant  role  as  a  MDA 
tool for the US and its partners.  

1.2  Structure of this document 

The remainder part of this document consists of two parts, each analysing one of the 
information sharing environments under investigation: MISE and SeaVision. 

Part 1 focuses on USA’s National MDA Architecture and MISE, and is structured as 
follows: 

• 

In  section  2,  the  vision  and  the  applied  development  strategy  of  the  MDA 
Architecture and MISE is outlined, with focus on the guiding principles, goals 
and objectives, scope and strategy development.  

•  Section 3 provides the overall IT architectural approach of MISE, including 

architectural building blocks, data models and information services. 

•  Section 4 includes the governance and the organisation structures that are 
in place to achieve the MISE’s strategic objectives, manage risks, and enable 
stakeholder engagement and buy-in. 

Part 2 focuses on SeaVision and is structured as follows: 

• 

In Section 5, the vision and the applied development strategy of SeaVision. 

•  Section 6 provides the overall IT architectural approach of SeaVision. 

•  Section 7 presents SeaVision’s governance and the organisation structure. 

Finally, within each of these sections, the interoperability aspects are analysed.  

21/06/2018 

Page 1 of 54 

 
 
 
 
 
 
 
 
 
PART I –THE MARITIME DOMAIN AWARENESS ARCHITECTURE IN 
THE USA AND THE MISE 

This  part  introduces  MDA  architecture  and  the  Maritime  Information  Sharing 
Environment in the US. The following picture summarises the main information that 
will be presented in more detail in the next sections according to the three areas of 
study.  

21/06/2018 

Page 2 of 54 

 
 
 
 
 
 
 
 
 
 
2  VISION  AND  APPLIED  DEVELOPMENT  STRATEGY  OF  THE  MDA 

ARCHITECTURE 

2.1  Vision and business strategy 

2.1.1  The evolution of MDA in the US and MISE 

In the wake of 9/11, the US established new bodies and set the basis for improved 
cross-domain  information  sharing,  including  the  maritime  domain.  The  following 
paragraphs provide a high-level overview of the policy roots, strategic decisions and 
key  events  that  lead  to  the  National  MDA  Architecture  Plan  and  the  Maritime 
Information  Sharing  Environment  (MISE).  The  main  elements  are  summarised  in 
Figure 1. Summary of evolution of Figure 1. 

21/06/2018 

Page 3 of 54 

 
 
 
 
 
 
 
 
 
Figure 1. Summary of evolution of MDA policy governance and technology related to the MDA 
Architecture Plan 

21/06/2018 

Page 4 of 54 

 
 
 
 
 
 
 
 
 
 
 
2004  

•  The Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA) 
established  the  Office  of  the  Program  Manager  for  the  Information 
Sharing  Environment  (PM-ISE)  and  granted  it  the  authority  to  plan, 
oversee,  and  manage  a  network-centric  information  sharing  environment 
(ISE) on several domains by promoting standards and architecture, security 
and access, and associated privacy protections.  

• 

In  December  2004, 
the  Maritime  Security  Policy  Coordination 
Committee  (MSPCC)  was  established  by  a  National  Security  Presidential 
Directive 41 [1] as a national-level interagency and interdepartmental forum 
at  the  National  Security  Council  (NSC)  for  de-conflicting  maritime  security 
policy, in order to “avoid a maritime 9/11”. At that time the fear was palpable 
that terrorists might launch any number of catastrophic maritime attacks [2].  

•  The  US  President  also  directed  the  Secretaries  of  the  DoD  and  Homeland 
Security  (DHS)  develop  a  comprehensive  National  Strategy  for  Maritime 
Security, “to better integrate and synchronize the existing Department-level 
strategies and ensure their effective and efficient implementation”. 

2005   

•  The National Strategy for Maritime Security (NSMS) was released along 
with eight supporting plans that “address the specific threats and challenges 
of the maritime environment” [3]. 

Interim Maritime Operational Threat Response Plan, 

International Outreach and Coordination Strategy, 

o  National Plan to Achieve Domain Awareness, 
o  Global Maritime Intelligence Integration Plan, 
o 
o 
o  Maritime Infrastructure Recovery Plan, 
o  Maritime Transportation System Security Plan, 
o  Maritime Commerce Security Plan, 
o  Domestic Outreach Plan. 

•  Within  the  NSMS,  the  National  Plan  to  Achieve  Maritime  Domain 
Awareness  (NPAMDA)  outlined  a  path  forward  to  ensure  that  “accurate 
information,  intelligence,  surveillance,  and  reconnaissance  is  shared  on  all 
vessels, cargo, and people extending beyond traditional maritime boundaries” 
[4].  The  national  plan  establishes  the  following  near-term  and  long-term 
priority topics. 

o 

Information and standards: 

  Enhance Information Collection, 

21/06/2018 

Page 5 of 54 

 
 
 
 
 
 
 
 
 
  Share Information, 

  Set Standards. 

o  Technology: 

  Sensors and Platforms, 

  Communications, 

 

Information Exploitation. 

o  Organizations and Personnel: 

  Building Coalitions and Partnerships, 

  Human Intelligence Collection, 

  Global Maritime Community Of Interest (GMCOI) Development, 

 

Integrated  National-Level  Maritime  Command  Centers  for 
Maritime Operational Threat Response. 

The  NPAMDA  also  gave  mandate  to  its  implementation  team  to  develop  a 
concept  of  operations  that  details  interagency  coordination  and  the 
development of national maritime common operating picture. 

•  The  NIEM  program  was  officially  launched  in  April  2005  by  the  Chief 
Information Officers of US Department of Homeland Security (DHS) and US 
Department  of  Justice  (DOJ)  to  support  data  exchange  across  government 
agencies [5]. The program was based on the experience of the Global Justice 
XML  Data  Model,  which  was  designed  specifically  for  criminal  justice 
information exchange [6]. 

2007 

•  The National Maritime Domain Awareness Concept of Operations (MDA 
CONOPS)  was  written  to  “execute  the  National  Plan  to  Achieve  Maritime 
Domain Awareness by establishing an on-going National MDA organizational 
structure” [7]. The document outlined the governance of national MDA and a 
desired  service-oriented  information  architecture  in  high-level  terms.  The 
document  proposed  the  creation  of  several  Enterprise  Hubs  from  existing 
organisations, acting as coordinators of information flows within their subject 
areas,  under  the  supervision  of  the  MDA  Stakeholder  board.  These  hubs 
are: 

o  Vessels, 
o  Cargo, 
o  People, 
o 
o  Architecture Management. 

Infrastructure, 

21/06/2018 

Page 6 of 54 

 
 
 
 
 
 
 
 
 
In  particular,  the  Architecture  Management  Hub  was  designated  to 
“further develop topics concerning information architecture” in several areas 
including  standards,  hosting  of  services,  technology  investments,  security, 
and SOA functionalities. The DoD Department of the Navy Chief Information 
Office (DON CIO) was designated as lead agency of this hub. 

2008  

•  NIEM entered a strategic partnership with DoD to develop the data model 

maritime domain extension [8]. 

2009 

•  The  MSPCC  was  renamed  to  Maritime  Security  Interagency  Policy 
Committee  (MSIPC).  With  this  change  of  name,  the  group  began  “to 
accommodate  global  maritime  security  issues,  including  piracy,  freedom  of 
navigation,  Arctic  Ocean  security,  and  U.S.  policy  relating  to  interdiction  of 
terrorists or weapons of mass destruction at sea” [2].  

•  The  National  Maritime  Intelligence  Centre  (NMIC)  was  created  by  the 
Director  of  National  Intelligence,  in  cooperation  with  the  Navy  and  Coast 
Guard. The NMIC was created “to serve as the national focal point for maritime 
intelligence” [9]. 

•  NIEM v2.1 was released and included the maritime domain, also referred to 

as NIEM-M [10]. 

•  The  DON  CIO  released  the  MDA  Architecture  Management  Hub  Plan, 
which  defines  in  more  detail  an  iterative  approach  and  methodology  to 
develop  the  AS-IS  and  TO-BE  national  MDA  architecture  [11].  In  the 
document,  NIEM  and  NIEM-M  were  designated  as  the  reference  data 
standards for information exchange.  

•  The  document  describing  the  MDA  As-Is  Architecture1  is  completed  in  June 

2009.  

2010 

•  The National MDA Coordination Office (NMCO), formerly known as Office for 
Global Maritime Situational Awareness (OGMSA), was established and was in 
charge with MDA information exchange within the unclassified sphere. 

• 

In October 2010, the documents describing the MDA To-Be Architecture and 
Architecture  Implementation  Plan2  are  merged  into  The  National  MDA 
Architecture Plan (NMDAAP), which describes the Maritime Information 
Sharing Environment (MISE)3. 

1 The document MDA As-Is architecture is not publicly available 
2 The documents MDA To-Be Architecture and Architecture Implementation Plan are not publicly 

available 

3 The first release of The National MDA Architecture Plan is not publicly available. 

21/06/2018 

Page 7 of 54 

 
 
 
 
 
 
 
 
 
                                                 
•  The Office of Management and Budget (OMB) provided guidance to all Federal 
Agencies to evaluate the adoption and use of NIEM as “the basis for developing 
reference information exchanges to support specification and implementation 
of reusable cross-boundary services” [12]. 

2012 

•  The  National  Maritime  Intelligence-Integration  Office  (NMIO)  was 
established  “to  consolidate  efforts  in  information  sharing  and  collaboration 
across the Global Maritime Community of Interest” [13]. The NMIO assumed 
the responsibilities of both the NMCO and the NMIC. 

•  Presidential Decision Directive 18: Maritime Security (PDD-18) was issued in 
August  2012.  The  directive  outlined  the  “responsibilities  of  numerous 
government  departments  and  agencies  vis-à-vis  maritime  security”  and  re-
establishes seven sub-plans. Particularly, the former National Plan to Achieve 
Maritime Domain Awareness and the Global Maritime Intelligence Integration 
Plan were integrated into a single National Maritime Domain Awareness 
Plan (NMDAP), which would be released subsequently in December 2013. 

•  According  to  ISE  2013  annual  report,  the  first  successful  evaluation  of  the 
National  MDA  Architecture  Plan  was  achieved  with  international  partners 
during  the  2011/2012  DoD  Trident  Warrior  exercises.  In  that  occasion, 
standardized  unclassified  data  sets  were  successfully  shared  between  the 
United States, France, and the United Kingdom. Based on how Trident Warrior 
successfully  facilitated  the  sharing  of  standards-based  information  between 
international  partners,  the  NMIO  and  PM-ISE  partnered  to  replicate  the 
sharing of maritime data between domestic partners [14].  

•  NMIO  and  the  PM-ISE  proposed  the  first  operational  implementation  of  the 
National  MDA  Architecture  Plan,  known  as  the  Domestic  Common  Maritime 
Picture  (DCMP).  The  DCMP  was  described  as  “an  unclassified,  multi-agency 
information  sharing  effort  in  the  port  of  Baltimore  that  improves  maritime 
security and builds port partnerships. Through re-using the data exchanges 
successfully  demonstrated  in  Trident  Warrior,  the  DCMP  has  successfully 
integrated data from DoD, DHS, Department of Transportation (DOT), and the 
Maryland Natural Resources Police into the MISE” [14].  

2013 

•  The National Maritime Domain Awareness Plan (NMDAP) [15] set as one 
of  its  objectives  to  improve  Domain  Awareness  through  enterprise-level 
access  to  data.  In  this  respect,  the  MDA  Executive  Steering  Committee 
(MDA  ESC)4  was  created  and  was  assigned  to  develop  an  enterprise 
architecture which includes:  

4 The MDA ESC is comprised of senior executive-level Principals designated by their respective 

departmental Executive Agents (EA) for MDA from cabinet-level departments (currently DoD, DOT, and 

21/06/2018 

Page 8 of 54 

 
 
 
 
 
 
 
 
 
                                                 
o  Enterprise, web-centric, cloud-based, information and services; 
o  Common data standards, and 
o  Data access policy. 

•  The National MDA Architecture Plan (NMDAAP) v2.0 was the first publicly 
introduces  the  MISE.  The  document  was 
available  document  that 
subsequently approved by the members of the MDA ESC (i.e. DOT, DHS, DoD 
and IC) through 2013 and 2014 [16]. 

•  The DoD adopted NIEM “as the best suited option for standards-based data 

exchanges” [17]. 

2015 

•  On behalf of the MDA ESC, the DoD Office of the Executive Agent for Maritime 
Domain Awareness gave the mandate to the DoT Volpe Centre and NMIO to 
conduct an engineering study to evaluate the alignment of the DHS Integrated 
Maritime Domain Enterprise - Coastal Surveillance System-Enterprise (IMDE-
CSS) as an enterprise system to the NMDAAP. According to 2017 Volpe Center 
Annual  Accomplishment  report  [18],  the  study  included  the  following 
elements. 

o  Overall direction and infrastructure hosting options for the Information 

Sharing Infrastructure (ISI) for the MISE. 

o  Evaluation  of  the  CSS  and  its  services,  and  determine  if  the  coastal 

CSS could serve as the ISI for the MISE. 

o 

In-depth  research  into  various  cloud  hosting  platforms  for  different 
government information classification types and purposes, including a 
cost/benefit analysis; 

o  Review and analysis of pertinent U.S. DOT, DHS, and DoD information-

sharing policies and regulations; and 

o  Critical evaluation of the National MDA Architecture Plan to inform and 

guide decision making. 

o  Technical  recommendations  and  a  course  of  action  for  MISE 

implementation. 

2016 

•  The  National  MDA  Architecture  Plan  was  updated  to  the  latest  publicly 

available version [19]. 

•  The  NSC  MSIPC  approved  the  National  MDA  Architecture  Plan  for  sharing 
maritime enterprise-level data and information. On this regard, NMIO Director 
remarked that in the “long term, the plan’s single unifying standard will ensure 

DHS) and the designated maritime representative of the Intelligence Community (IC). [See NMDAP, 
page 14] 
21/06/2018 

Page 9 of 54 

 
 
 
 
 
 
 
 
 
                                                 
a  more  holistic  approach  for wider  data  integration  efficiency  and  improved 
decision making” [20]. 

• 

In the context of the National Strategy for the Arctic Region, the White House 
prompted  the  DHS,  US  Coast  Guard  to  “leverage  the  Maritime  Information 
Sharing  Environment,  developed  as  part  of  the  National  Maritime  Domain 
Awareness Architecture, to develop the capability to receive information from 
diverse sources, analyse the information, and disseminate it to stakeholders. 
Publish a plan to establish a mechanism for information sharing for the Arctic 
by the end of 2017” [21].  

2017 to date 

As emerged during information exchanges with the US interagency representatives, 
the  MISE  and  its  Information  Sharing  Infrastructure  are  not  yet  operational  at 
national  level  in  the  way  outlined  by  the  MDA  Architecture  plan.  The  required 
architecture  building  blocks,  processes  and  governance  structures  are  not  yet  in 
place. 

The  initial  position  of  the  US  interagency  representatives  was  that  “the  MDA 
Architecture Plan was developed to show that it was feasible” and that “the MISE was 
put in place [for demonstration purposes only] but it was not operational”. 

Further discussions highlighted that today the concepts described in the National MDA 
Architecture  plan  are  seen  as  best  practices  for  implementing  mission-specific 
systems while assuring overall interoperability. Even though the MISE is not in place 
as described, the concept is still valid. US Government is committed to continue in 
the  direction  of  interoperability  by  encouraging  the  adoption  of  common  data 
standards and architectures. In the foreseeable future, efforts will continue to be put 
towards  establishing  an  interoperable  ecosystem,  rather  than  a  single  overarching 
system. 

In the time being, our discussions indicated that two initiatives are being built upon 
the concepts behind MISE:  

•  For  the  US  Maritime  Security  Initiative  in  South-East  Asia  there  is  an 
understanding  that  building  shared  awareness  in  Southeast  Asia  is  an 
immediate regional need.  

•  The  National  Maritime  Intelligence-Information  Office  (NMIO)  is  planning  to 

instantiate an environment based on MISE. 

2.2  Vision and mission statement, underlying values, goals and 

objectives 

2.2.1  Vision  

The National Strategy for Information Sharing and Safeguarding document outlines 
the vision on information sharing at national level [22]: 

21/06/2018 

Page 10 of 54 

 
 
 
 
 
 
 
 
 
“It is a national priority to efficiently, effectively, and appropriately share and 
safeguard information so any authorized individual (Federal, state, local, tribal, 
territorial,  private  sector  or  foreign  partner)  can  prevent  harm  to  the 
American people and protect national security.  

The Strategy points toward a future in which information supports national 
security  decision  making  by  providing  the  right  information,  at  any 
time,  to  authorized  users,  restricted  only  by  law  or  policy,  not 
technology:  and  where  safeguarding  measures,  to  include  a  comprehensive 
regimen of accountability, prevent the misuse of the information.”  

The National Strategy for Maritime Security outlines the objectives in the maritime 
domain [3]. 

Together, the National Strategy for Maritime Security and its eight supporting 
plans present a comprehensive national effort to promote global economic 
stability  and  protect  legitimate  activities  while  preventing  hostile  or 
illegal acts within the maritime domain. 

Finally,  the  National  MDA  Architecture  Plan  clarifies  its  mission  in  the  maritime 
domain [19]: 

“To  establish  a  national-level  MDA  enterprise  architecture  to  include: 
Enterprise,  web-centric,  cloud-based, 
information  and  services; 
Common data standards; and, Data access policy.” 

2.2.2  Definition of MISE  

In  2007,  the  MDA  CONOPS  outlined  the  desired  state  of  MDA  and  its  information 
architecture. Four “product lines” were initially envisaged, as follows. 

•  A  services-oriented  architecture  foundation  that  provides  a 
structure  for  interoperable  computing.  The  core  services  include 
security  and  information  assurance,  service  discovery,  enterprise 
services  management,  machine-to-machine  messaging,  people  and 
device discovery, mediation and metadata registry services; 

• 

• 

collaboration  that  enables  synchronous  communications  and  file 
sharing  among  users.  These  services  include  session  management, 
presence and awareness, audio collaboration, video collaboration, text 
collaboration, application sharing, application broadcasting, and virtual 
space; 

content discovery and delivery that provides common specifications 
to  expose,  search,  retrieve  and  deliver  information  across  the 
enterprise; and  

•  portal services that provide personalized, user-defined, web-enabled 

presentation and offer secure access to the enterprise. 

21/06/2018 

Page 11 of 54 

 
 
 
 
 
 
 
 
 
These four “product lines” from the MDA CONOPS however, are not all addressed in 
the definition of MISE as identified in the MDA Architecture Plan: 

The  MISE  provides  an  internet  accessible,  unclassified  information  sharing 
capability  where  data  providers  and  consumers  manage  and  share  maritime 
information through common data definitions and security attributes. […] 

The MISE employs industry standard service protocols that, in most cases, 
are already supported by participating agencies. The MISE does not define how 
agencies execute their missions, manage their infrastructure, or the products 
they  develop.  The  MISE  does  define  how  the  results  of  those  mission 
activities or information products are made available to others. Through 
the definition of data standards within the National Information Exchange Model 
-  Maritime  (NIEM-M),  the  MISE  provides  a  common  vocabulary  in  four 
initial  focus  areas:  Vessel  Positions,  Advance  Notice  of  Arrival, 
Indicators  and  Notifications,  and  Maritime  Operational  Threat 
Response.  While  only  four  focus  areas  are  defined  in  the  initial  effort,  the 
standards and processes defined by the MISE are designed to be reusable and 
extensible to support future information sharing products and partners. 

The overarching goal of the Architecture Plan is to establish information sharing 
process  and  framework  to  advance  information  sharing  capabilities.  The 
objective is for agencies and organizations within the GMCOI to be able to utilize 
their own requirements, authorities, information infrastructures, and resources 
to  share  information  within  the  community  that  would  assist  operational 
missions. The MISE simply provides an environment for the successful transfer 
of information between information consumers and providers. 

2.2.3  Guiding principles 

MISE’s guiding principles are defined at strategic level and at architecture level. These 
principles are set to help achieve MISE’s vision: 

The National Strategy for Information Sharing and Safeguarding defined the National 
vision for information sharing. In this document, 3 core principles at national strategy 
level are identified [22]: 

1.  Information as a National Asset 

2.  Information Sharing and Safeguarding Requires Shared Risk Management  

3.  Information Informs Decision Making  

At architecture level, the following “guiding concepts” are defined [8]: 

• 

“Users” will not access the MISE: provide system level connectivity, not user 
level. 

•  National products, not bulk data. 

•  Access control definitions are global yet flexible enough for each system 

21/06/2018 

Page 12 of 54 

 
 
 
 
 
 
 
 
 
 
•  Think  “free”:  focus  on  non-material  solutions;  architectural  processes,  not 

physical servers 

•  Follow best practices from industry: don’t build new just because we can. 

2.2.4  Value proposition 

According  to  Appendix  F  of  the  National  MDA  Architecture  Plan  [23],  the  value  of 
MISE to the Maritime Community is: 

•  User Convenience – Users can access multiple services using a common set 
of  standardized  security  credentials  making  it  easier  to  sign  on,  access 
applications, and manage account information. 

• 

Interoperability  –  MISE  specifies  common  security  standards  and 
framework so applications can adopt interoperable security specifications for 
authentication and authorization. 

•  Cost-Effectiveness  –  MISE  facilitates  information  sharing  by  using 
standardized  Extensible  Markup  Language  (XML)-based  credentials  that 
include information about each user’s identity and privileges. This reduces the 
cost and complexity of identity administration required to access applications 
and vet users. 

•  Privacy  –  MISE  will  reduce  the  propagation  of  personally  identifiable 
information  (PII),  reduce  redundant  capture  and  storage  of  PII,  and 
depersonalize data exchanges across domains using privacy metadata. 

•  Security  –  the  MISE  model  will  improve  the  security  of  PII  and  data  in 
participant organizations’ applications by providing a standardized approach 
to online identities between agencies or applications. 

2.2.5  Customer segments 

Several  publicly  available  documents  such  as  the  CONOPS,  MDA  Architecture  plan 
and MDA Architecture Management Hub plan indicate the GMCOI, or some parts of 
it, to be the main target of the MISE. The MDA Architecture Plan describes the GMCOI 
(Global Maritime Community of Interest) as “US Federal, state, local, tribal, territorial 
and international partners” [19]. More specific information such as a list of members 
cannot be found.  

2.3  Development strategy of MISE 

The  following  paragraphs  focus  on  the  MISE  project  and  give  an  overview  of  the 
project activities, status and way forward as a result of desk research and interviews. 

2.3.1   Scope, in terms of countries, agencies, and information services 

Analysis of MISE’s publicly available information has shown that its scope has evolved 
in terms of target users and information services: 

21/06/2018 

Page 13 of 54 

 
 
 
 
 
 
 
 
 
As defined in 2.2.5, MISE’s scope in terms of target users differs from document to 
document: the MDA CONOPS refers to only to “federal agencies within the GMCOI” 
while  the  National  MDA  Architecture  Plan  extends  the  target  to  “agencies  and 
organizations within the GMCOI”.  

In terms of information services, MISE website5 provides the latest available list 
of information services offered by the MISE. 

•  Position  (POS):  A  geospatial  position,  course,  heading,  speed,  and 
status of a vessel at a given time. A series of position reports can be 
combined to produce track information. 

• 

Indicators and Notifications (IAN): Indicators are information used 
to  inform  or  contribute  to  an  analytical  process.  Notifications  include 
warnings of a possible event and alerts about the execution of an event. 

•  Notice  of  Arrival  (NOA):  A  96-hour  advance  notice  that  all  vessels 
inbound  to  US  ports  are  required  to  submit,  which  lists  vessel,  crew, 
passenger, and cargo information. 

•  Vessel  Information  (VINFO):  Static  vessel 

characteristics 

information, such as vessel tombstone data. 

•  Consolidated  Vessel  Information  and  Security  Reporting 
(CVISR): Defined and standardized levels characterizing how much is 
known  about  a  vessel  (and  associated  people,  cargo,  and 
infrastructure)  at  a  given  time.  CVISR  is  generally  an  assembled 
product consisting of essential elements from the previous four IEPDs 
[i.e. data products]. 

As  shown  in  Table  1.  MISE’s  initial  scope  in  terms  of  information  services  evolved 
over time, according to the documentation available.  

Two additional information services that were mentioned in the documentation but 
their technical implementation was not found on MISE’s website. These are: 

•  Maritime Operational Threat Response (MOTR), defined as “A cross-

departmental conference convened as necessary to coordinated response to 
a maritime threat.” 

•  Biometric & Identity Information Exchange, defined as based on 

“ANSI/NIST standard being represented in Biometric domain”. 

5 https://web.archive.org/web/20161129005010/https://mise.mda.gov/drupal/node/42 

21/06/2018 

Page 14 of 54 

 
 
 
 
 
 
 
 
 
 
                                                 
Table 1: MISE’s focus areas (i.e. information services) as reported in public documents 

National 
MDA 
Architecture 
Plan v2 
(2013) 

National 
MDA 
Architecture 
Plan brief  
[8] (2015) 

National 
MDA 
Architecture 
Plan v3 
(2016) 

MISE 
website 
(as of 
Nov 
2016) 

Vessel position (POS) 

Advance notice of 
arrival (ANOA) 

Indicators and 
notifications (IAN) 

MOTR information 
exchange 

Biometric and identity 
information exchange 

Vessel information 
(VINFO) 

Consolidated Vessel 
Information and 
Security Reporting 
(CVISR) 

x 

x 

x 

x 

x 

x 

x 

x6 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

2.3.2  Overall design, development, test and roll-out 

The strategy to implement MDA within the context of national information and data 
sharing guidance evolved according to the below public documents [4] [8] [11]: 

•  This  guidance  started  with  the  publishing  of  the  National  Strategy  for 
Information Sharing in 2005. The National Strategy for Information Sharing, 
although broader in scope than just MDA and focused on terrorist information, 
establishes  guiding  principles  and  foundational  elements  for  information 
sharing  on  a  national  level.  Along  with  eight  supporting  plans  it  presents  a 
comprehensive  national  effort  to  promote  global  economic  stability  and 
protect legitimate activities while preventing hostile or illegal acts within the 
maritime domain. One of these plans is the National Plan to Achieve Domain 
Awareness.  

Many other policies, guidance documents, strategies, and plans helped set and shape 
the direction of information sharing for the Global Maritime Community of Interest 
(GMCOI)  

6 The revised document from 2016 states that: “While MOTR was designated as an initial focus area, the 

MOTR process was not used in the Architecture Plan”. 
21/06/2018 

Page 15 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                 
•  The  National  Concept  of  Operations  for  Maritime  Domain  Awareness  (MDA 
CONOPS) describes this desired state as an environment in which the GMCOI 
embraces  and  achieves  the  common  objective  of  obtaining  and  sharing 
information  as  a  mechanism  to  increase  the  safety,  security,  and  economic 
prosperity in the maritime domain. 

•  Then  the  principal  characteristic  of  the  MDA  enterprise  architecture  were 

developed and delivered as three products:  

o  An  As-Is  Architecture  Description  describing  the  architecture  of 
operations and resources that compose the current state of the MDA 
enterprise architecture.  

o  A  To-Be  Architecture  Description  describing  the  architecture  of 
operations  and  resources  that  will  compose  the  desired  state  of  the 
MDA enterprise architecture. 

o  An  Architecture  Migration  and  Implementation  Plan  describing  the 
capability gaps between the current (as-is) and desired states (to-be) 
of  the  MDA  enterprise  architecture  as  well  as  a  plan  for  migrating 
existing resources and for developing new resources in response 

•  Finally,  an  initial  SOA  Architecture  was  developed  focusing  on  five  initial 
products  /  processes.  These  were  MISE  initial  focus  areas:  Vessel  position 
(POS), Advance notice of arrival (ANOA), Indicators and notifications (IAN), 
Vessel  information  (VINFO),  Consolidated  Vessel  Information  and  Security 
Reporting (CVISR). 

2.3.3  Constraints: legal/regulatory environment, resources, time and cost 

The main constraints of the architecture were as follows (as in [19]): 

•  The architecture is not directive in nature: all participation is voluntary. 

•  The  architecture  cannot  affect  individual  policies,  resources,  missions  or 

existing architectures. 

•  The  architecture  must  have  low  threshold  of  entry:  use  proven  technology, 

integrate with Agency legacy systems. 

•  The architecture must leverage existing national capabilities to the greatest 

extent possible. 

2.4  Key Findings 

The  following  paragraph  highlight  the  most  relevant  findings  that  can  be  useful  to 
compare MISE with CISE on the topics outlined in this chapter. 

Main evolution milestones 

• 

Initially,  the  main  driver  of  MDA-related  policies  was  the  response  to  9/11 
terrorist attacks, with the military (US Navy) mostly in the lead.  

21/06/2018 

Page 16 of 54 

 
 
 
 
 
 
 
 
 
•  The scope of the MDA CONOPS was more far reaching than what proposed in 
the  MDA  Architecture  Plan  in  the  MISE.  The  MDA  CONOPS  envisaged 
essentially  a  set  of  features  enabling  content  discovery  and  delivery, 
collaboration  and  portal  services,  all  relying  on  a  services-oriented 
architectural  foundation.  On  the  other  hand,  the  National  MDA  Architecture 
Plan and MISE only seem to address the latter aspect. 

•  A  structured  and  centralised  approach  to  develop  the  architecture  was 
adopted by the Architecture Management Hub. The DoD Department of the 
Navy Chief Information Office (DON CIO) was designated as lead agency for 
the hub. 

• 

Instead of developing an entire data model from scratch, the MDA Architecture 
Hub Plan envisaged to leverage the existing successful efforts, i.e. the NIEM 
initiative and its dedicated maritime domain extension.  

•  The  first  evaluation  of  the  MDA  Architecture  Plan  and  the  MISE  was  in  a 
military exercise with few international US partners, while the first operational 
implementation was in the port of Baltimore.  

•  No  information  has  been  found  on  demonstrations,  pilot  projects  or  pre-
operation  validations  conducted  at  a  large  scale,  for  instance  among  all  US 
coastal States. 

•  Overall,  the  available  documentation  reviewed  indicates  that  a  top-down 
approach was followed, in which, after the initial policy push at strategic level, 
work  was  carried  on  mostly  by  the  US  Navy  with  no  clear  involvement  of 
stakeholders at state and local level. 

•  The  MISE  is  not  yet  operational  and  its  governance  structure  is  not  yet  in 

place. 

•  Besides the idea of adopting “common standards for common understanding” 
the concept of having the MISE implemented as a single system seems to be 
put on hold in favour of a more decentralised approach, i.e. an interoperable 
ecosystem allowing mission-specific systems to communicate with each-other 
when needed. 

Vision, principles, value proposition 

•  The overall vision of the United States regarding MDA “points toward a future 
in which information supports national security decision making by providing 
the right information, at any time, to authorized users, restricted only by law 
or  policy,  not  technology:  and  where  safeguarding  measures,  to  include  a 
comprehensive  regimen  of  accountability,  prevent  the  misuse  of  the 
information.” 

•  MISE’s  mission  can  then  be  defined  as  to  establish  a  “national-level  MDA 
enterprise  architecture  to  include:  Enterprise,  web-centric,  cloud-based, 

21/06/2018 

Page 17 of 54 

 
 
 
 
 
 
 
 
 
information and services; common data standards; and data access policy” in 
the unclassified domain. 

•  MISE’s  value  proposition  to  the  maritime  community  regards:  user 
convenience, interoperability, cost-effectiveness, privacy, and security.  

•  MISE’s  user 

convenience  and 

cost-effectiveness  are  particularly 
communicated  by  a  wealth  documentation  that  includes  implementation 
guides  and  code  samples.  These  online  guides  are  addressed  to  system 
integrators and administrators who want to join the environment. However, 
documentation  on  the  inner  working  of  the  sharing  environment  are  not 
available. 

Countries involved 

•  Target: the MISE was originally foreseen for use within the United States and 

with possible use by international partners. 

•  Actual: none, as MISE is not operational. 

Sectors (user communities) 

•  The  sectors  or  user  communities  are  not  formally  listed  in  any  reviewed 
source.  Maritime  domain  stakeholders  are  identified  in  the  MDA  CONOPS 
under the term “Global Maritime Community of Interest” which is defined as 
follows. “GMCOI includes, among other interests, the federal, state, local and 
tribal departments and agencies with responsibilities in the maritime domain. 
Because certain risks and interests are common to government, business, and 
citizen  alike,  community  membership  also  includes  public,  private  and 
commercial  stakeholders,  as  well  as  foreign  governments  and  international 
stakeholders.” 

•  The CONOPS states to be applicable to federal agencies within the GMCOI. 

Political and regulatory support 

•  The National MDA Architecture Plan describing the MISE was approved by the 
agencies taking part in the MDA Executive Steering Committee (Department 
of Defence, Homeland Security, Transportation and Intelligence Community) 

•  The National MDA Architecture Plan was subsequently approved at the level 
for the National Security Council by the Maritime Security Interagency Policy 
Committee. 

•  Adoption of the Architecture Plan and the MISE remains completely voluntary. 

•  NIEM was endorsed by the Office of Management and Budget (OMB) as “the 
basis for developing reference information exchanges to support specification 
and  implementation  of  reusable  cross-boundary  services”.  Later,  the 
Department  of  Defence  adopted  NIEM  “as  the  best  suited  option  for 
standards-based data exchanges”. 

21/06/2018 

Page 18 of 54 

 
 
 
 
 
 
 
 
 
3  OVERALL ARCHITECTURAL APPROACH 

This section presents the overall architectural approach of the MISE, introducing the 
requirements, use cases and MISE’s high-level IT architecture, which is then further 
detailed  into  its  architectural  building  blocks  and  interaction  patterns.  Finally,  we 
present an overview of the actual technical implementation 

3.1  Requirements 

The  National  MDA  Architecture  Plan  lists  the  features  of  the  Information  Sharing 
Infrastructure,  which  are  categorized  into  three  groups:  Entitlement  Management, 
Information Management and Logger and Auditing. These are listed below. 

Table 2. National MDA Architecture Plan Requirements: Entitlement Management 

Entitlement Management 

ENT-001 

ENT-002 

ENT-003 

ENT-004 

ENT-005 

ENT-006 

Users  are  granted  access  to  maritime  information  based  on  information 
access policies and attributes assigned by the information providers. 

The  ISI  recognizes  a  standardized  set  of  security  attributes  for  entitlement 
management  as  defined  in  the  National  Architecture  Plan.  Information 
providers use the security attributes7 to tag information they publish to the 
ISI  with  metadata  to  convey  data  protection  requirements.  The  security 
attributes are included as metadata on the information provided to consumer 
systems for integrity throughout the data management lifecycle. 

Information  providers  can  apply  security  attributes  at  varying  levels  of 
granularity  depending  on  policy:  message-level  (e.g.,  an  entire  XML 
message); record-level (e.g., records within an XML message). 

Trusted  systems  authenticate  users  using  either  an  internal  or  external 
identity management process. Trusted systems supply user attributes for all 
queries.  The  user  attributes  and  entity  attributes  (corresponding  to  the 
trusted system) are compared to the information provider supplied security 
attributes on the data to make entitlement decisions. 

Users are prohibited from accessing information for which they or their trusted 
system do not have entitlements. 

Both  information  provider  and  information  consumer  trusted  systems  are 
authenticated  by  the  ISI.  All  connections  between  the  ISI  and  the  trusted 
systems will be secured via SSL. 

ENT-007 

Trusted  systems  will  be  responsible  for  complying  with  all  rules  for 
maintaining trusted 

7 The attributes were explained in Appendix B of the document. 

21/06/2018 

Page 19 of 54 

 
 
 
 
 
 
 
 
 
 
 
                                                 
Table 3. National MDA Architecture Plan Requirements: Information Management 

Information Management 

INF-001 

Ingest, index, and cache messages from appropriate information providers. 

INF-002 

Information  providers  can  set  the  expiration  date  of  their  messages,  which 
shall  not  exceed  30  days  from  the  time  of  publication;  the  ISI  will 
automatically remove expired messages from the cache when they expire. 

INF-003 

Search  and  retrieve  information  from  the  cache  to  service  requests  from 
trusted systems. 

INF-004 

Securely dispose of expired information. 

Table 4. National MDA Architecture Plan Requirements: Logger & Auditing 

Logger & Auditing 

LOG-001 

Log all external interactions with the ISI. 

LOG-002 

Log all internal system activities. 

LOG-003 

Log  all  attributes  presented  by  a  trusted  system  for  each  request,  the 
request  itself,  the  messages  retrieved  to  match  the  request,  and  the 
resulting  messages  returned  to  the  trusted  system  upon  an  entitlement 
decision. 

LOG-004 

Log all attempted and established connections and sessions. 

LOG-005 

Capture all states and activities necessary for auditing. 

LOG-006 

Log all message disposal activity. 

LOG-007 

Maintain all logs in accordance with all auditing requirements. Ensure that 
logs are fully backed up for auditing purposes. 

LOG-008 

Log all auditing activity. 

3.2  Use cases 

The information sharing use cases identified in the National MDA Architecture Plan 
are focused on the role of the infrastructure only and highlight how the ISI can reply 
to queries. In particular: 

•  Use  Case  1  addresses  the  ISI  acting  as  an  Information  Broker.  The  ISI 

caches the information and acts as the decision authority. 

•  Use Case 2 addresses the ISI acting as a Request Broker only, passing both 
the request and the user attributes from the information consumer system to 
the information provider system. In this case the information provider system 
acts as the decision authority. 

21/06/2018 

Page 20 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
Pros and cons are also provided in the document and summarised below. 

Use Case 

Benefits 

Implications 

Use Case 1 
ISI Acts as 
Information Broker 
(ISI has Decision 
Authority and ISI 
Performs Caching) 

Use Case 2 
ISI acts as Request 
Broker only 
(Information 
Provider has 
Decision Authority; 
No Caching) 

•  Eliminates cost of servicing 

•  Information Provider must tag 

requests 

•  Reduces implementation 
costs associated with 
enforcing  information 
access policy 

messages with security attributes 
to convey information controls 

•  Information Provider must keep 
cached information in the ISI 
current 

•  Information Provider 

•  Increased implementation costs 

maintains maximum control 
over data by assuming IAP 
enforcement responsibility 

associated with enforcing 
information access policy 

•  Information Provider must tag 

messages with security attributes 
to convey information controls 
Information Provider must ensure 
capacity to service requests from 
National Maritime Federation 

3.3  Solution architecture 

3.4  Architectural elements 

3.4.1  Key building blocks 

The figure and table below explain the physical view of the key components of the 
MISE [19]: 

21/06/2018 

Page 21 of 54 

 
 
 
 
 
 
 
 
 
 
 
Figure 2: Building blocks of the MISE (physical view) 

Table 5: Building blocks of the MISE (explanation) 

Key functional elements  Description 

1.  Trusted  systems  and 
their users 

2.  NIEM-Maritime  data 
standards 

3.  Common  attributes  for 
access control 

Information  Sharing 

4. 
Infrastructure (ISI) 

Each  system  within  the  MISE  is  referred  to  as  a 
Trusted  System.  Systems  can  be  information 
providers or consumers. 
Shared  vocabulary  and  standards  as  defined  by 
NIEM Maritime extension (discussed earlier) 

Access  control  is  done  via  user  authentication. 
Authorisation is performed by the ISI according to 
per-record security attributes defined by the owner. 
ISI is the central hub of the MISE and provides the 
service  interfaces  to  the  trusted  systems.  Trusted 
Systems interact only with the ISI. 

Furthermore, the National MDA Architecture Plan describes the concept and technical 
specifications  of  the  Maritime  Information  Sharing  Environment  (MISE) 
through the National Maritime Architecture Framework. [19] 

The  resulting  framework  is  comprised  of  four  architectural  views  as  shown  in  the 
figure below [19]: 

1.  Data Architecture View 

2.  Services Architecture View 

3.  Security Architecture View 

21/06/2018 

Page 22 of 54 

 
 
 
 
 
 
 
 
 
 
 
4.  Technical Operations Architecture View 

Figure 3: Four architectural views of MISE 

1.  Data architecture view: 

In MISE, a record is the unit of shared information. Each record has a record 
type which is defined by a NIEM IEPD.  

As anticipated in section 2.32.3.1, the current IEPDs defined for usage in MISE 
[24]: 

Position (POS). A geospatial position, course, heading, speed, and status of 
a vessel at a given time. A series of position reports can be combined to produce 
track information [25]. 

Indicators  and  Notifications  (IAN).  Indicators  are  information  used  to 
inform or contribute to an analytical process. Notifications include warnings of 
a possible event and alerts about the execution of an event [26]. 

Notice of Arrival (NOA). A 96-hour advance notice that all vessels inbound 
to  US  ports  are  required  to  submit,  which  lists  vessel,  crew,  passenger,  and 
cargo information [27]. 

Vessel  Information  (VINFO) - Exchange  Model  Description.  Static  vessel 
characteristics information, such as vessel tombstone data [28]. 

Consolidated 
Reporting 
(CVISR) - Exchange  Model  Description.  Defined  and  standardized  levels 
characterizing  how  much  is  known  about  a  vessel  (and  associated  people, 

Information 

Security 

Vessel 

and 

21/06/2018 

Page 23 of 54 

 
 
 
 
 
 
 
 
 
 
 
cargo,  and  infrastructure)  at  a  given  time.  CVISR  Is  generally  an  assembled 
product consisting of essential elements from the previous four IEPDs [29]. 

2.  Services architecture view 

Two services are defined for retrieving information from the ISI [19]: 

•  Search  Service:  Find  records  matching  specified  criteria.  Returns  a 

list of summary records and record IDs in an atom feed. 

•  Retrieval Service: Retrieve a record with a specified ID. Returns the 

NIEM-M XML representation of the record.  

A single service is defined for publishing information into the ISI [19]: 

•  Publication  Service:  Place  information  into  a  cache,  and  keep  the 
cache  up  to  date  including  delete  operations  to  remove  information 
from the cache 

The figure below illustrates several important aspects of the MISE services. 
One of these aspects is the integration options. Two integration options are 
available for information providers, as shown in the 2 most right boxes [19]: 

• 

Implementing search and retrieval endpoints (ISI routes requests) 

•  Publishing  information  to  the  ISI  cache.  (ISI  acting  as  information 

broker) 

Figure 4: The MISE services 

3.  Security architecture view 

See section 4.3 on Information Security. 

4.  Technical operations architecture view 

The  technical  operations  view  provides  a  high-level  overview  of  MISE  operational 
concepts in three areas. 

21/06/2018 

Page 24 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
•  The document briefly mentions that service management activities of the 
MISE include: monitoring availability of information provider and ISI services, 
registration of trusted systems for authentication and discovery services, and 
review of services levels to ensure service performance thresholds and SLAs 
are met. 

•  High-level    roles  and  responsibilities  are  mentioned  for  the  MISE 
Management  and  for  Trusted  Systems  (generic  responsibilities  and  those 
applicable only to providers and to consumers) 

•  A section on end-user support outlines a 3-tier help-desk. 

Communication patterns 

The  National  MDA  Architecture  Plan  describes  the  characteristics  of  all  services 
interactions  between  trusted  systems  and  the  ISI.  For  further  details  see  section 
3.5.2.  

Trusted  systems  connect  to  the  ISI  over  the  public  Internet.  All  service 
interactions use the HTTPS protocol. 

MISE  services  are  RESTful  web  services.  RESTful  web  services  use  the  HTTP 
protocol as an application protocol, rather than simply as a transport. RESTful 
web  services  are  implemented  very  much  like  standard  web  applications,  as 
opposed to using any type of complex middleware layer. The RESTful style was 
chosen for MISE because of its simplicity and ease of integration. As RESTful 
services, nearly all MISE service interactions follow a simple pattern, which is 
the same pattern used by a web browser accessing a page on the Internet. 

3.5  Technical solution 

3.5.1  Data model 

The  data  model  adopted  for  the  MDA  Architecture  Plan  is  NIEM  and  its  Maritime 
domain extension.  

•  NIEM  is  a  community-driven  data  model  and  information  exchange 
specification adopted by many agencies and local governments in the US. 

•  The  NIEM  core  defines  universal  objects  (e.g.  people, 

locations, 

organisations)  

•  Several  NIEM  domains  (e.g.  maritime)  extend  the  NIEM  core  including  

mission specific data components (e.g. vessel, cargo) 

•  NIEM defines a process for business users to document information exchange 
requirements  into  standardised  packages,  the  IEPDs.  Custom  ad-hoc 
extensions and sub-standards are possible. 

21/06/2018 

Page 25 of 54 

 
 
 
 
 
 
 
 
 
 
•  NIEM formalises the development process of a IEPD in defining a six-phased 

approach. 

•  Documentation,  training  resources,  code  samples  and  tools  are  available 

online (niem.gov) 

3.5.2  Main technical solution(s) adopted to facilitate the implementation 

of the selected architecture 

The  US  National  MDA  Plan  briefly  describes  information  on  the  architecture  of 
MISE’s  technical  solution.  Detailed  information  on  their  building  blocks 
implemented is lacking.  

MISE end-to-end architecture is summarised in the picture below, where building 
blocks according to a sequential “data sharing value chain”. In the picture, dark 
orange  boxes  indicate  logical  components,  while  light  orange  boxes  indicate 
logical deployment boundaries. 

Figure 5. MISE IT Architecture (hub and spoke) 

The main characteristics of the technical solution are outlined below [19]: 

21/06/2018 

Page 26 of 54 

 
 
 
 
 
 
 
 
 
 
 
•  MISE  services  are  RESTful  web  services  provided  by  the  ISI  and 
exposing URIs accessible from the public internet over SSL.  The RESTful 
style was chosen for MISE because of its simplicity and ease of integration.  

o  Example: GET /search/<iepdname>?querystring 

•  The web syndication model is used to provide information updates. The 
information  consumer  system  periodically  queries  the  Search  service, 
using the full search query language, but including additional parameters 
allowing  the  returned  Atom  document  to  report  recent  changes  in  a 
manner efficient for the provider and consumer. 

•  Any error conditions are reported using standard HTTP status codes. 

Other  aspects  of  the  exchange  (e.g.  session  handling)  are  handled  following 
standard HTTP conventions. 

Documents  describing  the  ISI  in  more  detail  are  not  available.  The  available 
documentation  focuses  on  implementation  at  user  side  (i.e.  an  authority’s  Trusted 
System), with code samples and guides that are downloadable online. 

3.6  Key Findings 

Solution architecture approach 

• 

In the reviewed documentation, the requirements of the information sharing 
environment  were  first  explained  from  a  business  perspective  in  the  MDA 
CONOPS.  Then,  the  National  MDA  Architecture  Plan  lists  of  features  of  the 
Information  Sharing 
(i.e.  Entitlement  Management, 
Information Management, Logger & Auditing) and its two technical use cases. 
The relationship between the requirements in these documents is not explicitly 
mapped, e.g. via a table or via business-oriented use case that could better 
link business and technical requirements. 

Infrastructure 

•  The MISE consists of a hub-and-spoke architecture where a central building 
block  (the  Information  Sharing  Infrastructure)  acts  as  the  broker  between 
information providers and consumers. 

•  The  architecture  of  MISE  is  documented  according  to  several  views:  Data, 

Services, Security, and Technical Operations view. 

Main architectural building blocks 

•  The main building blocks of the MISE are: 

o  Trusted Systems, i.e. the information providers and consumers; 
o  NIEM-Maritime, which harmonise the data format exchanged between 

Trusted Systems; 

o 

Information Sharing Infrastructure (ISI), which acts as broker between 
Trusted Systems 

21/06/2018 

Page 27 of 54 

 
 
 
 
 
 
 
 
 
o  Trust Fabric, which ensures the security of the environment. 
•  The Trust Fabric consists of a set of certificates that are deployed manually 
into  the  Trusted  Systems  and  their  reference  is  maintained  by  the  MISE 
Management body in the Trust Fabric Document. 

•  Besides its functional requirements, further technical details on how the ISI is 
implemented are not available, therefore it is not clear whether the ISI is to 
be  implemented  as  a  single  centralised  system  or  as  a  more  distributed 
network.  

•  No specific building block is implemented to facilitate information discovery, 
e.g. a service inventory of the MISE. An IEPD clearinghouse is hosted at DOJ 
where  the  definition  of  the  maritime-related  IEPDs  can  be  found.  However, 
the list of IEPDs available in the MISE is found only in the documents.  

•  All  interactions  between  Trusted  Systems  and  the  ISI  are  synchronous  and 

happen via RESTful web services over standard HTTP protocol. 

•  A caching mechanism in the ISI decouples publishers and subscribers. 

Data model 

•  MISE’s data model is based on NIEM and its maritime domain extension 

•  NIEM core defines universal objects (e.g. people, locations, organisations). 

•  NIEM’s maritime domains extend the NIEM core including mission specific data 

components. 

•  NIEM formalises the development process of a IEPD in defining a six-phased 

approach. 

•  NIEM-based  and  custom  entities  are  combined  into  the  reusable  Maritime 

Domain Awareness Enterprise Information Exchange Model (EIEM). 

•  Entities  defined  in  the  MDA  EIEM  are  subsequently  combined  into  several 
IEPDs, which are finally the unit of information that is published and consumed 
in the MISE. 

•  MISE defines the following IEPDs 

o  Vessel position 
o  Notice of arrival 
o 
o  Vessel Information 
o  Consolidated Vessel Information and Security Reporting (CVISR) 

Indicators and notifications 

Service model 

21/06/2018 

Page 28 of 54 

 
 
 
 
 
 
 
 
 
 
•  For each IEPD implemented in the MISE, two services are defined: search and 

retrieve. 

•  The search service returns a list of records matching the search query in RSS 

format. 

•  The retrieve service returns the NIEM content of the requested record in XML 

format. 

21/06/2018 

Page 29 of 54 

 
 
 
 
 
 
 
 
 
 
 
4  GOVERNANCE AND ORGANISATION STRUCTURE 

4.1  Strategic governance and oversight 

The figure below is a representation of the US National MDA Strategic Governance 
Structure [11].  

1.  At high political level 

Several bodies are in charge of US MDA strategic governance, as shown in Figure 6 
and explained below [30]: 

Interagency coordination for maritime domain awareness is primarily exercised 
within  the  Maritime  Security  Interagency  Policy  Committee,  which  reports  to 
the  National  Security  Council  Deputies  Committee.  A  Maritime  Domain 
Awareness Stakeholders Board consists of representatives from all departments 
and  the  intelligence  community  advises  the  Maritime  Security  Interagency 
Policy  Committee  through  its  Executive  Steering  Committee.  DOD,  the 
Department of Homeland Security, and the Department of Transportation have 
all appointed executive agents for maritime domain awareness who, together 
with  a  representative  of  the  intelligence  community,  constitute  the  Maritime 
Domain Awareness Stakeholder Board Executive Steering Committee.  

Figure 6: US MDA strategic governance structure 

21/06/2018 

Page 30 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
-  The  Maritime  Security  IPC 

interagency  and 
interdepartmental forum at the National Security Council (NSC) on maritime 
security policy. 

is  a  national-level 

-  The  MDA  Executive  Steering  Committee  is  made  of  high-level  officials 

(Executive Agents) appointed by DoT, DHS, DoD and NMIO. 

-  The MDA Stakeholder board includes representatives from a broad cross-
section  of  agencies  in  order  to  ensure  appropriate  equities  are  represented 
and  all  information  and  intelligence  sharing  opportunities  are  exploited  and 
evaluated as a means to achieve MDA. 

-  The  Enterprise  Hubs  are  responsible  for  coordinating  information  sharing 
among the multiple agencies and organizations within each MDA information 
pillar: vessels, cargo, people and infrastructure. The MDA CONOPS describes 
the strategic governance structure below the enterprise hubs. 

-  The Architecture Management Hub is responsible for designing and 

managing the overall enterprise architecture needed to facilitate net-centric 
sharing of maritime information.  

2.  At level of MISE  

The MISE governance structure consists of the MISE Board of Directors (BOD), MISE 
Management, and the MISE Configuration Control Board (CCB) with representatives 

21/06/2018 

Page 31 of 54 

Figure 7: MISE governance structure 

 
 
 
 
 
 
 
 
 
 
 
(such as information providers and consumers) from the organizations taking part in 
the MISE8. It is presented in the figure below [23]: 

The specific organizations and individuals that comprise the BOD, MISE Management 
and CCB will evolve over time.  

•  The  MISE  Management  is  responsible  for  day-to-day  operations  of  MISE, 

leads the NIEM-M domain and managers the Help Desk and Security. 

•  The  Board  of  Directors  provides  executive  oversight,  allocates  budget, 

approves key decisions and identifies potential new partners. 

•  The  Configuration  Control  Board  changes  management,  analyses  / 
provides  recommendations  to  improve  MISE  (governance,  operations, 
policies) 

3.  At the level of NIEM data model 

NIEM is jointly governed by DoJ, DHS, and HHS. It is executed in a federated model 
through a consensus-based approach and headed by the entities below [31]: 

Executive Steering 
Council 

NIEM Program 
Management 
Office 

NIEM Technical 
Architecture 
Committee (NTAC) 

NIEM Business 
Architecture 
Committee (NBAC) 

Figure 8: NIEM governance structure 

•  The Executive Steering Council (ESC) sets the overall vision for the NIBM 
community and serves as decision-making body regarding NIEM membership, 
funding requirements, and program/technical direction.  

•  Day-to-day  operations  are  managed  by  the  NIEM  Program  Management 
facilitates  collaboration  between  NIEM 

Office  (NIEM  PMO),  which 

8 The document does not specify which organizations and individuals comprise the BOD, MISE 

Management and CCB. 
21/06/2018 

Page 32 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                 
community and stakeholders in developing NIEM-based information exchange 
solutions.  

•  The  NIEM  Business  Architecture  Committee  (NBAC)  guides  the 
development,  harmonization,  evolution,  and  implementation  of  NIEM  Core 
data components, as well as governs the processes for participating in NIEM 
domains.  

•  The  NIEM  Technical  Architecture  Committee  (NTAC)  is  responsible  for 

defining the technical architecture that governs NIEM. 

Specific agreements between NIEM PMO and MDA ESC define the following roles and 
responsibilities of the NIEM-M governance structure [31]: 

MDA Executive 
Steering 
Committee 

NIEM Program 
Management 
Office 

Content 
Management 
Working Group 

NIEM-M Steward 

Technical 
Committee 
(Training and 
Technical Support) 

Figure 9: NIEM-M domain governance structure 

•  The MDA ESC oversees the NIEM-M implementation. 

•  The  NIEM-M  Steward  is  responsible  for  the  domain’s  model  content, 
governance,  maintenance  and  coordination  with  stakeholders.  The  NIEM-M 
Domain Steward furthermore evaluates the performance of the NIEM-M and 
the related processes by the following metrics: 

o  The number of stakeholders or organizations who are participating in 

NIEM-M activities; 

o  The number of content change requests within the NIEM-M; 
o  The number of training and outreach opportunities; and 
o  The number of IEPDs created that leverage NIEM-M content.  

21/06/2018 

Page 33 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
These metrics are reported to the MDA ESC. 

•  The  Technical  Committee,  chaired  by  the  Steward,  consists  of  technical 
representatives from the MDA ESC and NIEM PMO; is responsible for technical 
support  and  NIEM-M  training;  provides  business  and  technical  expertise  in 
creating IEPDs. 

•  The Content Management Working Group provides a NIEM-M community 
forum  where  the  community  members  can  recommend  changes  and 
enhancements to the NIEM-M. 

4.2  IT service governance 

MISE’s  Service  Management  is  under  responsibility  of  the  MISE  Management 
Organization.  The  National  MDA  Architecture  Plan  provides  a  brief  overview  of  the 
topics concerning Service Level Agreements (SLAs). 

MISE’s service level agreements define: 

•  The type of services that will be used for the information exchange; 

•  Terms for selecting, accepting, maintaining and transitioning services into the 

MISE; 

•  Terms  for  executing  and  evaluating  the  quality  of  service  of  information 

exchanges; 

•  Terms for executing the service agreement. 

Terms for executing the service agreement will include: 

•  Contacts and Role assignment: Responsible organizations and roles that have 

access to the trusted systems and the MISE; 

•  Reporting: Logs will be provided based on terms laid out in the SLA; 

•  Review Process: Quarterly reviews will be established that include discussion 

on SLA fulfilment and future projects that may affect the SLA; 

•  Performance Level Guidelines: Outlines the inbound and outbound information 
flows to and from the ISI and expected behaviour from each trusted system 
and the MISE; 

•  Uptime  Requirements:  Outlines  the  expected  availability  that  the  trusted 
systems must deliver as well as the expected availability that it will provide; 

•  Equipment Support Requirements: Access and security of trusted systems in 

the MISE; 

•  Third Party Sharing: Can data be shared beyond the receiving trusted system 

other than as defined in the releaseability attribute? 

21/06/2018 

Page 34 of 54 

 
 
 
 
 
 
 
 
 
MISE Management has the authority to sign any service Level Agreements on behalf 
of the MISE. Any modifications to the standard agreement or assignments of these 
agreements will require the BOD approval. 

4.3  Information security 

Details  on  MISE’s  information  security  are  given  in  the Security  Architecture  view. 
The purpose of the MISE Security Architecture is to ensure that shared information 
is protected in accordance with applicable doctrine. Information providers must be 
assured that shared records will only be revealed to users who meet certain criteria. 
In addition, some records contain subsets of information that should only be revealed 
to  a  subset  of  MISE  users.  This  section  describes  the  main  features  of  MISE’s 
information security [19]:  

•  Attributes are assigned to entities, users and the data. 

o  Entity Attributes: Attributes that pertain to a trusted system (granted 

by MISE management) 

o  User Attributes: Attributes that pertain to a human user (granted by 

the trusted system) 

o  Data  Attributes:  Attributes  that  pertain  to  data  (granted  by  the 

provider system) 

•  Indicators  are  included  in  the  attributes  for  users,  entities  and  data. 
Indicators define which the type of information a user and a trusted system is 
entitled to access, e.g. “Law Enforcement”, “Privacy Protected”, “Sensitive but 
unclassified”, “Protected critical infrastructure information”, etc. 

•  Certificates are issued to trusted systems (both consumers and providers) 

by the MISE Certificate authority. 

•  The MISE Trust Fabric is a digitally signed XML document describing each 
trusted system in the MISE. This document is signed by the MISE Certificate 
Authority and distributed to all trusted systems as a trust anchor upon which 
all cryptographic operations rely. The trust fabric is set-up manually by the 
MISE Management. 

User  attributes  are  sent  by  the  service  consumer  to  the  service  provider  at  the 
beginning of the interaction, before a session is created. 

4.4  Key findings 

Strategic and operational governance (incl. SLAs) 

•  At political level, information sharing efforts in the maritime domain between 
US agencies are overseen by the MDA Stakeholder Board with an Executive 

21/06/2018 

Page 35 of 54 

 
 
 
 
 
 
 
 
 
 
Steering Committee composed of agents from Departments of Transportation, 
Homeland Security, Defence and from the Intelligence Community. 

•  One  level  below,  several  hubs  are  responsible  for  coordinating  information 
sharing  among  the  multiple  agencies  and  organizations  within  each  MDA 
information pillar: vessels, cargo, people and infrastructure. 

•  A  dedicated  enterprise  hub  is  responsible  for  managing  the  MDA  enterprise 

architecture. 

•  At  the  level  of  MISE,  the  governance  structure  consists  of  MISE  Board  of 
Directors  (BOD),  MISE  Management,  and  the  MISE  Configuration  Control 
Board (CCB) with representatives from various organizations, both providers 
and consumers). 

•  MISE’s data model, NIEM-Maritime, is a separate initiative with a dedicated 

governance structure. 

•  Specific  agreements  between  NIEM  and  the  MDA  ESC  define  roles  and 

responsibilities of the NIEM-M governance structure.  

•  MISE Management body is responsible of IT Service Management and SLAs. 

•  MISE Management has the authority to sign any service Level Agreements on 
behalf  of  the  MISE.  Any  modifications  to  the  standard  agreement  or 
assignments of these agreements will require the BOD approval. 

•  The  National  MDA  Architecture  plan  touches  upon  what  SLAs  should  define 
and  what  should  be  the  main  terms  for  executing  service  agreements. 
However these topics are not elaborated in detail. 

IT Service Management and Information Security 

• 

Information  security  is  a  responsibility  that  is  shared  among  MISE 
stakeholders. 

o  MISE Management is responsible for setting up the Trust Fabric among 
Trusted  Systems  (i.e.  maintaining  the  Trust  Fabric  Document  and 
granting  the  right  attributes  to  the  systems),  and  assuring  the  ISI 
allows access to data according to the right permissions. 

o  Trusted  Systems  owners  are  responsible  of  enforcing  security 

attributes to data and to the users. 

•  User  attributes  are  sent  by  the  service  consumer  to  the service  provider  at 

the beginning of the interaction, before a session is created 

21/06/2018 

Page 36 of 54 

 
 
 
 
 
 
 
 
 
PART II – SEAVISION 

This  part  introduces  SeaVision.  The  following  picture  summarises  the  main 
information that will be presented in more detail in the next sections according to the 
three areas of study.  

21/06/2018 

Page 37 of 54 

 
 
 
 
 
 
 
 
 
 
 
5  VISION AND APPLIED DEVELOPMENT STRATEGY 

5.1  Vision and business strategy 

5.1.1  Strategy definition process: the evolution of SeaVision 

The  following  paragraphs  give  a  high-level  overview  of  the  policy  roots,  strategic 
decision and key events that influenced the birth of SeaVision from 2010.  

2006 

•  The Maritime Safety and Security Information System (MSSIS) is established 
as  “a  freely-shared,  unclassified,  near  real-time  data  collection  and 
distribution  network.  Its  member  countries  share  data  from  Automatic 
Identification  Systems  (AIS)”.  Participants  voluntarily  share  national  AIS 
information.  In  return  participants  have  access  to  all  AIS  in  the  network. 
MSSIS  was  developed,  hosted  and  maintained  by  US  Department  of 
Transportation Volpe Center. 

2010 

•  Development of SeaVision started as a basic viewer for MSSIS data. 

2011  

•  As of 2011, 68 countries around the world participate in the MSSIS network 

[32]. 

•  SeaVision is released as a web-based MSSIS AIS visualization tool aimed at 
supporting US Naval Forces Africa (NAVAF) and partner countries in the area 
[32]. Data sources were Automatic Identification System (AIS), coastal radar, 
and  satellite  AIS.  With  the  introduction  of  satellite  AIS,  MSSIS  data  was 
increased by 157% providing visibility to large areas not previously covered 
by Terrestrial AIS. Also, a 30-day historical data of ship tracks, a feature not 
previously available in MSSIS.  

2013 

•  All 20 African countries that were members of MSSIS and used SeaVision were 

contributing their own data [33]. 

2014 

• 

In 2014, a requirements letter from Commander, U.S. Fleet Forces Command 
(USFFC)  to  Oceanographer  and  Navigator  of  the  Navy  (OPNAV  N2/N6E) 
defined  a  requirement  for  “enterprise  access  to  maritime  data,  automated 
analytics and information sharing capabilities to support operational level MDA 
in  an  Unclassified/Non-PKI  environment”  [34].  More  details  are  given  in 
section 6.1. 

2015 

21/06/2018 

Page 38 of 54 

 
 
 
 
 
 
 
 
 
•  OPNAV N2/N6E replied to the USFFC identifying SeaVision as the near-term 
solution to satisfy the requirements, while “[t]he long-term solution will be to 
transition the functionality of Sea Vision into the DoD enterprise unclassified 
information sharing platform, All Partners Access Network (APAN)” [35]. 

• 

In 2015, SeaVision was used in three naval exercises including participation 
from  23  African  countries  and  their  respective  Maritime  Operation  Centers 
(MOCs) [36]. 

2016   

•  SeaVision 1.0 – delivered September 2016 added improved dashboard 

features (analytics). 

2017 

•  SeaVision  2.0  –  delivered  January  2017:  enhanced  data  management  and 

sharing and user management features. 

• 

In  October  2017  during  an  information  sharing  exercise  (Bold  Quest) 
SeaVision sent NIEM data to UK’s command and control system. [37] 

5.2  Vision and mission statement, underlying values, goals and 

objectives 

5.2.1  Vision  

No specific hints on SeaVision’s vision nor a formal vision statement have been found. 
According  to  the  US  interagency  representatives,  SeaVision’s  vision  is  to  ”increase 
maritime  information  sharing  to  improve  situational  awareness  and  foster 
partnerships worldwide”. 

5.2.2  Definition of SeaVision 

SeaVision  Project  Description  for  release  2.0  [38],  which  was  shared  by  US  DoD, 
provides an overview of the tool. 

SeaVision  is  an  internet  based  application  that  provides  users  with  an 
unclassified  information  sharing,  visualization  and  analytical  capability. 
SeaVision automates the collection of maritime data from a variety of sources 
and  applies  that  data  against  user  defined  business  rules.  The  data  and  rule 
results are available to a global, authorized user community. 

Functionally,  SeaVision  is  made  up  of  three core  parts: Common Maritime  Picture, 
Analytics, and Administration. 

•  Common  Maritime  Picture  (CMP):  A  Google  Maps  based  geospatial 
visualization  of  near  real-time  maritime  information  and  analytical  results.  
Includes settings and functions that enables a user configurable CMP. 

21/06/2018 

Page 39 of 54 

 
 
 
 
 
 
 
 
 
 
•  Analytics: Search and automated rules based computations applied against 
near  real-time  and  historical  data.  Includes  user  defined  and  adjustable 
parameters. 

•  Administration:  User  and  data  management  functions.    Management  of 
Communities,  Personas  and  users  to  include  the  access  authorization  to 
appropriate data sets. 

5.2.3  Guiding principles 

No specific guiding principles have been found. 

5.2.4  Value proposition 

According  to  a  SeaVision’s  available  documents,  the  value  proposition  of  the  tool 
resides in the following aspects. 

•  Low cost, internet delivered information visualization and management tool 

•  Standardized attribute based access controls for managing user content 

•  The ability to quickly add and provide new data sources 

5.2.5  Customer segments 

SeaVision’s initial customer segments were members of the MSSIS network, a wide 
array of stakeholders active in maritime security and surveillance. 

Customers have expanded to include the US Navy MOCs and their mission partners.  
US  mission  partners  who  are  “without  resources  to  fund  themselves  (e.g.,  African 
partners in Nigeria, Morocco, and Senegal)” are often funded by the Numbered Fleet 
Commander/Naval  Component  Commander.  Non-governmental  organizations 
(NGOs) and U.S. partner nations who do not have access to traditional, closed US 
DoD networks are also a part of the expanded customer segments with appropriate 
data restrictions. 

As the future plan of SeaVision is to become part of a DoD Program of Record, the 
future customer segments will include the platform’s broader set of users. 

5.3  Development strategy of SeaVision 

The  following  paragraphs  focus  on  SeaVision  and  give  an  overview  of  the  project 
activities, current status and way forward as provided by US Navy. 

5.3.1  Scope, in terms of countries, agencies, and information services 

SeaVision’s scope in terms of countries. 

•  Target: SeaVision was originally foreseen for use by NAVAF/NAVEUR for use 

with their international partners for partnership building. 

21/06/2018 

Page 40 of 54 

 
 
 
 
 
 
 
 
 
•  Actual:  US  Government  (US  Navy),  over  60  US  partner  nations,  other 

government and non-government organizations. 

In  terms  of  information  services,  SeaVision  provides  information  on  the  following 
topics mostly via its web-interface. 

•  Vessel information e.g. Port History & Facilities, Ownership, Cargo & Crew. 

•  Vessel position, with historical track data from a variety of data sources (AIS, 

Radar, Imagery)  

5.3.2  Overall design, development, test and roll-out 

Roll-out of 2.0 was completed in 2017 and included the following: 

•  US Fleet Forces, East Pacific (3rd Fleet), South Atlantic (4th Fleet), Middle East 
(5th  Fleet),  Europe-Africa  (6th  Fleet),  West  Pacific  (7th  Fleet),  Pacific  Fleet 
(PACFL) 

•  Delivered Community Manger training for partnership communities (Europe-

Asia, and Pacific region) 

•  User training of partnership building communities are funded separately. 

•  Transition all SeaVision V1.0 users by end fiscal-year 2017. 

Following 2.0 roll out, delivery of new functionality based on US Navy requirements 
will occur incrementally (2.1, 2.2, 2.3, etc.) and every 90 days. SeaVision 3.0 will be 
delivered January 2019. 

5.3.3  Constraints: legal/regulatory environment, resources, time and cost 

Data  contracts  are  negotiated  to  allow  for  maximum  flexibility.  The  Navy  has  the 
right  to  share  such  commercial  data  products  per  restrictions  outlined  in  the  data 
contract. SeaVision provides the US Navy community access to commercial data but 
also provides metrics regarding usage in order to comply with the contracts [37].  

The main constraints that have impacted the development of SeaVision:  

•  Enhanced  analytics,  which  required  the  development  of  a  centralised  data 

repository. 

•  Having  limited  control  on  the  incoming  data  formats,  which  required  the 

development of ad-hoc interfaces. 

•  Having  to  comply  with  information  sharing  requirements,  which  required  to 

expose APIs [37]. 

5.4  Key findings 

Main evolution milestones 

•  SeaVision  was  developed  initially  by  US  DOT  Volpe  Center  as  a  web-based 
visualisation  tool  for  the  MSSIS  network.  When  US.  Naval  Forces  Africa 

21/06/2018 

Page 41 of 54 

 
 
 
 
 
 
 
 
 
• 

• 

(NAVAF) saw its progress, they provided funds to advance the technology and 
further develop the tool. 

In  2015,  SeaVision  was  selected  as  the  near-term  solution  to  satisfy  the 
Navy’s  requirements  for  enterprise  access  to  maritime  data,  automated 
analytics and information sharing capabilities to support operational level MDA 
in an Unclassified/Non-PKI environment. 

In  2017,  SeaVision  was  equipped  with  advanced  data  management  and 
sharing features implementing concepts of the National MDA Architecture Plan 
and  MISE  (NIEM  data  model,  attribute-based  access  control).  During  an 
information sharing exercise (Bold Quest) SeaVision sent NIEM data to UK’s 
command and control system. 

•  The long-term strategy of SeaVision is to transition its functionality into a DoD 
program  of  record  (POR)  to  provide  an  enterprise  unclassified  information 
sharing platform. 

Vision, principles, value proposition 

•  SeaVision’s vision and inspiring principles are not clearly listed in the reviewed 

documentation. 

•  SeaVision’s value proposition is aligned with both the overall vision regarding 
MDA and MISE’s own value proposition. SeaVision’s value can be summarised 
in cost-effectiveness, interoperability, user-convenience, privacy and security. 

Countries 

•  Target: SeaVision was originally foreseen for use by NAVAF/NAVEUR for use 

with their international partners for partnership building. 

•  Actual:  US  Government  (US  Navy),  over  60  US  partner  nations,  other 

government and non-government organizations. 

Sectors (user communities) 

•  SeaVision  user  communities  include  various  US  Government  entities  and 

partner nations. 

•  The main focus is towards the US government and enhancing ability to share 

maritime information with partner nations. 

Political and regulatory support 

•  Within  the  US  Navy’s  Fleet  Forces,  SeaVision  has  been  identified  as  the 
solution satisfying specific requirements of non-classified information sharing 
with international partner nations. 

21/06/2018 

Page 42 of 54 

 
 
 
 
 
 
 
 
 
 
 
6  OVERALL ARCHITECTURAL APPROACH 

This section presents the overall architectural approach of the SeaVision, beginning 
with the requirements, use cases and SeaVision’s high-level IT architecture. 

6.1  Requirements 

SeaVision’s latest top-level requirements came from the US Fleet Forces Command 
(US Navy) and are summarised below, as found in [34]: 

•  Access to Non-Public Key Infrastructure environment, with the purpose 
of  “providing  an  enterprise-wide  Non-CLAS  low  bandwidth  environment  to 
low-end users without resources to fund themselves (e.g., African partners in 
Nigeria,  Morocco,  Senegal).  Access  to  this  environment  shall  increase  our 
mission  partners'  situational  awareness  (e.g.,  port  arrivals/departures, 
suspicious activity, vessel movement/identification) and foster collaboration. 

•  Access to data / data feeds, “to include, but not be limited to Global, Space 
&  Terrestrial  Automatic  Identification  System  (AIS),  commercial  radar 
satellite,  and  other  open  source  commercial  sites  (e.g.,  Lloyds  of  London, 
Journal  of  Commerce,  GCaptain.com) 
that  provide:  ship  position, 
characteristics,  movement,  history,  identification,  ownership,  cargo,  crew, 
imagery,  port  facilities  and  economic  trends  within  a  designated  Area  of 
Responsibility (AOR).” 

•  Analysis  capability,  that  “includes  providing  the  ability  to  develop  a 
standardized set of user-defined queries and include automated business rules 
to  integrate  and  correlate  data  necessary  to  conduct  risk  assessments, 
highlight anomalies, generate alerts and warnings that will assist in identifying 
potential threats and automatically notify users vice requiring analysts to pull 
assessment data from the system.” 

•  Information  sharing  capability  “for  automated  two-way  sharing  of 
information (e.g., text, imagery, queries, etc.) with mission partners on a one-
to-one  or  a  one-to-many  basis,  to  enable  collaboration  in  support  of 
Combatant  Commander  (CCDR)  TSC  Plans.  Additionally,  mission  partners 
should be able to contribute their own agreed sets of data (e.g. coastal radar 
tracks) in a standardized format to the information sharing environment.” 

•  Common maritime picture “for data to be made available for display, which 
includes presentation in a common maritime picture (CMP) on a geographic 
presentation.  The  data  should  also  allow  for  generation  of  a  user-defined 
operational picture.” 

These  top-level  requirements  were  then  decomposed  into  functional  and  system 
requirements, as in the System Requirement Specification document [39]. 

21/06/2018 

Page 43 of 54 

 
 
 
 
 
 
 
 
 
6.2  Use cases 

No  explicit  reference  is  made  to  use  cases  in  the  documentation  from  a  business 
perspective,  although  they  are  implied  in  the  SRS  document,  which  provides 
information on how the system can be used.  

Use  cases  for  each  of  the  requirements  are  developed  and  vetted  through 
requirements  owners.    Development  teams  leverage  approved  use  cases  to 
determine best implementation approach. 

6.3  Solution architecture and architectural elements 

No information was found on the high-level architecture of SeaVision.  

According to interviewees, SeaVision implements a centralised multi-tier architecture 
that is usually found in modern web-based applications. The main building blocks can 
be organised conceptually into layers as follows. 

•  Presentation layer, a HTML-based graphical user interface. 

•  Application layer, which includes the core elements of SeaVision implemented 

as loosely-coupled modules. 

•  Application Programming Interfaces, which are exposed by the data layer. 

•  Data  layer, which  contains  information  about  users,  alerts,  rules, warnings, 

lists, shapes, tracks, etc. 

Ad-hoc  interfaces  for  data  ingestion  from  external  sources  to  the  data  layer  were 
developed according to specification of each source. 

SeaVision is currently in the process of implementing the service interfaces described 
in the MDA Architecture Plan for data publishing. The actual interfaces will differ from 
the ones described in the MDA Architecture Plan, because SeaVision’s requirements 
are different and include sharing analytics-related information. 

According to our interviewees, this centralised mode of operation was a first step as 
a result of having a limited team with limited resources. 

6.4  Technical solution 

6.4.1  Data model 

As of version 2.0, SeaVision uses an ad-hoc internal data model.  With AIS being the 
primary source of vessel position data, the international data standard for AIS data, 
NMEA 0183, will continue to be supported as an input format for SeaVision. However, 
SeaVision will adopt and implement NIEM’s IEPDs or BIECs, and also plans to publish 
data using NIEM-M.  

NIEM  and  the  MDA  Architecture  Plan  are  mentioned  several  times  in  the  System 
Requirement Specifications document. 

21/06/2018 

Page 44 of 54 

 
 
 
 
 
 
 
 
 
As  SeaVision  and  community  partners  mature,  data  management  and  user 
attributes  will  migrate  towards  those  defined  in  the  National  MDA 
Architecture Plan. Data products published to or consumed from the MISE 
will comply with the Architecture Plan.  

Where possible, the abstracted data layer will reflect a data structure defined 
in a NIEM Maritime Information Exchange Package Document (IEPD) or 
Basic Information Exchange Component (BIEC).  

Common data exchange models will be defined and used. SeaVision will adopt 
and  implement  maritime  exchange  models  and  processes  outline  in  the 
National MDA Architecture Plan and the National Information Exchange 
Model (NIEM)-Maritime. 

SeaVision will publish and consume data using structured information formats. 
Initial formats include NMEA 0183 (AIS & radar targets), XML (NIEM CVISR 
and commercial data) and bulk SQL data exports. 

According to US interagency representatives, APIs will be setup to publish position 
reports  in  NIEM-M  format.  Moreover,  some  analytical  data  will  be  exposed  using 
NIEM-M, for which new IEPDs will be developed. 

6.4.2  Main technical solution(s) adopted to facilitate the implementation 

of the selected architecture 

The  technical  architecture  of  the  SeaVision  consists  of  several  building  blocks 
implemented on Amazon Web Services, as showed in the picture below.  

Figure 10. SeaVision high-level IT architecture 

21/06/2018 

Page 45 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
Figure 11. SeaVision deployment scheme on AWS 

In detail: 

•  Data  ingest  takes  care  of  fetching  data  from  external  data  sources  into 

SeaVision’s database. 

•  Database  is  a  group  of  databases  implemented  on  Amazon  Relational 

Database Services. 

•  Servers  is  a  group  of  Amazon  EC2  instances  that  provide  the  software 

environment and computing power. 

•  Redis is a caching mechanism for storing user authentication tokens and is 

implemented on Amazon Elastic Cache. 

•  Google maps API and User interact with the above mentioned elements via 

web browser (see picture below) 

21/06/2018 

Page 46 of 54 

 
 
 
 
 
 
 
 
 
 
Figure 12. SeaVision user interface 

6.5  Key findings 

Solution architecture approach 

•  SeaVision’s architecture is typical of a multi-tier web-based application. 

•  SeaVision only supports caching in a single central database. This is done for 

operational purpose to support its analytical features.  

Main building blocks 

•  SeaVisions’s  main  building  blocks  can  be  organised  conceptually  into  layers 

as follows. 

•  Presentation layer, a HTML-based graphical user interface. 

•  Application layer, which includes the core elements of SeaVision implemented 

as loosely-coupled modules. 

•  Application Programming Interfaces, which are exposed by the data layer. 

•  Data  layer, which  contains  information  about  users,  alerts,  rules, warnings, 

lists, shapes, tracks, etc. 

Data model 

• 

Internally, SeaVision uses a custom data model. 

•  SeaVision uses NIEM-M data model only for publishing vessel position to other 

systems. 

• 

In  the  future,  new  IEPDs  will  be  developed  to  meet  the  requirements  of 
sharing analytics-related information. 

21/06/2018 

Page 47 of 54 

 
 
 
 
 
 
 
 
 
 
 
Service model 

•  SeaVision  is  currently  in  the  process  of  implementing  the  service  interfaces 
described  in  the  MDA  Architecture  Plan  for  data  publishing.  The  actual 
interfaces  will  differ  from  the  ones  described  in  the  MDA  Architecture  Plan, 
because SeaVision’s requirements are different and include sharing analytics-
related information. 

•  Besides vessel position, all the information that SeaVision stores is available 
via its web interface only. Exporting functionality of Vessel Positions, Vessel 
Information, Vessel Lists, Rule Results, and Alert Results in various formats is 
available via the web interface. 

21/06/2018 

Page 48 of 54 

 
 
 
 
 
 
 
 
 
 
7  GOVERNANCE AND ORGANISATION STRUCTURE 

7.1  Strategic governance and oversight 

The current governance structure of the SeaVision project, as described in the Project 
Description  document,  involves  OPNAV  N2/N6I  (for  strategic  oversight  and 
programme  management),  COMUSFLTFORCOM  (for  requirements  management), 
SPAWAR  DESC  (for  development  and  integration)  coordinating  DoT  Volpe  Centre 
(CMP,  administration,  hosting,  infrastructure,  databases,  APIs)  and  SPAWAR  SSC 
PAC (analytics, notifications, data export). 

Comparing this with MISE’s governance structure, the MISE Management would be 
played today by SPAWAR DESC and the Commander of US Fleet Forces, while the 
Configuration Control Board would be N2N6. 

Requirement  Management:  The  OPR  will  work  directly  with  COMUSFLTFORCOM  as 
the single voice for providing requirements from the Fleet leading up to FOC. There 
will be regularly scheduled user juries and peer reviews for the MOCs as additional 
capabilities and functionality are incorporated. Additionally, there will be an annual 
community-wide review of SeaVision. 

Regarding  requirements  management  and  gathering  feedback  from  users,  our 
interviewees shared that getting quicker feedback is something they are working on, 
as the annual review cycle with the Navy requirements owners is rather slow. 

7.2  IT service governance 

No specific information was found. 

7.3  Information governance 

The  development  teams  at  DoT  Volpe  Center  and  SPAWAR  System  Center  Pacific 
manage data sources in collaboration with data providers. [37]. 

7.4  Information security 

Data  access  policies  will  be  defined  per  personas  and  enforced  per  record  by  the 
Administrators, following the attribute-based approach in the MDA Architecture Plan. 

However, the Trust Fabric described for the MISE will not be implemented. 

Internally  the  implementation  of  data  attributes  deviated  from  the  approach 
described  in  the  MDA  Architecture  plan  in  order  to  allow  finer  control  of  the 
contractual requirements for purchased data [37]. 

21/06/2018 

Page 49 of 54 

 
 
 
 
 
 
 
 
 
7.5  Key findings 

Strategic and operational governance (incl. SLAs) 

•  Most roles of SeaVision’s governance are held by US DoD / Navy as the Office 

of Primary Responsibility (OPR).  

•  Requirement management process follows the standard procedure within US 

Navy. This is done through an annual feedback gathering procedure. 

•  Governance approach of SeaVision is different than the one foreseen in MISE. 
However, SeaVision team is working for including the voice of the user more 
rapidly in the feedback process. 

•  No  specific  information  was  found  on  SLAs  nor  on  how  IT  services  are 

managed. 

IT Service Management and Information Security 

• 

Information  Security  is  enforced  per  record,  following  the  attribute-based 
approach in the MDA Architecture Plan and MISE. 

•  The Trust Fabric described for the MISE will not be implemented. 

21/06/2018 

Page 50 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
8  REFERENCES 

[1]  

United States: The White House Office, “Homeland Security Presidential Directive 13: 
Maritime  Security 
[Online].  Available: 
21  December 
https://www.hsdl.org/?view&did=470301. [Accessed 06 June 2017]. 

Policy,” 

2014. 

[2]  

J. Kraska, Maritime power and the law of the sea: expeditionary operations in world 
politics, New York: Oxford University Press, 2011.  

[3]  

[4]  

[5]  

US Department of Defense, Department of Homeland Security, “National Strategy for 
Maritime 
Available: 
2005. 
https://www.state.gov/documents/organization/255380.pdf. 

Security,” 

[Online]. 

Department  of  Homeland  Security,  “National  Plan  to  Achieve  Maritime  Domain 
Awareness,” 
Available: 
2005. 
https://www.dhs.gov/sites/default/files/publications/HSPD_MDAPlan_0.pdf. 
[Accessed 06 September 2017]. 

[Online]. 

October 

NIEM, 
niem/history. [Accessed 06 Sepetember 2017]. 

“NIEM’s  History,” 

[Online].  Available:  https://www.niem.gov/about-

[6]  

US  Department  of  Justice,  “Global  Justice  XML  (Archive),”  [Online].  Available: 
https://it.ojp.gov/initiatives/gjxdm. 

[7]  

“National Concept of Operations for Maritime Domain Awareness,” December 2007. 
Available: 
[Online]. 
https://www.ise.gov/sites/default/files/National%20MDA%20CONOPS%202007.pdf. 
[Accessed 06 Sepetmber 2017]. 

[8]   MDA Architecture Management Hub, “National MDA Architecture Plan Brief,” [Online]. 

Available: 
https://web.archive.org/web/20170125032020/https://mise.mda.gov/drupal/sites/d
efault/files/AMH_Default%20Brief_V4_0.pdf. [Accessed 06 September 2016]. 

[9]  

K. L. J. Caswell, “Establishment of the national Maritime Intelligence Center,” March 
2010. [Online]. Available: http://www.dtic.mil/dtic/tr/fulltext/u2/a518529.pdf. 

[10]   NIEM,  “Release  2.1,”  [Online].  Available:  https://release.niem.gov/niem/2.1/. 

[Accessed 06 September 2017]. 

[11]   Office  of  the  Chief  Information  Officer,  “Maritime  Domain  Awareness  Architecture 
Available: 
Management  Hub 
https://mise.mda.gov/drupal/sites/default/files/MDA_Arch_Plan_V_2.0_Release2_Fu
ll_1.pdf. [Accessed 06 September 2017]. 

[Online]. 

January 

V1.2,” 

2009. 

Plan 

[12]   Federal CIO Council, “Agency Information Exchange Functional Standards Evaluation,” 
https://cio.gov/wp-

Available: 

2010. 

June 
content/uploads/downloads/2012/09/3.12.1-NIEM-Assessment-
Report_Final_Master.pdf. [Accessed 06 September 2017]. 

[Online]. 

21/06/2018 

Page 51 of 54 

 
 
 
 
 
 
 
 
 
 
[13]   US Government, “National Maritime Intelligence-Integration Office (NMIO) website,” 

[Online]. Available: http://nmio.ise.gov/. 

[14]  

ISE,  “Annual  Report  to  the  Congress,”  30  June  2013.  [Online].  Available: 
https://www.ise.gov/sites/default/files/2013_ISE_Annual_Report_Final.pdf. 
[Accessed 07 September 2017]. 

[15]   US DoD, DHS, “National Maritime Domain Awareness Plan for the National Strategy 
Available: 

December 

[Online]. 

Maritime 

2013. 

for 
https://www.hsdl.org/?view&did=747691. 

Security,” 

[16]   MISE,  “Home,”  [Online].  Available:  https://mise.mda.gov/drupal/.  [Accessed  06 

September 2017]. 

[17]   US DoD, “Aoption of the National Information Exhcnage Model within the Department 
Available: 

of 
http://www.eic.org/docs/NIEM_adoption_within_dod_2013-03-28.pdf. 

Defense,” 

[Online]. 

March 

2013. 

28 

[18]   DOT Volpe Center, “Annual Project Accomplishments 2017,” January 2017. [Online].  

[19]   MISE,  “National  MDA  Architecture  Plan,”  February  2016.  [Online].  Available: 
[Accessed 

https://mise.mda.gov/drupal/sites/default/files/NMDAAP_Feb_2016.pdf. 
2016 September 06]. 

[20]   National Maritime Intelligence-Integration Office, “Annual report 2016,” 31 December 
Available: 

2016. 
[Online]. 
http://nmio.ise.gov/Portals/16/Docs/UNCLAS_2016_Annual_Report.pdf?ver=2017-
07-10-115225-223. [Accessed 06 September 2017]. 

[21]   Executive  Office  of  the  President  of  the  United  States,  Arctic  Executive  Steering 
Committee,  “Implementation  Framework  for  the  National  Strategfy  for  the  Arctic 
Available: 
Region,” 
https://obamawhitehouse.archives.gov/sites/whitehouse.gov/files/documents/Natio
nal%20Strategy%20for%20the%20Arctic%20Region%20Implementation%20Frame
work%20(Appendix%20A)%20Final.pdf. 

[Online]. 

March 

2016. 

[22]   The  White  House  Office,  “National  Strategy 

for  Information  Sharing  and 
Safeguarding,” 
Available: 
https://www.ise.gov/sites/default/files/2012infosharingstrategy.pdf.  [Accessed  06 
September 2017]. 

December 

[Online]. 

2012. 

[23]   MISE, “National MDA Architecture Plan: Appendix F - Governance manual,” February 
2015. 
Available: 
https://mise.mda.gov/drupal/sites/default/files/MDA_Arch_Plan_V_3.0_Appendix%2
0F.pdf. [Accessed 06 September 2017]. 

[Online]. 

[24]   MISE, “Maritime IEPDS,” [Online]. Available: https://mise.mda.gov/drupal/node/42. 

[Accessed 08 September 2017]. 

[25]   MISE, “NIEM - Maritime Exchange Model Summary: Position,” January 2015. [Online]. 

Available: 

21/06/2018 

Page 52 of 54 

 
 
 
 
 
 
 
 
 
https://mise.mda.gov/drupal/sites/default/files/POS%20Exchange%20Model_V1.0.p
df#overlay-context=node/78. [Accessed 08 September 2017]. 

[26]   MISE,  “NIEM  -  Maritime  Exchange  Model  Summary:  Indicators  and  Notifications,” 
January 
Available: 
https://mise.mda.gov/drupal/sites/default/files/IAN%20Exchange%20Model_V1.0_0
.pdf#overlay-context=node/78. [Accessed 08 September 2017]. 

[Online]. 

2015. 

[27]   MISE, “NIEM - Maritime Exchange Model Summary: Notice of Arrival,” January 2015. 
Available: 

[Online]. 
https://mise.mda.gov/drupal/sites/default/files/NOA%20Exchange%20Model_V1.0.
pdf#overlay-context=node/78. [Accessed 08 September 2017]. 

[28]   MISE,  “NIEM  -  Maritime  Exchange  Model  Summary:  Vessel  Information,”  January 
Available: 

2015. 
https://mise.mda.gov/drupal/sites/default/files/VINFO%20Exchange%20Model_V1.
0.pdf#overlay-context=node/78. [Accessed 08 September 2017]. 

[Online]. 

[29]   MISE, “NIEM - Maritime Exchange Model Summary: Consolidated Vessel Information 
Available: 
January 
and 
https://mise.mda.gov/drupal/sites/default/files/CVISR%20Exchange%20Model_V1.0
_0.pdf#overlay-context=node/78. [Accessed 08 September 2017]. 

Reporting,” 

[Online]. 

Security 

2015. 

[30]   GAO - United States Government Accountability Office, “Intelligence, surveillance, and 
reconnaissance - DOD needs a strategic, risk-based approach to enhance its Maritim 
Domain 
Available: 
http://www.gao.gov/assets/320/319811.pdf. [Accessed 23 November 2017]. 

Awareness,” 

[Online]. 

2011. 

June 

[31]   MDA  ESC,  “Charter  for  the  NIEM  Maritime  Domain  (NIEM-M),”  December  2014. 
[Online]. 
https://mise.mda.gov/drupal/sites/default/files/NIEM-
M%20Charter_Stewardship%20Agreement_FINAL.pdf.  [Accessed  08  September 
2017]. 

Available: 

[32]   US Naval Forces Commander Sixth Fleet, “Maritime Domain Awareness Perspectives, 
Available: 

Mediterranean 
https://community.apan.org/cfs-file/__key/telligent-evolution-components-
attachments/13-7124-00-00-00-09-94-46/Malta_5F00_brief_5F00_rev1.ppt. 

[Online]. 

Security 

January 

2012,” 

2012. 

[33]   DoT Volpe Center news, “SeaVision Improves Africa's Maritime Picture,” 30 January 
Available: 

2013. 
https://web.archive.org/web/20161102220002/https://www.volpe.dot.gov/news/se
avision-improves-africas-maritime-picture. 

[Online]. 

[34]   Departement  of  the  Navy,  Commander,  U.S.  Fleet  Forces  Command,  “Operational 
level  unclassified/non-public  key  vinfrastructure  (Non-PKI)  maritime  domain 
awareness (MDA) requirements,” 3 November 2014. [Online].  

[35]   Oceanographer and Navigator of the Navy (OPNAV N2/N6E), “Unclassified/Non-Public 
Key Infrastructure (NON-PLI) Maritime Domain Awareness (MDA) Information Sharing 
Way Forward,” 23 September 2015. [Online].  

[36]   D.  V.  Center,  “Annual  Project  Accomplishments  2016,”  January  2016.  [Online]. 

Available: 

21/06/2018 

Page 53 of 54 

 
 
 
 
 
 
 
 
 
https://ntl.bts.gov/lib/56000/56800/56847/Annual_Project_Accomplishments_Jan20
16.pdf. 

[37]   US Interagency representatives, Interviewees, US Govt.. [Interview]. 10 July 2017. 

[38]   US  Department  of  Transportation,  “SeaVision  Project  Description,  Release  2.0,” 

December 2015. [Online].  

[39]   Department of Transportation, “SeaVision, System Requirements Specification (SRS), 

SeaVision Release 2.0, SRS version 2.0,” February 2016. [Online].  

[40]   MISE,  “NIEM  -  Maritime,”  [Online].  Available:  https://mise.mda.gov/drupal/niem-

maritime. [Accessed 08 September 2017]. 

[41]   Niem,  “About  Niem,”  [Online].  Available:  https://www.niem.gov/.  [Accessed  08 

September 2017]. 

[42]   National  Maritime  Intelligence-Integration  office  (NMIO),  [Online].  Available: 

http://nmio.ise.gov/. [Accessed 23 November 2017]. 

21/06/2018 

Page 54 of 54 

 
 
 
 
 
 
 
 
 
 
 
 
 
SC430DI07171 

D2.5.3 Structured report on SESAR (SWIM) 

Date: 21/06/2018 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Document Metadata 

Property 

Value 

Date 

Status 

21/06/2018 

Approved 

Version 

1.00 

Authors 

Reviewed by 

Andrea Marcato – PwC EU Services 
Lora Van Looveren – PwC EU Services 
Max Stahlecker – PwC EU Services 
Alexandru Chiric – DG MARE 
David Berger – JRC 
Jesus Hermida - JRC 

Approved by  

Alexandru Chiric – DG MARE 

This study was prepared for the ISA Programme by: 

PwC EU Services 

Disclaimer: 

The views expressed in this report are purely those of the authors and may not, in 
any circumstances, be interpreted as stating an official position of the European 
Commission. 

The  European  Commission  does  not  guarantee  the  accuracy  of  the  information 
included in this study, nor does it accept any responsibility for any use thereof. 

Reference  herein  to  any  specific  products,  specifications,  process,  or  service  by 
trade  name,  trademark,  manufacturer,  or  otherwise,  does  not  necessarily 
constitute  or  imply  its  endorsement,  recommendation,  or  favouring  by  the 
European Commission. 

All  care  has  been  taken  by  the  author  to  ensure  that  s/he  has  obtained,  where 
necessary,  permission  to  use  any  parts  of  manuscripts  including  illustrations, 
maps,  and  graphs,  on  which  intellectual  property  rights  already  exist  from  the 
titular holder(s) of such rights or from her/his or their legal representative. 

21/06/2018 

Page 2 of 76 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 

2 

1.1 
1.2 

2.1 

2.1.1 

2.2 

2.2.1 
2.2.2 
2.2.3 
2.2.4 
2.2.5 

2.3 

2.3.1 
2.3.2 
2.3.3 
2.3.4 

3 

2.4 

3.1 
3.2 
3.3 

3.3.1 
3.3.2 

3.4 

D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Table of Contents 

INTRODUCTION ........................................................................................................... 7 

PURPOSE OF THIS DOCUMENT ...................................................................................................... 7 
STRUCTURE OF THIS DOCUMENT ................................................................................................... 7 

VISION AND APPLIED DEVELOPMENT STRATEGY .......................................................... 8 

VISION AND BUSINESS STRATEGY ................................................................................................... 8 
Strategy definition process: the evolution of SESAR ............................................................. 8 
VISION AND MISSION STATEMENT, UNDERLYING VALUES, GOALS AND OBJECTIVES ................................. 16 
Vision .................................................................................................................................. 16 
Definition ............................................................................................................................ 18 
Guiding principles ............................................................................................................... 18 
Value proposition ................................................................................................................ 19 
Customer segments and stakeholders ................................................................................ 20 
DEVELOPMENT STRATEGY .......................................................................................................... 21 
Scope, in terms of countries, agencies, and information services ...................................... 21 
Overall design, development, test and roll-out .................................................................. 22 
Project management aspects ............................................................................................. 27 
Constraints: legal/regulatory environment, resources, time and cost ............................... 28 
KEY FINDINGS ......................................................................................................................... 29 

OVERALL TECHNICAL ARCHITECTURE AND DESIGN ...................................................... 32 

REQUIREMENTS ....................................................................................................................... 32 
USE CASES .............................................................................................................................. 33 
ARCHITECTURAL ELEMENTS ........................................................................................................ 35 
Key building blocks ............................................................................................................. 35 
Communication patterns .................................................................................................... 43 
TECHNICAL SOLUTION ............................................................................................................... 44 
Data model ......................................................................................................................... 44 
Service model ...................................................................................................................... 46 

3.4.1 
3.4.2 
3.4.3  Main technical solution(s) adopted to facilitate the implementation of the selected 

4 

3.5 

4.1 

4.1.1 
4.1.2 
4.1.3 

4.2 
4.3 
4.4 

architecture ........................................................................................................................ 47 
KEY FINDINGS ......................................................................................................................... 49 

GOVERNANCE AND ORGANISATION STRUCTURE ......................................................... 52 

STRATEGIC GOVERNANCE AND OVERSIGHT .................................................................................... 52 
Governance of SESAR .......................................................................................................... 52 
Governance of SWIM .......................................................................................................... 55 
Deployment status of the PCP – SWIM Governance deployment action plan .................... 65 
IT SERVICE GOVERNANCE ........................................................................................................... 68 
INFORMATION SECURITY / CYBERSECURITY ................................................................................... 68 
KEY FINDINGS ......................................................................................................................... 70 

5 

REFERENCES ............................................................................................................... 72 

List of Figures 

Figure 1. PCP implementation status ......................................................................................................... 15 

21/06/2018 

Page 3 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 2. Initial SWIM implementation status and expected roadmap ...................................................... 16 

Figure 3. SES vision offering improvements at every stage of the flight .................................................... 17 

Figure 4: Information sharing with and without SWIM [19] ...................................................................... 18 

Figure 5. SWIM high-level roles .................................................................................................................. 21 

Figure 6: Phases of SESAR [25] ................................................................................................................... 22 

Figure 7. SESAR innovation lifecycle. Source: SESAR JU [22] ...................................................................... 22 

Figure 8. SESAR Maturity Phases (TRL vs. E-OCVM) ................................................................................... 24 

Figure 9: Activities and steps involved the SESAR 2020 programme ......................................................... 27 

Figure 10: Clusters of Project Management Activities  [27] ....................................................................... 28 

Figure 11. SWIM use cases, part 1 .............................................................................................................. 33 

Figure 12. SWIM use cases, part 2 .............................................................................................................. 34 

Figure 13. High-level SWIM-TI architecture from SWIM ConOps ............................................................... 36 

Figure 14: SWIM-TI Functional Breakdown ................................................................................................ 37 

Figure 15: SWIM-TI Technical Architecture View ....................................................................................... 40 

Figure 16. SWIM-TI and different SWIM-TI Functional Block deployment options ................................... 43 

Figure 17. Structure of AIRM ...................................................................................................................... 45 

Figure 18. SWIM-TI Architecture - Logical entities vs deployment boundaries ......................................... 47 

Figure 19. SWIM-TI Yellow Profile standardised interface bindings .......................................................... 48 

Figure 21. SESAR deployment governance. Source: EC .............................................................................. 55 

Figure 22: SWIM proposed governance structure ..................................................................................... 58 

Figure 23: IM Functions .............................................................................................................................. 63 

Figure 24. SWIM Trust Framework for Common PKI ................................................................................. 70 

21/06/2018 

Page 4 of 76 

 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Acronym 

Meaning 

List of abbreviations 

SES 

ATM 

SESAR 

SJU 

SWIM 

PCP 

EC 

WP 

Single European Sky 

Air Traffic Management 

Single European Sky ATM Research 

SESAR Joint Undertaking 

System-Wide Information Sharing 

Pilot Common Project 

European Commission 

Work Package 

DM, SDM 

SESAR Deployment Manager 

EU 

European Union 

SWIM-TI 

SWIM Technical Infrastructure 

PCP 

Pilot Common Project 

iSWIM 

Initial SWIM 

PKI 

QoS 

SLA 

ATC 

R&I  

PPP 

VLD 

TRL 

STI 

PDP 

DP 

CEF 

EDA 

ISRM 

AIRM 

21/06/2018 

Public Key Infrastructure 

Quality of Service 

Service Level Agreement 

Air Traffic Control 

Research & Innovation 

Public Private Partnership 

Very Large Demonstration 

Technology Readiness Level 

Security Token Infrastructure 

Preliminary Deployment Programme 

Deployment Programme 

Connecting Europe Facility 

European Defence Agency 

Information Service Reference Model 

ATM Information Reference Model 

Page 5 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

ANSP 

ICAO 

Air Navigation Service Providers 

International Civil Aviation Organisation 

E-OVCM 

European Operational Concept Validation Methodology 

TEN-T 

Trans-European Transport Networks in Europe 

FB 

LS 

Functional Block 

Legacy System 

21/06/2018 

Page 6 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

1 

INTRODUCTION 

1.1  Purpose of this document 

This  document  provides  an  overview  of  Single  European  Sky  ATM  Research 
(SESAR) project with particular focus on its infrastructure component, the System-
Wide Information Management (SWIM). The information has been gathered via 
desk  research  work  on  publicly  available  documentation  and  via  meetings  with 
representatives from the European Commission and SESAR Deployment Manager.  

1.2  Structure of this document 

This document is structured as follows. 

•  Section 1 introduces this document and provides its structure. 

• 

In section 2, the vision and the applied development strategy of SESAR and 
SWIM are outlined, with focus on the guiding principles, goals and objectives, 
scope and strategy development and deployment.  

•  Section 3 provides the overall IT architectural approach of SWIM Technical 
Infrastructure, including mention to architectural building blocks, data model 
and information services. 

•  Section 4 includes the governance and the organisation structures in place 

for driving SESAR and particularly SWIM deployment and operations. 

Finally, within each of these sections, the interoperability aspects are analysed.  

21/06/2018 

Page 7 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

2  VISION AND APPLIED DEVELOPMENT STRATEGY 

2.1  Vision and business strategy 

2.1.1  Strategy definition process: the evolution of SESAR 

The  paragraphs  below  give  a  high-level  overview  of  the  policy  roots,  strategic 
decision and key events that influenced the birth of SESAR from 2004.  

2000 

•  The  European  Commission’s  Single  European  Sky  (SES)  initiative  was 
launched  with  the  objective  of  reforming  Air  Traffic  Management  (ATM)1  in 
Europe in order to cope with sustained air traffic growth in the busy European 
skies [1]. For this purpose, SES initiative adopted a legislative approach at a 
European rather than at local level [2]. 

2004:  

•  European Parliament and Council adopted the first set of SES legislation, also 

known as the SES package [13].  

• 

In  order  to  ensure  that  the  Single  European  Sky  is  an  airspace  without 
frontiers, the Commission proposed in the Regulation (EC) 551/2004 on the 
organisation and management of airspace to set up a unique flight information 
region  by  merging  all  the  national  regions  into  a  single  portion  of  airspace 
within which air traffic services will be provided according to the same rules 
and procedures.  

•  The  Single  European  Sky  ATM  Research  (SESAR)  programme  was 
launched  as  the  technological  pillar  of  SES.  The  scope  of  SESAR  is  the 
innovative 
definition,  development,  validation  and  deployment  of 
technological and operational ATM solutions. The project was structured under 
three phases2: 

o  Definition phase (2005-2008), having among its objectives to establish 
a  detailed  and  phased  development,  implementation,  validation  and 
deployment plan (the SESAR Master Plan)  

o  Development phase (2008-2024), having as objectives: exploring and 
developing  new  operational  and  technology  solutions;  validating  and 
demonstrating benefits in real-operational environments; delivering a 
catalogue of solutions. 

1 Air traffic management is about the procedures, technology and human resources which make sure 
that aircraft are guided safely through the sky and on the ground and that airspace is managed to 
accommodate the changing needs of air traffic over time. [69] 

2 See: http://www.icao.int/safety/acp/Inactive%20working%20groups%20library/ACP-WG-C-11/ACP-

WGC11-WP30-SESAR%20Part%201%202%20new%20(JF).ppt  
21/06/2018 

Page 8 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

o  Deployment  phase  (2015-2035),  having  as  objectives  implementing 
SESAR solutions to answer local needs and synchronising deployment 
to deliver Europe-wide benefits. 

2005:  

•  The definition phase of the SESAR project started [14].  

•  The  Commission  has  stated  the  political  vision  and  high  level  goals  for  the 

Single European Sky and its technological pillar: 

o  Enable a 3-fold increase in capacity which will also reduce delays, both 

on the ground and in the air; 

Improve the safety performance by a factor of 10; 

o 
o  Enable a 10% reduction in the effects flights have on the environment 

and; 

o  Provide ATM services to the airspace users at a cost of at least 50% 

less. 

2007:  

•  The SESAR Joint Undertaking (SJU) was established as a public-private 
partnership in order to manage the development phase of the SESAR 
programme3. SJU was established under European Union law, founded by 
the European Commission, Eurocontrol4 and industry. Industry participation 
was encouraged by a call for interest to become a member of the SJU in 
2007. 

2008:  

•  The SESAR Master Plan was released as one of the key results of the SESAR 
definition  phase.  The  plan  constituted  a  commonly  developed  roadmap, 
endorsed by the Council of the EU and recognised by all the stakeholders [15]. 
The  master  plan  would  be  used  to  steer  the  work  programme  for  the 
development  phase  and  to  govern  the  SESAR  deployment  phase  [4].  The 
following are the focus areas:  

o  Optimised ATM network services, 
o  High performing airport operations, 
o  Advanced air traffic services, 
o  Enabling  aviation 

infrastructure, 

including  the  System  Wide 

Information Management (SWIM).  

3 See: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32007R0219  
4 EUROCONTROL is an intergovernmental organisation with 41 Member and 2 Comprehensive 
Agreement States. [71] 

21/06/2018 

Page 9 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  SJU  kicked  off  the  SESAR  project  (subsequently  renamed  “SESAR  1”)  [5]. 
The  work  programme  consisted  of  16  work  packages  (WPs),  split  into  four 
different threads: 

o  Operational activities, under WPs 4, 5, 6, 7. 
o  System development activities, under WPs 9, 10, 11, 12, 13, 15. 
o  System Wide Information Management, under WPs 8, 14. 
o  Transversal activities, including ATM Master Plan maintenance, target 

concept and architecture maintenance, under WPs B, C, 3, 16.  

2009:  

•  SES  legislation  was  reviewed  with  Regulation  (EC)  n°  1070/2009  (the  so-
called SES2 package) and introduced, among other aspects, the definition of 
Common Projects as the legal basis for “synchronised deployment” within the 
SESAR  deployment  phase.  The  SES2  package  also  designated  the  Network 
Manager as a centralised function at EU level to co-ordinate certain actions at 
network level5. 

•  SJU signs agreements with 16 partners totalling €1.9 billion for the creation 
of  Europe’s  future  ATM  system.  Airlines,  business  and  general  aviation, 
associations join SESAR to modernise the European sky.  

2010:  

•  Europe/US agree to cooperate on SESAR.  

2011:  

•  Launch of the European ATM Master Plan update campaign. 

•  The Commission established the Network Manager as a body to carry out 

the following centralised ATM business functions: 

o 
o 
o 
o 

to develop and create Route Network Design; 

to provide a central function for Frequency Allocation; 

to coordinate improvements to SSR Code Allocation; 

to carry out the Air Traffic Flow management function. 

•  The Commission nominated EUROCONTROL as Network Manager. 

•  EUROCONTROL as Network Manager started to publish a first set of data via 

SWIM-compliant web services. 

•  SJU  published  the  SESAR  Release  1,  presenting  a  set  of  projects  that 
underwent already verification and validation in operational environment “in 
order to enable actors to take industrialisation and deployment decisions”. 

5 See: https://ec.europa.eu/transport/modes/air/single_european_sky/ses_2_en  

21/06/2018 

Page 10 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

2012:  

•  Presentation of release 2 of the Master Plan (validation exercise). 

•  First live SWIM demonstration. 

2013:  

•  European Commission proposes new mandate for SJU to support the Single 

European Sky.  

•  Publication of Release 3 of the Master Plan. 

•  Successful live demonstration of SWIM at the World ATM Congress in Madrid. 

•  Implementing  Regulation  409/2013  on  definition  of  common  projects, 
governance  and  incentives  supporting  the  implementation  of  the  European 
ATM Master Pan. The regulation introduces the following aspects. 

o  Purpose  and  content  of  common  projects.  Specifically,  common 

projects shall: 

 

 

“aim to deploy in a timely, coordinated and synchronised way 
ATM  functionalities  that  will  achieve  the  essential  operational 
changes”, and 

“identify  the  ATM  functionalities  that  having  reached  the 
appropriate 
for 
implementation; require synchronised deployment”. 

industrialisation,  are  mature 

level  of 

o  Deployment  governance,  coordinating  the  implementation  of 
facilitating 

common 
and 
industrialisation, composed of to three levels as follows. 

interfacing  with 

projects  while 

  Policy level, driven by the Commission supported by competent 

bodies, including SESAR JU. 

  Management level, under the responsibility of the deployment 
manager  (DM),  in  coordination  with  SESAR  JU,  the  military 
and the industry where appropriate. 

 

Implementation  level,  driven  by the  Commission, that  selects 
projects based on the maturity of their industrialisation process. 

o  Deployment programme, i.e. “a structured work plan of all activities 
necessary  to  implement  technologies,  procedures  and  best  practices 
required to implement common projects”, to be submitted by the DM 
and approved by the Commission. The deployment programme “shall 
constitute  the  reference  for  the  work  of  the  Management  and 
Implementation levels.” 

o 

Incentives, focused on implementation projects. 

2014:  

21/06/2018 

Page 11 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  The Commission released the Implementing Regulation (EU) No 716/2014 on 
the establishment of the first common project, known as the Pilot Common 
Project (PCP) supporting the implementation of the European ATM Master 
Plan. The regulation defines the in-scope ATM functionalities “to be deployed 
in  timely,  coordinated  and  synchronised  way  so  as  to  achieve  the  essential 
operational  changes  stemming  from  the  European  ATM  Master  Plan”.  The 
functions  include  the  Initial  System  Wide  Information  Management 
(iSWIM) to be put operational as of 1 January 2025. iSWIM was defined in 
the PCP as follows. 

o  Common infrastructure components:  

  SWIM  registry  for  information  (metadata)  publishing  and 

discovery. 

  Public  Key  Infrastructure  (PKI) 

for  secure 

information 

transmission. 

o  SWIM Technical Infrastructure (TI) and Profiles, i.e. 

  Blue  SWIM  TI  profile  for  blue  profile  for  real-time  or  near-
real-time exchanges between Air Traffic Control (ATC) centres. 

  Yellow  SWIM  TI  profile  for  all  exchanges  with  less 

demanding Quality of Service (QoS) requirements. 

o  Aeronautical  information  exchange,  e.g.  airspace  usage  information 

and plans. 

o  Meteorological information exchange, e.g. forecasts, wind speed. 
o  Cooperative network information exchange, e.g. information on airport 

capacity. 

o  Flight information exchange, e.g. flight plans, status routes. 

•  The Council of Ministers of the EU extended SJU mandate to 2024. In addition, 
the amending regulation entrusted the SJU with EUR 585 million from Horizon 
2020  to  execute  and  deliver  the  SESAR  Research  &  Innovation  (R&I) 
Programme  2020  (SESAR  2020)  to  contribute  achieving  the  Single 
European Sky and more particularly the European ATM Master Plan [16].  The 
programme is structured into three main research phases working in parallel 
and in line with the European ATM Master Plan6: 

o  Phase  1:  Exploratory  Research,  performing  fundamental  scientific 

research and investigating initial applications. 

6 See: https://ec.europa.eu/transport/sites/transport/files/modes/air/news/doc/2014-07-09-
sesar/annex-iii.pdf 

21/06/2018 

Page 12 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

o  Phase 2: Industrial Research and Validation, delivered through Public-
Private-Partnership  (PPP),  includes  applied  research,  pre-industrial 
development and validation. 

o  Phase  3:  Very  Large-Scale  Demonstration  (VLD)  aiming  to  raise 
awareness  regarding  SESAR  activities  and  assessing  full-scale 
deployment readiness. 

o  Besides the three phases, the programme included transversal, which 

included the maintenance of the European ATM Master Plan. 

Within SESAR 2020, the work on SWIM Technical Infrastructure was expected 
to be in continuity with SESAR 1. In particular, the work would include: 

o  Elaborating  logical  architecture  of  the  SWIM  Technical  Infrastructure 

and options for the technical architecture. 

o  Developing prototypes of necessary SWIM Technical Infrastructure to 
support validations with one or more different technical architectures, 
considering  also  civil-military  SWIM  interoperability  (ATM  and  Air 
Defence). 

o  Global  coordination  ensuring  interoperability  between  global  SWIM 

Technical Infrastructures. 

o  Contributions to standardisation. 
o  Demonstration and Communication activities. 

•  The Call for Expression of Interest for candidate members to participate in the 

SESAR 2020 Programme was published7 [6]. 

•  European ATM Master Plan new review campaign was kicked-off [7]. 

• 

In December 2014, SESAR Deployment Phase was launched8. The European 
Commission appointed the SESAR Deployment Alliance — a partnership of 
the  A6  ANSP  alliance,  the  A4  airlines  group  and  the  SESAR-related 
Deployment Airport Group (SDAG) European Economic Interest Group (EEIG) 
–  to  the  role  of  SESAR  Deployment  Manager  (SDM)  being  in  charge  of 
managing  the  synchronised  deployment  of  the  first  set  of  SESAR  Solutions 
defined in the Pilot Common Project.  

•  SESAR  Deployment  Alliance 

the  Preliminary  Deployment 
released 
Programme (PDP V0) which  provided  “the  initial  project  view  of the  ATM 
functionalities of the Pilot Common Project in order to support the successful 
implementation of the Regulation (EU) No 716/2014”9. 

7 See also: https://ec.europa.eu/transport/modes/air/news/2014-07-09-sesar_fr  
8 See: https://publications.europa.eu/en/publication-detail/-/publication/de20c2eb-3137-11e6-b497-

01aa75ed71a1/language-en/format-PDF/source-61710894  

9 See: https://www.sesardeploymentmanager.eu/wp-content/uploads/2015/02/SDA-Preliminary-

Deployment-Programme-V0.pdf  
21/06/2018 

Page 13 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  SESAR  is  included  as  priority  area  within  the  Connecting  European  Facility 

(CEF). 

2015:  

• 

In March 2015, the SESAR JU and the SESAR DM signed a Memorandum of 
Understanding to provide a platform upon which to build cooperation for the 
smooth and timely delivery and deployment of SESAR Solutions to the ATM 
community.  A  critical  factor  for  success  is  the  exchange  of  information  to 
support the industrialisation phase, to ensure effective bridging between R&D 
and deployment and to facilitate interoperability10. 

•  Launch of first SESAR 2020 call for exploratory research projects, focusing on 

ATM science and outreach.  

•  SESAR SWIM Master Class kicks off, which is an initiative to encourage the 

further take up of SWIM. 

•  The 2015 edition of the European ATM Master Plan is published. 

• 

Initial SWIM was included in SESAR Release 5 as ready to go through 2015 
and 2016 validation exercises. 

2016:  

•  The SJU membership is renewed with 19 entities and SJU publishes the first 
edition  of  the  SESAR  Solutions  Catalogue,  containing  63  SESAR  Solutions 
delivered by SJU members and partners. 

•  A call for exploratory research projects on the integration of drones into civil 

airspace is launched [7]. 

•  The  SJU’s  Single  Programming  Document  for  2017–2019,  outlined  the 
roadmap to the successful implementation of SESAR 2020 and its contribution 
to the SES objectives for the following three years. 

•  SJU  and  EUROCONTROL  agree  on  the  cooperation  the  European  Defence 

Agency (EDA). 

•  SWIM  Global  Demonstration  event  “showed  the  technical  feasibility  of 
connecting different local implementations of SWIM [Europe, United States, 
Australia, United Arab Emirates, Mongolia and Brazil], exchanging information 
in  areas  such  as  aeronautical,  meteorological,  and  flight  and  network 
information through globally common SWIM standards.”11 

2017 to date 

10  https://publications.europa.eu/en/publication-detail/-/publication/de20c2eb-3137-11e6-b497-

01aa75ed71a1/language-en/format-PDF/source-61710894 

11 A document on SWIM Global Demonstration Lessons Learned can be found at: 

https://www.sesarju.eu/sites/default/files/documents/swim/IMPWG3WP19_Architecture_SESAR_SWIM
_Global_Demonstrations_Lessons_Learned_Attachment.pdf  
21/06/2018 

Page 14 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  EUROCONTROL  has  been  identified  by  the  European  ATM  Standardisation 
Coordination  Group  (EASCG)  to  provide  the  technical  specifications  for 
Foundational  information  service  implementation  standardisation  area  in 
support  of  iSWIM  deployment.  After  formal  consultation,  EUROCONTROL 
released three specifications for SWIM addressing: 

o 

o 

o 

the description of information services, which took into account SESAR 
Information Service Reference Model (ISRM); 

the definition of the exchanged information, which made reference to 
the ATM Information Reference Model (AIRM), and 

the technical infrastructure on which the services are implemented, i.e. 
by  fine  tuning  SESAR  work  on  SWIM-TI  Yellow  Profile  Technical 
Specification12. 

•  The Commission mandated SESAR DM and SESAR JU respectively, to review 
progress in modernising European air traffic management, and to prepare for 
the next wave of technology implementation under a second Common Project 
(CP2) 

•  The updated SESAR Deployment Programme document (2017) sheds light on 

the status of the PCP as of May 2017 

o  The  Pilot  Common  Project  total  deployment  status  is  summarised  in 

the picture below, with 18,8% completed implementation. 

Figure 1. PCP implementation status 

o  Concerning Initial SWIM (AF#5), the following pictures summarise the 

status and expected roadmap of implementation activities.  

12 See: http://www.eurocontrol.int/publications/eurocontrol-specifications-system-wide-information-

management-swim  
21/06/2018 

Page 15 of 76 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 2. Initial SWIM implementation status and expected roadmap 

2.2  Vision and mission statement, underlying values, goals and objectives 

2.2.1  Vision 

At policy level, the vision for a Single European Sky was initially expressed in art. 1 
of Regulation 459/2004, although not referred to as “vision”. 

The objective of the single European sky initiative is to enhance current 
air  traffic  safety  standards,  to  contribute  to  the  sustainable 
development  of  the  air  transport  system  and  to  improve  the  overall 
performance  of  air  traffic  management  (ATM)  and  air  navigation 
services (ANS) for general air traffic in Europe, with a view to meeting 
the requirements of all airspace users. This single European sky shall 
comprise  a  coherent  pan-European  network  of  routes,  network 
management and air traffic management systems based only on safety, 
efficiency  and  technical  considerations,  for  the  benefit  of  all  airspace 
users. 

In 2007, the ATM Target Concept clarified that: 

The  ATM  vision  for  Europe  is  to  have  an  affordable,  seamless  ATM 
Network  enabling  all  categories  of  Airspace  Users  to  conduct  their 
operations  with  minimum  restrictions  and  maximum  flexibility,  whilst 
meeting  the  agreed  targets  for  safety,  operational  efficiency,  cost 
effectiveness, environmental impact and meeting security and national 
defence requirements13 

SES vision impacts the entire ATM system, offering improvements at every stage of 
the flight as shown in Figure 2 [16]. 

13 See: SESAR Consortium – Document D3 – ATM Target Concept - DLM-0612-001-02-00a – Sept. 2007 
Page 16 of 76 

21/06/2018 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 3. SES vision offering improvements at every stage of the flight 

The political vision and high-level objectives of SESAR have been announced in 2005 
by  its  then Vice-President  Jacques  Barrot.  The  objective  of  SESAR  is  to  modernise 
European ATM by defining, developing and delivering new or improved technologies 
and procedures in order to: 

•  Enable a 3-fold increase in capacity which will also reduce delays both 

on the ground and in the air; 

• 

Improve safety by a factor of 10; 

•  Enable a 10% reduction in the effects flights have on the environment; 

and 

•  Provide ATM services to the airspace users at a cost of at least 50% 

less. 

Detailed business objectives have been defined through the three editions of the ATM 
Master Plan14.  

At the level of infrastructure, the purpose of SWIM is: 

information  users  with 

To  provide 
relevant  and  commonly 
understandable information. [SWIM] does not refer to a single solution 
or  technology,  but  rather  a  global  level  of  interoperability  and 

14 See: SESAR Performance Framework in 2008 edition and the Business View of costs and Benefits of 

the 2015 edition. 
21/06/2018 

Page 17 of 76 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

standardisation  that  enables  users  and  providers  to  exchange  data 
without having to use different interfaces or protocols  [10]. 

SWIM aims at simplification of information sharing as shown in Figure 3. 

Figure 4: Information sharing with and without SWIM [19] 

2.2.2  Definition 

SWIM is defined at high-level in its latest Concept of Operations [19] as follows. 

SWIM consists of standards, infrastructure and governance enabling the 
management  of  ATM  information  and  its  exchange  between  qualified 
parties via interoperable services 

In more detail, these elements are: 

•  Standards: 

o  SWIM data model, i.e. the ATM Information Reference Model (AIRM); 
o  SWIM Technical Infrastructure profiles (e.g. the Yellow Profile) 
o  Descriptions of the services.15 

•  Infrastructure, i.e. the SWIM Technical Infrastructure (SWIM-TI). 

•  Governance.  SESAR  1  introduced  of  IM  Functions,  Governance  bodies 
(Steering Group, Expert Groups, Management Unit), and additional actors in 
SWIM (Service Providers, Service Consumers, Common infrastructure Service 
Providers). These elements are still under discussion and not which is not yet 
completely defined. More details are provided in Section 4. 

2.2.3  Guiding principles 

SWIM  Concept  of  Operations  outlines  10  Key  Principles  of  SWIM  that  “provide 
direction for all stakeholders in respect of the design, provision, evolution of SWIM, 

15 SESAR 1 introduced also the concept of Information Service Reference Model (ISRM) but, according to 

our interviewees, it is not used anymore. 
21/06/2018 

Page 18 of 76 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

and with regard to the information/solution providers and consumers, the processes, 
standards, and technologies”.  

SWIM Key Principles are: 

1.  Accessibility: ATM stakeholders can directly offer, and consume, ATM 
information using common service interfaces and network connectivity. 
2.  Equity: No individual stakeholder dominates, or constrains, what may be 

offered, or consumed, by other stakeholders. 

3.  Flexibility: Capability for adequate, responsive, timely, dynamic and 
asynchronous changes of providers and users and the information and 
services they offer and consume. 

4.  Performance: Combined ATM stakeholder and infrastructure provisions 

must ensure required levels of performance, safety, and resilience, and 
provide effective incident and evolution management. 

5.  Quality, Integrity & Security: ATM Stakeholders retain responsibility for 
the quality, integrity, security, and availability of the information, whilst 
interface and infrastructure technology ensures integrity of exchanges. ATM 
Stakeholder identification allows information to only be exchanged with 
appropriate parties and security measures applied. 

6.  Implementation & Evolution: Clear vision and roadmap for operational, 
technical, and institutional, implementation and evolution; aligned with 
reduction in the use of individually specialised interfaces and connectivity. 
7.  Cost: Reduced costs for on-going information exchanges, with costs for ATM 
evolution proportionate to needs, benefits and stakeholder affordability. 

8.  Service orientation: Service orientation methods are expected to be 
applied to support the ATM stakeholders’ use of services to share 
information. 

9.  Open standards: SWIM is expected to make use of applicable open and 
internationally recognised standards for the information, the content, the 
processes, and the provision of services. 

10. Global applicability: SWIM will need both international and local 

agreements, to achieve a seamless ATM information environment and 
therefore adequate governance needs to be established [23]. 

2.2.4  Value proposition 

The value  proposition  of SWIM  is to  make the  same  ATM  information  available  to 
and easy to use by all stakeholders [25]. 

In particular,  

SWIM contributes to achieving the following benefits: 

21/06/2018 

Page 19 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

a) improved decision making by all stakeholders during all strategic 
and  tactical  phases  of  flight  (pre-flight,  in-flight  and  post-flight) 
through: 

(i) improved shared situational awareness; and 

(ii)  improved  availability  of  quality  data  and  information  from 
authoritative sources; 

b) increased system performance; 

c)  more  flexible  and  cost-effective  communications  by  the 
application of common standards for information exchange; 

d)  loose  coupling  which  minimizes  the  impact  of  changes  between 
information producers and consumers; and 

e) support of ATM Service Delivery Management (SDM). 

In general, according to our interviewees ATM stakeholders were engaged through a 
two-folded incentive: on the one hand, they would get access to research through 
the SESAR program. On the other hand, they would gain competitive advantage by 
being part of R&D activities that would lead to international standards. 

2.2.5  Customer segments and stakeholders 

SWIM Concept of Operations lists and describes SWIM Stakeholders in terms of actors 
and their roles.  

SWIM Actors are:  

•  Aerodrome community: airports;  
•  Airspace providers: States and organisations responsible to allow or deny 

access to their sovereign airspace;  

•  Airspace users: organisation operating aircrafts and pilots;  
•  ATM service providers: all organisation that are engaged in provision of 
ATM services to airspace users (this includes ANSPs and EUROCONTROL);  
•  ATM support industry: all organisations providing  systems and services to 

ATM service providers;  

•  International Civil Aviation Organization (ICAO);  
•  Regulatory authorities, e.g. aviation safety regulators, standardisation 

and certification authorities, investigation authorities. 

•  States.  

SWIM roles, at high level are presented in the picture below. 

21/06/2018 

Page 20 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 5. SWIM high-level roles 

The Concept of Operations assigns one or more roles to each actor, specifying that 
“there  will  always  be  exceptional  cases,  where  some  of  the  actors  perform  other 
roles”. 

2.3  Development strategy 

The  following  paragraphs  focus  on  the  SESAR  programme  strategy  and  give  an 
overview of the project activities, status and way forward as a result of desk research 
and interviews. Due to the complexity of the programme, only the information that 
is most relevant to the purpose of this study is presented.  

2.3.1  Scope, in terms of countries, agencies, and information services 

SESAR, and SWIM, scope in terms of countries is aligned with the Single European 
Sky initiative. In principle, all EU Member States are concerned by this initiative. The 
PCP involves airports and Air Navigation Service Providers from 12 Member States 
and Turkey. In practice, SWIM is not yet operational at the time of writing. 

In terms of information services, the PCP identifies 5 families of services that shall 
be implemented by participants. These are: 

•  Family 5.3.1 for Aeronautical Information Exchanges 

•  Family 5.4.1 for Meteorological Information Exchanges 

•  Family 5.5.1 for Cooperative Network Information Exchanges 

21/06/2018 

Page 21 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  Family 5.6.1 for Flight Information Exchanges 

•  Family  5.6.2  for  Flight  Object  Exchanges  between  ANSPs  for  improving  the 

trajectory management. 

2.3.2  Overall design, development, test and roll-out 

The following paragraphs build on and consolidate the information that was presented 
in chronological order under section 2.1.2.   

In summary, the overall strategy of SESAR evolved as SESAR’s three phases rolled-
out. 

Figure 6: Phases of SESAR [25] 

SESAR has been following an iterative process from planning to R&D and deployment. 
At  the  time  of  writing,  both  development  and  deployment  phases  are  running  in 
paralle.  The  different  activities  that  form  the  continuous  lifecycle  for  ATM 
modernisation are described below. 

Figure 7. SESAR innovation lifecycle. Source: SESAR JU [22] 

21/06/2018 

Page 22 of 76 

 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

2.3.2.1  Definition activities  

These activities involve the design and maintenance of the ATM Master Plan, which 
is used as a planning tool for defining priorities for the realisation of SESAR Target 
Concept.  For this purpose the Master Plan “identifies the related changes and groups 
them  according  to  whether  they  are  already  in  place,  in  the  pipeline  towards 
deployment, or planned as part of future R&D activities”. 

The  Master  Plan,  available  as  web-portal  and  in  print,  is  divided  into  three  levels, 
each one comprised of several views 

•  Level 1, Executive level. 

•  Level 2, Planning and Architecture level. 

•  Level 3, Implementation level. 

The three levels are briefly explained below. 

The Master Plan comprises an integrated set of information, with Level 
1  constituting  the  synthesis,  consisting  of:  Executive  Summary;  The 
SESAR Vision; Performance View; Operational View; Deployment View; 
Business View; Risk Management. 

The  intended  readership  for  Level  1  is  executive-  level  stakeholders. 
Levels 2 and 3 of the Master Plan provide more detail on the operational 
changes  and  related  elements  and  therefore  the  target  audience  is 
expert-level stakeholders. 

Level  2  (Planning  and  Architecture  View)  is  available  through  the 
European  ATM  portal  (www.atmmasterplan.eu),  which  provides  the 
detailed planning and architecture information supporting Level 1. 

Level  3  (Implementation  View)  comprises  the  European  Single  Sky 
ImPlementation (ESSIP) Plan (and Report), which is a set of commonly-
agreed implementation actions. These actions, including those resulting 
from the other SES plans such as the SESAR Deployment Programme, 
help  to  achieve  the  performance  targets  (11)  in  the  areas  of  safety, 
environment,  capacity  and  cost  efficiency.  In  addition,  Level  3  of  the 
Master Plan provides stakeholders with a basis for short-term common 
implementation planning. 

SESAR JU holds the responsibility for updating the Master Plan every 2-3 years by 
integrating  inputs  from  all  stakeholders  and  reflecting  the  results  of  the  R&D 
programme and deployment activities. 

21/06/2018 

Page 23 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

2.3.2.2  Development activities 

SESAR created an innovation pipeline through which ideas are first explored and then 
into  real  operations.  The  pipeline  consists  of  three  phases:  exploratory  research; 
industrial research projects and validations; large-scale demonstrations.  

SJU tracks the progress, validation, standardisation and industrialisation of each ATM 
functionality  being  developed  according  to  two  frameworks:  the  Technology 
Readiness  Levels16  and  the  European  Operational  Concept  Validation  Methodology 
(E-OVCM17).  These  frameworks  are  interwoven  with  the  three  phases  of  the 
innovation pipeline as described in the picture below18. 

Figure 8. SESAR Maturity Phases (TRL vs. E-OCVM) 

SESAR R&D activities bring ATM functionalities up to TRL7, which is defined as: 

TRL  7  System  demonstration  in  an  operational  environment 
(ground, airborne or space):  System  demonstration  in  operational 
environment. System is at or near scale of the operational system, with 
most  functions  available  for  demonstration  and  test  and  with  EASA 
proof  of  concept  authorisation  if  necessary.  Well  integrated  with 
collateral  and  ancillary  systems,  although  limited  documentation 
available. 

16 See definition in Horizon 2020 work programme: 

https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-
annex-g-trl_en.pdf  

17 Guidance material found on: http://www.eurocontrol.int/publications/european-operational-concept-

validation-methodology-eocvm  

18 See:  

21/06/2018 

Page 24 of 76 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Then,  after  demonstration,  each  operational  or  technical  solution  is  branded  as  a 
SESAR solution and packaged for further industrialisation and deployment (TRL 8 
and 9) which are out of the scope of SESAR 1 and SESAR 2020).  

The  current  list  of  SESAR  Solutions,  which  were  delivered  by  the  SESAR  1 
programme, can be found in the SESAR Solution Catalogue19. 

Standards are developed by the SJU and EUROCAE working group [18]. 

2.3.2.3  Deployment activities 

At high-level, the ATM Master Plan provides the overall approach to deployment of 
SESAR Solutions and mentions the SESAR Deployment Manager as responsible for 
deployment of common projects20.  

At the time of writing, the deployment of a first set of top-priority SESAR Solutions 
that  needed  synchronised  deployment  at  European  Level  has  been  included  in  the 
Pilot Common Project running between 2015 and 2024.   

The  implementation  plan  and  the  tool  to  track  progress  of  the  PCP  is  the  SESAR 
Deployment  Programme  (DP)21.  The  DP  is  developed  and  maintained  by  SDM, 
with  technical  contribution  by  SJU,  the  Network  Manager,  the  European  Defence 
Agency, and the wider ATM community. 

The Deployment Programme translates the ATM functionalities to be implemented by 
the PCP into groups of Families of implementation projects. A Family is defined 
as follows. 

A  Family  therefore  represents  a  more  specific  set  of  homogeneous 
technological and operational elements, which shall be deployed within 
a defined geographical scope in order to make sure that the operational 
scenario  defined  by  the  PCP  Regulation  becomes  reality  and  the 
associated  performance  improvements  are  delivered  to  the  ATM 
Community and – in turn – to European passengers 

In  the  case  of  SWIM,  the  Deployment  Programme  contains  12  Families,  as  a 
guideline  for  the  operational  stakeholders  to  implement  Initial  SWIM  (iSWIM) 
projects. The 12 Families fall into 3 distinct sets. 

19 See: https://www.sesarju.eu/newsroom/brochures-publications/sesar-solutions-catalogue  
20 In general, two high-level options are foreseen: 

-  Option 1: optimised ATM infrastructure deployment: deployment with strong, network wide 

coordination. In this case strong harmonisation of systems, rules and procedures is achieved. 

-  Option 2: local deployment: deployment with light coordination and moderate degree of 

harmonisation of systems. 

  According to SESAR deployment approach, “the choice between both options will be made when a new 
technology is mature for deployment, in the context of the common projects, based, inter alia, on the 
results of the development phase”. See ATM Master Plan, p 60 

21 https://www.sesardeploymentmanager.eu/publications/deployment-programme/  

21/06/2018 

Page 25 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

A  first  set  is  dealing  with  the  necessary  common  components  and 
structures.  “Common”  in  this  respect  means  that  only  one  common 
system  or  one  common  set  of  rules  is  to  be  deployed  for  the 
geographical  scope  mandated  by  [the  PCP  regulation].  Thus,  all 
operational  stakeholders  have  to  collaborate  and  put  these  in  place 
together  to  facilitate  the  SWIM  interoperability  and  interconnectivity 
[…] 

The  first  set  is  complemented  by  a  second  set  that  deals  with  the 
specific  infrastructure  components  to  be  implemented  by  each 
operational  stakeholder  within  its  own  area  of  responsibility.  These 
stakeholder  infrastructure  components  form  the  basis  for  information 
provisions and consumptions dealt with in the third set […] 

The  third  and  last  set  is  dealing  with  the  different  kinds  of  ATM 
information  exchanges  defined 
the 
interdependencies with the other AFs 

the  PCP, 

including 

in 

Moreover, a list of services, developed in the context of SESAR 1 or services deployed 
or planned by Network Manager is provided22. This list is based on an interpretation 
of the PCP and defines a starting point for the SWIM implementation towards a partial 
coverage of the ATM information exchanges required by the regulation. Therefore, 
further evolution or adaptations are foreseen under the responsibility of the SWIM 
Governance. 

Some  more  general  ideas  on  the  approach  to  the  implementation  of  SWIM  are 
provided in a dedicated chapter of SWIM Concept of Operations document23. 

The  implementation  of  SWIM  is  not  a  big-bang  replacement  of  the 
existing  ATM  environment,  but  an  evolutionary  process  based  on  a 
gradual  transition  towards  a  service-oriented  European  ATM  system 
architecture. The adoption of SWIM will be flexible and foster increased 
levels of collaboration within business domains. It will enable supporting 
systems to interact in an interoperable and standardised way.  

The transition itself will be simplified by decoupling providers from 
consumers  of  services,  i.e.  between  providers  and  consumers  of 
information. This will allow gradual growth in the number of SWIM 
participants and diversification in their nature, as well as a continuous 
increase in SWIM enabled applications.  

22 See Appendix I of Guidance Material for SESAR Deployment Programme Implementation - Planning View 2017. 

Link: https://www.sesardeploymentmanager.eu/wp-content/uploads/2018/01/SESAR-DM-Planning-View-
2017.pdf  

23 For more details see Project 08.01.01 D41 – SWIM Concept of Operations, Chapter 7, Implementing 

SWIM through gradual change. 
21/06/2018 

Page 26 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

The implementation roadmap should thus reflect an iterative process 
that  foresees  continuous  improvement  and  evolution  in  step 
with business needs.  

Services  will  be  added  as  necessary  to  support  ATM 
stakeholders’ requirements. Other key components of SWIM, such 
as  the  AIRM,  the  ISRM,  the  registry,  information  management 
functions,  infrastructure  elements  and  governance  will  gradually 
evolve  and  be  aligned  with  the  requirements  of  the  services 
available at any given point in time. […] 

It should be noted that because not all regions move towards SWIM at 
the  same  speed,  legacy  means  of  interaction  may  need  to  be 
maintained for some time.   [23]. 

2.3.3  Project management aspects 

The following paragraphs explain the programme and project management aspects 
of SESAR  

The  development  of  content  in  the  SESAR  2020  Programme  is  structured  and 
executed  by  three  high  level  business  processes  and  practices  executed  in  6 
activities. The following pictures summarises these steps: 

Figure 9: Activities and steps involved the SESAR 2020 programme 

21/06/2018 

Page 27 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

The project management activities are broken down into a dedicated set of practices 
and  are  based  on  industry  best  practices.  Project  management  activities  can  be 
clustered into a number of dedicated practices, many of which are interrelated. The 
following picture provides an overview (green boxes). 

Figure 10: Clusters of Project Management Activities  [27] 

2.3.4  Constraints: legal/regulatory environment, resources, time and cost 

SESAR’s budget contains approximately €50 billion for a 19 year period:  

•  SESAR definition phase: €60M.  

•  SESAR 1 Programme (2008-2016): €2,1b (TEN-T funding)  

•  SESAR 2020 Programme (up to 2024): €1,6b  (Horizon 2020 funding) 

•  Deployment  phase 

(2015-2035):  estimated  €18b-€28b,  of  which 
approximately  10  %  is  funded  by  the  EU  with  the  remainder  sourced  from 
within the aviation sector. 

21/06/2018 

Page 28 of 76 

 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

2.4  Key findings 

The following paragraphs highlight the most relevant findings that can be useful to 
compare SESAR and SWIM to CISE on the topics outlined in this chapter. 

Main evolution milestones 

•  SJU  Members  and  ATM  Stakeholders  have  highlighted  the  importance  of 
SESAR,  and  the  SJU,  as  a  key  enabler  of  the  wider  SES  policy,  forming  an 
“unprecedented public-private partnership that co-ordinated and concentrates 
effort and resources at European level to achieve modernisation of ATM.” 

•  The high level strategy (definition, development, deployment) of SESAR was 

decided upfront, according to the three phases from 2005 to 2035. 

•  Development  and  deployment  activities  are  now  running  in  parallel. 
Relationship  between  R&D  and  deployment  is  structured  according  to  the 
SESAR  innovation  pipeline  that  iteratively  generates  SESAR  Solutions, 
comprising  those  projects  are  mature  enough  to  be  validated  and 
industrialised. 

•  The first deployment project (the Pilot Common Project) included a subset of 
most important features and the ones who were most ready to deployment. 
An ad-hoc body was established to coordinate implementation (SESAR DM). 

•  The Network Manager is an ad-hoc body that was created to centralise and 
coordinate certain ATM-related specific functions. The body became the first 
SWIM pioneer (see below). 

•  Establishment of SWIM Governance was delayed and required new deadlines 
to be defined and a specific action plan to be drafted in SESAR Deployment 
Programme 2016. 

•  Time for proper industrialisation and standardisation is needed between R&D 
and  implementation,  as  “end  of  validation  does  not  mean  straight 
implementation.”  However,  in  SESAR  the  formal  checks  to  identify  when  a 
validated solution can be put in production are not clearly specified. 

•  SWIM  strategy  has  been  decoupling  providers  from  consumers  of  services, 
i.e. between providers and consumers of information, allowing gradual growth 
in the number of SWIM participants and diversification in their nature, as well 
as a continuous increase in SWIM enabled applications.  

•  The first early adopter of SWIM was the Network Manager (EUROCONTROL) 
in  2009  who  started  publishing  data  following  SWIM  concepts.  This 
encouraged  stakeholders  to  try  first-hand  how  SWIM  works  and  to 
incrementally build trust and embed these services in their own operational 
environments. As a result, NM B2B Web Services grew from 15 million queries 
made in 2011 up to around 400 million in 2015. 

21/06/2018 

Page 29 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  Stakeholder involvement in SWIM, besides funding, was fostered also through 
annual SESAR SWIM Master Classes and demonstrations within Europe and at 
World ATM Congress. Moreover, workshops around the world increased buy-
in towards global interoperability, which culminated in the SESAR SWIM Global 
demonstration  event.  In  SESAR  1  the  coordination  of  these  activities  was 
under the responsibility of a dedicated project. 

Vision, principles, value proposition 

•  At policy level, the main value proposition of SESAR has been communicated 
by  the  Commission  with  KPIs  that  are  used  throughout  the  program  to 
evaluate overall results. 

•  SWIM vision to provide relevant and commonly understandable information is 
communicated also through its official definition: “SWIM consists of standards, 
infrastructure and governance enabling the management of ATM information 
and its exchange between qualified parties via interoperable service”. 

•  The value proposition of SESAR and SWIM towards industry stakeholders is 
being  in  the  position  to  develop  the  technology  that  will  be  subsequently 
adopted  as  standard.  This  will  give  industry  stakeholders  in  competitive 
advantage  as  they  will  be  ready  to  sell  SESAR/SWIM-compliant  solutions 
earlier than competitors. 

Countries involved 

•  Target: EU and beyond. 

•  Actual: PCP countries. 

Sectors (user communities) 

•  All stakeholders in Air Traffic Management are targeted by SESAR and SWIM.  

Political and regulatory support 

•  SESAR  and  SWIM  enjoy  a  strong  regulatory  and  political  support.  However 
implementation and compliance to regulations is still under the responsibility 
of Member States. SESAR DM acts as intermediary and coordinator but it is 
not mandatory for MS to refer to it in order to implement and deploy SESAR 
solutions  individually  without  funding.  Therefore,  the  risk  of  not  having  full 
interoperable systems persist, as does the strong need to promote the value 
of cooperation and coordination. 

•  PCP  regulation  allowed  room  for  interpretation  (as  seen  in  Deployment 
Programme) and did not mention SWIM governance, whose delay is a blocking 
factor.  For  this  reason  the  DM  had  to  translate  the  regulation  into  a 
deployment  programme  that  made  reference,  for  example,  to  the  actual 
services resulting from SESAR 1. However the deployment programme is non-
binding and provides only guidance and recommendations. These limitations 

21/06/2018 

Page 30 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

will  be  overcome  by  the  Revised  PCP  that  will,  for  example,  make  specific 
reference to SWIM governance. 

•  Standardisation  activities  are  triggered  when  a  sufficiently  large  number  of 
parties  agree  to  consolidate  the  output  of  R&D  activities  into  standards. 
Subjects  of  standardisation  are 
frameworks  or  rulebooks,  not  the 
implemented products (e.g. not the service instances), which allows flexibility 
and evolution. 

At the moment, standardisation is managed by EUROCONTROL, but it will be 
with the sharing environment governance bodies when they are in place. 

21/06/2018 

Page 31 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

3  OVERALL TECHNICAL ARCHITECTURE AND DESIGN 

This section provides an overview on the architecture of SWIM and its constituting 
elements, with particular attention to those that were described with most detail in 
publicly available documents.  

The following sections will present the characteristics that are most relevant for the 
purpose of this report. Punctual references will be given should the reader need more 
detailed information. 

SWIM  comprises  standards,  infrastructure  and  governance.  With  respect  to  this 
definition,  this  section  focuses  mostly  on  describing  the  architecture  of  the 
infrastructure  part,  i.e.  the  SWIM  Technical  Infrastructure  (SWIM-TI).  The 
standards part will be also addressed in several sub-sections, namely: 

•  Section 3.4.1 on data model (AIRM) 

•  Section 3.4.2 on the service model (ISRM) 

The governance part of SWIM will be described in more detail in section 4.1.2. 

The reader shall be aware that the information contained in the documents might not 
be fully developed in all the aspects at the time of writing and is subject to change. 

3.1  Requirements 

SWIM-TI requirements from the Architectural Definition Document are listed below. 

•  Fit for purpose. SWIM Technical Infrastructure Design and Artifacts must be 
an  answer  to  business and  operational  needs.  This  will  mean  that solutions 
provided  by  SWIM  Technical  Infrastructure  must  be  well  based  either  in 
existing needs, either in future needs. This Principle applies not only to the 
SESAR Programme but also to further evolutions of the SWIM-TI Design after 
the R&D Stages; 

•  Aim  for  the  interoperability.  SWIM  Technical  Infrastructure  Design  must 
always handle the interoperability between the existing architectural solutions 
and the new to be designed; 

•  Aim  for  the  functionality  /  implementation  freedom.  SWIM  Technical 
Infrastructure  Design  must  be  follow  as  much  as  possible  functionality 
description approach, rather than a physical description approach, leaving the 
implementer the freedom of implementation as long as the requirements are 
covered and the interoperability maintained 

•  Distributed/Modular  design.  SWIM  Technical  Infrastructure  Design  must 

always support a distributed and/or federated approach;  

•  Scalability. SWIM Technical Infrastructure Design must ensure the scalability 

of the proposed architectural Artifacts and Solutions;  

21/06/2018 

Page 32 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  Standards.  SWIM  Technical  Infrastructure  Design  must  use  of  standard 
technologies  where  applicable.  In  case  of  developed  software,  WP14  is 
expected  to  deliver  primarily  domain  independent solutions.  If  a need  for  a 
domain  specific  software  development  as  part  of  the  SWIM  Technical 
Infrastructure is identified and agreed, it shall be implemented respecting a 
modular approach (the generic part of the SWIM Technical Infrastructure can 
be  used  independently  from  the  domain  specific  part  for  ATM  software 
applications which do not need this domain specific part). 

•  Formal Models. SWIM Technical Infrastructure Design Artifacts must make 

use of formal models (such as UML) to express system interfaces;  

•  Service Orientation. SWIM Technical Infrastructure Design must apply the 
concepts  behind  service-orientation  and  provide  monitoring  mechanisms  at 
service level in the design of every component;  

•  Reuse.  SWIM  Technical  Infrastructure  Design  must  reuse  existing 
components when possible; I reusability in general should be considered as 
one of major goals in order to reduce costs. 

3.2  Use cases 

The SWIM Concept of Operations presents 11 use cases of SWIM, which are displayed 
in the pictures below. 

Figure 11. SWIM use cases, part 1 

21/06/2018 

Page 33 of 76 

 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 12. SWIM use cases, part 2 

The identified use cases are listed below. 

•  UC01: A Stakeholder joins SWIM 

•  UC02: The “SWIM authority” validates a stakeholder 

•  UC03 A stakeholder proposes a new or upgraded service definition 

•  UC04  The  “SWIM  authority”  manages  the  lifecycle  of  the  Reference  Models 

(AIRM / ISRM) 

•  UC05 A provider proposes a new or upgraded service instance 

•  UC06 A provider develops a new service instance 

•  UC07 A stakeholder upgrades the SWIM infrastructure 

•  UC08 The “SWIM authority” validates the compliance of a service instance 

•  UC09  A  provider  deploys  a  new  or  upgraded  service  instance  on  the  SWIM 

infrastructure 

•  UC10  A  consumer  prepares  to  use  an  existing  service  via  the  SWIM 

infrastructure 

•  UC11 A provider decommissions a service instance on the SWIM infrastructure 

21/06/2018 

Page 34 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

3.3  Architectural elements 

3.3.1  Key building blocks 

In the reviewed documentation, SWIM-TI is referred to as a Distributed System of 
Systems. The following passage from SWIM ADD provides a clarification on this term. 

The  use  of  the  term  Distributed  System  of  Systems  stresses  the 
autonomy  of  the  systems  that  participate  in  the  overall  Distributed 
System.  Despite  the  absence  of  the  level  of  “control”  by  a  single 
authority and not being under the responsibility of a single organisation, 
the  SWIM-TI  needs  the  establishment  and  enforcement  of  governing 
rules 
interoperability.  
The following characteristics can be observed for the SWIM-TI: 

procedures 

service 

ensure 

and 

to 

• behaves as a single coherent system for its users 

•  the  common  goal  of  this  system  is  targeted  at  provision  of 
interoperability to its users 

• the components of this system interact through a network, whether 
they  are  distributed  geographically  or  geographically/physically  co-
located 

•  is  not  operated  as  a  single  coherent  system  from  deployment  and 
technical supervision point of view 

The SWIM Concept of Operations provides a high-level definition of the SWIM-TI. 

The  SWIM-TI  is  a  set  of  software  components  distributed  over  a 
network 
infrastructure  providing  capabilities  properly  enabling 
collaboration among ATM systems. These capabilities are instantiated 
in  a  set  of  SWIM  nodes  (stakeholders’  endpoints)  and  common 
components (providing capabilities to all the distributed SWIM nodes):  

The  SWIM  node  concept  therefore  represents  a  bundle  of  SWIM-TI 
capabilities, allowing a given ATM system to use the SWIM-TI.  

Examples of common components are:  

•  the  registry,  which  is  used  to  enable  the  sharing  of  information 
(metadata) about services at design time;  

• the public key infrastructure (PKI) that aims to manage the trusted 
digital certificates which will be used.  

According to this definition, the SWIM Concept of Operations provides a first high-
level architectural representation of SWIM-TI.  

21/06/2018 

Page 35 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 13. High-level SWIM-TI architecture from SWIM ConOps 

The  picture  highlights  that  SWIM  nodes  can  be  physically  deployed/instantiated  in 
several ways. 

In order to describe the architectural building blocks of SWIM-TI in a more detailed 
and structured manner, the SWIM Architectural Definition Document provides three 
architectural views. 

• 

In  the  Functional  View,  SWIM-TI  is  considered  as  “a  single  entity  that 
provides and possibly consumes services”. Then, a functional decomposition 
of the SWIM-TI details what functionalities the SWIM-TI must provide. At this 
level,  no  reference  is  made  to  physical  implementation  or  specific 
technologies. 

•  The Technical View, on the other hand, provides the “how” of SWIM-TI by 
describing “possible architectural components that can provide/realize/deploy 
the functions of the Functional view”. 

•  Finally,  the  Deployment  View  provides  several  deployment  options  for 
illustrative purposes only. The purpose of this view is to discuss alternatives, 
as deployment choices are under the responsibility of SESAR Stakeholders. 

According to our interviewees and available documentation, no possible architectural 
alternatives were evaluated. 

21/06/2018 

Page 36 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

The following subsections will provide an overview of the key architectural elements 
according to the aforementioned views. 

3.3.1.1  SWIM-TI Functional view 

As anticipated, the Functional view provides the Functional Breakdown of SWIM-TI. 

The  Functional  decomposition  deals  with  the  “what”  aspect  of  the 
SWIM-TI. 

• The Functional decomposition does not address the “where” or “how” 
aspects of the SWIM-TI. 

•  In  particular  the  Functional  decomposition  remains  entirely 
independent of and totally silent about specific technology. This allows 
the Functional view of the SWIM-TI to persist and remain valid across 
technology changes. 

Figure 14: SWIM-TI Functional Breakdown 

The identified SWIM-TI Functional Blocks (FB) and functions are listed below. 

•  Registry:  provides  the  following  functions  to  retrieve  “Meta-Information” 

about the Services and the ATM Information available:  

registration functions,  

o  discovery functions,  
o 
o  security functions,  
o  system interface functions,  
o  policy functions. 

21/06/2018 

Page 37 of 76 

 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  Messaging:  provides  interoperability  between  distributed  systems  with 
varying degrees of decoupling and including features for effective and reliable 
communication. In particular, this FB provides the following functions:  

o  Routing,  
o  Distribution,  
o  Message Filtering,  
o  Protocol Bridge,  
o  Data Management,  
o  Messaging Quality of Service,  
o  Policy Enforcement,  
o  Data Validation and Transformation. 

•  Security: provides technical functions enabling the Access Control (Identity 
management, Authentication and Authorization), Audit and Data Protection in 
a federation of security domains in order to control and protect services and 
resources in the whole security chain.  

•  Supervision:  provides  functions  to  support  all  SWIM  related  supervision 
functions:  configuration  management,  fault  management,  performance 
management, security, legal recording. 

•  Recording: provides the ability to collect, store and on demand retrieval of 
information  related  to:  communication  performed  via  the  SWIM  Interfaces, 
and supervision actions and events.  

•  Shared object: allows the sharing of data across multiple SWIM Nodes by 
using  publish/subscribe  and  request/reply  messaging  pattern.  Multiple 
operations  on  an  agreed  data  model  are  possible,  e.g.  creation,  update, 
delete, and search. 

Registry  and  Identity  Management  are  tagged  as  Shareable  Functions  to 
highlight the fact that their implementation can possibly be shared through several 
profiles.  

3.3.1.2  SWIM-TI Technical view 

The Technical view describes the components that can realise the functions presented 
in the Functional view and describes the possible organizations of such components 
in a network. 

For this purpose, the Technical View identifies:  

•  SWIM-TI Technical Entities that compose the system. These are: 

o  SWIM-TI Infrastructure Systems. 

21/06/2018 

Page 38 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

A  SWIM-TI  Infrastructure  System  is  a  System  providing  a 
collection of SWIM-TI shareable functions.  

At  the  time  of  writing,  the  infrastructure  systems  are  the  SWIM 
Registry and SWIM Identity Management. 

  SWIM  Registry:  The  current  design-time  registry  is  a 
centralised  web  application  managed  by  EUROCONTROL24.  In 
the future, a run-time registry will be used, which will allowing 
dynamic  discovery,  binding  and  monitoring  of  services. 
According to the SWIM ADD, the run-time registry will be “Root 
registry  with consumer  affiliate”.  Information is  stored  at  two 
locations, the root registry and an affiliate registry. The affiliate 
registry  gets  information  by  regular  polling  or  using  a 
subscription  mechanism.  This  allows  to  distribute  querying 
traffic and to have better resilience. 

  SWIM 

Identity  Management: 

Two 

non-concurrent 

technologies are provided. 

•  A  Public  Key  Infrastructure  responsible  for  signing, 
emitting  and  maintaining  X.509  certificates  and 
revocation lists. 

•  A Security Token Infrastructure providing capabilities to 

manage security tokens and Identity stores. 

o  SWIM-TI Profiles 

A  SWIM-TI  Profile  is  a  SWIM-TI  Infrastructure  Systems  that 
groups  a  coherent,  appropriately-sized  set  of  SWIM-TI 
Functional  Blocks 
technical 
constraints/requirements that permit a set of stakeholders to 
realize Information sharing.  

given 

set 

for 

of 

a 

It also defines the mandated open standards and technologies 
required. 

At the time of writing, the three identified profiles are: Yellow, Purple 
and Blue. Only the Yellow and Blue are being deployed in the PCP and 
only the Yellow has been currently standardised by EUROCONTROL. 

The  reasoning  behind  SWIM  Profiles  acknowledges  the  difficulty  to 
establish  one  single  specification  that  would  satisfy  all  performance, 
security  and  availability  requirements  of  all  stakeholders.  Such 
standard  would  be  too  costly  for  many  stakeholders  to  implement. 

24 Link: http://eur-registry.swim.aero  

21/06/2018 

Page 39 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Therefore, SWIM proposes a limited set of modular specifications (i.e. 
the profiles) grouped according to coherent needs. 

•  SWIM-TI Interface Bindings, which are “the definition of a set of protocols 
and standards describing a dedicated interface supported by the SWIM-TI”. 

The Technical View displays the current identified SWIM Technical Entities and their 
interfaces in the following picture. 

Figure 15: SWIM-TI Technical Architecture View 

In  the  picture,  the  arcs  labelled  with  i1,  i4,  and  i5  indicate  the  interoperable 
interfaces between the same profiles, which use their respective interface bindings. 
i2 and i3 indicate Identity management Interface and Registry Interface, which can 
be accessed by any profile using dedicated interface bindings. 

3.3.1.2.1  Focus: SWIM-TI Profiles 
A high-level rationale of the three available profiles  is provided below, as found in 
the SWIM ADD. 

Yellow Profile (best effort) 

Many types  of  information  sharing  in  ATM  do not  have  an  immediate 
high safety critical context and can be satisfied by infrastructure that is 
less demanding and less sophisticated. Many services can be satisfied 
by  a  middleware  providing  generic  functionality  with  a  "Best  Effort" 
QoS.  

21/06/2018 

Page 40 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

SWIM-TI’s Yellow Profile (YP) is explicitly targeted at:  

Support for a wide variety of interactions in a flexible manner and 
that is affordable for the service consumer.  

The  interaction  must  be  able  to  run  over  Internet  and  must  be 
sufficiently secured  

Use of technology based on the Web Services stack of standards  

The  technology  must  be  supported  out-of-the-box  by  the 
mainstream development frameworks as well as mainstream execution 
frameworks.  

Keeping as many options open as possible re deployment.  

Blue Profile (rock solid) 

Certain  types  of  information  sharing  in  ATM  take  place  under  a  high 
safety critical context and hence, the requested infrastructure needs to 
be  ready  to  support  demanding  requirements.  These  types  of 
information  share  demand  to  be  reliable  and  to  deliver  the  required 
performance.  This  set  of  supported  demands  is  usually  identified  as 
“Rock Solid” QoS, meaning that is trustable and not easily breakable. 
SWIM-TI’s Blue Profile (BP) is explicitly targeted at:  

Real-time or near real-time uses  

Extremely high availability  

Secured interactions  

Severe constraints with respect to the available resources  

Purple Profile (air-ground communications) 

Some types of information sharing in ATM are performed in challenging 
conditions and/or constraints and need specific infrastructure.  SWIM-
TI’s Purple Profile (PP) is explicitly targeted at:  

High latency and/or low bandwidth conditions  

Need  to  minimize  the  communication  overhead  and  transport 
connection number due to high cost of use of the communication 

Intermittent  and  unpredictable  availability  of  end-to-end 
connectivity over the communication infrastructure  

21/06/2018 

Page 41 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Facilitate  Security  controls  through  constraints  in  the  interaction 
patterns  

A permanent need for time, space and synchronization decoupling 
between participants (asynchronous operations)  

Simple and easily certifiable information producers and consumers  

SWIM  Profiles  are  not  atomic  by  themselves.  For  instance,  the  Yellow  profile  has 
several modular Profile Parts. 

•  “Core” Yellow Profile: a minimum mandatory solution that is shared by all 

stakeholders. 

•  “Security+” Profile Part, optional, which enhances security features. 

•  “Advanced”  Profile  Part,  optional,  which  has  higher  performance  and 

satisfies additional messaging functional requirements 

•  “Messaging+”  Profile  Part,  optional,  supporting  additional  message 

exchange patterns. 

In the context of Initial SWIM, SESAR R&D work on the SWIM-TI Yellow Profile has 
been  taken  into  account  by  EUROCONTROL  for  its  standardisation  work  on  the 
EUROCONTROL Specification for SWIM Technical Infrastructure (TI) Yellow 
Profile.25 At the time of writing, however, the specification “relates to, but does not 
include,  requirements  for  interfacing  with  infrastructure  services  shared  among 
various  organisations,  e.g.  Public  Key  Infrastructure  (PKI),  Security  Token 
Infrastructure (STI), and Service Registry”. 

3.3.1.3  SWIM-TI Deployment view 

As said, SWIM-TI deployment options of the SWIM Node is entirely dependent on the 
stakeholders specific needs. Therefore, the architecture document does not mandate 
any particular configuration. The document however mentions the several possible 
scenarios. 

25 http://www.eurocontrol.int/sites/default/files/content/documents/single-

sky/specifications/EUROCONTROL-SPEC-170%20SWIM%20TIYP%20Ed%201.0.pdf  
21/06/2018 

Page 42 of 76 

 
 
 
 
 
 
 
 
  
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure  16.  SWIM-TI  and  different  SWIM-TI  Functional  Block  deployment 
options 

Three options are provided: 

CC1: There is no integration between Legacy System and SWIM TI. The 
SWIM Enabled ATM System provides ATM functionality and the SWIM-
TI  SWIM  Profile  enables  the  interchange  of  info  between  the  SWIM 
Enabled ATM System and others. 

CC2:  The  SWIM  Enabled  ATM  System  already  incorporates  the 
necessary SWIM-TI Functional Blocks to ensure the interchange of info 
with other SWIM Enabled ATM Systems. The set of SWIM-TI Functional 
Blocks need to be coherent to one or more SWIM-TI Profiles. 

CC3: It represents the most evolved SWIM Enabled ATM System. On 
it,  the  communications  between  its  Functional  Blocks  is  already  done 
via  a  SWIM-like  mechanism,  implementing  a SWIM  Profile.  It  doesn’t 
need specific SWIM-TI Profiles or SWIM-TI Functional Blocks. 

Several  deployment  options  are  given  also  for  messaging  routing  and  the  PKI  for 
future investigation. 

3.3.2  Communication patterns 

The need of having specific communication patterns is described SWIM-TI Messaging 
FB, within the Distribution function.  

21/06/2018 

Page 43 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

In  practice,  for  SWIM-TI  Yellow  Profile,  the  EUROCONTROL  specifications  (see  
section 3.3.1.2.1) mention the following ones: 

•  R/R, Request Reply (1 to 1, time and process coupled); 

•  aR/R, asynchronous Request Reply (1 to 1, time but not process coupled); 

•  P/S, Publish Subscribe, which can be further specialized into push and pull. (1 

to N decoupled); 

•  FF, Fire and Forget (1 to 1). 

3.4  Technical solution 

3.4.1  Data model 

The SESAR ATM Information Reference Model (AIRM) is the data model adopted by 
SWIM. The document “AIRM Primer26” contains a high-level overview of the AIRM. 

The  SESAR  ATM  Information  Reference  Model  (AIRM)  constitutes  a 
semantic  baseline  for  definition  of  global  and  European  ATM 
information in general and in particular supports current state-of-the-
art  interoperability  developments  that  are  using  information  services 
within SWIM.  

In  particular,  the  AIRM  represents  civil,  military  and  civil-military 
information  constructs  relevant  to  ATM.  This  means  that  information 
constructs from the AIRM can be used, for example, as the information 
elements that are exchanged between nodes in process models or as 
the semantic reference for the definition of the message of a service. 

The document specifies that the SESAR AIRM acts as a “common reference for the 
other  models  developed  as  part  of  SWIM  research  and  development,  and 
deployment”.  Being  a  reference  model,  SESAR  AIRM  is  “independent  of  specific 
implementation standards, technologies, implementations, or other concrete details”.  

The AIRM consists of the following components: 

•  AIRM Primer. The AIRM primer is the entry point into the ATM Information 
Reference Model (AIRM). It provides an introduction to the AIRM and sets it, 
and  each  of  its  components,  into  context.  It  also  outlines  those  documents 
that support the usage of AIRM. 

•  AIRM Information Model. The AIRM Information Model provides a reference 
model for the SESAR information concepts for operational experts. It contains 
entities  and  relationships  relevant  to  the  ATM  operational  discourse  and 
concerns.  

26 See: https://www.eurocontrol.int/sites/default/files/content/documents/sesar/8.1.3.d47-airm-primer-

v4.1.0.pdf  
21/06/2018 

Page 44 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  AIRM  Consolidated  Logical  Data  Model.  The  AIRM  Consolidated  Logical 
Data Model provides a reference model of the SESAR data concepts for service 
architects  and  system  implementers.  It  contains  the  information  elements 
necessary to model the shared information of ATM 

•  AIRM  Foundation.  The  AIRM  Foundation  consists  of  a  Rulebook  and  a 
Library.  The  AIRM  Foundation  Rulebook  provides  principles,  rules  and 
recommendations  for  modellers  creating  contributions  to  the  AIRM  or 
developing and maintaining the AIRM. The rules are intended to be used for 
model  construction,  consolidation,  validation,  verification,  conformance  and 
quality checks purposes. The AIRM Foundation Library contains UML packages 
to support the Foundation Rulebook.  

•  AIRM Glossary. The AIRM Glossary provides a simple dictionary of general 

terms and definitions that are used in AIRM models.  

•  AIRM Constraints Model. The AIRM Constraints Model provides the business 
driven  constraints  which  have  an  impact  on  the  AIRM  Information  Model 
and/or the AIRM Consolidated Logical Data Model.  

Figure 17. Structure of AIRM 

The evolution of AIRM is set in the AIRM Strategy document and its quality criteria 
are described in the AIRM Quality Assurance Handbook. Governance of AIRM is 

21/06/2018 

Page 45 of 76 

 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

performed through a Change Control Board and annual Review Forum. Additional 
source of information on AIRM are its dedicated Website and Wiki27. 

In  the  context  of  Initial  SWIM,  the  PCP  regulation  states  that  “Service 
implementations  shall  be  compliant  with  the  applicable  version  of  AIRM,  the  AIRM 
Foundation Material and the ISRM Foundation Material”. Therefore, SESAR R&D work 
on AIRM served as input for the standardization work performed by EUROCONTROL 
on  the  Specification  for  SWIM  Information  Definition28  in  which  “the 
requirements  ensure  that  information  definitions  conform  to  the  semantics  of  the 
AIRM, the common reference language for iSWIM”. 

3.4.2  Service model 

SESAR’s Information Service Reference Model (ISRM) provides general purpose 
rules  and  guidelines  to  identify,  design  and  validate  information  services  based on 
user needs and information requirements.  

The  ISRM  corpus  includes  the  ISRM  Foundation  Rulebook  which  provides 
standards and vocabularies for the development of ISRM information service models. 

Besides  general  rules  and  rules  on  naming  convention,  the  rulebook  prescribes 
several service modelling rules and in particular 

•  Service Rules (e.g. the indication of message exchange patterns) 

•  Interface Rules (e.g. presence of consumer and provider interfaces) 

•  Payload  Rules  (e.g.  referencing  AIRM  information  model  and  logical  data 

model)  

•  Diagram Rules (e.g. presence of at least one Sequence Diagram) 

In the context of Initial SWIM, similarly to the case of AIRM, the SESAR R&D work 
on  the  ISRM  Foundation  Rulebook  served  as  input  for  the  standardization  work 
performed  by  EUROCONTROL 
for  the  Specification  for  SWIM  Service 
Description29. 

27 For more details on AIRM see:  

• 

• 

• 

• 
• 

AIRM Governance Handbook: 
https://www.eurocontrol.int/sites/default/files/content/documents/sesar/airm-governance-
handbook.pdf  
AIRM Quality Assurance Handbook: 
https://www.eurocontrol.int/sites/default/files/content/documents/sesar/airm-quality-
assurance-handbook.pdf  
AIRM Strategy: https://www.eurocontrol.int/sites/default/files/content/documents/sesar/airm-
strategy.pdf  
AIRM Wiki: http://im.eurocontrol.int/wiki/index.php/Category:AIRM  
AIRM Website: http://airm.aero/  

28 See: http://www.eurocontrol.int/sites/default/files/content/documents/single-

sky/specifications/EUROCONTROL-SPEC-169%20SWIM%20INFO%20Ed%201.0.pdf  

29 See: http://www.eurocontrol.int/sites/default/files/content/documents/single-

sky/specifications/EUROCONTROL-SPEC-168%20SWIM%20SERV%20Ed%201.0.pdf  
21/06/2018 

Page 46 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

3.4.3  Main technical solution(s) adopted to facilitate the implementation 

of the selected architecture 

An attempt to capture SWIM’s end-to-end architecture is summarised in the picture 
below, where building blocks are organised according to a sequential “data sharing 
value  chain”.  In the  picture,  dark orange  boxes  indicate  logical  components,  while 
light orange boxes indicate logical deployment boundaries.  

Figure 18. SWIM-TI Architecture - Logical entities vs deployment boundaries 

The figure highlights the different deployment options of the SWIM Node: 

• 

In a dedicated environment (as in the case of LS1) 

•  As a software component with or without specific adapter (LS2 and LS3) 

The figure shows the common SWIM-TI Functional Blocks, i.e. Registry and PKI (or 
Information  Management  in  general).  Finally,  the  cloud  represents  any  IP-based 
network. 

At network level, public Internet is used at first, with the plan to incrementally use 
the PENS (Pan-European Network Service), which is an international ground/ground 
communications infrastructure jointly implemented by EUROCONTROL and European 
ANSPs. The work on establishing and evolving PENS is also performed under SESAR 
and being deployed in the PCP (ATM Family 5). 

From the point of view of choices of communication patterns and technology choices, 
the EUROCONTROL specifications for SWIM-TI Yellow Profile  (see  section 3.3.1.2.1) 
provides the following summary table of the specified interface bindings. 

21/06/2018 

Page 47 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 19. SWIM-TI Yellow Profile standardised interface bindings 

In the figure, SWIM-TI Yellow Profile possible interfaces are differentiated from each 
other based on messaging and security characteristics:  

•  Exchange cardinality describes whether the information is intended 
to be sent from one endpoint to another or to several ones during the 
exchange (1 to 1, 1 to N).  

•  Time Decoupling determines whether the participating entities need 
to be available at the same time in order to exchange information.  

•  Process Decoupling determines whether the process originating the 
exchange  remains  blocked  until  there  is  a  response  from  the  entity 
addressed. 

21/06/2018 

Page 48 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  Supported  /Specified  MEP  describes  the  capability  to  implement 
(supported) or the availability of a concrete specification to implement 
(specified)  a  certain  MEP:  R/R,  Request  Reply  (1  to  1,  time  and 
processed coupled); aR/R, asynchronous Request Reply (1 to 1, time 
but  not  process  coupled);  P/S,  Publish  Subscribe,  which  can  be 
further  specialized  into  push  and  pull.  (1  to  N  decoupled);  FF,  Fire 
and Forget (1 to 1).  

•  Messaging QoS describes the capability to ensure a certain type of 

delivery (e.g. at most once, at least once, exactly once).  

•  Bandwidth  Efficiency  provides  an  estimate  of  the  bandwidth 

overhead of each of the protocol selections.  

•  Security:  Information  exchanges  are  cryptographically  protected 
ensuring  their  confidentiality  and  integrity  and  enforcing  user 
authentication  and  authorization  access.  Based  on  the  different 
Interface Bindings available, the SWIM TI provides different options 
to  secure  information,  applying  security  at  different  levels:    - 
Transport  Level  Security:  Uses  transport  protocols  (i.e.  TLS)  to 
secure  communications.  Providing  point-to-point  security  and  an 
efficient  information  exchange;  -  Message  Level  Security:  Uses 
message  security  protocols  (e.g.  SOAP  Message  Security,  XML 
encryption) to secure messages individually and independently of the 
transport.  It  is  suitable  when  information  is  routed  through 
intermediary systems and security needs to be ensured end-to-end. 

3.5  Key Findings 

Solution architecture approach 

•  SWIM approach is to establish a Service Oriented Architecture leveraging open 

standards and mainstream technologies. 

•  The scope of SWIM is:  

o  Harmonized  definition  of  information  exchanges  as  Services  (using 

ISRM) 

o  Defined  semantic  interoperability  of  exchanged  information  (using 

AIRM) 

o  Technical interoperability achieved through standardized technological 

profiles (e.g. SWIM-TI Yellow Profile) 

o 

“Common situational awareness” on the available information via the 
SWIM Registry. 

21/06/2018 

Page 49 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  ATM business processes, i.e. what happens behind service interfaces, are out 

of scope of SWIM. 

•  From  a  documentation  perspective,  the  architecture  is  organised  in  three 
views, which is a good practice: functional and technical views (normative), 
and a deployment view (illustrative). 

•  SWIM  use  cases  describe  only  the  interaction  between  service  information 
provider and consumers through the infrastructure. The use cases focus on 
the  lifecycle  of  the  infrastructure  and  the  evolution  of  service  evolution.  In 
other  words,  the  uses  cases  do  not  enter  into  the  details  of  ATM  business 
processes.  

Main architectural building blocks 

•  SWIM  Node  is  a  logical  entity  with  no  specific  deployment  constraints.  The 
sole purpose is to group SWIM functional blocks and allow a given system to 
use the SWIM-TI. Stakeholders have the freedom of choosing the best suitable 
deployment configuration according to their specific needs. 

•  SWIM-TI profiles are limited sets of modular specifications that are grouped 
according to coherent needs. This allows for better technical interoperability 
than having single standard with large footprint. Different stakeholders may 
bind  their  service  to  the  most  suitable  set  of  standards  for  their 
implementation of the service. 

•  The  SWIM  Registry  is  a  common  functional  block  that  contains  information 
about  the  services  available  via  SWIM,  will  be  central  entity  with  data 
replication to affiliate registries for better query performance and availability.  

•  The design-time SWIM Registry will be replaced by a run-time Registry which 
will allow for dynamic binding to services, provision of routing information to 
services, provision of service status information and lookup of policies. 

•  SWIM-TI Identity Management is a common functional block that will take the 

form of two non-mutually-exclusive technologies: 

o  A  Public  Key  Infrastructure  responsible  for  signing,  emitting  and 

maintaining X.509 certificates and revocation lists. 

o  A  Security  Token  Infrastructure  providing  capabilities  to  manage 

security tokens and Identity stores. 

•  The main idea behind SWIM PKI is to introduce a bridge certificate authority 
that  would  allow  to  extend  trust  between  regional  certificate  authorities. 
Technology would allow in principle to achieve a global PKI where certificates 
issued in Europe are recognised also in the U.S., Asia, etc.  

•  A  security  framework  for  the  deployment,  governance,  management  and 
operations  of  the  SWIM-TI  Identity  Management  functions  is  still  under 
discussion.  

21/06/2018 

Page 50 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  The Shared Object functional block ensure that a single logical entity is kept 
up to date by all parties wishing to share information about a specific object. 
All parties use the shared object as a reference and keep it updated with the 
latest  information,  thus  ensuring  consistency  and  freshness  of  data  across 
systems. In SESAR, this is the “Flight Object” shared object. 

•  At network level, public internet is used at first, with plan to incrementally use 
the  PENS  (Pan-European  Network  Service),  which  is  an  international 
ground/ground  communications 
implemented  by 
EUROCONTROL and European ANSPs. The work on establishing and evolving 
PENS  is  also  performed  under  SESAR  and  being  deployed  in  the  PCP. 
Nonetheless, the network level is not in the scope of SWIM. 

infrastructure 

jointly 

Data model 

•  The SESAR ATM Information Reference Model (AIRM) constitutes a semantic 
baseline  for  definition  of  global  and  European  ATM  information.  AIRM 
represents  civil,  military  and  civil-military  information/data  constructs 
relevant to ATM and is managed as a product with dedicated governance. 

•  Among AIRM constituting elements, the AIRM Foundation Rulebook provides 
principles, rules and recommendations for modellers creating contributions to 
the AIRM or developing and maintaining the AIRM. 

•  AIRM is explicitly mentioned in the PCP regulation as the data model for the 

services in SWIM. 

•  EUROCONTROL’s  specifications  referencing  AIRM  show  how  to  provide 
guidance  to  document  semantic  correspondence  to  a  data  model  when 
stakeholders draft new information definitions. 

Service model 

• 

Information  Service  Reference  model  (ISRM)  is  a  model  that  provides  each 
service with a complete description in terms of functionality, behaviour and 
logical interfaces. 

•  As  prescribed  in  the  ISRM  Rulebook,  the  information  that  is  exchanged 
through  a  service  shall  be  traced  back  to  the  AIRM  (ATM  Information 
Reference Model), which ensures that this exchanged information shares the 
same  meaning  at 
its  destination  (i.e.  semantic 
interoperability).  

its  origin  and  at 

• 

• 

ISRM is a platform-neutral service design framework, which means that there 
are no platform or implementation specific details. 

ISRM  is  explicitly  mentioned  in  the  PCP  regulation  as  the  model  for  SWIM 
services. 

21/06/2018 

Page 51 of 76 

 
 
 
 
 
 
 
 
 
  
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

4  GOVERNANCE AND ORGANISATION STRUCTURE 

4.1  Strategic governance and oversight 

4.1.1  Governance of SESAR 

4.1.1.1  Development governance 

Responsibility  for  research  and  development  was  assigned  to  the  SESAR  Joint 
Undertaking which was established by Council Regulation (EC) No 219/200730. SJU 
responsibilities were defined as follows. 

[SESAR Joint Undertaking] shall be responsible for the execution of the 
ATM Master Plan and in particular for carrying out the following tasks: 

-  organising and coordinating the activities of the development phase 
of  the  SESAR  project,  in  accordance  with  the  ATM  Master  Plan, 
resulting  from  the  definition  phase  of  the  project  managed  by 
Eurocontrol,  by  combining  and  managing under  a  single  structure 
public and private sector funding, 

-  ensuring the necessary funding for the activities of the development 
phase of the SESAR project in accordance with the ATM Master Plan, 

-  ensuring  the  involvement  of  the  stakeholders  of  the  air  traffic 
management sector in Europe, in particular: air navigation service 
providers,  airspace  users,  professional  staff  associations,  airports, 
and  manufacturing  industry;  as  well  as  the  relevant  scientific 
institutions or the relevant scientific community, 

-  organising  the  technical  work  of  research  and  development, 
validation  and  study,  to  be  carried  out  under  its  authority  while 
avoiding fragmentation of such activities, 

-  ensuring the supervision of activities related to the development of 
common  products  duly  identified  in  the  ATM  Master  Plan  and  if 
necessary, to organise specific invitations to tender. 

The  internal  organisation  of  the  SJU  is  described  in  the  Annex  of  the  Council 
Regulation. The two main organs are: 

•  The SJU Administrative Board has the responsibility to ensure that the SJU 
complies  with  its  statutory  responsibilities  as  set  out  in  its  establishing 
regulation,  all  other  relevant  legislation  and  the  relevant  European 
Commission financial rules in relation to its use of public funds.  

30 See: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32007R0219&from=EN  

21/06/2018 

Page 52 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  The  Executive  Director  is  responsible  for  the  successful  leadership  and 
management  of  the  SJU  and  for  the  execution  of  the  SESAR  programme 
development phase and is accountable to the Administrative Board, to which 
he reports on a regular basis. 

Four supporting bodies exist 

•  The Programme Committee (PC) 

•  The Scientific Committee  (SC) 

•  The SESAR Performance Partnership (SPP)  

•  The  ATM  Master  Planning  Committee  (created  in  2016)  provides  expert 
advice  and  recommendations  to  the  SJU  Executive  Director  on  the 
maintenance,  execution  and  update  of  the  European  ATM  Master  Plan  and 
contributes  to  maintaining  a  strong  connection  between  the  SESAR 
development and deployment activities. It is composed of representatives of 
the European Commission, EUROCONTROL, the Network Manager, civil users 
of airspace, the military, air navigation service providers, ground equipment 
manufacturers,  airborne  equipment  manufacturers,  airports,  professional 
staff  organisations  in  the  air  traffic  management  sector,  the  SESAR 
Deployment Manager, EASA and Eurocae. 

The SESAR Joint Undertaking signed agreements with 16 partners31 in the Air Traffic 
Management sector for a total amount of €1.9 billion. The Commission contributed 
with €700 million, EUROCONTROL with €700 million and €500 million came from the 
members over a period of seven years.  

4.1.1.2  Deployment governance 

SESAR deployment governance was defined in the regulation 409/2013 (Chapter III, 
Section  1).  Three  levels  are  provided:  policy  level,  management  level,  and 
implementation level. 

At  policy  level,  the  Commission  is  responsible  for  issuing  common  projects  and 
monitoring the activities of the Deployment Manager. 

At  management  level,  the  Deployment  Manager32  is  responsible  for  developing, 
maintaining and implementing the Deployment Programme. In particular these are 
SDM’s responsibilities.: 

31 Air navigation service providers: AENA (Spain), DSNA (France), DFS (Germany), ENAV (Italy), NATS 

(En Route) Limited (United Kingdom) and NORACON (Northern Europe and Austria); 

Ground and aerospace manufacturing industry: Frequentis, Indra, NATMIG, SELEX Sistemi Integrati and 

Thales; 

Aircraft manufacturers: Airbus and Alenia Aeronautica; 
Airports: AENA, SEAC (a consortium of six airport operators: ADP, BAA, Fraport, Munich, Schipol & 

Unique) and NORACON; 

Airborne equipment manufacturers: Honeywell and Thales. 
32 The Commission selected the SESAR Deployment Alliance (SDA) as the entity to perform the SDM 

function until 31st December 2020. SDA is an international association composed of leading airlines, 
airports and air navigation service providers.  
21/06/2018 

Page 53 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

(a)  developing,  proposing,  maintaining  and 
deployment programme; 

implementing  the 

(b)  associating  the  operational  stakeholders  that  are  required  to 
implement common projects;  

(c)  establishing  mechanisms  and  decision-making  processes  that 
ensure  efficient  synchronisation  and  overall  coordination  of  the 
implementation  projects  and  the  related  investment  in  line  with  the 
deployment programme; 

(d) ensuring effective management of risks and conflict of interest; 

(e) advising the Commission on issues related to the implementation of 
common projects and to the setting up new common projects;  

(f)  implementing  Commission  decisions  and  ensuring  and  monitoring 
their implementation by the implementation level; 

(g) identifying the most appropriate financing mechanisms combining 
public and private funding; 

(h) monitoring implementation of the deployment programme;  

(i) reporting to the Commission; 

(j)  ensuring  appropriate  coordination  with  National  Supervisory 
Authorities. 

The  Deployment  Programme  is  the  “sole  reference  for  PCP  implementation”, 
therefore, in order for implementing partners (e.g. ANSPs, airlines, airports) to access 
funds,  their  requests  need  to  be  compliant  with  the  deadlines  and  open  gaps 
described in the programme. For this purpose, the SDM also supports implementing 
partners in drafting their proposal and acts as a “gateway” to EC Funds33.  

At  implementation  level,  it  is  responsibility  of  the  implementing  partners  to 
execute  the  common  projects  through  the  realisation  of  Implementation  Projects 
(IP). 

33 In SESAR, funds are granted by INEA according to the Connecting Europe Facility (CEF) Multiannual 

Work Programme 2014-2020. 
21/06/2018 

Page 54 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 20. SESAR deployment governance. Source: EC 

A structured legal framework, the SESAR Framework Partnership Agreement34, 
is at the basis of the interactions among the 3 layers.  

4.1.2  Governance of SWIM 

The concepts concerning SWIM Governance were first developed during SESAR 1 (WP 
8). Therefore the following paragraphs are based on the information found in SESAR 
1 deliverables.  

The reader shall keep in mind that the concept of SWIM governance is still evolving 
from  the  original  ideas  of  SESAR  1.  At  the  time  of  writing,  work  is  ongoing  under 
SESAR 202035. 

Moreover, in the context of deployment, the reviewed documentation highlighted that 
these concepts will have to be tailored to the prevailing view on the appropriate level 
of governance that will emerge during the PCP. 

The elements that were proposed under SESAR 1 were: 

•  Essential requirements for SWIM Governance36. 

•  SWIM Governance Structure, which is made of several governance groups. 

• 

Information Management (IM) functions, which are mapped to the governance 
groups. 

34 See: http://www.sesardeploymentmanager.eu/wp-content/uploads/2015/11/Annex-18-SESAR-

Framework-Partnership-Agreement-FPA.pdf  

35 Project reference: PJ17 SWIM-TI. See: 

- 
- 

SESAR JU: https://www.sesarju.eu/projects/swim-ti  
CORDIS: https://cordis.europa.eu/project/rcn/206402_en.html  

36 See: DEL08.01.01 D52 SWIM Foundation v2 

21/06/2018 

Page 55 of 76 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

• 

Interactions  between  IM  functions  and  the  governance  structure, which  are 
documented as: 

o  Use cases 
o  Governance processes. 

The next subsections will provide a brief overview of these elements with references 
to the source documents for the complete available details. 

4.1.2.1  Essential requirements 

Under SESAR 1, the SWIM Foundation document lists the Essential Requirements as 
“the  minimum  set  of  requirements  which  are  absolutely  necessary  for  defining 
SWIM”. Essential requirements for SWIM Governance are summarised below:  

Table 1. Essential requirements for SWIM Governance 

ID 

Requirement description 

GOV-01 

The  operation  and  evolution  of  SWIM  shall  be  governed  by  a 
SWIM  Authority  consisting  of  the  necessary  bodies  that 
represent the SWIM stakeholders’ interests. 

GOV-02 

Policies should be defined under the responsibility of the SWIM 
Authority on the following subjects: 

1. 

2. 

3. 

4. 

5. 

6. 

Service Management 

Compliance Assessments 

Information Security  

Financial Management (not foreseen for iSWIM) 

Supervision (not foreseen for iSWIM) 

Legal Aspects (not foreseen for iSWIM) 

GOV-03 

GOV-04 

GOV-05 

A  design-time37  SWIM  registry  shall  be  created  under  the 
responsibility  of  the  SWIM  Authority  in  order  to  enable  the 
discoverability of, access to, and support of the management of 
SWIM information services. 

The  design-time  SWIM  Registry  shall  contain  information 
necessary to discover and access services. 

The  SWIM  Authority  shall  declare  the  applicable  SWIM 
Controlled  Vocabulary  with  the  purpose  of  defining  the 
common set of terms used by the SWIM community. 

37 The concept of SWIM registry will evolve from design-time to run-time under SESAR 2020 used to 

dynamically discover and connect to SWIM services 
21/06/2018 

Page 56 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

GOV-06 

The  SWIM  Authority  shall  take  account  of  the  following 
principles: 

1.  Steering content. The SWIM Foundation is constituted 
of  a  set  of  steering  SWIM  elements  deemed  to  have  a 
converging impact and used by the communities working 
on standardised SWIM solutions. 

2.  Technology agnostic. The SWIM Foundation should not 
include  specific  technical  choices  at  the  implementation 
level.  

3.  Performance  based  approach.  The  intent  is  to  avoid 
being  too  prescriptive.  In  practice  it  may  though  be 
necessary 
for  some  specific  aspects  some 
prescriptive  technical  specification  may  still  be  required 
to  be  included  in  the  SWIM  Foundation.  However  the 
intent is to minimize this. 

that 

4.  One  SWIM  Foundation.  The  SWIM  Foundation  is  a 
single  item  used  in  multiple  contexts  (e.g.  the  service 
developments, data standardisation within a community 
of interest specifying a data exchange model). 

The  SWIM  Authority  shall  establish  the  applicable  list  of 
standards and guidance to deploy SWIM 

In the areas of Information, Information Service and Technical 
Infrastructure,  normative  compliance  criteria  shall  ensure  the 
ability to adhere to the governing standards. When a governing 
standard 
is  accompanied  by  a  normative  compliance 
framework it shall ensure at a minimum the following aspects: 

1.  The ability for adherence to the governing standard; 

2.  The validity period of the compliance assessment result; 

3.  The renewal process; and 

4.  The  resolution  process  for  any  issues  identified  during  the 

compliance assessment. 

GOV-07 

GOV-08 

4.1.2.2  Governance Structure 

The proposed governance bodies from SESAR 1 are depicted in Figure 26 below38. 

38 This organisational structure was approved as fit for purpose by the A6 Steering Board in Q4/2014. 
The governance structure proposed is modelled with the successful PENS governance approach as a role 
model. For more details, see: 08.01.01 D47 SWIM Governance Structure. 

21/06/2018 

Page 57 of 76 

 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Figure 21: SWIM proposed governance structure 

SWIM governance bodies are briefly described as follows. 

The SWIM Steering Group (SSG) has to represent the interests of all 
SWIM  stakeholders  and  shall  oversee  the  operational  and  strategic 
development  of  SWIM. It  shall  steer  the  other governance  bodies.  In 
this regard it provides direction to the SMU for the collaboration with 
the SWIM Users and to the SEG for their technical advice provision. 

The SSG is the decision making body for general topics which have a 
broad  technical,  strategic,  political,  financial  or/and  organisational 
impact.  It  serves  as  the  final  escalation  body  for  disagreements  on 
changes, problems or improvement suggestions.  

In addition it has to ensure the coordination with the outside world on 
a global and European level, e.g. Deployment Manager, SESAR 2020, 
ICAO, EUROCAE, etc. 

The SWIM Expert Group (SEG) has to provide technical and financial 
advice to the SSG.  

The internal setup of the SEG will specifically address in a well-managed 
way  the  SWIM  elements  related  to  information  (AIRM),  or  related  to 
SWIM services, or related to the SWIM registry. 

The SEG shall report to the SSG on assigned SWIM elements addressing 
current and future operations and requirements of SWIM, including the 

21/06/2018 

Page 58 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

provision  and  maintenance  of  those  SWIM  elements  (e.g.  SWIM 
Policies, SWIM Foundation elements, guidance material). 

The SEG conducts the SWIM change management activities. 

The  SEG  provides  technical  solutions  on  delegated  problems  (e.g.  as 
reported by the SMU). 

The SWIM Management Unit (SMU) has to ensure the effective and 
efficient 
implementation  of  changes,  problem  solutions  and 
requirements  concerning  SWIM  Services  and  SWIM  Technical 
Infrastructures.  

The SMU shall carry out the day to day management of SWIM, including 
implementation  planning  and  service  monitoring  for  safety  and  time 
critical information services and common infrastructure services.  

The SMU supports (e.g. by taking care of reported problems) the SWIM 
Service  Consumers  (SSC)  and  manages 
the  SWIM  Common 
Infrastructure Service Providers (SCSP). Thereto the SMU ensures the 
provision of common infrastructure services (e.g. the SWIM Registry). 

The SMU supports stakeholders with conformance reporting according 
to  the  SWIM  Compliance  Framework.  Thereto  the  SMU  supports  the 
SWIM  Service  Providers  (SSP)  by  supplying  needed  materials  and 
assistance to enable compliant service provisioning in accordance with 
the effective rules and policies.  

The SWIM Users are not part of the SWIM Governance structure but 
are  representing  the  main  SWIM  stakeholders.  SWIM  Users  comprise 
SWIM Providers and SWIM Service Consumers (SSC). They are not 
represented  by  a  single  group,  but  are  independent  actors,  whereby 
both  the  SSC  and  the  SWIM  Providers  have  common  interests.  The 
notion of SWIM Providers is an umbrella term for the SWIM Service 
Providers  (SSP)  and  SWIM  Common  Infrastructure  Service 
Providers (SCSP)39. 

The Terms of Reference (TOR) of the SWIM governance bodies define the roles, 
tasks and relationships between the governance bodies as well as a description of in- 
and outputs. References to the engineering artefacts of the IM Functions, i.e. the IM 
Functions requirements. 

39 Definition: “The SWIM Common Infrastructure Providers (SCSP) supply common functionalities needed 

by providers and consumers of information services to technically establish a secure usage of SWIM 
services.”  
21/06/2018 

Page 59 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

4.1.2.3  Information Management (IM) Functions 

IM Functions are defined as “those needed for the operation and evolution of SWIM”. 
They are the functions for the provision, distribution, sharing and use of information 
provided by the European ATM Information Services.  

[Information Management functions] should be applicable to all SWIM 
participants  to  ensure  the  interoperability  that  leads  to  the  effective 
exchange of information. 

As a first proposal resulting from SESAR 1, SWIM IM Functions were grouped under 
three groups: “steering”, “policy management” or “governed’ functions”, as shown in 
Figure 25. These are briefly described below. 

The steering functions are the functions that guide and steer the SWIM evolution. 
They  also  cover  the  actual  overall  SWIM  governance  process.  The  ‘steering’  IM 
Functions  have  a  direct  influence  on  the  ‘policy  management’  and  ‘governed’  IM 
Functions. 

Steering function 

Responsibilities / Purpose (non exhaustive) 

Overall Governance 
Management 

Global Co-ordination 

SWIM Evolution 
Management 

Implementation Co-
ordination 

Set and supervise the strategy, policy, principles and 
common  procedures  for  the  SWIM  Governance. 
Identify and establish the relevant decision bodies to 
perform change management on the various elements 
that  build  the  SWIM  Foundation,  standards  & 
guidelines. 

Ensure  global  consistency  and  compliance  with  all 
applicable  rules  and  regulations  by  liaising  with 
international standards bodies and regulatory bodies 

Provide the overall control for the SWIM standards and 
SWIM  Common  Infrastructure  Services.  Evaluate, 
approve  or  reject  change  request  to  SWIM  elements 
like  the  SWIM  Foundation,  SWIM  Guidance  Material 
and SWIM Standards. 

Perform 
requests 
impact  analyses  on  change 
impacting  SWIM  TI,  service  descriptions  and/or 
service  instances  that  require  overall  coordination. 
Define appropriate transition plans and co-ordinate the 
execution of such plans. 

The  policy management  functions  create  and  maintain  the  policies  for  the  areas 
covered by SWIM services (financial, compliance, supervision, etc.). 

21/06/2018 

Page 60 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Policy management 
function 

Financial Policy 

Responsibilities / Purpose (non exhaustive) 

Manage (define and update) the financial policy related 
to  funding  and  charging  of,  e.g.,  SWIM  governance 
structures,  provision  of  common  components  or 
services, compliance assessment activities, audits.  

Information Security 
Policy 

Manage (define and update) the information security 
policy  applicable  to  SWIM,  according  to  security 
requirements.  

Service Policy 
(including Registry) 

Compliance Policy 

Supervision Policy 

Legal Aspects Policy 

Manage  (define  and  update)  Service  Lifecycle  policy, 
including  the  Registry  policy.  The  service  lifecycle 
comprises  several  steps  that  a  service  needs  to 
traverse from its inception to its deprecation and the 
artefacts to be produced.  

Manage  (define  and  update)  the  SWIM  Compliance 
Principles and Criteria (on the basis of existing SWIM 
Compliance  Principles  and  Criteria  documents).  This 
Compliance  policy  may  cover  items  (objects  under 
assessment)  such  as  service  definitions;  service 
Instances, SWIM infrastructure (e.g. SWIM nodes) etc. 

Manage  (define  and  update)  the  SWIM  Supervision 
policy.  It  may  cover,  inter  alia,  the  need  for  SWIM 
Supervision  (e.g.  Configuration  Management,  Fault 
Management,  Performance  Management,  etc.)  at 
various  levels,  which  may  be  local,  FAB/sub-regional 
and/or the European level (e.g. through the use of a 
Common Service). 

Manage (define and update) the SWIM Legal Aspects 
policy,  which  covers  topics  such  as  intellectual 
property rights, liability, limitation of use of some data, 
legal frameworks for incident analysis. 

The governed IM functions are classified as such because their scope is defined / 
delimited by the steering and policy management functions. 

Governed IM function 

Responsibilities / Purpose (non exhaustive) 

Financial Management 

Implement the actions set out in the Financial Policy 

21/06/2018 

Page 61 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Information Security 
Management 

Implements  the  Information  Security  Policy  through 
concrete actions. 

Supervision 

Compliance 
Assessment 

Implement  and  maintain  the  “common”  information 
security services specified in the Information Security 
Policy, e.g. provision and operation of the PKI. 

Implement the tasks defined by the Supervision Policy, 
which depend on the content of the policy. 

level  to  service 
Assign  the  correct  compliance 
providers.  Depending  on  the  Compliance  Policy, 
perform  the  actual  assessments  or  instruct  third 
parties to do so. 

Service Management 
(including Registry) 

Offer SWIM services in compliance with the applicable 
policies. 

Maintain  the  information  related  to  services  in  the 
Registry  (definitions,  instances,  attributes,  access 
rights, etc…) 

21/06/2018 

Page 62 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

Steering functions

Overall Governance 
management

SWIM Evolution
 management

Implementation 
coordination

Global coordination

Policy management functions

Financial Policy

Supervision Policy

Information Security 
Policy

Service Policy 
(including registry)

Compliance Policy

Legal Aspect Policy

Governed functions 

Financial management

Service management
(including registry)

Compliance Assessment

Information Security 
management

supervision

Figure 22: IM Functions 

Governance functions are assigned to one or more governance bodies according to 
the following preliminary mapping. 

Table 2. IM functions mapping to SWIM governance bodies 

21/06/2018 

Page 63 of 76 

 
 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

4.1.2.4  Use cases and governing processes 

In  order  to  “ensure  the  completeness  and  consistency  of  the  IM  Functions”  listed 
above,  SESAR  1  detailed  a  number  of  governing  processes,  which  were  mapped 
against  uses  cases  from  SWIM  Concept  of  operations  and  IM  functions.  As  in  the 
previous  cases,  the  information  found  in  SESAR  1  documents  is  expected  to  be 
expanded and refined during SESAR 2020 R&D activities and PCP deployment. 

Then, each use case has been detailed and assigned to SWIM Governing Processes, 
as shown in the table below. 

SWIM Governing process 

SWIM ConOps Use cases 

SWIM  Service  Design  Management 
Process 

UC03; A stakeholder proposes a new or 
upgraded service definition 

SWIM Service Deployment Management 
Process 

UC05;  A  provider  proposes  a  new  or 
upgraded service instance 

UC06; A provider develops a new service 
instance 

The 

UC08; 
Governance 
“SWIM 
Authority”  /  provider  assesses  the 
compliance of a service instance UC09; 
A  provider  deploys  a  new  or  upgraded 
service instance on SWIM 

UC11;  A  provider  decommissions  a 
service 
the  SWIM 
infrastructure. 

instance 

on 

SWIM Standards Management Process  UC04; The SWIM Governance Authority 
manages  the  lifecycle  of  the  reference 
models 

UC07;  A  Stakeholder  upgrades  the 
SWIM infrastructure  

UC12; The SWIM Governance Authority 
deprecates a service definition 

SWIM Stakeholder Management Process  UC01; A stakeholder joins SWIM 

UC02; The SWIM Governance Authority 
assesses a stakeholder 

Finally, each process has been drawn as sequence diagram showing the interactions 
between  governance  groups.  E.g.  the  picture  below  shows  the  Service  Design 
Management process. 

21/06/2018 

Page 64 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

4.1.3  Deployment status of the PCP – SWIM Governance deployment 

action plan 

One of the risks identified in the SESAR Deployment Programme 2015 was the late 
definition or failure to establish SWIM governance, which would slow down the 
implementation of SWIM technology and would affect the realisation of the full PCP. 
This risk materialised in 2016, when the delayed establishment of SWIM Governance 
was recognised as a blocking factor for implementation and full operation of SWIM, 
which was also confirmed by our interviewees. 

As  a  mitigation  action,  the  Commission  tasked  the  SDM  to  define  a  SWIM 
Governance  deployment  action  plan,  which  was  defined  in  the  Deployment 
Programme 201640. The plan reiterates that: 

The  lack  of  SWIM  Governance  will  highly  increase  the  risk  on  SWIM 
Deployment as it is intended and mandated by the PCP and will most 
likely  compromise 
interoperability  between  ATM 
stakeholders. 

the  required 

The action plan urges all stakeholders to use the initial input of SESAR 1 (presented 
in  the  previous  sections)  and  to  any  other  relevant  initiatives41  as  inspiration  for 
further develop and finally implement SWIM governance. 

“Three evolutionary steps” are envisaged towards a full SWIM governance: 

40 See: SESAR Deployment Programme 2016, Strategic View - Addendum 2, SWIM Governance Action 

Plan 

41 The document mentions the governance of, for example, the new Pan European Network Services 
(NewPENS) network, which is being deployed under PCP Family 5.1.2, or the governance through 
Change Control Boards of the exchange models AIRM, AIXM, WXXM, FIXM. 
21/06/2018 

Page 65 of 76 

 
 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

- Refinement of the SWIM Governance specifications developed 
during  SESAR  1  […].  This  comprises  the  elaboration  of  the  Terms  of 
Reference  of  the  relevant  governance  bodies,  the  specification  of  the 
main  processes  of  governance,  the  specification  of  the  compliance 
framework  etc.  Extensive  stakeholder  consultation  forms  an  integral 
part of this stage. During this stakeholders can raise any concern with 
the proposed arrangements, suggest changes etc. The ultimate goal is 
to arrive at SWIM Governance arrangements that are widely accepted 
by the stakeholder community and are ready for deployment in the next 
step. 

- Initial execution of SWIM Governance: During this step the SWIM 
Governance  will  be  in  operation,  although  not  all  processes  and 
functions will be executed from the beginning. Processes and functions 
will  be  added  to  the  operation  as  they  mature  and  are  required; 
likewise, SWIM Governance policies will be adapted.  

- Full execution of SWIM Governance: This is the final, steady-state 
during  which  SWIM  Governance  will  be  fully  operational.  Final  legal 
agreements for SWIM Governance are expected to be clarified (and in 
place  when  needed)  and  a  mechanism  for  financing  the  SWIM 
Governance (if applicable) is expected to be functional. 

In  terms  of  operational  actions,  SDM  proposed  a  plan  in  two  phases,  which  were 
further revised in 2017 as shown in the picture below. 

21/06/2018 

Page 66 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

The current status can be summarised as follows42. 

Since  the  publication  of  the  Deployment  Programme  2016,  the 
execution of the SDM SWIM Governance Action Plan detailed in DP 2016 
has started.  

In  particular,  Phase  1,  a  set  of  4  targeted  actions  by  a  group  of 
stakeholders  supported  by  SDM  [activities  in  light  grey],  has  been 
completed,  while  Phase  2,  the  execution  of  the  SWIM  Governance 
Deployment  Implementation  Project  [activities  in  dark  grey],  has 
started. […] 

The  current  focus  lies  on  defining  the  Terms  of  Reference  for  the 
Governance  bodies  as  well  as  the  essential  policies  guiding  the 
SWIM Governance execution. The end of the project is scheduled for 
July 2019.  

42 See: SESAR Deployment Programme – Planning view 2017 – pp10-11. 

21/06/2018 

Page 67 of 76 

 
 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

4.2  IT service governance 

SWIM service management is a responsibility that is shared among IM functions. 

In the context of SESAR 1, a preliminary mapping between ITILv3 framework and 
IM functions was performed using a RACI matrix, highlighting that “SWIM will see a 
split responsibility between IM Functions that provide a central steering and Functions 
that are carried out by a local service provider. In some cases a global accountability, 
responsibility  or  consultancy  is  complemented  by  a  local  one  that  fulfils  the  IM 
Function on a local level”. 

The  design  of  a  new  SWIM  service  can  be  triggered  by  a  stakeholder  who  has  an 
information need, by a data provider or by a service provider.  

The  service  design  might  be  financed  through  public  funding  (e.g.  in  case  of  a 
mandatory service change due to regulations) therefore the Financial Policy needs to 
be taken into account.  

The Service Lifecycle Management is the governing process where the main part 
of the service design is accomplished. [42] 

Concerning  Service  Level  Agreements,  according  to  the  public  available 
documentation,  SWIM  service  monitoring  and  standardised  SLAs  are  still  not  well 
defined in detail. 

Performance management functions of the SWIM Registry shall include functionalities 
aiming at managing policies lifecycle, including monitoring and reporting SLAs. Some 
examples are given in the SWIM Architectural Definition document: 

The  SLA  will  typically  contain  non-functional  requirements  such  as 
mean time between failures (MTBF), mean time to repair or mean time 
to  recovery  (MTTR),  and  other  measurable  metrics  such  as  response 
times. 

However,  no  further  information  has  been  found  on  how  SLAs  shall  be  defined  or 
negotiated between providers and consumers. 

4.3  Information Security / Cybersecurity 

Cybersecurity and the establishment of a Public Key Infrastructure are the focus of 
two distinct SESAR Deployment Programme’s Families. 

•  Family 5.1.4 for the common part dealing with the definition of common 

specifications relating to PKI and its governance. 

•  Family 5.2.3 for the implementation of PKI at the stakeholders. 

For the common part, the DP mentions the following specifications to be developed: 

•  Processes related to signing, emitting, maintaining and revoking certificates 

21/06/2018 

Page 68 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

•  Objectives and requirements for: 

o  Confidentiality 
Integrity 
o 
o  Non-repudiation 
o  Accountability 
o  Authenticity 
o  Safety 
o  Rules and processes for delegating a certificate. 

In  late  2017,  the  project  “SWIM  Common  PKI  and  policies  &  procedures  for 
establishing a Trust Framework” was launched at EUROCONTROL to cover family 
5.1.4. The project’s description, scope and objectives are listed below43. 

The project aims at developing and deploying a common framework for 
both integrating local PKI deployments in an interoperable manner as 
well as providing interoperable digital certificates to the users of SWIM. 
The resulting PKI and its associated trust framework, which will be part 
of the cyber security infrastructure of aviation systems, are required to 
sign, emit and maintain digital certificates and revocation lists 
as required in the family 5.1.4. The digital certificates will allow user 
authentication  and  encryption/  decryption  when  and  where 
needed  in  order  to  ensure  that  information  can  be  securely 
transferred.  All  aviation  Stakeholders  (ANSPs,  Airspace  users,  MIL, 
Airport, etc …) will benefit from the project. 

The scope of the project includes the definition and development of a 
dedicated common PKI and its associated trust framework for 
Europe, its integration and validation with some Stakeholders. It will 
ensure  the  interoperability  of  digital  certificates  within  Europe 
and with other regions.  

The  project  also  aims  at  preparing  the  development  of  the  systems 
needed to operate a PKI and its associated trust framework in order to 
produce and manage digital certificates, e.g. Certification Authorities, 
validation services such as OCSP (Online Certificate Status Protocol) or 
CRL (Certificate  Revocation  List), user  interfaces,  systems  supporting 
the  Registration  Authority  and  Policy  Management  Authority  roles. 
These systems will be developed through procurement, for which the 
project will prepare the Call For Tenders (CFT).  

43 Source: https://www.sesardeploymentmanager.eu/wp-content/uploads/2017/12/3.-Common-PKI-

INEA-2017-Kick-off.ppt  
21/06/2018 

Page 69 of 76 

 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

From a technical perspective, the idea of the project is to develop a Trust framework 
related  to  a  Common  Bridge  PKI  which  would  allow  a  federated  environment. 
Cross-certification among regional or Authority-led bridges (e.g. maintained by ICAO) 
could then constitute an interoperable federated KPI, which in the long term could 
scale up to global level. 

A preliminary diagram of the elements of the SWIM Trust Framework for a Common 
PKI is provided below. 

Figure 23. SWIM Trust Framework for Common PKI 

Our interviewees stressed the importance of establishing a security framework, which 
is key for buy-in of the military. 

4.4  Key findings 

Strategic and operational governance (incl. SLAs) 

•  At  level  of SESAR  research  and  development, the  main governance  body  is 
the SESAR Joint Undertaking, which is responsible for coordinating research 
project and for the maintenance of the ATM Master Plan. 

•  Coordination  of  deployment  activities  is  done  by  the  SESAR  Deployment 
Manager,  who  maintains  the  SESAR  Deployment  Programme  and  acts  as  a 
gateway between stakeholders and European funding.  

•  At  level  of  SWIM,  the  first  ideas  for  the  governance  have  been  defined  in 

SESAR 1 and encompass the following aspects: 

21/06/2018 

Page 70 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

o  Essential  requirements  for  SWIM  Governance,  which  shall  include: 
SWIM authority, SWIM registry, controlled vocabulary, standards and 
guidance to depoy SWIM, and a compliance framework. 

o  SWIM  Governance  Structure,  which  is  made  of  several  governance 

groups. 

o 

o 

Information  Management  (IM)  functions,  which  are  mapped  to  the 
governance groups. 

Interactions between IM functions and the governance structure, which 
are documented as, use cases and governance processes. 

•  SWIM governance  is  being  refined,  in  particular  the  Terms  of  Reference  for 
the  Governance  bodies  as  well  as  the  essential  policies  guiding  the  SWIM 
Governance execution. The target date for completion is 2019. 

•  The delay of establishment of SWIM governance is recognised as one blocking 
factor for the full implementation of SWIM technology that could potentially 
affect the whole Pilot Common Project. 

•  Governance of service monitoring and SLAs is still not well defined in detail. 
Providing SLA guidelines and standards (e.g. agreement templates) is under 
the responsibility of SWIM governance, but no detailed information is available 
yet. 

•  Performance  management  functions  of  the  SWIM  Registry  shall  include 
functionalities aiming at managing policies lifecycle, including monitoring and 
reporting SLAs, however no details are available yet. 

IT Service Management and Information Security 

•  SESAR  Deployment  programme  addresses  the  topic  of  information  security 
and cybersecurity with ATM  families at two levels.  One family (5.1.4)  deals 
with  common  specifications  for  a  common  Public  Key  Infrastructure  and  its 
governance. Another family (5.2.3) focused on the implementation at the level 
of  stakeholders  (in  particular  ANSPs,  Airport  Operators,  Airspace  Users, 
Network Manager, Military Authorities, MET Service Providers). 

•  The  deployment  programme  urges  stakeholders  to  explore  how  current 
technology  can  be  applied  to  the  ATM  domain.  A  PCP  implementing  project 
started in late 2017 with the purpose of covering these common specifications 
for a comprehensive cross-border security framework and is expected to end 
in 2019. The main idea of a SWIM Public Key Infrastructure is to introduce a 
common bridge certificate authority (CA) that each stakeholder’s local CA shall 
trust. This approach would ensure minimal impact on existing infrastructures 

•  One  prerequisite  for  implementation  of  information  security  concepts  is  the 

establishment of SWIM Governance and its governance processes. 

•  Establishing a solid security framework could help get buy-in from the military. 

21/06/2018 

Page 71 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

5  REFERENCES 

[1]   European Commission, “Single European Sky,” [Online]. Available: 

https://ec.europa.eu/transport/modes/air/single_european_sky_en. 
[Accessed 24 July 2017]. 

[2]   SESAR JU, “Objectives,” [Online]. Available: 

https://www.sesarju.eu/approach/objectives . [Accessed 17 July 2017]. 

[3]   European Commission, “Report from the Commission to the European 

Parliament and the Council on the implementation of the Single Sky 
legislation,” 14 November 2011. [Online]. Available: http://eur-
lex.europa.eu/legal-content/en/ALL/?uri=CELEX:52011DC0731. [Accessed 21 
August 2017]. 

[4]   European Commission, “SESAR - Modernising Air Traffic Management in 

Europea,” [Online]. Available: 
https://ec.europa.eu/transport/sites/transport/files/modes/air/sesar/doc/200
8_sesar_brochure_en.pdf. [Accessed 21 August 2017]. 

[5]   European Commission, “Commission staff working paper on preparing a 

deployment strategy for the Single European Sky technological pillar,” 10 
December 2010. [Online]. Available: 
https://ec.europa.eu/transport/sites/transport/files/modes/air/sesar/doc/201
0-sec-2010-1580-f.pdf. [Accessed 4 August 2017]. 

[6]   European Commission, “Commission staff working paper on preparing a 

deployment strategy for the Single European Sky technological pillar,” 10 
December 2010. [Online]. Available: 
https://ec.europa.eu/transport/sites/transport/files/modes/air/sesar/doc/201
0-sec-2010-1580-f.pdf. [Accessed 4 August 2017]. 

[7]   SESAR JU, “SESAR 1,” [Online]. Available: https://www.sesarju.eu/sesar1. 

[Accessed 24 July 2017]. 

[8]   SESAR JU, “Second draft of the SESAR 2020 R&I Programme,” 2014. 

[Online]. Available: 
https://ec.europa.eu/transport/sites/transport/files/modes/air/news/doc/201
4-07-09-sesar/annex-iii.pdf. 

[9]   SESAR JU, “SESAR 2020 membership reflects growing Europe-wide 

commitment to ATM modernisation,” [Online]. Available: 
https://www.sesarju.eu/newsroom/all-news/sesar-2020-membership-
reflects-growing-europe-wide-commitment-atm-modernisation. [Accessed 24 
July 2017]. 

21/06/2018 

Page 72 of 76 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

[10]  SESAR JU, “SESAR History,” [Online]. Available: 

https://www.sesarju.eu/discover-sesar/history. [Accessed 17 July 2017]. 

[11]  SESAR JU, “Vision,” [Online]. Available: https://www.sesarju.eu/vision. 

[Accessed 17 July 2017]. 

[12]  SESAR JU, “SWIM Technology Solution,” [Online]. Available: 

http://www.sesarju.eu/sesar-solutions/swim-technology-solution. [Accessed 
24 July 2017]. 

[13]  Best, “Project Description,” [Online]. Available: 

http://best.futurado.hu/project.html. [Accessed 28 July 2017]. 

[14]  SESAR JU, “SWIM Concept of Operations,” 6 June 2013. [Online]. [Accessed 

25 July 2017]. 

[15]  SESAR JU, “AIR/Ground System- Wide Information Sharing (SWIM),” 

[Online]. Available: 
http://www.sesarju.eu/sites/default/files/documents/wac/SWIMdemo-
08_AG-SWIM_Benefits.pdf. [Accessed 25 July 2017]. 

[16]  Department of International Affairs, NATS, “SESAR Concept Development: an 

ANSP Case Study,” [Online]. Available: 
https://www.sesarju.eu/sites/default/files/documents/atc/NATS_Slides_for_A
TC_Global_v2.pdf. [Accessed 17 July 2017]. 

[17]  SESAR 2020 Programme Overview, 22 March 2017. [Online]. Available: 

http://www.sesarju.eu/sites/default/files/documents/events/Call-infoday-
20170322/2.SESAR2020%20Programme%20Overview.PHO.pdf. 

[18]  E. Commission, Interviewee, [Interview].  

[19]  SESAR JU, “SWIM Governance Structure,” 5 February 2016. [Online]. 

Available: 
http://www.sesarju.eu/sites/default/files/documents/transversal/DEL08%200
1%2001-D47-SWIM%20Governance%20Structure.docx.. [Accessed 18 July 
2017]. 

[20]  “EUCISE2020 Technical Note Draft V0 6.2,” [Online].  

[21]  SESAR JU, “From Vision to Reality,” 2016. [Online]. Available: 

https://www.sesarju.eu/sites/default/files/SESAR_from_Vision_to_Reality_0.
pdf. [Accessed 17 July 2017]. 

[22]  SESAR JU, “European ATM Master Plan - The roadmap for delivering high-

performing aviation for Europe,” 2017. [Online]. Available: 

21/06/2018 

Page 73 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

https://ec.europa.eu/transport/sites/transport/files/modes/air/sesar/doc/eu-
atm-master-plan-2015.pdf. [Accessed 17 July 2017]. 

[23]  European Commission, “Deployment of SESAR,” [Online]. Available: 

https://ec.europa.eu/transport/sites/transport/files/modes/air/sesar/doc/201
1_09_13_workshop_eca_ifatca_atceuc_ifatsea.pdf. [Accessed 17 July 2017]. 

[24]  SESAR, “SESAR 2020 Animation,” 3 March 2017. [Online]. Available: 

https://youtu.be/ArdXq-hV3TY. [Accessed 17 July 2017]. 

[25]  ICAO, “SESAR Definition Phase,” 18 September 2006. [Online]. Available: 

http://www.icao.int/safety/acp/Inactive%20working%20groups%20library/A
CP-WG-C-11/ACP-WGC11-WP30-
SESAR%20Part%201%202%20new%20(JF).ppt. [Accessed 17 July 2017]. 

[26]  Eurocontrol, “SESAR 2020,” [Online]. Available: 

http://www.eurocontrol.int/sesar2020. [Accessed 17 July 2017]. 

[27]  SESAR JU, “SWIM (GG AG ) Architectural Definition - Final,” 15 July 2016. 

[Online]. Available: 
https://www.sesarju.eu/sites/default/files/solutions/01_CN_Solution_46_SWI
M_Technological_Solution.pdf. [Accessed 18 July 2017]. 

[28]  SESAR JU, “The SESAR Concept and SWIM,” [Online]. Available: 

https://www.sesarju.eu/sites/default/files/documents/events/atcglobal2014/
ATC-2014-SWIM.pdf. [Accessed 17 July 2017]. 

[29]  SESAR JU, “SESAR Solutions Explained,” [Online]. Available: 

http://www.sesarju.eu/activities-solutions. [Accessed 24 July 2017]. 

[30]  SESAR JU, “How SESAR 2020 plans to deliver next-wave ATM solutions,” 07 

March 2017. [Online]. Available: 
https://www.sesarju.eu/sites/default/files/documents/press-
releases/2017_03_06%20%20SESAR%202020.docx.. [Accessed 25 July 
2017]. 

[31]  Eurocontrol, “SWIM: the global ATM intranet,” 2016. [Online]. Available: 

https://www.eurocontrol.int/sites/default/files/content/documents/official-
documents/skyway/articles/2016-spring-skyway-swim.pdf. [Accessed 25 July 
2017]. 

[32]  Eurocontrol, “SWIM Concept of Operations,” 06 June 2013. [Online]. 

Available: 
https://www.eurocontrol.int/sites/default/files/publication/files/del08.01.01-
d41-swim_conops.pdf. [Accessed 25 July 2017]. 

[33]  European Commission, “Introduction to the SESAR 2020 Programme 

Execution,” 12 October 2015. [Online]. Available: 

21/06/2018 

Page 74 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

http://ec.europa.eu/research/participants/data/ref/h2020/other/guides_for_a
pplicants/jtis/h2020-pr-exec-intro-ta-ir-vld-sesar-ju_en.pdf. [Accessed 25 
July 2017]. 

[34]  Eurojust, “SWIM: From R&D to reality,” 6 March 2017. [Online]. Available: 

http://www.eurocontrol.int/events/swim-rd-reality. [Accessed 25 July 2017 ]. 

[35]  SESAR JU, “SWIM - State of Play,” [Online]. Available: 

http://www.sesarju.eu/sites/default/files/documents/swim/SMC2014-
State_of_Play.pdf. [Accessed 26 July 2017]. 

[36]  ICAO, “Manual on System Wide Information Management (SWIM) Concept,” 

[Online]. Available: 
https://www.icao.int/airnavigation/IMP/Documents/SWIM%20Concept%20V2
%20Draft%20with%20DISCLAIMER.pdf. [Accessed 26 July 2017]. 

[37]  SESAR JU, “SESAR Solutions Catalogue,” [Online]. Available: 

https://www.sesarju.eu/newsroom/brochures-publications/sesar-solutions-
catalogue. [Accessed 27 July 2017]. 

[38]  SESAR JU, “Contextual note – SESAR Solution description form for 

deployment planning,” [Online]. Available: 
https://www.sesarju.eu/sites/default/files/solutions/01_CN_Solution_46_SWI
M_Technological_Solution.pdf. [Accessed 25 July 2017]. 

[39]  SESAR JU, “Introduction to the SESAR 2020 Programme execution,” 13 April 

2015. [Online]. Available: 
http://ec.europa.eu/research/participants/data/ref/h2020/other/guides_for_a
pplicants/jtis/h2020-pr-exec-intro-er-sesar-ju_en.pdf. [Accessed 26 July 
2017]. 

[40]  SESAR JU, “Factsheets SESAR,” [Online]. Available: 

https://www.sesarju.eu/sites/default/files/Factsheet_SESAR_A4.pdf. 
[Accessed 28 July 2017]. 

[41]  Eurocontrol, “Welcome to the Meteorological Information Exchange website,” 
[Online]. Available: http://www.wxxm.aero/. [Accessed 28 July 2017]. 

[42]  Eurocontrol, “ATM Information Reference Model (AIRM),” [Online]. Available: 

http://www.eurocontrol.int/articles/airm-atm-information-reference-model. 
[Accessed 28 July 2018]. 

[43]  Eurocontrol, “ATM Architecture & Information Management,” [Online]. 

Available: http://www.eurocontrol.int/articles/atm-architecture-information-
management. [Accessed 7 August 2017]. 

21/06/2018 

Page 75 of 76 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for SESAR – Draft outline 

[44]  Eurocontrol, “Air traffic management (ATM) explained,” [Online]. Available: 
http://www.eurocontrol.int/articles/air-traffic-management-atm-explained. 
[Accessed 8 August 2017]. 

[45]  Eurocontrol, “Who we are,” [Online]. Available: 

https://www.eurocontrol.int/articles/who-we-are. [Accessed 18 August 
2017]. 

[46]  SESAR Deployment Manager, “SESAR Deployment Programme (Edition 

2017),” 31 May 2017. [Online]. Available: 
http://www.sesardeploymentmanager.eu/wp-
content/uploads/2016/12/421968-SESAR-Deployment-Programme-edition-
2017-Hfdst-2.pdf. [Accessed 4 September 2017]. 

[47]  European Defence Agency, “The military in SES / SESAR - partnering for safe 

and efficient skies,” 23 February 2016. [Online]. Available: 
https://eda.europa.eu/docs/default-source/eda-publications/eda-sesar-wac-
brochure_light. [Accessed 08 November 2017]. 

21/06/2018 

Page 76 of 76 

 
 
 
 
 
 
 
 
 
 
SC430DI07171 

Structured report on IFC1 

1 This report is based on limited publicly available information   

Date: 21/06/2018 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

Document Metadata 

Property 

Value 

Date 

Status 

21/06/2018 

Approved 

Version 

1.00 

Authors 

Reviewed by 

Andrea Marcato – PwC EU Services 
Lora Van Looveren – PwC EU Services 
Max Stahlecker – PwC EU Services 
Alexandru Chiric – DG MARE 
David Berger – JRC 
Jesus Hermida - JRC 

Approved by  

Alexandru Chiric – DG MARE 

This study was prepared for the ISA Programme by: 

PwC EU Services 

Disclaimer: 

The views expressed in this report are purely those of the authors and may not, in 
any circumstances, be interpreted as stating an official position of the European 
Commission. 

The  European  Commission  does  not  guarantee  the  accuracy  of  the  information 
included in this study, nor does it accept any responsibility for any use thereof. 

Reference  herein  to  any  specific  products,  specifications,  process,  or  service  by 
trade  name,  trademark,  manufacturer,  or  otherwise,  does  not  necessarily 
constitute  or  imply  its  endorsement,  recommendation,  or  favouring  by  the 
European Commission. 

All  care  has  been  taken  by  the  author  to  ensure  that  s/he  has  obtained,  where 
necessary,  permission  to  use  any  parts  of  manuscripts  including  illustrations, 
maps,  and  graphs,  on  which  intellectual  property  rights  already  exist  from  the 
titular holder(s) of such rights or from her/his or their legal representative. 

21/06/2018 

Page 2 of 18 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

Table of Contents 

1 

2 

1.1 
1.2 

2.1 

2.1.1 
2.1.2 
2.1.3 
2.1.4 

2.2 

2.2.1 

2.3 
2.4 

3.1 
3.2 
3.3 
3.4 

4.1 
4.2 
4.3 
4.4 
4.5 

3 

4 

5 

6 

INTRODUCTION ........................................................................................................... 4 

PURPOSE OF THIS DOCUMENT ...................................................................................................... 4 
STRUCTURE OF THIS DOCUMENT ................................................................................................... 4 

VISION AND APPLIED DEVELOPMENT STRATEGY .......................................................... 5 

VISION AND BUSINESS STRATEGY ................................................................................................... 5 
The evolution of IFC .............................................................................................................. 5 
Vision and mission statement, underlying values, goals and objectives .............................. 6 
Value proposition .................................................................................................................. 6 
Customer segments and stakeholders .................................................................................. 7 
DEVELOPMENT STRATEGY ............................................................................................................ 7 
Scope, in terms of countries, agencies, and information services ........................................ 7 
OVERALL DESIGN, DEVELOPMENT, TEST AND ROLL-OUT ..................................................................... 7 
KEY FINDINGS ........................................................................................................................... 8 

OVERALL TECHNICAL ARCHITECTURE AND DESIGN ...................................................... 10 

OVERALL ARCHITECTURAL APPROACH........................................................................................... 10 
ARCHITECTURAL ELEMENTS ........................................................................................................ 10 
TECHNICAL SOLUTION ............................................................................................................... 11 
KEY FINDINGS ......................................................................................................................... 11 

GOVERNANCE AND ORGANISATION STRUCTURE ......................................................... 13 

STRATEGIC GOVERNANCE AND OVERSIGHT .................................................................................... 13 
IT SERVICE GOVERNANCE ........................................................................................................... 14 
INFORMATION GOVERNANCE ..................................................................................................... 15 
INFORMATION SECURITY / CYBERSECURITY ................................................................................... 15 
KEY FINDINGS ......................................................................................................................... 15 

REFERENCES ............................................................................................................... 16 

GLOSSARY ................................................................................................................... 18 

List of Figures 

Figure 1: Example of IFC's MARSEC weekly report [7] ............................................................................... 14 

21/06/2018 

Page 3 of 18 

 
 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

1  INTRODUCTION 

1.1  Purpose of this document 

This document provides an overview of Information Fusion Centre (IFC), which 
is an initiative from the Republic of Singapore Navy that aims at building a common 
and coherent maritime situation picture and acts as a maritime information hub for 
the Southeast Asia region.  

This provided overview is drawn from analysis on publicly available documentation. 
It serves as annex of the deliverable D2.6 Final report. 

The  purpose  of  this  overview  is  to  support  the  key  findings  and  recommendations 
listed in the body of the final study report.  

1.2  Structure of this document 

This document is structured as follows: 

• 

In section 2 the vision and the applied development strategy of the IFC are 
outlined,  with  focus  on  IFC’s  goals  and  objectives,  scope  and  strategy 
development and deployment.  

•  Section 3 provides the overall IT architectural approach of the IFC, including 

architectural building blocks, data models and information services. 

•  Section 4 includes the governance and the organisation structures in place 

for driving IFC in its deployment and operations. 

Finally, within each of these sections, some interoperability aspects are analysed.  

21/06/2018 

Page 4 of 18 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

2  VISION AND APPLIED DEVELOPMENT STRATEGY 

The first part of this chapter will touch upon the evolution of IFC from its 
introduction in 2009. It then provides information on IFC’s vision, mission, and 
value proposition.  

In the second and third part, IFC’s development strategy and overall design, 
development and rollout are explained. Some parts are lacking information as 
publicly available information is limited.    

2.1  Vision and business strategy 

2.1.1  The evolution of IFC 

The paragraphs below give a high-level overview on the establishment and evolution 
of IFC since 2009, based on publicly available information. 

1980 

•  The  South  China  Sea  and  the  Straits  of  Malacca  and  Singapore  saw  a 
significant rise in piracy incidents from the 1980s onwards. Piracy and other 
illicit  activities  have  remained  a  persistent  problem  in  the  Southeast  Asia 
region ever since [1].  

2009 

• 

2011 

IFC is inaugurated on 27 April 2009 by the Republic of Singapore Navy (RSN) 
at Singapore’s Changi Command & Control Centre (CC2C) with the vision of 
strengthening  maritime  security  in  the  region  and  beyond,  by  building  a 
common  and  coherent  maritime  situation  picture  and  acting  as  a  maritime 
information hub for the region [2]. 

•  As  of  April  2011,  ten  countries  have  deployed  International  Liaison  Officers 
(ILOs) to the IFC. ILOs act as linkages between the IFC and their partners to 
facilitate cooperation. Several more countries deployed ILOs later in 2011. 

2012 

• 

Inauguration of the Association of Southeast Asian Nations (ASEAN) Maritime 
Security  Information  Sharing  Exercise,  which  includes  a  Maritime  Security 
Practitioners course and regular workshops on maritime security [1]. 

Since  its  establishment,  the  Singapore  signed  a  series  of  Memoranda  of 
Understanding (MoU) with participating countries as well as data sharing agreements 
with  other  maritime  security  centres,  which  formed  the  legal  basis  on  which  IFC 
operates. More precise information on this legal basis were not available to the study. 

21/06/2018 

Page 5 of 18 

 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

2.1.2  Vision and mission statement, underlying values, goals and 

objectives 

IFC  can  be  defined  as  a  multi-national  maritime  security  information  centre 
established  in  Singapore  that  develops  a  shared  maritime  security  picture  for 
Southeast Asia via the ILO system and information technology [1] [3]. 

Vision 

Its vision to strengthen maritime security is found in multiple documents as follows: 

“IFC’s  vision  is  to  facilitate  information-sharing  and  collaboration  between 
partners to enhance maritime security [4].” 

“IFC’s vision is to strengthening maritime security in the region and beyond, by 
building a common coherent maritime situation picture and acting as a maritime 
information hub for the region. [2]”  

“The  RSN’s  vision  for  the  IFC  is  a  regional  node  for  information  sharing  to 
enhance MDA, this strengthening maritime security [2].” 

Objectives  

This vision of strengthening maritime security is translated into the below objective: 

“IFC  aims  to  deliver  actionable  information  to  regional  partners  for  further 
collaboration or to cue timely operational responses. [2]”  

In  essence,  the  IFC  intends  to  “collate  and  fuse  the  information”;  to  sense-
make information”; and to “deliver actionable information” [5].  

Guiding principles 

No information on guiding principles was shared in publicly available information.  

2.1.3  Value proposition 

IFC’s value is created in the core functions that evolve around [1]: 

•  Alerts & early warning; 
• 
Incident responses; 
•  Sharing of best practises; and 
•  Strategic coordination. 

21/06/2018 

Page 6 of 18 

 
 
 
 
 
 
 
 
 
   
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

This  strategic  coordination  in  specific  is  where  IFC’s  value  for  its  stakeholders  is 
created. The below extract explains in detail the two unique aspects that relate too 
this [2]:  

The  unique  initiative  at  IFC  is  the  presence  of  International  Liaison  Officers, 
working  as  an  integrated  team  with  the  RSN  personnel  on  a  daily  basis.  The 
ILOs  serve  as  the  conduit  to  their  respective  countries’  various  agencies 
operation centres, facilitating the seamless sharing of information between their 
parent agencies and the IFC. Collectively, this enables the pooling of resources 
and expertise, allowing for better shared awareness.  

The  other  unique  feature  of  the  IFC  is  the  extensive  links  that  have  been 
established  both  nationally  and  internationally.  This  is  important  as  a 
cooperative  security  approach  entails  whole-of-government  commitment, 
regional collaboration as well as close links with the global maritime community.  

2.1.4  Customer segments and stakeholders 

IFC’s stakeholders are multi-bilateral and comprise [1] [2]: 

•  National enforcement agencies (customs, defence, immigration, etc. ); 

•  National  maritime  security  agencies  (mainly  military  focus)  (E.g.  Maritime 

Security Task Force); and  

•  The International shipping industry (E.g. Singapore Shipping Association). 

2.2  Development strategy 

2.2.1  Scope, in terms of countries, agencies, and information services 

It was clear from the start that IFC would become the maritime information hub for 
the Maritime security incidents in Southeast Asia. IFC’s scope in terms of information 
types therefore does not only address piracy, but the broader spectrum of maritime 
security  issues,  including  fishery  crimes  and  maritime  terrorism  (but  excluding 
interstate issues such as territorial and maritime boundary disputes) [1].  

IFC’s scope in terms of participating countries developed incrementally as the amount 
of  participating  countries,  agencies  and  liaison  officers  increased  over  time.  IFC 
started  in  2011  with  ILOs  from  ten  countries  (Australia,  France,  India,  Malaysia, 
Philippines,  Thailand,  New  Zealand,  the  United  Kingdom,  the  United  States  and 
Vietnam). [2] The most recent source indicates 111 ILOs from 23 countries [6]. 

2.3  Overall design, development, test and roll-out  

IFC’s  information  technology  (OASIS  &  SMART)  is  fully  operational,  but  unfinished 
and requires continuous improvement. OASIS was developed by the Comprehensive 

21/06/2018 

Page 7 of 18 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

Maritime Awareness Team from the Defence Science and Technology Agency (DSTA) 
of the Singapore government [1].  

Some constraints that IFC experienced are resource and trust related. Both impact 
interoperability which is key for information sharing. The below paragraph explains 
how IFC tries to solve these constraints [2]:   

Despite the obvious utility of information sharing, challenges remain. Firstly, a 
certain  level of  trust  needs  to  be  developed  between  the  various  information 
sharing  partners.  This  willingness  to  share  does  not  come  easy,  as  most 
continue to operate on a ‘need to share’ basis.  

Another  issue  relates  to  maintaining  a  baseline  capability.  Interoperability 
between countries can be impeded due to equipment limitations. In such cases, 
capacity building is key to enable all partners to be able to share on an equal 
footing.  

Maritime  threats  do  not  respect  borders  and  can  only  be  effectively  curtailed 
through strong partnerships. Thus, international collaboration remains the key 
to any working solution. A viable model for such collaboration could be the IFC, 
where cooperation starts from a regional level, with a final goal of linking up to 
form a global information sharing grid.  

The  design,  development,  test,  roll-out  and  other  work  of  the  IFC  is  almost 
exclusively  funded  by  the  Singapore  government  [7]  and  partially  by  other 
participating regional governments [1]. No information on exact numbers was found.  

2.4  Key findings 

The following paragraphs highlight the most relevant findings that can be useful to 
compare IFC to CISE on the topics outlined in this chapter. 

Main evolution milestones 

•  A persistent problem of piracy attacks and other illicit activities in the Southeast 

Asian region since 1980.  

•  The  Republic  of  Singapore  Navy  was  the  driver  in  the  development  of  IFC, 
gradually involving other countries by hosting their representatives (Information 
Liaison Officers) for facilitating communication between navies. 
IFC is operational since 2009. 

• 

Vision, principles, value proposition 

• 

IFC’s value proposition is focused on strengthening maritime security in the 
region through the exchange of information. 

Countries involved 

21/06/2018 

Page 8 of 18 

 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

•  23 countries take part in information exchange (mainly within the Southeast Asia 
region,  but  also  including  European  countries  such  as  France  and  the  United 
Kingdom) 

Sectors (user communities) 

• 

IFC target sectors are:  

o  National enforcement agencies (customs, defence, immigration, etc.); 
o  National maritime security agencies (mainly military); and 
o  Shipping industry. 

Political and regulatory support 

•  The legal basis of IFC operations is provided by: 

o  Memoranda of Understanding (MoU) between Singapore and participating 

countries; and 

o  Data sharing agreements with other maritime security centres. 

•  Funding commitment is provided mainly by the government of Singapore 
•  Participation in IFC is voluntary. 

21/06/2018 

Page 9 of 18 

 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

3  OVERALL TECHNICAL ARCHITECTURE AND DESIGN 

This section presents the overall architectural approach of the IFC, beginning from 
the  overall  architectural  approach  to  the  architectural  building  blocks.  Finally,  we 
outline an overview of the actual technical implementation.  

3.1  Overall architectural approach 

IFC’s  information  technology  is  drawn  on  open  interface  architecture  that  can  be 
customized to different needs [4]. 

3.2  Architectural elements 

IFC’s information technology is built on [1] [4]:  

1.  The  Open  and  Analysed  Shipping  Information  System  (OASIS),  which  is  a 
software  that  contains  vessel  information  and  tracks  it  on  the  basis  of  the 
satellite Automatic Identification System (AIS) and Long Range Identification 
Tracking  System  (LRIT).  In  addition,  OASIS  also  provides  the  basis  for 
different customized portals, including: 

• 

• 

• 

• 

the Malacca Straits Patrol’s Information System (MSP IS); 

the  Western  Pacific  Naval  Symposium’s  (WPNS)  Regional  Maritime 
Information Exchange (ReMIX), providing an internet-based platform from 
which  members  can  access  maritime  information  from  their  home 
countries easily; 

the ASEAN Information-Sharing Portal (AIP); and 

the  ACCESS  2  system,  which  is  an  application  that  operates  through  a 
satellite or internet broadband network and provides a common situation 
picture  as  well  as  a  real-time  secured  communications  linkage  for 
collaboration. 

2.  OASIS  also  provides  the  data  for  an  analytical  tool  called  Sense-Making, 
Analysis and Research Tool (SMART). SMART allows the user to define rules 
and  enables  to  make  links  between  real-time  and  archived  data  that  spans 
organizational, national and time boundaries. Thereby SMART facilitates the 
investigation  of  vessels  across  time  periods  and  identification  of  emerging 
trends. 

Thus, OASIS fuses information and SMART provides the analytical tools to map trends 
and  identify  potential  issues.  Combined  with  the  face-to-face  coordination  of  the 
Liaison  Officers  and  the  chat  facility  the  IFC  hence  provides  an  architecture  for 
maritime security cooperation, rapid reaction as well as analysis.  

21/06/2018 

Page 10 of 18 

 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

3.3  Technical solution 

OASIS is web-based, but also has a mobile version available. It stores information 
and allows efficient communication through chat functionality with a live translation 
tool, by which chat messages are translated into other languages. 

The IFC works with several data entities that is collated from open sources and ILOs 
[4] [8]: 

•  8  types  of  maritime  security  incidents:  Illegal,  unreported  and  unregulated 
(IUU) fishing, piracy, irregular migration, arms trafficking, general maritime 
incidents, contraband trafficking, natural disasters, terrorism;  

•  Vessel  data:  the  system  contains  vessel  information  and  tracks  vessel 

movement on the basis of (IMO, AIS, LRIT); and   

•  Weather and geographical data.  

3.4  Key findings 

Solution architecture approach 

• 

• 

IFC’s  architecture  approach  is  an  open  interface  architecture  that  can  be 
customized to different needs.  

IFCs architecture approach is defined and implemented. 

Main architectural building blocks 

•  The main building blocks of IFC architecture are:  

o  Open and Analysed Shipping Information System (OASIS); and 
o  Sense-Making, Analysis and Research Tool (SMART). 

No detailed information is available 

Service model 

• 

Information not available. 

Data model 

•  The IFC deals with the following information entities. No information on the 

data model was found. 

o  8  types  of  maritime  security  incidents:  IUU  fishing,  piracy,  irregular 
migration,  arms  trafficking,  general  maritime  incidents,  contraband 
trafficking, natural disasters, terrorism. 

o  Vessel data (IMO, Automatic Identification System - AIS, LRIT) 

21/06/2018 

Page 11 of 18 

 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

o  Weather and geographical data 

21/06/2018 

Page 12 of 18 

 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

4  GOVERNANCE AND ORGANISATION STRUCTURE 

This  section  presents  IFC’s  governance  structure,  touching  upon  decision  making, 
stakeholder management and information governance. Limited information is found 
due to lacking publicly available information.  

4.1  Strategic governance and oversight 

The ILOs are key in the decision making of the IFC, but have many more roles and 
responsibilities, as explained below [2] [4]: 

The  IFC  has  set  up  a  24/7  operation  run  by  a  team  of  ILOs  and  Singapore’s 
naval officers who coordinate with their home country agencies, facilitating the 
seamless sharing of information between their parent agencies and the IFC. 

The  ILO  plays  a  critical  role  in  the  operation  of  the  IFC.  As  national  liaison 
officers,  ILOs  provide  a  link  back  to  their  respective  operation  centres  and 
represent their navies and other national agencies. However, the ILO is much 
more than a national linkage as they are also an integrated member of the IFC, 
involved in the day-to-day work and decision making of the IFC.  

Collectively,  this  enables  the  pooling  of  resources  and  expertise,  allowing  for 
better shared awareness. Nascent indications of security trends are identified 
and quickly disseminated to other partners, including the international shipping 
community. 

The  above  explains  that  linkages  are  key  within  IFC’s  operations.  Also  through 
stakeholder management activities that IFC is engaging in, it is creating linkages with 
and amongst stakeholders: 

•  The  IFC  organizes  various  activities  such  as  visits,  information  sharing 
exercises  and  maritime  security  workshops.  For  example,  the  IFC 
organizes the quarterly Shared Awareness Meetings (SAM) which enables IFC 
to reach out, explain and gather feedback on key security issues and trends 
facing the regional maritime security community (including partners such as 
The  Regional  Cooperation  Agreement  on  Combating  Piracy  and  Armed 
Robbery against Ships in Asia (ReCAAP), International Maritime Bureau (IMB) 
and the shipping associations) [2][4].  

• 

In addition, the IFC is also engaged in education, training and exercises, 
for  instance  through  organizing  the  ASEAN  Maritime  Security  Information 
Sharing  Exercise,  a  week-long,  bi-annual  Maritime  Security  Practitioners 
course and regular workshops on maritime security [1].  

•  The  IFC  sends  out  weekly  reports  to  its  stakeholders  with  a  summary  of 
events and incidents, as well as recommendations [9]. The below figure is the 
front page of such a report [10] :  

21/06/2018 

Page 13 of 18 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

Figure 1: Example of IFC's MARSEC weekly report [7] 

These activities aims for the region to shift from a ‘need to share’ to a ‘responsibility 
to share’ and has so far already brought change towards greater information sharing 
for maritime security in the region [2].   

4.2  IT service governance 

No detailed information was found on IT service governance. 

21/06/2018 

Page 14 of 18 

 
 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

4.3  Information governance 

The below extracts explain whom uses the information that the IFC receives and how 
it is managed:  

Participation  in  the  reporting  scheme  of  IFC  is  free  and  voluntarily.  All 
information  received  by  IFC  is  treated  in  strict  commercial  confidence  and  is 
only used by the military and maritime enforcement agency partners [3]. 

As a 24/7 centre, the IFC is well-poised as a maritime information hub to its 
various regional partners. It has a common maritime situation picture collated 
from various information sources, both through its partners as well as through 
new  technologies  such  as  the  AIS  and  LRIT.  This  provides  early  warning  to 
prevent maritime incidents or maritime crime. When the IFC is first alerted to 
an  incident,  the  Duty  Officer  follows  a  dedicated  check  list  and  informs  key 
stakeholders of the incident, while simultaneously forwarding the details to one 
of  its  information  sharing  portals  such  as  the  ReMIX  or  the  MSP  IS.  The 
integrated RSN-ILO team would then examine the collected data and analyse 
the incident. This includes both qualitative and quantitative assessments of the 
information,  including  the  identification  of  any  associated  trends  and  other 
important  enablers  to  the  incident.  Derived  outcomes  would  then  be 
transmitted to the relevant information sharing partners to trigger operational 
responses where applicable [4]. 

It thus looks like the information received is managed via a manual process. Although 
this is not 100% clear at the moment of writing. 

4.4  Information Security / Cybersecurity 

No sufficient information was found on Information Security from publicly available 
documentation. 

4.5   Key findings 

Strategic and operationa governance (incl. SLAs) 

•  111  International  Liaison  Officers  (ILOs)  are  the  national  linkages  between 
Singapore  and  the  other  countries  and  in  charge  of  day-to-day  work  and 
decision making of the IFC.  

IT Service Management and Information Security 

• 

Information is not available. 

21/06/2018 

Page 15 of 18 

 
 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

5  REFERENCES 

[1]   C.  Bueger,  “From  Dusk  to  Dawn?  Maritime  Domain  Awareness  in  Southeast  Asia,” 

Contemporary Southeast Asia Vol. 37, No. 2, p. 157–82, August 2015.  

[2]   POINTER: Journal of the Signaport Armed Forces Supplement, “The Information Fusion 
Centre  (IFC)  -  A  Case  for  Information  Sharing  to  Enforce  Security  in  the  Maritime 
Domain.,” The Information Fusion Centre: Challenges and Perspectives, pp. 3-10, April 
2011.  

[3]   Information  Fusion  Centre,  “Guidelines  for  Shipping  Companies  on  VCR,”  [Online]. 
Available:  https://www.bundespolizei.de/Web/DE/01Sicher-auf-Reisen/03Mit-Schiff-
Boot/02Piraterie-Praevention/Informationen-der-
Sicherheitsbehoerden/_Suedostasien/guidelines-for-shipping-
companies_file.pdf?__blob=publicationFile&v=1. [Accessed 11 January 2018]. 

[4]   MINDEF, “Fact Sheet: Information Fusion Centre (IFC),” 13 February 2015. [Online]. 

Available: 
https://www.mindef.gov.sg/oms/imindef/press_room/official_releases/nr/2014/apr/0
4apr14_nr/04apr14_fs.html. [Accessed 11 January 2018]. 

[5]   F.  E.  Hutchinson  and  T.  Chong,  “Pirates  and  Law  Enforcement  Agencies:  complex 
relations across the Malacca Straits,” in The Sijori Cross-Border Region: Transnational 
Politics, Economics and Culture, Singapore, ISEAS Publishing, 2016, pp. 437 - 438. 

Available: 

[6]   MINDEF  Signapore,  “Fact  Sheet:  Information  Fusion  Centre,”  28  September  2016. 
https://www.mindef.gov.sg/web/portal/mindef/news-and-

[Online]. 
events/latest-releases/article-detail/2016/september/2016sep27-news-releases-
02341/!ut/p/z1/vVJNc9MwEP0tHHxUtJa_YmYYxrSdtkzcFEjb2BdGdtYfxZZdSY3h37OJg
QukDBd00ezb1dt9b8VzvuW5kvu2lrYdlOwozvLwc7Q-P7sCX9ysg4. 
February 2018]. 

[Accessed 

11 

[7]   C. Bueger, “A role model for information sharing? Visiting the Singapore IFC,” Christian 
Bueger,  10  March  2015.  [Online].  Available:  http://bueger.info/a-role-model-for-
information-sharing-visiting-the-singapore-ifc/. [Accessed 11 January 2018]. 

[8]   IFC,  “Observations  on  sea  theft  and  robberies  recorded  in  Singapore  Strait  and  its 
approaches  –  January  to  December  2017,”  19  January  2018.  [Online].  Available: 
http://www.intertanko.com/upload/112412/IFC-Spot-Commentary-1-18.pdf. 
[Accessed 12 February 2018]. 

[9]   Institute for Security Studies, “Policy brief: effective maritime domain awareness in the 
Available: 
Western 
https://issafrica.s3.amazonaws.com/site/uploads/policy-brief104.pdf.  [Accessed  09 
February 2018]. 

[Online]. 

Ocean,” 

Indian 

2017. 

[10]   “Information Centre MARSEC Weekly Report 04_10 Apr 15,” 15 April 2015. [Online]. 
Available:  https://www.scribd.com/document/262413199/IFC-Weekly-Report-4-10-
Apr-15i. [Accessed 09 February 2018]. 

21/06/2018 

Page 16 of 18 

 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

21/06/2018 

Page 17 of 18 

 
 
 
 
 
 
 
 
 
 
D2.1.1 Structured report on detailed findings for IFC – Draft outline 

6  GLOSSARY 

Glossary 

AIP 

AIS 

ASEAN Information-Sharing Portal 

Automatic Identification System 

ASEAN 

Association of Southeast Asian Nations 

CC2C 

DSTA 

IFC 

ILO 

IMB 

IMO 

IUU 

LRIT 

Singapore’s Changi Command & Control Centre 

Defence Science and Technology Agency 

Information Fusion Centre 

International Liaison Officers 

International Maritime Bureau 

International Maritime Organization 

Illegal, unreported and unregulated 

Long Range Identification and Tracking 

MARISX 

Maritime Information Sharing Exercise 

MARSEC 

Maritime Security 

MDA 

MoU 

MSP IS 

OASIS 

ReCAAP 

Maritime Domain Awareness 

Memorandum of Understanding 

Malacca Straits Patrol Information System 

Open and Analysed Shipping Information System 

The  Regional  Cooperation  Agreement  on  Combating  Piracy  and  Armed 
Robbery against Ships in Asia 

ReMIX 

Regional Maritime Information Exchange 

RSN 

SAM 

SMART 

WPNS 

Republic of Singapore Navy 

Shared Awareness Meeting  

Sense-Making, Analysis and Research Tool  

Western Pacific Naval Symposium  

21/06/2018 

Page 18 of 18