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